Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/JAQA20/LaComanda/llms.txt

Use this file to discover all available pages before exploring further.

Every order in La Comanda follows a structured lifecycle that connects the front-of-house waiter to the kitchen and barista stations. From the moment a waiter opens the table map to the moment food and drinks are delivered, each step is tracked in real time — ensuring nothing gets lost and every station sees exactly what it needs to prepare.

​
Order Lifecycle

1

Select a table

The waiter opens views/index.php to see the interactive table map. Each table is displayed with its current status: disponible (free and ready to accept a new order) or ocupada (currently has an active order in progress). The waiter taps or clicks a disponible table to begin a new order.
2

Add products

With a table selected, the waiter browses the product catalog, which is grouped by category. Products for each category are loaded on demand via:
GET /public/api/listarProductos.php?categoria={slug}
Replacing {slug} with the category’s URL slug (e.g. cafes, bebidas, platos-principales). The waiter adds the desired quantity of each item before proceeding.
3

Submit the order

When the waiter clicks Submit, the front-end serialises the cart and POSTs it as JSON to:
POST /public/api/guardarOrden.php
The request body must include the following fields:
FieldTypeDescription
mesaintegerTable number
itemsstringOne line per item in "Product Name x Quantity" format
notasstringOptional free-text notes for the kitchen
usuario_idintegerID of the logged-in waiter (from session)
See Item Text Format below for the exact items string syntax.
4

Kitchen and barista prepare

As soon as the order is saved, items automatically appear on the correct preparation screen. The routing is determined by each product’s category slug:
  • Kitchen screen (views/cocina.php) — receives all items whose category slug is not cafes or bebidas (and not mesas).
  • Barista screen (views/barista.php) — receives items from categories with slug cafes or bebidas.
Neither station needs to refresh manually; both screens poll their respective APIs for new work.
5

Mark ready

Kitchen staff progress each order through two actions:
  1. En preparación — cooking has started.
  2. Listo — food is plated and ready for collection.
Barista staff follow the same two-step flow for their drinks and café items. See Kitchen & Barista for the full API details.
6

Deliver

Once items are marked listo, the waiter (or an admin) calls:
POST /public/api/entregarOrden.php
with the fields mesa (table number) and area (e.g. cocina or barista) to mark that sub-order as delivered. When all items across both stations reach entregado, the table’s status automatically returns to disponible and is available for the next party.

​
Order Status States

Each order line (detalle_orden) carries an estado_item that moves through a defined set of states. The table-level estado_general is derived dynamically from those line states and is never stored separately.
StateDescription
pendienteOrder received, not yet being prepared
en_preparacionKitchen or barista has started preparing the item
listoAll items are ready and awaiting delivery
entregadoItem has been delivered to the table
entregadaFull order delivered — every item has reached entregado

​
Order Routing Logic

When guardarOrden.php saves an order, it creates one detalle_orden row per item and sets estado_item = 'pendiente' for each. Routing is then handled by the database view vw_detalle_preparacion, which calculates an area_preparacion column for every item using the following logic:
  • 'barista' — if categoria.slug IN ('cafes', 'bebidas')
  • 'ignorar' — if categoria.slug = 'mesas'
  • 'cocina' — for all other category slugs
The kitchen and barista API endpoints each query this view, filtering on their respective area_preparacion value, so neither station ever sees the other’s items.

​
Item Text Format

The items field sent to guardarOrden.php is a plain-text string with one item per line, using the format Product Name x Quantity: 
Espresso x 2
Sandwich de Pollo x 1
Cheesecake x 3
Each line is parsed server-side to extract the product name and quantity. Ensure product names match the catalog exactly, including capitalisation, as the server uses this string to identify items.

​
Viewing Order History

Admins can review the full order history from views/admin/ordenesAdmin.php. The page fetches data from: 
GET /public/api/ordenesAdminData.php
The response surfaces four key metrics:
MetricDescription
Total ordersAll orders ever placed in the system
RevenueSum of delivered order totals
Delivered countOrders with estado_general = 'entregada'
Pending countOrders still in progress
This view is restricted to admin users and provides a real-time snapshot of restaurant throughput.
Each order’s overall estado_general is calculated dynamically from its detalle_orden items — it is not stored separately.

Build docs developers (and LLMs) love

Get started for freeTalk to us