# BR-SALES-001 — Customer/product purchase history

Recorded: 2026-10-19
Source: explicit owner request.
Status: CONFIRMED REQUIREMENT — planned, not implemented.
Delivery phase: P4 Sales & CRM; depends on posted invoice lines and customer/product identity.
Financial reconciliation and adjustments integrate with P6; consignment allocations integrate with P7.

## Confirmed business rule

The same sales history must be searchable in both directions:

1. Customer -> product:
   From a customer's invoice/purchase history, search for a particular item/product.
   Show when that customer purchased the product and the amounts paid/invoiced for those purchases.

2. Product -> customer:
   From a product's sales/history page, show which customers purchased it.
   Search/filter that history by a particular customer and inspect purchase dates and amounts.

Both entry points refer to the same underlying invoice lines and source documents.
This is required core ERP behavior and must work without AI.

## Required results

- Customer identity, product identity, purchase/invoice date, invoice reference and amount.
- Drill through to the source invoice when the caller is authorized.
- Filters combine customer and product rather than searching unrelated customer purchases.
- Preserve historical transactions when names, SKUs or prices change.
- Enforce company/branch permissions at query and document-access levels.
- Do not expose all customers to someone who is only authorized for a subset.

## Proposed acceptance criteria for P4 review

The following details are implementation proposals, not additional owner-approved accounting policy:

- Result rows include quantity, unit price, discount, net amount, tax, gross amount, currency and document status.
- Optional date range, SKU/barcode/name search and pagination.
- Totals distinguish gross sales, returns/credit notes and net sales.
- Cancelled/draft documents are excluded by default or shown with explicit status.
- Multiple currencies are not added together without an explicit conversion basis.
- Payment allocation is distinct from invoice value: do not call an invoice amount cash collected unless receipt allocation proves it.
- The product and customer screens return consistent totals for identical filters.
- Use invoice-line queries and appropriate indexes, not a separately editable history copy.
- Snapshot fields preserve what was sold at the time, alongside immutable entity references.
- Tests cover partial invoices, multiple purchases of one product, returns, corrections and cross-company denial.

## Open details to settle at the relevant phase

- Whether the default date is invoice date, posting date or delivery date.
- Which amount columns and VAT basis are displayed by default.
- Whether to show receipt allocations alongside invoice values.
- Date-range defaults and export needs.
- For consignment: delivery alone is not a purchase invoice; only sold-and-invoiced quantities appear as purchases. DN traceability remains available internally.

## Planning boundary

Documented now so the P4 invoice-line design and product history UI account for it.
Do not implement this feature before the sales/customer/invoice foundations are ready.
This document does not claim that invoices, customer sales history or payments currently exist in ERP.