# Sales Order & Customer Service Framework

## Purpose

This file accompanies `hav_seafood_sales_order_customer_service_framework_v1.xlsx` and describes the static **Sales Order & Customer Service Architecture** for HAV Seafood.

It belongs to **Phase 1 — Business Architecture**:

**1. Business architecture -> 2. Stories -> 3. Operational dataset**

The workbook defines **how customer orders and customer-service handling are designed**. It intentionally contains **no actual sales orders, order lines, customer-service cases, emails, shipments, invoices or performance history**.

The core distinctions are:

`Forecast != Confirmed Sales Order != Shipment != Invoice`

and:

`Customer Service Intake != Specialist Case Ownership`

---

## Scope at a glance

The current architecture covers:

- **4 current customer accounts**;
- **73 active customer/SKU listings**, each with exactly one static order-rule assignment;
- **3 reusable customer order profiles**;
- **3 customer-service profiles**;
- **6 sales order types**;
- **4 order-entry channels**;
- **5 commercial lead-time classes**;
- **17 order-validation rules**;
- **9 order-hold types**;
- **10 order lifecycle statuses**;
- **14 customer-service request types**;
- **5 response-service classes**;
- cross-domain interfaces to Production, Logistics, Finance and Quality.

These are current-state rules and structures, not historical activity.

---

## Core model

At a high level:

`Customer Account`

`+ Commercial Market / Channel / Territory`

`+ Customer-SKU Listing / Customer Item Code`

`+ Pricing & Commercial Terms`

`+ Customer Agreement`

`-> Customer Order Profile`

`-> Order Validation / Cutoff / Lead-Time / Site Rules`

`-> Confirmed Sales Order (future Phase 3, ESYS-001)`

`-> Production / Logistics / Finance interfaces`

Customer-service handling follows:

`Customer Contact / Request`

`-> Service Request Type`

`-> Customer Service / Account Owner`

`-> Specialist Routing / Escalation where needed`

`-> Future CRM / specialist operational case records`

---

## Important current-state decisions

### Current customer order profiles

- `CUS-001` Nordmark Food Distribution -> `COP-STRAT-DIST` Strategic Distributor Order Profile;
- `CUS-002` Fjord & Field Retail -> `COP-STRAT-RETAIL` Strategic Direct Retail Order Profile;
- `CUS-003` Baltic Pantry -> `COP-CORE-DIST` Core Export Distributor Order Profile;
- `CUS-004` Northline Grocers -> `COP-STRAT-RETAIL` Strategic Direct Retail Order Profile.

Strategic customers use structured/EDI ordering as the normal primary channel, with email as a fallback. Baltic Pantry uses email/file input with validated manual ERP entry as the normal current model. HAV Seafood has no separate customer portal in the existing systems architecture, so one is not invented here.

### Substitution

The upstream Customer Assortment architecture explicitly marks **all 73 current customer/SKU listings as `Substitution_Allowed_Flag = No`**.

Therefore every current row in `Customer_SKU_Order_Rules` uses:

`SUB-NONE`

The workbook defines customer-approved substitution profiles only as future architectural capability. It does not silently change current listing rules.

### Line minimum versus customer minimum

The architecture keeps two different rules separate:

- **line-level minimum / order multiple** — owned by the Customer Assortment listing architecture; current listings are normally orderable in case multiples with a one-case line minimum;
- **customer-level commercial minimum order** — owned by Pricing & Commercial Terms and currently varies by customer profile (24, 36 or 48 cases).

This distinction prevents line-level ordering rules from being confused with the total-order commercial threshold.

### Customer sites / ship-to boundary

The current Customer Account architecture contains one **city-level primary commercial/buying site** for each customer.

It does not yet contain a detailed network of distribution centres or operational ship-to addresses.

`Customer_Order_Site_Rules` therefore references the existing commercial site for sold-to/commercial identity but explicitly defers detailed ship-to/delivery-site architecture to future Logistics/customer delivery-site work.

No fictitious distribution centres have been inserted merely to make ordering look complete.

---

## System-of-record model

The existing enterprise System & Data Ownership Model is preserved:

- **`DOBJ-082 Confirmed Sales Order` -> `ESYS-001 Core ERP`** — authoritative confirmed executable sales-order transaction;
- **`DOBJ-081 Customer Interaction / Activity` -> `ESYS-006 Sales CRM`** — customer interactions and commercial follow-up;
- **`DOBJ-083 Customer Complaint Intake` -> `ESYS-006 Sales CRM`** — commercial complaint intake/correspondence;
- **`DOBJ-084 Quality Complaint Case` -> `ESYS-003 QMS`** — technical investigation and disposition;
- **`DOBJ-094 Warehouse Pick / Dispatch` -> `ESYS-001 Core ERP`** — warehouse fulfilment transaction;
- **`DOBJ-095 Shipment / Dispatch Record` -> `ESYS-001 Core ERP`** — outbound shipment/dispatch transaction;
- **`ESYS-007 Microsoft 365`** — email, Excel/PDF order-source files and customer communications, but not authoritative for confirmed orders;
- **`ESYS-009 Power BI`** — reporting copies only.

