Pricebook

Define conditional pricing here — a discount, a special price or membership points for the customers, branches, dates and items you choose. This applet only stores the rules: POS and the sales document applets apply the price book named in their own Default Pricebook setting when a line is added.

Overview

The Pricebook applet is where a pricing administrator defines conditional pricing: a Price Book is a named container with a calculation logic, and each Price Set inside it says who qualifies (entity type, member class, branch, company, customer or employee category, date range), which items it covers (items, categories, code or name patterns, with minimum quantity and amount) and what happens (a discount, a sales price, or membership points). The applet only maintains this master data. The rules are applied by the consumers: the POS General, Sales Invoice, Sales Order and Sales Quotation applets evaluate the price book selected in their Default Pricebook setting when a line is added, and the OCR membership-points processor evaluates a price book on the server for scanned cash bills.

Free-gift promotions for purchase orders and POS are price books too (types PO_FREE_GIFT / POS_FREE_GIFT), but they are created and listed in the Purchase Order and POS General applets and are deliberately hidden here.

Where it fits

Screens and menus

The applet has two menu entries, Price Book and Price Set, plus Settings and Personalization.

There are two editors for a price set: the Price Set menu, and the Pricing Set tab of a Price Book. They save the same price set but offer different rule types and treatments (see Fields).

This page does not include screenshots yet; the previous marketing infographic was removed because it did not show the product.

Configuration

Before you can use it

• Items and categories exist in Doc Item Maintenance or Inventory Item Maintenance. Category rules match on the item’s category labels 1 to 10.
• Pricing schemes exist if a treatment uses Price Source = Pricing Scheme; the Treatment tab lists them.
• Customer / employee category labels are assigned on the entity (Customer Maintenance, Employee) for Customer Category / Employee Category rules.
• Member classes, member labels and points currencies exist in Membership Admin for Member Class / Member Label rules and the Point treatment.
• Companies and branches exist in Organization for Company / Branch rules.
• The consuming applet points at the price book. Nothing is applied until Default Selection → Default Pricebook is set in POS General, Sales Invoice, Sales Order or Sales Quotation (see Settings in other applets).
• Tenant permissions. TNT_LOG_PRICE_BOOK_OWNER / TNT_LOG_PRICE_BOOK_ADMIN or TNT_API_PRICE_BOOK_CREATE / UPDATE / DELETE / READ are checked on every price-book action; read access is also what POS and the sales applets need to load the price book.

Applet settings

Field Settings has one toggle and Default Selection a handful of pickers. Both save tenant-wide, so a value applies to every user of the applet; anyone who can open Settings can change them.

Rendered and saved on Default Selection but read by nothing in this applet: DEFAULT_BRANCH, DEFAULT_LOCATION, DEFAULT_COMPANY. Picking a branch also fills Company and the branch’s main location into those three controls.

Personalization → Default Selection is non-functional: changing Branch or Location fails before anything is saved.

Settings in other applets that control this applet

Feature visibility / permissions

No client-side permissions are registered for this applet, so the Feature Visibility screen and the role / team / user permission listings under Settings have nothing applet-specific to gate. Access is decided by the tenant permissions listed under Before you can use it; the API returns not authorised when none of them is assigned.

Fields

Code and name inputs on the create forms accept letters, digits, space, hyphen and underscore only, are upper-cased on save and are limited to 255 characters. Pricebook Name, Pricing Set Name and Description are stored as typed and read by nothing else; the audit stamps (Created By / Date, Modified By / Date) are read-only and come from the price-book event rows described under Lifecycle. Only the fields below behave in a way the form does not show you.

Price Book — create

Price Book — edit › Details

Price Set — Details

Created from the Price Set menu (choose the Price Book first) or from Price Book → Pricing Set (book pre-filled).

A new price set is saved with empty rules on all three tabs (Rules Logic And, Negation Disabled) and no treatment.

Price Set — Rules tabs

