> ## Documentation Index
> Fetch the complete documentation index at: https://firespark.cloud/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Pedidos

> Una compra del cliente desde cualquier canal, enrutada a tu operación.

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

| Campo | Significado para los equipos |
| - | - |
| Canal | Dónde pidió el cliente (app, Uber Eats, kiosco, …) |
| Tienda | Qué ubicación lo prepara |
| Líneas | Productos con las elecciones de grupos de modificadores del cliente |
| Fulfillment | Pickup, delivery o dine-in |
| Estado | `OPEN` mientras es carrito, `CLOSED` después de colocar, luego `COMPLETED`, `VOIDED`, `REVERSED` o `REFUNDED` |
| Pago | `payment_intents[].tenders[]`: método, monto, `collect_at` y estado. Ver [Pagos](https://firespark.cloud/docs/es/concepts/payments.md). |

## 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](https://firespark.cloud/docs/es/storefront-api/orders/\[id]/place/post) 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](https://firespark.cloud/docs/es/storefront-api/orders/\[id]/reopen/post) 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

> [card] [Canales](https://firespark.cloud/docs/es/concepts/channels.md)
>
> Dónde nacen los pedidos

> [card] [Fulfillment](https://firespark.cloud/docs/es/concepts/fulfillment.md)
>
> Cómo se completan

> [card] [Tiendas](https://firespark.cloud/docs/es/concepts/stores.md)
>
> Dónde se preparan


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.