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
- Seu provedor faz POST do callback fiscal. O Fire o valida e responde
202 Accepted. Um202significa enfileirado, não processado, e nunca significa que um evento foi enviado. - Um worker em segundo plano guarda o veredito no pedido, normalmente em poucos segundos.
- 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.
Onde cai cada campo do callback
Tudo abaixo cai emorders.fiscal.authority, e dali nos eventos.
Três regras explicam a tabela:
documentviracountryData. O Fire não mantém uma lista das chaves de cada país: tudo o que vem emdocumentchega intacto acountryData. Um identificador novo que o seu órgão passe a exigir viaja sem nenhuma mudança do lado do Fire.provideremetadatamantêm os nomes da numeração. Do lado da numeração o provedor também enviaprovideremetadata, e o Fire os expõe comoproviderIdentityeproviderMetadata. 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 semprovideroumetadata(ou com{}) guardaproviderIdentity: nulleproviderMetadata: 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,deniedouerror. Eles são guardados; o seu consumidor só os vê emlastKnown.fiscal.statusde um evento posterior. - Um
202nã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
authorizedcujoeventIdnão corresponde termina emnotFounde não muda nada; se o pedido não tem documento, oauthorizedo cria. UmeventIdque o Fire não emitiu para esse pedido é rejeitado com400antes do202. Umcancelledresolve o documento mais recente do pedido e o atualiza, seja qual for o provedor que o emitiu — inclusive o PlugNotas.

