The table that decides what each document can find — transcript

Play this as a presentation — one slide per step, with the same narration. Every word of every step is on this page.

This presentation is for you if you set up or look after the companies in GadgetSphere’s group, and you want every invoice to find its order and every purchase invoice to find its receipt. In about ten minutes you will learn what ties one document to the next, write the table that decides it for each company, and prove it works before anyone depends on it.

Step 1 — Know what ties one document to the next

After this step you will know what finding the one before it means in BigLedger. The orders, receipts and invoices in this series each have a draft state, where they have done nothing, and a final state, where they are locked. What ties one document to the next is a knock-off. On the new document’s KO For tab you pick a finalised source, and its open lines, with the customer or supplier, the items, the quantities and the prices, are copied forward and linked. The link is what lets GadgetSphere invoice twenty-two of forty ordered handsets now and the other eighteen later. The stock and the money move when the new document is finalised, according to its own type: a plain goods receipt moves nothing, and the purchase invoice books the stock in.

Reference: Core Concepts — 1. The chain is held together by knock-off, and knock-off is an open queue

Step 2 — See what finalising a source leaves for the next document

After this step you will know why a finalised order can be invisible. When a document is finalised, one of the jobs it sets off reads the company’s Knock Off Configuration. For every target type enabled there for this source type, it writes one open-queue row per goods line, holding the quantity still open, and the next document’s KO For grid reads nothing but those rows. If the company has no enabled row for that source type, the job writes nothing and logs nothing: the order finalises normally and nobody can find it. Each target type gets its own row. A GadgetSphere sales order line keeps one balance for the sales invoice and another for the goods delivery note, so the note still offers all forty after the invoice has taken twenty-two.

Reference: Organization — Knock Off Configuration (Company › Knock Off Config › Knock Off)

Step 3 — Write the pairs for each company before its first document

After this step each GadgetSphere company will have the pairs its documents need. The table is in the Organisation applet, under Company, then Knock Off Config, and it belongs to one company. Creating a company creates no rows, so GadgetSphere, GadgetSphere Online and GadgetSphere Distribution each need their own. A row is one sentence: when a document of this type is finalised in this company, leave its open quantity where that other type can find it. The pairs other applet pages rely on include sales order to sales invoice and to delivery order, purchase order to goods receipt, goods receipt to purchase invoice, and stock requisition to outbound stock transfer. Write each company’s list from how it actually trades, and enable every row before its first document is finalised, because nothing on a timer goes back for documents finalised earlier.

Reference: Organization — Knock Off Configuration (Company › Knock Off Config › Knock Off)

Step 4 — Choose one route into each downstream document

After this step your staff will have one way, not two, to bring goods onto an invoice. Purchase order to purchase invoice and goods receipt to purchase invoice are separate rows, and when both are enabled the invoice’s KO For tab offers both sources. Decide which document your invoices are drawn from, and enable that pair only. It matters more than it looks: if the purchase order is enabled for both receipts and invoices, ticking it counts each flow’s balance separately, but every save from the edit screen counts them together, and a balance the other flow still needed can vanish. For receiving, the grid refuses a second goods-receipt type for the same source with KO Conflict Detected. Stay in one receiving pair per company, because a receipt that books the stock alongside an invoice that also books it counts the goods twice, and the opposite mix never counts them.

Reference: Purchase Invoice (Internal) — Knocking off a purchase order or a goods receipt

Step 5 — Prove the chain on each company before go-live

After this step you will know the table works before go-live week, not during it. Nothing on the configuration screen confirms anything, and saving succeeds whether the pairs are right or not. So, for each company, take the first genuine source for each pair you enabled, a real sales order at a Klang Valley branch for instance, not a dummy, and once it is final open the downstream applet and look for it on its KO For or Search Document tab. It should be there. If it is not, and your draft matches its branch and customer, the pair is missing or disabled, and nothing was logged to tell you. Do the same for a purchase order and a goods receipt. Keep the list of enabled pairs with each company’s set-up notes, so whoever adds a new document type later knows it needs a row as well.

Reference: Organization — How you know it worked

Check yourself

Three to five questions on what you just heard. Every correct answer links to the page that makes it correct, so you can check the source, not just the mark.

Next: Knock off part of a document, and what the new one inherits · Back to the series · Play this as a presentation