Skip to main content
O callback fiscal faz uma coisa: ele grava o veredito do órgão fiscal no pedido. Os eventos não são montados a partir do callback — são montados a partir do que o pedido armazena. Por isso a pergunta “o que o meu consumidor recebe?” tem sempre a mesma resposta: fiscal.authority, com a forma descrita aqui. Se ainda não leu, Como o fiscal funciona no Fire explica os dois atos e os dois blocos que esta página pressupõe.

O que acontece, passo a passo

  1. Seu provedor faz POST do callback fiscal. O Fire o valida e responde 202 Accepted. Um 202 significa enfileirado, não processado, e nunca significa que um evento foi enviado.
  2. Um worker em segundo plano guarda o veredito no pedido, normalmente em poucos segundos.
  3. Dependendo do eventType, o Fire emite um evento para os seus Integration Flows — ou não.

Qual evento dispara

Um evento só é emitido quando o callback realmente mudou o documento. Um reenvio de um estado já aplicado (idempotent), um callback que faria o documento retroceder (regression) ou um que não corresponde a nenhum documento (notFound) também recebe 202, e não emite nada.
order.cancelled não vem do callback. Ele dispara quando o pedido é cancelado no Fire, antes de o órgão ser consultado. A confirmação do órgão chega depois como um callback cancelled, que produz order.reversed.

Onde cai cada campo do callback

Tudo abaixo cai em orders.fiscal.authority, e dali nos eventos. Três regras explicam a tabela:
  • document vira countryData. O Fire não mantém uma lista das chaves de cada país: tudo o que vem em document chega intacto a countryData. Um identificador novo que o seu órgão passe a exigir viaja sem nenhuma mudança do lado do Fire.
  • provider e metadata mantêm os nomes da numeração. Do lado da numeração o provedor também envia provider e metadata, e o Fire os expõe como providerIdentity e providerMetadata. O callback faz o mesmo, então os dois blocos do pedido se leem igual. providerIdentity.reference é o que você cita ao provedor para encontrar a operação nos registros dele.
  • Vazio significa null, não ausente. Um callback sem provider ou metadata (ou com {}) guarda providerIdentity: null e providerMetadata: null.

Onde aparece em cada evento

A referência campo a campo desse bloco está em o bloco fiscal.

O caminho sem callback: Brasil (PlugNotas)

No Brasil não há callback fiscal: o Fire fica sabendo do veredito da SEFAZ diretamente pelo PlugNotas. O bloco que o seu consumidor recebe tem a mesma forma, com estas diferenças:

Um pedido, de ponta a ponta

O mesmo pedido brasileiro pelo callback fiscal, recortado às partes fiscais.
1

Callback: authorized

2

O Fire responde 202 e depois guarda o veredito

3

order.invoiced o carrega

4

O pedido é cancelado no Fire

order.cancelled dispara imediatamente com data.cancellation.fiscal = { "status": "authorized", "authority": { … } } — a fatura como estava. Nada foi pedido ao órgão ainda.
5

Callback: cancelled, depois order.reversed

O provedor envia eventType: "cancelled" com o seu próprio eventId (reutilizar o da autorização retorna 409). O Fire emite order.reversed com authority.documentType: "CREDIT_NOTE", cancelledAt preenchido, os dois documentos em history e compensates apontando para a fatura.

O que não acontece

  • Nenhum evento para rejected, denied ou error. Eles são guardados; o seu consumidor só os vê em lastKnown.fiscal.status de um evento posterior.
  • Um 202 não é um evento. Consulte o endpoint de resultado se precisar saber que o callback foi processado.
  • O callback não altera fiscalRepresentation. O que foi impresso no caixa fica como estava.
  • Não há guard por provedor. Um pedido guarda um único documento. Quando o pedido já tem um documento, um authorized cujo eventId não corresponde termina em notFound e não muda nada; se o pedido não tem documento, o authorized o cria. Um eventId que o Fire não emitiu para esse pedido é rejeitado com 400 antes do 202. Um cancelled resolve o documento mais recente do pedido e o atualiza, seja qual for o provedor que o emitiu — inclusive o PlugNotas.