# ADR-003: Product master boundary

- **Status:** Accepted by owner 2026-10-20; additive implementation in progress
- **Date:** 2026-10-19

## Context

The existing `erp_products` table stores a complete product per company. The roadmap calls for a reusable master product database across legal companies while prices, tax treatment, accounts and availability may differ by company.

## Proposed decision

Use an installation-level product identity with variants and barcodes, then a company-level assortment record:

- Product and variant: descriptive identity shared inside the customer installation.
- Barcode: many barcodes per sellable product/variant; the same barcode may be associated with different products to preserve existing supplier mistakes. Ambiguity requires explicit selection and must never silently merge products or auto-post stock.
- Company product: activation, internal SKU when needed, tax code, sales/purchase settings and accounting references.
- Price lists: separate from product identity.
- Media and TDRA certificates: linked to the appropriate product/model version with explicit public/private classification.

## Migration rule

Do not modify or drop the applied `erp_products` migration. P2 must introduce additive tables, backfill in staging, reconcile duplicates and retain a documented rollback path before production deployment.

## Open point

Owner accepted shared product identity and company-specific prices/activation/stock. New master SKU is installation-unique; existing company-specific erp_products remain unchanged pending explicit reconciliation, with no automatic duplicate merges. Owner confirmed SOH prices include VAT at 5%. First implementation uses sellable master rows (including model/color), multiple barcode associations and company-specific dated retail/wholesale/van/clearance prices. No variants are inferred from similar names. Full family/variant hierarchy and controlled master-data editing remain follow-up work.