Knowledge Domain Database - Retail & E-commerce
How does the domain work before writing a line of code? Choose a document from the left tree: each page explains part of the model.
Business Rules - Retail & E-commerce (EN)
BR-001: Net Available ≥ 1 for BOPIS Reservation
Code: BR-001 Name: BOPIS Availability Threshold Description: Before accepting a BOPIS order for a Product at a Store, the net available quantity (on_hand − reserved) must be ≥ 1. Reserving on a zero or negative net available generates a fulfilment failure. Rationale: BOPIS cancellations due to inventory inaccuracy directly damage customer experience and trust. A buffer of 1 unit above zero absorbs minor synchronisation delays between POS and OMS. Priority: Critical Actors: OMS, Inventory System Violation Consequence: BOPIS order rejected at checkout with "not available at this store" message. Customer redirected to next nearest store with availability. Traceability: UC-04 (BOPIS), INV-001
---
BR-002: Monetary Values as Integer Cents
Code: BR-002 Name: Integer Cents for All Monetary Values Description: All monetary amounts (price, cost, discount, total) must be stored and computed as INTEGER CENTS. Example: €19.90 = 1990. FLOAT and DECIMAL types are prohibited for monetary columns. Rationale: Floating-point arithmetic introduces rounding errors (e.g., 0.1 + 0.2 ≠ 0.3 in IEEE 754). In retail pricing and promotional calculations, even 1-cent errors compound to significant financial discrepancies across millions of transactions. Priority: Critical Actors: All systems handling monetary data (POS, OMS, ERP, e-commerce) Violation Consequence: Financial reporting discrepancies, incorrect promotional calculations, potential regulatory issues in price compliance. Traceability: All entities with monetary fields, schema.sql
---
BR-003: Automatic Reorder Trigger at Reorder Point
Code: BR-003 Name: Automatic Replenishment at Reorder Point Description: When (quantity_on_hand + quantity_on_order) falls below the reorder_point for a SKU at a Store, the system automatically generates a replenishment order to the supplier without requiring manual buyer intervention. Rationale: Manual replenishment introduces human lag and is error-prone at scale. Automated replenishment maintains shelf availability with minimal operational overhead. Priority: High Actors: Inventory System, ERP, Supplier Violation Consequence: Stockout risk, loss of sales, customer dissatisfaction, potential OSA KPI breach. Traceability: UC-01 (automated replenishment), BP-02 (supplier category management)
---
BR-004: GDPR Consent Required for Marketing Communications
Code: BR-004 Name: GDPR Marketing Consent Gate Description: Marketing communications (email, SMS, push notifications, personalised offers) may only be sent to customers with gdpr_consent = true AND gdpr_consent_at IS NOT NULL. Rationale: GDPR Regulation (EU) 2016/679 Art. 6(1)(a) requires explicit, informed, freely given consent as the lawful basis for marketing communications. Processing without consent exposes the company to administrative fines up to €20 million or 4% of global annual turnover. Priority: Critical (regulatory) Actors: CRM System, Marketing Platform, Data Protection Officer Violation Consequence: GDPR violation - regulatory fines, reputational damage, mandatory breach notification. Customer may file complaint with Supervisory Authority (Garante in Italy). Traceability: UC-05 (churn detection), Customer entity, BP-02
---
BR-005: Returns Within Policy Period and Condition
Code: BR-005 Name: Return Eligibility Validation Description: A return is accepted only if: (a) the return request is within the policy period from delivery date (typically 30 days, varying by category), AND (b) the product condition is acceptable (not excluded by policy, e.g., opened perishables, personalised items). Rationale: Return policy sets customer expectations and operational boundaries. Accepting returns outside policy creates operational chaos and financial exposure. EU Consumer Rights Directive (2011/83/EU) mandates minimum 14-day right of withdrawal for online purchases. Priority: High Actors: Store Cashier, OMS, Customer Service Violation Consequence: Return rejected; customer informed of policy with reference to order details. Traceability: UC-03 (omnichannel return), BP-04 (reverse logistics)
---
BR-006: Promotional Price Above Minimum Margin Floor
Code: BR-006 Name: Promotion Margin Floor Guard Description: A promotional price must be strictly greater than the cost price + minimum margin floor percentage defined per category. Formula: promo_price_cents > CEIL(cost_price_cents × (1 + margin_floor_pct / 100)). Rationale: Promotions below cost (selling at a loss) erode profitability without necessarily building loyalty. The margin floor ensures promotions remain commercially sustainable. Priority: High Actors: Pricing System, Category Manager Violation Consequence: Promotion configuration rejected; Category Manager alerted with calculation breakdown. Override possible with Merchandising Director approval. Traceability: UC-02 (markdown), BP-05 (flyer campaign)
---
BR-007: Inventory Movement Mandatory Reason
Code: BR-007 Name: Inventory Movement Audit Trail Description: Every change to quantity_on_hand must be recorded via an InventoryMovement with a mandatory movement_type (sale, return, transfer_in, transfer_out, write_off, cycle_count, receiving). Direct updates to on_hand without a movement record are forbidden. Rationale: Full inventory audit trail is essential for loss prevention analysis (shrinkage calculation requires reliable movement data), supplier dispute resolution, and regulatory compliance. Priority: High Actors: All systems with write access to inventory (POS, OMS, WMS, Receiving) Violation Consequence: Inventory reconciliation impossible; shrinkage calculations inaccurate; internal audit failure. Traceability: UC-03 (return), UC-06 (perishable write-off), BP-03 (store operations)
---
BR-008: Order Status Valid Transition Sequence
Code: BR-008 Name: Order State Machine Transition Guard Description: Order status transitions must follow the valid state machine. Invalid transitions are rejected. Valid transitions: pending → confirmed, confirmed → picking, picking → ready_for_pickup (BOPIS) or shipped, ready_for_pickup → delivered, shipped → delivered, delivered → return_requested, return_requested → returned. From any state: confirmed → cancelled. Rationale: Preventing invalid status transitions ensures operational coherence between OMS, warehouse, store, and carrier systems. An order jumping from pending to delivered without picking would skip fulfilment verification. Priority: Critical Actors: OMS, WMS, POS, Carrier Integration Violation Consequence: Status update rejected; error logged; fulfilment team alerted for manual investigation. Traceability: UC-03, UC-04, state machine ordine-omnicanale-lifecycle
---
BR-009: Food Donation Documentation per Italian Law 166/2016
Code: BR-009 Name: Perishable Donation Fiscal Documentation (Legge Gadda) Description: When perishable products are donated to non-profit organisations per Italian Law 166/2016 (Legge Gadda), the donation must be documented with: (a) a delivery note (DDT) identifying donor, recipient, products, and quantities; (b) a monthly donation summary declaration if using the simplified regime; (c) the donated products must be safe for consumption at the time of donation. Rationale: Law 166/2016 provides tax benefits (VAT exemption, income tax deduction) for food donations to non-profits. The documentation requirement is the condition for accessing these benefits and demonstrating compliance. Priority: Medium (regulatory - Italy only) Actors: Store Manager, Finance, Non-profit Partner Violation Consequence: Loss of tax benefit; potential regulatory non-compliance. Donated products without documentation create inventory discrepancies. Traceability: UC-06 (perishable expiry management)