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>
58 lines
2.2 KiB
TypeScript
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";
|
|
}
|