How to schedule Magento sales rule correctly?

Magento provides a sales rule engine which allows you to offer discount to your clients: free shipping, buy x products and get y products free, providing a discount from a voucher are samples usage of prices rules

Two important concepts exist in this model:

  • Can we cluster sale rules: can rules be combined or if a rule is applied, are the others automatically excluded ?
  • Sorting rules importance within the priority concept

How does Magento apply prices rules on cart ?

Each time you update your cart content or each time you display the cart page, Magento loads all the active sales rules for the current date, current website, current user group and test for-each rule if the conditions match the cart content. If yes, Magento applies specified discounts to items in cart.

If a rule has been flagged as “stop rule processing”, we stop iteration on the rule collection. If not, we continue and apply the others matching discount until we have tested all rules or we have applied a discount which stop iteration

The Magento sales rule priority

Priority is a numeric id defining the rule importance and how it’ll be tested: the less is the priority value, the more important is the rule

Priority is specified when the sales rule is defined from back-office

Priority is not a mandatory field: if you do not specify a value, the priority applied will be 0, and so the rule will be tested at first before all other sale rules

Technically, when the rules collection is loaded, it’ll be sorted by the priority value (sort_order field)

Priority is not unique: you can define several rules having the same priority

What happens if some Magento sale rules have the same priority?

There is no second filter to order rules: so if you have two rules which can be applied, this is the oldest one which will be used and applied firstly. Is it really what you were expecting? Perhaps not.

Furthermore, if you have many sale rules, you should ensure to know exactly each conditions criteria to understand exactly how are applied rules and in which order. Possibly very difficult in a long time or if you have many sale rules defined

How can you reduce the risk that some rules are not executed as you want?

Reviewing the rules to ensure that priority is unique is the only one solution to avoid risk that rules are not executed the way you are expecting them. But it could be difficult to maintain if you define later others sales rules.

If you want to reorder priority, you can define priority levels: the most important one have a priority defined with one digit, lesser priority with two digits, oldest one or more generic sale rules with a priority of three digits. In this case, you’ll ensure that you’ll know with an unique priority how they’ll be tested, and be able to add others rules easily

One other best practice is to defind strong application conditions criteria: the more generic they are, the more risk you have to apply a rule that should not be executed

Magento tutorial: how to overload a Varien class?

If you have read my previous post about Magento overloading mechanism, you’ll see that there is two existing mechanisms to overload classes in Magento

But these two mechanisms are only available for classes which are instantiated.

Many of Varien classes are not loaded directly through a new. So how we can overload them?

If class is only used when using extends, we have only one way to overload it’s content: the passive overload

This mechanism is based upon the auto-loading mechanism embedded with Magento

  • Loading first from app/code/local folder
  • Then first look for classes in app/code/community
  • If always not found, look for the app/code/core folder
  • Always not found? look for lib folder

The only way you can use to overload a Varien class is to use this mechanism to provide your own functionalities by copying Varien class in app/code/community or app/code/local folder (we do not touch at the app/code/core)

By using this method, this is your class which will be loaded, instead of Varien one

Magento multistore model: in which default language do I have to describe best my sales catalog?

One of the Magento amazing feature is the ability to manage different stores in different languages: You can administrate many websites to share a common sales catalog in a same Magento host

Magento configuration hierarchy is based upon a cluster of website, stores and store views. The following schema is an exemple of a possible Magento multi store usage: We have two websites; the first one is available in French and English, the second one in Japanese and Chinese

Magento products are initially in a code pool not linked to a website. Linking a product to a website renders it available for sale. But if you share this sales catalog within different languages, it’s interesting to take time to define in which default language you’ll define your catalog, the language for the product code pool / default scope

Take a look at the following example:

  • If you store your catalog in French, you only have to overload description for English store view.
  • If you store your catalog in English, you must make two times the same work for the French stores views

Take care also of your deploying plan: if you plan to open many website for south america, perhaps it could be interesting to set up your catalog in spanish instead of you using your native language: describe a catalog is a long task, and time is money

So you should always use the most used language

Magento guide: the three concepts of a Magento website context

Magento embeds a native multistore model that allows to configure multiple e-commerce models on the same magento source. If you are a Magento beginner, perhaps you are quite a bit lost with these stores, websites and views context. Each one has a dedicated role, and you should respect them, otherwise you would have to modify deep Magento’s working layer which would be quite difficult.

Screenshot of the stores management administrative panel available through the Magento administrative panel System > Stores Management

The magento websites are used to define your way of working :

  • Define a sales catalog
  • Configure the price rules management
  • Configure how customer accounts are shared between all yours stores

Define a sales catalog in a Magento website

Your catalog is manageable through the administrative panel catalog > Manage products. You can define there all your products data: name, description, price, etc

But this is not because you have enabled a product in this administrative panel that it will be salable: it needs to be part of a sales catalog: what do you want to sell on your store? All your products? Only some elements of your work?

For example, take a look at the LVMH group. This group owns Dior fragrance, Louis Vuitton bags, etc… Imagine they want to build a Magento to sell all their catalog (and if you want, you can contact me :)), they would want to sell each dedicated brand products in a dedicated store. To do that, they need two things:

  • They will first describe all their products in Magento back-office: product’s names, reference in their informatic system, etc. Afterthat products are editable, but not salable

  • Secondly, they’ll have to publish them in their sales catalog to ensure that only fragrance will be published in the Dior dedicated store, and only bags will be sold through the Louis Vuitton online store

To do that, products need to be linked to a website. This is available through the product sheet website tab

Checking the website checkbox will publish your product in the related sales catalog

So you should have at least one website per sales catalog

Are your sure? I’m not LVMH group, have only one online store, and I never do that, and I’ve not the website tab …

When you are in a single website context, all is done in background without any action

Define the scope of your prices in Magento through website

At this point you should know how to define your sales catalog

Now imagine that your business model will propose two different prices for the same product: a discount store and a normal one for example. If your prices rules are not managed with conversion rates, you should configure the price rule scope as website instead of global

This configuration value is available though the administrative panel system > configuration > catalog > prices > Catalog price scope

Magento adminstrative panel which allow to configure the price scope in a multistore context

You can with this rule apply a specific price for an article in a dedicated sales catalog

Configure how customer accounts are shared between websites

Websites allow also to configure the visibility scope of your customers account.

Suppose now that Amazon would migrate to Magento. (Yes perhaps you need to do a benchmark for other solutions, but it’s another problem 🙂 ). Do they want the customer accounts to be shared between amazon.co.uk, amazon.com, and amazon.de? Sharing same shipping address, same customer email account, etc? If so if you update your customer account on amazon.com, data will be also updated on amazon.de.

Customer accounts scope is a configuration value available through the system > configuration > Customers > Account sharing scope.

Screenshot of the account sharing option available through the administrative panel System > Configuration > Customer configuration

This option value will define how your customer accounts will be shared between each website

Why is it so important to well define the store model on your Magento?

As you can see, website define deep main work of your client and for this reason website are probably the most important degree of organization in the Magento multistore model. Updating a store model during a Magento project life is not an easy task, and for this reason, you should well define it at the beginning of your project. So be sure to ask yourself the revelant questions