Skip to main content
Sometimes the connected ERP system needs more for an order item than the order data provides by default. For this case, there is the CustomizedBasketPositionOrderData function, CBPOD for short. It works like this: you store up to five templates of your own. The shop parses each of them for every single basket item, encodes the result in hexadecimal and writes it into the order data. You determine what goes into these templates using the familiar tag technique. The two tags with the prefix CBPOD- are the bracket into which this content belongs. Guide: Enriching order data

​
The process

This function does not require activation by WEBSALE AG. It is active as soon as at least one of the five templates is entered in the shop configuration.
The content ends up hexadecimal-encoded in the order data. It is not readable there, and the receiving system must decode it. Coordinate this before you start building.

​
The complete example

Within the loop, all BASKET tags and all general WEBSALE tags are available. They are not limited to product data: customer data, existing JSON data or sending via asynchronous data transfer are also possible.

​
CBPOD-PR-Data

The outer bracket and the loop in which the data of the basket item is compiled.
The loop {@CBPOD-PR-Data} runs exactly once, not over all basket items. The shop parses the template once per item, and the loop provides the item concerned in this run. If you treat it like an ordinary item loop and count or sum within it, you get the same result of one for every item.
Why the loop exists at all: it sets the reference to the current item. Only within the loop do the BASKET tags know which item is meant. Without it, they return nothing.

​
Checking the number of items

As an area tag, CBPOD-PR-Data accepts a number or a comma-separated list of numbers as a parameter. The area applies if the basket has exactly that many visible items.
Without a parameter, the area applies as soon as the basket contains any visible items at all. The check for a specific number is intended for special cases, for example to pass single orders to the ERP system differently from collective orders.
The visible items of the entire basket are counted, not the set sub-products and not the item currently being processed.

​
CBPOD-PR-SetChildData

Outputs the set sub-products of the item. Unlike the outer loop, this one actually runs over several entries.
Within the set loop, the BASKET tags refer to the respective sub-product; outside of it, to the set parent product. The switch happens automatically when entering and leaving the loop.

​
What does not work on these templates

BASKET-PR-Data and BASKET-PR-SetChildData cannot be used on the CustomizedBasketPositionOrderData templates. They are replaced by exactly the two CBPOD tags. The other BASKET tags work as usual, but only within the CBPOD loops.
Both tags are permitted exclusively on the five CBPOD templates. On any other template, they are invalid.
If the internal calculation of the basket data fails, the shop hides all CBPOD areas and outputs nothing. The order data then contains an empty entry instead of an error message. Therefore, when setting up, check the actual result in the order data and not just the preview.

​
The tags at a glance

Both are only permitted on the templates stored in the shop configuration under CustomizedBasketPositionOrderData01 to …05. CBPOD-PR-SetChildData additionally only within the loop {@CBPOD-PR-Data}.
  • Guide: Enriching order data
  • Guide: JSON interface
  • Guide: Asynchronous Server-Side Events (ASSE)
  • Reference: <Templates> section
  • Reference: Items in the basket