Commerce Core includes a Promotion module that supports various types of offers, conditions, and coupon configurations – with both limited use coupons and bulk coupon code generation. Any user role can be granted access to configure new promotions, disable old promotions, or add coupons to existing promotions.

The promotion architecture shown in the form above consists of four primary parts:

  1. Promotion metadata: the high level details of a promotion, including name, status, dates of availability, usage limits, and more. These elements appear at the top and in the sidebar of the form.

    Some of these fields are used to filter out potentially applicable promotions early for performance reasons. For example, if the current date is outside of the promotion’s date range, it will not be loaded nor will its conditions be evaluated during price calculation, cutting down the processing required during pricing.

  2. Offer type: when the promotion applies, the offer determines what benefit the customer will get. The core offer types include the following, with additional types being added by contributed modules:
    1. Buy X Get Y: often referred to as BOGOs, when a customer adds the X product(s) to the cart, the Y product(s) are discounted per the rules.
      1. Examples: buy one shirt, get one half off; buy one book, get one free
    2. Fixed amount off each matching product: discounts a static amount off any matching product in the cart. This discount will be represented as an order item adjustment for those products in the cart.
      1. Example: get $5 off a pair of sunglasses
    3. Fixed amount off the order subtotal: discounts a static amount off the entire order. This discount will be represented as an order adjustment.
      1. Example: a single use coupon code for $5 off your next purchase
    4. Fixed amount off the shipment amount: discounts a static amount off a qualified shipping selection. This discount will be represented as an adjustment on the shipment itself.
      1. Example: free standard shipping on orders over $50
    5. Percentage off each matching product: similar to b above, just with a percentage based discount instead of a static amount.
    6. Percentage off the order subtotal: similar to c above, just with a percentage based discount instead of a static amount.
    7. Percentage off the shipment amount: similar to d above, just with a percentage based discount instead of a static amount.
    8. Combination: combine any of the above options together.
  3. Conditions: the conditions you add to a promotion determine whether or not it applies to any given order. You can enable any combination of conditions on a promotion and decide whether all conditions must pass or if any one passing will suffice. The core condition groups are listed below, with additional groups being added by contributed modules.
    1. Customer conditions: evaluated based on the current user and / or uid assigned to the order.
    2. Order conditions: evaluated based on elements of the order itself.
    3. Product conditions: evaluated based on the products in the order. The first product condition will match against any variation referenced by the given product, and the product categories condition will match against any taxonomy term referenced by a product.
  4. Coupons: when you create a promotion, you have the option to add coupon codes to it. If coupon codes are defined for a promotion, even if all other conditions apply, the promotion will not be applied to the order until the customer adds a valid coupon code. Coupon codes may be limited in usage either globally (e.g. a single coupon can be redeemed 5,000 times by anyone) or per user (e.g. a single use coupon can be used once by one person, though this does require customers to be logged in in order to work).

Every component mentioned above is extensible through custom code. You can add custom fields to the metadata or define custom offer type or condition plugins. We do this on many of our projects that call for more complex logic than the default offer types or conditions can satisfy.

Promotion application process

Promotions are applied to orders during the order refresh process. They are given a high priority, meaning they will be applied early in the order refresh process. By default, this means being applied before taxes, though the order of processing can be altered by adjusting the weights on the various processors via custom code.

Finally, promotion usage is calculated when an order is placed upon checkout completion or by an order manager. The promotions applied to the order, with or without a coupon, are recorded in the commerce_promotion_usage table in your database, which tracks the order ID, order email, promotion ID, and, where applicable, the coupon ID that resulted in the promotion being applied to the order.

Note that promotion usage is distinct from coupon usage, though the two concepts overlap. You can apply limits at either level, creating a scenario, for example, where a promotion is available to the first 5,000 customers to redeem one of 10,000 bulk generated coupon codes. There’s a small logic gap when it comes to preventing usage by customer on sites that permit anonymous checkout, so be sure to test the available options against your exact checkout configuration before activating a promotion in your production environment.

Need help implementing or customizing any of the above? Our services include consulting and custom development to ensure your promotions function exactly how you need at any scale. Contact us to find out more.

Source link