Store and terminal records in LS Central: the two setup cards everything else hangs off

Implementation · 9 min read

Every LS Central implementation, whatever else it includes, stands on two records: the store and the POS terminal that belongs to it. Store Management in LS Central covers the setup and maintenance of stores, terminals, and sales staff — and of the three, the store and terminal cards are the pair that everything else references. Profiles attach to them. Statements collect sales against them. Get these two cards right and the rest of the setup has something solid to hang off; get them muddled and every later problem looks like it comes from somewhere else.

Two cards, two different jobs

The store card represents the trading location: the unit that sells, holds stock, and closes a statement at the end of the day. With store statements, the POS sales data is collected per store and then posted to inventory, customer, and the general ledger — so the store record is where sales stop being till activity and start being accounting.

The POS terminal card represents one till point inside that store. A store can run several terminals, and each terminal can differ from its neighbours where the physical setup differs — different hardware, a customer-facing display, a self-service role. The rule of thumb that keeps this manageable: the store card holds what is true for the whole location; the terminal card holds only what is different about this one till. Most of what follows is about enforcing that split, because LS Central's profile system is built to reward it.

What lives on the store card

Beyond the store's identity, the store card carries the store's set of POS profile assignments (covered in the profile section below) and channel settings that apply to the store as a whole. A concrete example is the Omni FastTab, which holds the settings needed for Commerce Service and eCommerce:

• Web Store and Loyalty check boxes — selected if the store uses Loyalty and eCommerce.
• Mobile check box — selected if the store uses Mobile POS.
• Web Store POS Terminal — assigns a default POS terminal for Loyalty and eCommerce transactions. Note what this implies: at least one terminal record must exist before this store-level field can point anywhere.
• Web Store Staff ID and Web Store Customer No. — the default staff and customer attached to those transactions.
• Web Store Shipping Cost Item — the item that handles shipping cost.

The pattern generalises: if a setting describes the store's trading behaviour rather than one till's behaviour, it belongs on the store card, set once.

What lives on the POS terminal card

The terminal card carries its own profile assignments plus the fields that describe this specific till point. Two documented examples show the flavour:

• Dual Display. The LS Central Dual Display — the customer-facing screen that can show what is being sold in a transaction or selected offers — is configured in the BackOffice and must be enabled in the POS Terminal Card to run. Its settings sit in the Dual Display FastTab on the terminal card, including Dual Disp. Enabled and Dual Disp. Interface Profile. The Dual Disp. Screen field is 0 by default and only needs changing when the terminal has more than two screens.
• Idle and slip behaviour. The terminal card's AutoLogoff After (Min) field determines after how many idle minutes in Payment mode the system voids the order and displays the idle screen, and Allow AutoLogoff in Sales Mode controls whether the POS can time out even with an open, unfinalised transaction. The Sales Type Filter field holds the sales types the terminal may use, configured as a filter with | between sales type codes, and the card also carries the terminal's Sales Slip and Void Slip print behaviour.

None of these are store-wide truths. The next till over may have no second screen and a completely different idle policy — which is exactly why they sit on the terminal card.

The profile stack: five profiles, two cards, one resolution order

The POS layout, look, and functionality are configured mainly in five types of POS profiles, which are then linked to stores, terminals, and/or staff:

When the POS loads, exactly one profile of each type is active, and the system finds it in a fixed order: first the Store Links on the staff card, secondly the Staff card itself, thirdly the Terminal card, and finally the Store card. The moment a value is found, the search stops and that value is active. If no value is found anywhere, the ##DEFAULT profile becomes active — which is why LS Retail recommends that every profile type has a ##DEFAULT profile in every company setup.

Read that order carefully, because it inverts a common assumption: for profiles, the store card is the last resort before ##DEFAULT, not the first. A value left on a terminal card silently outranks the store value. That is a feature when it is deliberate — and a classic source of "I changed the store and nothing happened" when it is not.

Setup procedure: store first, terminal second

