Best practices to follow when defining naming conventions in LS Central

Often, businesses underestimate the importance of naming conventions when implementing a new system. But setting up a clear and easy-to–follow naming standard can help make deployment simpler and faster.

Instead, it’s very common for companies, or their implementation partners, to use the same names and codes that are provided on the LS Central demo database, without considering the limitations that could affect the deployment process and even processes within the application. However, reusing names and codes increases risk because it becomes impossible to detect what the different elements of the system are, and where they are located, such as POS, stores, locations, etc.

To shorten the deployment process, reduce the amount of work needed, and keep your business running optimally, I highly recommend you define and apply clear naming conventions for all the following entities:

• Instances
• Databases
• Companies
• POS Computers
• Jobs and Subjobs
• Stores, Locations and POS terminals

It’s also always a good idea to use prefixes or suffixes for the instances, databases and companies, to provide  information about what the entity is – for example  PROD_***, UAT_***,DEV_*** – so  the user can easily identify it in the system  (Production, User Acceptance Test, Development, etc.). Make sure to always use a prefix or suffix in your deployment and don’t mix them to prevent confusion.

Naming standards for databases and companies as well as the POS computers will make them easy to find and, in the case of the POS computers, that same name will be inherited from the Data Director after replication.

Here’s what I recommend:

Instances, databases, and company names

I recommended using two or three letters as prefix to identify customers (e.g. CC-Coca Cola, KFC-Kentucky Fried Chicken, LSR-LS Retail, etc.).

Short identifiers (e.g. PROD-Production Database/Instance, TEST-Testing Database/Instance, DEV-Development Database/Instance, etc.).

Some examples:

Store numbers

Prefix (S) – Always 4 digits.

POS terminal numbers

Prefix (Store + POS Terminal No.) – Always 6 digits.

For handhelds, POS terminal numbers start on number 51 for terminal 1, 52 for terminal 2, and so on. These terminal numbers are integral components of the receipt number for POS transactions. The structure comprises the store number followed by the terminal number, with the total length not exceeding 10 characters.

Your LS Retail partner and consultants must take into consideration the number of terminals and stores to define these entities properly. If there is a need to have less than 99 stores and more than 100 POS terminals, you could, for example, use three digits for the store and five for the terminals (e.g. S01 for store 1 and S01001 for the POS terminal 1 of store 1) to clarify the entities better within the system.

POS Computers (Data Director)

Be sure to keep standardized names of the POS computers to make them easy to identify (POS Terminal Code is a good option). It is also recommended not to use spaces for codes; it is better to use one word or use dashes or underscores to separate concepts. Examples of this on the table below:

Jobs and subjobs

Identify the main and related tables that need to be replicated for each area within the application (e.g. Items, POS, Stores, Discounts, KDS, Hospitality, etc.). When setting up scheduler subjobs for related tables, use a prefix to identify which entity the table is related to (e.g. I_*** for items, S_*** for stores, P_** for POS terminals, etc.). By doing this it will be easier for you to group those subjobs to the corresponding job.

You can use the subjobs and jobs on the demo database as a basis – but make sure you refine, update, and configure them to meet your needs. You can find some examples of jobs and subjobs in table below:

Stores and locations

When setting up “Locations” for stores, it is highly recommended that the location code is the same as the “Store No.” This way you can easily identify which location corresponds to which store in the database. Not only: there are some reports within the application that use the location and Store No. indistinctly, so by having the same number you will simplify your life (for example, if store number is defined as S001 then the inventory location code that will be linked to it as the sales location must be S001).

Using a naming convention for at least the entities listed above will provide many benefits. You can simplify maintenance, plan ahead of time when setting up new locations, and more easily configure the distribution locations for replication, since the user will know what parameters to use and how to define the settings for a location that has not been installed or configured.

Another benefit of doing this is that it will be easier to track any communication and/or replication issue.

Ultimately, if you use these best practices for your naming conventions in LS Central, it’ll much faster for you to deploy the LS Central solution, and you can more easily identify all the different aspects of your business within the system should something need to be addressed. Have more questions about LS Central? Get in touch – we’re here to help!