Finalise one document and prove it — transcript

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

This lesson is for you if everything in this course is configured and nobody has yet proved it. Two records to create first, then one invoice and one journal — and then a short list of the things this course did not switch on, so you hand over a tenant whose gaps are known rather than discovered. Fifteen minutes.

Step 1 — Settle the entity code prefixes before you create anything

After this step your customer and supplier codes will look deliberate. When somebody saves a customer without typing a code, BigLedger builds one from a per-type prefix plus a running number. That prefix lives in a tenant configuration row that no screen currently edits, so if you want codes that start with a letter you recognise, it has to be set for you before the first record is saved. Ask your BigLedger contact now, while nothing exists — including the test customer you are about to make. Retrofitting is painful: the engine skips a number that is already taken, so a tenant that imported records first finds its generated codes jumping over them for years afterwards.

Reference: Document Numbering — Customer, supplier and employee codes come from the same table

Step 2 — Create the one customer and the one item the proof needs

After this step you have the two records the test invoice cannot be raised without, and nothing in this course has created either of them yet. Make one test customer — a debtor carrying its receivable account from your chart, a tax code and payment terms — and one service item, an installation service priced at a thousand ringgit. Two records, not a migration. The full customer setup is a course of its own and so is the item master, because a real customer carries credit limits, categories and pricing and a real item carries tax codes, GL codes and category groups. Here you need one of each, correct enough to post.

Reference: Core Module — The order a new tenant sets things up in

Step 3 — Post one test invoice, and use a service item

After this step GadgetSphere has a document to prove. Raise a sales invoice for a test customer at one of your branches, with the six per cent tax code, for a round figure — a thousand ringgit works well because the arithmetic is obvious. Use a service item for the line, not a stock item. On a brand-new tenant nothing has stock anywhere yet, and a sales invoice for a stock item with none at the branch is refused at final, which looks like a configuration fault and is not. Save the invoice, then set it to final. The journal is written at final, never at save, so saving alone proves nothing.

Reference: Chart of Accounts Setup Guide — Step 9: Enter opening balances and post one test invoice

Step 4 — Find the journal and read its three lines

After this step you have proof rather than confidence. Open the Ledger and Journal applet and find the journal carrying your invoice number. It should have exactly three lines: a debit to your trade debtor account for the gross amount, a credit to your sales account for the net, and a credit to your output tax account for the tax. For a thousand-ringgit sale at six per cent that is a debit of RM 1,060, a credit of RM 1,000 and a credit of RM 60. If those three lines are there, against the codes you chose, then the chart, the ledger, the default GL codes and the tax setup are all correct together — the sections were proved separately, on the opening-balance view in lesson five. There is no cost-of-goods line at this point and there should not be; that is computed at month-end from the stock side.

Reference: Chart of Accounts Setup Guide — Step 9: Enter opening balances and post one test invoice

Step 5 — Name what you have stopped doing by hand

After this step you can explain to your finance manager what the configuration bought. Nobody at GadgetSphere has to choose an account on a document — the defaults answer for them, unless somebody has deliberately put a code on the line, on the document header, or on the item. Finalising a document enqueues a posting job, and that job reads the company’s default GL codes and writes the journal — thousands of times a month, on documents raised by people who have never seen a chart of accounts. The same pattern ran earlier and you may not have noticed: saving the company created its corporate entity, its primary ledger and its stock-in-transit location in one transaction, and saving a branch created its location and linked it. That is the shape of this product. You configure a rule once; a processor applies it every time.

Reference: Chart of Account — Applet settings

Step 6 — Learn the one screen that tells you whether it ran

After this step you have a way to check without watching. Open the Financial Report applet and go to Error Checking, Trace Document. Give it the document type and number and it runs six checks against that one document — whether the journal exists, whether it is right, whether the cashbook line and the shadow document exist, and for a voided document whether the reversal and its queue exist. Each failed check has a Resolve button that creates or reposts the missing piece. Beside it, the Stock Flow Report does the same work in bulk: inventory value against accounting value, per module, with a difference column you can click into and post from.

Reference: Financial Report — Error Checking

Step 7 — Know the honest gap: nothing tells you at the time

After this step you will build a habit rather than trust a notification. There is no alert when a posting job fails. The posting runs on a background thread long after the request that finalised the document returned, so there is nobody left to tell: the person who raised it sees a normal document. The failure is recorded, in a table no screen or report in the product reads. Trace Document and the Stock Flow Report both answer the question, and both only when somebody asks. So the cover is a routine, not a setting. Know two more things before you need them. Nothing re-drives a failed journal — some tenants have a watchdog that re-queues a failed stock posting, but there is no equivalent for the ledger, so a missing journal stays missing until a person finds it. And you cannot fix a failed posting by finalising again: add the mapping, then Resolve.

Reference: Financial Report — Error Checking

Step 8 — Switch on the thing that is still empty: knock-off

After this step you will not spend go-live week explaining why the invoice cannot find the order. Creating a company creates no knock-off rows, and nothing in this course created any. That table decides, per company and per pair of document types, whether finalising one document leaves anything for the next one to pick up. If there is no enabled row for a document’s company and type when it goes final, no open-queue rows are written and nothing is logged anywhere — and the downstream Search Document tab then finds nothing. Enable the pairs you need before anybody finalises anything real, because there is no repair afterwards: nothing sweeps up a document that went final with no enabled pair. Take the course on knock-off configuration before you decide which pairs those are.

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

Step 9 — Go back to Tenant Admin, then void the test and open up

After this step the tenant is ready for other people. Permission sets can only be scoped once companies, branches and locations exist, which is why this is the last step rather than the first — the Permission Wizard will now generate a set for each location, company and branch combination and, if you ask it to, a role for each one. Grant deliberately, and remember that role and permission changes leave no audit row. Then void your test invoice. Only after that, switch the company’s e-invoice status on — once it is on, every finalised invoice is queued, and voiding pulls one out only while it is still unsent.

Reference: Tenant Admin Applet — Lifecycle and effects

How the steps fit together

    flowchart TD
  s1["Step 1 — Settle the entity code prefixes before you create anything"]
  s2["Step 2 — Create the one customer and the one item the proof needs"]
  s3["Step 3 — Post one test invoice, and use a service item"]
  s4["Step 4 — Find the journal and read its three lines"]
  s5["Step 5 — Name what you have stopped doing by hand"]
  s6["Step 6 — Learn the one screen that tells you whether it ran"]
  s7["Step 7 — Know the honest gap: nothing tells you at the time"]
  s8["Step 8 — Switch on the thing that is still empty: knock-off"]
  s9["Step 9 — Go back to Tenant Admin, then void the test and open up"]
  s1 --> s2
  s2 --> s3
  s3 --> s4
  s4 --> s5
  s5 --> s6
  s6 --> s7
  s7 --> s8
  s8 --> s9
  

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.

Back to the series · Play this as a presentation