Repository navigation
Feature: Shift lifecycle management, cash drawer reconciliation, & business day close #279
Description
Refs: #370 — POS feature roadmap (Phase 1)
Important
Status: Needs maintainer review — ported from fork codewithsharma/FloCafe (branch develop). Requires maintainer review/approval before implementation.
Operations & Shift Management Feature Request
Extracted from fork codewithsharma/FloCafe (branch: develop):
Overview
Full shift management lifecycle, cash drawer float tracking, drawer count reconciliation with variance calculation, shift enforcement middleware, and business date day-close reporting.
Proposed Changes
- Shift Schema & Migrations:
- Migration 69 (
shiftstable,shift_idonordersandbills, indices) and Migration 70 (expected_cash_centsandvariance_centscolumns onshifts).
- Migration 69 (
- Shift Lifecycle & Cash Reconciliation:
- Open shift modal (opening float input), Close shift modal (cash drawer count), Force close shift option.
- Shift reconciliation logic comparing system-calculated expected cash vs actual cash count to determine variance.
- Reference:
main/services/shift.ts,frontend/src/components/shifts/.
- Shift Enforcement Middleware:
- Option to require an open shift prior to performing cash transactions.
- Reference:
main/middleware/shift-enforcement.ts.
- Day Close & Business Date Accounting:
- Migration 71 (
day_closestable storing business date, closed user, and summary JSON). - Timezone-safe local day boundary calculation (
localDayBoundsUtc) to avoid UTC vs local business day discrepancies. - Reference:
main/services/day-close.ts.
- Migration 71 (
Acceptance criteria
- Shift open/close/force-close with opening float and cash-drawer count + variance calculation.
- Optional shift-enforcement middleware gates cash transactions.
-
day_closestable + timezone-safe local day boundary calculation.
Activity
khaira777 commentedon Aug 16, 2026
Verdict: VALID ENHANCEMENT — large; needs product decision before implementation
Findings:
shifts,day_closes, drawer-float, or enforcement logic exists on main (the only "shift" hit is a timezone comment atmain/db.ts:4785). X/Z report menu items (main/index.ts:529-530) just navigate the renderer to the reports page;reports.tshasdaily-stats(main/routes/reports.ts:105) but no business-day close.dateStampInTimezone, see feat: configure invoice numbering #297) and is reusable forlocalDayBoundsUtc-style day boundaries.Suggested scope (MVP first): shifts table + open/close modals with opening float and drawer count + expected-vs-actual variance; then shift enforcement middleware and day-close accounting as separate follow-ups. Overlaps: #278 (cash refunds in day-close expected cash), #287 (SHIFT_START/END audit events), #280 (inventory snapshot at close). Maintainer decision needed: is shift enforcement a desired workflow change (forces open shift before cash transactions)?
itsbkm commentedon Sep 4, 2026
Research follow-up: day-end closing terminology and comparable POS behavior
I reviewed documentation from several established POS systems to compare their day-end closing workflows.
Findings
Product recommendation for FloCafe
“Day close” is the business workflow, but the underlying record should be a cash session/shift, tied to a specific till/register/device. A day can contain multiple tills or multiple shifts, and a shift can cross midnight.
Recommended terminology:
cash_sessionThe MVP close report should include:
Important distinction: a shift/till close reconciles money; a day-end report summarizes business activity. If FloCafe has one till and one daily session, the UI may present this as “Close Day”, but it should still persist a shift/cash-session record underneath.
This research supports the existing issue scope, with the likely implementation sequence:
itsbkm commentedon Sep 21, 2026
Re-scoping check per the stabilization plan: the plan's original instruction was "rewrite against cash_closures" — that table now exists (main/db.ts, migration add_cash_closures) with business_date tracking, and shift_id-based drawer attribution already flows through main/services/refund.ts. So part of this issue's foundation has landed since it was filed.
Full shift lifecycle management is explicitly out of this stabilization milestone's scope (0-5phases.md, "Explicitly not in this milestone: Full shift/cash-session lifecycle"), so this issue correctly stays open — it just needs re-scoping against the current cash_closures foundation rather than a from-scratch design. Labeling state:needs-design; owner scoping needed before implementation starts.
carvalab commentedon Sep 23, 2026
Approach A is implemented in #836, ready for review (branch
shift-lifecycle).What it builds, following the three comments above:
cash_sessionstable (migration v90); closes persist ascash_closuresrows withscope='session', using the extension door this issue anticipated. Day close is untouched.Checks: new 65-test session suite plus the day-close, payments, refunds, reports, and export suites green; lint, build, and i18n checks green; three review rounds with every high and medium fixed; walked end to end in a real browser (open float, live expected, variance preview, close result, confirmed in the database).
Left out on purpose: concurrent multi-till sessions, inventory snapshot at close, audit events, per-user grants. Two small follow-ups if you want them: a confirm step on negative variance, and a shared print helper with day close (skipped to avoid touching that path here).
feat(shifts): cashier shift open/close with variance and session Z (F…
feat(shifts): cashier shift open/close with variance and session Z (#279
khaira777 commentedon Oct 20, 2026
Delivered and verified on
mainin merged PR #836 (commitec08aa008833b9e043af40b8b02eca715be11c5d). Cashiers can open and close cash shifts with opening float tracking, automated variance computation, shift enforcement gates, and session Z printing (main/routes/cash-sessions.ts,main/routes/cash-closures.ts,main/services/shift-session-gate.ts,tests/cash-sessions.test.ts).