Item setup for retail: the fields on the item card that decide whether the POS behaves

Implementation · 9 min read

A retail item looks simple: a number, a description, a price. At the till, that simplicity is an illusion. LS Retail states the starting point plainly — a retail item is created and set up as an ordinary item in the inventory system — and then the Retail Item Card adds the fields that decide whether the POS sells it cleanly, prices it correctly, and posts it to the right accounts. This guide walks those fields in the order they appear in the documented creation procedure, and explains what each one controls.

The scope is deliberately narrow. Not every field on the card matters on day one. The fields covered here are the ones LS Retail's own retail item procedure names, plus the Business Central item-card facts that sit directly behind them: templates, price and VAT treatment, and units of measure. Field names follow the LS Retail documentation; wording can differ in newer versions, so confirm names in the version in use.

A retail item is an ordinary item, with retail consequences

Microsoft Learn makes the same point from the Business Central side: an Item Card must be filled in for each item offered, and document lines pull their information from that card. LS Retail adds the retail layer on top of the ordinary item — including, for example, the ability to use a standard bill of material setup for a retail item and explode that item's BOM when posting statements. The practical consequence is that an error on the card does not stay on the card. It travels to every sale of that item until it is fixed and redistributed.

Templates reduce that risk. Business Central item templates reuse settings for different types of items, speed up adding new items, and increase consistency in item data: when a new item is registered, a template can be chosen and its settings are filled in on the new item card. LS Retail's retail procedure shows why consistency matters — several of the most consequential fields arrive as defaults copied from another record, and a template-plus-product-group discipline is what keeps those defaults right.

The fields that matter, field by field

Two rows deserve emphasis. First, the Product Group Code is not a cosmetic classification: selecting it automatically fills the Item Category with the category of the product group, and the three posting groups on the Invoicing FastTab arrive as copies of the product group's values. Choose the wrong product group and the item inherits a coherent, plausible, wrong set of posting defaults. Second, those defaults can be changed for each retail item — the documentation says so explicitly — so "the product group did it" is an explanation, never an excuse, once the card has been reviewed.

Posting groups: defaults copied, responsibility not copied

Specification check, in the literal sense: before a new item goes live, open the Invoicing FastTab and compare the three copied fields — Gen. Prod. Posting Group, VAT Prod. Posting Group, and Inventory Posting Group — against the values finance expects for that class of item. The check takes a minute and catches the most expensive class of item-setup error, because a posting-group error repeats silently on every transaction, while a price error is usually noticed by a customer within a day.

The VAT posting group deserves its own look because it interacts with price. Microsoft Learn documents that item prices can be set up to include or exclude VAT, and that typically prices on the Item Card exclude VAT. Whether the unit price is treated as including VAT changes how the application calculates the price copied to sales lines, using the VAT product posting group combination. LS Retail's retail procedure, meanwhile, has the operator fill in Cost and Unit Price Including VAT. Those two documented facts have to be reconciled in each implementation: know which convention the store's item prices follow, set the VAT product posting group correctly, and do not assume the number typed into the price field means the same thing in every database.

Price, VAT and units of measure

Additional prices are also part of the documented procedure: if additional prices are needed, the operator clicks Pricing and selects the relevant sales code. That is the documented route to more than one price for an item, and it is cleaner than duplicating the item to get a second price — duplicate items split sales history and stock, and create two cards to maintain where one card with an additional price would do.

Units of measure follow the same pattern of a small field with long reach. The retail procedure includes filling in the Base Unit of Measure by selecting the appropriate unit. Business Central documentation adds that multiple units of measure can be set up for an item, that a filled Base Unit of Measure is already set up as an item unit of measure, and that for an additional unit the Qty. per Unit of Measure states how many base units the new unit contains. A wrong quantity-per value does not produce an error message; it produces wrong quantities, which look like shrinkage or overstock until someone traces them back to the card.

Scale items and linked items

The POS FastTab carries the most literally till-facing field in the procedure: if the item needs to be weighed on a scale at sales time, select the Scale Item check box on the POS FastTab. Leave it clear for a weighed item and the sale cannot follow the weighed flow; set it for a non-weighed item and staff inherit a prompt that should never appear. It is a one-checkbox field with a one-question test — is this item weighed at the moment of sale? — and it should be answered from the physical item, not from habit.

Linked items are the other behavioural field set. Retail items can be linked together so that every time the main item is sold, the linked items are sold also. LS Retail's example is drinks in bottles: the bottle is linked to the drink, so each sale of the drink sells the bottle with it. The documentation is precise about direction: when the linked item is sold on its own, the main item is not sold; a main item cannot itself appear as a linked item, and an item cannot be linked to itself. Quantities matter too — the Linked Item setup records the unit of measure and the number of linked units per main item, and a returnable linked item can be set with a negative quantity arrangement so a return brings it back. Set linking up casually and every sale quietly sells something extra; set it up deliberately and deposits and bundled components stop depending on cashier memory.

Setup procedure: create a retail item end to end

1. Open the Retail Item Card from LS Retail Back Office, Retail Item Card — or, in current interfaces, open the Retail Item List and choose New — and start a new item, choosing an item template if templates are in use.
2. Fill in No. by selecting the appropriate number series, then enter the Description.
3. Set the Base Unit of Measure by selecting the appropriate unit of measure.
4. Select the Product Group Code, and confirm the Item Category has been filled automatically from the product group.
5. On the Invoicing FastTab, verify the copied posting groups — Gen. Prod. Posting Group, VAT Prod. Posting Group, and Inventory Posting Group — and change any of them for this item if finance requires it.
6. Fill in Cost and Unit Price Including VAT, applying the store's documented price-includes-VAT convention consistently.
7. On the POS FastTab, select Scale Item only if the item is weighed on a scale at sales time.
8. Add additional prices if needed through Pricing and the relevant sales code; add linked items if another item must always sell with this one.
9. Fill in any other fields the store requires, then close the card. Closing the entry creates an action in the Actions table.
10. Wait for distribution: the new item is on file and ready to be sold after the system next exports retail item data to the POS terminals.

What success looks like

After the export to the POS terminals has run, find the item at a terminal and sell it in a test transaction. Success is specific: the item is found by its number, the price matches the Unit Price Including VAT as entered under the store's VAT convention, a weighed item follows the scale flow and a non-weighed item does not, any linked item appears on the sale automatically in the right quantity and unit, and — after posting — the sale lands under the posting groups verified on the Invoicing FastTab. If the item cannot be found at the POS, check distribution first: per the documentation, readiness to sell follows the export of retail item data, so a perfect card that has not been exported is not yet a sellable item.

Disclaimer: field names and navigation in this procedure follow LS Retail documentation that spans several versions; the Retail Item Card in a current version may label FastTabs or actions differently. Verify against the documentation for the version in use, and involve finance before changing posting groups on live items.

FAQ

Why did a new item inherit the wrong posting groups? They are copied from the Product Group as defaults. Either the product group was wrong for this item, or the per-item override on the Invoicing FastTab was never applied.

Why is the item on the card but not on the POS? The documented sequence is entry, an action created in the Actions table, then readiness after the next export of retail item data to the POS terminals. Check that the export ran.

One item, two prices — duplicate the item? The documented route is Pricing with the relevant sales code for additional prices, keeping one card, one stock record, and one sales history.