Sponsored Development: Promotions

From ADempiere
Revision as of 04:11, 27 July 2007 by Heerish (Talk) (Promotion 1:)

Jump to: navigation, search
This Wiki is read-only for reference purposes to avoid broken links.

Under Construction- but please feel free to comment

Summary

ADempiere supports basic discounts. But there is a demand for many more types of promotions. This is an effort to collect and document the various promos that may be desired and establish a project to provide them.

Project Team

Coordinator

Joel Stangeland

Functional Specs

  • Joel Stangeland

Developers

  • Sendy Yagambrum (Developer)
  • Frederick Tsang (Architect)

Testers

e-Evolution,SC 2000 USD

Westfalia IT 2000 USD

Sponsors

Requirements

Overall

  • Promos should be configurable based on Organization, Warehouse, Business Partner, BP Group, Product, and Product Category
  • Promos should apply at the line or order level (existing discounts apply only at line level)
  • Existing functionality should be preserved
  • Need to support PromoCodes/Coupon Codes (i.e. the promo only applies if a code is submitted)

Related Threads

Give Away Articles

Sales Orders with Bonus Items

Basic Procedure

  1. When the order is prepared the Promo structure is evaluated
  2. If applicable Promo's are found insert an order line with the result
  3. Remove any promo lines (from previous prepares) that have not been delivered or invoiced


Questions

  • When/how should the promos be triggered? The current implementation is easy, it applies a discount at the line level as a reduction of the price. It is immediately visible. In order to facilitate order level promos, it seems like they need to be evaluated when the order is prepared. Does that seem right?

A Discount is based on the orderline level, whereas a promotion is based on the order level. So my answer will be yes, the promotion evaluation must kick off, just when the order is about to be prepared, or completed. Fredtsang 13:06, 5 July 2007 (EDT)

  • Should the promo be implemented as an inserted orderline? Would it be better to handle it similar to the tax implementation? It seems the order line would be better since some of the promos are products, the others can be charges.
  • There may be a need to check the promos before an order is processed, especially in a call center implementation. Maybe there could be a 'Check Promos' button so that you could preview the results before processing the order?

Will be trying to minimize the implementation, is there a strong backing for this feature? Fredtsang 13:06, 5 July 2007 (EDT)

I think it could be a later addition jsSolutions 01:41, 6 July 2007 (EDT)


  • Is there any reason to implement these at some time other than Order?


  • The standard discount structure should probably remain for backward compatibility, but does it make sense to support discounts in the new structure as well?

Yes discount is on order line level, and promotion on order level. So you could have 3 items that have been discounted at 20%, and yet receive another one free. So we won't touch the discount structure. Fredtsang 13:06, 5 July 2007 (EDT)

--Armen 01:31, 10 July 2007 (EDT) : Fred, I think Promotion should be in order line level too. Promotion must also support staggered discount breaks of get 1 free for buying 5, get 2 free for buying 8, and so on. My proposal is to enhance the M_DiscountSchemaBreak and C_Campaign (actually I did it before in Compiere, not fully developed though). Why C_Campaign ? First I like it it's already an Acct. Dimension, you can run report to know you promo cost and revenue. For order level discount, we can add a new field GrandDiscount in C_Order. All should remains backward compatibility.


Armen, I have written a long specification document which is in draft right now, and being reviewed by a couple of sponsors. It should cater for most of the promotions we can currently think of and some weird ones if you get creative. :) It will be posted shortly after a first review, and will really welcome your comments. Armen you are right, however I will still stick with promotion being based on the order and not the orderline. But yes being on the order does not mean taking into account a promo on a single line. You could have an order which consist solely of a single orderline of 5 items, and you should get a promotion for that. As a counter example we could also have 5 items of the same product, on 5 different lines, and the promotion should still work. So we really have to apply it on the order level on the orderline level it would not work. Hope am not too confusing. Fredtsang 14:07, 10 July 2007 (EDT)


