Price is not importing correctly. It imports $1.50 instead of $150 when 150 or 150.00 is the source

Commerce feeds imports the cell straight away into the internal price-field format (integer).

Find attached a patch vs. 7.x-1.0 (current stable release) that adds a third option to the Mappers-configuration-screen:

"Formatted price". By using this mapper option, the attached function will try its way around all currency symbols, thousands and decimal separators and converts this to the internal price-field format.

I briefly tested with these values:
EUR 2.115,50
Fr. 1'225.30
USD 1,215.50

Opps. Wrong patch uploaded first.

use mappers-commerce_price.inc.patch (attached here) to fix the problem described in this issue.
use commerce_feeds.module.patch (attached above in #1) to fix another problem with at least the swiss currency:

There are different symbols in use for swiss franc (CHF). Iso says Fr., M$ says SFr., Wikipedia says CHF, SFr. and Fr. are all fine.
To be able to parse alternative symbols, commerce_feeds.module extends the internal commerce-currencies list with a list of other symbols used for this currency.

Be careful here. The reason this broke is that Commerce itself now stores the actual price as the raw "minor unit" value. So you're better to keep this as minor units and just lose the decimal point.

As I've answered spiffl by mail last week regarding this issue, there is also the "problem" with having a very flexible currency configuration in commerce, you can have the currency symbol virtually anywhere in the price chain, so we can have 35€ or €15, or even 15EUR so is very difficult to take care of every single case, I would say that the best solution is what rfay suggest is to use the minor units and let Commerce to take care of decimals depending on the currency and the symbol.

Sorry if this is a stupid question, but what do you mean with "to use the minor units"?

I really need this patch, but I can't get it to work. The error comes down to:

Warning: require_once(C:\wamp\www\sitename\sites\all\modules\commerce_feeds\mappers\commerce_price.inc) [function.require-once]: failed to open stream: Permission denied in module_load_include() (line 302 of C:\wamp\www\sitename\includes\module.inc).

I installed Cygwin to install the patch. I opened the bat file as administrator (using W7) and I mainly got my instructions from http://randyfay.com/node/70 and http://www.werockyourweb.com/patching-drupal-modules-in-windows.

Am I missing something obvious?

I think we agree here that we're going to stay with the minor units for import. That means that you would put 150 in the import file instead of $1.50.

If your import source doesn't have minor units, you'll probably want to use the excellent Feeds Tamper to adjust the price on the way in.

So don't patch your module. Patch your input source, using Feeds Tamper or otherwise.

Thanks for the quick response!

I had already tried to do it with Feeds Tamper, but I haven't succeeded in adjusting the price.
"7.85" ends up to be "0,08" in products (currency set to EUR).

I first tested out 'rewrite' ([price]*100), but kept getting 0,08
Then I tried 'replace' ("." by ""), just dropping the point. Also without any effect...

Other suggestions are very welcome.

Here's a screencast showing how to do what you need using Feeds Tamper. http://vimeo.com/25722743

Note that Feeds Tamper does not support multiplication or other arithmetic (or php) operations, although it's easy to create your own plugin. So that's why your rewrite approach didn't work.

I believe my method for removing the currency symbol is rather efficient at cleaning out the symbol. With the second patch that adds alternative symbol names (as in CHF, Fr., Fr, sFr...), the remaining sources of error when importing are closed.

Thus I strongly advise to look into the "Formatted price" importer again and at least try to break it so we can improve on the code. But then again, I don't belive you will find reasonably formatted prices that don't parse...
Example for an unreasonable price would be 3EUR 50 as it doesn't have decimal separator...

as suggested by Pedro I'm reopening for discussion.

I understand the arguments by rfay and agree 100%. But then we are not talking about replacing the current import mechanism with the internal units but rather adding an alternative way of specifying prices+currencies at the same time.
And after all, this is a feature request, thus telling people to go and tamper with data rather than just exporting what e.g. Excel or an SAP exports is rather silly.

And I'm confident to say, that you won't find a reasonably formatted price that doesn't import. There, I said it again ,-)

For a change i had price in format "780" without decimals so it ends up as 7.80 EUR.
What you can do is add plugin "Format a number" - decimals = "2"; decimal point = "."
Next add another plugin, exact same shown on the video #11, which is to replace "." with empty string.
Hope it helps someone.

+1 for alternative/additional input method that supports a best effort on "formatted price"

As we've been pointing out in #4, #6, #8 and #11 this is the desired behavior of Drupal Commerce, it's storing the amount for the prices as "minor units" so if you try to import 150 in a currency that is configured with 2 decimals, this would import into 1.50 (i.e EUR or USD).

You can fix this pretty easily two ways: one, add those two zeros to your source, and if you can't do this (I understand there are enviroments where you simply can't modify your origin data), both Feeds and Feeds Tamper provide a quite good API for these afer parse operations.

