MEGAINFRA-WEBAPP/src/lib/document-kind.ts
DEls 21f6c40731 fix(financial): an invoice is evidence of delivery, not a reason to discount it
Corrects an over-correction. The previous change excluded invoices from
"delivered" to stop a note-and-invoice pair double counting. But which
document a supplier sends is the supplier's habit, not a statement about
whether goods arrived: plenty never issue a delivery note at all, and for
those the invoice is the ONLY evidence. Excluding it took R6.2m of orders
down to 0.8% delivered and showed suppliers like Global Precast at 0%
against R51k of invoices they had plainly fulfilled.

Every receipt document now counts, including ones we could not classify —
under-counting a real delivery is worse than the small risk of counting
something odd, and an unclassified document lands in neither evidence
bucket so it stays findable.

The genuine risk is narrower and is now measured rather than guessed at:
`possibleDoubleCount` is the quantity appearing on BOTH a delivery note
and an invoice for the same purchase order line. It is reported, never
silently subtracted, because a supplier can legitimately deliver the same
quantity twice and only a person can tell. Across the live book it is one
line — Building Sand 15.24 tons, about R3 539, the AS0002112 /
IRN010002042 pair.

Fulfilment by value goes from 0.8% to 7.1%. Still low, but for the real
reason: 28 documents against 24 purchase orders, with R3.3m of orders
carrying no paperwork at all yet.

952 tests.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-18 01:42:27 +02:00

58 lines
2.2 KiB
TypeScript

/**
* `delivery_notes.document_type` classifies which kind of document a
* `delivery_notes` row actually is. The collection name is historical —
* it holds delivery notes, collection notes AND invoices, distinguished
* only by this field.
*
* ## All three prove a receipt
*
* Which document a supplier sends is the supplier's habit, not a
* statement about whether goods arrived. Some issue a delivery note on
* the day; plenty only ever issue an invoice. For those, the invoice is
* the only evidence the goods came — so it must count.
*
* An earlier version of this module excluded invoices from "delivered".
* That zeroed out most of the book: R6.2m of purchase orders showed 0.8%
* delivered, because 63 of 79 documents in the queue were invoices from
* suppliers who send nothing else.
*
* ## The real risk
*
* A supplier who sends BOTH — a weighbridge ticket at delivery, then an
* invoice for the same load days later. Counting both doubles that
* delivery. `po-fulfilment.ts` measures that overlap per purchase order
* line as `possibleDoubleCount` and reports it rather than guessing,
* because a supplier can legitimately deliver the same quantity twice.
*
* `unknown` and `""` still count as a receipt: a document we could not
* classify is more likely to be a real delivery than not, and dropping
* it silently understates what arrived. `countsAsInvoiced` is only for
* splitting the evidence, never for excluding it.
*/
export type DocumentKind =
| "delivery_note"
| "collection_note"
| "invoice"
| "unknown"
| "";
/**
* Evidence that goods were received. Every document kind qualifies —
* the distinction below is about WHICH evidence, not whether it counts.
*/
export function countsAsReceipt(_kind: DocumentKind): boolean {
return true;
}
/** Evidenced by a delivery or collection note rather than an invoice. */
export function countsAsDeliveryNote(kind: DocumentKind): boolean {
return kind === "delivery_note" || kind === "collection_note";
}
/**
* Evidenced by an invoice. Still a receipt — this only says which kind,
* so an invoice that pairs with a delivery note can be spotted.
*/
export function countsAsInvoiced(kind: DocumentKind): boolean {
return kind === "invoice";
}