Each of Rules - Doc Hdr, Rules - Multi Line and Rules - Single Line has:

Rules are edited in memory and written only when you press Save on the price set (the toasts say Please save your data to prevent losses).

Rule types offered by the two editors:

Every rule has Rule Name (required) and Negation Logic (Enabled / Disabled). The type-specific part:

Price Set — Treatment tab

Option values: Price Source NA, Base Quantity, Standard Amount, Price Unit Cost, Net Amount, Transaction Amount, Pricing Scheme; Operator NA, Multiply, Absolute, Add, Subtract, Formula; Apply Treatment To Net Unit Price, Net Amount, Transaction Amount. A formula may use the placeholder {PRICE_SOURCE}. Sales and Discount priorities must differ — Save is refused with Sales Treatment and Discount Treatment cannot have the same priority. Each ticked treatment is saved on the price set; unticking removes it.

Lifecycle and effects

What the applet writes. The price book, its price sets (rules, treatments and priority), its status, and an audit row per action (created, updated, deleted, price set created). Every save of a price set saves the whole parent price book. The webhooks PRICE_BOOK_CREATED, PRICE_BOOK_UPDATED and PRICE_BOOK_DELETED fire.

Posting. This is master data: no journal, no stock movement, no queue. A document line can in principle record which price book and price set priced it, but nothing writes that on a sales document or at a till, so on a document BigLedger produced itself it is blank — see Where the number came from below.

Statuses. A price book’s Status (Active / Inactive) is read by nothing that prices a line. A price set’s status (Active / Inactive) is. Delete is a soft delete: the price book and its price sets are marked deleted and disappear from every listing and every engine.

Backend validation on save: a unique price book code, and referenced branches, entities and items must exist. Nothing on the server validates the rules or the treatments — a malformed rule is saved and simply never matches.

Which engine prices your line

There is not one price-book engine. There are four, plus a fifth on the server, and they disagree. The POS General, Sales Invoice and Sales Quotation applets each carry their own copy of the calculator, the Sales Order applet uses a shared one, and they have diverged. Which one runs is decided by the screen, not by configuration, so the same price book gives different answers on different screens.

Consequences worth knowing before you design a price book:

• A Sales Treatment only ever reaches a price on a Sales Invoice. The Sales Treatment block is hidden until SHOW_SALES_TREATMENT is switched on, so while that setting is off you cannot create one and the divergence stays latent. It goes live the day somebody turns the setting on and saves the first Sales Treatment — and from then on the same price book prices an invoice one way and a till another, with nothing to warn you.
• A price set with two single-line rules means two different things. At the till both must match; on every sales document either one will do. A price set with a single rule cannot show you the difference, so the day somebody adds a second one, a counter and an invoice start disagreeing on the price with no message either way.
• At the till only the first treatment counts, and only one price set prices a line. The till’s calculator reads the first treatment of a price set and ignores the rest, so a price set with a Point treatment first and a Discount second awards the points and gives no discount at the counter — exactly as on a sales quotation, while a sales invoice applies both. And for each line the till takes one price set — the matching set with the highest Priority Level — and uses it for both the price and the points. (With the POS applet’s manual promotion selection setting on, the cashier can choose a different matching set for the price in Item Details; it is still one set.) Put together, the till itself gives a line a price-book discount or price-book points, never both — neither two treatments in one set nor two sets covering the same item get round it. Decide which one the counter should give and put that treatment first. (Points the till did not give can still arrive later from the server’s backstop in Points: the till computes, the server fills the gaps, on a line that carries none.)
• At the till a lone threshold is ignored. The till’s calculator applies Min Quantity and Min Amount only when both are above zero; with one left at 0 the line matches at any quantity and any amount. The sales-side engines test each threshold on its own. A volume tier built on Min Quantity alone therefore holds on an invoice and gives the top tier’s price for a single unit at the counter.
• A price set with no single-line rule never prices a line through a calculator. An empty rule list is no match on every screen, the till included. A price set can perfectly well carry Multi Line rules and nothing on Single Line, and such a price set is not dead: on a till it is read by the purchase-with-purchase pass described next, which is not a calculator and does not price a line as you scan it.

