# Sales & Demand Planning Framework

## Purpose

This file accompanies `hav_seafood_sales_demand_planning_framework_v1.xlsx` and describes the static **Sales & Demand Planning Architecture** for HAV Seafood.

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

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

The workbook defines **how commercial demand planning is designed**. It intentionally contains **no actual forecasts or forecast quantities**.

The core distinction is:

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

---

## Core model

At the detailed level the future operational planning grain is:

`Customer + SKU + Period`

The architecture connects:

`Customer / Market / Channel / Territory`

`+ Customer-SKU Listing`

`+ Customer Agreement Forecast Expectations`

`+ SKU Lifecycle / Shelf-Life / Seasonality Classification`

`-> Demand Planning Profile`

`-> Forecast Method / Horizon / Granularity`

`-> Review / Consensus / Approval Structure`

`-> Approved Demand Plan`

`-> Production Planning + Purchased-Material Supply Planning`

The workbook currently covers **4 customer accounts, 24 active SKUs and all 73 active customer/SKU listings**.

---

## Important modelling principles

### Forecasts are operational data

Phase 1 defines who forecasts, what is forecast, how often, at what grain and under what rules.

It does **not** contain values such as "1,250 cases next month". Those are inherently time-dependent Phase 3 records.

### Customer forecast is not an order

A customer forecast is an input to planning. A confirmed order is executable demand and remains a separate ERP transaction.

### Demand remains commercially unconstrained

Production-capacity or material-supply constraints can create planning exceptions and business decisions, but they should not silently overwrite the underlying demand forecast. This preserves the distinction between:

- what the market/customer is expected to demand;
- what HAV Seafood can currently produce or supply;
- what the business ultimately decides to commit.

### Current customer forecast collaboration

The current agreement architecture implies:

- `CUS-001` — monthly forecast collaboration, mandatory;
- `CUS-002` — monthly forecast collaboration, mandatory;
- `CUS-003` — quarterly forward forecast collaboration, expected;
- `CUS-004` — monthly forecast collaboration, mandatory.

Internal Sales reviews can still occur monthly even when the customer's input cadence is quarterly.

---

## Ownership model

### Sales owns

- demand types;
- demand-planning profiles;
- forecast methods and horizon rules;
- customer and customer/SKU planning assignments;
- customer forecast-input requirements;
- forecast-version/status concepts;
- Sales forecast review and override principles;
- demand-planning exception taxonomy;
- forecast-quality metric definitions;
- approved commercial demand signal.

### Customer Account / Commercial architectures own

- Customer_ID;
- market/channel/segment/territory assignments;
- customer account ownership.

### Customer Assortment owns

- valid customer/SKU listings;
- SKU commercial listing status/orderability.

Demand planning creates rules only against valid current listings.

### Customer Agreements owns

- contractual forecast-collaboration expectations;
- agreement commitments.

Demand Planning references those commitments but does not redefine them.

### Production owns

- SKU technical identity upstream;
- production lines and work centers;
- capacity and bottlenecks;
- production order planning/execution;
- production scheduling.

### Procurement & Supply Chain owns

- purchased-item planning profiles;
- material planning policy;
- inventory-control policy;
- resulting supply-side planning actions.

### HR owns

- positions and incumbency.

Demand-planning responsibility is attached primarily to positions.

---

## Current role design

The current static operating model is:

- **Key Account Managers** — customer/account forecast input ownership;
- **Commercial Analyst** — forecast consolidation, validation and analysis;
- **Sales Manager** — process ownership and consensus approval;
- **Production Manager** — downstream production-planning recipient / feasibility input;
- **Procurement Manager** — downstream supply-planning recipient / material-risk input;
- **Sales Coordinator** — planning administration/file coordination support.

Named employees appear only as current-state navigation where included. HR remains authoritative for incumbency.

---

## System architecture

HAV Seafood currently has no dedicated demand-planning application.

The intended architecture is therefore deliberately realistic for a 92-person business:

