So I have my shiny commerce_price field, and I want to turn its amount into a nice formatted value ($50.00 for example).
I expected it would be a simple matter of calling commerce_price_format, but it turns out there are additional steps needed.

Snipped from commerce_offer:

$price_amount = commerce_currency_integer_to_amount($wrapper->commerce_offer_price->amount->value(), $wrapper->commerce_offer_price->currency_code->value());
$price = commerce_currency_format($price_amount, $wrapper->commerce_offer_price->currency_code->value());
$price = trim($price);

The reason why I need the trim is the last line of commerce_currency_format:

return t('@code_before @negative@symbol_before@price @symbol_after @code_after', $replacements);

So,
1. Why doesn't commerce_currency_format do the integer-to-amount conversion automatically?
and
2. Why don't we throw in a trim there?

Discussed this with pcambra, and he confirmed that he himself ran into this multiple times, so simplifying it would be great.

Comments

rszrama’s picture

rszrama commented

Adding the trim is easy enough and makes sense. I have a big patch in progress since the middle of last week to address the price conversion - it's just not being easy. : (

bojanz’s picture

bojanz commented

:/

Our storage decision has one more implication: using aggregate functions in Views gives a value that is 100 times too big, so the workflow actually needs to be like this:
1. Add field, set SUM. Set "Exclude from display". Set "Thousands separator: none"
2. Add Global: Math expression, enter "[above_fields_token] / 100".

This workaround needs to be documented, and we need to figure out a way to fix this (our own handler which overrides views_handler_field_field, that only does anything if grouping is on and the field is one of the price ones)

rszrama’s picture

rszrama commented

Well, we can't actually assume it's divisible by 100, so I'm guessing that math expression won't work. Can we define custom math operations that would actually use the price conversion API? It's dependent on the currency's decimals property.

bojanz’s picture

bojanz commented

Of course. It's just a workaround. When we create our own handler (as described in #2), we'll just call our format function and that's it.

pcambra’s picture

pcambra
he/him
Primary language Spanish
commented

Correct me if I'm wrong, but it won't always be 100 times bigger, doesn't this depend on the currency info decimals of each currency? maybe in currencies with 1 decimal (if any) it is 10 times bigger and in currencies with no decimals is just fine.

pcambra’s picture

pcambra
he/him
Primary language Spanish
commented

Marking this one as duplicated #1123860: Views Group By

bojanz’s picture

bojanz commented

I'm repeating what I said in #4.
I'm not planning to hardcode anything. Call the conversion & format functions, then go to lunch :)

rszrama’s picture

rszrama commented
Title: Price formatting is too complicated » Ensure Views support for price aggregation / display since we use integers in the database

Mmm, lunch. Today I had a Gordita Supreme from Taco Bell. ; )

I'm going to rename this issue, because the original formatting issues have both been dealt with in my upcoming price patch. We'll just make this one specifically about ensuring Views support now that we aren't automatically converting values on load.

hunziker’s picture

hunziker commented

With Views 3.x there is a option for using "group by" statements. This is useful for generating reports about sales etc.

The problem is that all amounts are stored as "int" and not as "decimal". So the aggregation functions does generate the wrong output. (For USD, EUR, CHF you need to divide it by 100.) Because the sum field is not any more a price field, you can't apply the currency formatter.

For me its strange to store a price as a integer. Because you need now always a formatter to handle the data properly. Why is not a common decimal or float used?

hunziker’s picture

hunziker commented

Closely related to this issue is that the group by the create date won't work, because the date formating is done with PHP. For reports you want to group by orders by date (for example by months) and then sum the order totals up.

The query produce at the moment looks like:

   SELECT commerce_order.created AS commerce_order_created, [...] FROM 
{commerce_order} commerce_order [....] GROUP BY commerce_order_created

For the correct grouping the query must look like this:

   SELECT commerce_order.created AS commerce_order_created, [...] FROM 
{commerce_order} commerce_order [....] GROUP BY FROM_UNIXTIME(commerce_order_created, , '%m-%Y'), '%m-%Y')

This works with MySQL. For Oracle you need to use the function "to_date()". Does someone knows if this is possible with the database abstraction layer of Drupal?

bojanz’s picture

bojanz commented
Status: Active » Fixed

Views now handles this correctly without the need for extra work on our end.
I just created a products view, grouped by product status, SUMed the price fields, chose "Formatted amount" as the formatter, and it displays correctly.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.