POS Masters: Product Catalog, Promotion Rules, and User Access Control

Every time a cashier scans a packet of biscuits and the screen instantly shows the name, the price, the applicable tax, and a festive discount, a lot of invisible groundwork is doing its job. That groundwork sits in the master data of the Point of Sale (POS) system. Masters are the reference tables that a POS reads from before it can ring up a single sale. Three of them shape almost everything that happens at the counter: the product catalog, the promotion rules, and the user access controls. Understanding how these three are built and connected is the difference between a checkout that flows smoothly and one that produces wrong prices, unauthorised discounts, and accounting headaches.

What master data means in a POS system 🔗

In retail software, a master is a stored set of records that rarely changes during a transaction but is referenced constantly. Think of masters as the system’s long-term memory, while the day’s sales are its short-term activity. When a barcode is scanned, the POS does not calculate anything from scratch. It looks up the scanned code in the product catalog master, pulls the matching price and tax, checks the promotion rules master to see if any offer applies, and confirms through the user master whether the logged-in operator is even allowed to perform the action. Get these masters right and the rest of the system simply executes. Get them wrong and errors multiply across every store and every till.

The product catalog master 🔗

The product catalog master holds information about every SKU (Stock Keeping Unit) the business sells. An SKU is the retailer’s own internal identifier for a sellable item, distinct for each variant of size, colour, or flavour. The catalog is the single source of truth for what a product is, what it costs, and how it should be taxed.

What goes into a single product record 🔗

A well-built product record usually carries several fields. The Article Code, SKU number, or EAN code uniquely identifies the item. The selling price and indirect tax determine the final amount the customer pays. Beyond these, the record typically stores discount conditions, quantity in stock, the manufacturer, the distributor, the brand, the category and sub-category, and a product description. These fields are not just for billing. Category and brand data feed sales analysis, stock figures support replenishment, and the description helps staff confirm they are selling the right item.

Barcodes, EAN, and product codes 🔗

The barcode printed on a pack is most often an EAN-13 code, a thirteen-digit number that retailers worldwide use to identify products at the point of sale. The same number is also called a GTIN (Global Trade Item Number), the umbrella identifier maintained by the global standards body GS1. As GS1 India explains, an EAN-13 is effectively a GTIN-13, and codes issued within the country begin with the prefix 890. It is worth keeping the distinction clear: an SKU is created by the retailer for internal tracking, while an EAN or GTIN is a globally unique number that stays consistent across every store and marketplace that sells the product. A single item can carry both, and many systems let one product hold multiple scannable codes.

Indirect taxes in the catalog 🔗

The original textbook framing lists VAT as the indirect tax stored against each product. In practice, Value Added Tax has largely been replaced. Since 1 July 2017, the Goods and Services Tax (GST) has subsumed VAT, excise, and service tax into a single destination-based levy, as documented by sources tracking the current GST rate structure. Today most goods fall under simplified slabs, so a POS catalog must record the correct GST rate against each SKU rather than a flat VAT figure. VAT still survives only on a few items kept outside GST, such as petroleum products and alcohol. Storing the right tax field per product matters because the POS computes the tax automatically at billing, and a wrong slab leads directly to compliance problems.

Central catalogs in large chains 🔗

In a single shop the catalog can live on the same machine as the till. In a chain with hundreds of outlets, this does not scale. Large retailers maintain the master centrally at head office and then replicate it to each POS terminal, usually with fewer details than the full central record. The store-level copy needs the code, price, tax, and active promotions to complete a sale quickly, but it does not need every back-office field. This central-then-replicate model keeps pricing consistent across the network while allowing each till to operate even when the network connection is briefly unavailable, because the essential data already sits locally.

The promotion rules master 🔗

Promotions are central to modern retail, and the promotion rules master is where their logic is configured. Instead of manually keying in discounts, staff define rules once and the POS applies them automatically whenever the conditions are met. A capable promotions engine can grant offers based on product categories, cart value, customer segment, and more, all without a coupon being typed in.

The kinds of discounts you can configure 🔗

The rule master typically supports several distinct discount types. Item or line-level discounts reduce the price of a specific product on the bill. Bill-level discounts apply to the entire transaction once a condition is met, for example a percentage off when the total crosses a set amount. Product combination discounts reward buying items together, the classic example being “buy one, get one.” Volume or value-based discounts reward quantity or spend, such as a tiered “buy more, save more” offer. Customer-specific discounts target a particular segment or loyalty tier, while time-based discounts run only during a defined window like a weekend sale or a festive campaign.

How the engine decides what applies 🔗

What makes this master powerful is its ability to react to context. A POS can offer a varying discount based on the articles already scanned in the same bill, or based on whether the shopper is a loyalty programme member. This raises a real problem: what happens when several offers qualify at once? Retail pricing engines apply governance rules that decide the order in which promotions stack and whether certain offers are exclusive, meaning they cannot be combined with others. Without such control, layered discounts could push a price far below the intended floor. Defining priority and exclusivity in the rule master is therefore as important as defining the discounts themselves.

User management and access control 🔗

The third master protects the system from misuse, whether accidental or deliberate. The user master stores user details and the access rights attached to each person. A POS handles money, inventory, and pricing, so deciding who can do what is a genuine financial control, not just an IT setting.

The maker and checker principle 🔗

A core safeguard is the maker and checker principle, also known as the four-eyes principle. The idea, as described in the standard definition of maker-checker controls, is that for a sensitive action, at least two people are required: one initiates it and a different person authorises it. In a store, this is why a discount beyond a cashier’s limit needs store manager approval before it goes through. The cashier is the maker; the manager is the checker. This single division of labour deters fraud, because a dishonest act would need two people to collude, and it catches honest mistakes before they are committed.

Segregation of duties 🔗

Closely tied to maker-checker is the idea that conflicting responsibilities should not sit with one person. A common rule is that receiving goods and selling goods are not permitted for the same user. If one employee could both book stock into the system and sell it out, they could conceal theft by manipulating both ends. Separating these duties means the records created by one person are effectively cross-checked by another, preserving the integrity of inventory and cash figures.

Role-based access control 🔗

Managing rights person by person is impractical, so POS systems use role-based access control (RBAC). Users are grouped into categories such as Administrators, Power Users, and Operators, and each role carries a defined set of permissions. Access can be further restricted to the specific devices a user is allotted, so an operator can work only on assigned tills. The principle behind this design is least privilege: a user is given no more access than the job requires. An operator can ring up sales but cannot change prices; a power user might handle returns and limited overrides; an administrator configures the masters themselves. Roles also make staffing changes easy, because the role stays constant even as the people filling it come and go.

Seen together, the three masters reinforce one another. The product catalog decides what is sold and at what price and tax. The promotion rules decide how that price flexes for offers. The user master decides who is allowed to touch any of it. A POS is only as trustworthy as the masters behind it, which is why setting them up carefully is one of the most consequential tasks in retail technology.

What do you think? If you were configuring the promotion rules master for a festive sale, how would you decide which offers should be exclusive and which should be allowed to stack? And where would you draw the line for the discount a cashier can give without manager approval, balancing customer convenience against the risk of misuse?

References

1. https://www.gs1india.org/blog/what-is-a-13-digit-gtin-number-and-why-is-it-important-for-a-retail-product
2. https://www.gs1india.org/blog/ean-13-the-barcode-number
3. https://cleartax.in/s/gst-rates
4. https://fabric.inc/blog/product/enterprise-guide-promotions-engines
5. https://en.wikipedia.org/wiki/Maker-checker
6. https://arxiv.org/pdf/0903.2171