Jump to content

Eu (Proforma) Invoicing Critical Bug


blesta_tester

Recommended Posts

Hello,

 

When a proforma invoice is issued, the date of a real invoice (not proforma) should be the date the payment is received. Currently we have numbers/dates like that:

 

Invoice 80 2015-02-02 (proforma 3)

Invoice 81 2015-01-30 (proforma 1)

Invoice 82 2015-02-01 (proforma 2)

 

And our taxman visited us today... because it looks like a fraud in EU. Newer invoices with date older than old invoices. I hope you can get it fixed very soon, because no invoicing could be done in EU like that.

Link to comment
Share on other sites

i have not yet tested or reproduce it , but from the OP i have this remark .

the date showed is the date of proforma creation . i think it should have the date of the day converted from proforma to invoice .

i have other scenario . some of our client pay with bank transfert , and some transfert take 2 or 3 days to appear in our account , if we apply the date of the payment recieved it will have 2 days ago , and can be a probleme also , what i suggest to to make the date of the conversion from proforma to invoice .

proforma created (PR22) with date 2-1-2015

client pay by wire transfert in 5-1-2015

we recieve the payment in our account 7-1-2015

(7-1/8-1 is saturday and sunday not working in office) 8-1-205 a client has made order and pay it with online payement invoice created auto with date 8-1-2015 INV-10 )

we apply payment 9-1-2015 fro proforma PR22 and INV-11 is created with date 7-1-2015 .

so in this exemple we have also INV-11 has date older than INV-10 .

what is suggest is to make the date as the date of converting from proforma to invoice (in our exemple is 9-1-2015)

Link to comment
Share on other sites

If the "Bill Date" is the same for the paid invoice as the proforma, then setting the "Bill Date" to the date the invoice is created (same time the proforma is paid), does anything else need to change? For example, it would be possible to have a bill date that is after the due date. How should this be handled, what is the proper way of dealing with all invoice dates?

Link to comment
Share on other sites

I have looked at this case in profound , because is something trivial and critical and cant be wrong , because it could try trouble with fiscalite .

The only good solution that can be good enough for almost all case (maybe theee case i have not rhough in it) is to make the invoice date in date of creation (changing from proforma to invoice) , with that We are sure no invoice with old date .

Waiting the other for thier remark . So for me

-1 for payment date .

+1 for convertion date from proforma to invoice .

Link to comment
Share on other sites

I also experienced this reported bug before.

All of this is coming because 2 differents documents type (unpaid invoice and paid invoice) are sharing at some point same sequential numbering in a single column "id_value" at Table "invoices" in database.

1/ Proforma (unpaid invoice or quote by the way)

Are not really sequential number by now in Blesta because it's re-use old previous number that was existing before (before the switch at payment "date_closed"), so at different time, you can send to different customers , proforma using an old used sequence number "id_value" that was again released.

 

So, it's a traceability & commercial issue. All proforma should be related to an unique content/proposal.

 

2/Paid invoice

should have their very own sequential numbering, created from the payment date (this sequential number column is now missing in Blesta, this new column could be "id_paid")

What accountability request in EU (but not only there), is Paid invoice number are sequential and without numbering interruption (missing number between paid invoices), and the more easy is just to base the number sequence on the payment date, and not like now from proforma sequence, because not all proforma will be paid...
-----------

Unpaid  vs paid are 2 separate "documents" type for the sequencing number

UNPAID:

sequencing is based on creation of the document itself ("date_billed" in table "invoices"), it's ever "id_value", but it's should be persistent (never be changed when invoice is closed)

PAID:

sequencing number should be based on payment date more exactly "date_closed" in Table "invoices", so it will be more suitable to have a new column "id_paid" in Table "invoices"

  In place of:  like Blesta is working now by only sharing "id_value" for both type (unpaid & paid).


So my proposal to solve the issue, will be easy to implement as it's do not change a lot the way Blesta work and for old data, it's will be easy to create the missing paid invoice sequencial "id_paid" number with an Blesta upgrade & SQL query, as "date_closed" is ever know in the database.

 

I past here bellow more detail I given in this post:

http://www.blesta.com/forums/index.php?/topic/3306-pro-forma-invoices-numbering-are-not-sequential/page-3


 

Link to comment
Share on other sites

I have looked at this case in profound , because is something trivial and critical and cant be wrong , because it could try trouble with fiscalite .

The only good solution that can be good enough for almost all case (maybe theee case i have not rhough in it) is to make the invoice date in date of creation (changing from proforma to invoice) , with that We are sure no invoice with old date .

Waiting the other for thier remark . So for me

-1 for payment date .

+1 for convertion date from proforma to invoice .

 

