# Customer Assortment & Product Listing Architecture

## Purpose

This workbook defines the static **Customer Assortment & Product Listing Architecture** for **HAV Seafood**.

It belongs to **Phase 1 — Business Architecture** of the synthetic business dataset project:

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

The architecture answers:

> **Which existing HAV Seafood SKUs are commercially available in which markets and channels, which SKUs are currently listed by each seeded customer, and what static customer-item and listing requirements apply?**

It does **not** contain sales orders, sales quantities, prices, promotions, listing-event history, customer negotiations or other operational activity.

The authoritative workbook is:

`hav_seafood_sales_customer_assortment_product_listing_v1.xlsx`

This Markdown file is a compact AI/human reference. If it conflicts with the workbook or an authoritative upstream source, the authoritative source wins.

---

## Architecture scope at a glance

The workbook currently contains:

- **24 active sellable retail SKUs** referenced from Production;
- **4 current seeded customer markets**;
- **2 current Sales channels**;
- **7 commercial assortment groups**;
- **4 current assortment profiles**;
- **73 active Customer + SKU listings**;
- **73 synthetic customer item-number cross-references**;
- **6 reusable listing-requirement definitions**;
- **365 static customer-listing requirement assignments**;
- **96 Market + SKU availability relationships**;
- **48 Channel + SKU applicability relationships**.

Current listing counts are:

- `CUS-001` Nordmark Food Distribution — **20 SKUs**;
- `CUS-002` Fjord & Field Retail — **17 SKUs**;
- `CUS-003` Baltic Pantry — **18 SKUs**;
- `CUS-004` Northline Grocers — **18 SKUs**.

These differences are ordinary static assortment design. They are **not deliberate Phase 2 anomalies**.

---

## Core model

The core structure is:

`Production SKU`

`+ Customer Account`

`+ Market`

`+ Sales Channel`

`-> Customer SKU Listing`

The architecture deliberately keeps separate:

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

A SKU may therefore exist and be commercially available without being part of a particular customer's current assortment.

---

## Authoritative ownership model

### Production / Shared Enterprise

Production remains authoritative for:

- `SKU_ID`;
- product family and variant identity;
- SKU name and pack format;
- shelf life and storage class;
- GTIN placeholder values;
- packaging-material identity and SKU packaging relationships;
- recipes/BOMs and technical product structure.

Core ERP `ESYS-001` remains system of record for sellable `SKU_ID` according to the existing enterprise system/data ownership architecture.

### Customer Account architecture

`hav_seafood_sales_customer_account_commercial_organization_v1.xlsx` remains authoritative for:

- `Customer_ID`;
- customer account name;
- customer language;
- shared customer/master-account attributes.

### Markets, Channels & Commercial Territory architecture

`hav_seafood_sales_markets_channels_commercial_territory_v1.xlsx` remains authoritative for current:

- customer market assignment;
- Sales channel;
- customer segment;
- commercial territory.

### This workbook — Sales & Commercial

This workbook owns:

- commercial Market + SKU availability extensions;
- Channel + SKU applicability;
- commercial assortment groups;
- customer assortment profiles;
- customer-to-assortment profile assignments;
- current Customer + SKU listing relationships;
- listing status/classification;
- customer product-code cross-reference structure;
- commercial listing requirements.

Sales CRM `ESYS-006` is selected as the operational master for commercial availability, assortment profiles and commercial listing status/scope.

Core ERP `ESYS-001` is selected as the operational master for the customer item-number cross-reference used in order processing, while CRM consumes that code.

---

## Workbook sheets

### `SKU_Commercial_Reference`

Linked Sales-facing view of all 24 active Production SKUs.

Includes product hierarchy, pack format, case/pallet references, storage class, shelf life, GTIN placeholder and relevant packaging IDs.

This sheet is **not** a competing SKU master.

### `Market_SKU_Availability`

Defines static commercial availability of each active SKU in each of the four current seeded customer markets.

All 24 active SKUs are structurally available in each current market. `Standard_Offering_Flag` distinguishes the current normal seeded assortment from selectively available products.

This supports future architecture expansion without treating today's customer range as a permanent market restriction.

### `Channel_SKU_Applicability`

