# HAV Seafood — Tax, Currency & Financial Documents Framework

## Purpose

This workbook defines the static **Tax, Currency & Financial Documents** architecture for **HAV Seafood**.

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

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

The workbook defines how financial transactions are structurally interpreted through currencies, exchange-rate classes, synthetic tax treatment, financial document types, document numbering, lifecycle states, correction/reversal relationships, source-business-object interfaces, and Finance system ownership.

It intentionally contains **no operational financial history**.

## File

`hav_seafood_finance_tax_currency_document_framework_v1.xlsx`

## Core model

`Business Source Object`

`-> Financial Document Type`

`-> Currency + Tax Treatment`

`-> Posting Class`

`-> GL / Subledger`

Correction and lifecycle logic are modeled separately:

`Financial Document -> Status Model / Transition Rules`

`Financial Document -> Correction / Reversal Relationship -> Related Financial Document`

## Architecture scope at a glance

- **4 transaction currencies**: DKK, EUR, SEK and NOK;
- **5 exchange-rate types**;
- **12 currency-conversion rules**;
- **8 tax categories**;
- **8 tax codes**;
- **8 tax-determination rules**;
- **7 tax-to-GL mapping rows**;
- **27 financial document types**;
- **27 document-number series**;
- **10 reusable financial-document statuses**;
- **16 permitted status transitions**;
- **27 document requirement profiles**;
- **14 correction/reversal relationship rules**;
- **16 cross-domain source-to-Finance interfaces**.

These are static architecture counts, not transaction counts.

## Workbook sheets

### `Finance_Currency_Config`

Defines the Finance currency environment for `COMP-HAV` and `LED-001`.

The primary functional, accounting and reporting currency is **DKK**. Foreign-currency transactions are structurally permitted. Exchange-rate value history is deliberately excluded.

### `Transaction_Currencies`

Extends the Shared Enterprise currency reference with Finance applicability.

Current currency identities are:

- `DKK` — Danish krone;
- `EUR` — Euro;
- `SEK` — Swedish krona;
- `NOK` — Norwegian krone.

Shared Enterprise remains authoritative for the currency code, name and decimal precision.

### `Exchange_Rate_Types`

Defines five exchange-rate usage classes:

- transaction accounting rate;
- month-end closing rate;
- reporting average rate;
- budget rate;
- approved manual exception rate.

These are **rate types**, not actual dated exchange rates.

### `Currency_Conversion_Rules`

Defines which rate type should normally be used for customer invoices, supplier invoices, settlements, open-item remeasurement, foreign-currency bank remeasurement, reporting and planning.

It references the existing `PCL-*` posting classes from the Accounting Foundation rather than redefining them.

### `Tax_Categories`

Defines high-level tax-accounting classifications such as standard output tax, recoverable input tax, zero-rate output, non-recoverable input, exempt, outside-scope, cross-border self-assessed treatment and tax correction.

### `Tax_Codes`

Defines eight Finance tax codes, including synthetic 25% domestic and cross-border treatment used for later dataset generation.

**Important boundary:** these tax rates and tax-determination rules are fictional internal HAV Seafood architecture. They are **not statements of Faroese, Nordic, EU or international tax law**.

### `Tax_Determination_Rules`

Defines static rules for choosing a tax code based on transaction side, domestic/cross-border classification, country, party and transaction/document class.

No actual tax calculation or tax event is stored.

### `Tax_GL_Mappings`

Maps tax accounting to the existing Accounting Foundation accounts including:

- `GL-1330` — Indirect Tax Receivable;
- `GL-2140` — Indirect Tax Payable.

The GL account master remains authoritative in the Accounting Foundation workbook.

### `Financial_Document_Types`

Defines 27 controlled financial document types spanning:

- customer billing and receivables;
- supplier invoices and payables;
- banking/cash;
- general ledger journals;
- FX and tax adjustments;
- inventory/production accounting;
- fixed assets;
- payroll accounting interface.

A **financial document type is not an actual financial document**.

### `Document_Number_Series`

Defines one current internal number-series configuration for each financial document type.

Important distinction:

`External Supplier Invoice Number != HAV Seafood Internal AP Document ID`

Actual issued numbers and sequence history belong to Phase 3.

### `Document_Status_Model`

Defines ten reusable statuses from Draft through Posted/Settled/Reversed.

### `Document_Status_Transitions`

Defines the permitted movement between document statuses.

Actual workflow events, timestamps, users and approvals are not included.

### `Document_Requirements`

Defines structural requirements by document type, including customer/supplier identity, currency, FX rate, tax, dates, cost centers, references and approval evidence.

### `Document_Relationship_Rules`

Defines explicit relationships for corrections, reversals, refunds, reclassifications and tax adjustments.

The model deliberately prevents a correction from being represented as deletion or silent overwrite of an original posted document.

### `Document_Source_Interfaces`

Defines how upstream business objects may create or support Finance documents.

Examples:

`Sales Order / Billable Event -> Customer Invoice`

