PDF Invoice 5.0.5 – Factur-X marks unpaid bank transfer invoices as fully prepai

  • Posts: 11
  • Thank you received: 2
  • Hikaserial Standard Hikashop Business
1 week 9 hours ago #373422

Hello,

I found what seems to be an issue in the Factur-X generation of PDF Invoice 5.0.5.

In facturx.php, the monetary summation currently always contains:

$this->_addElement($dom, $monetarySummation, $this->nsRam, 'ram:TotalPrepaidAmount', $this->_amount($tax_inclusive_amount));
$this->_addElement($dom, $monetarySummation, $this->nsRam, 'ram:DuePayableAmount', $this->_amount(0));

This means that every generated Factur-X invoice is marked as fully prepaid, regardless of the actual payment method or whether any payment has already been received.

In my case, the payment method is:

order_payment_method = banktransfer

It is displayed to the customer as “Rechnung” / payment by invoice.

The payment method is configured so that the HikaShop order status is immediately set to confirmed. This is intentional, because the confirmation email, invoice and event ticket should be generated immediately after the order.

However, at that point no payment has been received yet. The customer still has to pay the invoice by bank transfer.

The generated Factur-X XML currently contains:

<ram:TotalPrepaidAmount>250.00</ram:TotalPrepaidAmount>
<ram:DuePayableAmount>0.00</ram:DuePayableAmount>

This results in the validator visualization showing:

Prepaid amount: 250.00 EUR
Amount due: 0.00 EUR

But the correct values at the time the invoice is issued should be:

Prepaid amount: 0.00 EUR
Amount due: 250.00 EUR

The Factur-X document passes validation without errors or warnings, because the XML is formally consistent, but the payment information is factually incorrect.

It looks like the current Factur-X generator always assumes that the full invoice amount has already been paid.

Could you please check whether TotalPrepaidAmount and DuePayableAmount should instead be determined based on the actual payment state / payment method?

For reference:

PDF Invoice version: 5.0.5
Payment method: banktransfer
Order status: confirmed
Invoice total: 250.00 EUR
Payment received at invoice creation: 0.00 EUR

Regards,
Thomas

Please Log in or Create an account to join the conversation.

  • Posts: 86214
  • Thank you received: 14221
  • MODERATOR
1 week 8 hours ago #373423

Hello,

Thank you for the detailed report, you were right. The plugin always wrote Factur-X and UBL invoices as fully paid.

We fixed this in version 5.0.6 of the PDF invoice plugin, which you can download now. An invoice is written as not paid yet, with nothing prepaid, the whole amount due and the payment method as payment terms, when the order has no invoice number or uses a payment method chosen in the new "Payment methods paid after the invoice" setting of the plugin.

Since your bank transfer orders are confirmed, and so get their invoice number, before the money arrives, select your bank transfer payment method in that setting after the update. Your invoices should then show a prepaid amount of 0.00 and an amount due of 250.00 in the validator.

Please Log in or Create an account to join the conversation.

  • Posts: 11
  • Thank you received: 2
  • Hikaserial Standard Hikashop Business
6 days 13 hours ago #373430

Hello Nicolas,

thank you for the quick fix in 5.0.6.

I have also reviewed the documentation for onHikashopGenerateStructuredInvoice.

As I understand it, this event allows another plugin to request a Factur-X or UBL document from PDF Invoice, but it does not provide an extension point during the normal automatic Factur-X generation performed by the PDF Invoice plugin itself.

We have a few GfSE-specific additions to the generated Factur-X XML, such as:

adding the participant name to the invoice line description
using a custom HikaShop address field as the Buyer Order Reference
adjusting/removing delivery information where appropriate

At the moment these require modifications directly in facturx.php, which would be overwritten by plugin updates.

Would it be possible to add an event after the XML has been generated, for example something similar to:

onHikashopAfterGenerateStructuredInvoice(&$order, $format, &$xml, $options)

before the XML is embedded into the PDF?

Alternatively, an override mechanism for facturx.php, similar to the existing invoice layout override in media/com_hikashop/plugins/, would also solve the issue.

