# Customer Agreements Framework

## Purpose

This file describes the static **Customer Agreements Architecture** for **HAV Seafood**.

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

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

The architecture answers:

> **What current commercial agreement relationships exist with HAV Seafood customers, what do those agreements structurally cover, which pricing/commercial-term profiles apply, what commitments and service expectations exist, and how are agreement review, notice, governance and system ownership designed?**

The authoritative workbook is:

`hav_seafood_sales_customer_agreements_framework_v1.xlsx`

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

---

## Architecture scope at a glance

The workbook contains:

- **4 current active primary customer agreements**, one for each current Customer_ID;
- **9 agreement types**, including framework and optional supplemental agreement capabilities;
- **4 reusable current agreement profiles** aligned to the existing customer/commercial-term structures;
- **4 customer-scope relationships**;
- **4 market-scope relationships**;
- **4 channel-scope relationships**;
- **4 product-scope relationships**, each referencing the assigned customer assortment profile rather than copying every customer/SKU listing;
- **4 agreement-to-commercial-term assignments**;
- **6 commitment types** and **14 current static agreement commitments**;
- **5 exclusivity types**, with all current agreements explicitly **non-exclusive**;
- **5 commercial service-commitment types** and **16 current service-term relationships**;
- **6 document-requirement types** and **21 current document-requirement relationships**;
- **4 review/renewal rules**;
- **4 notice-term structures**;
- **4 agreement authority classes**;
- **current agreement governance mappings** to HR positions and current incumbents for navigation;
- CRM/Microsoft 365/ERP/BI system-role mappings for each current agreement.

No agreement failures, expiry crises, conflicting exclusivity, missed commitments or deliberate anomalies are seeded.

---

## Current customer agreements

| Agreement ID | Customer | Profile | Market | Channel | Effective | Expiry | Renewal |
|---|---|---|---|---|---|---|---|
| CAGR-001 | Nordmark Food Distribution | Strategic Distributor Framework | MKT-SE | SCHA-002 | 2025-01-01 | 2027-12-31 | Automatic |
| CAGR-002 | Fjord & Field Retail | Strategic Direct Retail Framework | MKT-NO | SCHA-001 | 2025-04-01 | 2028-03-31 | Automatic |
| CAGR-003 | Baltic Pantry | Core Export Distributor Framework | MKT-LT | SCHA-002 | 2026-01-01 | 2027-12-31 | Manual renewal decision |
| CAGR-004 | Northline Grocers | Extended Direct Retail Framework | MKT-FI | SCHA-001 | 2025-07-01 | 2028-06-30 | Automatic |

These dates describe the **current agreement instances**. They are not an agreement-history table.

---

## Core entity model

The principal model is:

`Customer Account`

`-> Agreement Profile`

`-> Current Customer Agreement`

`-> Customer / Market / Channel / Product Scope`

`-> Commercial Term Profile`

`-> Commitments / Service Terms / Document Requirements`

`-> Review / Renewal / Notice Structure`

`-> Agreement Governance / Authority Class`

The important distinctions are:

`Customer Agreement != Pricing Profile != Sales Transaction`

`Contractual Commitment != Actual Performance`

`Agreement Requirement != Actual Document / Evidence`

---

## Relationship to Pricing & Commercial Terms

The Pricing & Commercial Terms workbook remains authoritative for:

- price lists;
- pricing profiles;
- discounts;
- volume-pricing rules;
- rebate structures;
- allowances;
- freight commercial terms;
- minimum-order rules;
- pricing exceptions.

This Customer Agreements workbook does **not** copy those mechanics.

Instead:

`Customer Agreement -> Commercial_Term_Profile_ID`

The agreement architecture therefore defines **contractual applicability**, while the Pricing architecture defines **commercial mechanics and values**.

---

## Relationship to Customer Assortment & Product Listing

The agreement architecture intentionally avoids copying all 73 current customer/SKU listings.

Each current agreement instead references the assigned `Customer_Assortment_Profile_ID`.

The normal product-scope model is:

`Agreement -> Customer Assortment Profile -> Current Approved Customer/SKU Listings`

The Customer Assortment workbook remains authoritative for actual listing identity and status.

---

