Skip to main content

Structured items

A structured item is an item that consists of other items — a gift package, a ski package, a meal deal. It is sold as one article, but the stock that moves is the stock of its components.

How it works​

The relationship is defined in PnP as an item link of type STRUCTURE, with a quantity per component. STP reads those links and expands the movement.

Selling one Ski Package consisting of 1 pair of skis and 2 poles produces:

TransactionItemQuantity
the sale itselfSki Package−1
expanded componentSkis−1
expanded componentPoles−2

Selling one Ski Package made of 1 pair of skis and 2 poles. The sale line becomes three transactions: the Ski Package itself, minus 1, recorded so the sale is visible but moving no stock, and its components, Skis minus 1 and Poles minus 2, which move stock. All three carry the same linkIdStructure, the Ski Package transaction’s transactionId. Component quantities are the link quantity times the quantity sold, and a return reverses the signs into Returned.

Component quantities are multiplied by the sold quantity, and the sign is preserved — so a return of one Ski Package puts 1 pair of skis and 2 poles back, as Returned stock.

Every transaction from one expansion — the bundle's own and each component's — carries the same linkIdStructure, which is the transactionId of the bundle's transaction. A consumer groups on it to see which component movements came from which bundle sale. isStructuredItem is true on the bundle's transaction and false on its components.

Components are expanded one level. A component that is itself a structured item is not expanded again.

The bundle itself never holds stock​

The bundle's own transaction is created alongside its components' — a business needs to see that a Ski Package was sold — but it moves no stock. The stock that exists is the components' stock, not the bundle's.

STP treats the parent of a structured item as not stock handled, whatever its own Stp.StockHandlingType. So the same sale is never counted twice, and the bundle needs no stock configuration of its own: the stock settings that matter are the components'.

Components need their own master data​

Each component is a stock-handled item in its own right, so each one needs:

  • Stp.StockHandlingType = DoStockHandling
  • a costing method, if the default FIFO is not wanted — see Cost calculations
  • its own purchase price in PnP. A component's cost is its own, never inherited from the bundle. A component with no purchase price produces movements costed at 0.

Return