I'd be happy to add a feeds tamper plugin here to help this conversion if twistor doesn't want to add it to feeds tamper itself.

Great video! (#11 - rfay)

It didn't quite work right for me because of the poor formatting on the csv I had available. I found that using Tamper's "Format a number" will work better in cases where the input data is not consistently formatted -- as in "1" in place of $1.00, while still allowing for 1.5 or 1.95. When creating the filter, set "Decimals" to 2 (or whatever is appropriate in your currency) and clear the fields for "Decimal point" and "Thousands separator"

Hi,

Isn't it better to use a mathematical operation like 100* instead of removing the comma. Because sometimes you don't use a comma but a point.
Mathematical operation with feeds tamper: http://drupal.org/node/1271700
greetings, Martijn

I agree with #18. This way you don't need to force them to have 2 decimal points.

I did it!
1. Use http://drupal.org/project/feeds_tamper 7.x-1.x-dev.tar.gz (31.95 KB) 2012-Feb-02
2. Tamper plugins->
xpathparser:4 -> Price: Amount
Format a number (Decimals: 2) + Find replace (Text to find: .)

I want to convert the price amount on the way in by multiplying it x 100 ie 15 shows as £15.00 not £0.15
I tried using replace addin with value ([price]*100) but this failed. I assume this is because replace will not work on integer fields with the * operator. Please can anyone help me out, I am sure someone has done this already!

thanks muchly!!

@jtreg, https://vimeo.com/25722743

Hi randy - yes I already saw your video but this does not address the problem. I have £150 not £150.00 in the feed file. If it were £150.00 I could have used your neat solution right away. As I said, I am looking for the best way to multiply my Price amount by 100 ... thanks for your reply anyway!

Also I did try format to two decimal places and decimal = "." then replace "." with ""

I even deleted all the products and re-ran the importer.

Please tell me what I did wrong...

@jtreg, all you have to do is add two 0's to the end of your value. Feeds tamper has many ways to help you with this. Experiment with it.

yes, thanks Randy... I figured out that I need to add "00" on (or 00) but I dont see any documentation on feeds tamper - I think the find replace might be a way forward but I am not sure what syntax I need for example, my field is [price]

so, I have
[price]
replace with..
[price]+"00"

(I tried this but it did not work)

I would love to arrive at this by experimenting but for the most part I have reached an impasse and was kind of hoping someone could give me some explicit instructions on this, based on the fact there is scant (absent) documentation. Hope that does not sound too unreasonable.

P.S.
the actual values in the file do not have quotes around them (price amount) - does this mean they are not being treated as a string but as an integer, or does that not matter?

solved it by using the plugin at www.bstraw.com/file/price_convert.zip this still had a bug as it did not convert the last product but otherwise did the trick for me! Thanks to Swig on irc

I kinda of feel that this is not that user friendly.. I was scratching my head for a bit. Why not just add a bit of code in the system to find the decimal and then multiply by that to set it up in the minor units afterwards. I think that way it doesn't matter to the user how the 'system' is storing things. I can imagine some of my clients being seriously confused by this and also when exporting CSV from other systems (for product tracking) and then reimporting online they *always* use decimals. So it just makes another step.

Thoughts?

Hi, see http://drupal.org/node/1159426#comment-5004130 very nicely explained why this is the case.
greetings, Martijn

I've created a fork of Commerce Feeds that incorporates the patches from #1 and #2:
https://github.com/beatchristen/commerce_feeds

The current patch is here:
https://github.com/beatchristen/commerce_feeds/compare/7.x-1.x...1159426...

As suggested in #16, I created a Feeds Tamper plugin using the processing function by spiffl. I reopened the issue, because some cases can't be solved with other suggested solutions. For example I can't multiply the field with a constant value to convert the price to minor units, because my source has product prices in multiple currencies with different minor unit conversion ratios. This plugin is specific to commerce and it belongs to Commerce Feeds, so I haven't tried to submit it for Feeds Tamper.

The plugin extracts the amount and currency, and converts the amount to minor units. A default currency can be specified which is used when the source field doesn't provide a currency. The amount is converted to minor units using the specified or default currency. The results can be written to the source field or to another fields.

Please don't reopen this issue, I think it's been clarified why minor units are used in the comments above.

As for a tamper plugin refers, if you can't modify your source data to add the 0's, you can just append them with tamper if you need them, we shouldn't assume that the currency separator or symbol is in a given place with a given format.

You said in #16 that you would be happy to add a feeds tamper plugin that I provided in my patch, that's why I reopened tha issue. Should I file a separate issue and provide my patch there?

There are cases where the knowledge of commerce currency data is needed, and that is the use case for the solution of spiffl moved into a separate tamper plugin. I can even modify the plugin in a way that has the choice to use a default format but gives the choice to the user to provide the currency and amount in a separate fields, and offers to do the currency->minor unit conversion using the currency data that commerce provides.

Created an issue for a tamper plugin based on this thread and other discussion with pcambra: #1926822: Feeds Tamper plugin to convert an amount to minor units based on currency in another field

Pedro,
I'm not sure if you have looked at the patch properly. I completely agree to your decision that minor currency units are the desirable INTERNAL data format.
The patch takes a CSV source that is usually created by humans with simple means like Excel. Excel knows how to handle currencies rather well, and so does the importer method in the patch:
- If 1.50 is provided, it is converted to default currency + 150.
- If $1.500000 is provided, it is converted to $ + 150.
- If 1.5 $ is provided, it is converted to $ + 150.
How does the converter know how to convert from human readable currency format to the internal data format? Because all the currency information is already stored inside Drupal Commerce: It knows about thousands-separator, major/minor units seprator, currency symbols and names, etc.

I agree with Spiffl.

/open soapbox

The current state of the feeds importer in regards to one of the most mission critical fields (price) is completely and totally non-user friendly and most importantly purpose defeating. Isnt the purpose of having an "import" module suppose to reduce the amount of tasks a user needs to do in order to import basic mission critical fields? The fields I consider to be mission critical are any field that Commerce provides by default (price, sku, title, etc).

I'll give you an example. Pathauto. Does it require the user to add the _ character for spaces? No it doesnt. Why is that? Drupal stores all path's with spaces as an _ right? Just like commerce stores all prices in minor unit format. It doesnt force people's node title's to include an _ because it would be self defeating and defeat the purpose of the module which is to make things quick and easy. I see the same thing here. Just because commerce stores data one way, doesnt mean that the source should also be in that exact same format. So while pathauto is obviously a very simple example, the idea is the exact same. It has source data and it converts that source data to a standard format that drupal is able to utilize efficiently, just like commerce feeds should be doing for drupal commerce data. It should be importing data and converting anything mission critical into something that drupal commerce can understand otherwise, whats the point?

Thus it seems to me that we are going backwards by ignoring the fact that there needs to be some unit conversions done by default or at the very least as a built in option. It's simply unrealistic to think or expect that source data will always be in minor units just like its completely unrealistic to expect all Node titles to be in the format of This_Is_a_Title in order for pathauto to work. If we are completely aware that 50-100% or even 30-100% of the source data commerce feeds is going to be working with will be in a format other than that which commerce uses, then we need to account for that with a built in feature/option of some sort. If this had affected a field other than a default field that commerce provides (say a length field or something that isnt a default commerce field), then yes it would be unrealistic to expect commerce feeds to account for that field by default because it's not a commerce mission critical field. Price however is totally and completely mission critical. It needs more consideration that it's received. The patch that Spiffl provides is completely logical and it actually works well with ALL of the data I've thrown at it thus far. I believe this task should be re-opened and the provided solutions examined and ultimately implemented.

/close soapbox

The current state of the feeds importer in regards to one of the most mission critical fields (price) is completely and totally non-user friendly and most importantly purpose defeating.

Just brilliant. Great way to provide feedback to a module maintainer.

This issue is closed, feeds tamper provides the feature just like that.
Add '00', done.
For more advanced use, i.e. multicurrency import, #1926822: Feeds Tamper plugin to convert an amount to minor units based on currency in another field is the way to go.
And please, if you want it fixed, provide code and not rants.

Let's stop commenting here, this was marked as closed in 2011.

Just in case anyone needs this, I know that this post was closed but I found it helpful. The new version of Feeds tamper provides multiplication so you can edit your prices by selecting the Number - Mathematical Operation. I multiplied my price fields by 100 ([price] * 100). This was the perfect fix for my poorly formatted data which came in with fields like 150, 20.5 and 20.25. Hope this helps someone else. (Oh it's the DEV version that has the new plugin not the production version).

Thank you, very helped!

Sol133 (comment #38) I will find you, and invite you a beer, your comment helped me solving my update price problem, thanks a lot!!