Is there any way to restrict other promotions execution if voucher/coupon based promotion applied with same qualified products
Context:
Created a coupon based promotion rule (couponPromotionRuleGroup)
Created a percentage discount promotion rule (ProductPromotionRuleGroup)
In both cases qualifying products are same (in conditions).
Problem statement:
Expectation here is if coupon based promotion is applied on cart, then do not want to apply other percentage discount promotion cart, though both rule matches with conditions.
Somehow both promotions are overlapping.
I had given a try with Rule execute, somehow it is not working.
your help is much appreciated.
Related
The shopify store I edit has a 'sale' collection. This consists of products which have been auto-tagged on the condition that the 'compare at price' is higher than the actual price.
I want to create a new 'clearance' section, which would consist of products where the actual price is cheaper than the compare at price by 50% or greater. I can't find a simple way to do this (i.e. by using the inbuilt collection creator).
Can anyone help me out?
Discounts are applied at the checkout, not when browsing a product. That is why the Smart Collection logic has no conditions based on discounts. If I were you I would try and work out how to build a collection "clearance" with conditions that make sense, and then you could create a price rule/discount that would apply to that collection (50% off). It seems like that is the way to go.
When adding a promotion you can choose that if cart contains a product you can apply a discount to items in cart.
This way, if you have 5 products in cart and one of them is selected in the rule configuration, all 5 products in cart will have a discounted price.
My question is if this can be modified so only those products selected in the rule will have the discount and not every product you have in cart.
Thank you,
The concept of promotions in Sylius is based on 3 pillars: rules, actions and filters.
rules specify in which case promotion will be applied (in your case it when order contains a specific product) - so they have nothing in common with a discount applied
actions are about what discount is applied - which means how many money/how big percentage of money will be cut of the final price of order/item
filters are about on which items discount will be applied (so they're strictly connected with item-based actions)
So in your case you should specify "Contains product" rule, then add a "Item fixed/percentage discount" action. And if you want to apply discount only on specific product - you must configure "Product filter" with it.
I know it can be a little bit confusing at the first time, but if you think about it's quite good separation of responsibility.
So one more time:
rule - when to apply promotion
action - how big discount is
filter - on which items it's applied
Hope it helped ;)
My primary business is pre-orders, and this is how it works:
I list an item for sale.
My customers order the item. Their credit card is authorized but not charged.
Once a minimum number of orders are placed, the customers are charged, and the buy is live.
If, after a specified amount of time, the minimum is not reached, all orders are cancelled.
What i would like to do is this:
Specify the minimum number of orders needed for a particular item in the backend. (not 100% needed, but it would be nice).
Display the total number of pre-orders on the product page, so that my customers know how many are left before the buy is live (it would be great to show it in the following format: 23/50 Ordered).
Does anyone know if this is possible? If so, can you please explain to me what I need to do in order to make this happen?
Thanks!
P.S. - In case it doesn't show up, I'm using Bigcommerce
Store the minimum needed as a custom field & set the initial inventory to that same number. You'll also need to allow inventory to be displayed for pre-orders, though you can hide it from display if you'd like (we only want it present in the DOM).
As the products are pre-ordered, inventory will decrement. Use javascript to subtract the number left in inventory from the original number (the custom field) and display in the ProductDetails.html panel.
I've got to build a standalone menu button with submenu that contains links to price ranges.
I activated the blocklayered module (not for this task, only for regular left-column filters). So the relative db tables are in place and populated.
I want to make a controller specific for price ranges. So I've got to do the right query and maybe set up the same url vars as the blocklayered module so they wil not conflict.
Would it be too crazy to import blocklayered or blocklayered-ajax in my controller and use part of their functionality? Maybe not good because of object duplication or other issues?
Or maybe, would it be a bad idea to use the blocklayered tables (for example layered_price_index) to help me get filtered products? I'm wandering if it would be a better solution than re-doing all by myself, or if instead it's not good for some reason.
Any idea?
It really depends on which amount (among the ones below) you would like to take into account in your price range filter:
Amount without taxes
Amount including taxes
Amount including discount/promotion
Amount in several currencies or only one currency
Amount for a specific customer group or for everyone
Amount base on any other product price rule
The easy way:
You can build a price range controller easily by yourself, handling only a single currency and prices without taxes and reduction. It will probably be 90% accurate (because of the missing discounts a product might not show up for a certain range).
In that case, you can easily build a query on the ps_product and ps_specific_price tables and SELECT in real-time the right products for a given range.
The proper way:
You want to handle discounts, price rules, specific prices, etc. If you build a real-time query including all these calculations and parameters, it may slow down the server.
Build a product price cache or re-use the one setup by the Block Layered module.
I have a quote that contains items (store in table QuoteItem):
QuoteItemId, QuoteId, ItemId, Quantity etc.
Now, I need to be able to create a group of chosen items in the quote and apply a discount on it.
Well that's simple, I create two more tables:
Group: GroupId, DiscountPercentage
GroupQuoteItem: GroupId, QuoteItemId
Let's say I have 30 items in a quote.
I made a group that contains items 1-20 from the quote and I applied a discount on it.
Now I need to have another group that contains items 10-30, the problem is about those inner 10 items, I need to control whether the discount should apply on the items after the other discount or it should be on the items' base price.
For instance, I am gonna talk about item no. 15 in the quote: QuoteItem.Cost = 100
I applied 1st discount of 10% = 90.
Now I want to apply the second discount, I need to be able to control if the discount should be on the 100 or should be on the 90.
Same is when I have multiple discount groups and when I wanna apply a complex architecture of discounts.
Any assistance will be really appreciated.
I would look into adding a column to the GroupQuoteItem table, GroupQuoteItem.Priority. This column would be used in the query that determines the final price. If you have N discounts with the same, highest priority, they will be stacked atop each other (the order doesn't matter, thanks to associativity of multiplication).
If all of these high-priority discounts are later removed, lower-priority discounts can take their place. This should help you in setting up pretty complex discount structures.
I hope that at least gives you somewhere to start from.
It really depends on your own business rules. Do you want to apply the discounts on the price after discount or on the original price. When you ask questions like this it helps with SAMPLE Data then show us expected results.
This may be one of those rare times in normalization when you want to store data that you could calculate otherwise. So, in QuoteItem, you could have a Cost field and a DiscountedCost field. If they're the same, then you know no discount has been applied, if they are not, then a discount has been applied. By having this field, you would also be able to do comparisons on what the discount is already and whether you want to add the additional discount. In fact, you could also store that number in an ExistingDiscount field.
Why not store a column in the Group table that specifies whether or not the discount can be accumulated with other discounts versus if it must be applied to the base price only? You could name the field something like "ApplyToBasePriceOnly."
Other than that, I agree with JonH that a lot of this logic should be placed in business rules. I think your general database structure looks pretty good.