`PO + Goods Receipt -> Supplier Inventory Invoice`

`Payroll Run -> Payroll Accounting Document`

`Production Event -> Production Accounting Document`

`Bank Movement -> Settlement / Bank Finance Document`

The upstream object remains authoritative in its own domain.

### `System_Data_Ownership`

Preserves the existing system model:

- `ESYS-001 Core ERP` — accounting/document system of record;
- `ESYS-013 Online Banking Portal` — authoritative external source for actual bank movements;
- `ESYS-009 Power BI` — reporting copy/model only.

### `Source_Mappings`

Records the authoritative upstream sources used or referenced by this workbook.

### `Relationship_Catalog`

Provides an AI-friendly view of the major entity relationships and authority flow.

### `Architecture_Notes`

Documents key assumptions, ownership boundaries, Phase 1 exclusions, tax/legal boundary and story neutrality.

### `Data_Dictionary`

Provides field-level descriptions for every sheet.

## Relationship with Accounting Foundation & Financial Dimensions

`hav_seafood_finance_accounting_foundation_dimensions_v1.xlsx` remains authoritative for:

- `LED-001` Finance ledger;
- DKK accounting/reporting currency configuration inherited by this workbook;
- GL account identity;
- `PCL-*` posting classes;
- financial dimensions and cost centers.

This workbook extends that foundation with tax, FX and financial-document architecture.

## Relationship with Shared Enterprise

Shared Enterprise remains authoritative for:

- currency identity;
- country identity;
- company identity;
- enterprise system identity.

Finance does not redefine DKK, EUR, SEK, NOK or country codes.

## Relationship with Sales & Commercial

Sales remains authoritative for:

- customer identity/extensions;
- price lists and commercial prices;
- commercial agreements and order structures;
- customer market/currency commercial context.

Current Sales price lists use SEK, NOK and EUR and are tax-exclusive.

Sales previously deferred payment-term master ownership to Finance. That boundary is preserved here, but detailed payment terms belong to the later Customer Credit, Billing & Receivables framework rather than this workbook.

## Relationship with Procurement & Supply Chain

Procurement remains authoritative for supplier sourcing and commercial procurement context.

The current supplier architecture uses DKK, SEK, NOK and EUR and contains provisional payment-term assumptions. Those assumptions explicitly defer the final payment-term master to Finance.

Detailed supplier payment-term/AP architecture belongs to the later Supplier Payables & Payment framework.

## Important conceptual boundaries

`Currency Master != Exchange Rate`

`Exchange Rate Type != Exchange Rate Value`

`Tax Category != Tax Code`

`Tax Code != Tax Transaction`

`Financial Document Type != Financial Document`

`Sales Order != Customer Invoice`

`Shipment != Customer Invoice`

`Purchase Order != Supplier Invoice`

`Goods Receipt != Supplier Invoice`

`Supplier Invoice Number != Internal AP Document ID`

`Credit Note != Invoice Deletion`

`Reversal != Record Deletion`

`Document Status Rule != Status Event`

`Bank Movement != ERP Accounting Document`

## Operational data intentionally excluded

This workbook contains no:

- exchange-rate history;
- actual customer invoices;
- actual supplier invoices;
- credit/debit notes;
- journal entries;
- payments or receipts;
- bank movements or balances;
- tax calculations;
- tax returns or payments;
- FX gains/losses or revaluation runs;
- document numbers actually issued;
- posting dates or accounting entries;
- document status history;
- approvals or workflow history;
- invoice PDFs or attachments;
- correction/reversal events;
- audit trails.

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

## Story neutrality

The architecture does not deliberately seed:

- tax errors;
- incorrect FX rates;
- currency mismatches;
- duplicate invoices;
- numbering gaps;
- missing original-document links;
- invalid reversals;
- failed approval controls;
- late posting;
- unusual FX losses;
- document workflow failures.

Those should be introduced deliberately in Phase 2/3 if selected as business stories.

## Recommended AI use

For fast navigation:

- Currency question -> `Finance_Currency_Config` + `Transaction_Currencies`.
- Which FX rate type applies? -> `Currency_Conversion_Rules`.
- Tax treatment question -> `Tax_Determination_Rules`, then `Tax_Codes` and `Tax_GL_Mappings`.
- What Finance document exists for an event? -> `Financial_Document_Types` + `Document_Source_Interfaces`.
- Required fields for a document -> `Document_Requirements`.
- Correction/reversal question -> `Document_Relationship_Rules`.
- Lifecycle question -> `Document_Status_Model` + `Document_Status_Transitions`.
- System/source-of-truth question -> `System_Data_Ownership` + `Source_Mappings`.
- Cross-entity joining -> `Relationship_Catalog`.

## Overall role

Together, these sheets form HAV Seafood's static **currency, tax-interpretation and financial-document control layer**.

They allow later synthetic invoices, journals, payments, settlements, tax records and FX activity to behave as part of one coherent accounting system while preserving upstream ownership of customers, suppliers, orders, receipts, Production events, payroll calculations and bank movements.
