Incorrect subunit calculation for CZK

[sambaranhazra]

Czech Koruna has defunct currency subunit since 2008, though moneta calculation allows without rounding up to next integral.

public void testCurrencyCZK() {
        MonetaryAmount amount = Monetary.getDefaultAmountFactory()
            .setCurrency(Monetary.getCurrency("CZK"))
            .setNumber(207)
            .create();
        System.out.println(amount.multiply(0.34));
    }

results into CZK 70.38 which is incorrect

[keilw]

Thanks for pointing that out. What would be correct to drop the 38 and how does rounding happen in CZ now, could you point us to a source like the national bank etc.?

[keilw]

In fact based on the Wikipedia quote

2008 due to their diminishing purchasing power and circulation.[9] However, financial amounts are still written with the accuracy of 1-haléř (CZK 0.01); prices in retail shops are usually multiples of CZK 0.10. When transactions are made, the amount is rounded to the nearest integer.

So it depends on the kind of calculation, the accuracy of 0.01 CZK still exists at it looks like especially in ebusiness or accounting, only in retail shops (a bit similar to Sweden or other Scandinavian countries) the rounding to the "nearest integer" takes place, but this would be domain-specific in your own application e.g. a cashier system or POS as opposed to online banking, Amazon or Zalando.

Please advise, because for eBusiness it seems correct (above number) while in a kiosk you may have to do a different rounding yourself, but that context is currently out of scope for Moneta and I am not sure, if we'd ever add that.

[sambaranhazra]

Thanks for having a look into this, so does it mean it depends on the cash/electronic payment method and needs to be handled specific to the payment method where it's being applied on?

[keilw]

Yes but that's not something Moneta would do for you, if you have an application you may have a payment method like "Cash", "Card", "Paypal", "Apple Watch" or who knows what else exists nowadays that different vendors and applications offer, that is domain-specific and could not be covered by JSR 354 or the JDK. So I'd say this is out of scope here and given the complexity and variety of payment options it may never be subject to this or other JSR implementations.