# Sales & Commercial Architecture

## Purpose

This folder contains the static **Sales & Commercial Architecture** for **HAV Seafood**, the fictional Faroese seafood manufacturer used in the synthetic business dataset.

The files define how HAV Seafood's commercial side is structurally designed: customer accounts, markets, channels, territories, customer assortments, product listings, pricing, commercial terms, customer agreements, demand planning, sales-order rules, customer-service handling, commercial processes, authority and controls.

The architecture belongs to **Phase 1 — Business Architecture** of the project:

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

It describes **what exists and how Sales & Commercial are designed**. It intentionally does **not** contain operational or historical sales activity such as sales orders, invoices, forecasts, CRM interactions, customer-service cases, actual discounts, shipments, approval events or sales-performance history.

---

## Core architecture principles

The Sales & Commercial Architecture follows these rules:

- Shared Enterprise customer-organization, market, country, currency, language, system and identifier structures are reused rather than redefined.
- Production remains authoritative for finished-product / SKU identity and technical product characteristics.
- HR remains authoritative for employees, job roles, positions, position seats, incumbency and the enterprise authority backbone.
- Sales owns the commercial customer extension, Sales channels, customer segments, commercial territories, customer assortment/listing structures, pricing rules, commercial terms, customer agreements, demand-planning rules, order/customer-service rules and Sales process/control architecture.
- Finance is expected to remain authoritative for payment terms, customer credit, accounting treatment, invoicing, accounts receivable, tax, company-wide monetary approval limits and financial settlement.
- Logistics is expected to remain authoritative for shipment execution, carriers, routes, dispatch, delivery and transport performance.
- Quality remains or is expected to become authoritative for technical quality requirements, technical customer complaints, product compliance, release and quality evidence.
- Marketing should own consumer-facing brand, campaign and consumer-marketing structures rather than Sales redefining them.
- Current-state commercial master data is separated from historical or transactional activity.
- Rules, profiles and eligibility are modeled separately from actual events and outcomes.
- Authority is attached primarily to positions and authority classes rather than named employees.
- Derived reference workbooks do not override authoritative source workbooks.
- If a derived value conflicts with an authoritative source, the authoritative source wins.
- No deliberate Phase 2 business-story anomalies are seeded during Phase 1.

---

## Architecture scope at a glance

The current Sales & Commercial architecture includes:

- **4 current customer accounts**, extending the four customer organizations already seeded in Shared Enterprise;
- **9 linked Shared Enterprise market/region records** used for commercial geography;
- **2 current Sales channels**;
- **3 customer segments**;
- **2 current commercial territories**;
- **24 active retail SKUs** referenced from Production;
- **7 assortment groups** and **4 customer assortment profiles**;
- **73 active Customer + SKU listings**;
- **73 customer product-code cross-references**;
- **4 current price lists** and **96 current price-list lines**;
- **73 Customer + SKU pricing relationships**;
- **4 reusable commercial-term profiles** with current customer assignments;
- **4 current active primary customer agreements**;
- **8 demand-planning profiles** covering all current customers, SKUs and listings;
- static demand-planning rules for all **73 active Customer + SKU listings**;
- static sales-order rules for all **73 active Customer + SKU listings**;
- **37 Sales & Commercial processes** and **214 reusable static process steps**;
- **35 consolidated commercial controls** and **11 segregation-of-duties controls**;
- a complete derived Sales & Commercial reference layer for AI navigation and cross-domain joining.

These values describe the current static synthetic architecture, not historical commercial activity.

---

## Files in this folder

### `hav_seafood_sales_customer_account_commercial_organization_v1.xlsx`

Defines the authoritative Sales customer-account and commercial-organization architecture.

Contains:

- `CUS-001` to `CUS-004` customer identities;
- links to Shared Enterprise external organizations;
- customer account classifications;
- customer hierarchy posture;
- Sales-specific commercial roles;
- commercial-site and functional-contact references;
- account ownership types;
- position-seat-based customer ownership;
- ERP/CRM customer mappings;
- source mappings, architecture notes and data dictionary.

