~15 containers a week move through one warehouse into three channels. None of them report back what they took.
Ocean freight from US mainland suppliers lands in one central warehouse. Three channels draw from it: Wholesale/B2B (hotel clients), Cash & Carry (walk-in commercial), Retail (POS supermarket). No system records those withdrawals.
Cost is margin, not reporting. Replenishment is guessed from a visual walk, so fast movers stock out while slow movers spoil. Stock informally held for a hotel delivery can be sold over the counter the same day, breaking a committed B2B order.
One centralized web system owning a single stock ledger across the warehouse and all three channels. Goods captured once at receiving as a batch. Warehouse-to-department moves logged as transfers. Every sale writes a deduction — automatically where the channel is a system, by a fast screen where it is not. GK Foods owns the platform outright, no per-seat licence.
Receiving capture, central stock ledger across warehouse and all three channels, internal transfers, UOM conversion, outbound deduction from every channel including POS integration, batch and expiry tracking, shrinkage logging, replenishment analytics, role-based access.
Accounting, payroll and tax stay in QuickBooks. This system is the record for stock and feeds accounting, not the reverse. Commercial terms handled separately.
Severity reflects revenue and margin exposure, not effort to fix.
| ID | Pain point | Sev | Today | Impact | Solution | Module |
|---|---|---|---|---|---|---|
| P-01 | No real-time stock visibility | Critical | Three channels draw from the warehouse with no deduction event. At close of day nobody knows what remains. | Ordering, B2B commitments and pricing all rest on a number nobody can verify. | One central ledger. Every movement writes a row against product + location. On-hand is derived, never typed. |
Inventory · Ledger |
| P-02 | Internal transfers unrecorded | Critical | Retail and Cash & Carry pull stock off the warehouse floor as they run down. The move is never logged. | Warehouse and department both count the same stock. Neither knows its own true position. | Stock transfer module: warehouse-to-department moves logged as their own event type, with department-level on-hand. Sales then deduct from department stock, not the warehouse. | Internal Transfers |
| P-03 | Channel collision on shared stock | Critical | 100 cases arrive; Wholesale mentally reserves 50 for hotels. Walk-ins clear those 50 in a day. Wholesale never told. | Broken hotel delivery commitments on the highest-value revenue line. | Allocation layer — B2B orders hard-hold quantity, so other channels see only the truly sellable balance. Large-movement alert fires to purchasing on any bulk withdrawal. | Checkouts · Allocation · Alerts |
| P-04 | Unit-of-measure chaos | Critical | Invoice reads 100 cases, 1 case = two 2 lb bags. Retail sells by the pound, Cash & Carry by case or weight, Wholesale by case. Reconciled mentally. | Counts never tie. Real loss hides inside conversion error. | One base unit per product, conversions on top. Each channel transacts in its own unit; the system converts once, the same way every time. | Catalog · UOM |
| P-05 | Mixed-pallet receiving gap | High | ~15 containers weekly, one 8 ft pallet holding several SKUs at different quantities and weights. Piece-scanning at the dock is not viable. | The best moment to set an accurate opening balance is missed on every shipment. | Pallet logged as a batch; invoice lines entered at SKU level against it, not pallet-only. Piece detail added at breakdown, off the critical path. | Inbound · Batches |
| P-06 | Paper-only supplier invoices | High | US suppliers send hard copy only. No CSV, no EDI, format not changeable on request. | Receiving entry is manual by necessity — slow, late, error-prone. | Fast keying screen matched to the real invoice layout: supplier line templates, remembered case configurations, invoice photo attached to the batch for audit. | Inbound Items |
| P-07 | Blind purchasing decisions | High | Staff walk the warehouse and estimate before ordering. No sales history exists. | Simultaneous stockouts on fast movers and overstock spoilage on slow movers — margin lost at both ends. | Consumption rate per SKU from ledger history, with reorder point, suggested order quantity and supplier lead-time buffer. | Analytics · Alerts |
| P-08 | Retail POS operates as a silo | High | Retail scans barcodes into QuickBooks Enterprise. Those sales never reduce stock. | The one channel already producing clean digital data contributes nothing to accuracy. | Pull sales transactions from QuickBooks Enterprise, post matching outbound movements automatically. See section 10. | POS Integration |
| P-09 | Cash & Carry outbound uncaptured | High | Counter sales recorded for cash but not as stock movements. Method to confirm — Q-03. | A high-volume channel deducts nothing, capping ledger accuracy regardless of what else is fixed. | Two-tap checkout screen: pick product, enter quantity in the counter's own unit, confirm. Fast enough for counter tempo. | Checkouts |
| P-10 | Perishables have no batch identity or rotation rule | Medium | No received-date or expiry on produce and frozen goods. Rotation depends on whoever is picking. Damage discarded unrecorded and still counted as sellable. | Older stock buried behind newer stock and spoils. No basis for recall or supplier quality claim. Loss invisible. | Batch identity from receiving carried through every movement, expiry alerts, and FEFO pick order for dated stock (FIFO where undated). Write-offs with reason codes report loss by SKU, supplier and channel. | Batches · Adjustments · Alerts |
| P-11 | No audit trail on stock loss | Medium | Stock goes missing with no record of who moved what, or when. | Losses cannot be investigated; no corrective action can be targeted. | Every movement stamped with user, timestamp, channel and reference document. Immutable — corrections post as offsetting entries, never edits. | Ledger · Users |
| C-01 | Recurring licence cost sensitivity | Constraint | Management is cautious about enterprise software carrying per-seat licensing and monthly fees. | Shapes what solution is acceptable, regardless of technical merit. | Owned, modular web platform built on the existing QuickBooks and POS estate. Deployed phase by phase, each phase useful on its own, so spend tracks delivered value rather than seat count. | Architecture · Phasing |
GK Foods has no system of record for stock movement.
The warehouse holds a paper truth. The POS holds a partial digital truth for one channel. Wholesale holds an undocumented truth in the manager's head. Cash & Carry holds a cash truth with no stock dimension. None reconcile, and none can be promoted to authoritative — each covers only a fragment.
That determines what the fix has to be. Fixing the symptoms individually fails:
The fix is one ledger all four locations write to, with capture fitted to how each physically works.
On-hand is always the sum of movements. No editable quantity field exists. Corrections post as offsetting movements with a reason code — auditable end to end, impossible to quietly overwrite.
Warehouse and each department are separate locations. Moving stock to Retail or Cash & Carry is a logged transfer; the sale then deducts from that department. No stock is counted twice.
Cases, bags, pallets and pounds are conversions on top of a declared base unit. Channels keep their natural units; the system does the arithmetic once, correctly.
Batch capture at the dock because it is fast. Automatic POS integration where data already exists. A two-tap screen at the counter. Forcing one method on all three is what gets systems bypassed.
| Module | What it does | Closes |
|---|---|---|
| Dashboard | Daily operating picture: stock value, low-stock and expiring counts, recent movements, open alerts. | P-01 P-07 |
| Suppliers | Supplier master with terms, lead times and receipt history. Lead time feeds reorder calculation. | P-07 |
| Inbound Items | Container and invoice receiving. Creates batches, captures SKU-level lines fast, attaches the invoice photo, posts inbound movements. | P-05 P-06 P-10 |
| Product Catalog | SKU master with category, base unit, conversions, barcodes, reorder point, channel pricing. | P-04 P-07 |
| Inventory | On-hand by product and location, full movement ledger, batch and expiry view, adjustments and write-offs with reason codes. | P-01 P-10 P-11 |
| Internal Transfers | Warehouse-to-department moves as a first-class event: request, issue, receive. Gives Retail and Cash & Carry their own on-hand. | P-01 P-02 |
| Checkouts | Outbound for Cash & Carry and B2B: pick lines in the channel's own unit, allocate against batches, confirm, post the deduction. | P-03 P-09 |
| POS Integration | Reads retail sales from QuickBooks Enterprise, posts matching outbound movements, reconciliation report for unmatched lines. | P-08 |
| Analytics | Consumption rate per SKU, reorder suggestions, shrinkage by SKU and supplier, channel mix, stock-value trend. | P-07 P-10 |
| Alerts | Low stock, expiry window, allocation conflict, negative-balance anomaly, and large-movement notice to purchasing after any bulk withdrawal. | P-03 P-07 P-10 |
| Settings & Users | Locations, units, categories, alert thresholds, role-based permissions per channel. | P-11 |
A clickable prototype of these screens accompanies this document — see the prototype dashboard.
Internal labels printed and applied at receiving, produce included. Every later movement is a scan.
Strengths
Constraints
Receiving keyed from the supplier invoice at SKU level. Outbound automatic from the POS, near-automatic at the counter.
Strengths
Constraints
Start with Option B, layer Option A onto high-value and high-shrinkage categories. Two reasons. Dock velocity — ~15 containers weekly on 8 ft mixed pallets — makes scan-everything a poor day-one bet, and a system that slows the bay gets bypassed. And the loss is on the outbound side, which Option B closes immediately. Barcode capture then becomes an accuracy upgrade on a system already in daily use.
| Operation | Today | With the system |
|---|---|---|
| Container receiving | Paper invoice checked by eye; nothing recorded. | Pallet logged as a batch, SKU lines keyed once, stock live the same day. |
| Knowing what is on hand | Walk the warehouse and estimate. | Open the screen — on-hand by product, location and batch. |
| Stock to Retail / Cash & Carry | Taken off the floor, never recorded. | Logged transfer. Department gets its own on-hand; warehouse drops by the same amount. |
| Retail sale | POS records money; warehouse learns nothing. | Sale syncs from QuickBooks and deducts automatically. |
| Cash & Carry sale | Cash recorded; stock movement invisible. | Two-tap checkout in the counter's own unit; deduction on confirm. |
| Hotel B2B order | Reserved in someone's head; can be sold out from under the commitment. | Hard allocation. Other channels see only the sellable balance. |
| Bulk walk-in withdrawal | Nobody finds out until stock is gone. | Large-movement alert to purchasing as it happens. |
| Unit conversion | Cases to pounds to pieces, done mentally, differently by each person. | One conversion table per product, applied identically everywhere. |
| Reordering | Guessed from a visual count. | Consumption rate and lead time produce a suggested quantity per SKU. |
| Stock rotation | Depends on whoever is picking; old stock buried and spoils. | FEFO pick order on dated stock, with expiry-window alerts. |
| Spoilage | Discarded, unrecorded, still counted as sellable. | Written off with a reason code; reported by SKU, supplier and channel. |
| Loss investigation | Not possible. | Every movement carries user, timestamp and reference document. |
GK Foods runs QuickBooks Enterprise Solutions (Intuit). Narrow, one-directional objective: read completed retail sales, post a matching stock deduction. Nothing is written back into the accounting records — this system is authoritative for stock, QuickBooks stays authoritative for accounting. No competing set of books.
| Deployment | Route | Assessment |
|---|---|---|
| Enterprise Desktop, local or hosted | Web Connector with qbXML, or Desktop SDK against the company file | Well-trodden Standard supported route, configurable polling. |
| Enterprise via QuickBooks Online | Intuit REST API plus webhooks | Cleanest Event-driven, near-real-time deduction. |
| Separate POS feeding QuickBooks | Integrate the POS directly; QuickBooks stays accounting-only | Depends Often better — data at source, richer detail. |
| No usable interface | Scheduled export ingestion (IIF / CSV / report export) | Fallback Works, but batch-lagged. |
The route depends on two unknowns: the exact Enterprise edition and year, Desktop or hosted; and whether the retail POS is the QuickBooks POS module or separate software exporting into it. Questions Q-01 and Q-02. Every route above is workable — the answers pick which one, not whether.
Any sale that cannot be mapped to a catalog SKU lands in an exception queue rather than being silently dropped — which matters most for produce sold by weight and POS codes that have drifted from the product master. A daily report shows sales captured, movements posted and exceptions outstanding, so integration health is visible rather than assumed.
Product catalog with base units and conversions, supplier master, locations, users and roles. Item master imported from the existing SKU spreadsheet.
Useful alone: one clean product and unit definition shared across all three channels for the first time.
Batch receiving from invoices, movement ledger, on-hand by location, batch and expiry tracking, write-offs.
Useful alone: an accurate opening balance and a real receiving record — what was originally asked for.
Internal transfers to Retail and Cash & Carry, counter checkout screen, B2B pick and delivery with allocation, QuickBooks sales sync with reconciliation.
Useful alone: closes the loop. From here the on-hand figure is trustworthy.
Consumption rate, reorder points and suggested orders, shrinkage reporting, full alerting, then barcode capture on selected categories.
Useful alone: ordering shifts from guesswork to calculation, on history the earlier phases accumulated.
Phases 1 and 2 run against live receiving alongside existing paper practice, so nothing is at risk during changeover. Paper is retired only once Phase 3 reconciles cleanly for a full week.
No baseline exists today — that is itself the finding. Each is captured during Phases 1 and 2 so improvement can be demonstrated rather than asserted.
| Metric | Baseline today | Target once live |
|---|---|---|
| Stock record accuracy vs physical count | Not measurable; no system record | 98%+ on cycle count, by value |
| Stockout events per week, A-class SKUs | Unknown; not logged | Reduced against Phase 2 baseline, reorder alerts firing before depletion |
| B2B order fill rate | Unknown; shortfalls handled informally | No shortfall caused by another channel selling allocated stock |
| Spoilage loss (USD by SKU) | Not quantified | Quantified from Phase 2 day one, then reduced via FEFO and expiry alerts |
| Time counting stock before ordering | Manual walk before every order cycle | Replaced by an on-screen figure |
| Receiving-to-visible lag | Never becomes visible | Same working day |
| Risk | Why it could bite | Mitigation |
|---|---|---|
| Receiving keying skipped when the dock is busy | One unkeyed invoice makes the ledger wrong, and one wrong day erodes trust in the whole system | Keying is off the critical path, minutes per invoice. Unreceived-container alert fires if a delivery is logged but lines are not entered by end of shift. |
| Transfers skipped when a department restocks in a hurry | Department sells stock the ledger still shows in the warehouse — reintroduces the original problem | Transfer is two taps and required before a department can sell. Negative department balance triggers an immediate anomaly alert. |
| QuickBooks interface more limited than expected | Retail deduction falls back to batch lag rather than real time | Four routes in section 10 including scheduled-export fallback. Confirmed before build starts. |
| Unit conversions wrong at setup | A bad case-to-weight factor silently corrupts every movement for that SKU | Verified against physical samples in Phase 1, then locked with change history. Anomaly alerts flag impossible balances. |
| Counter staff bypass the checkout screen at peak | Largest remaining manual capture point, easiest to skip | Two-tap design tested against real counter tempo before rollout. Daily variance report makes gaps visible immediately. |
| Weight-sold produce cannot be matched to a SKU | Weight-based POS lines may carry no clean product code | Exception queue plus a mapping table in the catalog. Nothing silently dropped. |
| Item master incomplete or inconsistent | Garbage in the catalog undermines every downstream number | Import and clean the SKU spreadsheet in Phase 1, with a duplicate and gap report before go-live. |
Q-01 to Q-04 shape the architecture and are needed before build. The rest shape detail and can follow.
Sections 3 and 4 derive from the warehouse operations discovery session — full transcript and structured summary in gk_foods_transcript_and_summary.md.