# Pricing & Commercial Terms Framework

## Purpose

This folder file defines the static **Pricing & Commercial Terms Architecture** for **HAV Seafood**.

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

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

The architecture answers:

> **What current pricing structures does HAV Seafood use, which price lists and normal commercial terms apply to the current customer/SKU relationships, and what static discount, volume, rebate, freight, minimum-order and exception rules govern those relationships?**

It does **not** contain sales orders, quotations, invoice prices, actual discounts, promotion events, price-change history, rebate accruals, allowance claims, credit notes or customer-payment activity.

The authoritative workbook is:

`hav_seafood_sales_pricing_commercial_terms_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:

- **24 active sellable SKUs** as linked pricing reference data;
- **4 current market/channel price lists**;
- **96 current price-list lines** (24 SKUs x 4 price lists);
- **4 reusable customer pricing profiles**;
- **4 current customer pricing-profile assignments**;
- **73 current Customer + SKU pricing relationships**, exactly matching the current Customer + SKU listings;
- **4 standard discount profiles**;
- **2 volume-pricing profiles** and **7 quantity tiers**;
- **3 rebate profiles** and **6 active rebate tiers**;
- **4 allowance types**;
- **3 freight-commercial term profiles**;
- **3 minimum-order rules**;
- **4 surcharge types**;
- **4 reusable commercial-term profiles**;
- **4 current customer commercial-term assignments**;
- **4 conceptual pricing-authority classes**.

All current monetary values and percentages are **fictional HAV Seafood assumptions** created for this synthetic dataset. They are not researched market prices, legal terms, accounting rules or real-company benchmarks.

---

## Core pricing model

The normal current pricing chain is:

`Customer + SKU Listing`

`-> Market / Channel Price List`

`-> Current List Price`

`-> Assigned Customer Pricing Profile`

`-> Standard Profile Discount`

`-> Current Customer Base Price`

Additional architecture may then govern potential:

`Volume Discount / Promotional Adjustment / Commercial Exception`

The important distinction is:

`List Price != Customer Base Price != Actual Transaction Price`

The workbook defines the first two layers of current commercial master pricing. **Actual transaction price belongs to Phase 3.**

---

## Current price lists

The current synthetic price-list architecture contains:

- `PL-SE-DIST` — Sweden Distributor List — SEK;
- `PL-NO-RETAIL` — Norway Direct Retail List — NOK;
- `PL-LT-DIST` — Lithuania Distributor List — EUR;
- `PL-FI-RETAIL` — Finland Direct Retail List — EUR.

Each current price list contains all 24 active SKUs, matching the existing architecture in which all active SKUs are structurally available in each current seeded market.

These are **current-state master values only**. No historical price-list versions or effective-date history are represented.

---

## Current customer pricing assignments

- `CUS-001` Nordmark Food Distribution -> `CPP-STRAT-DIST` / `PL-SE-DIST`;
- `CUS-002` Fjord & Field Retail -> `CPP-STRAT-RETAIL` / `PL-NO-RETAIL`;
- `CUS-003` Baltic Pantry -> `CPP-CORE-DIST` / `PL-LT-DIST`;
- `CUS-004` Northline Grocers -> `CPP-EXT-RETAIL` / `PL-FI-RETAIL`.

The current customer base price for each active listing is formula-derived from the applicable list price and standard pricing-profile discount. No current customer/SKU pricing exception is deliberately seeded.

---

## Workbook sheets

### `SKU_Pricing_Reference`

Linked Sales-facing view of the 24 active sellable SKUs. It provides convenient product context but does not replace the upstream product/listing architecture.

### `Pricing_Models`

Defines reusable pricing models including direct-retail market list pricing, distributor list pricing, customer-specific exceptions and temporary promotional pricing.

The latter two are architecture capabilities; they do not imply current exception or promotion events.

### `Price_Lists`

Defines the four current market/channel/currency price-list masters.

### `Price_List_Lines`

Defines 96 current synthetic SKU list prices.

These prices are static architecture master values. They are deliberately fictional and should not be interpreted as real seafood market pricing.

### `Customer_Pricing_Profiles`

Defines four reusable pricing profiles combining the normal price list, segment/channel/market applicability, discount profile, rebate profile, freight profile and volume-pricing profile.

### `Customer_Pricing_Assignments`

Assigns one current primary pricing profile and price list to each seeded customer.

### `Customer_SKU_Pricing`

Defines the 73 current pricing relationships corresponding exactly to the 73 active Customer + SKU listings.

The sheet contains:

- list price;
- standard profile discount percentage;
- formula-derived standard discount amount;
- formula-derived current customer base price;
- volume/rebate profile references;
- pricing source classification.

It intentionally contains no actual order/invoice price and no historical price changes.

### `Discount_Types`

Defines reusable discount concepts: standard profile, volume, promotional, new-listing support and commercial exception.

### `Discount_Profiles`

Defines the current normal baseline customer-discount structures and synthetic normal combined-discount control limits.

Those control limits are **commercial policy assumptions**, not Finance accounting thresholds.

### `Volume_Pricing_Profiles`

Defines reusable case-volume pricing structures.

### `Volume_Price_Tiers`

Defines static case-quantity tiers and incremental discount eligibility.

No actual order quantity or applied discount event exists here.

### `Rebate_Types`

Defines annual target-attainment, assortment-support and no-standard-rebate concepts.

### `Rebate_Profiles`

Defines current reusable commercial rebate eligibility profiles.

### `Rebate_Tiers`

Defines synthetic rebate-rate tiers based on achievement relative to a future agreed target.

The target amount itself belongs to the future Customer Agreements architecture; accounting/accrual treatment belongs to Finance.

### `Commercial_Allowances`

Defines potential listing, promotional, display and distribution-support allowance types.

No allowance amount, claim, settlement or accounting entry is stored.

### `Freight_Commercial_Terms`

Defines commercially agreed freight responsibility such as delivered direct-retail/distributor treatment and a customer-collect exception structure.

Sales owns the **commercial promise**. Future Logistics owns physical shipment execution.

### `Minimum_Order_Rules`

Defines normal commercial case-quantity minimums by customer type/channel.

These are separate from technical SKU order multiples in the Customer Assortment & Product Listing architecture.

### `Surcharge_Types`

Defines potential small-order, expedited, customer-specific-label and non-standard-pallet surcharge structures.

No actual rate or transaction charge is represented.

### `Commercial_Term_Profiles`

Combines reusable pricing, discount, volume, rebate, freight and minimum-order structures into a convenient Sales commercial package.

A commercial-term profile is **not a customer agreement**.

The sheet explicitly defers payment-term master data to future Finance architecture.

### `Customer_Term_Assignments`

Maps each current customer to its primary commercial-term profile.

### `Pricing_Authority_Classes`

Defines conceptual authority classes referencing established Sales/management roles and positions.

These are control classifications only. Actual workflow steps, approval rules, delegation and audit events will belong to the future **Sales Process, Authority & Commercial Control** architecture and Phase 3 operational data.

### `Commercial_Classifications`

Controlled Sales-local classification codes used in this workbook.

### `System_Mappings`

Documents intended system roles.

The main architecture decision is:

- `ESYS-001 Core ERP` — operational master for executable current price lists, list-price lines and current customer/SKU base pricing;
- `ESYS-006 Sales CRM` — master for reusable customer-pricing/commercial-profile semantics and commercial eligibility structures;
- `ESYS-009 Power BI` — reporting consumer only.

These new pricing objects should be added to the Shared Enterprise System/Data Ownership model when that architecture is refreshed.

### `Relationship_Reference`

Derived AI-friendly joined view of all 73 current customer/SKU pricing relationships, connecting customer, listing, product, market, channel, segment, territory, price list, current price, pricing profile and commercial-term structures.

It does not own master data.

### `Source_Mappings`

Documents upstream authority and conflict precedence.

### `Architecture_Notes`

Documents design decisions, scope, story neutrality and ownership boundaries.

### `Data_Dictionary`

Field-level documentation for the workbook.

---

## Relationship with previous Sales architecture

### Customer Account & Commercial Organization

Remains authoritative for:

- `Customer_ID`;
- customer account name;
- primary customer currency and shared account attributes.

### Markets, Channels & Commercial Territory

Remains authoritative for:

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

### Customer Assortment & Product Listing

Remains authoritative for:

- SKU commercial references;
- current Customer + SKU listing relationships;
- orderability/listing status;
- technical/customer listing-level order constraints.

This pricing workbook prices those existing relationships rather than inventing new customer/SKU combinations.

---

## Finance boundary

This workbook deliberately does **not** define:

- payment-term masters or number of payment days;
- customer credit limits;
- credit risk/status;
- VAT/tax treatment;
- revenue-recognition rules;
- accounts receivable;
- invoice accounting;
- currency/FX accounting;
- cost/margin/profitability accounting;
- rebate accrual accounting;
- allowance accounting;
- ledger mappings;
- customer payment activity.

Future Finance architecture is authoritative for those structures.

Sales can define that a rebate, allowance, surcharge or freight term is commercially possible without becoming authoritative for its accounting treatment.

---

## Customer Agreements boundary

This workbook does **not** create:

- signed customer agreements;
- agreement duration;
- exclusivity;
- contractual territory rights;
- binding volume commitments;
- contract renewal/termination structures;
- agreement-document history.

The future Customer Agreements architecture should reference the reusable pricing/commercial-term profiles defined here.

A useful future relationship is:

`Customer Agreement -> Commercial Term Profile -> Pricing / Discount / Rebate / Freight Rules`

---

## Current state versus history

Current architecture may contain:

- current list price;
- current standard customer discount profile;
- current customer base price;
- current rebate/volume eligibility structure;
- current commercial-term profile assignment.

Phase 3 should contain:

- price-change events;
- quotations;
- negotiation history;
- promotional periods/prices;
- actual order discounts;
- actual invoice prices;
- rebate accruals/settlements;
- allowance claims;
- surcharge charges;
- approval events;
- exception history.

---

## Story neutrality

No deliberate Phase 2 pricing problem is seeded here.

The architecture does not intentionally contain:

- unauthorized discounts;
- anomalous customer prices;
- margin erosion;
- incorrect currencies;
- inconsistent price-list assignment;
- unexplained rebate leakage;
- pricing-control failure;
- hidden customer-specific exceptions.

All four customers follow coherent normal profile pricing.

Such patterns can be introduced deliberately in Phase 3 once the business stories are selected.

---

## Identifier conventions

Existing customer, SKU, market, channel, segment, territory, role, position and system IDs are preserved.

New Sales-local prefixes include:

- `PRMOD-*` — pricing models;
- `PL-*` — price lists;
- `PLL-*` — price-list lines;
- `CPP-*` — customer pricing profiles;
- `CPA-*` — customer pricing assignments;
- `CSP-*` — customer/SKU current pricing;
- `DPR-*` — discount profiles;
- `VPR-*` / `VPT-*` — volume-pricing profiles/tiers;
- `RPR-*` / `RBTIER-*` — rebate profiles/tiers;
- `FRT-*` — freight-commercial term profiles;
- `MOR-*` — minimum-order rules;
- `SCTP-*` — Sales commercial-term profiles;
- `CTA-*` — customer term assignments;
- `PAUTH-*` — pricing authority classes.

These prefixes are provisional Sales-domain conventions and should be registered in Shared Enterprise identifier standards when refreshed.

---

## Recommended AI usage

For rapid context:

1. Read this Markdown file.
2. Inspect `Relationship_Reference` for one joined view of current customer/SKU pricing.
3. Inspect `Customer_SKU_Pricing` for authoritative current customer base-price relationships.
4. Inspect `Price_List_Lines` for current list prices.
5. Inspect `Customer_Pricing_Profiles` and `Commercial_Term_Profiles` for reusable pricing/term logic.
6. Inspect discount, volume and rebate sheets when reasoning about eligible adjustments.
7. Consult upstream Sales architecture for customer, market/channel and listing identity.
8. Treat future Finance and Customer Agreement structures as unresolved where explicitly deferred.

If a linked upstream value conflicts with this workbook, the authoritative upstream source wins. If a derived `Relationship_Reference` value conflicts with an authoritative subject sheet, the subject sheet wins.

---

## Use in later phases

### Phase 2 — Stories

This architecture can support later stories involving:

- price increases or delayed updates;
- customer-specific exceptions;
- discount leakage;
- promotion effects;
- volume-tier behavior;
- rebate eligibility;
- minimum-order behavior;
- freight/surcharge disputes;
- agreement/pricing mismatch;
- sales-volume/margin effects;
- Finance consequences of rebates and commercial support;
- approval/control failures.

Stories should reference these existing IDs/rules rather than change the architecture merely to make a pattern possible.

### Phase 3 — Operational dataset generation

Operational datasets should:

1. reuse the customer, SKU, listing, market/channel and pricing IDs defined here;
2. generate normal transaction prices from the static pricing hierarchy;
3. preserve the distinction between list price, customer base price and actual transaction price;
4. use volume/rebate/allowance/surcharge rules only when the relevant operational event qualifies;
5. preserve ERP/CRM system boundaries;
6. use future Finance rules for accounting and settlement once that architecture exists;
7. create realistic ordinary activity around deliberately selected Phase 2 pricing stories.
