- v2 · atual
- v1.2 · descontinuado
- v0 · descontinuado
Você está lendo o contrato atual (v2) de
order.invoiced. v2 é uma mudança incompatível apenas em data.fiscal: o bloco plano é substituído por um bloco estruturado — campos canônicos dentro de authority, os identificadores do órgão dentro de authority.countryData, valores dentro de authority.amounts — mais history e compensates. docType e dataAutorizacao não são mais emitidos; cStat viaja dentro de authority.countryData. O resto do snapshot do pedido não muda. Veja Mudanças de caminho em relação à versão anterior.order.invoiced dispara quando o órgão fiscal do país autoriza o documento fiscal associado a um pedido — SEFAZ no Brasil, SRI no Equador, DIAN na Colômbia, AFIP na Argentina, SII no Chile, SENIAT na Venezuela.
Este evento é separado de order.completed: o pedido é pago primeiro (order.completed), depois o documento é emitido por meio do seu provedor fiscal, e order.invoiced dispara apenas quando o órgão devolve a autorização.
Condição de disparo
O Fire emiteorder.invoiced quando um documento fiscal do pedido chega a authorized, seja pela integração nativa com o provedor ou pelo callback fiscal com eventType: "authorized".
O que tem em trigger.data
O mesmo snapshot V4 do pedido que order.completed, mais o bloco fiscal descrito abaixo. O status do pedido permanece "COMPLETED": uma autorização fiscal não muda o status do pedido.
Exemplo — Brasil (NFC-e, sanitizado)
Os blocos omitidos como igual a
order.completed são byte a byte o snapshot que order.completed carrega. Veja a referência de campos de order.completed.Campos de dinheiro em
payments.paymentMethods[]. customerCashAmount e changeAmount são números. Os pedidos injetados antes de 24 de setembro de 2026 trazem customerCashAmount como o texto "0" e sem changeAmount: se você reenviar ou reprocessar eventos antigos, leia o campo como número. Veja a referência de campos de order.completed.O bloco fiscal
Para ver como cada campo do callback fiscal chega aqui, veja Do callback aos eventos. O bloco fiscal deorder.invoiced, order.cancelled e order.reversed é o que o Fire guardou no pedido, com a mesma forma. Ele não é reconstruído por emissor: seja o documento vindo pela integração nativa do seu provedor fiscal ou pelo callback fiscal, você lê os mesmos campos na mesma profundidade.
Onde fica em cada evento
Campos do bloco
string | null
O status fiscal do pedido, não de um documento:
awaiting_payment, not_issued, pending, processing, fiscal_graphic, authorized, cancelling, cancelled, rejected, denied, error. Na prática order.invoiced leva authorized, order.reversed leva cancelled e order.cancelled leva authorized ou cancelling.string | null
Código ISO 3166-1 alpha-2 do regime que emitiu o documento (
BR, CO, EC, CL, AR, VE). O país não vive mais no nome do evento: filtre por este campo.string | null
Identificador do Fire para o adaptador que processou o documento (
plugnotas, generic). É nosso, não o nome do provedor.string | null
Timestamp ISO 8601 UTC do fato fiscal que disparou o evento, conforme reportado pelo provedor.
object | null
O veredito do órgão sobre o documento vigente. Os campos que significam o mesmo em todos os países ficam no topo; os identificadores próprios do órgão ficam em
countryData, no vocabulário daquele país.object[]
Cada parada da jornada fiscal do pedido que descreve um documento, da mais antiga para a mais recente — incluindo a atual. Em
order.invoiced normalmente tem uma entrada, igual a authority; em order.reversed tem a fatura e depois o cancelamento. Paradas sem bloco de documento não aparecem — por exemplo o cancelling que o Fire registra antes de consultar o órgão; um processing que já traz a numeração do caixa aparece.Não é
fiscalRepresentation.history. Aquele lista apenas os documentos anteriores da numeração; este é a jornada completa e termina com o documento atual.object | null
Um ponteiro para o documento que o atual substitui. Presente quando o status fiscal do pedido é
cancelled; null caso contrário. Aponta para a última parada de history que não é ela mesma um cancelamento — procure lá o seu documentNumber para ter o documento inteiro.Não carrega
reason, ao contrário de fiscalRepresentation.compensates. O motivo já viaja no mesmo evento, com mais detalhe: cancellation.cancellationType, cancellationGroup, cancellationReason, cancellationNote e cancellationSource. O Fire não emite order.reversed sem um registro operacional de cancelamento, então esse bloco está sempre presente quando compensates está. Um código fixo ORDER_CANCELLATION aqui diria o mesmo com menos informação. O bloco de numeração carrega sim um reason: é onde o código canônico é resolvido no texto impresso na nota de crédito, que precisa do texto próprio da empresa.No Brasil o ponteiro se refere ao mesmo número. A SEFAZ não numera um novo documento para cancelar um, então
compensates.documentNumber é igual a authority.documentNumber. Isso está correto, não é um bug.countryData e o callback fiscal
countryData é um bloco com três nomes, dependendo de qual lado do Fire você olha:
O que seu provedor envia no
document do callback é o que você recebe em authority.countryData, com os mesmos nomes de chave. A regra que separa os dois é a exclusão: toda chave do callback que não é um campo canônico cai em countryData intacta. É por isso que um novo identificador de um país viaja sem nenhuma mudança do lado do Fire.
Os campos raiz do callback se tornam os campos de topo de authority com os mesmos nomes, exceto os três valores, que se agrupam em amounts. provider e metadata viram providerIdentity e providerMetadata (null se ausentes ou vazios). A tabela campo a campo está em Do callback aos eventos.
O
protocolo do Brasil fica em countryData, não no topo. Só a SEFAZ o tem — o Chile tem trackId, a Argentina o cae — então é vocabulário do órgão, não um campo canônico. Pedidos armazenados antes deste contrato o tinham no topo como authorizationProtocol; o Fire o emite como countryData.protocolo também para esses.Mudanças de caminho em relação à versão anterior
Cada caminho anterior tem exatamente um caminho atual. O payload não carrega número de versão: a versão pertence a este contrato documentado.
Onde vivem os totais fiscais
authority.amounts são os valores do documento conforme o órgão os reportou. Os agregados do próprio pedido (vBC, vNF, vICMS…) continuam em data.payments.metadata.fiscal, e a classificação por linha (NCM, CFOP) em data.orderLines[n].metadata.fiscal — igual a order.completed.
Handler de exemplo
Erros comuns
- Leia
fiscal.authority.*, nãofiscal.*. Os campos planos da v1.2 não existem mais. A tabela em Mudanças de caminho mapeia cada um. - Não alinhe por hora usando
authorizedAtno Brasil. Ele carrega uma meia-noite convencional; useissuedAtpara a hora. historyinclui o documento atual. Não conte suas entradas como “documentos anteriores”.- Não há evento para
rejected/denied/error. Esses resultados são armazenados, mas não disparamorder.invoiced.
Eventos relacionados
order.completed
Dispara antes deste evento — o próprio pedido.
order.reversed
Dispara depois se o documento for cancelado no órgão.
Callback fiscal
Como um provedor reporta a autorização que dispara este evento.
data.fiscalRepresentation
Sem mudanças na v2. É a numeração fiscal que o ponto de venda obteve antes de injetar o pedido — o que foi impresso no caixa — e é um bloco diferente de fiscal: fiscalRepresentation é o que foi numerado, fiscal.authority é o que o órgão decidiu. A referência de campos está em order.completed e na página v1.2.