Every order in CafeteriaPM passes through a well-defined lifecycle enforced by the API. TheDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/123048152-JJDS/CafeteriaPM_S203/llms.txt
Use this file to discover all available pages before exploring further.
PATCH /pedidos/{id}/estado endpoint validates that each transition is allowed before updating the state. Critically, when an order transitions to listo (ready), the API automatically deducts the required ingredient quantities from stock by calling descontar_ingredientes() — no separate inventory step is needed.
Order States
Each state reflects a distinct phase in the order’s journey from placement to payment.| State | Description |
|---|---|
pendiente | Order has been created and is waiting to be picked up by the kitchen. |
en_preparacion | The kitchen has acknowledged the order and started preparing it. |
listo | The order is fully prepared and ready for the waiter to collect. Ingredient stock is deducted at this point. |
entregado | The order has been carried to the table and delivered to the customer. |
pagado | Payment has been processed; a Venta record is created and linked to the order. Terminal state. |
cancelado | The order was cancelled. Only cancelled orders can be permanently deleted. Terminal state. |
reservado | A special state used by the table reservation system. This is not part of the normal order preparation flow. |
Valid Transitions
The API enforces a strict transition graph. Any attempt to jump to a state not listed in the Allowed Next States column is rejected.| Current State | Allowed Next States |
|---|---|
pendiente | en_preparacion, cancelado |
en_preparacion | listo, cancelado |
listo | entregado, pagado, cancelado |
entregado | pagado |
pagado | (terminal — no further transitions) |
cancelado | (terminal — order can only be deleted) |
cancelado can be reached from any non-terminal state (pendiente, en_preparacion, listo, or entregado) as a special shortcut — the transition guard always permits a move to cancelado regardless of the current state.
Automatic Stock Deduction
When an order transitions tolisto, the service calls descontar_ingredientes(db, pedido_id). This function:
- Loads every
OrderDetailrow for the order. - For each detail, iterates over the product’s
ProductoIngredienterecipe entries. - Accumulates the total required quantity per ingredient as
item.cantidad × recipe_quantity. - Checks that every ingredient has sufficient
stock_actualbefore applying any changes. - Subtracts the accumulated quantities from each
Ingrediente.stock_actualin a single atomic flush.
400 Bad Request. No partial deductions are applied.
Example deduction:
GET /stats/inventario-estado (requires admin or cocina role) to spot ingredients approaching their stock_minimo threshold.
Payment Flow
Once an order reacheslisto or entregado, a cashier registers payment by calling POST /ventas/. This creates a Venta record linked to the order and automatically advances the order to pagado.
Venta record stores the cashier ID, payment method, total amount, amount received, and timestamp. The computed cambio (change due) is derived from monto_recibido − monto_total.
History Tracking
Every state transition — including the initialpendiente creation — is recorded in the historial_estados_pedido table. Each row captures:
- The state before the change (
id_estado_origen,nullfor creation) - The state after the change (
id_estado_destino) - The user who triggered the change (
id_usuario) - The exact timestamp (
cambiado_en)
Creating an Order — Full Flow Example
The following sequence walks through a complete order from placement to payment usingcurl.
id_estado_nuevo values correspond to the integer primary keys in the estados_pedido table. You can retrieve the full list of states and their IDs at any time by calling GET /pedidos/estados.