# HAV Seafood — Logistics Process, Service & Control Framework

## Purpose

This workbook defines the static **Logistics Process, Service & Control Architecture** for HAV Seafood. It is the governance layer above the existing Logistics network/carrier and outbound fulfilment/dispatch frameworks.

It belongs to **Phase 1 — Business Architecture** and contains object definitions, lifecycle statuses, permitted transitions, booking rules, delivery-service rules, exception/return taxonomies, process design, authority mappings, controls, escalation structures and service-metric definitions. It contains **no operational shipment history**.

The core lifecycle is:

`Dispatch-Ready Fulfilment -> Shipment -> Transport Booking -> Loading -> Dispatch -> In Transit -> Delivery -> Proof of Delivery -> Closure`

with exception branches:

`Shipment / Delivery -> Logistics Exception -> Resolution / Escalation`

and reverse-logistics branches:

`Delivery / Complaint -> Return Authorization -> Return Shipment -> Controlled Receipt -> Quality / Commercial Disposition`

## Architecture scope at a glance

- **12 conceptual Logistics operational objects**;
- **12 shipment lifecycle statuses**;
- **20 permitted shipment-status transitions**;
- **12 transport-booking rules**;
- **15 combined delivery-service/completion/POD rule records**;
- **20 Logistics exception types**;
- **9 return-reason/handling rules**;
- **22 Logistics processes**;
- **110 static process steps**;
- **6 Logistics authority classes** mapped onto the existing HR authority backbone;
- **24 consolidated Logistics controls**;
- **8 segregation-of-duties controls**;
- **5 escalation classes**;
- **10 service-metric definitions**.

## Key architecture decisions

### The Sales Order remains separate from the Shipment

The Sales architecture already defines `OST-CONFIRMED` as the confirmed executable commercial order and `OST-RELEASED` as the handoff into Logistics fulfilment. This workbook defines the separate Shipment lifecycle and does not turn the Sales Order into a Shipment.

### Existing Logistics master layers remain authoritative

`hav_seafood_logistics_distribution_network_carrier_framework_v1.xlsx` remains authoritative for:

- ship-to locations;
- carriers;
- transport-service classes;
- outbound lanes;
- lane/carrier eligibility;
- delivery requirements.

`hav_seafood_logistics_outbound_fulfilment_dispatch_framework_v1.xlsx` remains authoritative for:

- fulfilment profiles;
- inventory eligibility;
- rotation/allocation;
- picking;
- handling-unit types;
- staging;
- consolidation;
- dispatch-readiness requirements.

This workbook starts with **shipment governance and execution design** rather than duplicating those masters.

### No dedicated TMS or WMS is introduced

The existing System & Data Ownership Model assigns both:

- `DOBJ-094 Warehouse Pick / Dispatch`; and
- `DOBJ-095 Shipment / Dispatch Record`

to **`ESYS-001 Core ERP`** as the authoritative system.

Carrier booking/tracking may involve external carrier portals, email or files, but HAV Seafood does not gain an invented dedicated TMS in this architecture.

### Cross-functional authority is preserved

Logistics owns physical shipment execution. It does not take over authority owned elsewhere:

- **Sales** owns customer/commercial order decisions and customer-facing complaint/service handling;
- **Quality** owns product release, technical complaint investigation, product-integrity decisions and technical return disposition;
- **Finance** owns freight-invoice/payment, credit and financial settlement authority;
- **Procurement** supports carrier commercial/sourcing relationships;
- **HR** owns positions, incumbency and the enterprise authority backbone.

The Logistics Supervisor (`POS-LOG-SUP`) is the routine operational authority. Material operational exceptions can escalate to the Production Manager (`POS-PROD-MGR`), because the existing organization has the Logistics Supervisor reporting to that position.

## Workbook sheets

### `Architecture_Overview`
High-level purpose, formulas for key architecture counts, system boundaries and cross-domain ownership.

### `Shipment_Object_Model`
Defines the conceptual future objects: Sales Order, Shipment, Shipment Line, Handling Unit, Transport Booking, Dispatch, Tracking Event, Delivery, POD, Logistics Exception, Return Authorization and Return Shipment.

### `Shipment_Lifecycle_Status`
Defines the static Shipment lifecycle from Planned through Closed/Cancelled.

### `Shipment_Status_Transitions`
Defines permitted status transitions and approval requirements. Actual status events belong to Phase 3.

### `Transport_Booking_Rules`
Defines eligibility, carrier preference, temperature compatibility, cutoffs, change control and cross-domain commercial boundaries for bookings.

### `Delivery_Service_Rules`
Compact combined sheet defining delivery-service classes, delivery-completion rules and accepted POD principles.

