# Inbound Logistics & Receiving Architecture

## Purpose

This workbook defines the static **Inbound Logistics & Receiving Architecture** for **HAV Seafood**.

It describes how purchased goods are normally expected to move from approved supplier sources to HAV Seafood's receiving area, how those goods are structurally inspected and documented at receipt, and how accepted or non-conforming material is routed into the existing inventory/storage architecture.

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

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

The workbook defines **what lanes, profiles, requirements and rules exist**. It does not contain shipment, receipt, inspection, customs, putaway or inventory history.

---

## Scope at a glance

The architecture contains:

- **7 reusable inbound lane profiles**;
- **18 supplier inbound lanes** across **11 physical-goods suppliers**;
- **188 supplier-item lane assignments**, covering every sourcing relationship in the current Supplier & Sourcing Architecture;
- **8 receiving profiles**, aligned to the 8 existing inventory-control profiles;
- **26 receiving requirement mappings**;
- **32 putaway/disposition rules**;
- references to the two existing Shared Enterprise logistics partners: `ORG-EXT-012` NorthRoute Cold Chain and `ORG-EXT-013` BlueArc Freight.

The two procurement service suppliers do not receive physical inbound lanes because they provide services rather than stocked goods.

---

## Workbook

### `hav_seafood_supply_chain_inbound_logistics_receiving_v1.xlsx`

### `Inbound_Lane_Profiles`

Defines reusable transport patterns such as:

- domestic chilled seafood;
- domestic frozen seafood;
- Nordic temperature-controlled ingredients;
- Nordic ambient ingredients;
- European/Baltic temperature-controlled ingredients;
- European/Baltic ambient ingredients;
- Nordic packaging freight.

Profiles define transport mode, temperature regime, consolidation principle, import/customs applicability, typical transit-time class, frequency class, carrier arrangement and core transport controls.

These are static expected patterns, not route-performance history.

### `Supplier_Inbound_Lanes`

Defines the normal supplier-origin-to-HAV route structure.

Each lane references:

- an existing `Supplier_ID` / Shared Enterprise external organization;
- supplier origin city and country;
- an inbound lane profile;
- the Shared Enterprise receiving section `LOC-HAV-FAC-RCV`;
- Production Goods-In Dock `FA-002`;
- a preferred logistics partner where appropriate;
- standard transit days;
- normal delivery frequency/window;
- commercial delivery-term/freight-responsibility assumptions imported from the Supplier Governance & Commercial Framework;
- import/customs applicability;
- lane criticality.

A lane is a **static expected route**, not a shipment, booking, container or actual carrier event.

### `Item_Lane_Assignments`

Provides the bridge:

`Supplier-Item Sourcing Relationship -> Inbound Lane -> Receiving Profile -> Primary / Quarantine Storage`

There is one row for every one of the **188** current `Supplier_Item_Sourcing` relationships.

This means preferred and secondary approved sources can use different inbound lanes while keeping the same authoritative `Item_ID`.

The sheet is relational/derived from existing master architecture. It does not redefine suppliers, items, sourcing parameters or storage locations.

### `Receiving_Profiles`

Defines 8 reusable receiving-control patterns corresponding to:

- chilled raw seafood;
- frozen raw seafood;
- temperature-controlled ingredients;
- allergen-controlled ambient ingredients;
- standard ambient ingredients;
- food-contact packaging;
- printed SKU-specific packaging;
- secondary/tertiary packaging.

Profiles define whether receipt requires identity, quantity, lot, date/shelf-life, temperature, visual condition, packaging integrity, origin/traceability documents, COA/conformance evidence and artwork/version checks.

They also identify the operational receiving role, Quality review role, ERP/QMS relationship and initial stock-status treatment.

Technical acceptance limits remain in the authoritative Production/Quality sources.

### `Receiving_Requirement_Map`

Maps receiving profiles and selected materials to concrete static receiving requirements.

The map references existing Quality requirements such as:

- `QR-001` seafood lot traceability;
- `QR-002` chilled seafood receiving condition;
- `QR-003` frozen seafood receiving temperature;
- `QR-004` incoming packaging integrity;
- `QR-005` incoming ingredient lot/allergen verification;
- `QR-006` / `QR-007` histamine controls;
- `QR-008` herring parasite-treatment evidence;
- `QR-009` salmon parasite-risk evidence;
- `QR-010` cooked shrimp microbiological status.

Those Quality records remain authoritative. This sheet only explains their receiving applicability.

### `Putaway_Disposition_Rules`

Defines the allowed structural outcomes after receipt:

- pending inspection/release;
- accepted/released;
- quality hold/investigation;
- rejected/non-conforming.

Rules reuse stock statuses from the Supply Planning & Inventory Framework and route material to:

- `SL-INSP-01` during initial inspection;
- the item's existing primary storage location after acceptance;
- the item's existing quarantine location when held or rejected.

No actual inventory movement is represented.

### `Architecture_Notes`

Summarizes key scope, ownership and boundary decisions.

### `Data_Dictionary`

Defines workbook fields, datatype, relational role, ownership and authoritative status for AI and human interpretation.

---

## Core relationships

At a high level:

`Shared Enterprise External Organization`

`-> Procurement Supplier`

`-> Supplier-Item Sourcing Relationship`

`-> Inbound Lane`

`-> HAV Goods-In / Incoming Inspection`

