# Arquitectura de MARIMAR DIGITAL — versión inicial

## Objetivo operativo
Reducir filas y mejorar la preparación de pedidos sin perder control de precios, clientes, inventario ni responsabilidades de cada puesto.

## Mapa de módulos

1. **Clientes** — catálogo, categorías, búsquedas, registro, carrito, compra por unidad/gramos, retiro, delivery, observaciones, pedidos e historial. *Base piloto disponible v0.1*.
2. **Administración** — acceso por rol, mantenimiento inicial de productos y precios, stock, visualización de pedidos, estados y tablero con cifras reales de la base. *Base piloto disponible v0.1*.
3. **Preparación (carnicería, fiambrería, panadería y resto)** — cola por sector, pedidos por peso, ajuste de peso final, faltantes, sustitución autorizada, tiempos. *Próxima fase*.
4. **Turnos/retiros** — capacidad por franja, bloqueo de sobrecupo y confirmación de horarios. *Próxima fase*. En v0.1 se guarda el horario **preferido**, sin prometer cupo reservado.
5. **Caja** — lector de barras, cobros mixtos, arqueo, movimientos, devoluciones y Mercado Pago. *Pendiente*. En v0.1 sólo existe confirmación manual de pago recibido.
6. **Delivery** — repartidor asignado, gestión exclusiva de sus envíos, dirección, geolocalización si el cliente consiente, rutas, estados, cobros. *Pendiente*. En v0.1 el administrador puede cambiar el estado a “en camino”.
7. **Inventario y proveedores** — unidades de compra/venta, ingreso de mercadería, mermas, lotes, proveedores, alertas, ajustes y auditoría. *Pendiente*. En v0.1 se registra movimiento básico por pedido/cancelación/ajuste.
8. **Propietario/reportes** — ventas reales vs. cobradas, márgenes, productos/categorías, comparativos, desempeño por repartidor y por sector, días/horarios. *Pendiente*, salvo resumen piloto sin métricas inventadas.
9. **Notificaciones** — correo, WhatsApp Business bajo integración/consentimiento, SMS opcional, alertas internas. *Pendiente*.

## Decisiones de base de datos que evitan errores

- `products.unit_type = unidad`: `stock_qty`, `min_qty` y `step_qty` expresados en **unidades enteras**.
- `products.unit_type = peso`: esos tres campos expresados en **gramos enteros**. El precio (`price_cents`) se registra por **kilo**.
- Los importes son **centésimos de peso uruguayo**, con redondeo a centésimo por línea: `round(precio_centavos × gramos / 1000)` mediante aritmética entera.
- El `order_items` guarda una copia del nombre, cantidad, unidad y precio de compra: cambiar un producto mañana **no altera** un pedido anterior.
- Stock reservado al confirmar el pedido, dentro de una transacción con bloqueo de filas. Al cancelar, se devuelve una única vez y queda un registro.
- En futuras fases el peso solicitado y el peso realmente pesado **serán dos campos distintos**, con revisión del total, autorización y manejo correcto de pagos. No cobremos automáticamente un peso aún no confirmado.
- Historial de estados vinculados al operador que los cambia.
- Roles previstos: `cliente`, `admin`, `propietario`, `preparador`, `caja`, `delivery`. **Todavía no todos tienen una interfaz especializada.**

## Circuito del pedido y responsables

`Nuevo → Preparando → Listo → (En camino para delivery) → Entregado`.

Puede cancelarse desde Nuevo/Preparando/Listo, con devolución de stock. En caso de pago ya marcado como recibido, primero habrá que incorporar el procedimiento de devolución; el prototipo debe bloquear la cancelación automática de pedidos cobrados.

## Criterio de aprobación del módulo

No se declara lista una fase por tener pantallas. Cada entrega debe incluir escenario reproducible, datos de prueba, control de importes, stock, permisos, manejo de errores y prueba de regresión de lo que ya funcionaba.