Prestashop: Display of a different currency between FO and Invoices

[onklmaps]

EDIT:
Is your feature request related to a problem? Please describe.
Editing the display of the currency on the FO change as well the currency on the order or invoice (and all the financial document related to an order). The change can make an invoice not acceptable from an accounting perspective for some business, mostly for B2B. That would be a reason not to have your FO customized for fear of making a bad invoice.

Describe the solution you'd like
The possibility to edit the currency display of the FO and of the documents on the order page.

Describe alternatives you've considered
Have a single currency configuration for all the financial documents.

We often find us self wanting to _clean up_ front office prices, removing the decimals:
so that: 10,40 becomes, 10 and 10,50 becomes 11.
Editing /translations/cldr/main--xx-XX--numbers from
from "standard":"\u00a4\u00a0#,##0.00"
to "standard":"\u00a4\u00a0#0"
works fine.

However, when the tax/vat (in my case 25%) is to be calculated on the invoice, PrestaShop still uses the "standard" parameter (now without decimals), and now it becomes an issue.

Let's say a order total is: 99 tax included.
Tax is 25% of this, or in amount 19,80
When cutting away the decimals, however, PrestaShop shows the tax amount as 20 kr.
Should'nt PrestaShop use the "accounting"-parameter from the cldr for all values in invoices?
In my example:
"accounting":"\u00a4\u00a0#,##0.00",
"standard":"\u00a4\u00a0#0",

If this is changed, we can both show _clean_ prices to customers in FrontOffice, but still calculate correctly when doing the accounting. It should be noted that also integrations should get the "real" / "accounting" price, so that for example an integration with an accounting-system would get the correct calculations. Maybe same with everything in back-office.

[khouloudbelguith]

Hi @onklmaps,

It's planned to remove the number of decimal parameters in Shop parameters > General.
You can follow this ticket: #12223
And it's also planned to add this feature in CLDR part 2: #11660

Thanks to check & feedback.

[eternoendless]

I discussed this with @onklmaps on gitter.

Basically CLDR defines not one, but _two_ patterns for formatting prices:

• "standard" pattern (the one we use)
• "accounting" pattern (which we don't)

It could be a good idea to add optional support for the accounting pattern, which would be used in invoices only.

Wdyt @colinegin @samuel-pires @marionf ?

[onklmaps]

I think it's also a good idea to use the "accounting" other places too. The issue applies everywhere tax/vat is being calculated: cart totals, checkout.
In _the old 1.6 days_ when turning off decimals was still an option, we would with some payment methods get payment error due to rounding issues with vat/tax.

I would argue that the _correct_ "accounting"-price is the one to be used behind the scenes, but the "standard" one is to be used when displaying product prices to customers.

Price display method could be an option in the customer group settings. B2B-customers could use "accounting" for example whereas b2c could use "standard".

[eternoendless]

I think it's also a good idea to use the "accounting" other places too. The issue applies everywhere tax/vat is being calculated: cart totals, checkout. [...] I would argue that the correct "accounting"-price is the one to be used behind the scenes, but the "standard" one is to be used when displaying product prices to customers.

This a fundamental misunderstanding. CLDR is meant exclusively for display, and should not be taken at all into account when performing calculations. That is, calculations should always be performed with the maximum possible precision, then rounded up for display according to the CLDR specification.

I think the correct issue here is allowing prices to be displayed without decimals, but always display decimals (aka the accounting format) at least for invoices, and maybe in order details as well (to avoid rounding errors with taxes for example).

[onklmaps]

That is, calculations should always be performed with the maximum possible precision
I just fell in love with PrestaShop even more ;-)

Yes, I belive taxes should always be displayed with the "accounting" pattern, because the math needs to be correct. But also then the cart total should be displayed with "accounting" pattern, so that we get "calculation":

Like this:
Cart total: 25,49 EUR
Tax 25%: 5,10 EUR

Not this:
Cart total: 25 EUR
Tax 25%: 5,10 EUR

You could also argue that all prices in the checkout/cart should be in accounting format to avoid "calculations" like: 50 * 10 = 495 (if it was not obvious, the numbers behind the scene in this case: 49,500000000 * 10 = 495,000000000).

[MatShir]

Indeed, it is a good point. For the invoice and order details in the checkout, it seems a necessary needs, especially for B2B.

Is the CLDR file complete enough for the accounting part for all currencies?
Can we rely on it if we don't offer customization in the BO? Wdyt @eternoendless ?

I imagine a good start will be if there are any missing values, we could start with two decimals.

@onklmaps Aren't you afraid of customer incomprehension for the total price variation?

[eternoendless]

After further analysis I found out that the accounting format is probably not the answer after all.

The number of significant decimals is defined by the currency, whereas the accounting format is defined by the locale. Therefore, using the accounting format wouldn't help us in showing a different number of decimals in some contexts.

Worse, in many popular locales (including English, French and Spanish) negative numbers are shown between parentheses when using the accounting format:

If your language uses different formats for negative numbers than just adding "-" at the front, you can put in two patterns, separated by a semicolon. The first will be used for zero and positive values, while the second will be used for negative values.
For example: #,##0.00¤;(#,##0.00¤) is used to make negative currencies appear like "(1'234,56£)" instead of "-1'234,56£". That is used for formatting currency amounts in English, but not for general-purpose decimal numbers.

(source)

Example from localization/CLDR/core/common/main/en.xml:

<currencyFormat type="accounting">
  <pattern>¤#,##0.00;(¤#,##0.00)</pattern>
</currencyFormat>

When using the accounting format, discounts in US English would appear as ($1,234.56) and not -$1,234.56.

We could still add support for two distinct number of decimals, one for displaying prices, and one for order detail/invoices/etc. This would be handled by setting both to the CLDR default on creation, then letting the user change both independently when editing the currency. But it will introduce more complexity, as there will be two ways to format prices, one for "orders and invoices" and the other for "product prices".

[khouloudbelguith]

Hi @MatShir,

Any news about this issue?

Thanks!

[MatShir]

Hi @khouloudbelguith,
As @eternoendless said, the "accounting" system is not the right solution but the need for this functionality is clearly there. That would be a reason not to have your FO customized for fear of making a bad invoice.
Anyway, we must wait for the final integration of the CLDR on the 177 to add any more feature to the price management.

I will edit the original and the rename the issue to have a clearer view of the needs.

[onklmaps]

Please keep in mind also in the process of finding a good sollution that tax calculation in the cart/checkout MUST be done with the highest precision allowed by the currency, not more, not less. Regardless if one chooses to cut of decimals in product price display.

Let's say I want to remove decimals in FO product prices and a product is priced to 11 tax included. Then in checkout this should be (with 25% tax) 8.8 tax excluded, and the tax should display as 2.2. Not 9 (Or 8, I don't remember) and 2, like today if I choose to cut away decimals from the cldr file.