`-> Receiving Profile + Receiving Requirements`

`-> Stock Status`

`-> Primary Storage or Quarantine Storage`

Another useful view is:

`Supplier + Item -> Lane -> Receipt Rules -> Putaway Rule -> Inventory Control`

---

## Ownership boundaries

### Shared Enterprise

Remains authoritative for:

- external organization identity;
- logistics-partner identity;
- enterprise locations;
- countries and shared reference data;
- system identity.

### Procurement

Remains authoritative for:

- supplier sourcing relationships;
- source priority;
- supplier standard lead time;
- commercial freight/delivery assumptions.

### Supply Chain / Logistics

This workbook owns:

- inbound lane profiles;
- supplier inbound lane structure;
- item-to-lane assignments;
- receiving-profile structure;
- receiving applicability mapping;
- putaway/disposition routing rules.

### Production

Remains authoritative for:

- technical item specifications;
- physical receiving/work-center structure;
- detailed storage locations;
- storage compatibility;
- item storage/handling requirements;
- raw-material/ingredient/packaging technical receipt conditions.

### Quality & Food Safety

Remains authoritative for:

- detailed technical acceptance criteria;
- sampling plans;
- HACCP/control points;
- supplier/lot quality evidence;
- actual inspection and release decisions.

### Finance

Later Finance architecture should own:

- freight accounting;
- landed-cost treatment;
- duties/taxes accounting;
- supplier/freight invoice treatment.

---

## Logistics-partner boundary

The Shared Enterprise Architecture already contains two synthetic logistics partners:

- `ORG-EXT-012` — NorthRoute Cold Chain;
- `ORG-EXT-013` — BlueArc Freight.

They are used here as **preferred network partners** for applicable imported lanes.

This does not mean every later shipment must use them. Actual carrier selection, booking, tracking and performance belong to Phase 3 operational data.

Domestic Faroese seafood lanes remain supplier-arranged under the current commercial assumptions and therefore do not require a dedicated carrier identity in this architecture.

---

## Customs/import boundary

Non-Faroese inbound lanes are structurally marked as requiring import/customs documentation for entry to the Faroe Islands.

The architecture does **not** define:

- customs declarations;
- tariff codes;
- duties;
- customs brokers;
- clearance events;
- border delays;
- import charges.

Those can be generated later if useful to Phase 3 stories and logistics/finance datasets.

---

## Explicit operational exclusions

This workbook does not contain:

- purchase orders;
- shipment records;
- advance shipping notices;
- freight bookings;
- actual carrier assignments;
- vehicle/container numbers;
- tracking/GPS events;
- dispatch dates;
- estimated or actual arrival events;
- customs declarations or clearance events;
- actual delivery times;
- goods receipts;
- received quantities;
- receipt temperatures;
- damaged-delivery events;
- shortages or over-deliveries;
- receiving inspection results;
- quality test results;
- rejected-delivery events;
- putaway transactions;
- inventory movements;
- dock queues;
- freight invoices;
- demurrage;
- actual transit-time or OTIF performance.

These belong to **Phase 3 — Operational Dataset** after business stories are designed.

---

## Story neutrality

The architecture deliberately does not seed:

- late imported ingredients;
- damaged packaging loads;
- seafood temperature failures;
- histamine failures;
- customs delays;
- carrier failures;
- receiving congestion;
- rejected lots;
- supplier OTIF patterns;
- excess freight costs.

Such patterns should be deliberately selected in Phase 2.

---

## Systems relationship

The architecture uses the existing system landscape:

- `ESYS-001 Core ERP` — operational/commercial receipt and inventory transaction system;
- `ESYS-003 Quality Management System` — quality inspection, release, supplier-quality and related evidence.

The Systems Landscape and System/Data Ownership Model remain authoritative for system identity and source-of-record decisions.

---

## Identifier conventions

New local identifiers in this workbook:

- `ILP-*` — inbound lane profiles;
- `ILN-*` — supplier inbound lanes;
- `ILA-*` — supplier-item lane assignments;
- `RCP-*` — receiving profiles;
- `RRM-*` — receiving requirement mappings;
- `PDR-*` — putaway/disposition rules.

Existing `ORG-EXT-*`, item IDs, `SRC-*`, `LOC-*`, `FA-*`, `SL-*`, `INVP-*`, `STK-*`, `QR-*`, `CP-*`, role IDs and system IDs are preserved.

---

## Recommended AI use

For quick analysis:

1. read this Markdown file;
2. inspect `Supplier_Inbound_Lanes` for supplier-level route structure;
3. inspect `Item_Lane_Assignments` to join an item/source to its route and receiving profile;
4. inspect `Receiving_Profiles` and `Receiving_Requirement_Map` for receipt controls;
5. inspect `Putaway_Disposition_Rules` for the handoff into inventory;
6. consult authoritative Procurement, Production, Quality or Shared Enterprise files whenever precise source attributes are needed.

---

## Use in Phase 3

Later operational datasets can generate:

`Purchase Order -> Supplier Dispatch -> Shipment -> Inbound Lane -> Delivery -> Goods Receipt -> Receiving Inspection -> Quality Disposition -> Putaway -> Inventory Movement`

using the stable IDs and rules defined here.

Actual data should preserve the distinction between the **expected architecture** defined here and the **events that actually occur**.
