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.
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.
As I have looked all over for an answer to my question and found nothing of use, I can only assume a) I can't use Google b) I'm the only one stupid enough to not know the answer off my own back.... So would be greatful for any advice or support on this.
Basically I'm setting up a basic e-commerce site. I have the standard products, customers, orders, orderdetails, addresses, and cart tables in place.
What I'm struggling to envisage is how to incorporate cataloguing into my design. There will be hundreds of products and downs of account but not all the products will be available to each account/customer. One customer may only have 4 products in their catalogue to choose from but another may have 50. Would merely creating a seperate catalogue for each customer (CatalogueID against Account ID), at the risk of repeating data, be my only answer?
Hope this makes sense.
Cheers.
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.
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.
I am working on integrating affiliate sales into few existing sites. We are using a few merchants who work via different networks (cj, shareasale, linkshare, Amazon).
Now my observation is that all these networks provide data feeds in different formats. But that's not a big problem. My main concern is actually merchants using different titles on same products. I don't want to run into these situations:
1) two listings of the SAME product from N merchants (if titles are just a bit different)
2) one listing of N different products from merchants (if we don't use strict comparison algorithm)
We want to automate everything as much as possible, want to avoid operators scanning listings under question all the time.
How is this problem typically handled?
I believe a common solution here is to use some universal identifier (UPC code, ISBN code for books, etc). If you can't do that, it becomes a difficult problem, and you probably won't get it 100% right. This may be a silly (and expensive) idea, but perhaps consider using Amazon Mechanical Turk API to have people do it for you (at least the difficult cases which your algorithm can't get right).
All affiliate network feeds have one thing in common: they all list products by a SKU / MPN number that is unique for that product, regardless of affiliate network or distribution channel. That's your unique identifier to key off of when matching different product catalogs across networks.