What Promos to Have

  1. Existing Promos: Existing functionality is based on the discount schemas and supports the following options
    1. Flat Percentage: This existing feature allows for a percentage to be discounted from the order. The percentage can be the same for all BPs or can be defined at the individual BP level
    2. Line Level Quantity Based Break: Can define a product or product category, a minimum quantity to qualify for the break, and a discount Percent
    3. Line Level Currency Based Break: Can define a product or product category, a minimum price to qualify for the break, and a discount Percent
  2. Requested Promos
    1. "Buy x Get x": If you order x number of units of a Product or Product Category you get x units of some product free. There should also be a max quantity that the Promo applies to. This should probably also work on currency basis also (i.e. spend $50 get a free gizmo)
    2. Free Shipping: No charge incurred for shipping costs
    3. Order Level Currency Based Break: Based on the total of the order, get a discount percent. (Note: sometimes it's not based on anything, just a result of bargaining - User:Armenrz)
    4. Gift Card: Gift cards can be purchased in advance, and can be applied to purchases until the balance is gone. This might be a whole different animal, but note it here anyway.
    5. Promo Credit: A percent of the price of certain items is added to an account, and can later be redeemed for certain products. (Note: It could also be a point rewards, perhaps we could simply implement it as "just another currency" - User:Armenrz)
    6. Discount on Discount: After you get your discounted price, you'll get another discount. (User:Armenrz)
    7. Additional Discount Amount: After you get your discounted price, you'll get a certain discount amount (sometimes a result of bargaining, sometimes just for rounding down). (User:Armenrz)
  3. Advanced Promos (User:Armenrz)
    1. Exchange Stuff: Bring your old stuff, we'll give you special price. This will require material receipt process.
    2. Discount By Sales Target: Create a sales target period. If your sales performance achive the target, you will get discounted price.

AD Changes

  1. Add table M_Promo
    1. Value
    2. Name
    3. Description
    4. M_Warehouse_ID
    5. C_BPartner_ID
    6. C_BP_Group_ID
    7. C_Charge_ID  : What to charge the expense to
    8. IsCodeMandatory
    9. M_PromoType_ID
    10. M_PromoMin : The number they must purchase to get the promo.
    11. M_PromoMax  : Sometimes there is an upper limit. For example if this is 20, then if they buy more than 20, they only get the free items based on the first 20.
    12. M_PROMO_PRODUCT_ID : This is the item that they get free
    13. M_PROMO_QTY : This is the number of the item that they can get free
    14. VALIDFROM  :Date the promo starts
    15. VALIDTO  : date the promo ends
    16. IsExclusive  : No other Promos can be used
  2. Add to C_Orderline
    1. IsPromoGenerated flag to C_Orderline (for cleanup in case the order is changed and re-prepared)
    2. M_PROMO_ID
  3. Add table M_Promocode
    1. Value
    2. Name
    3. Description
    4. M_Promo_ID
  4. M_PromoType - for adding the different promo methods listed above
    1. Value
    2. Class


Code Specifications

buy x get x

When the order is prepared or completed:

0. Check to see if there are any orderlines where ISPROMOGENERATED=Y AND QtyDelivered=0. Delete these lines- previously generated but not shipped out yet.

1. Check to see if the order BPartner or BPartnerGroup matches to an M_Promo record or if there is an M_Promo that applies to all BPs; and C_Order.DateOrdered is in between M_Promo.ValidFrom and M_Promo.ValidTo if so, then #2.

2. Check to see if C_Orderline.M_Product_ID is in M_Promo where IsActive='Y' AND C_Order.DateOrdered is in between M_Promo.ValidFrom and M_Promo.ValidTo AND C_Orderline.QtyOrdered > M_Promo.MinQty if so then #4

3. Get the Qty to use as MultiplierQty. Take the lesser of QtyOrdered or X_MaxQty

4. Insert a line to the order with M_product_ID=M_Promo_Product_ID AND QtyOrdered= MultiplierQty*M_Promo_Qty AND Price=0 AND M_PROMO_ID= the promo that created the line, AND ISPROMOGENERATED='Y'

See Also

Promotion Posterita Specifications

PROMOTION CONDITION MODEL

Conceptually, a promotion has a qualification criteria and rewards. In simple terms, the criteria is applied to the shopping cart, and if it is met, the rewards are given to the customer. A promotion has many types of conditions associated to it. Primarily, there are 5 different types:

1. Schedule conditions that limit the application of a promotion only within a certain period of time.

2. Targeting conditions that restrict the application of a promotion to a subset of customers (Business Partners, BP Group).

3. A promotion code condition which requires that a correct code should be entered before the promotion can be applied (Coupons).

4. An application limit constraint which limits the number of times a promotion can be applied to an order, to a customer, or overall.

5. A purchase condition which requires the customer to have purchased a certain combination of products, or spent a certain amount on a certain combination of products.

The first four types can be considered pre-conditions. They are the constraints a customer must satisfy before the purchase condition is even evaluated. They generally have a simple model and are easy to implement. We shall focus on how to properly model the last type of condition: the purchase condition.

DIFFICULTIES SURROUNDING PROMOTION

Best Pattern

The major difficulty in implementing the promotion is the ability to have a single item being part of a promotion. This is problematic because there would be potentially hundreds of different combination depending on how the system is configured. Therefore, we could assume that in the interest of the customer, the system should pick the best combination possible. We could define the best combination as in the maximum amount of money the customer would be saving. This requires a very complex mathematical algorithm that would need to be implemented. In essence, it would evaluate in a very efficient way a matrix of different combinations, and pick the best deal. We estimate this implementation to be very costly, so we are discarding this option for now.


Missed Opportunity

If a customer buys an item X that is currently in a promotion of buy 1 get 1 free but forgets to have the free item in his cart. Will we need to be able to send a warning to the person making the sales and to warn the customer about the possible missed opportunity?

PROPOSED SCOPE OF WORK

Priority Algorithm v/s Best Pattern Algorithm

If an item belongs to a single promotion at a given time, then there would be no need for this costly algorithm. If an item belongs to several promotions at a given time, then we could resolve this issue by using priority and also we could warn the user that this item is already in a promotion, therefore there is a possible conflict. The user would need to understand about this potential issue, and thus set the best priority according to the different promotions. We believe that we can safely assume that for most case scenarios, this would be acceptable for the users. If not, we would have to work a quote for the algorithm. With a priority algorithm the implementation will be significantly lower.

Different types of promotion that will be supported

There can be many case scenarios about the promotion and this is a list of the different promotions that we propose to implement. The scenarios listed here are just examples of different types of promotions and the values can be changed as required. • Buy 1-3 X and get 10% off of each, buy 4-6 and get 20% , buy 7 or more and get 30%

• Get 10% off the first three X, 20% off the next three, and 30% off of any additional X purchased

• Buy 3 X for $20

• Buy 1X and 1Y for $129

• Buy 1X , take up to 4Y at 50%

• Buy 1X and 1Y, get 10% off X and get Y for $1.

• Buy 1X get 1X free

• Buy 1X get 1Y free

• Buy 3 items get cheapest one free

• Buy for $1000 or more, get 1X free

DETERMINING WHICH PROMOTION IS APPLICABLE

1. Identify purchase patterns targeted by a promotion

2. Based on the number of times a pattern occurs, determine the distribution

3. Based on the distribution, calculate the rewards associated with that range.

E.g. Promotion: 'Buy 1-3 bottles of water and get 10% off, buy 4-6 bottles and get 20% off, buy 7 or more and get 30% off.' A customer buys 10 water bottles. The purchase pattern is one single water bottle . This pattern occurs 10 times.The purchase pattern is one single water bottle . This pattern occurs 10 times. Therefore, the distribution is '7 or more' and the reward is 30% off.

NOTE 1:

A purchase pattern is usually done by specifying some selection criteria.

NOTE 2:

The quantity requirement contained in the definition of a quantity distribution can be either a single value or a range. E.g. Promotion : ' Buy a water cooler, take up to four bottles of water at 50%'. In this case, if a customer buys one water cooler and one bottle of water, the distribution is a match. If a customer buys one water cooler and two bottles of water, the distribution is still a match; in fact if the customer buys one water cooler and anywhere between one and four bottles of water, the distribution is always a match.

NOTE 3:

Rewards to different items in a target purchase pattern can be different. E.g. Promotion: 'Buy a water cooler and a five-gallon water bottle, and get 10% off the water cooler and get the water bottle for $1'.

IMPLEMENTATION STRATEGY

The Promotion will have 2 main windows. One defining the Promotional Items and the other one the Promotion.

Promotional Group Window

Tab: Promotional Group Fields: • Standard Adempiere Fields (ORG CLIENT etc...)

• Name • Description

• Process button, that will create Promotional Product

Tab: Promotional Product • Standard Adempiere Fields (ORG CLIENT etc...)

• Products ID

Promotion Window

Tab: Promotion Field: • Standard Adempiere Fields (ORG CLIENT etc...)

• Name : name of the promotion

• Description: a full description of the promotion

• Sequence

• Priority Level: sets the priority of this promotion. This will be used to resolve conflicts when a product is part of multiple promotions


Tab: Pre Condition • Standard Adempiere Fields (ORG CLIENT etc...)

• Business Partner(s): the business partner(s) to whom the promotion is applicable

• Business Partner Group: the business partner group to whom the promotion is applicable

• Warehouse: the warehouse for which the promotion is applicable

• Number of times applied (READ ONLY) Start with zero • Number of times limit.

• Start Date

• Expiry Date

• Sequence • Promotional Code: If a promotional code is entered, then at sales time, when completing or preparing the order, a dialog box, will prompt the user to enter the different promotion codes that he may have.

Tab: Purchase Patten

• Standard Adempiere Fields (ORG CLIENT etc...)

• Identifier: Unique identifier to identify the purchase pattern

• Promotional Group: which promotional group to use for matching. • Quantity

• Amount

Tab: Quantity Distribution

• Standard Adempiere Fields (ORG CLIENT etc...)

• Sequence No.

• D_ID • Description

• Operator (>=, <=)

• Quantity

• Promotional Group

• Distribution Operation ( MIN(), MAX(), MINUS() )

• Sorting (Ascending, Descending, Distributed)

Tab: Rewards

• Standard Adempiere Fields (ORG CLIENT etc...)

• Sequence No: to identify a reward • R_ID: reward id

• D_ID: Distribution ID value which will specify which quantity distribution to use for that reward or NULL if all distributions are to be used.

• Percentage Discount: percentage discount on the products in the current distribution or all distributions or Percentage discount on order.

• Flat Discount: Flat discount on the products in the current distribution or all distributions or Flat discount on order.

• Amount: Sets the absolute price that will be given to items from that distribution or all distributions.

• Reward Operation on Amount: (MIN, MAX, MINUS)

• Free Shipping: Free shipping for the products in the current distribution and belonging to the promotional group specified.

• Target: Order, All Distribution, Distribution Line

• Product Cost: Highest, Lowest

• Product

• Quantity


Promotion 1:

Buy 1-3 items of group X and get 10% off of each item, buy 4-6 and get 20% off of each, buy 7 or more and get 50% off the whole. Case: Group X has items A, B, C. The customer has bought 5A + 2B

Model:

Promotional Group Window

Promotional Group: X Promotional Items: A, B and C Promotional Group: Y Promotional Items: D, E, F Promotion Window

Promotion Window

Promotion:

Name: promotion 1

Description: Buy 1-3 items of group X and get 10% off , buy 4-6 and get 20% off ,buy 7 or more and get 50% off .


Pre-Condition:

The fields in this tab do not require extensive analysis, being quite self-explanatory and easily understood at the business and programming level.

Purchase Pattern:

P_ID Promotional Group Quantity Amount
P1 X 1 -


Quantity Distribution:

We have 3 distributions according to that promotion, i.e. 1<=X<=3, 4<=X<=6 and X>=7 Below is the Grid View of Quantity Distribution for easy reference

D_ID Seq Operator Quantity Amount Promotional Group Distribution Operation Sorting
D1 100 >= 7 - X Max ( ) -
D2 200 >= 4 - X Max ( ) -
D3 300 >= 1 - X Max ( ) -


Rewards:


R_ID Target D_ID Seq  %Disc Flat Discount Amount Reward Operation Product Source Quantity Product Cost
R1 Dist Line D1 10 50 - - - - - -
R2 Dist line D2 20 20 - - - - - -
R3 Dist Line D3 30 10 - - - - - -

Promotion 2:

Buy 3X get 1 free Case Scenario: A customer buys 6X +1Y

Model:

Promotion Window
Create a new Promotion X where only A is in X.

Promotion: Name: promotion 2

Description: Buy 3X get 1 free

Sequence: 20