El módulo de Restaurante de Axentra está diseñado específicamente para el sector gastronómico dominicano: restaurantes de mesa, cafeterías, bares, food trucks y operaciones con delivery. Integra el ciclo completo de servicio —desde que el cliente se sienta a una mesa hasta que paga la cuenta y el platillo se despacha desde cocina— con el resto del ERP: inventario (descuento de ingredientes), contabilidad (asientos automáticos), facturación electrónica (e-CF) y conduces.
A diferencia del POS tradicional, el restaurante maneja el concepto de orden abierta: una mesa puede acumular consumos durante horas antes de cobrarse, dividir la cuenta entre varios comensales, transferirse a otra mesa si el grupo se muda, o fusionarse con otra orden.
Antes de operar el módulo, es útil entender el vocabulario que usa Axentra:
| Término | Significado |
|---|---|
| Área | Zona física del local (salón principal, terraza, VIP, barra). Cada área agrupa mesas. |
| Mesa | Espacio físico donde se sientan los clientes. Tiene capacidad, ubicación en el plano y estado. |
| Estación | Lugar de la cocina donde se prepara un tipo de platillo (parrilla, frío, postres, bar). Cada producto del menú pertenece a una estación. |
| Orden | Cuenta abierta asociada a una mesa (o a un canal como delivery). Acumula renglones (platillos y bebidas) mientras el cliente consume. |
| Ticket de cocina | Comanda enviada a una estación específica con los platillos a preparar. |
| Canal | Origen de la orden: mesa, para llevar, delivery, barra, plataforma externa (Uber Eats). |
| Mesero | Usuario asignado a una orden. Recibe la propina y es responsable del servicio. |
| Propina legal | 10% sobre el consumo (sin ITBIS) exigido por la Ley 16-92. |
| Propina voluntaria | Gratuidad adicional opcional que el cliente decide dejar. |
Antes de tomar la primera orden debe configurar varios elementos en Configuración → Restaurante. Este proceso solo se hace una vez (o al abrir un nuevo local).
Vaya a Restaurante → Configuración → Áreas.
Para cada área física del local:
Luego, dentro de cada área, cree las mesas:
El editor de plano permite reflejar la distribución real del local, lo que facilita al anfitrión identificar mesas disponibles de un vistazo.
Vaya a Restaurante → Configuración → Estaciones.
Típicamente un restaurante tiene entre 3 y 6 estaciones. Ejemplos:
Para cada estación:
El menú del restaurante reutiliza el catálogo de productos del módulo de Inventario. Esto significa que cada platillo es un producto con:
Para configurar un producto como platillo:
Los modificadores son variaciones que el mesero puede indicar al tomar la orden:
Cada modificador puede:
Los meseros son usuarios con el rol Mesero en Configuración → Usuarios. Cada mesero puede:
En Configuración → Restaurante → Preferencias defina:
El mesero selecciona una mesa desde la pantalla de Plano del Salón:
La mesa pasa a estado Ocupada (rojo) y aparece un cronómetro con el tiempo transcurrido.
Una vez abierta la orden, el mesero agrega platillos:
El carrito se va armando en el panel derecho. Los platillos aún no se han enviado a cocina — están en estado Pendiente.
Cuando el cliente termina de ordenar (o al final de cada curso), el mesero hace clic en Enviar a Cocina.
En este momento:
Si el mesero agrega más platillos después, puede enviar otra ronda a cocina. Cada envío genera un ticket nuevo con la marca de tiempo, para que cocina sepa el orden de llegada.
La estación de cocina ve una pantalla con los tickets activos en tiempo real, suscrita vía GraphQL subscription:
Importante: el botón de Entregar del cocinero marca el platillo como listo y libera la estación inmediatamente — no espera confirmación del mesero (ACK). El backend mantiene el estado pending hasta que el mesero confirma la entrega en la mesa.
Durante la estadía del cliente es normal agregar rondas de bebidas, postres, etc. El flujo es idéntico: buscar, agregar, enviar a cocina. La orden sigue abierta.
Cuando el cliente pide la cuenta:
Una vez el cliente decide el método de pago:
En este momento se dispara el workflow durable de cierre:
La propina se registra en una cuenta por pagar al mesero que se liquida al cierre del turno o periódicamente.
El KDS (Kitchen Display System) y la impresión de tickets son dos caras del mismo flujo: cuando una orden se envía a cocina, Axentra crea un ticket por cada estación involucrada y lo entrega a la pantalla viva de esa estación o a la impresora térmica si la estación está configurada con una.
Cada estación de cocina puede consumir tickets de dos maneras (no excluyentes):
Restaurante → Cocina → Pantalla filtrada por estación. La pantalla muestra los tickets activos a pantalla completa, en grid de tarjetas, con mucho contraste para que se lean desde la línea de cocina.Si la estación tiene impresora configurada, el ticket se imprime automáticamente. Si tiene pantalla activa, también aparece ahí. La mayoría de cocinas usa pantalla; la impresora suele reservarse para estaciones de bar y postres donde la operación es más rápida.
| Estado | Significado |
|---|---|
| QUEUED | Recién creado, esperando que la pantalla lo confirme o la impresora lo imprima |
| PRINTED | La pantalla lo confirmó (botón Listo) o la impresora terminó. Estado de éxito. |
| FAILED | Después de 6 reintentos no pudo entregarse. Requiere intervención (reimprimir manual). |
| VOIDED | Anulado (la orden cambió o se canceló antes de prepararse). |
Al enviar la orden a cocina, Axentra inicia un flujo durable (PrintKitchenTicketWorkflow) por cada ticket. El flujo:
Reintentos: hasta 6 intentos con backoff exponencial 3s → 6s → 12s → 24s → 48s → 2min (cap). En cuanto una pantalla se conecta o la impresora vuelve, el siguiente intento entrega exitosamente.
Si los 6 intentos fallan, el ticket se marca FAILED, se publica un evento al panel de operación, y un usuario humano puede reimprimirlo manualmente desde Restaurante → Cocina → Cola de Tickets.
Vaya a Restaurante → Cocina → Cola de Tickets para ver el estado de todos los tickets en tiempo real.
Columnas:
Filtro por estación. La pantalla mantiene los últimos 200 tickets en memoria y se reconcilia en vivo con la suscripción.
Cualquier ticket - incluso PRINTED - puede reimprimirse manualmente desde la cola:
La reimpresión es útil cuando un ticket se perdió físicamente, la pantalla se cayó, o la impresora se atascó.
La asignación se hace a nivel de categoría: cada categoría del menú apunta a una estación, y todos los productos de esa categoría imprimen ahí. Vaya a Restaurante → Configuración → Estaciones → Ruteo y asigne cada categoría a su estación.
Si un mismo producto debe llegar a dos estaciones (raro pero posible, por ejemplo postres con preparación en frío), defina dos categorías distintas y asigne el producto a la que corresponda según el contexto.
"El ticket no aparece en la pantalla"
Verifique que la pantalla esté abierta filtrada por la estación correcta. Si está abierta y aún no aparece, revise la cola de tickets - probablemente está reintentando. Refresque la pantalla.
"La impresora no imprime el ticket"
Verifique conexión USB/red de la impresora. Axentra reintenta hasta 6 veces con backoff; si la impresora vuelve dentro de los 5 minutos siguientes, el ticket termina imprimiéndose solo. Si pasa más, marque el ticket FAILED y reimprima desde la cola.
"El ticket llega a una estación equivocada"
La categoría del producto está apuntando a la estación incorrecta. Revise Configuración → Estaciones → Ruteo.
El ruteo de órdenes es el mecanismo por el cual Axentra decide a qué estación de cocina se envía cada platillo, en qué momento y con qué prioridad. Un ruteo bien configurado es la diferencia entre una cocina sincronizada (todos los platos salen juntos y calientes) y una cocina caótica (la entrada llega cuando el cliente ya comió el plato fuerte).
Cada producto del menú tiene una estación asignada en su configuración (ver "Configuración Inicial → Menú"). Cuando el mesero hace clic en Enviar a Cocina:
Ejemplo: una mesa ordena ensalada César (Frío), churrasco (Caliente), papas fritas (Caliente), mojito (Bar) y tiramisú (Postres). Al enviar a cocina se generan 4 tickets simultáneos: uno en Frío, uno en Caliente (churrasco + papas agrupados), uno en Bar y uno en Postres.
Para servicio formal, Axentra permite definir cursos — grupos de platillos que deben salir juntos:
Al agregar un platillo, el mesero asigna su curso (o acepta el predeterminado del producto). El sistema encola los platillos por curso y solo los dispara (fire) cuando el mesero lo indica.
En lugar de enviar todo a cocina de una vez, el mesero puede:
Esto resuelve el problema clásico: el principal no se enfría esperando. Cocina recibe el ticket justo a tiempo para que el plato llegue caliente cuando el cliente esté listo.
Alternativamente, configure auto-fire: el curso 2 se dispara automáticamente N minutos después del curso 1, y el curso 3 N minutos después del curso 2. Configurable en Configuración → Restaurante → Ruteo.
Cuando un curso involucra varias estaciones, cada KDS muestra un indicador de sincronización: cada estación ve cuánto tiempo llevan las otras estaciones del mismo curso, para que todas terminen a la vez.
Ejemplo: el churrasco (Caliente) tarda 12 min y la copa de vino (Bar) tarda 30 s. El bar ve "Caliente: 8 min / 12 min estimados" y espera antes de servir, para que el vino no llegue 11 minutos antes que la carne.
Los tickets en el KDS se ordenan por:
El color del ticket cambia según el tiempo transcurrido:
En casos excepcionales, el supervisor de cocina puede reroutear un ticket en vivo:
Cada reruteo queda auditado con quién lo hizo y motivo obligatorio.
El canal de origen afecta el comportamiento del ruteo:
| Canal | Comportamiento |
|---|---|
| Mesa (dine-in) | Ruteo estándar con cursos y fire times |
| Takeout | Todos los platillos al mismo curso, disparo inmediato |
| Delivery propio | Disparo inmediato, prioridad alta si el repartidor espera |
| Bar | Tickets rápidos, ruteo solo a Bar con alta prioridad |
| Uber Eats / plataformas | Disparo inmediato con SLA agresivo; KDS marca rojo al acercarse al tiempo de recogida |
En restaurantes grandes, el expediter coordina la salida de platillos del pase al comedor. Axentra soporta una pantalla de expediter que:
Puede definir reglas por horario:
Se configura en Configuración → Restaurante → Reglas de Ruteo.
El ruteo es local a la sucursal — una orden tomada en la sucursal A nunca se enviará a la cocina de la B. Las estaciones son específicas por sucursal.
Todos los eventos de ruteo quedan registrados:
Esto alimenta los reportes de tiempos de servicio y permite identificar cuellos de botella (ej. "Frío tarda 3 min más que Caliente en horas pico — ¿necesita personal adicional?").
| Estado | Color | Significado |
|---|---|---|
| Abierta | Azul | Se está tomando la orden, no se ha enviado a cocina |
| En curso | Amarillo | Platillos enviados a cocina, cliente consumiendo |
| Cuenta pedida | Naranja | Se generó la precuenta, esperando pago |
| Cerrada | Verde | Pagada y facturada |
| Cancelada | Gris | Anulada (requiere motivo y permiso de supervisor) |
| Estado | Color | Significado |
|---|---|---|
| Libre | Verde | Disponible para nuevos clientes |
| Ocupada | Rojo | Tiene una orden abierta |
| Reservada | Azul | Apartada para una reserva futura |
| Sucia | Gris | Recién desocupada, pendiente de limpieza |
| Bloqueada | Negro | Fuera de servicio (daño, mantenimiento) |
Axentra maneja propinas siguiendo la legislación dominicana.
Al final del turno (o semanalmente, según política):
Cuando un grupo quiere pagar por separado:
Si el grupo se muda a otra mesa (ej. pide terraza al llegar el sol):
Si dos mesas deciden unirse (ej. dos parejas que se conocen):
Una orden puede originarse en distintos canales, y cada uno tiene flujo particular.
Flujo estándar descrito arriba. El cliente consume en el local.
Órdenes rápidas sin mesa asignada:
Ver sección dedicada abajo.
Estado: En desarrollo — requiere completar el módulo de Canales.
Axentra se integrará con Uber Eats para sincronizar menú, recibir órdenes y consolidar la facturación. Cada tenant debe proveer sus propias credenciales de Uber Eats (Axentra no comparte cuentas).
En Configuración → Restaurante → Uber Eats:
Estas credenciales se almacenan cifradas en reposo. Nunca se comparten con otros tenants ni aparecen en logs.
Axentra notifica a Uber Eats los cambios de estado:
Axentra imprime los recibos del restaurante exclusivamente mediante QZ Tray — igual que el POS. No se usa el diálogo nativo del navegador. Esto asegura formato ESC/POS correcto, corte automático y apertura de gaveta si aplica.
El selector de impresora aparece como un botón con ícono 🖨️ en dos lugares:
Flujo:
La selección se guarda en el navegador (localStorage.axentra_pos_printer), así que es por equipo. El mismo valor sirve tanto para POS como para Restaurante.
Cuando el mesero presiona Pay y cierra la cuenta:
Si falla (sin impresora configurada, QZ no corriendo) aparece un error explícito; no hay fallback silencioso.
Idéntico al del POS — encabezado (empresa, RNC, teléfono, dirección), tipo de comprobante (E31/E32), NCF, cliente si aplica, tabla de platillos con cantidad/ITBIS/total, totales, pagos, cambio y QR de DGII.
Para E32 el QR apunta a fc.dgii.gov.do/consultatimbrefc; para E31 a ecf.dgii.gov.do/consultatimbre — igual que en el POS.
Si no usa impresoras físicas, puede operar la cocina 100% digital:
Ventajas:
Restaurante → Reportes ofrece:
El módulo se construye en fases:
| Fase | Estado | Alcance |
|---|---|---|
| A — Fundación | Completada | Migración, dominio, modelos, CRUD, editor de plano |
| B — Ciclo de Orden | Completada | Abrir, agregar, enviar, cerrar orden |
| C — Cocina (KDS) | Completada | Tickets vía GraphQL subscription, ACK de mesero, cola en vivo |
| D — Divisiones | Planeada | Split, transferencia y fusión de órdenes |
| E — Propinas | Planeada | Propina legal (10%) + voluntaria, liquidación |
| F — Canales | Planeada | Takeout, delivery propio, barra |
| G — Uber Eats | Planeada | Integración completa con API externa (credenciales por tenant) |
¿Puedo usar el restaurante sin e-CF?
Sí. En Configuración → Empresa desactive e-CF y el restaurante operará con comprobantes internos. No recomendado si ya está obligado por DGII.
¿Qué pasa si se va la luz o el internet mientras cobro?
La venta se guarda localmente. Cuando vuelve la conexión, el e-CF se reintenta automáticamente. La orden ya está cerrada y el cliente ya pagó.
¿Puedo tener varias sucursales?
Sí, cada sucursal tiene sus propias áreas, mesas, estaciones y usuarios. La contabilidad y el inventario se consolidan a nivel empresa.
¿Se imprime ticket al cliente?
Sí, la precuenta se imprime (no fiscal) y al cerrar se imprime el comprobante fiscal (e-CF) o un recibo interno.
¿Puedo cambiar el ITBIS a 16% para ciertos productos?
Sí, cada producto puede tener su tasa de ITBIS configurada en Inventario. Los productos exentos (0%) también son posibles.
¿Cómo manejo las cortesías (invitaciones de la casa)?
Al agregar el platillo, aplique un descuento del 100% con el motivo Cortesía. El descuento requiere aprobación de supervisor si supera el umbral configurado.
¿Puedo imprimir el menú desde Axentra?
Sí, Restaurante → Menú → Imprimir genera un PDF listo para imprimir con precios actualizados.
Para dudas específicas sobre el módulo de Restaurante, contacte al administrador de su sistema o revise los otros módulos relacionados: POS, Inventario, Contabilidad, e-CF.