The core identity distinction is:

`Shared External Organization -> Sales Customer_ID`

Shared Enterprise remains authoritative for the real-world organization identity. Sales owns the customer-domain commercial extension.

The four current customers are:

- `CUS-001` — Nordmark Food Distribution AB, Sweden;
- `CUS-002` — Fjord & Field Retail AS, Norway;
- `CUS-003` — Baltic Pantry UAB, Lithuania;
- `CUS-004` — Northline Grocers Oy, Finland.

The workbook does **not** contain sales orders, invoices, pricing, credit limits, sales history, forecasts or CRM interaction history.

---

### `hav_seafood_sales_markets_channels_commercial_territory_v1.xlsx`

Defines how commercial geography, routes to market, customer segmentation and internal Sales responsibility are structured.

Contains:

- linked Shared Enterprise market/region references;
- market-country mappings;
- **2 Sales channels**;
- **3 customer segments**;
- market-channel applicability;
- **2 commercial territories**;
- territory scope;
- current customer commercial assignments;
- position-seat-based territory ownership;
- Sales classifications;
- system mappings and data dictionary.

The principal distinctions are:

- **Market** = commercial geography;
- **Channel** = route to the commercial customer;
- **Customer Segment** = classification of the customer relationship;
- **Territory** = HAV Seafood's internal commercial responsibility structure.

Shared Enterprise remains authoritative for `Market_ID`. Sales owns Sales Channel, Customer Segment and Commercial Territory.

Current channels are:

- `SCHA-001` — Direct Grocery Retail;
- `SCHA-002` — Distributor / Importer.

Current territories are:

- `CTER-001` — Nordic Key Accounts;
- `CTER-002` — Baltic & Export Accounts.

No sales-volume, market-share, territory-history or sales-performance data is included.

---

### `hav_seafood_sales_customer_assortment_product_listing_v1.xlsx`

Defines which products HAV Seafood can commercially offer in each market/channel and which SKUs are currently listed by each customer.

Contains:

- linked commercial reference for all **24 active finished-goods SKUs**;
- **96 Market + SKU availability relationships**;
- **48 Channel + SKU applicability relationships**;
- **7 assortment groups**;
- **4 current customer assortment profiles**;
- **73 active Customer + SKU listings**;
- **73 customer product-code cross-references**;
- reusable listing-requirement definitions;
- **365 static listing-requirement assignments**;
- system mappings, source precedence, architecture notes and data dictionary.

The key distinction is:

`SKU existence != Market availability != Customer listing`

Production remains authoritative for the SKU and its technical definition. Sales owns the commercial availability, assortment and customer-listing relationships.

No listing history, actual orders, sales volumes, listing approvals or customer-range review events are included.

---

### `hav_seafood_sales_pricing_commercial_terms_framework_v1.xlsx`

Defines the current Sales pricing architecture and reusable commercial-term structures.

Contains:

- linked reference to all **24 active sellable SKUs**;
- **4 current market/channel price lists**;
- **96 current price-list lines**;
- **4 reusable customer pricing profiles**;
- current pricing-profile assignments for all four customers;
- **73 Customer + SKU pricing relationships** matching the active customer listings;
- **4 standard discount profiles**;
- **2 volume-pricing profiles** and **7 quantity tiers**;
- **3 rebate profiles** and **6 active rebate tiers**;
- allowance types;
- freight-commercial term profiles;
- minimum-order rules;
- surcharge types;
- **4 reusable commercial-term profiles**;
- current customer commercial-term assignments;
- conceptual pricing-authority classes;
- system mappings, source precedence and data dictionary.

The pricing hierarchy is conceptually:

`SKU + Market / Channel -> Price List -> Customer Pricing Profile -> Customer/SKU Price`