## Exclusivity

The architecture supports explicit:

- market exclusivity;
- channel exclusivity;
- product/assortment exclusivity;
- territory exclusivity.

However, **all four current seeded agreements are explicitly non-exclusive**.

Any future exclusivity must be separately scoped and uses the material agreement authority class `AGAUTH-003`.

This avoids silently interpreting a distributor relationship as exclusive.

---

## Commitments

Static contractual commitment types include:

- demand forecast sharing;
- approved assortment maintenance;
- commercial business review;
- distributor market coverage;
- optional minimum contracted volume;
- optional joint promotional planning.

The current agreements use ordinary forecast, assortment and review commitments. Distributor relationships also contain market-coverage expectations.

A minimum-volume capability exists, but **no numeric minimum annual volume is currently seeded**. This is deliberate: the project has not yet designed the future demand/sales scale or Phase 2 stories, so Phase 1 does not accidentally constrain those later datasets.

Actual forecast submissions, sales volumes, business reviews and coverage performance belong to Phase 3.

---

## Service commitments

The agreement framework can express commercial expectations around:

- customer order coordination;
- forecast collaboration;
- documentation access;
- commercial delivery-point treatment;
- commercial issue escalation.

Detailed order-processing rules and numeric service levels are intentionally deferred to the future **Sales Order & Customer Service Framework**.

Physical delivery execution remains a future Logistics responsibility.

---

## Document requirements

The architecture defines potential requirements for:

- a controlled signed agreement copy;
- commercial/pricing schedules;
- current product specifications;
- quality/food-safety certificates;
- Faroese origin documentation;
- customer item/listing schedules.

The workbook stores **requirements and system references only**.

It contains no signed agreements, PDFs, Word documents, document versions, signatures or approval trails.

Technical document content remains authoritative in the appropriate Quality, Production or other specialist source.

---

## Agreement review, renewal and notice

Reusable review/renewal rules separate:

- review frequency;
- automatic versus manual renewal;
- renewal-term concept;
- review lead time;
- review owner.

Reusable notice terms define synthetic 30/60/90/180-day notice structures.

These are **fictional internal HAV Seafood commercial assumptions**, not statements of Faroese, Nordic or other law.

---

## Agreement governance and authority

Agreement governance is attached primarily to **positions and position seats**, not named employees.

Current employee names are included only as present-state navigation references from HR incumbency.

The framework distinguishes:

- commercial owner;
- agreement reviewer;
- Finance reviewer;
- Quality reviewer;
- executive approver.

Authority classes distinguish standard, strategic, exclusivity/material and material-amendment arrangements.

This workbook does **not** define executable approval workflow. The future **Sales Process, Authority & Commercial Control Framework** will own process steps, segregation of duties, actual approval rules and approval events.

---

## System architecture

The current structural system split is:

- **ESYS-006 Sales CRM** — current customer-agreement relationship metadata;
- **ESYS-007 Microsoft 365** — controlled agreement document/repository reference;
- **ESYS-001 Core ERP** — confirmed Customer_ID master and pricing/order execution context;
- **ESYS-009 Power BI** — reporting copies only.

This agreement metadata assignment should be registered explicitly if the Shared Enterprise System/Data Ownership Model is refreshed later.

If the executed controlled agreement document conflicts with a CRM summary, the controlled executed document should be treated as the agreement evidence while upstream master sources continue to own Customer_ID, pricing profiles, SKUs and other referenced entities.

---

## Finance boundary

This architecture does **not** create:

- payment-term masters;
- customer credit limits;
- credit-risk structures;
- accounts receivable;
- rebate accounting/accrual rules;
- revenue-recognition rules;
- tax rules;
- ledger mappings;
- settlement transactions.

Those belong to the future Finance Architecture.

---

## Quality boundary

Customer agreements may require product specifications, quality certificates or other technical/compliance evidence.

Sales owns the fact that a requirement is commercially present.

Quality/technical domains remain authoritative for:

- requirement content;
- specification values;
- certificates;
- approvals;
- audits;
- quality evidence;
- release decisions.

---

## Current state versus history

The workbook can legitimately store:

