Pedram poses a problem regarding discounts for product customizations.
Example
If you apply a specific price for 100 pieces, let's say 5% discount, and you add 50 t-shirts with print A and 50 t-shirts with print B, you get a discount. But in reality only 50 pieces of one print production is sold. So there shouldn't been any discount (perhaps in my opinion).
Let's take a crazy example, say we have 100 different prints, then you would have to set up the printing production 100 times! And there for the discount for 100 pieces is not appropriate anymore.
Question
How can I make discounts (specific price) only apply to an indivual customization in the cart?
Further thought
My guess is that it should be changed somewhere in the core. Hopefully with a not to invasive class override. The setting PS_QTY_DISCOUNT_ON_COMBINATION tells if a discount should apply to the whole product or only to the combination. This setting is used in SpecificPriceCore::getSpecificPrice(), and doesn't seem to be the key in solving this problem.
While it's possible combinations, setting a specific price for customizations (not to be confused) is unfortunately is not yet supported in the Core.
It looks that this cannot be done by means of an override because you'd probably need to add a new parameter to getSpecificPrice(), among others.
Feel free to submit a pull request if you want this feature added to the Core (branch develop for 1.7), or add a ticket to the forge.
Related
So I am trying to take payment and book appointments for my oil change shop, I found an app that takes care of the scheduling, but now I need to make the product change prices based on the make/model/year of the car. Pricing is pretty simple, $49, $59 or $79 based on the labor for the specific make/model/year. I have a database and excel sheet with the corresponding price for every car we service.
I've tried a lot of apps and none of them seem to fit. Currently, I'm using Infinite Product Options which allows me to change the price based model but doesn't pay attention to the year (which I could live with) but I can't find a way to validate the selection. i.e. if Ford is selected as the make, it should only show cards made by Ford in the model dropdown.
Is there a better way to do this? Is this a feature in the app that I am missing?
Appreciate any help you can offer!
A long time ago I made a car shop or two or three. All of them used the standard MODEL/MAKE/YEAR selections for choosing things like available tires, etc.
So that magic is controlled by a mafia and you pay for access to it. It costs something like $2000 but that may have changes. Anyway, if someone chooses Ford, they only get Ford cars, which means MAKE choices are so much easier. I suppose it is also smart enough to know you cannot have a 1972 Ford Taurus.
Once you get past that brain dead selection, you could present the correct variant, and hence the correct price by having that selector match variants based on some magic. A back-end script might use the MAKE/MODEL/YEAR result to find a product that matches the make, then the 100 variants would cover model (for the most part).
Anyway, tough for you as yes, those low-fruit on the tree Apps for product options are generally too simple for serious use.
I've tried asking this on the main Sitefinity forums but had no luck as such.
I have a given scenario and I am wondering how this could be structured in the Sitefinity eCommerce module.
I essentially have two product types, a full product and spare part. As expected spare parts relate to full products and some spare parts can relate to different full products.
I have modeled this structure in Sitefinity fine using a Related Data property on the full product with the ability to select multiple spare parts per product.
My issue arises when I create variants of the full product and the main variant attribute is essentially the design print on the full product. I need to be able to associate a spare part to a specific variant, an example being a replacement cover that has the specific design print on so can only ever be associated with a variant of a full product. So in effect I just need a Related Data property against the variant rather than the product itself if that makes sense.
Is this possible out of the box in Sitefinity? If not, can I structure my product / spare parts in manner that I can query spare parts on a variant basis? Or do I need to model this outside of Sitefinity?
Thanks.
PS I am fairly new to Sitefinity development so if there is anything I could have missed please let me know.
anyone could address me to solve the following issue?
In PS 1.4 I have a generic discount (6 pieces, 10% reduction). But it can be that I add a specific price discount starting from 1 piece, let's say 20%.
Now, PS applies the generic discount (10%) when I order 6 or more pieces, and the higher (20%) if I order from 1 to 5 pieces.
Basically, the more I buy, the more I pay...
the easiest solution would be to intercept the lines of code which actually add the prices to the cart. Where are they? Any idea?
In the cart class, i'm not really familiar with 1.4, but i think there is a function called "checkDiscountValidity". I can see that all discount validations are made there, so override this method and add your own validations (adding a hook to a created module should be better in my opinion)
Note: Images are clickable to allow zoom
I have problem with this database design, I have different solution but none of them satisfact me enough.
The software is about a configurator for a product. You can choose with this configurator all the extras that will increase the price.
This is the data that I should present to the user. What's giving me problems is the fact that there are 2 type of extras:
This type of extra doesn't have a price, is merged inside a package which has a price for all its extras. (Relax [A123] is an example of package with price, first image)
This type of extra has a price and its package doesn't have any price, because they aren't boundled in the package (Water supply is an example of package without price)
Here is my current design, which I'm not satisfact with:
(Ignore ExtrasCategory which is only to group up extras)
The biggest problem is that each Extra (the class now) belongs to a package, even if it doesn't have a price.
However, each Package may have a price different for each Boat, so I need to set different prices.
I want something like this:
Each Extra has a "basic" Package.
If the Package has a price, we set it differently for each boat
If the Package doesn't have a price, we can use the "basic" Package of the Extra
However in this way I have redundancy: Extra has a Package, BoatExtra (an extra with price) has a BoatExtrasPackage and so we have 2 times a reference to a package
How can I solve this design issue?
Edit 1: Ok I've created an image which explains better what I want. I want a "default package" for an extra (on a per-extra basis), if the BoatExtra doesn't have one.
You have redundancy in your design ie: code and name. I would do it as attached if I understand properly your system.
Seems the problem is that I want to minimize space consumption, not make a good design. After I understood I were doing this (which for me it's wrong) I came up with a totally different design which is better than the previous one and fixed my problem.
I obviusly need to build more packages but this is what the logic wants
I'm trying to set up Schema.org metadata on a site at the moment, and I'm wondering how (or if) to declare multiple currencies. I have 6 formats of the price - GBP, USD and EUR, all with inc. and ex. VAT prices.
Based on the examples Schema provide on the Product page, there is only ever 1 price - is it possible to specify more, and if so, how does the search engine decide which one to show? If not, I'm assuming I should show GBP inc. VAT - is that correct?
It's really the Offer that has a price associated with it. If you look at the second example on the Offer schema page, you'll see multiple offers associated with a single product. They're from different sellers (and don't specify the price in a machine readable way), but you could do the same thing with multiple offers in different currencies from the same seller.
I'm not sure there is a way to express inclusive or exclusive of VAT in the schema, so you may be stuck with just text labels for that.
If it’s the same Offer and you allow payment in multiple currencies, you could use multiple priceSpecification properties.
Each property has a PriceSpecification as value, which can have a price (via price property) and a currency (via priceCurrency property).
how does the search engine decide which one to show?
That’s up to the search engines. When you specify the currency, they have all they need to know (if or if not they use this information is a different question, off-topic for SO). Schema.org doesn’t provide a way to mark a "primary" PriceSpecification, and why should they? After all, all your prices are valid.