Opening a new store in LS Central: the setup checklist that prevents go-live fires

Implementation · 9 min read

Opening a new store in an existing LS Central chain is not a big-bang project. It is a short chain of records that have to exist in the right order, because each one is referenced by the next. Build them out of order and the failures show up at the worst possible moment: the first logon, the first card payment, or the first end-of-day statement. This checklist builds a new retail store in dependency order and finishes with a verification pass, so the go-live fires never start.

Scope note: this guide assumes LS Central is already running for other stores and the new store joins the same company. First-time LS Central installation is a different project.

Why order matters in a new-store build

Three resolution rules drive the whole sequence. First, a store needs a location underneath it: the relevant locations have to be created and set up as a store location which is active for Replenishment, with the field Active for Autom. Replenishment on the Location card set to True. Second, the POS profiles that decide behaviour and hardware are resolved through a fallback chain (covered in Step 3), so a blank field is a decision, not an omission. Third, several checks only work when head office and the store agree: for the missing-transaction check in statement calculation, the Functionality Profile must be the same for HO and Stores. Set these foundations first and the terminal setup becomes routine.

Step 1: Location and store record first

1. Create the location. Create the store location and set Active for Autom. Replenishment to True on the Location card. Without a store location there is nothing for the store record, replenishment, or transfers to point at.
2. Create the store record. Add the new store and confirm the side effects: when a new store is created, the system automatically introduces a store group of type Store for the store itself and also adds it to the global store group of type ALL. Store groups describe a selection of stores treated similar in Replenishment, and the types are ALL, Store, and Group.
3. Decide on extra store groups. If the new store should receive the same item distribution as a sister store, add it to the matching user-defined Group store group now. Doing this before items are distributed is far easier than repairing assortments after opening week.
4. Add sections and shelves only if they will be used. Sections and shelves define the store on a lower level and can be used in capacity planning. A small store that will never run capacity planning can skip them safely.
5. Fill the store's Commerce fields only if the store sells online. The Omni FastTab in the Store Card holds the Commerce settings: select the Web Store and Loyalty check boxes if using Loyalty and eCommerce, select Mobile if using Mobile POS, and set the Web Store POS Terminal, Web Store Staff ID, and Web Store Customer No. fields. A bricks-only store leaves these alone.

Step 2: Number series and tender types before terminals

Terminals produce numbered transactions from the first test sale, so numbering has to be settled before any terminal is switched on. In Business Central, a number series is assigned where it is used: on the setup page for the area, on the Number Series FastTab, and the selected series then fills in the No. field on cards and documents. If more than one number series exists for the same kind of information, relationships can be created between the series so the right code can be selected where a number is needed.

Apply that pattern deliberately for a new store. Decide whether the new store shares the chain's existing transaction numbering or gets its own related series, and set the choice up before the first sale rather than after the first statement. Do the same for tenders: the tender types the store will actually take on day one — cash and card at a minimum — must exist as setup before cashiers are trained on them, because the tender declaration at close can only count tenders that were set up to be counted. Retrofitting a tender after a week of trading means a week of declarations that do not match how money was actually taken.

Step 3: Profiles — decide store-level vs terminal-level

LS Central has five POS profile types: Interface, Menu, Functionality, Style, and Hardware. The Functionality Profile includes different POS functionality that decides the POS behaviour; the Hardware Profile holds the setup for the POS hardware, meaning which hardware is in use and how it is set up. All five profiles can be connected to Stores and Terminals, and the Interface, Menu, and Style profiles can also be connected to Staff Cards and to the Store Link Lines in the Staff Card.

The active profile for a session is resolved in a fixed order: first the Store Links on the Staff card, secondly the Staff card, thirdly the Terminal card, and finally the Store card; when no profile value is found, the system uses the ##DEFAULT profile as the active value. Whenever the POS finds a value, that value becomes active and the search stops. Two practical rules follow. Set the chain-standard profiles on the store record and leave terminal fields blank wherever the terminal is standard — one place to maintain. Only write a profile value on a terminal card when that terminal genuinely differs, because that value will override the store for every cashier who uses it. And make sure a ##DEFAULT profile exists for each profile type: it is the safety net that becomes active when nothing else is found, not a leftover from the demo data.

Step 4: Terminal records and hardware

1. Create one terminal record per physical till, linked to the new store. Before using Commerce Service with a new company, the general data setup includes stores and terminals, including a web store and web terminal for eCommerce — so create the web terminal at the same time if the store trades online.
2. Assign profiles at the store level first, per Step 3, and add terminal-level values only for exceptions.
3. Sync the hardware. To enable LS Hardware Station in the Web POS, the Hardware Station is synced to a Hardware Profile: select the Sync with LS Hardware Station check box and insert the correct URL in the Hardware Station Host field, then click Detect Hardware so all available devices are added to the hardware profile, each in its relevant FastTab. The full device procedure is covered in the hardware profiles guide.
4. Create the staff who will log on for testing. A terminal that nobody can log on to cannot be verified, and go-live day is the wrong time to discover that.

Step 5: The pre-opening verification procedure

1. Log on at every terminal with a real staff ID and confirm the POS opens with the expected look and behaviour. A wrong profile shows up here first.
2. Run a test sale in each tender type the store will take — cash and card at minimum — and confirm each sale completes and a receipt prints.
3. Void one test transaction and confirm the void completes. Voids exercise manager and tender paths that a plain sale does not.
4. Run a tender declaration for the test amounts and confirm the counted tenders match the test sales.
5. Calculate a statement. The missing-transaction check lets the store manager verify that all transactions on the POS are actually present when the statement is calculated: activate it by selecting the Check for Missing Transactions field in the Functionality Profile(s) used at the Store or POS, remembering that the profile must be the same for HO and Stores. The system compares the highest Transaction No. in the local database against the highest Transaction No. in the POS terminal's database, and if transactions are missing on a terminal, a page shows which terminals are affected and offers the chance to abort the calculation.
6. Clear the test data per your chain's procedure so opening-day figures start clean.

What success looks like: every terminal logs on, sells in every tender, prints, voids, declares, and the first statement calculates with no missing-transaction warning. Anything less is a setup item to finish before doors open, not a surprise to debug in front of customers. The end-of-day routine that follows from here is covered in the statement reconciliation guide.

Decision framework: copy an existing store or build fresh

The comparison rule is simple: copy when the two stores should behave identically a year from now, not just on opening day. Every copied terminal-level profile value is an override that will silently win over future store-level changes, so a copied store deserves one pass through its terminal cards deleting overrides that are no longer exceptions.

FAQ

Can terminals be created before the store record? No. Terminals belong to a store, profiles resolve through the store as the final explicit level, and the store group side effects only happen when the store is created. Store record first, terminals after.

What happens if a profile field is left blank everywhere? The ##DEFAULT profile for that type becomes active. That is safe if ##DEFAULT is maintained as the chain standard, and confusing if it still holds demo settings.

Does the new store need its own number series? Not automatically. Business Central supports related number series for the same kind of information, so the choice is a reporting and control decision: share the chain series for simplicity, or relate a store-specific series where separate numbering is required. Decide before the first sale either way.

Disclaimer: setup field names and locations reflect the LS Central and Business Central documentation cited for this guide and can vary by version and localisation. Verify against your own version before a production go-live.