This would allow site-specific Factur-X extensions to remain completely update-safe.

Regards,
Thomas

Please Log in or Create an account to join the conversation.

  • Posts: 86214
  • Thank you received: 14221
  • MODERATOR
6 days 8 hours ago #373431

Hello,

You read it right: onHikashopGenerateStructuredInvoice is there for another plugin to ask the PDF invoice plugin for a document, and nothing was triggered during the generation the plugin does on its own.

So we added the event you describe, with the name and the arguments you suggested:

onHikashopAfterGenerateStructuredInvoice(&$order, $format, &$xml, $options)

It is triggered once the XML is generated and before it is embedded in the PDF or written to a file, so changing $xml in your plugin is all you have to do. The $format argument tells you which document you are given: facturx, facturx_credit_note, ubl or ubl_credit_note. It fires for the invoices and the credit notes the plugin generates by itself, and also for the documents another plugin requests through onHikashopGenerateStructuredInvoice, so your additions are in what a platform connector sends as well. Your plugin has to be in the hikashop plugin group to receive it.

Your three cases are all changes to the XML, so they fit in it: the participant name in the line description, your custom address field as the Buyer Order Reference, and the delivery information you remove.

This is in the next version of the plugin, 5.0.7 that was just published.

Please Log in or Create an account to join the conversation.

  • Posts: 11
  • Thank you received: 2
  • Hikaserial Standard Hikashop Business
5 days 13 hours ago #373441

Hello Nicolas,

thank you very much for adding the new event so quickly.

I have now updated to PDF Invoice 5.0.7 and moved our GfSE-specific Factur-X changes into a separate HikaShop plugin using:

onHikashopAfterGenerateStructuredInvoice(&$order, $format, &$xml, $options)

We tested it with an existing invoice and the hook works exactly as intended.

Our plugin now modifies the generated XML for:

adding the participant name to the invoice line description
using our custom address field as Buyer Order Reference
removing the incorrect delivery/service date
removing zero-value HikaShop option products from the structured invoice

The resulting Factur-X XML was validated successfully with no errors and no warnings.

So the direct modification of facturx.php is no longer necessary and our changes are now update-safe.

Thanks again for implementing this so quickly — this solves the issue perfectly for us.

#######################################################

BUT, unfortunately I found something new:

while testing PDF Invoice 5.0.7 with a normal HikaShop order, we found another rounding case in Factur-X.

The order contains:

product: EUR 25.00 gross, 7% VAT
shipping: EUR 4.70 net, 7% VAT → EUR 5.03 gross
order total: EUR 30.03

The visible PDF shows:

net amount: EUR 28.06
VAT: EUR 1.96
total: EUR 30.03

However, the generated Factur-X XML contains:

TaxBasisTotalAmount: 28.06
TaxTotalAmount: 1.96
GrandTotalAmount: 30.02
DuePayableAmount: 30.02

So the structured invoice differs from the actual HikaShop order total by EUR 0.01.

This is reproducible with a normal two-decimal shipping net price, so it is not related to our custom Factur-X plugin.

Would this case need to use ram:RoundingAmount (BT-114) so that the amount due remains identical to the HikaShop order total?

#######################################################

By the way, do you have any news regarding the other issue we reported concerning the TCPDF font path conflict between PDF Invoice and HikaSerial?

www.hikashop.com/forum/16-serial-bug-rep...er-status-email.html

We are still using our temporary workaround that normalizes the trailing slash in K_PATH_FONTS, and it works reliably, but we have not yet received any feedback on whether this will be addressed in one of the plugins.

Regards,
Thomas

Last edit: 5 days 10 hours ago by thomas.eilers@gfse.org.

Please Log in or Create an account to join the conversation.

  • Posts: 86214
  • Thank you received: 14221
  • MODERATOR
4 days 15 hours ago #373443

Hello,

You are right on both points, and both are done in version 5.1.0 of the PDF invoice plugin, which you can download now.