- **ESYS-007 Microsoft 365** — controlled working forecast files, customer Excel/CSV attachments, collaboration and planning workbooks;
- **ESYS-006 Sales CRM** — customer/account relationship context and forecast follow-up metadata;
- **ESYS-001 Core ERP** — confirmed sales orders and downstream approved-demand/production-planning handoff;
- **ESYS-009 Power BI** — reporting/analysis copies only.

The existing enterprise System & Data Ownership Model does **not yet register dedicated forecast/demand-plan data objects**. `System_Mappings` therefore marks those future objects as **provisional**. They should be registered before Phase 3 operational forecast generation.

Existing registered objects remain authoritative, including:

- `DOBJ-082 Confirmed Sales Order` -> ESYS-001;
- `DOBJ-085 Production Order Planning Header` -> ESYS-001.

---

## Relationship with Supply Planning

The existing Supply Planning & Inventory Architecture defines **8 purchased-item supply-planning profiles** (`SPP-01` through `SPP-08`).

Sales Demand Planning does not assign those profiles or redefine material planning.

The intended chain is:

`Approved Customer/SKU Demand Plan`

`-> Finished-Goods SKU Requirements`

`-> Production/BOM Explosion`

`-> Purchased-Material Requirements`

`-> Existing Item Planning Assignment / SPP Profile`

`-> Purchase / Inventory Planning`

This keeps the commercial demand signal separate from the policy used to replenish individual purchased materials.

---

## Relationship with Production Capacity

`Production_Planning_Interface` maps the nine finished-product families to their existing primary Production lines and bottleneck context:

- salmon families -> `LINE-SAL`;
- cod families -> `LINE-COD`;
- pickled herring -> `LINE-HER`;
- canned mackerel and cod roe -> `LINE-CAN`;
- shrimp salad -> `LINE-SHR`.

This is a reference/interface layer only.

Sales does not determine production feasibility or production schedules.

---

## Workbook sheets

### `Demand_Types`
Controlled taxonomy separating baseline, customer, Sales, promotion, contract, new-product, seasonal and confirmed-order demand concepts.

### `Demand_Planning_Profiles`
Reusable planning profiles for customer classes, SKU storage/lifecycle characteristics and promotion overlays.

### `Forecast_Methods`
Permitted forecasting-method concepts, including customer collaboration, Sales judgment, historical baseline, seasonal baseline, contract reference, analogue, promotion overlay and consensus composite.

### `Forecast_Horizons`
Reusable short-, medium- and long-range planning windows.

### `Forecast_Time_Buckets`
Daily, weekly, monthly, quarterly and mixed weekly/monthly bucket definitions.

### `Forecast_Granularity`
Permitted dimensional planning grains. Customer + SKU + period is the main intended detailed future grain.

### `Planning_Hierarchy`
Compact commercial and product hierarchy references used for aggregation/navigation.

### `Customer_Planning_Assignments`
Current customer-level planning profile, agreement forecast cadence, input rule and planning ownership mapping for all four customers.

### `SKU_Planning_Assignments`
Current planning treatment for all 24 SKUs based on existing Production/assortment characteristics such as storage class, shelf life and product family.

### `Customer_SKU_Planning`
Main architecture junction table covering all 73 current active customer/SKU listings.

Each row links the listing to customer and SKU planning profiles, baseline/consensus method, horizon, seasonality, lifecycle, promotion applicability, agreement, production-line interface and planning ownership.

It contains **rules only, not forecast quantities**.

### `Seasonality_Profiles`
Qualitative structural seasonality classifications. No monthly indices or demand percentages are stored.

### `Lifecycle_Demand_Rules`
Planning treatment for established core, established extended, new, seasonal, phase-out and customer-specific lifecycle classes.

### `New_Product_Planning_Rules`
Architecture for forecasting new products/listings before sufficient normal history exists.

### `Promotion_Demand_Rules`
Defines how future promotion demand should be represented as a controlled overlay rather than silently changing baseline demand.

