Numeração¶

Quem escolhe o número do documento é a decisão de migração mais importante desta documentação. Existem duas faixas de comportamento, e a sua credencial fica em uma delas. Não é escolha por requisição.

Numeração pela API (padrão)¶

Nós somos donos do contador. Para cada empresa, modelo, série e ambiente existe um contador travado por linha: números saem em ordem, sem colisão, mesmo com o seu PDV emitindo em paralelo.

Você não envia o número. No FocusNFE, é o comportamento padrão do provedor, então nada muda para você. No ACBrAPI, nós ignoramos ide.nNF nessa faixa.
O código numérico (cNF) é sempre nosso, em qualquer faixa, mesmo quando você controla o número. Nós o sorteamos, e ele entra na chave de acesso.
A série vem do corpo, quando você a informa. Se você omitir, usamos a única série registrada para emissão via API naquela empresa. Se houver mais de uma registrada, nós recusamos a requisição e pedimos que você informe qual. Não escolhemos por você.

Uma série tem um único emissor

Uma série usada pela API não pode ser a mesma que um equipamento de PDV usa localmente. Toda série tem um dono registrado. Tentar emitir por dois caminhos na mesma série é erro de configuração, não uma corrida que alguém vence. Se a sua operação hoje mistura emissão local e emissão em nuvem, separe as séries antes de migrar.

Numeração pelo cliente¶

Se o seu sistema já é o dono da numeração, a sua credencial pode ser configurada para essa faixa. É o caso comum de quem vem do ACBrAPI, onde ide.nNF é campo obrigatório. Aí o comportamento muda de forma importante:

O número passa a ser obrigatório. Omitir nNF (ACBrAPI) ou numero (FocusNFE) é 422. Nós nunca assumimos uma faixa de numeração que é sua: não há troca silenciosa para a numeração automática.
Não há contingência offline. Emitir em contingência significaria inventar um documento no seu espaço de numeração e assiná-lo em seu nome. Em vez disso, respondemos o estado real (ver Contingência).
Um número que a consulta prova vazio volta para você. Se a SEFAZ confirma que não registrou nada naquele número, o pedido termina como rejeitado, com série, número e chave liberados. Não há inutilização automática de um número que você não consumiu.

Quando um número seu pode ser reutilizado¶

Situação do número na SEFAZ	Pode reenviar?
Rejeitado	Sim, se o número não estiver na sua custódia. Rejeição não consome numeração, incluindo rejeições de duplicidade (204, 539)
Autorizado, denegado, cancelado, inutilizado	Não. O número está consumido
Tentativa ainda sem desfecho conhecido	Ainda não. Liberado assim que uma consulta prova o desfecho

A primeira linha fala do pedido feito por aqui. Um número que já tem documento seu na custódia continua ocupado, mesmo que a última tentativa por aqui tenha sido rejeitada. É o caso de documento emitido por equipamento na mesma série, de custódia migrada e de número já inutilizado. Reenviar sobre ele é recusado em banda, e a resposta diz qual número está ocupado.

Na numeração pela API, uma lacuna nunca volta¶

Um número já transmitido que não vira documento deixa uma lacuna no nosso contador. O contador não volta atrás: o próximo pedido recebe o número seguinte, e não o que ficou para trás. Uma recusa nossa, antes da transmissão, não chega a numerar. O número volta, e não há lacuna.

A lacuna é nossa, não da SEFAZ: lá o número continua livre. É por isso que fechá-la exige inutilização, que todos os dialetos expõem. É o mesmo caminho que a plataforma já usa para os documentos que você emite por outros meios, então os relatórios de lacuna continuam valendo.

Quem fecha a lacuna depende de como a tentativa terminou. Se a SEFAZ rejeitou o documento, você a fecha: nós deixamos o número aberto e não avisamos. Se a tentativa ficou sem desfecho, nós a fechamos por conta própria. Reemitimos o pedido em contingência com número novo, e inutilizamos o número morto assim que a consulta prova que ele não chegou a existir. Também inutilizamos por conta própria o documento que emitimos em contingência e que a SEFAZ recusa depois.

A chave de acesso¶

Montamos a chave de 44 caracteres e o dígito verificador. Se você declarar uma chave na requisição, nós a conferimos contra o próprio documento antes de qualquer aritmética. Uma chave que discorda do documento que ela identifica é um erro pior que um dígito errado, e nós a tratamos como tal.