A shift is the interval between two counts at one bar with a name on it, and its page is the report: what was poured, what the recipes account for, and what is missing, in bottles, tots and shillings.
What a shift is here
A shift is a period at one bar, bounded below by a stock count and above by the next one, with one person named as responsible for the shelf in between. Its code looks like SHF-000123.
Almost nothing new is stored. The interval between two counts at a location already existed, and the Variance engine already knew how to read it. A shift adds exactly two facts to it: who had the bar, and which sales belong to that stretch of the night. It posts nothing to the stock ledger, and it never will: opening, handing over and closing a shift change no balance anywhere.
One bar means one storage location, for the same reason a stocktake is per location. A shift covering the main bar and the club bar together would report one number across two shelves, and nobody could say which of them lost the stock.
The Shifts page lives under Bar Suite and needs manage_shifts or view_reports, plus the BAR module, which is part of the Enterprise plan. A venue on the smaller plan keeps its counts and simply has no Bar Suite section in the sidebar.
The list
Two tabs, and the tab lives in the URL:
- Open: bars somebody is answerable for right now, oldest first. A shift open since Tuesday is a shelf nobody has counted since Tuesday.
- Closed: finished shifts, newest first. Each of these has a variance to read.
Each row shows the shift's code, the bar, the responsible person, the status, when it opened and closed, and the two boundary counts (CNT-000031 then CNT-000034, or "open" while it runs). There is deliberately no quantity anywhere on this page. That is what lets a bar manager hand a shelf over without being shown what the system expects to be on it, which would make their own counts sighted. The figures are on the shift's own page, behind a different grant.
Opening a shift
Open shift (needs manage_shifts) asks for four things: the outlet, the bar, the opening count, and the responsible person. A note is optional.
Two of those are worth pausing on.
The opening count must be finished. Only counts that have been submitted or approved appear in the picker. A shift is anchored to the moment counting finished, and a sheet still being walked has no such moment: "CNT-000031 is counting, and a shift needs a finished count as its boundary. Finish the count first; if it was finished on a phone, wait for the queue to send it." Approval is deliberately not required, for the reason in the report section below.
The shift starts when the shelf was counted, not when you press the button. If the count finished at 18:00 and somebody opens the shift at 18:40, the shift began at 18:00. The gap is exactly the trading the report is about.
The responsible person can be anyone active in the company. It is not limited to people who hold manage_shifts, because a bar back who never opens the app is a perfectly good answer to "who had this shelf". Authority to hand a bar over and responsibility for what was handed are two different things.
One bar has at most one open shift. Trying to open a second gets the first one's code back: "SHF-000123 is still open at this location. Hand it over or close it, two open shifts at one bar would each claim to be answerable for the same stock."
Handing over
A handover is one count, not two. The count that closes the outgoing shift is the same document that opens the incoming one: one walk of the shelf at 2am serves both. Asking for two counts would simply get the second sheet copied from the first.
Hand over asks for the closing count and for who takes the bar next. Both halves happen together or neither does, because a closed shift with no successor is a shelf nobody is answerable for, and an open successor beside an unclosed predecessor is two people who both are. If the person you name is not an active member of the company, nothing changes and the old shift stays open.
A closing count has to be a different document from the opening one, and it cannot have been counted before the shift began: "CNT-000029 was counted before SHF-000123 opened, so it cannot close it. A shift ends at the count that follows the one it began with." Counts arrive out of order more often than you would think, because a phone that was in a cold room on Friday can sync on Monday.
Closing
Close is a handover with nobody taking the bar next: the bar is shut rather than passed on. It takes the same closing count and the same optional note.
One refusal bites at both closing and handover. A shift cannot close while a bottle sign-out at its bar is still open. The message names the documents and the people: "Close BSO-000045 (Amina, VIP 3) before the closing count. That bottle is off the shelf right now, so a count taken before it is accounted for would read as a loss against SHF-000123." See Bottle Service; the reason is that the closing count is about to walk a shelf that three bottles are missing from, and those three bottles are on a table rather than gone.
Once a shift is closed, everything about it is fixed except its note. Boundaries, times and the responsible person do not change afterwards, because changing them would rewrite who was answerable for a loss after the loss was found. The note stays editable because the explanation for a variance almost always arrives after the variance does.
Reading the report
The shift's own page is its variance report, and the order of that page is an argument rather than a layout.
Caveats first
Everything that weakens the number sits above the number, in sentences. You may see any of:
- Sign-outs still open, so bottles counted as missing are actually on a table.
- The shift is still open, so there is no closing count and no usage figure yet, only the movements so far.
- A boundary count that has not been approved, so the figures may still change. This is the one that is always there on the night, and it is the point rather than a defect.
- A boundary count that was rejected, so somebody has already judged its figures wrong.
- A boundary count that was sighted: the counter could see what the system expected, so the count can agree with the ledger without independently confirming it.
- No sales file assigned to this shift, so the recipes account for nothing and every pour reads as a loss.
- Sold lines with no recipe behind them, which make the variance larger than it is, with the first few POS names listed.
- Items on one sheet and not the other, which are counted as zero at the missing end.
An empty caveat list means the report is standing on two approved blind counts and an assigned sales file, which is the only state where the figure needs no explanation.
What this shift is
Status, responsible person, opened and closed times, the two boundary counts each with its status and a blind or sighted stamp, the exact window the movements were read over, and the total variance in KES.
Sales assigned to this shift
Files assigned, lines exploded, lines unmapped, and the POS names still to map. A shift with no file assigned reports theoretical usage of zero, and a variance against zero theoretical is not a finding. It is a shift nobody imported sales for.
Bottles signed out on this shift
Shown only when there were any: how many are still out, how many bottles were unaccounted for, what those were worth, and the register rows themselves, open first and then by value. This sits beside the item figures rather than inside them, because a sign-out changes no balance. What it changes is whose name a shortfall belongs to. Three bottles short with three unaccounted to one waiter is not the same finding as three bottles short with an empty register.
By item
Opening, Closing, Actual used, Recipes say, Variance, In tots, Per tot, and At cost, sorted worst first, with the largest loss at the top. A row carries a warning where the item was on one sheet and not the other. Read the direction word rather than the bare sign: variance is negative when more was used than the recipes account for.
Why the report does not wait for approval
A shift closes at 2am and gets read at 3am. Accepting a count is somebody else's morning, so a report that waited for it would be read the following week, which is the same as not existing.
So the report reads the two counts' own counted figures rather than the ledger balance, and tells you in the caveats exactly what state those counts are in. Once both boundary counts have been approved, the shift's per-item variance equals the daily Variance report's for the same bar over the same window. That agreement is tested rather than hoped for, and it is what keeps a shift from becoming a second, different truth.
Sales: a day is whole or it is per shift, never both
Shift-level theoretical usage needs shift-level sales, and only the till can split a night: a Z-report per shift, or a report run for a time range. So a sales import carries an optional shift, and one rule holds the whole thing together.
A business date is either one whole-day file or a set of per-shift files. Mixing them is refused in both directions, naming the import already there. The reason is arithmetic: the daily variance report sums every active import on the date, which is right under either regime and catastrophically wrong when both are present. The day would be counted twice, theoretical usage would double, and a bar that poured exactly what it sold would report a surplus the size of a night's trading.
Two other things to know. A shift file can still be filed for seven days after the shift closes, because the Z-report gets walked to the office on Monday, and after that the day has to go in as a whole-day file. And a shift belongs to the file you attach it to, never to a guessed time window: a Micros export carries no timestamps, so deriving the split from the clock would invent an attribution the source data does not contain, in the direction that decides whose shift carries a shortfall.
Tots
A tot is a way of reading a number, not a way of storing one. Every quantity in the platform stays in bottles; a pour size for one particular drink is that drink's recipe line and stays there.
The house measure lives in Company Settings → Inventory Policy, in the card called The bar: Tot size (ml), 30 by default, which is the usual Kenyan pour. The hint under the box does the arithmetic for you as you type ("At 30 ml a 750 ml bottle pours 25.00 tots, and a 1 litre bottle 33.33").
Because nothing is stored, changing the tot size changes what you see today and rewrites no history. An item whose usage unit is not a volume has no tot reading at all and shows a dash: asking how many tots are in a kilogram of chips has no answer, and inventing one would put a confident number where there is no fact.
Who can do what
| Grant | What it allows | Seeded to |
|---|---|---|
manage_shifts | Open, hand over, close, name the responsible person, edit the note | Bar Manager, Outlet Manager, Admin |
view_reports | Read the shift list and the variance report | Bar Manager, Outlet Manager, Chef / Kitchen Lead, Finance / Accounts, Procurement Officer, Auditor, Admin |
The Stock-taker role reaches none of this, deliberately. The report carries quantities, and a counter who can look up what a bar should hold is no longer counting blind. See Roles & Permissions.
On the phone
The mobile Bar Shifts screen (under More, behind manage_shifts and the BAR module) lists every shelf at the outlet, each with its open shift or with "Nobody is answerable for this shelf right now". A list of only the open ones would answer the opposite question: an uncovered bar is exactly the thing that has to be visible.
Each row offers Start a shift, or Hand over and Close where one is running. A shelf with open sign-outs says so on the row, with a tap through to the register, so you find out before you choose a closing count rather than from a refusal afterwards.
These three actions need a connection. They name a person against a count the server must already hold, and they happen at a handover with a manager present rather than at a shelf under time pressure. Counting itself still works offline exactly as it always has, and the screen says so when you are off signal.
There is also a shortcut. Right after you press Finish counting on the Stocktake screen, a panel offers the shift action that count implies: start a shift at a shelf with none, or hand over where one is open. Tap the person and you are done, with no navigation at all. If the app reloads before you get to it, and at 2am it will, the Bar Shifts screen is the way back in.
FAQ
The count is not approved yet. Why is the report showing figures? Because it reads the counters' own numbers rather than the ledger, and says so in the caveats at the top. Waiting for an approver would make this a report nobody reads. Once both counts are approved the figures agree with the daily variance report exactly.
Two people worked the bar and one shift is open. Whose name is on the loss? The person named as responsible. If the bar genuinely changed hands, that is a handover: one count, closing one shift and opening the next. A shift is the unit of attribution, so splitting the night is how the shortfall lands on the right person.
Somebody went home without closing their shift.
An Outlet Manager holds manage_shifts for this reason. Walk the shelf, then close the shift on that count from the web or the phone. The shift ends at the count, not at the moment you pressed the button, so a late close does not stretch the period.
The variance is huge and we did nothing wrong. Look at the caveats first. Almost always it is the sales file: no import assigned to the shift, so the recipes account for nothing and every pour reads as a loss. Assign the shift's Z-report and read it again.
Can I put a whole-day sales file on a night we ran two shifts? Yes, but then neither shift gets a theoretical figure and both report every pour as a loss. Import per shift, or accept that the day is only readable on the daily report. What you cannot do is both.
Is a shift anything to do with staff hours or rosters? No. A shift here is a custody interval over one shelf. It has no hours, pays nobody, and is not a roster.