The rounding first. BT-114 is indeed the mechanism for it. The VAT of the breakdown has to be the taxable base times the rate, 28.06 x 7% = 1.96, while HikaShop rounds the tax of the product and of the shipping separately, 1.64 + 0.33 = 1.97, so the two are a cent apart. The grand total stays the sum of the base and the tax, which BR-CO-15 requires, and the cent goes in the rounding amount, so that what is due is the total of the order:

<ram:TaxBasisTotalAmount>28.06</ram:TaxBasisTotalAmount>
<ram:TaxTotalAmount currencyID="EUR">1.96</ram:TaxTotalAmount>
<ram:RoundingAmount>0.01</ram:RoundingAmount>
<ram:GrandTotalAmount>30.02</ram:GrandTotalAmount>
<ram:TotalPrepaidAmount>0.00</ram:TotalPrepaidAmount>
<ram:DuePayableAmount>30.03</ram:DuePayableAmount>

The amount due follows BR-CO-16 in both cases, whether the invoice is written as paid or not, and the rounding element is only there when the breakdown and the order total differ. The UBL file of an invoice or a credit note does the same with cbc:PayableRoundingAmount.

This does not depend on your "Round prices during calculations" setting: the document is compared with the total of the order however that total was reached, so the file settles on what the customer has to pay in both modes. The amounts of the Factur-X and UBL files now also follow the decimals the currency of the order is written with, as HikaShop and the payment plugins do, and what the file may carry as a rounding follows the same step, with at least the rounding increment of a currency that has one, like the five centimes of the Swiss franc. A larger difference is left alone rather than called a rounding.

One more thing of the same version, since your bank transfer orders are invoiced before the money arrives: the new "Say how to pay the invoice" setting makes those invoices say how. Fill in your IBAN, the account name and the reference you want quoted, and the Factur-X and UBL files carry the payment means next to the amount due, so the customer's accounting knows where the transfer has to go. What kind of instruction it is follows the payment method of the order, a transfer for yours and a cheque for an order paid by cheque.

The font path is ours, and 5.1.0 takes the plugin out of the way. It does not define K_PATH_FONTS at all any more: the document now names the definition file of each face it draws with, read from its own folder, so it needs no shared constant to find its fonts. HikaSerial then defines that constant itself, with the trailing slash its TCPDF expects, as it does on a site where our plugin is not installed. After the update you should be able to put back the original _getfontpath() of HikaSerial and remove the Helvetica files you copied into the tc-lib-pdf-font folder. Jerome is also planning on updating TCPDF in HikaSerial and moving it into a namespace of its own, which will settle the double load itself.

Please Log in or Create an account to join the conversation.

  • Posts: 11
  • Thank you received: 2
  • Hikaserial Standard Hikashop Business
3 days 20 hours ago #373446

Hi Nicolas,

just a short update after testing PDF Invoice 5.1.0.

The font/TCPDF conflict is now completely resolved. I restored the original HikaSerial TCPDF file and also removed the temporary copied Helvetica font files. Invoice PDFs, Factur-X and HikaSerial tickets are all generated correctly.

During the tests I noticed a separate issue with HikaSerial PDFSerial:

Event orders with a PDFSerial ticket displayed the HikaShop checkout completion message above the Joomla header, while normal book orders without HikaSerial were displayed correctly.

I traced this to HikaSerial:

plugins/hikaserial/pdfserial/pdfserial.php

generatePdf() calls:

ob_get_clean();

but the file does not contain a corresponding ob_start().

Adding an ob_start() at the beginning of generatePdf() fixed the checkout page immediately, while ticket generation and email attachment still work correctly.

I will report this to Jérôme as it appears to be a HikaSerial issue.

I am mentioning it to you only because it became visible during the tests around PDF Invoice 5.1.0. I am not assuming that PDF Invoice caused it — it may simply have exposed an existing output-buffer dependency in HikaSerial.

Thanks again for the 5.1.0 fixes.

Best regards,

The following user(s) said Thank You: nicolas

Please Log in or Create an account to join the conversation.

Time to create page: 0.069 seconds
Powered by Kunena Forum