Current synthetic prices are legitimate Phase 1 master data. Historical price changes, negotiated price events, transaction prices, discount events, rebate accruals and settlements are not included.

Finance remains the future authority for payment terms, credit, tax, accounting and financial settlement.

---

### `hav_seafood_sales_customer_agreements_framework_v1.xlsx`

Defines the current customer-agreement structure and contractual commercial scope.

Contains:

- **9 agreement types**;
- **4 reusable current agreement profiles**;
- **4 current active primary customer agreements**;
- customer, market, channel and product-scope relationships;
- commercial-term assignments;
- **6 commitment types** and **14 static agreement commitments**;
- **5 exclusivity types**, with all current agreements explicitly non-exclusive;
- **5 service-commitment types** and **16 current service-term relationships**;
- **6 document-requirement types** and **21 current requirement relationships**;
- review and renewal rules;
- notice-term structures;
- agreement governance and authority classes;
- CRM/Microsoft 365/ERP mappings;
- source precedence and data dictionary.

The principal relationship is:

`Customer -> Agreement -> Scope -> Commercial Term Profile -> Commitments / Service Terms / Governance`

The Pricing workbook remains authoritative for pricing mechanics. This workbook determines which commercial structures are contractually applicable.

No negotiation emails, redlines, signatures, amendments, renewal events, disputes, breaches or historical agreements are included.

---

### `hav_seafood_sales_demand_planning_framework_v1.xlsx`

Defines how HAV Seafood's commercial demand-planning process is structurally designed.

Contains:

- demand types;
- **8 reusable demand-planning profiles**;
- forecast methods;
- horizons and time buckets;
- forecast granularity structures;
- planning hierarchy;
- customer demand-planning assignments;
- SKU demand-planning assignments;
- static planning rules covering all **73 active Customer + SKU listings**;
- seasonality and lifecycle treatment;
- new-product planning rules;
- promotion-demand rules;
- customer-forecast-input rules;
- forecast version/status models;
- override rules;
- review framework;
- position-based planning ownership;
- forecast-quality metric definitions;
- planning-exception types;
- explicit interfaces to Production and Procurement/Supply Planning;
- system mappings, source precedence and data dictionary.

The key distinction is:

`Demand Planning Architecture != Forecast != Sales Order != Production Plan`

This workbook intentionally contains **no forecast quantities**.

Sales owns the commercial demand signal and demand-planning rules. Production and Procurement/Supply Chain remain authoritative for downstream production and material planning structures.

---

### `hav_seafood_sales_order_customer_service_framework_v1.xlsx`

Defines how customer orders are expected to be accepted, validated and governed, and how Customer Service should classify and route commercial requests.

Contains:

- **6 sales-order types**;
- **4 order-entry channels**;
- **3 reusable customer order profiles**;
- current order-profile assignments for all four customers;
- static order rules covering all **73 active Customer + SKU listings**;
- order cutoff rules;
- **5 commercial lead-time classes**;
- requested-versus-promised-date rules;
- **17 order-validation rules**;
- **9 order-hold types**;
- **10 order lifecycle statuses** and permitted transitions;
- amendment and cancellation rules;
- substitution and backorder profiles;
- allocation-priority classes;
- **3 customer-service profiles**;
- **14 customer-service request types**;
- request-routing rules;
- **5 response-service classes**;
- communication/document requirement structures;
- order exception and escalation structures;
- Production, Logistics and Finance interface definitions;
- ERP/CRM/QMS mappings;
- source precedence and data dictionary.

The architecture separates:

`Forecast -> Customer Order -> Fulfilment / Shipment -> Invoice`

These are different business objects and are not collapsed into one structure.

Detailed ship-to infrastructure, Finance credit/payment structures and outbound Logistics execution remain deliberately outside this workbook.

No actual orders, service cases, amendments, backorders, shipment events, complaints, emails or response-time history are included.

