# HAV Seafood — Sales Customer Account & Commercial Organization Architecture

## Purpose

This file describes `hav_seafood_sales_customer_account_commercial_organization_v1.xlsx`, the authoritative **Sales customer-account and commercial-organization architecture** for HAV Seafood.

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

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

The workbook defines **who HAV Seafood currently sells to structurally, how customer accounts extend shared external organizations, how those accounts are classified and owned internally, and how customer identity maps across ERP and CRM**.

It intentionally contains **no operational or historical sales activity**.

---

## Core architecture model

The principal identity chain is:

`Shared External Organization -> Sales Customer_ID -> Commercial Roles / Sites / Contacts -> Account Ownership -> ERP / CRM Mapping`

The most important distinction is:

`External_Organization_ID != Customer_ID`

- `External_Organization_ID` is the shared enterprise identity of the real-world organization.
- `Customer_ID` is HAV Seafood's Sales/customer-master identity for a confirmed customer relationship.
- Shared Enterprise remains authoritative for the organization itself.
- Sales owns the customer-domain extension.

The workbook issues the previously reserved Sales customer identifier pattern `CUS-*` as `CUS-001` through `CUS-004`.

---

## Current customer population

The workbook creates customer masters only for the four customer organizations already seeded in the Shared Enterprise architecture:

- `CUS-001` -> `ORG-EXT-019` — Nordmark Food Distribution AB, Sweden
- `CUS-002` -> `ORG-EXT-020` — Fjord & Field Retail AS, Norway
- `CUS-003` -> `ORG-EXT-021` — Baltic Pantry UAB, Lithuania
- `CUS-004` -> `ORG-EXT-022` — Northline Grocers Oy, Finland

No additional external organizations are invented inside Sales because Shared Enterprise owns external-organization identity.

The current Shared Enterprise source contains no authoritative multi-company customer-group hierarchy for these organizations. Each customer is therefore represented as a **standalone root account**. Future parent/child retail-group structures should only be added after the corresponding external organizations exist in Shared Enterprise.

---

## Workbook sheets

### `Customer_Accounts`

Authoritative Sales customer master.

Contains:

- `Customer_ID`;
- link to `External_Organization_ID`;
- customer account name;
- customer account type;
- customer status;
- primary shared market;
- country, currency and preferred commercial language references;
- relationship model;
- account tier;
- strategic/direct/distributor flags;
- ERP/CRM system references;
- shared customer party-role reference.

It does not contain pricing, payment terms, credit limits, sales history, assortment, forecasts or orders.

### `Customer_Hierarchy`

Defines current customer hierarchy posture.

All four current accounts are level-1 standalone roots because no authoritative parent/child customer organizations are currently present in Shared Enterprise.

### `Commercial_Roles`

Defines Sales-specific commercial roles such as:

- Retail customer;
- Distributor;
- Importer;
- Buying organization;
- Private-label customer (available for future use).

These extend, but do not replace, the shared `PROLE-CUSTOMER` external-party role.

### `Customer_Account_Roles`

Maps customers to one or more commercial roles and identifies the primary role.

### `Customer_Commercial_Sites`

Sales extension of shared external-address identity.

Each current customer references its existing shared `External_Address_ID` as the primary commercial site. The shared source contains only city/country-level location information, so this workbook deliberately does not invent street addresses, postal codes, distribution centers, ship-to locations or bill-to locations.

### `Customer_Contacts`

Sales extension of shared functional contact identity.

Each customer references its existing shared `External_Contact_ID` as a buying/commercial functional contact. Named individuals, email addresses and telephone numbers are not populated.

### `Account_Ownership_Types`

Defines reusable structural account-responsibility types:

- account owner;
- sales management oversight;
- customer-service owner;
- sales-administration support;
- commercial-analytics support.

### `Account_Ownership`

Maps customer accounts to existing approved HR position seats.

Current structural assignment is:

- Sweden, Norway and Finland -> Nordic-markets Key Account Manager seat `PSEAT-074`;
- Lithuania -> Export-markets Key Account Manager seat `PSEAT-075`;
- Sales Manager oversight -> `PSEAT-073`;
- Customer Service & Order Coordination -> `PSEAT-078`;
- Sales Administration -> `PSEAT-077`;
- Commercial Analysis -> `PSEAT-079`.

The existing approved vacant KAM seat `PSEAT-076` is deliberately **not** assigned a portfolio.

Position-seat ownership is used because it allows a future employee replacement to inherit structural account responsibility without redefining the customer architecture.

### `Customer_Classifications`

Controlled Sales-specific classifications for:

- customer account type;
- customer status;
- relationship model;
- account tier;
- hierarchy relationship;
- commercial site type;
- commercial contact role.

Shared classifications such as country, currency, language and market are referenced from Shared Enterprise rather than recreated here.

### `Customer_System_Mapping`

Defines static customer identity across systems.

The governing system model is:

- `ESYS-001 Core ERP` — authoritative for confirmed `Customer_ID` and confirmed customer transactional/master fields;
- `ESYS-006 Sales CRM` — authoritative for customer relationship-management extensions, future pipeline/activity and commercial follow-up;
- `ESYS-007 Microsoft 365` — shared external-organization identity registry context.

The existing `DOBJ-043 Customer Master`, `SYNC-009`, `SYNC-010` and related conflict-precedence rules are preserved.

This sheet contains only static mappings, not synchronization history.

