Sharing pantry stock with another business

Sharing a pantry across two businesses

Two separate ibakepro accounts can link their pantries into a shared pool. The stock for a shared item stops living in either account and lives in the pool instead, so both businesses read the same number and every movement is written to one ledger.

Why it exists

Two businesses in one kitchen usually buy the expensive staples together. The flour, the couverture, the cream all arrive on one invoice, sit on one shelf and then get counted twice, once in each system, or not counted at all. Every inventory tool assumes a stock figure belongs to exactly one business, which is why the usual answer is "run two accounts and settle it by memory". That works until a Saturday when both of you plan around the same remaining butter.

Setting up the link

Linking is deliberately a two-person, three-step handshake. Both people must be the owner of their account. A manager or team member cannot start or accept a link, and both accounts have to be in the same data region.

An account can be in one pool with one partner at a time. You cannot link an account to itself, and a code that is guessed at repeatedly stops accepting attempts rather than staying open indefinitely.

What moves into the pool

Seeding runs as soon as the link is confirmed, and the two sides are treated differently on purpose.

Everything active in the primary account's pantry joins the pool. From the second account, only items created at or after the link was made join. Anything that account already had stays private to it. That is the rule that stops a link from quietly absorbing a pantry someone built up before the partnership.

For each item that joins, the quantity is moved out of that account's own count and into the pool as a recorded stock adjustment, not a silent overwrite. The local count then reads zero and availability is read from the pool. A copy of the item appears in the partner's pantry carrying the definition: name, category, unit, cost per unit, supplier, allergens and thresholds. Later edits to those fields propagate to both copies, most recent edit winning. Quantity is never propagated that way, because quantity is the pool's job.

New pantry items created on either side afterwards are picked up automatically within a few minutes, and the shared pantry screen has a re-sync button for when you want it now.

Working with a shared item

Availability for a shared item is the pool balance minus the reservations both accounts hold against it, so your partner's committed orders reduce what you can promise. If more is claimed than physically exists, or the pool balance reaches zero, a notice is written into both accounts, not only the one that triggered it, and it clears itself once the pool recovers.

Design decisions

• It shares the pantry, nothing else. Orders, customers, products, prices and financials stay private to each account. Be aware that a shared item's cost per unit and supplier are part of the definition that syncs, so your partner can see what you pay for it.
• A pool links two accounts, one partner at a time.
• Unlinking runs through support, deliberately. The primary business keeps the physical stock, the other account's shared items go back to holding their own counts and every movement is recorded. Treat linking as a decision you make once rather than one you try out.
• For shared items the pool notice is the signal to act on, since a pooled item's own account count reads zero. Per-account low stock alerts cover the items you hold privately.
• Splitting the shared invoice stays between the two of you.