A generic **Customer Service Case** data object is not yet registered in the enterprise ownership model. `System_Mappings` therefore marks it **provisional** for CRM and recommends registering it before Phase 3 operational generation.

---

## Order lifecycle

`Order_Status_Model` defines the structural lifecycle:

`Received -> Validating -> Confirmed -> Released for Fulfilment -> Allocated -> Dispatched -> Completed`

with possible states such as:

- On Hold;
- Partially Fulfilled / Backorder;
- Cancelled.

The workbook explicitly records the owning domain for each status.

Sales owns the commercial order relationship. Logistics owns fulfilment, allocation, dispatch and physical delivery facts. Shipment remains a separate object rather than being collapsed into the sales order.

No status transition events or timestamps are stored in Phase 1.

---

## Requested date versus promised date

The architecture keeps these separate:

- **Requested delivery date** — what the customer asks for;
- **Promised delivery date** — what HAV Seafood confirms after applying cutoff/lead-time rules and operational feasibility.

The customer's requested date should not be silently replaced merely because it is infeasible.

Actual requested/promised dates belong to future Phase 3 order records.

---

## Commercial lead time versus logistics transit

`Commercial_Lead_Time_Classes` defines synthetic internal commercial promise rules.

These are not transport transit-time masters and do not guarantee product availability.

The normal current structure includes:

- core export consolidated orders;
- strategic distributor orders;
- direct retail orders;
- a shorter class for short-shelf-life chilled direct-retail listings;
- preplanned promotional/launch orders.

Production/Logistics remain authoritative for actual operational feasibility.

---

## Backorder and allocation boundary

Backorder profiles define **commercial treatment** such as whether partial fulfilment is normally acceptable and whether the customer must confirm the remainder.

Allocation-priority classes define a **commercial priority input**.

Neither structure allocates stock.

Actual inventory balances, reservations, picking, allocation and shipment activity belong to ERP/Logistics operational data.

---

## Customer-service model

The current first-line Customer Service structure uses the existing HR position:

`POS-SALES-CS-ORDER` — Customer Service & Order Coordinator

with account involvement through the relevant Key Account Manager and commercial escalation to the Sales Manager.

`Service_Request_Types` and `Service_Request_Routing` cover areas including:

- order status;
- order amendments/cancellation;
- availability;
- pricing/commercial terms;
- product information;
- documentation;
- delivery/shipment questions;
- invoice/account questions;
- forecast/planning collaboration;
- return/credit requests;
- product complaints;
- commercial/service complaints;
- customer/item master questions;
- agreement questions.

Customer Service may receive these matters, but receiving a request does **not transfer specialist ownership**.

Examples:

- invoice/AR matters -> Finance;
- product-quality complaint -> Quality/QMS;
- shipment facts -> Logistics/ERP;
- production feasibility -> Production;
- pricing/agreement decisions -> Sales.

---

## Workbook sheets

### `Sales_Order_Types`
Reusable commercial and exception order-type definitions.

### `Order_Entry_Channels`
Permitted structured, email/file, CRM-assisted and manual ERP order-entry routes.

### `Customer_Order_Profiles`
Reusable order policy profiles covering order type, entry channel, lead-time, cutoff, amendments, cancellation, substitution, backorder, allocation and service profile.

### `Customer_Order_Assignments`
Current order/service profile assignment for all four customers, linked to agreement, commercial terms, minimum-order and demand-planning references.

### `Customer_SKU_Order_Rules`
Main customer/SKU order-policy junction covering all 73 active listings.

It preserves upstream orderability, order UOM, line minimum, order multiple and substitution rules while adding Sales order-profile, lead-time, backorder, allocation and downstream pricing/planning references.

### `Order_Cutoff_Rules`
Synthetic internal order-acceptance/cutoff structures.

### `Commercial_Lead_Time_Classes`
Commercial promise classes. These are not physical transit times.

### `Requested_Promised_Date_Rules`
Static rules separating requested dates from future operational promise dates.

### `Order_Validation_Rules`
Customer, listing, item-code, quantity, minimum-order, price, date, site, Finance, Quality, availability and documentation validations.

### `Order_Hold_Types`
Controlled possible hold reasons and owning domains.

### `Order_Status_Model`
Commercial/fulfilment lifecycle states with explicit domain ownership.

### `Order_Status_Transitions`
Permitted normal/exception transitions. No event history.

### `Order_Amendment_Rules`
Rules for quantity, SKU, requested-date, delivery-reference and customer-reference changes.

### `Order_Cancellation_Rules`
Normal and exception cancellation governance.

### `Substitution_Profiles`
Current no-substitution profile plus unused future alternative profiles.

### `Backorder_Profiles`
Commercial backorder/partial-fulfilment treatment by customer profile.

### `Allocation_Priority_Classes`
Commercial priority inputs for constrained fulfilment; not operational allocation.

### `Customer_Service_Profiles`
Reusable first-line service, response and escalation expectations.

### `Service_Request_Types`
Controlled customer-service request taxonomy.

### `Service_Request_Routing`
First-line, account and specialist routing architecture.

