# HAV Seafood — Logistics Distribution Network & Carrier Framework

## Purpose

This workbook defines the static **outbound Logistics & Distribution network and carrier architecture** for **HAV Seafood**.

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

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

The workbook describes how finished goods are structurally connected from HAV Seafood's dispatch area to customer delivery locations through transport service classes, outbound lanes and eligible carriers. It intentionally contains **no operational shipment history**.

## Architecture scope at a glance

The current architecture contains:

- **4 current primary customer ship-to locations**, one for each current customer account;
- **2 current outbound logistics partners**, both reused from Shared Enterprise / existing inbound logistics architecture;
- **5 reusable transport service classes**;
- **10 carrier-to-service capability relationships**;
- **12 static outbound lanes**, defined by customer destination and temperature regime;
- **24 lane-to-carrier eligibility relationships**;
- **10 static outbound delivery requirements**;
- **73 derived Customer + SKU logistics relationships**, corresponding to the existing active Sales customer/SKU listings.

The design is intentionally compact and proportionate to HAV Seafood's size.

## Principal model

At a high level:

`Sales Customer -> Logistics Ship-To -> Outbound Lane -> Transport Service -> Eligible Carrier`

The product-facing relationship is:

`Production SKU -> Sales Customer/SKU Listing -> Storage Regime -> Default Outbound Lane -> Default Transport Service`

The future Phase 3 execution chain will be conceptually:

`Sales Order -> Shipment -> Handling Unit -> Transport Booking -> Dispatch -> Delivery -> POD / Exception / Return`

This workbook defines only the static structures required for that future execution chain.

## Workbook sheets

### `Architecture_Overview`
Provides a compact purpose, scope and architecture-count overview. Counts are derived from the detailed sheets.

### `Ship_To_Locations`
Defines the Logistics-owned delivery extension for the four current customer accounts.

Each current ship-to reuses an existing Shared Enterprise external-organization and external-address identity. The current shared address master contains city-level identities only, so this workbook does not invent street or postal data.

The important distinction is:

`Sales Customer_ID != Logistics Ship_To_ID`

Additional receiving sites can therefore be introduced later without redefining the customer account.

### `Carrier_Extensions`
Defines outbound-logistics capability extensions for the two existing Shared Enterprise logistics partners:

- `LCAR-001` — NorthRoute Cold Chain;
- `LCAR-002` — BlueArc Freight.

The legal/external organization identity remains owned by Shared Enterprise. Logistics owns only the outbound capability classification in this workbook.

### `Transport_Service_Classes`
Defines five reusable service classes:

- standard chilled groupage;
- standard frozen groupage;
- standard ambient food-grade groupage;
- dedicated refrigerated full load;
- expedited temperature-controlled service.

The final two are eligible structural alternatives, not normal shipment events or standing capacity commitments.

### `Carrier_Service_Capability`
Defines which carriers are structurally eligible for which transport service classes and their normal preference classification.

Capability does **not** mean that capacity has been booked, quoted or guaranteed.

### `Outbound_Lanes`
Defines the authoritative static outbound lane master.

Each of the four current customer destinations has separate:

- chilled;
- frozen;
- ambient

lanes, producing **12 active lanes**.

All lanes originate from `LOC-HAV-FAC-FIN — Finished Goods & Dispatch`.

Transit-day, frequency and delivery-window values are **synthetic internal planning assumptions** for the fictional architecture. They are not historical performance measurements or researched real-world service commitments.

### `Lane_Carrier_Applicability`
Maps each outbound lane to primary and secondary eligible carriers.

The relationship distinguishes planned preference from actual carrier selection. Actual booking and capacity confirmation belong to Phase 3.

### `Delivery_Requirements`
Defines static requirements such as:

- delivery documentation;
- customer-order reference;
- traceability;
- proof of delivery;
- export/customs documentation;
- temperature evidence;
- refrigerated-equipment suitability;
- delivery appointments;
- advance shipment information;
- handling-unit identification.

These are requirement rules, not actual compliance records.

### `Customer_SKU_Logistics`
Provides a **derived, non-authoritative bridge** across Sales, Production and Logistics.

For each existing active Customer + SKU listing it shows:

- current default ship-to;
- product storage regime;
- Production-owned temperature and shelf-life references;
- case/pallet references;
- default outbound lane;
- default service class;
- temperature-evidence requirement.

It must never be interpreted as creating a customer listing or overriding Sales or Production master data.

### `Position_Responsibility`
Defines position-based responsibility across Logistics, Sales, Procurement, Quality and IT.

HR remains authoritative for positions, position seats and incumbency. No employee-specific activity is stored here.

### `System_Data_Mapping`
Maps key Logistics data objects to the existing enterprise system landscape.

Important design decision:

> **No dedicated TMS is invented.**

The architecture primarily uses `ESYS-001 Core ERP` for operational master/reference structures and `ESYS-007 Microsoft 365` for controlled documents, with existing Sales/Quality systems referenced where appropriate.