### `Customer_Forecast_Input_Rules`
Current expected customer-input cadence, horizon, grain, file format, handling system and validation responsibility.

### `Forecast_Version_Types`
Future operational forecast-version categories such as customer submitted, Sales working, consensus and approved demand plan.

### `Forecast_Status_Model`
Future forecast lifecycle status vocabulary. No actual status transitions are present.

### `Forecast_Override_Rules`
Static permitted override categories, position responsibilities and documentation principles.

### `Forecast_Review_Framework`
Weekly, monthly, quarterly and annual review structures. No meetings or review history are stored.

### `Demand_Planning_Ownership`
Position-based demand-planning responsibilities, including account input, consolidation, approval and downstream planning interfaces.

### `Forecast_Quality_Metrics`
Definitions of future metrics including forecast accuracy, bias, MAE, customer forecast accuracy, forecast value added and coverage completeness.

No metric values are stored.

### `Planning_Exception_Types`
Static taxonomy of possible missing-input, large-change, completeness, agreement, capacity, supply-risk and data-quality exceptions.

No exception instances are seeded.

### `Supply_Planning_Interface`
Defines the handoff from commercial demand through Production/BOM requirements into the existing purchased-item supply-planning architecture.

### `Production_Planning_Interface`
References Production family/line/bottleneck structures so future demand can be compared with capacity without redefining Production architecture.

### `System_Mappings`
Static and provisional system roles for planning objects.

### `Planning_Classifications`
Supporting Sales-specific controlled values.

### `Relationship_Reference`
Derived AI-friendly customer-level navigation view.

### `Source_Mappings`
Authoritative-source and conflict-precedence register.

### `Architecture_Notes`
Key modelling decisions, scope and cross-domain boundaries.

### `Data_Dictionary`
Field-level workbook documentation.

---

## Architecture boundaries — deliberately excluded

This workbook contains no:

- forecast quantities;
- dated forecast periods;
- customer forecast files;
- forecast submissions;
- historical forecast versions;
- forecast status events;
- actual overrides;
- forecast accuracy/bias results;
- forecast-vs-actual reports;
- sales orders;
- backlog;
- production plans;
- production orders;
- MRP runs;
- purchase suggestions;
- shortages;
- capacity exception events;
- supply exception events;
- promotion events or uplift quantities;
- planning meetings;
- consensus decisions/history;
- S&OP records;
- financial budgets.

Those belong to Phase 3 or to their future authoritative domain architectures.

---

## Story neutrality

The architecture deliberately does not seed:

- chronic overforecasting or underforecasting;
- missing customer forecasts;
- inaccurate customer inputs;
- deliberate forecast bias;
- capacity conflicts;
- material shortages;
- promotions with forecast failures;
- contract commitments inconsistent with forecasts;
- poor forecast accuracy;
- unauthorized overrides.

The architecture makes these patterns possible to represent later without choosing them during Phase 1.

---

## Recommended AI use

For fast context:

1. read this Markdown file;
2. inspect `Relationship_Reference` for customer-level navigation;
3. inspect `Customer_SKU_Planning` for detailed planning-rule coverage;
4. inspect `Demand_Planning_Profiles`, `Forecast_Methods`, `Forecast_Horizons` and `Seasonality_Profiles` for rule interpretation;
5. inspect `Supply_Planning_Interface` or `Production_Planning_Interface` for downstream relationships;
6. follow `Source_Mappings` to the upstream authoritative workbook where the question concerns customers, listings, agreements, capacity, supply planning, positions or systems.

---

## Overall role

This workbook forms the static **commercial demand-signal architecture** between HAV Seafood's customer/listing/agreement structures and its Production and Procurement/Supply Chain planning structures.

It gives later synthetic customer forecasts, Sales forecasts, consensus versions, forecast exceptions, accuracy analytics, production plans and supply consequences a coherent structural foundation without mixing Phase 1 company design with Phase 3 operational history.
