Pedidos

Un pedido es una compra confirmada — ítems, totales, tienda, canal y cómo se cumplirá. Fire spark recibe pedidos de cada canal conectado y los enruta a tu POS o RMS para que cocina vea un flujo de tickets consistente.

​

Qué define un pedido comercialmente

​

Por qué importan pedidos unificados

Sin un hub, cada canal manda pedidos por un camino distinto. Soporte no ve historial completo; finanzas reconcilia por plataforma; operaciones maneja varias tablets. Con Fire spark, los pedidos de todos los canales entran al mismo stack operativo. Equipos comerciales y de soporte pueden razonar volumen y mix entre canales, no solo dentro de una app.

​

Pedidos y experiencia del cliente

• Canales propios — Sueles conocer al cliente y puedes soportar reorder y loyalty.
• Agregadores — El marketplace controla gran parte de la UX; tu foco es menú correcto, tiempos y handoff.

Fire spark no reemplaza las reglas de soporte del agregador; asegura que el lado operativo de cada pedido sea confiable.

​

Cómo se paga un pedido

Los tenders viven en un intent de pago, no como un solo pago del pedido. Guárdalos mientras el carrito está OPEN y luego coloca para bloquear el intent. El fulfillment espera en el paso PAYING hasta que los tenders de ese alcance estén liquidados. Si todavía no se capturó nada, reabrir anula esos tenders y devuelve un pedido OPEN nuevo. order_id es opcional y puede ser cualquier id de genId (genOrderId es una opción: por defecto ord-<tienda>- más 12 alfanuméricos; length es al menos 8, por defecto 12, y format puede cambiar el hash). Un literal puede ir pegado al hash, como genId().literal("BB21921").hash(8, "numeric").build() (BB2192100000001). Si lo omites, se conserva el id generado. Los dos pedidos se apuntan en metadata.reopen. Ese pedido nuevo se puede reabrir otra vez igual, una vez colocado y mientras se pueda cancelar.

​

Conceptos relacionados