"Illegal" behavior with the "VAT Addon" module

[Razva]

Hello,

Right now the "VAT Addon" module behaves like this:

• when applying payment the "Invoice Date" is changed into the current/today date, which is ok/normal
• the "Due date" is NOT changed, which results in very weird invoices, as sometimes clients pay way after the Due Date

Example:

• Proforma Invoice is issued by WHMCS in 01.11 and has 15.11 as the Due Date (everything normal until here)
• the client makes a late payment in 05.12, aka 20 days after the Due Date
• the accountant registers the payment in 06.12, this resulting in the Fiscal Invoice with 06.12 as Invoice Date BUT the Due Date remains 15.11.2018.

This behaviour is illegal in the vast majority of EU countries, as you cannot issue an invoice ... after its Due Date, or on different months.

Any fix for this?

Thank you,
Razvan

Edited December 4, 2018 by Razva

[brian!]

couldn't you just edit the invoice templates to remove the due date if the invoice has been paid, or replace it with a date paid value instead ??

[Razva]

7 minutes ago, brian! said:

couldn't you just edit the invoice templates to remove the due date if the invoice has been paid, or replace it with a date paid value instead ??

Sure I/we could, but that wouldn't really fix a behaviour that is not appropriate/legal. I think that the solution is for WHMCS to "be legal", not for its (paying) users to search workarounds and gimmicks. It's just my humble opinion.

Meanwhile, you had a great idea! Can't we modify the template so it shows the Due Date as InvoiceDate+15 days? I'm not a programmer but it doesn't looks very complicated?

Edited December 4, 2018 by Razva

[brian!]

8 minutes ago, Razva said:

Sure I/we could, but that wouldn't really fix a behaviour that is not appropriate/legal. I think that the solution is for WHMCS to "be legal", not for its (paying) users to search workarounds and gimmicks. It's just my humble opinion.

I wouldn't disagree that ideally WHMCS should fix this "illegal" behaviour.... but i've seen how long it takes WHMCS to even acknowledge that something might be illegal (they're not invoicing legal experts), let alone get around to fixing it.

if WHMCS were reactive, responsive, dynamic (none of those adjectives will ever apply to them!), then I wouldn't have spent 5+ years thinking of workarounds to resolve issues - and also to get around the pathetic slowness of WHMCS development. 🙄

12 minutes ago, Razva said:

Meanwhile, you had a great idea!

it was bound to happen eventually.

15 minutes ago, Razva said:

Can't we modify the template so it shows the Due Date as InvoiceDate+15 days? I'm not a programmer but it doesn't looks very complicated?

you could do in in the PDF template using (based on v7.6.1 Six template)...

$pdf->Cell(0, 6, Lang::trans('invoicesdatedue') . ': ' . date('d/m/Y',strtotime('+15 days',strtotime($datecreated))), 0, 1, 'L', '1');

adjust the date format accordingly to suit your site..

[Kian]

Well, I would say that it's """"illegal"""" at best. Due date is one of the few values that means nothing to Revenue Agencies. Just remove it as brian said.

[Razva]

1 hour ago, Kian said:

Well, I would say that it's """"illegal"""" at best. Due date is one of the few values that means nothing to Revenue Agencies. Just remove it as brian said.

Unfortunately it doesn't applies to Romania. Here the law imposes both the Invoice Date and Due Date, because it has "contractual meaning". So...yeah... 😕

[Razva]

2 hours ago, brian! said:

You could do in in the PDF template using (based on v7.6.1 Six template)...

$pdf->Cell(0, 6, Lang::trans('invoicesdatedue') . ': ' . date('d/m/Y',strtotime('+15 days',strtotime($datecreated))), 0, 1, 'L', '1');

 adjust the date format accordingly to suit your site..

I've replaced 

$pdf->Cell(0, 6, Lang::trans('invoicesdatedue') . ': ' . $duedate, 0, 1, 'L', '1');

with

$pdf->Cell(0, 6, Lang::trans('invoicesdatedue') . ': ' . date('d.m.Y',strtotime('+15 days',strtotime($datecreated))), 0, 1, 'L', '1');

The "original" invoice is this: 

The result is this: 

So we can consider this as a "win" for now. I'll search for somebody to write a module, because I'm pretty sure this will get overwritten at the first update and diff-ing is a huge pain in the arse.

Thank you very much for your support!

 

[Kian]

You could simply use InvoicePaidPreEmail action hook to increase invoice date by X days with a query. This way it can't be overwritten.

[Razva]

8 hours ago, Kian said:

You could simply use InvoicePaidPreEmail action hook to increase invoice date by X days with a query. This way it can't be overwritten.

I'm no programmer so ... I totally agree with you, but I have no idea how to implement it.

[brian!]

Kian's right - you don't need a module for this, just a hook that updates the duedate value in the database once an invoice is marked as paid and before it is sent to the client... I can't imagine the hook being more than a few lines, so make sure you aren't overcharged!!

[Razva]

4 minutes ago, brian! said:

Kian's right - you don't need a module for this, just a hook that updates the duedate value in the database once an invoice is marked as paid and before it is sent to the client... I can't imagine the hook being more than a few lines, so make sure you aren't overcharged!!

Well ... can you please make me an offer on PM? 🙂