Make a broken record impossible to save

Play this lesson as slides — one slide per step, with the same narration. The full text of every step is on this page.

This lesson is for you if you have fixed your customer list once and do not want to fix it again next quarter. A clean list decays through the front door: a new customer created in a hurry, at a branch, by somebody whose job is sales rather than compliance. About twelve minutes on the tenant settings closes most of that door, and this lesson also tells you honestly which part of it cannot be closed at all.

Step 1 — Know what the save already refuses

After this step you will know exactly how much protection you are starting with, which is less than you would hope. When you press Save on a customer, BigLedger checks that the customer code and the customer’s own reference are not already used by another record, that a receivable or payable type is set, and that the general ledger code, default label and consolidated entity it points at really exist. Name, type and currency are required. That is the whole of it. Nothing on the E-Invoice tab is examined. The identity or registration number is not checked at all — not for shape, not for uniqueness — and a customer with a completely empty E-Invoice tab saves without a murmur, then fails on its first individual sale.

Reference: Customer Maintenance — Lifecycle and posting

Step 2 — Make the identity number mandatory

After this step a clerk cannot create a customer with no identity number at all. In Application Settings there is a Mandatory Fields panel, and every switch in it is off out of the box — which is the fact worth carrying away, because it means the protection you assume you have, you do not. The one that matters here makes the identity or registration number required, and the applet’s own troubleshooting names it as the fix for e-invoices rejected on buyer details. Turn it on, and tell the branches first: a switch like this arrives at a counter as a refusal to save, on a Monday, with a customer standing there.

Reference: Customer Maintenance — Applet settings

Step 3 — Sort out the phone number, and know it misbehaves

After this step your contact numbers will be present, and you will not be confused by a screen that disagrees with itself. The contact number is mandatory on an e-invoice and must be between eight and twenty characters, so it is worth enforcing. One tenant switch governs it, and the E-Invoice tab’s own contact number is bound to that same switch. It also has a known defect. The create form reads the switch directly while the edit form and the E-Invoice tab read its opposite, so the number is demanded on one screen and optional on the other. Set it to whichever value gives you the behaviour you need on the screen your staff use most, and report it.

Reference: Customer Maintenance — Troubleshooting

Step 4 — Make sure the people filling this in can see the tabs

After this step nobody will be unable to finish a record for reasons they cannot see. Every edit tab, the E-Invoice tab and the Address tab included, has a hide switch that is off by default and a matching show permission. The pattern the applet page recommends is to hide a tab tenant-wide and grant the permission to the one role that should own it. That is a sensible control over credit limits and an expensive one over e-invoice fields, because the branch clerk who creates the customer is often the only person who will ever have the buyer in front of them. A tab missing for some users only is always this, and never a fault.

Reference: Customer Maintenance — Feature visibility / permissions

Step 5 — Accept that nothing checks the number itself

After this step you will stop treating a saved record as evidence that it is correct. There is no automatic format check when a customer is created, and no registration-number check anywhere at all. A tax number that is simply mistyped passes every screen in BigLedger and fails at submission, one document at a time, weeks later. The only verification available is the Verify action you run against the Inland Revenue Board on demand, and the habit worth building is running it when you onboard a business customer rather than when their invoice bounces. No setting will do this for you. It is a step in your onboarding procedure or it does not happen.

Reference: Best Practices — 1. Read the rejection list yourself, daily

Step 6 — Prove the guard rails are up

After this step you will know the settings took, rather than assuming it. Create one throwaway customer and try to save it with the identity number blank. The save should be refused. Fill the identity number and leave the contact number blank, and confirm you get the behaviour you chose on the screen your staff actually use. Open the E-Invoice tab and the Address tab as an ordinary branch user, not as yourself, and confirm both are there. Then delete or deactivate the test record, and look at the Audit Trail menu, which is where you will go the first time somebody asks who changed a customer’s tax number.

Reference: Customer Maintenance — Screens and menus

How the steps fit together

    flowchart TD
  s1["Step 1 — Know what the save already refuses"]
  s2["Step 2 — Make the identity number mandatory"]
  s3["Step 3 — Sort out the phone number, and know it misbehaves"]
  s4["Step 4 — Make sure the people filling this in can see the tabs"]
  s5["Step 5 — Accept that nothing checks the number itself"]
  s6["Step 6 — Prove the guard rails are up"]
  s1 --> s2
  s2 --> s3
  s3 --> s4
  s4 --> s5
  s5 --> s6
  

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 lesson: Fix a whole book of customers at once · Back to the course