`ESYS-011 Temperature & Cold-Chain Monitoring` remains a HAV Seafood facility-monitoring system and is not treated as an external carrier telematics platform.

### `Source_Precedence`
Defines authoritative ownership and source precedence for customer, organization, address, market, system, location, SKU, inbound logistics, HR and Logistics entities.

### `Architecture_Notes`
Captures major architecture assumptions, boundaries, design choices and Phase 1 exclusions.

### `Data_Dictionary`
Provides field-level definitions, datatype guidance, key/reference interpretation and authority/lineage guidance for every authored sheet.

## Relationship with Shared Enterprise Architecture

Shared Enterprise remains authoritative for:

- external organization identity;
- external address identity;
- countries and markets;
- enterprise locations;
- enterprise systems;
- shared identifier/reference structures.

This workbook reuses the existing customer and carrier external-organization IDs rather than creating competing organization masters.

## Relationship with Sales & Commercial Architecture

Sales remains authoritative for:

- `Customer_ID`;
- customer account status and commercial organization;
- market/channel/territory relationships;
- customer/SKU listings;
- orderability;
- customer orders and commercial fulfilment rules.

Logistics owns the physical delivery extension and outbound network design.

The boundary is:

`Sales Order / Customer Requirement -> Logistics Shipment / Delivery Execution`

The latter operational objects will be generated only in Phase 3.

## Relationship with Production Architecture

Production remains authoritative for:

- SKU identity;
- technical storage temperature;
- shelf life;
- pack/case/pallet definitions;
- detailed finished-goods storage locations.

This workbook references those attributes when determining storage regime and default outbound service.

## Relationship with Procurement & Supply Chain Architecture

Procurement & Supply Chain remains authoritative for:

- supplier inbound lanes;
- inbound transport design;
- receiving;
- putaway;
- supplier/logistics commercial structures where applicable.

This workbook deliberately does **not** copy the inbound lane architecture.

It reuses the two existing logistics partners already seeded in the inbound architecture, preserving common enterprise identity and terminology.

## Relationship with HR & Organization Architecture

HR remains authoritative for:

- roles;
- positions;
- position seats;
- incumbency.

Logistics responsibilities reference positions such as Warehouse & Logistics Supervisor, Customer Service & Order Coordinator, Procurement Manager, Quality & Food Safety Manager and IT & Systems Manager.

## Quality boundary

Quality remains authoritative for the technical meaning and review of temperature/release requirements where food-safety or technical product controls are involved.

Logistics owns the transport design and future execution records, but does not independently redefine technical Quality requirements.

## Finance / commercial boundary

This workbook does not define:

- freight rates;
- carrier price lists;
- carrier invoices;
- payment terms;
- freight accruals;
- transport claims accounting;
- company-wide monetary approval thresholds.

Those belong to Procurement/Finance and later operational datasets as appropriate.

## Operational data intentionally excluded

This folder does **not** contain:

- shipment records;
- shipment lines;
- transport bookings;
- carrier confirmations;
- pallet/handling-unit records;
- actual picked or loaded quantities;
- dispatch events;
- tracking events;
- actual delivery dates/times;
- proof-of-delivery files;
- actual transit times;
- freight rates or costs;
- freight invoices;
- customs declarations;
- temperature readings/evidence records;
- delays;
- delivery failures;
- damage;
- claims;
- returns;
- carrier scorecards;
- OTIF or transport-performance history.

Those belong to Phase 3 after the Phase 2 stories are selected.

## Story neutrality

The architecture does not deliberately seed:

- carrier deterioration;
- transport delays;
- temperature excursions;
- lost or damaged shipments;
- customs problems;
- delivery appointment failures;
- chronic late delivery;
- carrier-capacity shortage;
- freight-cost increases;
- carrier disputes.

The primary/secondary carrier structure exists as normal business architecture and should not itself be treated as a story.

## Recommended AI use

For fast navigation:

1. Read this Markdown file.
2. Inspect `Architecture_Overview`.
3. For destination questions, inspect `Ship_To_Locations`.
4. For carrier/service questions, inspect `Carrier_Extensions`, `Transport_Service_Classes` and `Carrier_Service_Capability`.
5. For route questions, inspect `Outbound_Lanes` and `Lane_Carrier_Applicability`.
6. For a Customer + SKU question, inspect `Customer_SKU_Logistics`, then verify the authoritative Sales and Production source if needed.
7. For ownership or system questions, inspect `Source_Precedence` and `System_Data_Mapping`.

## Overall role of this architecture

Together, these structures form the **static outbound distribution network and carrier layer** for HAV Seafood.

They connect existing customers and Production SKUs to current delivery locations, temperature-specific outbound lanes, transport services, eligible carriers, delivery requirements, responsibility and enterprise systems without creating shipment history or duplicating upstream masters.

This provides the stable foundation required for later synthetic shipment, dispatch, carrier, tracking, delivery, exception and transport-performance data.