Defines SKU applicability across the two current Sales channels:

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

Both channels may structurally carry all active SKUs. Standard/core/extended treatment describes the current static range design rather than historical sales behavior.

### `Assortment_Groups`

Defines seven reusable commercial groups:

- Cold-Smoked Salmon Range;
- Chilled Salmon Portions Range;
- Pickled Herring Range;
- Ambient Mackerel Range;
- Frozen Cod Range;
- Chilled Shrimp Salad Range;
- Ambient Cod Roe Range.

These are Sales commercial groupings around existing Production products.

### `Assortment_Group_SKUs`

Maps every active SKU to its primary commercial assortment group.

### `Customer_Assortment_Profiles`

Defines four current reusable assortment profiles:

- Nordic Distributor Broad Range;
- Direct Grocery Core Range;
- Baltic Export Balanced Range;
- Direct Grocery Extended Range.

Profiles are designed around the current market/channel/customer-segment structures already established in the Sales architecture.

### `Profile_Assortment_Groups`

Defines which assortment groups are core or selective within each profile.

Individual Customer + SKU listing rows remain authoritative for the precise current assortment.

### `Customer_Assortment_Assignment`

Assigns one current primary assortment profile to each of the four seeded customers and carries their existing market/channel/segment/territory references.

### `Customer_SKU_Listings`

The central authoritative Sales table in this workbook.

Each row represents one current:

`Customer_ID + SKU_ID`

relationship and includes:

- market/channel/profile/group context;
- current listing status;
- core/extended classification;
- orderability flag;
- minimal case-order UOM/MOQ/multiple defaults;
- commercial priority.

Later Phase 3 sales orders should normally only use active Customer + SKU combinations present here unless a deliberately designed story introduces an exception.

### `Customer_Product_Codes`

Defines one synthetic customer-specific item/article number for every current listing.

These codes do **not** replace `SKU_ID`.

They model the realistic customer-item cross-reference required in retailer/distributor relationships. They are wholly synthetic and do not represent real companies' coding schemes.

### `Listing_Requirements`

Defines six reusable commercial listing requirements covering:

- destination-market language labeling;
- customer item-number cross-reference;
- GTIN reference;
- EDI item setup;
- standard pallet reference;
- export outer-case identification.

Sales records that a requirement exists. Technical implementation/evidence stays with Quality, IT, Logistics, Production or other appropriate domains.

### `Customer_Listing_Requirements`

Maps each active listing to five applicable static requirements.

Direct grocery listings use the EDI requirement; distributor/importer listings use the export case-identification requirement.

This sheet contains **requirements**, not completed checks, approvals, exceptions or incidents.

### `Listing_Classifications`

Controlled Sales code list for availability, commercial priority, assortment/profile types, listing status/type/class, customer product-code types and requirement types.

### `System_Mappings`

Documents system roles for:

- SKU master;
- Customer master;
- market-SKU availability;
- assortment profiles;
- Customer SKU Listing;
- customer product-code cross-reference.

### `Relationship_Reference`

Derived AI-friendly joined view of all 73 current listings.

It connects each listing to customer, market, channel, segment, territory, assortment profile/group, SKU/product hierarchy, customer product code, ordering defaults, storage/shelf-life references and packaging references.

This is a navigation layer, not a separate master.

### `Source_Mappings`

Documents upstream authoritative sources and conflict precedence.

### `Architecture_Notes`

Defines scope, ownership, system boundaries, current-state interpretation, exclusions and story-neutrality rules.

### `Data_Dictionary`

Field-level definition of the workbook.

---

## Important architecture boundaries

### Pricing

No:

- prices;
- price lists;
- discounts;
- rebates;
- promotional allowances;
- invoice prices.

These belong to the future **Pricing & Commercial Terms** architecture and Phase 3 transactions.

### Customer agreements

No:

- signed agreements;
- exclusivity;
- listing fees;
- negotiated commitments;
- contract history.

These belong to the future **Customer Agreements & Commercial Terms** architecture.

### Sales activity

No:

- quotations;
- orders;
- deliveries;
- invoices;
- sales volumes;
- CRM calls or meetings;
- range-review history;
- listing approvals/delistings;
- actual promotions.