### `Response_Service_Classes`
Synthetic internal response targets. No measured SLA results.

### `Customer_Communication_Types`
Possible acknowledgement, confirmation, hold, delay, partial, cancellation, availability, documentation and escalation communications.

### `Order_Document_Requirements`
Static commercial/document reference requirements and downstream document boundaries.

### `Customer_Order_Site_Rules`
Current commercial/sold-to site references and explicit future ship-to boundary.

### `Order_Exception_Types`
Taxonomy of possible ordering exceptions. No exception instances are seeded.

### `Order_Escalation_Rules`
Standard, strategic, specialist, critical, Finance, Logistics and Production escalation structures.

### `Sales_Order_Interface`
Field-level conceptual schema for future sales-order header/line datasets. It contains no order records.

### `Production_Interface`
Sales-order demand handoff boundary to Production planning.

### `Logistics_Interface`
Order-to-fulfilment interface and ownership boundary.

### `Finance_Interface`
Dependencies on future Finance credit, billing, tax and AR architecture without inventing those masters.

### `System_Mappings`
Existing confirmed operational data objects plus provisional future customer-service/order-workflow objects.

### `Order_Service_Classifications`
Supporting Sales-specific controlled values.

### `Relationship_Reference`
Derived AI-friendly current customer view combining key order/service references.

### `Source_Mappings`
Authoritative source and conflict-precedence register.

### `Architecture_Notes`
Key scope, assumptions, boundaries and story-neutrality decisions.

### `Data_Dictionary`
Field-level documentation for the complete workbook.

---

## Ownership boundaries

### Sales owns

- sales-order policy;
- customer order profiles and current assignments;
- commercial cutoff and lead-time rules;
- order validation policy around Sales-owned data;
- customer/SKU order-rule extension;
- requested-vs-promised-date policy;
- commercial amendment/cancellation rules;
- customer-service intake, routing and communication taxonomy;
- commercial escalation and allocation-priority inputs.

### Customer Account / Commercial architectures own

- Customer_ID and customer status;
- commercial site identity;
- market/channel/territory/segment structures;
- account ownership.

### Customer Assortment owns

- valid customer/SKU listings;
- orderability;
- order UOM;
- line minimum/order multiple;
- customer item codes;
- current substitution allowance.

### Pricing & Commercial Terms owns

- current prices;
- pricing profiles;
- customer commercial-term profiles;
- customer-level minimum-order rules;
- freight commercial terms.

### Customer Agreements owns

- current agreement relationship and scope;
- contractual service/commitment references.

### Demand Planning owns

- forecast/planning architecture.

A forecast remains separate from an order.

### Finance owns / will own

- customer credit limits and credit status rules;
- payment terms;
- tax/accounting treatment;
- invoices, credit notes and AR;
- financial hold/release authority.

### Logistics owns / will own

- detailed delivery/ship-to architecture;
- inventory availability;
- allocation;
- picking;
- dispatch;
- shipment;
- carrier/route/delivery execution.

### Quality owns

- product/quality holds;
- technical complaint cases;
- quality evidence and disposition;
- technical product documentation where applicable.

### Production owns

- production feasibility;
- production orders/schedules;
- factory execution.

### HR owns

- positions and incumbency.

Responsibility references in this workbook attach primarily to HR positions.

---

## Architecture boundaries — deliberately excluded

This workbook contains no:

- sales-order headers;
- sales-order lines;
- order dates/timestamps;
- actual quantities;
- actual transaction prices;
- requested/promised dates;
- confirmations;
- amendments;
- cancellations;
- order holds;
- hold releases;
- backorders;
- allocations;
- pick records;
- dispatch records;
- shipments;
- delivery events;
- returns;
- credit notes;
- invoices;
- customer-service cases;
- CRM tickets;
- emails;
- calls;
- response-time records;
- complaint cases;
- order-fill or OTIF metrics;
- customer satisfaction data;
- operational exception events.

These belong to Phase 3 or their future authoritative domain architectures.

---

## Story neutrality

The architecture deliberately does not seed:

- invalid customer item codes;
- pricing discrepancies;
- repeated late orders;
- chronic backorders;
- unfair allocation;
- systematic manual-entry errors;
- repeated customer complaints;
- unresolved service cases;
- credit problems;
- quality holds;
- delivery failures;
- order-confirmation failures.

The structures make such future stories possible without choosing them during Phase 1.

---

## Recommended AI use

For fast context:

1. read this Markdown file;
2. inspect `Relationship_Reference` for customer-level navigation;
3. inspect `Customer_Order_Assignments` for account-level order/service policy;
4. inspect `Customer_SKU_Order_Rules` for detailed orderability/rule coverage;
5. inspect `Order_Validation_Rules`, `Order_Status_Model`, `Service_Request_Routing` and `Order_Exception_Types` for process interpretation;
6. inspect `Sales_Order_Interface`, `Logistics_Interface`, `Finance_Interface` and `Production_Interface` for future Phase 3 dataset boundaries;
7. follow `Source_Mappings` whenever customer, listing, pricing, agreement, demand-planning, position or system facts are required.