---

### `hav_seafood_sales_process_authority_commercial_control_v1.xlsx`

Defines Sales processes, commercial authority requirements, controls, segregation of duties and exception/escalation structures.

Contains:

- **37 Sales & Commercial processes** across 9 process categories;
- **214 reusable static process steps**;
- **7 Sales authority classes** mapped to the existing HR authority backbone;
- **12 position-to-Sales-authority mappings**;
- process authority rules;
- **10 commercial threshold types** and **17 threshold/authority rules**;
- domain-specific customer, listing, pricing, agreement, planning, order and service controls;
- **35 consolidated commercial controls**;
- **11 segregation-of-duties controls**;
- **11 commercial exception types**;
- **5 escalation classes**;
- exception and escalation rules;
- approval-evidence requirements;
- cross-functional review requirements;
- delegation rules;
- process output objects;
- system/process mappings;
- source precedence and data dictionary.

The core principle is:

`Responsibility -> Authority -> Approval Event`

Sales defines the commercial process and required Sales authority class. HR remains authoritative for positions and the enterprise authority backbone. Actual approver identity is resolved from position incumbency at transaction time.

Company-wide monetary approval limits are deliberately deferred to Finance.

No actual approvals, workflow histories, control executions, exceptions, escalations or audit findings are included.

---

### `hav_seafood_sales_commercial_reference_tables_v1.xlsx`

Provides the **derived, AI-friendly navigation and joining layer** across the complete Sales & Commercial architecture.

Contains compact reference views for:

- customers;
- overall customer commercial setup;
- markets, channels and territories;
- commercial SKU references;
- the full **73-row Customer + SKU commercial reference** joining assortment, pricing, agreement, demand-planning and order-rule structures;
- customer assortment summaries;
- pricing relationships;
- customer/SKU pricing;
- agreements and agreement scope;
- demand-planning rules;
- order and customer-service structures;
- customer/SKU order rules;
- Sales processes and controls;
- position/responsibility mappings;
- systems and data ownership;
- cross-domain bridges;
- entity ownership and source precedence;
- relationship catalog;
- architecture source catalog;
- architecture notes;
- data dictionary.

This workbook is **derived and non-authoritative**.

If it conflicts with an authoritative Sales, Shared Enterprise, Production, HR, Procurement/Supply Chain or later-domain source, the authoritative source wins.

This workbook should normally be the **first Excel workbook inspected when fast AI context or cross-Sales navigation is needed**.

---

## Companion Markdown files

Each Sales & Commercial workbook has a matching `.md` file containing a compact description of:

- purpose;
- principal entities and relationships;
- workbook contents;
- important current architecture counts;
- ownership boundaries;
- important assumptions;
- source precedence;
- relationships to other architectures;
- explicit Phase 1 exclusions;
- recommended AI use.

These companion Markdown files are intended to give AI systems and human users quick context without requiring every workbook to be opened first.

---

## How the Sales & Commercial architecture fits together

At a high level, the architecture follows this chain:

`Shared Enterprise External Organization`

`-> Sales Customer Account`

`-> Market + Channel + Segment + Commercial Territory`

`-> Customer Assortment + Customer/SKU Listing`

`-> Price List + Customer Pricing + Commercial Terms`

`-> Customer Agreement + Scope + Commitments`

`-> Demand Planning Rules`

`-> Sales Order + Customer Service Rules`

`-> Sales Process + Authority + Controls`

`-> Sales & Commercial Reference Tables`

A product-centric view is:

`Production SKU`

`-> Market Availability`

`-> Channel Applicability`

`-> Customer Listing`

`-> Customer Product Code`

`-> Customer Price`

`-> Agreement Scope`

`-> Demand Planning Rule`

`-> Order Rule`

A customer-centric view is:

`External Organization`

`-> Customer Account`

`-> Commercial Assignment`

`-> Assortment`

