0

I'm developing a website that mostly sells electrical wire. Prices are per kilometer and imported into commerce with 2 decimal places. Order amounts are per meter though, so in a rule I divide the price by 1000 when calculating the unit price. I use the following module for formatting the price with 5 decimals after the decimal point: https://drupal.org/project/commerce_price_decimals_formatter . In the display node this renders the price per meter correctly.

In the shopping cart view, I can also choose to format the price with 5 decimals, but the extra decimals are not shown, and simply show zeros.

So if I have a cable that's priced at

  • € 124.44 / km, it shows
  • € 0.12444 / m in the product display node, but
  • € 0.12000 / m in the shopping cart

The totals in the shopping cart are correct. I'm guessing views is only getting the unit price up to 2 decimals out of commerce. What can be done to fix this?

  • According to the front page of the decimals formatter module, it provides "Views handler for order total with n decimals". If that isn't working as described, I'd suggest this is probably a bug report for that module – Clive Feb 3 '14 at 11:16
  • The views handler is indeed available; the problem is that when I select 5 decimals, the extra decimals past the price field's decimal count are all zero. – Menno van den Heuvel Feb 3 '14 at 13:06
1

Prices are always going to be rounded when saved unless you've updated the definition of the currency itself to support storage to the 5th decimal place. It sounds like that module is simply offering part of the solution, while the whole solution will involve hooking into the currency info array and then updating whatever prices you've already entered to be saved with the new precision.

  • I don't think the unit price should get saved along with adding the product to the cart, as the totals are still exactly right according to the price at 5 decimals. Also: setting the decimal count for the currency to 5 yields an overflow, because the price field in the database is only a signed int32 - and there are products priced at over € 100 000. – Menno van den Heuvel Feb 6 '14 at 12:57
  • Then it sounds like you should also update the type of that column to a bigint. – Ryan Szrama Feb 6 '14 at 21:15
  • That would mean changing all price columns of commerce to bigint. I feel a little iffy about that. What if an update of commerce shakes up the database schema? What if that yields subtle bugs in the code interfacing to the database? I came up with an alternative solution that isn't perfect, but works. – Menno van den Heuvel Feb 7 '14 at 13:02
  • Fair enough. For what it's worth, I would never make a change like that in Commerce 1.x. It's possible the schema changes in Commerce 2.x, but we'll have a migration update path from one to the other. : ) – Ryan Szrama Feb 8 '14 at 13:02
0

I ended up soling this problem in a stupid straightforward way:

I edited the shopping cart and order summary view to

  • include a relation to the product
  • print the personalized product price instead of the line item price, formatted to 5 decimals

Obviously this is going to be trouble when I start including non-product line items, but for the time being I don't.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.