The till’s second pass — what the Multi Line tab actually drives

The POS General applet prices a bill twice, by two different mechanisms, and only the first is a calculator. The calculator above prices the line you just scanned, from the Doc Hdr and Single Line tabs; it never reads the Multi Line tab. Alongside it the applet runs a purchase-with-purchase pass over the whole bill, in three steps, and every one of them reads the Multi Line tab.

When it runs. On every line added, edited and deleted, dispatched from the item facade immediately after the line reaches the draft. So a promotion can appear, change and vanish again as the operator works down the bill — there is no separate “apply promotions” step and nothing to press.

When it does not run at all, and this is the part no screen tells you: the whole pass is skipped when the bill mixes a sale and a return (any line with a negative signum alongside a positive one — an exchange), when the customer record is flagged as an employee, or when the line that triggered it is itself a return line. A promotion that works all morning and does nothing on the one bill that included a swap is behaving exactly as built.

What it will act on, from what the Price Set editor can save. The pass reads the first rule on the Multi Line tab and matches its values against each bill line’s item — so make it an Item rule; a Category rule stores category identifiers, which never equal an item. It then totals the matching lines’ amount and quantity and requires Min Amount to be set above zero. If the total clears Min Amount and the matching quantity clears Min Quantity, then:

• if the price set’s treatment is a group discount, it posts a bill-level discount line carrying the price set’s name;
• otherwise it sorts the matching lines by standard unit price ascending and discounts the cheapest matching line, stamping the price set’s name onto it, which is the only trace of which rule fired.

What it reads that this applet cannot write. The richer branches of the pass — bundles, tiered buy-N-get-one, second-item-free, promotion exclusions — are driven by properties that no screen in the Pricebook applet can set. Those shapes are real in the till and are not configurable from this applet today; treat the item list plus Min Amount and Min Quantity as the whole of what a price set built here can drive.

And the handoff is deliberate, not an accident. The till’s calculator declines to price a single-line rule that carries a purchase-with-purchase quantity, precisely so the purchase-with-purchase pass owns it. Two engines, one job split between them, with nothing on either screen saying so.

Priority runs the other way here. The calculator’s line pass sorts price sets by priority descending and stops at the first match — highest number wins, as everywhere else. All three purchase-with-purchase effects sort ascending and walk the whole list. On a till, therefore, a Multi Line price set with the lowest priority number is considered first, and more than one can fire on the same bill. (The till’s header pass sorts ascending too, but it only filters, and the line pass re-sorts, so nothing turns on it.)

What every engine agrees on. Price sets are sorted by priority, highest first (the purchase-with-purchase pass above is the exception), and the first price set whose line rules match wins — the rest are never evaluated. The Doc Hdr tab’s Rules Logic is ignored and its rules are always ANDed; Negation Logic on that tab inverts the whole tab’s result. A price set with no priority at all is left wherever the server returned it in the list — give every price set a number.

Rules that pass without being tested. The sales-side engines evaluate Valid Date Range, Branch, Entity Type, Member Class, Employee Category and Customer Category on the Doc Hdr tab, and Item, Item Code Regex and Category 1 – 10 on the single-line tab. Every other rule type is skipped, which means treated as satisfied — so adding a Company or Currency rule widens the price set rather than narrowing it. A Branch rule fails on a document that carries no branch. A Relative Period date rule stores no dates and can never match. The till’s own engine additionally matches Item Category through the item’s category links and Category Code Regex against the category code, so two line-rule types that never match on a sales document do match at a till.