`-> Pricing / Commercial Terms`

`-> Agreement`

`-> Demand Planning Profile`

`-> Order Profile / Customer Service Profile`

`-> Process / Authority / Control Framework`

---

## Relationship with Shared Enterprise Architecture

Shared Enterprise remains the enterprise backbone around Sales & Commercial.

Sales reuses Shared Enterprise identifiers and structures including:

- company identity;
- departments and organizational units;
- external organizations;
- external address/contact identity;
- countries;
- currencies;
- languages;
- markets/regions;
- enterprise locations where relevant;
- employees and enterprise job roles as shared identities;
- enterprise systems;
- identifier conventions;
- shared reference data;
- entity-ownership rules;
- system/data ownership rules.

Important ownership distinctions include:

- **Shared Enterprise** — external organization identity, market identity, shared classifications, enterprise systems and cross-domain standards.
- **Sales & Commercial** — Customer_ID, Sales channels, customer segments, commercial territories, customer listings, commercial pricing, customer agreements, demand-planning rules, order/customer-service rules and Sales controls.
- **HR** — employee/role/position identity, incumbency and enterprise authority structures.
- **Production** — finished-goods/SKU technical identity and production-specific structures.

The Shared Enterprise Systems Landscape and System/Data Ownership Model remain authoritative for enterprise system identity and enterprise-level system-of-record decisions.

---

## Relationship with Production Architecture

Production remains authoritative for the finished-product master and technical product/factory structures.

Production continues to own areas including:

- SKU identity and technical product definition;
- product families and variants;
- recipes and BOMs;
- packaging technical requirements;
- shelf-life and storage requirements;
- production routings;
- production capacity;
- production staffing;
- production quality and food-safety controls;
- finished-goods production execution.

Sales uses these structures commercially without copying or redefining them.

Examples include:

- `Production SKU -> Market Availability`;
- `Production SKU -> Customer Listing`;
- `Customer/SKU Forecast Rule -> Future Finished-Goods Demand`;
- `Confirmed Customer Order -> Future Production/Fulfilment Demand`.

Sales may state commercial requirements and customer commitments. Production remains authoritative for how those requirements are technically produced and executed.

---

## Relationship with HR & Organization Architecture

HR and Shared Enterprise remain authoritative for people, roles, positions, position seats and authority structures.

Sales uses existing structures such as:

- Sales Manager;
- Key Account Managers;
- Customer Service & Order Coordination;
- Sales Administration;
- Commercial Analyst;
- Managing Director;
- specialist Finance, Quality, Production and Procurement positions where cross-functional review is required.

Customer and territory ownership is attached primarily to approved HR position seats rather than directly to named employees.

The Sales Process, Authority & Commercial Control workbook maps Sales authority classes to the existing HR authority backbone rather than creating an independent commercial hierarchy.

No employee-specific sales activity is stored in this folder.

---

## Relationship with Procurement & Supply Chain Architecture

Procurement & Supply Chain and Sales meet primarily through planning and availability.

Sales owns the commercial demand signal and customer requirements.

Procurement & Supply Chain remain authoritative for:

- purchased-material sourcing;
- supply-planning policy;
- purchased inventory-control policy;
- supplier relationships;
- inbound logistics and receiving.

The planning chain is conceptually:

`Customer / SKU Demand Signal`

`-> Finished-Goods Demand`

`-> Production Requirements`

`-> BOM / Material Requirements`

`-> Purchased Material Supply Planning`

Sales Demand Planning therefore feeds downstream supply planning without redefining Procurement's material-planning rules.

---

## Finance boundary

Sales contains commercial values and rules, but it does **not** replace the future Finance architecture.

Sales currently owns or defines:

- current list prices;
- current customer commercial pricing structures;
- discounts and rebate eligibility structures;
- commercial allowances;
- freight commercial terms;
- minimum-order commercial rules;
- customer agreements and commercial commitments;
- percentage/commercial deviation authority where Sales owns the decision.

