ART#304 - How to configure Price and PriceLists in ATG?

Back



Next





Now we have setup a catalog with categories, products and SKUs and added inventory to it. But what good is a product and a SKU if it does not have a price?
In this article we will discuss how to associate price with a SKU.

SKU Based Pricing
The easiest way to setup prices, is the SKU-based pricing. OOTB SKU item-descriptor has the following properties, which are used to set SKU-Based Pricing:-
  • listPrice: Which denotes the price of the SKU
  • saleprice: This is the salePrice (or discounted price) of the SKU.
  • onSale: This is a boolean flag, which is used to trigger salePrice. If this flag is true, then salePrice will be considered. If this flag is false, listPrice will be considered [even if salePrice property has a valid value]
While populating the ProductCatalog (via BCC or XML Import), we can specify these properties for a SKU. Later on, we can also change these properties via BCC. Since SKU is a part of ProductCatalog, which is a versioned repository [What? We will discuss that later], we CANNOT simply update the repository directly from dyn/admin [as we did for InventoryRepository before]. We will discuss the reasons when we jump onto Versioned Repositories.

This is a very simple way of implementing prices which is enabled OOTB. This approach, however is not very popular because of many reasons, which we will discuss soon. 
Once you do this, you will be able to add items to cart [Next Article!]


PriceList Based Pricing
This is the go-to way for setting up pricing for a SKU in ATG. It has many advantages over the standard SKU-Based Pricing.
Suppose you are developing an application which has two set of prices, one for USA and one for Europe. In this case you cannot store 4 prices (2 for US and 2 for EU) into SKU. Also, If you want to use certain prices for most of the users, and some other price for some selected users (something like old-timer registered users who registered more than 2 years ago), priceLists come in Handy.

For These scenarios, we create an entity called "priceList". A priceList is an item-descriptor which exists in /atg/commerce/pricing/pricelists/PriceLists repository.

Please note that PriceLists repository is also versioned, therefore, priceLists have to be deployed via BCC.

Considering above scenarios, we can create separate priceLists with separate IDs, for example:
1. defaultPriceList: default priceList for US
2. defaultSalePriceList: sale priceList for all US
3. defaultPriceListEU: default priceList for EU
4. defaultSalePriceListEU: sale priceList for EU.

Now, these objects do not contain any prices. These objects are used for notifying a certain list, with which the prices will be associated.

The PriceLists repository also contains an item called "price". This is the actual price which is associated with a SKU. Some important properties of this item are:-


  • id: This contains the id of price. [this can be auto-generated]
  • priceList: Id of the priceList we created above [defaultPriceList, defaultSalePriceList etc.]
  • skuId: ID of the SKU for which we want to set the price.
  • productId: ID of the parent product of above SKU.
  • pricingScheme: Its value will be mostly the string "LIST_PRICE". [Even if we have provided defaultSalePriceList for this item]
  • listPrice: the numeric value of the price for this SKU.
 

Therefore, let us say that we are setting the price for SKU with id sku10001. Now, we will have to create 4 "price" items for this SKU, for each price List.
See below diagram for details. Note that the skuId, productId and pricingScheme remain the same and id, priceList and listPrice change.

 

Enable PriceList Based Pricing

As we discussed that OOTB configuration does not allow priceList based pricing, we can enable the priceList based pricing in the /atg/commerce/pricing/ItemPricingEngine.
There is a property called "preCalculators", which has to be overridden by layering ItemPricingEngine.properties in the config-path.
Add the below properties in the ItemPricingEngine.properties and layer it in your config-path.

 

Once this is done, priceList based pricing will be enabled on rebuilding and deploying the application. Also, you have to deploy the priceLists items.

Once this is done, you have to notify the ATG system, which priceLists to use by default.
This can be done by layering the component /atg/commerce/pricing/priceLists/PriceListManager.
Suppose, the IDs of the priceLists you deployed are: defaultPriceList and defaultSalePriceList, then your PriceListManager.properties should look like:-



This will notify the ATG system, that these are the default priceLists which should be used by ATG system.

We can also configure priceLists for some particular users. In /atg/userprofiling/ProfileAdapterRepository, there is a "user" item-descriptor. In this item-descriptor, there are two properties viz. priceList and salePriceList which specify the price lists for a particular customer. 
Fill these properties with your desired priceLists. "price" items having these priceLists should also exist in the repository.

Catalog - CHECK
Inventory - CHECK
Prices - CHECK

Lets add some items to the cart!! 

Back



Next








7 comments:

  1. Hi Monis, you are doing an commendable job. Just one quick question. Do you know how many OOTB calculators we make use of most often and are important to know functionality wise.

    ReplyDelete
    Replies
    1. Hi Udit,

      Thank you for your comment.
      I will write a separate article on how you can configure the whole pricing engine (which would also contain a detail of calculators) soon.

      Delete
  2. One correction for the above article, defaultPriceListId and defaultSalesPriceListId properties are in PriceListManger component(not in PricingTools as you have mentioned).
    Overall this is very good article on PrcieList.

    Thanks,
    Arshad

    ReplyDelete
    Replies
    1. This is correct. Thanks for pointing out Arshad. This has now been corrected!

      Delete
  3. Hi Monis,
    Since in the above example, we have configured defaultPriceLisId as defaultPriceList. Wer we have to configure defaultPriceListEU if we access Europe Store

    ReplyDelete
    Replies
    1. In case you have a new store for EU, it must have a separate module layered above the CORE and STOREFRONT modules. In that module, you can override the PriceListManager.properties and set priceListIds for EU.

      Delete
  4. Hi Monis,
    Could you explain why we configure precalculators, postcalculators in pricing Engine component? What is the exact need of both? What all we can do in pre and postcalculators?

    ReplyDelete

Subscribe

Get All The Latest Updates Delivered Straight Into Your Inbox For Free!

Flickr