Pricebook Configuration

A price book is the only place in BigLedger where a member’s class changes a price or earns points automatically. A price set inside a book says who qualifies (header rules — Member Class is one of them), which items (line rules), and what happens (a discount, a sales price, or a Point treatment). GadgetSphere’s “Gold members get 5 % off smartphones and laptops and double points” is one book with two price sets, both with a Member Class rule naming GOLD — but a bill line takes one price set, the highest-priority one that matches, for its price and its points alike. If both sets cover smartphones, a Gold smartphone line gets the 5 % or the double points, whichever set has the higher Priority Level, never both. Tiered Membership shows the two builds that work.

Where to do this

Pricebook — a Core applet, not Membership Admin. The member classes it lists come from Membership Admin. Then, in each consumer: POS General’s DEFAULT_PRICEBOOK (and PRICEBOOK_POINTS_AUTO_APPLY if the Point treatment should apply without the cashier opening the Membership Points tab), and the equivalent setting on Sales Invoice, Sales Order and Sales Quotation. The OCR processor evaluates the price book named on its job template.

Facts from the Pricebook page that decide your design

• Header rules that the counter evaluates: Valid Date Range, Branch, Entity Type, Customer Code, Member Class, Employee Category, Customer Category. Member Label, Company, Currency, Settlement Method and OCR Company header rules are ignored by the client calculator — treated as satisfied. Do not build tier pricing on labels.

• Two calculators read the same price set for points, and only one of them needs a Member Class rule. The till works the points out as the line is added and tests a Member Class rule only if the price set has one. The server runs a second pass when a cash bill or sales invoice with a member is saved — only where PRICEBOOK_POINTS_AUTO_APPLY is on in POS General or Sales Invoice, and only for lines that arrived with no points. That pass reads just three header rule types (Valid Date Range, Branch, Member Class) and discards any price set with no Member Class rule at all.

  So a price set with a perfect Point treatment behind a date range and a branch earns at the till, and earns zero on every line the server has to fill in — an invoice keyed without points, a bill line the till missed — and the only trace is a server log.

  Name a Member Class on every price set that is meant to award points, including the class your walk-in members are created in, so the two agree. Whoever configures it proves it by finalising one bill for a test member of each class before go-live, and looking for the point transaction line rather than for an absence of errors.

• All evaluated header rules must pass; the Or option on the tab is not applied.

• A Relative validity period stores null dates and never matches; use absolute dates.

• Multi-line rules are not read by the client calculator — so they never price a line and never award a point. (The counter reads them on a separate purchase-with-purchase pass that only discounts; see Pricebook applet → The till’s second pass. Keep point treatments on Single Line.) Single-line rules match on Item, Item Code Regex, Item Category, Category Code Regex and Category 1 … 10, at the counter and in the server’s points pass below (the counter also matches Item Type); Item Name Regex, Category Name Regex and Category 0 never match, so with Negation ticked the counter applies them to every item. Pricing on a sales document matches only Item, Item Code Regex and Category 1 … 10.

• At the till, a Discount treatment with Price Source = Pricing Scheme is a price, not a filter: it looks the named scheme up on the item and works from that scheme’s selling price excluding tax, and where the item has no entry in that scheme it works from the line’s own standard price, with no message. It does not stop the price set applying to a line priced on another scheme. On the Sales Order path the same setting is a filter (Pricebook applet).

• A Point treatment’s points land on the document line as its point amount and point currency, which is what the backend turns into a REWARD line at the configured document type and status — see Membership in Depth → A job after Finalise.

Decide before you build the book

• One book per purpose the terminal can select. A terminal has one DEFAULT_PRICEBOOK; a promotion book that replaces the tier book for a weekend loses the tier prices for that weekend.
• Whether the treatment is a discount or a sales price, and keep it to one per price set. With both on one set, a sales invoice applies both, lowest treatment Priority first, while the till reads only the first treatment stored on the set; which of the two that is has not been established, so test a bill at the till before you rely on it. A treatment’s Priority runs the opposite way from the price set’s Priority Level, where the higher one wins; the Pricebook page has the rules.
• The Point treatment’s Validity Period (Days) — it is the expiry of every point the book awards, counted from the moment the points are worked out. Leave it empty and the server’s fill-in pass awards nothing for that price set; what the till records for points it works out itself has not been established, so give every Point treatment a validity (Points Expiry).

When it goes wrong