Multi-code & pricing rows

A product normally has one barcode and one sell price. A multi-code row adds a second layer: an alternative barcode, box code, price, discount, supplier or buy price — optionally limited to one warehouse and/or a schedule.

Multi-code rows are managed in the product editor's multi-code / supplier tab (visible when Multi code & supplier is enabled on the product). When the feature is off for a product, its multi-code rows are ignored everywhere.

Row fields

Price and discount are independent. A row may set only the price, only the discount, or both. An empty field does not clear anything — it simply leaves that field to be decided by other rows (and finally by the product itself).

Row order matters

Rows are processed from top to bottom (row 1, row 2, row 3 …) and the last row that carries a value wins that value. In practice:

1. Start from the product's own price and discount.
2. Walk the matching rows top to bottom.
3. Every time a row has a price, it becomes the current price. Every time a row has a discount, it becomes the current discount.

So if row 1 sets a 10 % discount and row 2 sets a lower price with no discount, the result is row 2's price with row 1's 10 % discount — the fields resolve separately.

The last row that supplied either the price or the discount is the winning row — its three checkbox flags are the ones that steer what that discount blocks (see Discount priorities).

Worked example

Walking down: price ends at 8.00 € (row 3), discount ends at 20 % (row 3). If row 3 had no discount, the result would be 8.00 € with 10 %.

The three row flags

The checkbox chips at the end of each row control how the row's discount competes — they matter only while this row is the winning row:

The chips are orthogonal — combine them freely. Lock does not remove BXGX by itself; to freeze a row's pricing completely check all three (Lock

• Ignore quantity + Ignore BXGX). See the combination table in Discount priorities.

Barcode-specific rows

The key business rule:

A price or discount attached to a specific barcode is only used when that exact barcode is scanned.

When you scan a row's own barcode, that row always wins for the fields it sets — a generic row can only fill the fields the scanned row leaves empty.

Warehouse-limited rows

A row with a warehouse only participates where its warehouse qualifies:

• Orders & invoices — the row's own warehouse must have the location's Is main warehouse flag checked (any main-flagged warehouse qualifies — the line's stock location is never a pricing input here). Rows bound to non-main (shop) warehouses are POS-only.
• Label maker — the context is the warehouse selected on the label sheet.
• POS — the row's warehouse must match the register's location. This is the only place a shop-bound row prices.

Rows with an empty warehouse apply everywhere and always participate.

A warehouse only decides whether the row participates — it never reorders precedence. Among the participating rows, row order decides as usual.

Schedules (happy-hour pricing)

A row with a schedule is only considered while all of these hold:

• today's date is inside the row's date range (if set),
• the current time is inside the row's time window (if set),
• today's weekday is in the row's weekday list (if set).

Outside the window the row is silently skipped — the other rows decide the price. A typical setup uses three rows for one location:

Because rows merge top to bottom, put the base price first and the scheduled overrides below it — while a schedule is active its values overwrite the base; when it ends the row stops participating and the base price returns automatically. Nothing needs to be switched back manually.

Lines already on an order keep the price they resolved when the document was last opened or edited — see the FAQ in How the price row is chosen.

Box codes and quantities

Scanning a box code adds the product with quantity multiplied by the product's box quantity (box_qty), at the scanned row's pricing. If the same value is registered as both a unit barcode and a box code, the cashier is asked which one was scanned.

Prices from stock adding (v3.102)

Whenever stock enters with a price that differs from the product's own price / purchase price, the differing price never overwrites the product — it lands on a multi-code price row instead, filling only the column that changed (buy, sell, or both):

If a matching price row already exists (same supplier and/or location, no code, no box code), its price columns are updated — repeated price changes never pile up rows and never touch the product's own prices.