0

This question relates to large retail POS systems, such as those used by Walmart and other large chains.

Is there a language which is commonly used by such systems to define price rules for items? I am trying to understand how a POS can apply so many rules when calculating prices of items. For example, the system has to account for sale prices based on date/time/coupon/number of items purchased. It must account for buy-one-get-one, buy several in a category and get something, get a coupon if a specific item is purchased, multiple-item discounts, membership card pricing, etc...

I want to understand how such a set of disparate rules would be

  1. created easily
  2. made simple for system administrators to keep up-to-date
  3. applied efficiently by hardware during the checkout process.

No languages with which I am familiar would make this an easy task for administrators. For example, a set of "if/then" or "case" statements could be used to pick which discounts to apply, but that seems very inefficient for managing huge inventories.

I'm sure the answer varies somewhat by POS manufacturer, but I'm interested in the general method of achieving this.

James Z
  • 12,209
  • 10
  • 24
  • 44
Ryan Griggs
  • 2,457
  • 2
  • 35
  • 58
  • Here's one very general overview I found: http://support.poshighway.com/resources/how-ncr-counterpoint-manages-pricing-strategy Looks like Stored Procedures (SQL) are used for extremely complex price calculations, but nothing is explained about their other methods of defining price rules. – Ryan Griggs Mar 12 '18 at 23:24
  • Here's something with a little more detail on price rules: http://www.lparetail.com/UserFiles/File/updating-pricing-in-ncr-counterpoint%202012.pdf – Ryan Griggs Mar 12 '18 at 23:28
  • Another example: https://docs.oracle.com/cd/E12440_01/rpm/pdf/150/html/pos_merch_impg/appendixc.htm – Ryan Griggs Mar 12 '18 at 23:30

2 Answers2

2

In the Object Management Group, standardization work on price optimization has just started.
At the moment RFP has been issued.

If you select "retail" in the OR Select Subgroups section of OMG Public Document Listings and click the search button, the following contents are included in the result.

retail/18-01-09: Price Optimization Standard RFP
(Contact: Ms. Karen Shunk)
Price Optimization applications help retailers establish initial prices and manage their markdown cycles. RFPs help retailers select software applications to fit their specific business needs.
Formats: Excel, PDF
Note:
This document is available to the general public.

It may not be suitable for your purpose or requirement, but it may be reflected in the specification by involving yourself in this standardization.

kunif
  • 4,060
  • 2
  • 10
  • 30
  • Thanks for this info. It's still quite vague. I'm trying to understand how existing retail POS systems define price rules. From what I have read in the links I added above, it looks like price rules are not as flexible as I had hoped. How on earth can large chains keep their pricing updated for all the sales and promotions they offer? And how can they test to ensure everything works properly? Seems there should be a simple way. – Ryan Griggs Mar 13 '18 at 20:12
  • My specialty is in the field of I/O device API, so I am not familiar with the field of retail business, but I feel that it often depends on human's undocumented knowledge about pricing as well. That kind of thing is linked with retailers competitiveness factor, so it will be difficult to publish or systematize. In recent technical trends, there is a possibility that it will be subject to machine learning and clear rules are not made. – kunif Mar 13 '18 at 23:41
2

It's going to depend upon the retailer and software. Many of the large chains use Toshiba ( formerly IBM ) or NCR software for their Point of Sale. I can only speak to some of them under the old IBM side and certain retailers. You will unfortunately have to differentiate the front end and "Mainframe"(more like cloud servers now) as well.

At the front end, what you have with at least IBM is a specific file that keeps track of the items and the price. That file is basically a big lookup table that gives you the basic item information ( department, description, base price, current price, etc ). Barcode scanned turns into UPC which is typically how you look up the item. Then there are other files cross-referenced for some of the deals. Coupons can be included here. Coupons are treated separately but are matched up to the item to validate they're good and applied at the register.

Discounts can be applied at different levels. I suspect there is a price that's set by the buyers up at the homeoffice level. As that price is changed, it trickles down to the stores. Then at the store level, managers usually have the ability to also modify that price for store deals. ( I probably skipped a district level as well ). Each layer can apply their prices. In the retailer I know they have a huge item database where these are probably all added up and calculated. By the time you get to the store level, the end result of that is sent to the Point of Sale that really just knows it as the current price.

I'm sure some retailers will use the Point of Sale software to track this, but most big retailers take care of it themselves or through another software setup that integrates with Point of Sale.

So back to your language question. No. It's all pretty much handle independantly and applied as part of the Point of Sale application. Prices come down one method, a separate bit of logic for coupons, another for your buy one get a gift card type deals.

Probably doesn't help you with what you're doing, but hope it gives some insight.

Brent
  • 109
  • 7
  • Thanks @brent. So in your example, how would they define the pricing for the following items: 1) Item 'A' is priced at $1.00. 2) Item B is priced at $2.00 3) If you purchase 2 of item A, you get one of item B free. 4) There is a coupon for Item B that gives a 10% discount if you purchase 4 of them. – Ryan Griggs Mar 14 '18 at 21:30
  • That's probably going to depend too much on the retailer. Different ones will do that different, and even coupons. Some coupons won't let you do other deals. I think less retailers are doing the old grocery store coupon stacking and multiplication type stuff. You would initially ring up the items. Then you scan the coupon and it'd search the cart. Setting Item B for free. If you purchased 4 you'd probably end up with 10% off of 3, as one of them is now free. Typically you'll ring up the in store price first before coupon. After you're done with all that, you apply taxes. – Brent Mar 21 '18 at 04:16
  • Yes I understand but I am interested in *how* these rules are defined in the POS. I.e. what language is used to define the rulesets. – Ryan Griggs Mar 21 '18 at 13:11