# Procurement Process & Control Framework

## Purpose

This workbook defines the static **Procurement Process & Control Framework** for **HAV Seafood**. It is part of **Phase 1 — Business Architecture** and describes how procurement activities are structurally initiated, reviewed, approved, controlled and escalated.

It does **not** contain actual procurement transactions or workflow history.

The project sequence remains:

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

---

## Workbook

`hav_seafood_procurement_process_control_framework_v1.xlsx`

The workbook contains:

- **19 procurement process definitions**;
- **119 static process steps**;
- **19 process-level approval authority rules**;
- **26 internal control rules**;
- **10 exception and escalation rules**.

---

## Core model

The framework separates:

`Business Need / Trigger -> Process -> Process Steps -> Review / Approval -> Controlled Execution`

with cross-cutting controls:

`Segregation of Duties + Specialist Review + Finance Authority + Exception / Escalation`

The framework defines **what should happen and who is structurally authorized**, not what happened historically.

---

## Sheets

### `Procurement_Processes`

Master catalog of 19 Procurement processes spanning supplier governance, sourcing, commercial agreements, requisitions, purchase orders, exceptions, supply escalation and supplier/master-data control.

The core process IDs are `PRC-001` through `PRC-019`.

### `Process_Steps`

Defines 119 ordered static workflow steps. A step identifies the responsible role/type, system context, whether approval is required and whether the step is required or conditional.

These are process definitions only; there are no timestamps, users, decisions or execution records.

### `Approval_Authority`

Maps each process to the existing enterprise/HR authority model rather than creating a second Procurement hierarchy.

Important reused authorities include:

- `HAL-04` — Department / Functional Manager; Procurement Manager `POS-PROC-MGR` / `R032`;
- `HAL-06` — Finance / Budget Authority; Finance & Administration Manager `POS-FIN-MGR` / `R044`;
- `HAL-07` — Specialist Control Authority; used for Quality/technical control through `POS-QUAL-MGR` / `R023`;
- `HAL-08` — Executive Authority; Managing Director `POS-EXEC-MD` / `R031`;
- `HAL-09` — Independent Review Authority for conflicts/unavailable approvers.

No Procurement-specific monetary thresholds are invented here. Future Finance Architecture remains authoritative for financial thresholds and payment-term master data.

### `Control_Rules`

Defines 26 static procurement controls including:

- self-approval prohibition;
- supplier creator/approver separation;
- approved supplier/source checks;
- suspended supplier blocking;
- independent Quality approval;
- material PO amendment reapproval;
- emergency purchase retrospective review;
- controlled non-approved-supplier exceptions;
- sensitive supplier-master verification;
- purchasing/receiving/invoice separation;
- agreement document control;
- Finance and Shared Enterprise ownership boundaries.

These controls are deliberately useful for later synthetic stories, but **no control failures are seeded in Phase 1**.

### `Exception_Escalation_Rules`

Defines 10 controlled exception types such as emergency shortages, unavailable preferred sources, non-approved suppliers, sole-source decisions, commercial-term exceptions, substitutions, delivery failures, documentation deficiencies, Quality restrictions and approver conflicts.

The sheet defines permitted temporary action and follow-up requirements, not actual exception cases.

### `Architecture_Notes`

Records the key architectural boundaries and system/ownership decisions.

### `Data_Dictionary`

Defines the meaning, logical type and ownership/origin of workbook fields.

---

## Relationship to other Procurement & Supply Chain architecture

This workbook orchestrates rather than duplicates the previous architecture:

`Supplier & Sourcing Architecture`

-> defines which suppliers, categories, items and sources are valid.

`Supplier Governance & Commercial Framework`

-> defines supplier qualification and commercial structures.

`Supply Planning & Inventory Framework`

-> defines replenishment and stock-control policy.

`Inbound Logistics & Receiving Architecture`

-> defines inbound lanes, receiving requirements and putaway/disposition rules.

`Procurement Process & Control Framework`

-> defines **who may initiate, review, approve, execute or escalate procurement actions and which controls apply**.