### `Relationship_Catalog`

AI-friendly description of the important entity relationships, keys and conceptual cardinalities.

This sheet is documentation/navigation and does not override authoritative sources.

### `Source_Mappings`

Records which existing architecture is authoritative for each reused concept and how the Sales workbook extends it.

### `Architecture_Notes`

Records scope, ownership, boundaries, assumptions, system-of-record decisions and future extension points.

### `Data_Dictionary`

Field-level definition of the workbook.

---

## Relationship with Shared Enterprise Architecture

Shared Enterprise remains authoritative for:

- external organization identity;
- shared party roles;
- external address identity;
- external contact identity;
- countries;
- currencies;
- languages;
- markets/regions;
- enterprise systems;
- identifier conventions;
- enterprise organization structures.

Sales extends those structures with `Customer_ID`, commercial account classifications, commercial roles, customer-site/contact interpretation and commercial ownership relationships.

If a Sales value conflicts with an authoritative Shared Enterprise identity value, the Shared Enterprise identity source wins for the shared concept.

---

## Relationship with HR & Organization Architecture

Sales does not create its own employee, role or position identities.

The workbook reuses:

- `DEPT-SALES`;
- Sales roles `R036`-`R040`;
- existing `POS-SALES-*` positions;
- approved `PSEAT-*` position seats;
- current incumbency only as a navigational reference.

HR remains authoritative for workforce establishment, positions, seats and incumbency.

---

## System/data ownership boundary

The existing enterprise ownership model deliberately splits customer responsibilities:

`Sales business ownership -> Customer concept`

`Core ERP ESYS-001 -> confirmed Customer_ID / transactional master`

`Sales CRM ESYS-006 -> relationship-management extensions and future activity`

`Shared Enterprise / M365 -> External_Organization_ID`

CRM and ERP therefore do not represent competing customer identities. They hold different authoritative portions of the customer domain.

---

## Deferred Sales architecture

The following are intentionally **not** defined here because they belong to later Sales & Commercial architecture workbooks:

- Sales channels;
- customer segments;
- commercial territories;
- detailed customer-SKU assortment/listings;
- list prices and pricing profiles;
- discounts, rebates and promotional allowances;
- customer agreements and contractual commercial terms;
- demand-planning profiles;
- order/customer-service profiles;
- Sales approval/process architecture.

The workbook includes the fields and relationships required to connect to those future architectures without pre-empting them.

---

## Finance boundary

This workbook does not define:

- customer credit limits;
- credit ratings;
- payment-term masters;
- accounts receivable;
- tax treatment;
- invoice accounting;
- customer credit holds;
- financial exposure;
- customer profitability.

Those belong to Finance or later derived analytical datasets.

---

## Operational data intentionally excluded

This workbook contains no:

- leads or opportunities;
- quotations;
- CRM activities;
- calls or meetings;
- emails;
- customer contact history;
- sales orders;
- sales-order lines;
- invoices;
- shipments;
- deliveries;
- order amendments;
- cancellations;
- customer forecasts;
- actual sales volumes;
- prices charged;
- discounts applied;
- rebates paid;
- complaints;
- returns;
- service incidents;
- customer profitability;
- account performance history;
- customer master change history;
- synchronization events or system errors.

Those belong to Phase 3 after business stories have been designed.

---

## Story neutrality

The architecture does not deliberately encode future business-story anomalies.

The strategic/core account tiers, retailer/distributor models and Nordic/export account ownership are normal structural design choices. They should not automatically be interpreted as indicators of performance, risk, customer satisfaction or future story importance.

---

## Identifier conventions

Existing identifiers are preserved, including:

- `ORG-EXT-*` — external organizations;
- `ADDR-EXT-*` — shared external addresses;
- `CONTACT-EXT-*` — shared external contacts;
- `MKT-*` — markets/regions;
- `R*` — enterprise job roles;
- `POS-*` — structural positions;
- `PSEAT-*` — approved HR position seats;
- `ESYS-*` — enterprise systems.

This workbook activates:

- `CUS-*` — Sales Customer_ID, already reserved in the enterprise identifier standards.

It also introduces Sales-local Phase 1 prefixes such as `CHIER-*`, `CROLE-*`, `CAR-*`, `CSITE-*`, `CCONTACT-*`, `AOWN-*`, `COWN-*` and `CSMAP-*`. These should be registered in the shared identifier standards if that workbook is refreshed.

---

## Recommended AI use

For fast context:

1. Read this Markdown file.
2. Inspect `Customer_Accounts` for the authoritative Sales customer list.
3. Use `Account_Ownership` to understand who structurally owns each account.
4. Use `Customer_System_Mapping` for ERP/CRM identity and system-of-record questions.
5. Use `Source_Mappings` when a field crosses into Shared Enterprise, HR or system ownership.
6. Use `Relationship_Catalog` to determine join paths.
7. Open the authoritative external source workbook whenever a shared identity, address, contact, employee, position, market or system field needs to be verified.

The Excel workbook remains authoritative for the Sales structures defined here. This Markdown file is a compact semantic reference and does not override workbook data.

---

## Overall role

Together, the workbook and this reference file form the first authoritative **Sales & Commercial master-data layer** for HAV Seafood.

They establish a stable customer identity and commercial-account model that later pricing, assortment, demand, order, CRM, Finance, Logistics, Quality and Marketing datasets can reference without redefining customers or losing alignment with Shared Enterprise and HR.
