- Documentation
- /
- Coast 15 Finance
- /
- 00 — Overview
00 — Overview
Demonstration prototype. coast_15_finance is a reference application and part of the Coastal Shipping series (catalogue SHP-15, Stage 3). It holds no real chart of accounts, tax rule or ledger connection — every account is a
MOCK_account, the ledger is a simulated adapter and every acknowledgment is a pretend answer. It illustrates the data model and the rules only.
What the Finance & Accounting Interface is
Is each issued invoice, approved supplier cost and committed agency fact posted once, in balance, and acknowledged by the ledger? — it is the adapter and reconciliation register between the shipping applications and an external ledger. It is not a general ledger, an invoice generator or a payment engine.
The chain the model is built around
issued fact → source (immutable, unique key) → batch (period, currency) → document (one balanced journal) → export attempt (simulated) → acknowledgment (per document) → reconciliation
- Only facts are sources. An issued billing document arrives as its complete posting snapshot (the header event is an observation only); an approved port or cartage supplier cost needs its supplier invoice line key (an estimate is never a source); an agency fact is cash, commission or remittance — never a statement, never a cost. A manifest rating or a port estimate is never posted as an actual transaction.
- One source, one key.
producer|source type|source id; the same key with the same hash changes nothing, with another hash it is a conflict and nothing is applied. A credit note or cost reversal is a new signed source linked to the original — the cost reversal is its exact negation. - Agent-paid is not carrier-payable. An agent-paid cost maps agent clearing; a carrier-payable cost maps supplier payable. The agent's cash facts move cash against the same clearing account but never touch a cost expense account, so an approved cost is never duplicated by agency cash (and a mapping that tries is refused).
- Mappings are approved configuration. Effective-dated, one per scope, two different accounts, dimensions from the source; no account is invented and a missing mapping blocks the batch. A positive signed amount posts debit account Dr / credit account Cr, a negative one the opposite sides — so a credit note needs no special case.
- One currency, balanced, exact. One currency per document and no implicit FX; debits equal credits; a reversal is the original's stored lines with debit and credit swapped. The arithmetic equals the pack's reference calculator (cross-check test).
- Approval is independent; the payload is frozen. The person who prepared a batch cannot approve it; approval hashes every document and the batch, and export refuses a payload that changed.
- Accepted is not posted.
SIMULATED_ACCEPTEDmeans the pretend transport took the batch. A document isPOSTEDonly when the ledger's acknowledgment names its document key, and its source hash, currency and amount match; otherwise it isMISMATCHEDorREJECTED. A partial batch stays exported; an unanswered document becomesUNCERTAINand is never resent until the ledger was queried. - Corrections link, they never edit. A posted document is corrected by an exact reversal and a replacement (new documents pointing at the original).
- External payments reconcile. A payment notice from the ledger is routed to coast_05_rating or coast_07_accounts for matching; a fact that originated in the ledger is
RECONCILE_ONLY. Neither is ever exported as new cash. - Cross-application links are strings.
source_ref,voyage_ref,port_call_ref,appointment_ref,customer_ref; no foreign key leaves the application.
The 14 models by area
| Area | Models |
|---|---|
| Financial Sources | FinSource · FinSourceSnapshot |
| Postings & Batches | FinPostingBatch · FinPostingDocument · FinJournalLine |
| Ledger Exchange | FinExportAttempt · FinPostingAck · FinReconciliationItem |
| External Payments | FinPaymentNotice |
| Accounting Configuration | FinAccountingProfile · FinAccountMapping · FinPostingPeriod |
| Audit & Exceptions | FinAudit · FinException |
Model names are unique across the whole fleet (hence the Fin prefix). Every model has a hidden canonical_ref (assigned by the runtime, shown in the collapsed Identifiers & integration section).
The demo scenario
Voyage V26-014 ex Lae, profile PGK-MAIN (legal entity LE-DEMO-CARRIER, connector mock_ledger). PB-26-0001 posts the two issued invoices (INV-26-0001 1 897.50, INV-26-0002 627.66) and is reconciled. PB-26-0002 posts the credit note CN-26-0001 (−948.75) and the Port Moresby port costs:
the simulated ledger rejects the agent-paid wharfage (PC-26-0002) and acknowledges the handling cost (PC-26-0003) at 100.00 against 110.00 — a mismatch — so the batch is in exception with two open reconciliation items. PB-26-0003 is approved but not exported (the Lae cartage
cost CC-26-0002 and its exact reversal CC-26-0003, the commission and the remittance). PB-26-0004 is a draft that will pick up the agent's three supplier payments; PB-26-0005 is a draft that already holds the replacement of the rejected wharfage document (a linked correction, never an edit). The collection AF-26-0001 originated in the external ledger: it reconciles with payment notice PN-26-0001 and is
never exported. The agency statement ST-26-0001 and the INV-26-0001 header are observations that never post; CC-26-0099 repeats a supplier invoice line and is quarantined; PN-26-0002 names nothing and is held unmatched.
How to read it
- Start from Financial Sources, then Postings & Batches; Ledger Exchange shows what the simulated ledger answered; Accounting Configuration holds the profile, the mappings and the periods.
- Amounts are
Decimal(18,2); every journal line is a debit or a credit, never both.