These belong to Phase 3.

### Quality and labeling

This workbook may state that a customer listing requires destination-language labeling, a GTIN reference or another commercial requirement.

It does not own:

- approved artwork;
- regulatory label content;
- technical label specifications;
- quality evidence;
- compliance decisions.

### Logistics

This workbook links existing standard pallet/package references where useful for commercial setup.

It does not own:

- physical palletization execution;
- shipment planning;
- transport;
- dispatch;
- delivery history.

---

## Current state versus history

The workbook models current static state.

Examples:

- current customer assortment profile = architecture;
- current Customer + SKU listing = architecture;
- current customer item number = architecture;
- listing activation/delisting event = Phase 3 history;
- customer item-number change history = Phase 3 history;
- range-review meeting = Phase 3 operational data.

No effective-dated listing history is stored here.

---

## Story neutrality

No deliberate story pattern is seeded in this architecture.

The workbook does **not** intentionally imply:

- failed listings;
- inappropriate market products;
- delisting risk;
- weak customer demand;
- customer dissatisfaction;
- impossible packaging requirements;
- SKU setup errors;
- EDI failures;
- regulatory problems;
- abnormal assortment gaps.

Range differences are normal commercial design choices.

Any later business story involving these topics should be selected explicitly during **Phase 2 — Stories** and introduced through operational data in Phase 3.

---

## Identifier conventions

Existing identifiers are preserved, including:

- Production `SKU_ID` values;
- Sales `CUS-*` customer IDs;
- Shared `MKT-*` market IDs;
- Sales `SCHA-*` channel IDs;
- Sales `CSEG-*` segment IDs;
- Sales `CTER-*` territory IDs;
- Production packaging IDs.

This workbook introduces local Sales prefixes including:

- `MSKU-*` — Market/SKU availability;
- `CSKU-*` — Channel/SKU applicability;
- `ASG-*` — assortment groups;
- `AGSKU-*` — assortment group/SKU mappings;
- `ASP-*` — customer assortment profiles;
- `PAG-*` — profile/group relationships;
- `CAA-*` — customer assortment assignments;
- `CSL-*` — customer/SKU listings;
- `CPC-*` — customer product-code records;
- `LREQ-*` — listing requirements;
- `CLR-*` — listing requirement assignments.

These should be registered in Shared Enterprise identifier standards if that architecture is refreshed.

---

## Recommended AI usage

For rapid context:

1. Read this Markdown file.
2. Inspect `Relationship_Reference` to see all current customer/SKU relationships in one place.
3. Inspect `Customer_SKU_Listings` when determining whether a seeded customer currently lists a SKU.
4. Inspect `SKU_Commercial_Reference` only for convenient product context; use Production as authoritative for technical SKU facts.
5. Inspect `Customer_Product_Codes` for customer-item cross-references.
6. Inspect `Customer_Listing_Requirements` when a future workflow depends on customer-specific commercial setup.
7. Consult the Customer Account and Markets/Channels/Territory workbooks for upstream customer/commercial dimensions.

If a linked value conflicts with an authoritative upstream source, **the upstream authoritative source wins**.

---

## Use in later phases

### Phase 2 — Stories

This architecture can later support stories involving:

- customer assortment changes;
- listing/delisting effects;
- SKU setup errors;
- customer item-code mismatches;
- EDI item-master problems;
- packaging/label requirement issues;
- product availability by market;
- differences between customer assortments;
- launch execution;
- downstream effects on forecasting, sales, production, logistics and finance.

The stories should use the existing IDs and structures rather than changing Phase 1 merely to create a problem.

### Phase 3 — Operational dataset generation

Operational Sales datasets should:

1. reuse `Customer_ID`, `SKU_ID`, market/channel/territory and listing IDs from the architecture;
2. validate normal orderable Customer + SKU combinations against `Customer_SKU_Listings`;
3. use customer product codes where realistic in order/EDI/customer communications;
4. preserve Production as the technical SKU source;
5. preserve Sales CRM versus ERP system-of-record boundaries;
6. generate ordinary business noise around deliberately selected Phase 2 stories;
7. avoid redefining product/customer master data inside transactional files.
