Skip to main content
POST
Registrar venda perdida
Uma venda perdida é dinheiro que se movimentou no balcão e não ficou registrado como venda. O caixa cobrou, algo impediu que o pedido fosse criado, e você devolveu o valor ali mesmo.
Sem esta chamada, essa venda não existe em lugar nenhum. Não há pedido, não há evento e —dependendo da causa— também não fica registro no domínio que falhou. O fechamento de caixa não consegue explicar e ninguém fica sabendo que uma loja parou de vender.
Não é um cancelamento. Um cancelamento tem pedido, nota de crédito e evento order.reversed. Aqui a venda nunca chegou a existir.
Não é você quem decide reportar. A Fire decide e avisa em policy.numberingFailure.action de Emitir comprovante: REFUND significa devolver a cobrança e reportar aqui; CONTINUE, seguir normal e não reportar nada. A regra é definida pela conta por vendor, então pode ser diferente entre duas lojas do mesmo cliente — por isso é perguntada em cada venda e nunca fica em cache.

O corpo é o da injeção

Não monte um payload novo. Mande exatamente o mesmo JSON que você ia mandar para Criar pedido, e acrescente duas chaves no mesmo nível: reason e detail. Não é conveniência: por dentro roda o mesmo mapeamento da injeção, então a venda perdida fica guardada com a mesma forma de uma vendida — mesmas linhas, mesmos totais, mesmos meios de pagamento. É isso que depois permite fechar o caixa do dia somando as duas.
string
obrigatório
Por que a venda não virou pedido.Não deduza: devolvemos em policy.numberingFailure.lostSaleReason da resposta da numeração. Copie. No dia em que adicionarmos uma causa, você não mexe em nada.É um enum fechado e não há endpoint para consultá-lo: a tabela acima é o catálogo completo, e o valor de que você precisa já veio na resposta que te trouxe até aqui. Enquanto for deste tamanho, uma chamada a mais para descobri-lo não compra nada. Se crescer, vira um endpoint e você vai ver isso anunciado aqui — o campo não muda.Qualquer outro valor volta 400.
object
O que a causa carrega. Para FISCAL_NUMBERING_FAILED copie da resposta da numeração:Opcional de propósito: o pior caso —um erro de configuração, que corta antes de criar a solicitação fiscal— não tem nada disso, e exigir deixaria de fora justamente o caso mais difícil de detectar.
string
obrigatório
Do payload de injeção. Junto com o vendor é a chave que torna o reenvio seguro.
string
obrigatório
Do payload de injeção. Sem ela não dá para fechar o caixa nem saber quem parou de vender.
Todo o resto do payload —client, order.products, payments, createdAt, orderCode…— viaja tal como está e é interpretado com o mesmo mapeamento de sempre.

Autenticação

string
obrigatório
Sua API key da Fire com escopo orders:write. A key precisa ser vendor-scoped — keys sem vendorId são rejeitadas com 403.

Reenviar é seguro

É idempotente por orderId + vendor, a mesma chave com que a Fire identifica um pedido. Se o caixa ficar sem rede bem aqui —um momento ruim, com o cliente na frente— acumule e reenvie. Não leva header Idempotency-Key: não existem duas perdas diferentes da mesma venda.

Exemplo

Request
201

Erros

Um campo a mais não é rejeitado, e um dia de negócio fechado também não: o dinheiro já se moveu, e esse mesmo dia fechado pode ser a causa da próxima perda. Preferimos guardar demais a perder o rastro de uma venda.