Cómo configurar el paso por cocina de un producto
Marca si un producto debe pasar por cocina/KDS y define, si hace falta, el nombre corto que verá cocina sin cambiar impresoras ni habilitar KDS globalmente.
En este artículo
Esta guía ayuda a responsables de catálogo, sala y cocina a decidir qué productos entran en el flujo de cocina. En la demo ES puedes usar Grupo Marea Demo, Marea Gran Via y Croquetas de jamon como ejemplo de producto que ya requiere cocina.
El cambio se hace desde el formulario completo de producto. KDS mostrará primero `Nombre cocina`, después `Nombre corto` y, si no hay ninguno de los dos, el nombre principal del producto.
Antes de empezar
- Hay una organización seleccionada; en ámbito de ubicación también hay una ubicación seleccionada, por ejemplo Grupo Marea Demo y Marea Gran Via.
- El producto existe en el mismo ámbito editable desde el que se abre, o se está creando desde el formulario de producto.
- Para abrir el detalle se necesita `catalog:view` o `catalog:manage`; para guardar cambios se necesita `catalog:manage`.
- El producto completo sigue siendo válido antes de guardar: nombre, precio, tipo de producto y categoría fiscal.
- Para ver el resultado en KDS, KDS debe estar habilitado y el usuario debe tener permisos de KDS/TPV; la demo ES no trae `kitchen_name` precargado.
Instrucciones
- 1.
Abrir el producto
Desde Catálogos > Productos, abre el producto que quieres revisar. En Marea Gran Via, `Croquetas de jamon` es un buen ejemplo para mostrar un producto de cocina con `requires_kitchen=true`.
- 2.
Comprobar si se puede editar
Si el usuario solo tiene lectura, el producto está eliminado o pertenece a otro ámbito, la pantalla queda como consulta. Para cambiar la configuración debe existir permiso de gestión en el mismo ámbito editable.
- 3.
Activar o desactivar Requiere cocina
Usa el control `Requiere cocina` para decidir si el producto entra en el flujo KDS. Activado lo hace visible para cocina cuando se añade a tickets nuevos; desactivado lo deja fuera del flujo de cocina habitual.
- 4.
Rellenar Nombre cocina si hace falta
Escribe un nombre más corto o más claro para cocina. Si lo dejas vacío, KDS usará el nombre corto del producto y después el nombre principal como fallback.
- 5.
Guardar el producto
Pulsa Guardar cuando haya cambios pendientes y el producto siga siendo válido. El guardado actualiza el producto completo, así que revisa precio, tipo, impuesto y el resto de campos antes de confirmar.
- 6.
Comprobar el efecto en TPV y KDS
La acción no reescribe tickets ya guardados directamente. El efecto aparece cuando TPV/KDS enriquecen los `ticket_items` con los datos actuales del producto y KDS filtra los items que siguen en cocina.
Validaciones y límites
- Abrir el detalle requiere `catalog:view` o `catalog:manage`; guardar requiere `catalog:manage`.
- Desde ubicación no se edita un producto heredado de organización si no coincide con el ámbito escribible.
- Guardar permanece deshabilitado si no hay cambios o si el producto completo no es válido.
- El frontend exige nombre no vacío, precio parseable, tipo de producto y categoría fiscal; el backend exige nombre y precio mayor que 0.
- `Requiere cocina` es booleano y `Nombre cocina` es opcional; el texto se recorta y vacío se guarda como ausencia de `kitchen_name`.
- Si `requires_kitchen=false`, los nuevos items normales no avanzan por `sent`, `preparing` o `ready`; los items que ya estén en esos estados siguen tratándose como cocina.
- Esta acción no habilita KDS, no configura impresoras ni define estaciones de cocina; eso depende de `tpv_settings.enable_kds`, permisos y configuración TPV/KDS.
Resultado esperado
El producto queda guardado con `requires_kitchen` y, si aplica, `kitchen_name`. A partir de ahí, TPV y KDS pueden usar esa marca para el flujo de producción y mostrar en cocina el nombre priorizado correcto.