# Sales Process, Authority & Commercial Control Architecture

## Purpose

This file accompanies `hav_seafood_sales_process_authority_commercial_control_v1.xlsx` and describes the static **Sales Process, Authority & Commercial Control Architecture** for HAV Seafood.

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

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

The workbook defines **which Sales processes exist, which authority classes they require, which positions participate, which controls apply, how exceptions escalate, and where specialist-domain review is required**.

It intentionally contains **no actual approval requests, decisions, timestamps, control executions, exception cases, escalations, audit findings or workflow history**.

The core model is:

`Commercial Process -> Process Steps -> Position / Authority Class -> Control -> Exception / Escalation -> Future Approval Event`

---

## Scope at a glance

The architecture currently contains:

- **37 Sales & Commercial processes** across 9 process categories;
- **214 reusable static process steps**;
- **7 Sales authority classes** mapped to the existing HR authority backbone;
- **12 position-to-Sales-authority mappings**;
- **10 commercial threshold types** and **17 threshold/authority rules**;
- **35 consolidated commercial controls**;
- **11 segregation-of-duties controls**;
- **11 commercial exception types**;
- **5 escalation classes**;
- explicit Finance, Quality, Production, Procurement/Supply and Logistics review boundaries.

These are static rules and relationships, not event history.

---

## Core authority principle

Sales does **not** create an independent approval hierarchy.

The existing HR architecture remains authoritative for enterprise authority levels, positions, incumbency, delegation principles and segregation-of-duties concepts.

The Sales architecture adds a domain interpretation:

`Sales Process -> Required Sales Authority Class -> Existing HR Authority Level / Position`

At transaction time in Phase 3:

`Authority Requirement -> Position -> Current Incumbent / Valid Delegate -> Actual Approver`

Actual approver identity is therefore not hard-coded into this Phase 1 architecture.

---

## Sales authority classes

The workbook defines seven Sales authority classes:

- **SAUTH-01 — Preparation / Operational Administration**: preparation, validation and coordination without approval authority;
- **SAUTH-02 — Account / Commercial Initiation**: account-owner/KAM initiation without self-approval authority;
- **SAUTH-03 — Sales Manager Commercial Authority**: normal department-level commercial approval, mapped to `POS-SALES-MGR` / HR `HAL-04`;
- **SAUTH-04 — Specialist Control Review**: Quality/Operations or other independent specialist review, referencing HR `HAL-07` where applicable;
- **SAUTH-05 — Finance Control Review**: Finance-owned authority, referencing HR `HAL-06`;
- **SAUTH-06 — Executive Commercial Authority**: Managing Director authority for material agreements, exclusivity and material commercial exceptions, mapped to HR `HAL-08`;
- **SAUTH-07 — Independent / Dual Control**: conflict-free or dual-control pattern referencing HR `HAL-09` / `HAL-10`.

These classes classify the requirement; they do not grant named employees authority independently of HR.

---

## Workbook contents

### `Sales_Processes`
Authoritative catalog of the 37 Sales & Commercial processes, covering customer management, commercial structure, listings, pricing/terms, agreements, demand planning, order management, customer service and commercial governance.

### `Process_Categories`
Controlled taxonomy for the nine process families.

### `Process_Steps`
Static ordered workflow structure for each process. Steps distinguish preparation, prerequisite validation, specialist review, commercial approval, master/workflow execution and evidence/synchronization.

### `Sales_Authority_Classes`
Sales-specific authority requirements mapped to existing HR authority levels.

### `Position_Authority_Mapping`
Maps Sales and specialist positions to their Sales-process capabilities. Preparation roles do not automatically become approvers.

### `Process_Authority_Rules`
Defines initiator/preparer, required authority, approver position/type, cross-functional review flags, self-approval prohibition, independent review and dual-approval expectations.

### `Commercial_Threshold_Types` / `Commercial_Approval_Thresholds`
Defines Sales-owned threshold concepts and their authority treatment.

Synthetic Sales thresholds include commercial discount/price deviations, forecast override magnitude, agreement duration, exclusivity, order-cutoff deviation and allocation-priority override.

**No company-wide monetary approval threshold is invented.** Monetary commitment and credit/payment thresholds remain future Finance architecture.

### Domain control sheets
- `Pricing_Control_Rules`
- `Customer_Master_Controls`
- `Listing_Control_Rules`
- `Agreement_Control_Rules`
- `Demand_Planning_Controls`
- `Order_Control_Rules`
- `Customer_Service_Controls`

These provide focused controls around each Sales subject area.

### `Control_Types` / `Commercial_Controls`
Defines control taxonomy and a consolidated catalog of 35 preventive, detective, approval, validation, SoD, specialist-review, system, documentation and escalation controls.