Finance is expected to own or finalize:

- customer credit limits;
- credit status and credit approval;
- payment-term masters;
- customer invoicing;
- accounts receivable;
- tax determination;
- revenue recognition;
- currency accounting;
- rebate accrual and settlement accounting;
- discount accounting;
- profitability and financial reporting;
- company-wide monetary approval thresholds.

Sales workbooks use explicit future Finance references rather than silently inventing these structures.

---

## Logistics boundary

Sales defines what has been commercially ordered and promised.

Future Logistics should own how finished goods are physically dispatched and delivered.

Sales currently defines or references:

- customer order structure;
- customer delivery-location requirements where known;
- requested/promised-date rules;
- freight commercial terms;
- commercial service levels;
- partial fulfilment/backorder rules;
- commercial allocation priority.

Future Logistics should own:

- outbound shipments;
- carriers;
- routes;
- transport bookings;
- dispatch;
- tracking;
- actual delivery;
- freight execution;
- delivery performance.

A sales order should not be treated as a shipment.

---

## Quality boundary

Sales may receive or record customer technical requirements and may receive customer complaints, but it does not own technical quality investigation.

Quality remains or is expected to become authoritative for:

- technical product/quality requirements;
- product and label compliance;
- customer-specific technical approval;
- technical complaint investigation;
- quality release;
- certificates and quality evidence;
- corrective-action processes technically owned by Quality.

The Customer Service framework routes product-quality complaints to Quality rather than duplicating a second complaint architecture inside Sales.

---

## Marketing boundary

Sales owns trade/commercial customer structures, not consumer marketing.

Marketing should later own areas such as:

- brand architecture;
- consumer segmentation;
- campaigns;
- media;
- consumer research;
- brand communications;
- consumer-facing product positioning.

Sales may reference promotions or customer-specific commercial support where they affect pricing, agreements or demand planning, but should not redefine Marketing-owned campaign architecture.

---

## Authoritative versus derived files

The following Sales & Commercial workbooks are authoritative for their Sales subject areas:

- `hav_seafood_sales_customer_account_commercial_organization_v1.xlsx`
- `hav_seafood_sales_markets_channels_commercial_territory_v1.xlsx`
- `hav_seafood_sales_customer_assortment_product_listing_v1.xlsx`
- `hav_seafood_sales_pricing_commercial_terms_framework_v1.xlsx`
- `hav_seafood_sales_customer_agreements_framework_v1.xlsx`
- `hav_seafood_sales_demand_planning_framework_v1.xlsx`
- `hav_seafood_sales_order_customer_service_framework_v1.xlsx`
- `hav_seafood_sales_process_authority_commercial_control_v1.xlsx`

The following workbook is deliberately **derived**:

- `hav_seafood_sales_commercial_reference_tables_v1.xlsx`

The derived reference workbook exists to simplify navigation, joining, AI context and later dataset generation. It should be refreshed whenever an authoritative Sales workbook materially changes and must never overrule an authoritative source.

Where a concept originates outside Sales, the upstream authoritative domain still wins. Examples include Market_ID from Shared Enterprise, SKU_ID from Production and Position_ID / Position_Seat_ID from HR.

---

## Current-state versus history

Most Sales architecture is intentionally modeled as **current state**.

Examples include:

- current customer relationship;
- current customer market/channel/territory assignment;
- current customer assortment;
- current Customer + SKU listing;
- current list price and customer pricing profile;
- current customer agreement;
- current demand-planning profile;
- current order/customer-service profile;
- current process and authority structure.

The architecture does not attempt to model every historical commercial change through effective-dated records.

Later Phase 3 datasets can generate histories against these stable structures, including customer onboarding, listing changes, price changes, agreement amendments, forecast revisions, order changes, service cases, approval activity and other commercial history.

---

## Commercial and legal boundary

