Count a commingled bin
This is for the facility operator at a shared site. Counting a location that holds several organisations' stock of the same shared anchor is a job only the operator can do, and it works differently from an ordinary count because the variance you find has to be shared out across organisations that each keep their own books.
Before you start
Three things all have to be true before the Count this bin control appears on a location at all.
Your active organisation has to hold the operator role on that site. At least one organisation you personally belong to has to hold stock of an anchored variant at that location. And the location has to be a countable storage location — receiving, dispatch, in-transit and virtual locations never offer a count.
The second condition is the one that catches people out. The control is driven by stock held by your own organisations at that bin, not by everything sitting there. If you're a member of the operator organisation alone, and the operator organisation holds no stock at that location, you'll see no control — even though the site is yours and the bin is full of tenants' stock. Ask for membership of a tenant organisation that holds stock there, or count from an account that already has it.
Count the location
- Open the location and select Count this bin. The dialog that opens is titled Cycle count.
- If more than one anchor is present at that location, pick which one you're counting from the Anchor list. If there's only one, the dialog names it for you and there's nothing to choose.
- Enter what you physically counted under Physical count. It accepts any non-negative number.
- Add anything worth recording under Notes (optional) — who counted, what they saw.
- Select Preview split.
Nothing about anybody's stock has changed at this point. The dialog moves to a second step, titled Review the split, and you can still back out with Discard without consequence.
Read the split
The review step shows Expected, Counted and Variance across the top, then a Per-org allocation table with one row per organisation holding that anchor at the bin.
Expected is the tenants' stock, and that's the model rather than an oversight. A facility operator doesn't hold stock at the site it runs, and it isn't a sharer of that site's shrinkage — the loss belongs to the organisations whose goods went missing. So Expected is built from the brand tenants' holdings, the variance is theirs, and the split shares it among them.
In the table, the Held column is each organisation's on-hand at the moment the count started, Attributed is yours to edit, and Allocation is what that organisation will actually book — negative for a loss, positive for a gain.
Attribute what you know the cause of
By default the whole variance is split across the organisations in proportion to what each of them held. That's the right answer when you don't know why the stock is missing. When you do know, say so.
- Type the units you know belong to a specific organisation into that organisation's Attributed box. Use a negative number for a loss, positive for a gain, the same way the Allocation column reads.
- Select Recompute split.
Attributed units go to the named organisation outright, and only the unexplained remainder is shared out proportionally. Recomputing replaces the previous attribution rather than adding to it, so clearing every box and recomputing puts you back to a plain proportional split.
This redistributes the variance between tenants. It does not change the total — the physical count is what it is, and every unit of it still lands on somebody. It is also not a way to take a loss onto your own books as the operator, or to account for stock belonging to an organisation that isn't in the table.
Two rules constrain what you can enter. You can't attribute more than the variance you actually found, and you can't allocate an organisation a bigger loss than it holds at that bin. Gains aren't bounded that way. If a recompute is refused, Yessort tells you which rule you hit, and the previously saved split is left intact — Publish stays available. Note also that allocations are no longer always whole numbers: attribute a fractional quantity and that fraction carries straight through.
Publish it
Select Publish.
Each organisation's share is sent to it as its own count message, and shortly afterwards each one writes the matching loss or gain against its own stock, on its own ledger. This happens in the background, on a one-minute sweep, so the tenants' figures move a little after you publish rather than the instant you do. Organisations whose allocation came out at zero are sent nothing at all.
If the count is refused before it starts
Yessort refuses to create the count when the location holds stock of the anchor you're counting that belongs to an organisation outside the counted tenants — most often stock owned by the operator organisation itself, or by an organisation whose membership of the site has been revoked. The refusal happens before anything is written, and the message names the offending organisation and how many units it holds.
The reason is that those units are physically in the bin but wouldn't appear in Expected, so the counted tenants would silently absorb them as a variance that was never theirs. The remedy is to resolve the ownership first — move that stock out, transfer it to an organisation that is a tenant of the site, or get the membership put right — and then count.
The money follow-up
Publishing settles the units. It doesn't settle the money.
Because a whole-number variance with nothing fractional attributed against it is split into whole units, every organisation can end up fractionally ahead of or behind its exact share. That residue is only ever trued up in money if you later open a settlement period covering the date the count was published — and only if you open it afterwards, because a period works out its figures once, at creation. See operator settlement periods for what that record is and what it is not.