### `Segregation_of_Duties`
Defines incompatible combinations such as pricing preparation versus material exception approval, demand preparation versus consensus approval, Sales order processing versus Finance hold release, and Sales priority versus physical stock allocation.

### `Exception_Types` / `Exception_Rules`
Defines possible commercial exception classes and the authority/evidence/escalation requirements for them. No actual exception cases are stored.

### `Escalation_Classes` / `Escalation_Rules`
Defines routine, manager, cross-functional, executive and critical escalation paths.

### `Approval_Evidence_Requirements`
Defines what future approval records should preserve, such as decision, approver, timestamp, reason, threshold comparison and specialist review.

### `Process_System_Mapping`
Maps Sales processes to Core ERP, Sales CRM, Microsoft 365 and QMS interactions while preserving Shared Enterprise system/data ownership.

### `Cross_Functional_Review_Rules`
Defines when Finance, Quality, Production, Procurement/Supply or Logistics review is required or conditional.

### `Delegation_Rules`
Defines Sales-specific delegation principles while deferring actual delegation authority to the HR/enterprise framework.

### `Approval_Status_Model`
Controlled future workflow statuses only: Not Required, Pending, Approved, Rejected, Returned, Escalated, Withdrawn and Expired.

### `Process_Output_Objects`
Maps each process to the master/current-state object or future Phase 3 event it creates or changes.

### `Control_Evidence_Types`
Defines evidence classes that future operational controls may produce.

### `Relationship_Reference`
Compact AI-friendly join/navigation layer across process, category, owner, authority, system, output object and specialist review requirements.

### `Source_Mappings`
Records the upstream authoritative and structural-reference files used to construct this architecture.

### `Architecture_Notes`
Documents major assumptions, boundaries and governance decisions.

### `Data_Dictionary`
Field-level documentation for the complete workbook.

---

## Relationship with existing Sales architecture

This workbook governs **how changes/actions are controlled**. It does not redefine the business objects owned by the preceding Sales workbooks.

Examples:

- Customer Account architecture owns the customer commercial master; this workbook defines the customer-setup/change process and controls.
- Assortment architecture owns customer-SKU listings; this workbook defines listing approval/control processes.
- Pricing architecture owns prices, discounts, rebates and commercial-term structures; this workbook defines authority and control around changes/exceptions.
- Customer Agreements owns agreement scope and commitments; this workbook defines executable approval/control requirements.
- Demand Planning owns demand-planning rules; this workbook defines preparation, consensus approval and forecast-override controls.
- Sales Order & Customer Service owns order/service policy; this workbook defines exception approval and escalation control.

---

## Finance boundary

Finance remains authoritative for:

- customer credit limits and credit decisions;
- payment-term authority;
- accounting treatment;
- rebate accruals and settlements;
- revenue/accounting controls;
- company-wide monetary approval thresholds;
- financial hold/release authority.

Sales may require Finance review but may not replace Finance authority.

`SAUTH-05` is therefore a **reference to Finance control authority**, not a Sales-created financial approval mandate.

---

## Quality and Operations boundaries

Quality remains authoritative for technical product/food-safety decisions, quality holds and technical complaint outcomes.

Production, Procurement/Supply and Logistics remain authoritative for capacity, material supply, physical allocation, fulfilment and delivery execution.

Sales may commercially approve a customer commitment or exception only within its own authority. It cannot make an unavailable product available, release a quality/credit hold, or physically reallocate stock merely through commercial approval.

---

## Current-state versus operational history

This architecture may define:

- process sequence;
- authority class;
- approval requirement;
- threshold rule;
- control requirement;
- possible exception type;
- escalation path;
- evidence requirement.

It does **not** contain:

- approval requests or decisions;
- approver names/timestamps;
- approval comments;
- delegation periods;
- control-test results;
- control failures;
- actual exception cases;
- escalation events;
- audit logs;
- commercial policy violations.

Those belong to Phase 3.

---

## Story neutrality

The architecture deliberately does not seed:

- approval bypasses;
- excessive discounting;
- SoD conflicts;
- unapproved agreements;
- repeated exceptions;
- suspicious customer changes;
- control failures;
- inappropriate Finance/Quality overrides;
- fraudulent or unusual commercial activity.

These remain possible Phase 2 story patterns, but are not present as Phase 1 outcomes.

---

## Recommended AI use

For fast context:

1. read this Markdown file;
2. inspect `Relationship_Reference` and `Sales_Processes`;
3. inspect `Process_Authority_Rules`, `Commercial_Controls` and `Segregation_of_Duties` for governance questions;
4. inspect the relevant upstream Sales workbook for the actual customer/listing/pricing/agreement/planning/order master;
5. inspect HR authority/position sources or specialist-domain architecture where authority crosses domain boundaries.

The Excel workbook is authoritative for the detailed static Sales process/control structures. This Markdown file is a semantic reference for humans and AI.