The Sales & Commercial architecture is designed to be realistic enough for a synthetic business dataset but is **not a statement of Faroese, Nordic or international commercial law**.

Unless explicitly stated otherwise, values and rules such as the following are synthetic internal HAV Seafood assumptions:

- list prices;
- discount percentages;
- rebate structures;
- minimum-order thresholds;
- commercial lead times;
- order cutoffs;
- customer agreement notice periods;
- review frequencies;
- service targets;
- Sales approval thresholds;
- commercial exception classes.

Incoterm-like or contractual concepts should be treated as synthetic company architecture unless later researched and deliberately aligned with real legal/commercial standards.

---

## Architecture boundaries — operational data intentionally excluded

This folder does **not** contain historical or transactional records such as:

- sales leads or opportunities;
- CRM activity;
- customer calls or visits;
- customer emails;
- quotations;
- negotiation history;
- price-change history;
- promotion events;
- actual discounts;
- rebate accruals or settlements;
- allowance claims;
- customer agreement amendments;
- agreement redlines or signatures;
- renewal events;
- contractual disputes or breaches;
- customer forecasts;
- forecast versions;
- forecast overrides;
- forecast accuracy results;
- demand-review meeting history;
- sales orders;
- sales-order lines;
- order amendments;
- order confirmations;
- cancellations;
- actual order holds;
- backorders;
- allocation events;
- actual requested/promised dates;
- customer-service cases;
- customer-service communications;
- response-time history;
- shipments;
- dispatches;
- deliveries;
- freight tracking;
- returns;
- customer invoices;
- credit notes;
- accounts-receivable activity;
- customer credit events;
- actual approval requests or decisions;
- workflow/audit logs;
- control executions;
- control failures;
- actual commercial exceptions;
- escalation cases;
- sales revenue and margin history;
- customer profitability;
- sales targets, quotas or commissions.

Those belong to Phase 3 after the Phase 2 business stories and patterns have been deliberately designed.

---

## Story neutrality

The Sales & Commercial architecture is intentionally designed to support future business stories without selecting them yet.

It does not deliberately seed outcomes such as:

- customer concentration problems;
- customer churn;
- delistings;
- unusual assortment gaps;
- pricing errors;
- excessive discounting;
- rebate leakage;
- conflicting agreements;
- missed volume commitments;
- forecast bias;
- missing forecasts;
- order-entry errors;
- chronic backorders;
- allocation conflicts;
- repeated late amendments;
- customer-service failures;
- unresolved complaints;
- approval bypasses;
- segregation-of-duties failures;
- suspicious commercial exceptions;
- declining sales or profitability.

Those patterns should be selected in **Phase 2 — Stories** and introduced deliberately when operational data is generated.

---

## Identifier conventions

Existing Shared Enterprise, Production and HR identifiers are preserved.

Examples include:

- `ORG-EXT-*` — external organizations;
- `MKT-*` / shared market identifiers — Shared Enterprise commercial geography;
- existing Production SKU identifiers — finished goods;
- `R*` — enterprise job roles;
- `POS-*` / `PSEAT-*` — HR positions and approved position seats;
- `ESYS-*` — enterprise systems.

Sales introduces domain-local identifiers for structures such as:

- `CUS-*` — Customer_ID;
- `SCHA-*` — Sales Channel;
- customer segments;
- commercial territories;
- customer-SKU listings;
- assortment groups/profiles;
- pricing structures;
- commercial-term profiles;
- customer agreements;
- demand-planning profiles;
- order/customer-service structures;
- Sales processes, authority classes, controls and exceptions.

Where a Sales-local prefix is not yet registered in the Shared Enterprise identifier standards, it should be registered if the enterprise standards workbook is refreshed.

---

## Recommended use of the folder

For fast context, inspect files in this order:

