Functionality profiles in LS Central: what the POS settings actually control

Implementation · 9 min read

Ask ten LS Central administrators what the Functionality Profile does and most answers stop at "POS settings." That vagueness has a cost: a behaviour change gets made in the wrong profile, or on the wrong card, and the till carries on exactly as before — until statement day. This guide maps what the Functionality Profile actually controls, how LS Central decides which profile a session is running, and a safe procedure for changing one.

Five profiles, five different jobs

When the POS client starts, one profile of each type is active for the session. LS Central has five POS profile types, and confusing them is the root of most "the setting didn't take" reports:

Within a company it is normal to have more than one setup for each POS profile type; the number depends on the variety of POS setups in use, and profiles can be edited or added later to redefine the look and behaviour of the POS. The demo data company ships several profiles of each type as examples, including profiles set up and used for Hospitality — useful as a reference, risky as a production starting point if nobody has read them.

What the Functionality Profile actually controls

The Functionality Profile is the behaviour layer. Four groups of settings matter most in day-to-day retail:

• Currency presentation. The POS Currency Symbol field contains a symbol representing the currency, such as a $ symbol for the Dollar currency. If a POS terminal is running on the local currency set up for the POS Functionality Profile, the terminal uses the currency symbol set up in the POS Functionality Profile for the store. A wrong symbol on receipts and screens is a profile problem, not a printer problem.
• Automatic logon for unattended terminals. Automatic Logon Staff is the staff member logged in to the POS on a self-service kiosk, and all self-service sales are registered to that staff member. Kiosk setups also use the profile's POS Currency symbol and the Placement of LCY in amount text setting. If kiosk sales are landing on the wrong staff record, this is the field to check.
• Transaction sending. LS Central 17.0 added a web replication way to send transactions from the POS using Web Requests. To activate that option, change the POS Functionality Profile Card on the Service Settings FastTab and enable the Use Background Session option — enabling it is mandatory in order to use this type of Web Replication method. A terminal that stops sending transactions after a profile change has usually had this area touched.
• Statement safety checks. The missing-transaction check in statement calculation is activated by selecting the Check for Missing Transactions field in the Functionality Profile(s) used at the Store or POS. Two conditions decide whether it works at all: the Functionality Profile must be the same for HO and Stores, and the check only applies if the Closing method at the store is by POS Terminals. If no POS or Terminal is chosen during statement calculation, the system uses the Functionality Profile from the Store.
• External service endpoints. A Functionality Profile can also carry service addresses: in Customer Order Setup, the Omni Func. Profile ID selects the Functionality Profile that includes the URL to Commerce Service, and that profile holds the URI that points to the Commerce Service that should receive messages. Changing the wrong profile can quietly break order messaging while the tills look perfectly normal.

Which profile is active: the resolution order

All five profiles can be connected to Stores and Terminals. Three of them — Interface, Menu, and Style — can also be connected to Staff Cards and to the Store Link Lines in the Staff Card. The Functionality and Hardware profiles are therefore assigned at store and terminal level only, which narrows the search when behaviour differs between tills.

When the POS loads, it looks for which profile should be the Active Profile for the session, in this order: first the profile value in Store Links on the Staff card, secondly the profile value on the Staff card, thirdly on the Terminal card, and finally on the Store card. When no profile value is found, the system uses the ##DEFAULT profile value as the active value. Whenever the POS finds a value, that value becomes the active value and the search stops.

That single rule explains the most common functionality-profile complaint. An administrator edits the store's Functionality Profile, restarts the POS, and nothing changes — because a value on the terminal card is found earlier in the search and the store card is never reached. The fix is not a stronger edit; it is removing or aligning the terminal-level value. Connecting profiles in the Store Link Lines also makes it possible for a Staff ID to log on to the POS with different profiles per store, which is powerful for staff who float between formats and confusing when it was set up once and forgotten.

The ##DEFAULT safety net — and its trap

Each profile type in the demo data includes a profile with ID ##DEFAULT, and it is highly recommended to have a ##DEFAULT Profile in all company setups. Its first purpose is fallback: if no active profile is found, the ##DEFAULT profile automatically becomes the active profile. Its second purpose is reuse: a menu that is identical for more than one menu profile should be located in the ##DEFAULT profile and only there, so shared setup is maintained once instead of per profile. The Interface, Menu, and Style profiles carry a lot of assigned data, and if the active profile does not include the data the POS is asking for, the system looks for it in another profile according to the Search Profile Rule.

The trap is treating ##DEFAULT as a scratch area. Because it is the fallback for every terminal with a blank assignment, an experiment saved into ##DEFAULT is live everywhere at once. Treat ##DEFAULT as production configuration with the widest blast radius in the system, and test experimental behaviour in a named profile assigned to one terminal.

Procedure: change a functionality profile safely

1. Identify the active profile first. Walk the resolution order for the affected terminal — Staff Store Links, Staff card, Terminal card, Store card — and write down the first Functionality Profile value found. That is the profile to change; editing any other one changes nothing.
2. Copy before editing. Create a copy of the profile under a new ID and make the change there. The original stays untouched as the rollback.
3. Assign the copy to one pilot terminal on its Terminal card, leaving the store assignment alone.
4. Restart the POS on the pilot terminal so it loads the newly assigned profile for the session.
5. Run a full test sale covering the changed behaviour, plus a payment and a void, and confirm receipts show the expected currency symbol and amounts.
6. If transactions are involved, confirm they arrive centrally before widening the change — especially after touching Service Settings such as Use Background Session.
7. Roll out by assignment level: move the change to the store card (and clear pilot terminal overrides) only after the pilot passes, or promote the tested settings into the existing store profile.
8. Record which profile each store runs. The statement missing-transaction check depends on HO and Stores running the same Functionality Profile, so an undocumented per-store divergence disables a safety check silently.

What success looks like: the pilot terminal shows the new behaviour, test transactions reach the central transaction list, receipts render the correct currency symbol, and the store's next statement calculates with the missing-transaction check still active. If any of those fail, the copy-based setup makes rollback a single assignment change.

Decision framework: one profile per chain, per store, or per terminal

• One per chain (default): choose this when stores trade the same way. It keeps the HO/Stores sameness the statement check requires and makes every behaviour change a single edit.
• One per store: choose this only for a genuine format difference, such as a self-service kiosk store that needs Automatic Logon Staff. Budget the maintenance: every chain-wide behaviour change now happens once per store profile.
• One per terminal: reserve this for pilots and for terminals with genuinely different roles. A permanent terminal-level profile is an override that wins over every future store-level change, so it should be rare, named clearly, and reviewed whenever store settings change.

The spec-verification habit that keeps this manageable: whenever behaviour at a till surprises you, verify the active profile by resolution order before changing any field. Most functionality-profile incidents are assignment incidents, not setting incidents.

FAQ

A setting was changed on the store profile but the till did not change. Why? A value earlier in the resolution order — Staff Store Links, Staff card, or Terminal card — is winning. Find the first value in the order; that profile is the active one.

Can staff carry a Functionality Profile? No. Only the Interface, Menu, and Style profiles can be connected to Staff Cards and Store Link Lines. Functionality and Hardware profiles resolve through Terminal and Store only (with ##DEFAULT as fallback).

Is ##DEFAULT just demo data? No. It is the recommended fallback for every profile type and the shared home for data reused across profiles. Deleting or casually editing it affects every terminal without an explicit assignment.

Disclaimer: field names and FastTab locations reflect the LS Central documentation cited for this guide and can vary by version. Confirm against your own version's POS Functionality Profile Card before changing production profiles.