CHEFMANAGER IA 3.9.0 · FOOD COURT FASE 4 (PAGO DIVIDIDO)
==========================================================

RESUMEN

Sobre las Fases 1-3 (catálogo agregado, pedido maestro con subpedidos, y
estado conjunto), esta entrega agrega el pago dividido: un pago cobrado en
un punto compartido del patio de comidas se registra y se aplica a los
subpedidos que cubre, marcándolos como pagados. Sigue sin interfaz de
usuario: todo lo nuevo es API + esquema, igual que las fases anteriores.

QUÉ SE AGREGÓ

- Pago central: quien administra el patio (Control Center o administrador
  acotado del patio) registra un cobro — en efectivo, QR, tarjeta,
  transferencia u otro — hecho en un punto compartido (por ejemplo un
  kiosco de pago del propio patio), y lo aplica a uno, varios o todos los
  subpedidos pendientes de pago de un pedido maestro. El monto debe
  coincidir exactamente con el saldo de lo que se está cubriendo, igual que
  ya exige el checkout normal de un pedido.
- Pago por local: cada negocio sigue pudiendo cobrar su propio subpedido en
  su propia caja con el checkout que ya existía desde la Fase 2, sin ningún
  cambio. Las dos formas conviven: un patio puede tener contratos distintos
  con cada operador, y un mismo pedido maestro puede terminar con parte
  cobrada de forma central y parte cobrada por cada negocio.
- Protección contra doble cobro en ambas direcciones: un subpedido ya
  cobrado por su negocio no puede volver a cubrirse con un pago central
  (rechazado con un mensaje claro), y un subpedido ya cubierto por un pago
  central queda con payment_status="paid", que el checkout normal de ese
  pedido ya rechaza como "El pedido ya fue pagado."
- Estado de pago conjunto (FoodCourtService::groupPaymentStatus): "paid"
  solo si todos los subpedidos del grupo están pagados por cualquiera de
  las dos vías, "partial" si al menos uno lo está, "unpaid" si ninguno.
  Visible en el panel de pedidos del patio, en el detalle de un pedido
  maestro y en el seguimiento público del cliente.
- Al cubrirse con un pago central, un subpedido que estaba esperando cobro
  antes de pasar a cocina (política normal de "para recoger" de ese
  negocio) avanza automáticamente a "confirmed", igual que lo haría el
  checkout normal de ese negocio.

ARCHIVOS NUEVOS

- database/sqlite-v21-food-court-payments.sql: tablas
  food_court_order_payments y food_court_order_payment_operators.
- (modificado) app/Support/Database.php: aplica la migración anterior.
- (modificado) app/Services/FoodCourtService.php: groupPaymentStatus(),
  groupPaymentDetail(), groupSuborders(), requiresPrepaymentTakeaway(), y la
  acción "orders/{id}/payments" (GET y POST) del dispatch.
- (modificado) api/public.php: la acción "food-court-track" ahora también
  devuelve payment_status (del grupo y de cada subpedido).

DECISIONES DE DISEÑO Y LÍMITES DELIBERADOS

- Un pago central NO crea ninguna fila en `sales` ni en `payments`, ni
  consume inventario, ni acredita puntos de lealtad. Esas operaciones viven
  en el checkout normal de `orders`, que exige una caja física abierta por
  un empleado real de ESE negocio (Auth::requirePermission('cash.manage') +
  una sesión de caja abierta) — una cuenta de plataforma no tiene, ni debe
  tener, esa autorización sobre la caja de un negocio ajeno. Fabricar una
  venta y un movimiento de caja de un negocio desde una cuenta de plataforma
  sería contabilidad falsa, no una función legítima del patio. Por eso el
  pago central se registra como su propio comprobante
  (food_court_order_payments) y solo actualiza el estado de pago del
  pedido; la reconciliación de cuánto le corresponde recibir en efectivo a
  cada operador de lo cobrado de forma central es exactamente el trabajo de
  la Fase 5 (liquidaciones), documentada en docs/ROADMAP-FOOD-COURT.txt.
- El monto de un pago central debe coincidir EXACTAMENTE (±0.01) con el
  saldo de los subpedidos que se están cubriendo; no se admite pago parcial
  de un solo subpedido individual (por ejemplo, pagar la mitad de lo que
  debe un operador). Esto evita dejar un subpedido en un estado ambiguo
  ("parcialmente pagado") que el modelo de `orders.payment_status`
  (unpaid/paid) no puede representar sin cambios más profundos al sistema
  de pedidos existente, fuera del alcance de esta fase.
- No hay reversa ni anulación de un pago central en esta fase: una vez
  aplicado, no puede deshacerse por API. Si se cobró un pago central por
  error, la corrección queda como un ajuste manual (por ejemplo, un
  reembolso registrado por fuera del sistema) hasta que una fase futura lo
  contemple.

ALCANCE NO INCLUIDO EN ESTA ENTREGA

- Liquidaciones, comisiones del patio y reportes de neto a pagar por
  operador (Fase 5) — ver docs/ROADMAP-FOOD-COURT.txt.
- Reversa o anulación de un pago central ya aplicado.
- Pago parcial de un subpedido individual.
- Interfaz de usuario: registrar un pago central hoy solo se puede hacer
  por API.

ANTES DE PRODUCCIÓN

- Diseñar la interfaz de usuario de Food Court (Fases 1 a 4) antes de
  ofrecer este módulo a un cliente final, incluyendo la pantalla donde
  quien administra el patio registra un pago central.
- Definir con cada patio real si el contrato es pago central, pago por
  local, o una mezcla, y capacitar al personal que cobra en el punto
  compartido para usar operator_ids cuando el pago no cubre todos los
  subpedidos pendientes.
