mercadodevida/work/artifacts/F-142/implementer.md

F-142 — Implementer evidence

Entrega

Se completó la fase obligatoria de discovery antes de crear componentes o endpoints:

• docs/reporting/REPORTING_ARCHITECTURE.md
• docs/reporting/REPORTING_TASKS.md

También se abrieron los tickets P0 iniciales en el backlog mediante scripts/new_ticket.py:

• F-143 — contracts, filters and RBAC
• F-144 — historical store and financial snapshots
• F-145 — payment lines and POS cash-safe capture
• F-146 — ReportingService, summary and sales API
• F-147 — Admin reporting shell and global filters
• F-148 — sales dashboard and channel views
• F-149 — product/category/brand reports
• F-150 — CSV export

Hallazgos principales

• La fuente única actual es orders_orders + orders_items, pero las ventas todavía no tienen store_id directo.
• TPV ya distingue source, terminal_id y cash_session_id, aunque el flujo POS completo todavía está en tickets POS posteriores.
• Pagos actuales son eventos de proveedor y no contienen método de pago ni líneas para pagos mixtos.
• No existe un modelo de devoluciones detallado ni movimientos de caja inmutables.
• orders_items conserva precio/descuento/impuesto, pero no vat_rate ni cost_at_sale; por tanto IVA por tipo y margen se marcan como no disponibles.
• El total de pedido no separa portes, por lo que la API futura debe distinguir total cobrado de ventas de mercancía.
• Categoría/marca actuales no son snapshots históricos.

Scope deliberadamente excluido

No se implementaron endpoints, tablas reporting paralelas, dashboards, datos mock, cálculos financieros frontend ni caché prematura. La implementación comienza en F-143/F-144/F-145 y respeta el orden de dependencias documentado.

Verificación

./scripts/verify.sh       ✅
backlog válido (264)      ✅
una sola feature activa (F-142) ✅