Edge case using VAT

[robert-stanciu]

Hello,

I have the following scenario that's not outputting the correct total. I know it's not a bug, but what would be a valid solution?

This is the code that's creating an invoice line with a 100k quantity and the price of 100 including VAT (that's why 100 / 1.19)

$line = (new \Einvoicing\InvoiceLine())
            ->setQuantity(100_000)
            ->setPrice(100 / 1.19)
            ->setVatRate(19);
$invoice = (new \Einvoicing\Invoice(CiusRo::class))
    ->addLine($line);
echo $invoice->getTotals()->taxInclusiveAmount;

The output of this code is 9.999.999,99 instead of 10.000.000

[floriankraemer]

I think this ->setPrice(100 / 1.19) is the problem. Try using https://github.com/piggly-dev/php-decimal to fix the issue. I don't think that this is a problem of the library but PHPs precision for this operation 100 / 1.19. Why do you need to divide it and then add it back anyway, if I get that right?

[robert-stanciu]

The reason I need to do that is because a customer could set the invoice line's price as 100 RON including VAT (on my platform).

If it does that with quantity = 1, then we have no issue. However, if he wants 100k units of that invoice line, the invoice's total must be 10.000.000.

I believe that the precision is not the issue because of the way rounding is done in this library. Here's a possible fix I prepared: https://github.com/robert-stanciu/einvoicing/pull/2/files

[robert-stanciu]

Today I found that this behavior happens in the UBL reader too. Because of the roundings that might appear, the invoice line price won't have enough precision to calculate the invoice totals.

This is a solution: https://github.com/robert-stanciu/einvoicing/pull/3

P.S.: I am aware that this edge case can appear only in certain countries.

[josemmo]

Hello @robert-stanciu,

Sorry for the delay.

This is because EN 16931 mandates the price without VAT of an item has to be rounded to 2 decimals. AFAIK, this is just how the specification works.

Maybe CIUS-RO has different decimal precision for some of the invoice fields, but I cannot find the specification in English to verify it.