Close a branch, and prove the settings

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

This last lesson covers the end of a branch’s life and the start of its working one. Closing, deleting and renaming behave in ways that surprise people, and then there is a single test — one cash bill, thirty seconds — that proves most of what the previous six lessons set up. Run it at every new GadgetSphere branch before anyone trades on it. About eleven minutes.

Step 1 — Close a branch without losing its history

After this step you can take a shop out of use safely. A branch’s status is active or closed, with a closing date beside it, and a location’s is the same choice stored as inactive and displayed as closed. The Organisation applet’s own company and branch listings load active records only, so a closed branch drops out of them while every document it ever raised keeps pointing at it. Check any downstream picker your closure procedure actually depends on, because that filter is this applet’s, not a rule the whole product follows. There is no state machine behind this and nothing approves it: the status is simply overwritten when you save, by anybody whose permissions let them edit the branch. Reopening is the same edit in reverse.

Reference: Organization — Lifecycle and effects

Step 2 — Know what closing a company takes with it

After this step you will not close an estate by accident. Setting a company’s status to closed asks you to confirm, and then sets every branch and every location of that company to closed as well. For GadgetSphere’s main retail company that is one confirmation and twelve Klang Valley shops, four in Penang, three in Johor Bahru and the rest, all shut in a single action. It is exactly right when a legal entity has genuinely stopped trading, and startling when somebody was tidying a record. Close branches one at a time unless you mean the whole entity.

Reference: Organization — Company Details tab

Step 3 — Prefer closing to deleting, always

After this step you will keep your history readable. Delete here is a soft delete: the record’s status becomes deleted, and that is all. No validator checks whether documents reference the company, branch or location first, so the record disappears from the pickers while its documents carry on holding its identifier. The row itself still exists, marked deleted, and no page says how each report will render a name that no longer resolves — so test the reports you rely on before you trust one. Closing does everything you actually wanted, out of the pickers and still readable in history, so use it, and keep delete for a record somebody created by mistake this morning.

Reference: Organization — Lifecycle and effects

Step 4 — Agree the code shape before you type it

After this step you will not inherit twenty-two codes you dislike. Company, branch and location codes are unique across the tenant and upper-cased on save, and a duplicate is refused outright. Branch and location codes are fixed once saved. A company code is the exception — an owner or an administrator can still change it, to another unique one. GadgetSphere uses a region and a sequence, so the first Klang Valley shop is GS-KV-01 and the first Penang one GS-PEN-01. Agree that shape before the first branch is saved, because for a branch the only remedy afterwards is a second record and a closed first one.

Reference: Organization — Branch — Details, Address and Marketplace

Step 5 — Find out who changed a setting

After this step you will know where to look, and how far to trust it. The Organisation applet has an Audit Trail screen listing back-office audit events with a detail panel and the user resolved from the tenant’s profiles. Which events it records, and whether it keeps the old value beside the new one, is not documented — so confirm that a branch edit appears there before you build a control around it. Note the asymmetry while you are here: the company, branch and location records are gated by server-side permissions, but anyone who can open this applet’s Settings menu can change what is in there, because no permission covers that screen.

Reference: Organization — Screens and menus

Step 6 — Prove the whole branch with one cash bill

After this step you will know a branch is configured rather than hoping so. Take the new branch and finalise one cash bill for a single low-value accessory. Four things should follow. The bill finalises, which means the till’s location matches the branch’s main location. The Stock Balance row for that location drops by one, which means the stock jobs ran and the precedence landed where you expected. The listing shows a branch number beside the tenant number, which means the branch counter is stamping. And the printout is the layout you set for that branch. Four checks, one bill.

Reference: Related Applets - Stock Balance — How a FINAL reaches the balance

How the steps fit together

    flowchart TD
  s1["Step 1 — Close a branch without losing its history"]
  s2["Step 2 — Know what closing a company takes with it"]
  s3["Step 3 — Prefer closing to deleting, always"]
  s4["Step 4 — Agree the code shape before you type it"]
  s5["Step 5 — Find out who changed a setting"]
  s6["Step 6 — Prove the whole branch with one cash bill"]
  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.

Back to the course