- current agreement identity;
- current status;
- current effective/expiry dates;
- current scope;
- current commercial-term linkage;
- current commitments;
- current renewal/notice rule;
- current governance.

It deliberately does **not** contain:

- prior agreements;
- draft/redline history;
- negotiations;
- signature events;
- amendments;
- historical versions;
- renewal decisions/events;
- termination notices;
- breaches;
- disputes;
- claims;
- actual commitment performance;
- approval events;
- emails or meeting records.

Those belong to Phase 3 after the Phase 2 stories are designed.

---

## Story neutrality

The architecture intentionally avoids seeding:

- expired agreements;
- agreements close to immediate expiry;
- contradictory scopes;
- conflicting exclusivity;
- impossible commitments;
- pricing/agreement mismatches;
- missing agreement governance;
- unauthorized commercial exceptions;
- missed minimum volumes;
- SLA failures;
- renewal disputes.

Those can later become deliberate cross-functional stories rather than accidental Phase 1 artifacts.

---

## Workbook sheets

### `Customer_Agreement_Reference`

Compact linked view of each current customer and its existing market/channel, assortment, commercial-term, pricing and account-ownership context. Derived reference only.

### `Agreement_Types`

Reusable customer agreement type taxonomy.

### `Agreement_Profiles`

Reusable agreement templates aligned to current customer classes and commercial-term profiles.

### `Customer_Agreements`

Authoritative current customer-agreement master for the Sales domain.

### `Agreement_Customer_Scope`

Defines the customer accounts covered by each agreement.

### `Agreement_Market_Scope`

Defines market applicability.

### `Agreement_Channel_Scope`

Defines Sales-channel applicability.

### `Agreement_Product_Scope`

Defines product applicability through customer assortment/SKU/listing references.

### `Agreement_Term_Assignment`

Links each agreement to its authoritative Pricing & Commercial Terms profile.

### `Commitment_Types`

Reusable contractual commitment taxonomy.

### `Agreement_Commitments`

Current static contractual expectations. No actual performance.

### `Exclusivity_Types`

Reusable explicit exclusivity classifications.

### `Agreement_Exclusivity`

Current agreement exclusivity structures. All current agreements are non-exclusive.

### `Service_Commitment_Types`

Reusable commercial service-expectation taxonomy.

### `Agreement_Service_Terms`

Current agreement-to-service expectation relationships.

### `Document_Requirement_Types`

Reusable contractual document requirement taxonomy.

### `Agreement_Document_Requirements`

Current agreement document requirements without actual document instances.

### `Review_Renewal_Rules`

Reusable review and renewal structures.

### `Notice_Terms`

Reusable synthetic notice-period structures.

### `Agreement_Governance`

Position-based current agreement ownership/reviewer mappings.

### `Agreement_Authority_Classes`

Conceptual authority classifications for agreement types/commitments.

### `Agreement_Status_Model`

Controlled agreement status vocabulary.

### `Agreement_Classifications`

Supporting Sales-specific agreement classifications.

### `System_Mappings`

Static CRM/M365/ERP/BI agreement system-role mappings.

### `Relationship_Reference`

AI-friendly derived one-row-per-current-agreement navigation layer.

### `Source_Mappings`

Authoritative source and conflict-precedence register.

### `Architecture_Notes`

Key modelling rules, boundaries and Phase 3 implications.

### `Data_Dictionary`

Field-level workbook documentation.

---

## Recommended AI use

For quick context:

1. read this Markdown file;
2. inspect `Relationship_Reference`;
3. inspect `Customer_Agreements` for current agreement identity/status/dates;
4. inspect the relevant scope/commitment/governance sheet;
5. follow `Source_Mappings` to the authoritative upstream workbook when a question concerns customer identity, market/channel, assortment, pricing, positions or systems.

Do not treat `Relationship_Reference` or `Customer_Agreement_Reference` as replacements for their authoritative source sheets.

---

## Overall role

This workbook forms the static **contractual/commercial relationship layer** between HAV Seafood's customer master and its pricing, assortment, market/channel and governance architectures.

It gives later synthetic orders, forecasts, promotions, pricing events, document records, renewals, disputes and performance analysis a stable agreement structure without mixing Phase 1 company design with Phase 3 history.
