Bitta Retail POS guide
Multi-store operations
Running several stores on one company: per-store settings like location and tax area, terminal-store-company configuration precedence, and cross-location stock visibility.
status: verified applies-to: 1.0.0.121rev: 8
Running more than one store on one Business Central company: what is configured per store, how store-scoped settings layer with company defaults and per-terminal overrides, and how the registers see stock across locations. The building blocks (Store -> Terminal -> POS User) are documented on Stores, terminals, and users; this page is about operating several of them side by side.
What each store owns
A POS Store carries the settings that make one location behave differently from the next:
| Field (POS Store) | What it does |
|---|---|
| Store Code / Name / Address / City / Phone No. | Identity and contact details, printed where the receipt layout uses them. |
| Location Code | The BC inventory location this store sells from. It is stamped onto mapped sale lines and drives pricing context, estimated SKU cost, stock badges, availability, and the location posted to the BC sales line. Configure a valid named location before selling mapped items. |
| Cash Customer No. | Store-level override of the walk-in cash customer used for this store's anonymous sales. Leave blank to use the company-wide cash customer from POS Setup. |
| Tax Area Code / Tax Liable | For an in-store or walk-in sale, the Store Tax Area Code is the primary destination jurisdiction - each store taxes at its own jurisdiction, not the customer's home address. Store Tax Liable is only the liability fallback when no customer authority exists. A configured store with missing or invalid tax setup fails validation instead of silently switching jurisdictions. See Taxes. |
| Active | Whether the store is available for use. |
The Store List also offers a Cash Rounding Policies action that opens the policies list filtered to this store, for per-store cash-denomination rounding overrides; company fallback policies stay on POS Setup. The store carries no "default terminal" or "default salesperson" field of its own - those defaults come from POS Setup and the POS User mapping.
Configuration precedence
Nearly every behavioral choice in the app ships as a scoped setting with a sensible default, resolved from the most specific scope to the most general:
- Print destinations resolve explicit destination -> terminal default -> store default -> company default. See Printers and hardware setup.
- Kitchen routes resolve one scope bucket in terminal, store, then company precedence - scope levels are replacements, never unioned. See Multi-station kitchen routing.
- Terminal overrides let one till differ from the rest of its store: tile size and favorites, tender buttons, receipt transport and printer, drawer-open mode, auto-lock, Price Check disable, card-reader assignment, and scale setup. The full field list is on Stores, terminals, and users.
Some policies are deliberately company-wide and have no store override - notably the pricing governance rules (discount caps, floors, reason requirements) on Pricing and discounts setup. Pricing itself, however, can vary per store by scoping a Pricing Profile to a Store, and store location feeds the standard BC price calculation.
TIP
When a register behaves unexpectedly at one store only, walk the scopes top-down: terminal override first, then store, then POS Setup. The most specific configured value wins.
People across stores
POS Users are mapped to a store and terminal, and to a BC salesperson for attribution. On shared tills, PIN login and the lock screen identify who is ringing regardless of which store they work in - see Security, PINs, and lock screen. Every sale is stamped with its store and terminal, so shifts, X/Z reports, and analytics can always be scoped to the right till at the right store - see Analytics and reporting.
Stock across locations
Because each store sells from its own BC location, the register can be honest about where stock actually is:
- Tiles show Out and low-stock badges against the current store's location.
- Price Check shows a per-location availability table with the current store pinned first.
- Adding an item that is out of stock locally raises a non-blocking "available nearby" toast naming the location with the most stock.
Availability is the live available-to-sell quantity per item, variant, location, and unit of measure, and selling out-of-stock never blocks a sale. The full computation and setup checklist are on Stock availability.
NOTE
Inventory only moves when the Sales Invoice or Credit Memo posts. In create-order mode, creating the BC Sales Order alone does not move inventory; shipping and posting the order does.