Replies: 5 comments 5 replies
-
Not sure if it should be part of the promotions API but looking at the resource attached a very nice use case to have is of the referrals. https://www.talon.one/referrals |
Beta Was this translation helpful? Give feedback.
-
wgrt the challenge you highlight @srindom it seems like there are generally two solutions to storing the discounts with relations: Solution A. One way this could be achieved could be to look at the new tax-api for inspiration. In the tax-api two different ways of applying tax exist, it can be applied by product-type or by product directly. This is structured in a way where a tax_rate is coupled to a product, product_type or shipping option by either a product-type-tax-rate(https://github.com/medusajs/medusa/blob/tax-api/packages/medusa/src/models/product-type-tax-rate.ts), product-tax-rate(https://github.com/medusajs/medusa/blob/tax-api/packages/medusa/src/models/product-tax-rate.ts) or shipping-tax-rate(https://github.com/medusajs/medusa/blob/tax-api/packages/medusa/src/models/shipping-tax-rate.ts) entity. This concept could be extended with In the totals calculation the additional rules would be evaluated in a similar way to how for (const item of cart.items) {
if (discount.rule.valid_for?.length > 0) {
discount.rule.valid_for.map(({ id }) => {
if (item.variant.product_id === id) {
discounts.push(
this.calculateDiscount_(
item,
item.variant.id,
item.unit_price,
discount.rule.value,
discount.rule.type
)
)
}
})
}
} This would additional loops to be added for different discount types as is done specifically with the Suggestion 2 A different take on a solution would be to create a more generic discount condition element with an enum value describing the condition applied to the discount i.e. product-type, collection, product, customergroup etc. The object would also contain an identifier of the given element, collection, etc. thus it would look something like this: DiscountCondition{
type: 'product' | 'collection' | 'customergroup'
value: string // ids, amounts, etc.
condition: 'lt' | 'gt' | 'eq' | etc...
} In this way a discount rule would be extended with an array of conditions which could then be checked when the discount is applied to the cart in the totals service in somewhat the same way as above. This solution, though more generic could require additional database queries in order to properly validate the condition if the given information is not present in the cart object when applying the discount. Applying generalised discounts When looking into applying discounts we are considering how we can do so in an extendable way to further empower developers to integrate with external tools (such as [talon.one](http://talon.one)) or to create their own custom validation in the most effortless way. To achieve this abstraction we could again look to the existing generalised implementations in Medusa core. We have already implemented generalised strategies for cart completion and tax calculation, all of which can be found in the Using this same pattern we will implement a DiscountCalculationStrategy interface along with a standard BaseDiscountCalculationStrategy which contains some basic logic for discount calculation but which can also be overwritten to implement discount calculation using services such as [Talon.one](http://Talon.one) as separate plugins. Saving state Because implementing discount calculations like Initially the implementation of |
Beta Was this translation helpful? Give feedback.
-
One of the most important things for any e-commerce store that most headless platforms miss is: tier pricing. This refers to a discount when you buy a different quantity of a specific SKU, e.g. buy 1 of ABC for $10 each, but buy 5 of ABC for $5 each, buy 10 of ABC for $3 each. I'm not sure if this should be part of promotions or if you add to the pricing schema for a SKU, but it is critical for most businesses. I think you can accomplish something like this with promotions by having a "Buy X, get Y Free" type of promotion. |
Beta Was this translation helpful? Give feedback.
-
Hello good morning sir |
Beta Was this translation helpful? Give feedback.
-
Hi there, where are we with those coupon / promotion ideas? Actually it's not possible to
|
Beta Was this translation helpful? Give feedback.
-
Hey everyone! 💜
We are looking into expanding upon the existing promotions capabilities in Medusa and we would love to get some feedback and inputs from you guys. Development on this feature will begin in the near future so the goal is to have a pretty clear idea about what the new API should look like within a week's time.
The current discounts API in Medusa allows you to do simple promotions for a store. Currently, we support:
The above options are pretty standard across most platforms and are also sufficient in many cases; however, we would like to expand upon the existing API to make promotions in Medusa even more powerful. Below are some of the cases that we would like to support going forward:
Stories
Enabling the use cases above would make Medusa extremely powerful by default and would also allow 3rd parties to hook into areas where niche use cases are better managed through other tools.
Success criteria
The goal for the new promotions API is the have a solution that makes the vast majority of promotions use cases easily attainable; while being remaining flexible enough to accommodate more advanced solutions with a bit extra work.
What to build
Some of the rough bigger ticket items to implement are as follows:
redeemPromotion
which can validate a given code against a 3rd party system. This function should be called as part of theaddDiscount
flow.GET /store/products
the api could format the response such thatproduct.variants[0].prices
are “promotion prices” and not the regular prices.SystemPromotionService
which is a default implementation for promotionsConsiderations
How much should be kept in Medusa vs how much should be controlled externally - i.e. if using a 3rd party tool should we store a “copy” of the code in Medusa or should Medusa only have a notion of externally existing coupons when calling
redeemPromotion
POST /carts/:id/discounts
w.{ code: "XYZ" }
{ code: "XYZ", provider_id: "promotion-plugin-provider" }
What should the
IPromotionService
interface look like?redeemPromotion(code, cart, context)
is a good starting point are there other things to consider?My thinking is that
redeemPromotion
will respond with a “Medusa-compatible” format. We need to figure out what this format should look like. Could be something like this:The goal of this format is primarily to allow the
TotalsService
to compute the totals. Which brings us to the next point.How should promotions be dealt with in totals computations. A thought that I think could be powerful would be to introduce
line_item_adjustments
these would adjust the regular line item total by some amount. A rough data model could beThis would allow us to not have to compute the discount all everytime a total is requested.
What rules should be added on top of the existing rule types (r.n. we only have product id)? I think we should add an option for adding promotions based on collection, product tag, product type too.
Research resources
Beta Was this translation helpful? Give feedback.
All reactions