A branch is where you traded; a location is where the stock is — transcript

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

Two records, created minutes apart, that people treat as one thing and then cannot explain their stock report. This lesson separates them properly, and covers the two places a location is tied to a branch, which is where a reorganisation goes wrong. About eleven minutes.

Step 1 — Ask the two questions separately

After this step you can file any new fact on the right record. A branch answers where you traded: it is the tag on the document, the thing a report groups by, the unit a permission can be scoped to. A location answers where the goods physically are. They are not the same question and the platform does not treat them as the same question — the branch lives with the finance records and the location lives with the inventory ones. A shop with one stockroom needs one of each. A shop with a sales floor and a sealed back store benefits from two locations under one branch, because a stock take then tells you which is which.

Reference: Setting Up a Group: What We Recommend — Branches and locations

Step 2 — Know that the location, not the branch, is the stock key

After this step you know why the branch column will not answer a stock question. Stock balances are kept per item per location. The chain of movements that produces a balance is walked per location, the baskets that first-in-first-out and last-in-first-out costing consume are held per location, and bins and serial numbers hang off a location too. The branch tag on a stock movement is a label for reporting; the location is what the arithmetic is actually done on. So when somebody asks how much is at the Penang shop, the honest answer is a sum over that shop’s locations, and it is exactly wrong by however much sits at a location nobody linked.

Reference: Costing Internals — FIFO — a register of receipts, consumed oldest first

Step 3 — Set each branch’s main location deliberately

After this step one till stops refusing to finalise. When a document line does not say where the goods were, the platform works down a list: the line’s delivery location, then the line’s store, then the header’s store, then the branch’s own default location. Stock always lands somewhere, and on a twenty-branch retailer a great many movements land on that last fallback. So the main location is not cosmetic. There is a sharper edge at the counter: a point-of-sale cash bill is refused at finalise when the document’s location is not the branch’s main location, and the message does not say so. Set it branch by branch, and set it before the first sale.

Reference: Organization — Troubleshooting

Step 4 — Find both places a location is tied to a branch

After this step a reorganisation stops producing ghosts. A location carries its own branch on its record, and there is also a separate table holding branch-to-location links. Creating a location the ordinary way writes both at once from the same value, so on a tenant that has only ever done it that way the two agree and you never notice there are two. They are read by different things. The permission-scoped location listing reads the location’s own column — this is one of the few listings that genuinely applies your branch target on the server. The link table is what a shopping-mall sales report joins stock balances through, and what marketplace order ingestion falls back to when it cannot find a store for the branch any other way.

Reference: Organization — A location belongs to a branch twice over

Step 5 — Know that a location can belong to more than one branch

After this step you can read the symptom. Because the link table is a many-to-many, a location can be linked to several branches while its own record names only one, and across the tenant estate there are noticeably more link rows than there are active locations, so this is genuinely used rather than theoretical. The practical consequence is a diagnosis. If a location has stopped appearing for a branch after somebody reorganised, there are exactly two places to look, and they can disagree. The record’s own column is the one the permission check reads, so that is the one to fix first when the symptom is that somebody cannot see a warehouse they should.

Reference: Organization — A location belongs to a branch twice over

Step 6 — Stop waiting for the branch hierarchy

After this step you will not switch on a field expecting something it does not do. There is a Parent Branch picker, hidden behind a setting, and it writes a parent onto the branch record. That is the whole of it. The only thing in the backend that reads it is an optional filter on the branch listing, so you can search for the children of a branch. Nothing rolls a child branch’s figures into its parent, no report groups by it, and no document inherits anything from the parent. If you want regions above branches in a report, that is what the analysis dimensions are for, and the next lesson is about those.

Reference: Organization — Applet settings

How the steps fit together

    flowchart TD
  s1["Step 1 — Ask the two questions separately"]
  s2["Step 2 — Know that the location, not the branch, is the stock key"]
  s3["Step 3 — Set each branch's main location deliberately"]
  s4["Step 4 — Find both places a location is tied to a branch"]
  s5["Step 5 — Know that a location can belong to more than one branch"]
  s6["Step 6 — Stop waiting for the branch hierarchy"]
  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: Branch and profit centre are two columns, not two names · Back to the series · Play this as a presentation