Repository navigation
feat(inventario): pantallas de insumos, captura en cocina y existencias - #7
Merged
Merged
Conversation
Tres pantallas de la Fase 1: - Insumos (admin): define QUÉ se controla. Es decisión de negocio, por eso no vive en la tablet de cocina. - Captura (cocina, tablet): un solo tablero con tres modos —llegó mercancía, merma y conteo físico—. Botones grandes de más y menos, cantidad editable a mano para no picar sesenta veces, y el botón de guardar fijo abajo. La usa alguien con las manos ocupadas: si tomara más de un minuto, en dos semanas nadie lo haría. - Existencias: cada renglón se abre y muestra el kardex que formó ese número. El stock sale de sumar movimientos, así que la explicación de un número raro está a un toque. La merma exige motivo: dentro de un mes nadie recuerda qué pasó. Un stock negativo se muestra tal cual —significa una compra sin capturar, y esconderlo sería tapar la señal.
La cocina pidió ver el inventario, no capturarlo. Se separa en dos pantallas distintas en vez de esconder botones: la de cocina es de solo lectura, con números grandes para mirarse de paso, sin historial ni detalle —lo que sobra en una pantalla de consulta rápida estorba tanto como lo que falta. El permiso cambia también en el backend: COCINA conserva únicamente GET /inventario/existencias. Un menú oculto nunca fue un permiso; quien tenga el rol puede mandar la petición a mano.
Se desconecta la pantalla de pedidos: la cocina trabaja con la comanda impresa y la bitácora de accesos no registraba una sola petición a /cocina. Ahora /cocina-panel muestra el inventario, que es el destino al que el backend ya mandaba a ese rol — sin tocar RoutingService. El componente PedidosPanel se conserva con una nota: devolverlo es reponer su ruta y su entrada de menú. El menú se queda aunque tenga una sola opción, porque el botón de cerrar sesión vive dentro del cajón.
Se elige un insumo y se marcan de un jalón los platillos que lo llevan. Son 19 insumos contra 233 productos: al revés habría que abrir cada platillo y recordar en cada uno qué insumos existen. Buscador, filtro de solo marcados, y cantidad por platillo para los que llevan más de una pieza (boneless 6pz y 12pz, milanesa oreja de elefante).
La API de productos entrega el identificador como `id`; la de insumos como `id_insumos`. La pantalla leía `id_productos` en los platillos, que no existe: ninguna casilla aparecía marcada aunque la receta estuviera guardada, y al picarla se escribía en una clave undefined. Se deja anotado en el componente, porque son dos convenciones distintas conviviendo en la misma API y es fácil volver a tropezar.
Cuatro filtros en vez del botón único: todos, marcados, en varios insumos, sin insumo. Cada uno con su conteo, para que revisar sea mirar la pantalla y no leer una lista aparte. Cada platillo muestra además en qué OTROS insumos ya está colgado. Estar en dos puede ser correcto —un gratinado lleva carne y queso— o un error de captura, así que se señala en vez de ocultarse: quien decide es quien conoce la receta. Tras guardar se recarga el panorama, si no los conteos de los filtros quedarían mintiendo.
La captura de "llego mercancia" pregunta ahora cuanto se pago EN TOTAL por cada entrada — solo aparece cuando ya hay cantidad, y es opcional: sin la nota a la mano, la compra se guarda igual y el costo promedio simplemente la ignora. Pantalla nueva /admin/costos: food cost por platillo, ordenado del que menos dinero deja al que mas. El costo es un PISO (solo insumos vigilados) y los platillos con insumos aun sin precio van marcados con asterisco y aviso arriba. Consume el reporte de RestFoodB PR #19.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Frontend de la Fase 1 del inventario. Consume los endpoints de RestFoodB PR #13 — ese tiene que desplegarse primero, si no las pantallas dan 404.
Las tres pantallas
Insumos (
/admin/insumos, ADMIN/DEV) — define qué se controla. Es decisión de negocio, no de operación, por eso no vive en la tablet de cocina.Captura (
/cocina-panel/inventario, COCINA) — la importante. Un solo tablero con tres modos: llegó mercancía, se echó a perder, conteo físico. La usa alguien con las manos ocupadas y prisa, así que:Existencias (
/admin/existencias) — cada renglón se abre y muestra el kardex que formó ese número. Como el stock sale de sumar movimientos y no de una columna, la explicación de un número raro está a un toque.Detalles que vale la pena señalar
Los movimientos de compra y merma se mandan uno por uno, no en lote: si falla el tercero, los dos primeros ya quedaron y no se pierde el trabajo de capturar.
Un stock negativo se muestra tal cual, en rojo. Significa una compra que nadie capturó. Esconderlo sería tapar exactamente la señal que el sistema existe para dar.
Probado
npm run linten 0 warnings ynpm run builden verde.Un apunte de proceso: durante el desarrollo,
npm run buildsobrescribió eldist/que Caddy sirve en producción, metiendo el menú de inventario en las tablets contra un backend que no tiene esos endpoints. Se detectó y se restauró de inmediato reconstruyendo desdemain— mismo hash de bundle, byte por byte lo que estaba desplegado. Vale la pena recordar que en este servidordist/es producción.🤖 Generated with Claude Code