Future price changes requires the use of StoreInfo schema version 1.6 or higher and is only supported by Shoppa versions 2.25 or higher.
Assume we have the following base price list to begin with. It has a start date of 2020-01-01
From 2020-01-15 we want to increase the price of product 111111 to 59.95 SEK. We also want to lower the price of 222222 to 19.95 and 444444 to 69.95 two weeks later.
Here we have to refer to the same package ID as the base price list if the changes are to be combined with the base price list at desired change date. Each package startdate in the XML defines when the changes will apply.
We have therefore created one package with startdate 2020-01-15 and one with startdate 2020-02-01 for the respective price changes.
The price of the product 333333remains the same at each change date.
If we want to reduce a price during a short period of time, for e.g. under a two month time. Afterwards we are to set the old price back again. We can not set a stopdate for the reduced price, instead we have to send the higher price on new.
The product will now be on a reduced priced during the two months between 2020-02-01 and 2020-03-31. At 2020-04-01 th eproduct will return to its original price.
It is possible to remove a previously uploaded package in case it was incorrect. This will remove all price changes that were set to occur at the specific date.
We delete the price changes above for 2020-02-01 with this xml:
The price change at 2020-01-15 will still be in effect.
To remove individual products from future price changes, use the delete attribute on the product element, like so:
We have now deleted the change for product 444444.The change for product 222222 at 2020-02-01 will still remain.
Here we will send in a few price changes for the product 111111 over a period of time. We will have price changes at each package startdate.
To remove all future price changes for product 111111we have to delete the product from each future price change package with the same startdate defined as when the change were to occur.
The XML will look like this:
Assuming we don't know when all the price changes for a product occurs, we can delete all prices for a product by sending in the product with an empty price value. The startdate of the package will determine from which date the prices are deleted.
All future price changes and the current price for product 111111 are now deleted, starting 2020-01-15.
Here we have a price change for 2020-02-01. After a while it is decided that the product should have another price from the same startdate. Correcting the price change is accomplished by setting the new price for the same startdate.
At 2020-02-01 the product will now have a price of 24.95 instead of the original 19.95.
Some time passes and we have made multiple changes to our pricelists at different times. For some reason we may have the need to replace all prices in a pricelist with new prices. Some products may no longer be relevant for example. We do this by setting the fullPackage attribute like this:
Now there will no longer be a price for product 333333 or 444444 starting from 2020-04-15.
This describes StoreInfo schema version 1.6.
While most product information is static over time, prices are not. Stores have different prices for the same product and prices change at different times. This information is stored in pricelists which is one kind of StoreInformation package.
In contrast to products and campaigns, pricelists are not automatically inherited along the customer tree. A store uses the pricelist named STANDARD from its own node by default, but a named pricelist from a parent node can be explicitly selected instead.
Pricelists are described by packages with a name and a start date, but no stop date. If no name is provided, the default name STANDARD is assumed. If you also provide a package id, you can later use this to refer to that package instead of using name + start date.
Mediablob primarily identifies packages by id + countryCode. If id is not provided, the package is identified by name + countryCode. We recommend using the id for identification when possible. This behaviour is different from previous versions of the api and should be considered when updating existing integrations.
Prices are changed by sending a new package with the same name for a later date.
Lets build a pricelist from scratch and see how it evolves with different requirements.
Lets say store S123 wants to sell our sample product for 205 SEK. The price is valid from September 21st, 2008. The corresponding xml format for creating a standard pricelist is:
Some stores may use a mutual pricelist. In this case HQ wants to publish a named pricelist the stores can subscribe to. We create the same pricelist above as a named pricelist. We use an id from the HQ ERP system for future tracking and updates. Here is the xml we need:
Now we want to add two other products to the named pricelist. The xml for this is:
After this, the pricelist contains three priced products.
We finally decide to restructure our pricelist system and want to delete a pricelist completely. We do this by setting the delete attribute but omitting the startDate. The xml for this is simply:
In addition to deleting a complete pricelist you also have the option to remove a selection of products from the existing pricelist. Instead of defining the delete attribute in the package tag, it will be set in the product tag. The xml for this is simply:
Local prices in combination with central prices requires the use of Shoppa version 2.25 or higher.
Pricelists on a store level overrides central prices only if the store is subscribed to the central pricelist, both pricelists have the same package ID, and the local pricelist does not have the name "STANDARD"
All future price change functionality is applicable for local overridden pricelists as well as central pricelists.
Locally overridden prices for a product will always trumf any centrally price changes for the same product.
Here we have a central pricelist stored on a HQ level.
In one of the stores we have different prices for the products with ID 222222 and 333333. We will therefore only send the price changes to the local pricelist.
Store1 will now have the local prices in addition to central prices that are not overridden. The other stores will receive all the prices from the Central Pricelist.
If a local price stops being active and we want the central price to be used again, it can be accomplished by deleting the local price from its pricelist.
Here we have deleted the product with ID 222222 from the local pricelist. Store1 will now receive a price for the product from the Central Pricelist. Other local price overrides will still remain.