Document Types

A document type declares that a pair of your datastores — a header and its lines — behaves as a transactional document. Sales invoice, purchase order, quotation, despatch note, credit note, timesheet: all the same shape.

The engine owns no data

A document type stores no records of its own. It points at a binding whose header and line roles name your datastores. Your invoice table stays your invoice table, with your columns; the document type adds lifecycle, conversion and traceability on top.

The practical consequence is that adopting documents does not require migrating anything. An existing orders datastore can be declared a document type and carry on holding the same rows.

Defining one

Each type carries a name, its binding, and its direction — whether it is a sales-side or purchase-side document. Direction matters because it determines the sign of any stock movement or ledger posting the document produces: a despatch takes stock out, a goods receipt puts it in.

Numbering

Pair each document type with a number scheme so references are allocated rather than typed. A gapless, predictable sequence per document type per entity is what auditors expect, and it removes an entire category of duplicate-reference problems.

Choosing your types

Declare a type for each document that has a genuinely different lifecycle, not for each variation in layout. A pro-forma invoice that follows exactly the same path as a normal invoice is a flag on the invoice, not a separate type. Two types that share a status list and a conversion map are usually one type wearing two hats.

What comes next

A document type on its own gives you a labelled pair of datastores. The value arrives with the two things built on it: an enforced status lifecycle, and conversion between types.