### `Logistics_Exception_Types`
Defines 20 reusable exception types across dispatch, carrier, transport and delivery categories.

### `Exception_Routing_Rules`
Maps exception type/severity to Logistics ownership, Sales/Quality/Finance involvement and escalation.

### `Return_Rules`
Defines return reasons, whether physical return is required, authorization/Quality review, return transport conditions and disposition boundaries.

### `Logistics_Processes`
Defines 22 Logistics processes from shipment creation through delivery closure and reverse-logistics handoff.

### `Logistics_Process_Steps`
Provides 110 reusable static process steps. These are process design, not workflow history.

### `Logistics_Authority_Classes`
Defines six Logistics-specific authority classes mapped to the existing HR `HAL-*` authority model.

### `Position_Authority_Map`
Maps existing HR positions to Logistics authority capabilities. No named employee activity is stored.

### `Process_Authority_Rules`
Defines required authority/review for each Logistics process and preserves Sales, Quality, Finance and Executive review boundaries.

### `Logistics_Controls`
Defines 24 preventive/detective/cross-domain controls around shipment creation, booking, dispatch, delivery, exceptions and returns.

### `Segregation_of_Duties`
Defines eight proportionate SoD rules for HAV Seafood's small organization.

### `Escalation_Classes`
Defines routine, supervisory, cross-functional, material/executive and critical product/safety escalation classes.

### `Service_Metric_Definitions`
Defines ten future Logistics service metrics such as on-time dispatch, on-time delivery, OTIF, collection punctuality, POD completeness and return rate. It defines metric semantics only — no targets or results.

### `System_Process_Mapping`
Maps Logistics objects/processes to the existing enterprise system landscape.

### `Cross_Domain_Interfaces`
Defines major handoffs between Sales, Logistics, Fulfilment, Distribution Network, Quality, Finance, Procurement and carriers.

### `Source_Precedence`
States which workbook/domain wins when concepts cross architecture boundaries.

### `Architecture_Notes`
Records the major design decisions and conceptual boundaries.

### `Data_Dictionary`
Field-level reference across the workbook.

## Important conceptual boundaries

`Sales Order != Shipment`

`Shipment != Transport Booking`

`Shipment != Dispatch`

`Dispatch != Delivery`

`Delivery != Proof of Delivery`

`Exception Type != Exception Case`

`Return Reason != Root Cause`

`Return Authorization != Credit Note`

`Physical Return != Quality Disposition`

`Process Rule != Process Event`

`Control Requirement != Control Execution`

`Authority != Approval Event`

`Metric Definition != Metric Result`

## Operational data intentionally excluded

This workbook contains no actual:

- Shipment or Shipment Line records;
- handling-unit instances;
- transport bookings or carrier confirmations;
- loading or dispatch events;
- tracking events;
- shipment-status history;
- delivery events;
- POD files;
- transport delays or damage incidents;
- temperature excursions;
- customer refusals;
- exception cases;
- return authorizations or return shipments;
- approval events;
- escalation events;
- control executions/failures;
- freight claims, invoices or payments;
- OTIF or other metric results.

Those belong to Phase 3 after the business stories have been deliberately selected.

## Story neutrality

The architecture does not deliberately seed late deliveries, carrier deterioration, damage trends, temperature failures, high return rates, customer refusals, missing POD, approval bypasses or similar outcomes. Those patterns should be introduced only during Phase 2 story design and Phase 3 data generation.

## Recommended AI use

For fast context:

1. read this Markdown file;
2. inspect `Shipment_Object_Model` and `Shipment_Lifecycle_Status` for object/lifecycle questions;
3. inspect `Logistics_Processes` / `Logistics_Process_Steps` for workflow questions;
4. inspect `Logistics_Exception_Types`, `Exception_Routing_Rules` and `Return_Rules` for exception/reverse-logistics questions;
5. inspect `Process_Authority_Rules`, `Logistics_Controls` and `Segregation_of_Duties` for governance questions;
6. consult the Network, Fulfilment, Sales, Quality, HR or System/Data Ownership source whenever the underlying fact belongs there.

## Source files used

- `hav_seafood_logistics_distribution_network_carrier_framework_v1.xlsx`
- `hav_seafood_logistics_outbound_fulfilment_dispatch_framework_v1.xlsx`
- `hav_seafood_sales_order_customer_service_framework_v1.xlsx`
- `hav_seafood_sales_process_authority_commercial_control_v1.xlsx`
- `hav_seafood_hr_reference_tables_v1.xlsx`
- `hav_seafood_hr_process_approval_authority_v1.xlsx`
- `hav_seafood_shared_enterprise_reference_v1.xlsx`
- `hav_seafood_system_data_ownership_model_v1.xlsx`
- `seafood_quality_food_safety_requirements_v1.xlsx`
