Skip to main content
POST
Registrar venta perdida
Una venta perdida es dinero que se movió en el mostrador y no quedó registrado como venta. La caja cobró, algo impidió que la orden se creara, y devolviste el cobro ahí mismo.
Sin esta llamada, esa venta no existe en ningún lado. No hay orden, no hay evento y —según la causa— tampoco queda registro en el dominio que falló. El cierre de caja no lo puede explicar y nadie se entera de que una tienda dejó de vender.
No es una anulación. Una anulación tiene orden, nota de crédito y evento order.reversed. Acá la venta nunca llegó a existir.
No sos vos quien decide reportar. Fire lo decide y te lo dice en policy.numberingFailure.action de Emitir comprobante: REFUND significa devolver el cobro y reportar acá; CONTINUE, seguir normal y no reportar nada. La regla la carga la cuenta por vendor, así que puede ser distinta entre dos tiendas del mismo cliente — por eso se pregunta en cada venta y no se cachea.

El cuerpo es el de la inyección

No armes un payload nuevo. Mandá exactamente el mismo JSON que le ibas a mandar a Crear orden, y agregale dos claves al mismo nivel: reason y detail. No es comodidad: adentro corre el mismo mapeo de la inyección, así que la venta perdida queda guardada con la misma forma que una vendida — mismas líneas, mismos totales, mismos medios de pago. Eso es lo que después permite cuadrar la caja del día sumando las dos.
string
requerido
Por qué la venta no llegó a ser orden.No lo deduzcas: te lo devolvemos en policy.numberingFailure.lostSaleReason de la respuesta de numeración. Copialo. El día que agreguemos una causa, no tenés que tocar nada.Es un enum cerrado y no hay endpoint para consultarlo: la lista de arriba es el catálogo completo, y el valor que te toca ya viene en la respuesta que te trajo hasta acá. Mientras sea de este tamaño, una llamada extra para descubrirlo no te compra nada. Si crece, pasa a ser un endpoint y lo vas a ver anunciado acá — el campo no cambia.Cualquier otro valor vuelve 400.
object
Lo propio de la causa. Para FISCAL_NUMBERING_FAILED copiá de la respuesta de numeración:Es opcional a propósito: el peor caso —un error de configuración, que corta antes de crear la solicitud fiscal— no tiene nada de esto, y exigirlo dejaría fuera justo al caso más difícil de detectar.
string
requerido
Del payload de inyección. Junto con el vendor es la llave que hace seguro reintentar.
string
requerido
Del payload de inyección. Sin tienda no se puede cuadrar la caja ni saber quién dejó de vender.
Todo lo demás del payload —client, order.products, payments, createdAt, orderCode…— viaja tal cual y lo interpretamos con el mismo mapeo de siempre.

Autenticación

string
requerido
Tu API key de Fire con scope orders:write. La key debe ser vendor-scoped — las keys sin vendorId se rechazan con 403.

Reintentar es seguro

Es idempotente por orderId + vendor, la misma llave con la que Fire identifica una orden. Si tu caja se queda sin red justo acá —un momento malo, con el cliente enfrente— acumulá y reenviá. No lleva header Idempotency-Key: no existen dos pérdidas distintas de la misma venta.

Ejemplo

Request
201

Errores

Un campo de más no se rechaza, y el día de negocio cerrado tampoco: el dinero ya se movió, y ese mismo día cerrado puede ser la causa de la próxima pérdida. Preferimos guardar de más a perder el rastro de una venta.