centralize sales flow

docs/SALES_MODULE_PLAN.md

@@ -15,6 +15,26 @@ The design stays aligned with the existing backend patterns:
 
 Returns, credit notes, and sales returns are **out of scope for Phase 1**.
 
+### Current Implementation Status
+The Phase 1 core is implemented and wired across the backend and frontend for:
+- sales invoices
+- sales slips
+- free issues as a slip alias
+- bundle sales
+- sales posting to stock/FIFO
+
+Shared backend services now centralize the repeated sales logic:
+- sales validation and pricing
+- sales posting checks and FIFO outbound posting
+- invoice/slip mapping and totals
+- shared draft edit/load workflow checks
+
+Still intentionally separate:
+- bundle pricing and bundle margin behavior
+- production and GRN as upstream stock/cost sources
+- reservation/backorder flow
+- sales reports visibility in the frontend UI, which is currently hidden from the navigation but still implemented in the backend
+
 ---
 
 ## Phase 1 - Basic Standard Sales Module
@@ -42,6 +62,22 @@ Implement the minimum sales flow needed for both B2B and B2C:
 - Stock posting
 - Basic sales reports
 
+### Implemented Shared Services
+- `ISalesDomainService`
+  - header validation
+  - line validation
+  - price resolution
+  - line financial computation
+  - stock-item classification
+- `ISalesPostingService`
+  - invoice/slip/bundle posting checks
+  - shared FIFO posting for stocked items
+- `ISalesMappingService`
+  - invoice/slip totals mapping
+  - invoice/slip DTO mapping
+- `ISalesDocumentWorkflowService`
+  - shared editable-document load and concurrency checks for invoice/slip draft updates
+
 ### Not in Scope for Phase 1
 - customer groups
 - price lists
@@ -51,6 +87,7 @@ Implement the minimum sales flow needed for both B2B and B2C:
 - approval workflow
 - returns and credit notes
 - advanced customer segmentation
+- fully unified sales provenance tracing across production, GRN, and sales documents
 
 ### Phase 1 Entity Design
 
@@ -211,6 +248,20 @@ When an invoice or slip is posted:
 - maintain source document traceability
 - update totals in the same transaction
 
+Sales document provenance is stored by document family:
+- `SalesInvoice` / `SalesInvoiceLine`
+- `SalesSlip` / `SalesSlipLine`
+- `BundleSale` / `BundleSaleLine`
+
+Inventory movement provenance is stored in:
+- `StockLayer`
+- `StockLedger` via `SourceDocType` / `SourceDocId`
+- `JournalEntryStub` via `SourceDocType` / `SourceDocId`
+
+Upstream cost/availability sources remain:
+- `Grn` / `GrnLine` for inbound purchasing cost
+- `ProductionRun` and stage tables for finished-goods production cost
+
 ### Phase 1 API Route List
 - `GET /api/v1/customers`
 - `GET /api/v1/customers/{id}`
@@ -239,6 +290,10 @@ When an invoice or slip is posted:
 - `GET /api/v1/reports/sales/{reportId}`
 - `POST /api/v1/reports/sales/query`
 
+Note:
+- the sales report backend routes remain implemented
+- the frontend report entry points are currently hidden from navigation, but the screens and API contracts still exist
+
 ### Phase 1 Folder / Module Plan
 - `Domain/Entities`
   - add `Customer`, `SalesInvoice`, `SalesInvoiceLine`, `SalesSlip`, `SalesSlipLine`
@@ -389,6 +444,7 @@ Allocation of a payment across invoices.
 - Verify discounts calculate correctly by percentage and fixed value.
 - Verify free issue lines post stock and appear in reports.
 - Verify stock ledger entries are created once per posted document.
+- Verify the frontend sales hub and sidebar only expose invoice, slip, and free-issue entry points while report pages remain reachable directly.
 - Verify Phase 1 routes remain stable before Phase 2 is added.
 
 ## Assumptions