1. `README_sales_commercial_architecture.md` — overall Sales & Commercial architecture, ownership boundaries and file map.
2. `hav_seafood_sales_commercial_reference_tables_v1.xlsx` — compact cross-Sales joining and navigation layer.
3. The matching authoritative Sales workbook for the subject being analyzed.
4. Shared Enterprise, Production, HR, Procurement/Supply Chain or later Finance/Logistics/Quality source workbooks whenever the relationship crosses a domain boundary.

For AI workflows, the README plus the Sales & Commercial Reference Tables workbook should normally provide enough context to identify which detailed authoritative source must be inspected next.

### AI navigation shortcuts

- Customer identity / ownership -> `Customer_Reference` in the Sales reference workbook, then Customer Account architecture.
- Market / channel / territory -> `Market_Channel_Territory`, then Markets, Channels & Commercial Territory.
- Customer + product question -> `Customer_SKU_Reference`, then Customer Assortment & Product Listing.
- Pricing question -> `Customer_SKU_Pricing` / `Pricing_Reference`, then Pricing & Commercial Terms.
- Agreement question -> `Agreement_Reference`, then Customer Agreements.
- Forecast/planning architecture -> `Demand_Planning_Reference`, then Sales & Demand Planning.
- Order/customer-service rules -> `Order_Service_Reference` / `Customer_SKU_Order_Rules`, then Sales Order & Customer Service.
- Authority/control question -> `Sales_Process_Reference` / `Commercial_Control_Reference`, then Sales Process, Authority & Commercial Control.
- System/data ownership question -> `System_Data_Reference` / `Entity_Ownership_Source`, then the relevant authoritative system/ownership workbook.

---

## Use in later phases

### Phase 2 — Stories

The architecture provides the stable structures required to design cross-functional stories involving areas such as:

- customer concentration and account development;
- product assortment and delisting;
- customer-specific product requirements;
- pricing and discount behavior;
- rebates and commercial support;
- agreement commitments;
- exclusivity;
- forecast accuracy and bias;
- customer forecast collaboration;
- demand versus capacity;
- demand versus material availability;
- order-entry errors;
- pricing/order discrepancies;
- backorders and allocation;
- customer-service performance;
- customer complaints;
- commercial approvals and exceptions;
- cross-functional Finance, Production, Procurement, Quality and Logistics consequences.

Stories should reference existing IDs, profiles, listings, agreements, rules and controls rather than changing the architecture merely to make a pattern possible.

### Phase 3 — Operational dataset generation

Operational Sales & Commercial datasets should:

1. reuse the customer, market, channel, segment, territory, SKU, listing, pricing, agreement, planning, order, service, process and control identifiers defined or referenced here;
2. preserve Shared Enterprise, Production, HR and Procurement/Supply Chain identifiers;
3. generate events according to the static rules and profiles in the authoritative workbooks;
4. use the established systems-of-record and ownership boundaries;
5. generate realistic ordinary activity and noise around deliberately selected Phase 2 stories;
6. avoid redefining master data inside transactional datasets;
7. create cross-functional records that join consistently with Production, Procurement, Finance, Logistics, Quality, Marketing, HR, IT and Management datasets.

The eventual operational Sales dataset can include realistic combinations of ERP exports, CRM data, Excel forecasts, customer purchase-order files, emails, quotations, agreements, order confirmations, service cases and other business formats while remaining anchored to the architecture defined here.

---

## Overall role of this architecture

Together, these files form the **static Sales & Commercial master-data, policy, relationship, planning and control layer** for HAV Seafood.

They connect Shared Enterprise customer identity and market structures to customer ownership, commercial segmentation, products, assortments, pricing, agreements, demand planning, orders, customer service and commercial governance while preserving the ownership of Production, HR, Procurement/Supply Chain and future Finance, Logistics, Quality and Marketing architectures.

This provides a consistent structural foundation for later synthetic sales, forecasting, CRM, order, service, delivery and financial data so that operational events behave like parts of one coherent company rather than independent synthetic tables.
