Skip to main content
With alternative product data, you grant specific buyer groups different prices or product conditions. This is triggered either through the customer account or through a marketing link. The difference from the test-oriented enrichment of product data, the ProductDataFieldInjection, lies in the source. Alternative product data comes from the ERP system. This allows not only price adjustments, but completely different product data.

​
How it works

Three questions determine the process and the required settings. Clarify these before you start with the configuration.

​
Where does the data come from?

There are two sources, and the two integration paths further below follow from them.

​
When should it take effect?

When the shop is called, WEBSALE V8s checks whether at least one entry is active for the buyer or the session. An entry is active when its criteria are met. These include:
  • a validity period from and to
  • the call in test mode or in production mode
  • the sub-shop
  • an activation in the buyer’s customer account
  • an activation via a URL parameter
Price-influencing elements such as customer discounts and percentage vouchers can be excluded. To do this, you overwrite the corresponding standard fields in the alternative product data, for example the discount eligibility.

​
What applies with multiple entries?

Several entries can be active at the same time. Using the Priority parameter, you set their weighting. The product’s standard data is then enriched or replaced once with the highest-weighted alternative data. If no alternative data exists for this entry, the entry with the next lower priority for which data is available takes effect.
Alternative product data has three limits that you should know before planning:It cannot be passed to the data feeds of the DataflowManager.It cannot be used in aggregate functions, meaning not in search, sorting, and filtering. An alternative price therefore does not affect a price sort, for example.It can only be used for products with dependent variants, or rather for fully resolved dependent variant combinations.

​
Requirements

The following applies for both paths:
  • You use the article import Pro.
  • The feature must be activated by WEBSALE for your shop. Contact your WEBSALE representative for this.
In both cases, the configuration takes place in the file product_alternatives.cfg in the directory /konfiguration/. Create it if it does not yet exist.

​
Path 1: Applying price rules

In the following example, product prices are reduced by 20 percent as soon as the buyer’s billing address field Suffix5 contains the value aktiv. The rule applies from 21.03.2022 at 12:00 until 01.01.2025 at 00:00.
The period follows the format YYYYMMDD-HH, the hour is optional. Test = yes means the entry initially only takes effect in test mode, see the section on testing further below. Reference: Configuration product_alternatives.cfg

​
Path 2: Using alternative product data files

Here the ERP system delivers a second product data file that fully or partially replaces the first.

​
Creating the file

The file name consists of the name of the original product data file and a freely selectable technical suffix. Permitted are alphanumeric characters as well as hyphen, underscore, and period. If the original product data is in 1234.prg, the alternative file is called, for example, 1234.prg-apd.
The alternative file must contain all product data, not just the differing fields.If a product has base data, alternative data for a marketing campaign, and alternative data for specific customers, these cannot be updated individually. When the product is updated, all files must always be delivered, both the alternative and the regular ones.

​
Adding to the configuration

In the following example, alternative product data is used in the same period as soon as the shop is called with the URL parameter pafirsttest=aktiv, for example via https://www.xyz.de/?pafirsttest=aktiv.
The suffix from the file name goes into AlternativeProductDataFileExtension. Both values must match, otherwise the shop will not find the file.

​
Showing original prices

This step is optional, but usually essential for the price display. If the function overwrites a data field, in this case the price, the designer cannot tell in the template that the regular price was a different one. The shadow tags exist for this purpose. With them you additionally display the original price, for example as a strike-through price. Product detail view ws_product.htm:
Shopping cart page ws_basket.htm:
Both examples assume that UsePriceShadowingVariables = yes is set in the entry. The APD-UsePriceShadow bracket checks exactly that.

​
Displaying information about the active entry

Also optional, but very useful for troubleshooting. On any template, this shows which entry is currently taking effect and with which settings.
The FileExtension line is only filled when using the product data files path.

​
Testing and going live

As long as Test = yes is set, the entry only takes effect in test mode. Call the shop accordingly and check whether the alternative data is applied as expected.
After the test, you end the test mode.
If the test is successful, set Test to no in the entry. It will then take effect in production mode.
Guide: Enabling and disabling the shop’s test modes