37 lines
1.7 KiB
Markdown
37 lines
1.7 KiB
Markdown
# F-144 — Historias de producto
|
|
|
|
## Reporting: snapshots de tienda, IVA, coste y envío
|
|
|
|
**Alcance:** backend-only. Añade las columnas mínimas de *snapshot* que el
|
|
módulo `reporting` (F-143↑, F-146 services) necesita para reportar ventas
|
|
multi-tienda sin reescribir la historia (REPORTING_ARCHITECTURE.md §5).
|
|
|
|
## Historias
|
|
|
|
- Como **analista multi-tienda**, quiero que cada pedido (`orders_orders`)
|
|
tenga `store_id` (tienda donde se vendió), para poder filtrar y agrupar
|
|
reportes por tienda sin reescribir histórico.
|
|
- Como **reportista de márgenes**, quiero que el importe del envío
|
|
(`shipping_cents`) esté separado del `total_cents`, para poder exponer
|
|
“ventas de mercancía” y “net sales” con nombres correctos (§5.6).
|
|
- Como **analista financiero**, quiero un *snapshot* del tipo de IVA
|
|
(`vat_rate`) y del coste (`cost_at_sale_cents`) por línea, para poder
|
|
calcular margen histórico e IVA por tipo (§5.2). Estos snapshots son
|
|
**nullable**: hasta que se poblén, margen/IVA-por-tipo permanecen
|
|
`unavailable` (nunca se publican como 0).
|
|
|
|
## Non-goals (fuera de F-144)
|
|
- Poblar `cost_at_sale_cents`/`vat_rate` en el flujo de venta (F-146 /
|
|
reporting-service snapshots).
|
|
- Crear la tabla de payment lines ni refunds (F-145 y el roadmap §5.3-4).
|
|
- Cualquier endpoint de reporte ni cálculo de métricas (F-146).
|
|
- Resolver explícitamente la tienda en el checkout (writes app-layered) — se
|
|
usa el DEFAULT de columna como mínimo; F-146 introduce la resolución de
|
|
tienda por request.
|
|
|
|
## Fuente de verdad
|
|
`orders_orders` y `orders_items` en PostgreSQL (`postgres:16`). La tienda
|
|
default (`id = 00000000-0000-0000-0000-000000000001`) es sembrada por
|
|
`043_pos_basics` y reutilizada desde `src/modules/inventory/index.ts`
|
|
(`DEFAULT_STORE_ID`).
|