---

## System boundaries

### Core ERP — `ESYS-001`

The Shared Enterprise architecture already defines the Core ERP as the key system for supplier commercial master data, purchase orders, receipts/inventory context and Procurement transaction processing. Future purchase orders are Procurement-owned ERP transactions.

### Quality Management System — `ESYS-003`

QMS remains authoritative for supplier-quality evidence, certificates, audits, technical approval and supplier-quality restrictions. Procurement references those decisions rather than recreating Quality records.

### Microsoft 365 — `ESYS-007`

M365 supports documents and communication such as RFQs, supplier correspondence, commercial agreements and approval evidence. Storage of a document in M365 does not make M365 the authoritative master/transaction system.

---

## Ownership boundaries

- **Shared Enterprise** owns external-organization identity, enterprise roles/positions, systems and common identifiers.
- **Procurement** owns procurement process design, supplier commercial/procurement controls, sourcing decisions and purchase-order process architecture.
- **Quality & Food Safety** owns technical supplier-quality approval, certificates, audits and quality restrictions.
- **Finance** owns supplier invoice accounting, enterprise financial approval/threshold rules and payment-term master data.
- **Warehouse & Logistics** owns physical goods receipt and enterprise inventory movement execution.
- **HR / Shared Enterprise authority architecture** remains authoritative for authority levels, position-based authority and delegation principles.

---

## Explicit exclusions

This workbook contains no operational/historical records such as:

- purchase requisitions;
- purchase orders or PO lines;
- PO amendments;
- RFQs or quotations;
- supplier selection events;
- signed agreements;
- approval requests or decisions;
- approver names;
- timestamps or comments;
- emergency purchases;
- supplier exception cases;
- supplier suspensions/reactivations as events;
- delivery escalations;
- workflow/audit logs;
- actual financial commitments;
- control breaches;
- fraud or policy violations.

Those belong to **Phase 3 — Operational dataset generation** after business stories have been selected.

---

## Important architectural decisions

### Authority reuse

Procurement does not create an independent approval hierarchy. Existing authority levels and management positions are reused. Actual approver identity would be resolved from current incumbency and delegation at transaction time.

### No Finance thresholds yet

This framework records where Finance or Executive review is required, but does not invent company-wide procurement value thresholds. Those should be introduced deliberately in the future Finance Architecture.

### Specialist authority remains independent

Procurement cannot approve supplier/item technical suitability on behalf of Quality when a Quality approval is required.

### Process architecture is not workflow history

`Process_Steps` defines expected sequencing and responsibilities. Later event datasets may include deviations, delays, bypasses and exceptions, but those are not part of the architecture.

---

## Use in Phase 3

Later operational Procurement datasets should use these IDs to generate realistic:

- requisition and PO workflows;
- approval events;
- RFQ/sourcing cases;
- commercial agreement approvals;
- emergency purchases;
- source/substitution exceptions;
- supplier suspension/reactivation cases;
- master-data changes;
- approval audit trails;
- control exceptions and escalation histories.

Generated events should respect the static authority and control rules unless a Phase 2 story deliberately requires a deviation.

---

## Source architecture used

The framework was built against the supplied current versions of:

- `hav_seafood_procurement_supplier_sourcing_architecture_v1.xlsx`;
- `hav_seafood_procurement_supplier_governance_commercial_framework_v1.xlsx`;
- `hav_seafood_supply_planning_inventory_framework_v1.xlsx`;
- `hav_seafood_supply_chain_inbound_logistics_receiving_v1.xlsx`;
- `hav_seafood_company_organization_structure_v1.xlsx`;
- `hav_seafood_enterprise_job_roles_job_families_v1.xlsx`;
- `hav_seafood_enterprise_systems_landscape_v1.xlsx`;
- `hav_seafood_system_data_ownership_model_v1.xlsx`;
- `hav_seafood_hr_process_approval_authority_v1.xlsx`.

Together, these references ensure this Procurement framework extends the existing enterprise model rather than redefining roles, systems, authority, supplier identity or transaction ownership.