1. Confirm the ##DEFAULT profiles exist. Before creating any records, check that each of the five profile types has a ##DEFAULT profile. It is the safety net the resolution order falls back to, and the place shared setup (such as a payment menu identical for all stores) should live — held once in ##DEFAULT rather than copied into every profile.
2. Create the store record. Set up the store as the trading unit the statement will be calculated for.
3. Set the store's profile assignments. On the store card, assign the profiles that describe this store. Leave a profile field empty where ##DEFAULT or a terminal-level value should govern — empty is a meaningful setting, not a gap.
4. Set store-level channel fields. If the store trades online, complete the Omni FastTab as far as possible now (Web Store, Loyalty, Mobile); the Web Store POS Terminal field gets filled in step 6, once a terminal exists to point at.
5. Create the terminal records, one per till. Each terminal belongs to the store. Leave its profile fields empty wherever the store value (or ##DEFAULT) is the intended behaviour.
6. Finish the cross-reference. Back on the store card, set Web Store POS Terminal, Web Store Staff ID, and Web Store Customer No. if the store uses Loyalty or eCommerce.
7. Add terminal-only hardware and behaviour. On terminals that need them: enable Dual Display in the terminal card's Dual Display FastTab, and set AutoLogoff After (Min), Allow AutoLogoff in Sales Mode, Sales Type Filter, and the slip fields to match how that till actually works.
8. Apply overrides sparingly. Where one terminal genuinely differs — the documented example is a different printer — set the overriding profile on that terminal only, and leave every other terminal empty.

Store-level or terminal-level? A decision framework

LS Retail's own hardware example shows the intended pattern. In a company with two printer types across five stores of ten terminals each, two hardware profiles are defined: ##DEFAULT for the common printer and a second profile for the other. Every store and every terminal with the common printer leaves the Hardware Profile field empty; only the terminals with the second printer carry its value. Result: five filled fields instead of fifty. Later, when one store replaces all its printers, the new profile goes on that store's card and the terminal values are cleared — the store value becomes active for all its terminals at once.

• Same for every till in every store? Put the shared content in ##DEFAULT and leave store and terminal fields empty.
• Same for every till in one store, different elsewhere? Set it on the store card; clear it on that store's terminals.
• Different on one till only? Set it on that terminal card — and nowhere else.
• Different per cashier? That is what staff cards and their store link lines are for; they sit above both cards in the resolution order.

What success looks like

• Each of the five profile types has a ##DEFAULT profile.
• Starting the POS on any terminal resolves one active profile of each type, and you can trace each one to the level that supplied it: staff store link, staff, terminal, store, or ##DEFAULT.
• Terminal profile fields are empty except where that till genuinely differs from its store.
• Changing a profile on the store card changes behaviour for every terminal in the store that has no override — test this on one profile before relying on it.
• For a store using Loyalty or eCommerce, the store card's Web Store POS Terminal points at a real terminal record.

Common mistakes

• Filling every field on every card. Fully populated terminal cards defeat inheritance: a later store-level change appears to do nothing because each terminal's own value wins the resolution order.
• Skipping ##DEFAULT. With no fallback profile, a card with empty profile fields has nothing to resolve to.
• Copying shared menus into every profile. A menu that is identical everywhere belongs in ##DEFAULT only; menus missing from the active profile are looked up there automatically. Copies drift apart.
• Setting store web fields before terminals exist. The Web Store POS Terminal field needs a terminal record to reference — sequence the work store, then terminals, then back to the store.

FAQ

Which card wins if both store and terminal specify a profile? The terminal. Resolution runs staff store links, staff card, terminal card, then store card, and stops at the first value found.

Can a cashier get different profiles from the rest of the store? Yes. The Interface, Menu, and Style profiles can also be connected to staff cards and to the Store Link Lines on the staff card, which are checked before the terminal and store — so one staff member can log on with different profiles per store.

Does every store need its own profiles? No. Profiles are shared setup linked to records, not part of the records. Stores with the same layout and behaviour can rely on the same profiles — or on ##DEFAULT alone.

Version note: Profile and field behaviour above follows the LS Central documentation for recent releases; profile pages and FastTabs can differ slightly between versions. Confirm field names on your own version before a rollout, ideally in a sandbox company first.