One table, four ticks — 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 whoever at GadgetSphere keeps the customer and supplier lists and has wondered why a supplier occasionally turns up in a customer search. In about twelve minutes you will know what one of these records really is, what each of the four ticks on it changes, and which surprises follow from all four living on the same row.

Step 1 — See what you are actually editing

After this step you will know what a customer record is underneath. There is no customer table in BigLedger. There is one entity table, and every customer, supplier, employee and merchant you have ever created is a row in it. What separates them is four independent yes-or-no flags on that row: is a customer, is a supplier, is an employee, is a merchant. They are independent, so any combination is legal, including all four and including none. Customer Maintenance is a filtered view of this table that ticks the customer flag for you. Entity Maintenance is the same table with the filter taken off.

Reference: Entity Maintenance — Overview

Step 2 — Read the population before you believe the theory

After this step you will know how common each combination is, because we counted. Across all ninety tenant databases on the platform there are about eight point four million customer-only records, in eighty-one tenants. Supplier-only: fifty-four thousand, in sixty-seven. Employee-only: sixteen thousand, in fifty-three. Records carrying both the customer and the supplier flag: two hundred and sixty, spread over thirty-one tenants, with a median of three in each tenant that has any. Customer and employee together: five hundred and ten, in eleven tenants. So the shared record is not a theoretical possibility. It is rare, it is deliberate, and a third of all tenants have some.

Reference: Entity Maintenance — Overview

Step 3 — Meet the record no applet will show you

After this step you will know about a shape you have almost certainly got and cannot see. Because all four flags default to off, a row can exist with none of them set. It has a name, an address, contacts, perhaps a tax number, and it is invisible in Customer Maintenance, in the Supplier applet, in Employee Maintenance and in every document picker, because each of those filters on its own flag. There are about two thousand six hundred such records across eighty-three tenants. Entity Maintenance is the only screen that lists them. If a record you are certain you created cannot be found, this is the first thing to check.

Reference: Entity Maintenance — Entity listing

Step 4 — Learn what each tick switches on

After this step you will know what a flag actually buys. Each one turns on that type’s own code and its own identifier: customer code, supplier code, employee code, merchant code, and four separate identifier columns behind them. When you tick a flag and save with the code box empty, the backend mints a code for that type alone, from that type’s own running number and its own prefix. Tick supplier on an existing customer and the record keeps the customer code it had and gains a supplier code beside it. Nothing is duplicated and nothing is copied. One row, now answering to two names.

Reference: Entity Maintenance — Lifecycle and effects

Step 5 — Know which door you came in by

After this step you will stop being surprised by the differences between the screens. Customer Maintenance, the Supplier applet, Employee Maintenance and Entity Maintenance all edit these same rows, and each adds its own tabs, its own defaults and its own guards. That is why a field can be mandatory on one screen and absent on another, and why a value entered through one door can look wrong through the next. When two of us disagree about what a record says, the useful first question is not what it says but which applet each of us was looking at.

Reference: Entity Maintenance — Overview

Step 6 — Understand what the ticks do not do

After this step you will know the two things sharing a row will cost you. First, anything stored once on the record is shared by every role it plays: one AR or AP control account, one currency, one set of addresses, one alert message. The next lesson but one is entirely about the first of those, because it is chosen once and never revisited. Second, a process that searches this table without filtering on a flag will find every kind of record at once — which is exactly how a campaign aimed at customers can reach a supplier. Neither is a fault. Both are consequences of the one table.

Reference: Customer Maintenance — The AR/AP type is decided once

How the steps fit together

    flowchart TD
  s1["Step 1 — See what you are actually editing"]
  s2["Step 2 — Read the population before you believe the theory"]
  s3["Step 3 — Meet the record no applet will show you"]
  s4["Step 4 — Learn what each tick switches on"]
  s5["Step 5 — Know which door you came in by"]
  s6["Step 6 — Understand what the ticks do not do"]
  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: The code you type is not the code that is stored · Back to the series · Play this as a presentation