Operators. The shared and Sales Invoice engines handle Multiply, Add, Subtract, Absolute and Formula; the till’s engine has no Formula branch. A discount is applied only when the computed figure is greater than zero and lower than the figure it replaces, so a treatment that raises a price does nothing.

Where the number came from, and what the line remembers

The price book runs after the pricing scheme has already put a price on the line. What it does with that price differs by screen, and so does what you see afterwards.

• Sales Invoice. The engine leaves Unit Price Std alone and writes the whole adjustment into Unit Discount, with Unit Price Net as the result. Each applied treatment is listed with the price set’s name. Editing the price by hand raises a Manual Price Override dialog naming the treatment, and confirming it removes the treatment — and the price field is read-only unless ENABLE_EDITING_UNIT_PRICE_STD is on.
• POS General. The engine writes the result into the line’s net and transaction amounts, derives the discount as the difference from the standard amount, and puts the price set’s name in the line’s Discount Description. With the Absolute operator it also overwrites the standard unit price, so the bill shows a price rather than a discount. The same price set therefore prints as a discount on an invoice and as a price at a till.
• Price Source = Pricing Scheme is not one setting. At the till it is a price: the engine looks the named scheme up on the item, takes that scheme’s selling price excluding tax, replaces the standard unit price with it, and works from there; if the item has no price under that scheme it falls back to the line’s own standard amount with no message. On the Sales Order path it is a filter: any price set whose treatment names a scheme other than the line’s is skipped. And the Sales Invoice engine knows three price sources — moving-average cost, standard amount and net amount — and Pricing Scheme is not one of them, so it silently falls back to the price already on the line.
• The document does not record which price book priced it. A document line can carry a reference to the price book and price set, and no behaviour keys off either. Nothing in the platform ever writes them — no sales path, no till, no import — so on a document BigLedger produced they are blank and stay blank, however many price books priced it. The only trace a price set leaves on a finished document is its name, in the line’s description. If you need to answer “which promotion priced this line” six months later, that string is all you have.

Points: the till computes, the server fills the gaps

Points are the one part of a price book that the server also evaluates for ordinary sales documents, and it is a backstop rather than a second pass. When a cash bill or a sales invoice that carries a member on its header is updated, the server reads Auto Apply Points From Pricebook off the POS General or Sales Invoice applet and does nothing when it is off, beyond a log entry. When it is on, it evaluates the price book and fills in point type, currency, amount and validity dates only on lines that carry no point already — so a till that already calculated points is never overruled, and a line the till missed is completed.

The separate scanned-cash-bill path is the only place the price book’s Calculation Logic is read at all: it honours POINTS_REWARD_HIGHEST, POINTS_REWARD_LOWEST, PRICESET_PRIORITY_ASCENDING and PRICESET_PRIORITY_DESCENDING and takes the first match for any other value or none.

Importing price books from a file

There is a bulk CSV import for price books that no screen in this applet exposes — it is reachable through the API only, so nothing you do in the UI will exercise it. Treat it as a capability to prove on a copy before you rely on it, not as a documented route into a live price book.

Related applets

• POS General — loads Default Pricebook, syncs price books for offline use, and owns the POS_FREE_GIFT books.
• Sales Invoice (Internal), Sales Order, Sales Quotation — apply the matched discount or sales price per line through the shared calculator.
• Purchase Order (Internal) — creates and lists the PO_FREE_GIFT price books that this applet hides.
• Membership Admin — member classes, member labels and points currencies referenced by member rules and Point treatments.
• OCR Cash Bill — the server-side price-book evaluation for scanned bills.
• Shipping Pricebook — the same design on the shipping-price tables.
• Doc Item Maintenance, Inventory Item Maintenance, Customer Maintenance, Employee, Entity, Organization — the master data the rules point at.

Troubleshooting

Related documentation

• Standard sales workflow — where pricing is applied in the sales cycle.
• Pricebook configuration for membership tiers — using Member Class rules for tier pricing.
• Point of Sale module, Sales module and Core module.