Yes, conversion date is also fine, as well as "Close" date, because when converting proforma to a real invoice (when payment is received) it becomes closed. 

Link to comment
Share on other sites

Hello,

 

When a proforma invoice is issued, the date of a real invoice (not proforma) should be the date the payment is received. Currently we have numbers/dates like that:

 

Invoice 80 2015-02-02 (proforma 3)

Invoice 81 2015-01-30 (proforma 1)

Invoice 82 2015-02-01 (proforma 2)

 

And our taxman visited us today... because it looks like a fraud in EU. Newer invoices with date older than old invoices. I hope you can get it fixed very soon, because no invoicing could be done in EU like that.

 

Backdating any type of document is indeed fraud.

Also keep in mind that in countries that use accrual accounting, VAT becomes due on the invoice date, and has to be paid at the end of the reporting period.

So if you do were to write out an invoice backdated to December 2014 today, the VAT on the invoice should have been paid at the end of Q4 2014, and you are late....

 

 

 

 

For example, it would be possible to have a bill date that is after the due date. How should this be handled, what is the proper way of dealing with all invoice dates?

 

 

 

Invoice date = date the (real) invoice is created. Which as naja already pointed out, can be later than the date the payment was received by your bank, in case of wire transfers and manual payment processing.

Note that -when there is advance payment, which is the case here- you are required to mention the date the payment was received on the invoice as well, but separately, and not as invoice date.

 

Invoices typically only have a due date and additional payment instructions ("if paying by bank transfer, use invoice number 1234 as description") if they have to be paid.

If the invoice was paid in advance, it shouldn't have a due date, as nothing is due.

Link to comment
Share on other sites

@Paul: Simplifying things :)

Pro-forma invoices should always have sequential not reused numbering.

Final invoice should always have the date of creation/converted (im not talking paid date), and should always have for tracking/search propose the pro-forma old number and also all client details saved (simple way as an array) to not be changed ever.

Resolving this will be all good :)

Link to comment
Share on other sites

@Paul: Simplifying things :)

Pro-forma invoices should always have sequential not reused numbering.

Final invoice should always have the date of creation/converted (im not talking paid date), and should always have for tracking/search propose the pro-forma old number and also all client details saved (simple way as an array) to not be changed ever.

Resolving this will be all good :)

very good resume :)

you have zipped all the ideas in 3 lines .

Link to comment
Share on other sites

i have release a new version of admin tools plugin 2.2.0 .

this version has option to fix the sequencial proforma invoicing .

i need a tester and a false/positive case .

for invoice date, i have a obstacle, that i can't know the returned invoice from the invoice.setclosed was a previos proforma . if i can know it i can set the new invoice date easly .

Link to comment
Share on other sites

i have release a new version of admin tools plugin 2.2.0 .

this version has option to fix the sequencial proforma invoicing .

i need a tester and a false/positive case .

for invoice date, i have a obstacle, that i can't know the returned invoice from the invoice.setclosed was a previos proforma . if i can know it i can set the new invoice date easly .

Great, thanks! Does it solve sequence in dates also (close date = invoice generated from proforma date)?

Link to comment
Share on other sites

Great, thanks! Does it solve sequence in dates also (close date = invoice generated from proforma date)?

this will be available in next version .

also i have idea to solve the probleme of editing the invoice closed . :)

the EU invoicing will be fully integrated in my next version of admin tools , stay tunned .

Link to comment
Share on other sites

Solved all issue now. I need to make a profound test before release .

Sequencial proforma is done

Invoice date is date of closed proforma , no probleme in dates

Invoice paid , saved auto in a folder with pdf format , so dont worry if the client change thier info , yiu have a saved pdf with old info .

Link to comment
Share on other sites

  • 3 weeks later...

There is a bug with it, I don't know why yet. Last proforma I wrote the previous month was #41, then of course I accepted some payments, these proforma invoices got converted to a normal invoices, and I've tried to create proforma yesterday. It got #0 assigned. Yes, 0, that's not a mistake :) That's why I ask Blesta developers if they're going to fix that in 3.5, because they haven't fixed it in 3.4.2. Without EU invoicing we cannot use Blesta billing.

Link to comment
Share on other sites

There is a bug with it, I don't know why yet. Last proforma I wrote the previous month was #41, then of course I accepted some payments, these proforma invoices got converted to a normal invoices, and I've tried to create proforma yesterday. It got #0 assigned. Yes, 0, that's not a mistake :) That's why I ask Blesta developers if they're going to fix that in 3.5, because they haven't fixed it in 3.4.2. Without EU invoicing we cannot use Blesta billing.

This is a known problem from blesta, proforma invoices numbers in blesta are reused after conversion to final invoice. we hope next release they will find a solution like me and naja7host has released a temporary fix for this :)

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...