On 7/24/07, Victor Sterpu <..hidden..> wrote:
This is what I was saing also. I need a new invoice number.
I proposed a unique index on invnumber. :)
The commentary is also not sufficient.
Because the reverse invoice may contain lines that don't have nothing
to do with the revered invoice.
There is a difference between a credit invoice and a transaction reversing reversing a voided invoice.
If you void the invoice, you are essentially saying that the document as a whole is (and has always been) invalid and is reversed atomically. In the US, we might do this by taking the initial invoice and writing VOID in ink on the face. In essence in many countries there may not be any other documents involved.
I.e. if I void a check (or cheque, depending on locale) there is no separate document, just a reversing entry in the GL.
A credit invoice would be a matter of partial reversals, or other credits, etc. That is a different matter.
I have done some work in trying to support the Greek requirements in the past. Unfortunately, it is not something that is entirely generally applicable to large sections of the market and has serious scalability costs (a lot of things have to be serialized using db locks because gaps in numbering of printed documents are absolutely not allowed).
I suppose I would be OK with adding a prefix to the reversing transaction (for example V, so an invoice 11001 would be voided with an invoice V11001) but I expect this would probably run amok with a lot of local rules as well (especially those that don't allow letters in invoice numbers or gaps in other sequences).
My suggestion at the moment is that we:
1) add a unique index on ar (invnumber, reverse) and by default keep the same invoice number on void. Credit invoices (other than voids) would use incrimenting invoice numbers.
ar.reverse is a new field in 1.3 which provides for tracking of an invoice's reversal status (i.e. credit invoices would have this flag set as would voids).
2) Allow for a patch which adds a unique index on ar (invnumber) and drops the invoice number before posting so that it incriments. This could be distributed in /contrib or the like.
Best WIshes,
Chris Travers
By example:
1) You have a invoice that contains product P with qty 10.
2) You have another invoice that contains product P with qty -5, and
another product P1 with qty 5.
This is the credit invoice scenario and there is no way in the current schema that we are able to adequately track related invoices. This isn't really the same as a voiding transaction though.
This is a valid case. Let's say products P are all defect, so we
replace them with P1.
In this case, a invoice number that points back to the initial invoice
is not exactly what we need.
Because we do not reverse the invoice, but only a line(partial) from
the initial invoice.
I think we may be able to add such tracking for 1.4, but there are also general human interface issues to contend with (and these are not easy problems either). The big issue is that a voided invoice probably should be immediately recognizable as such in a report, and an auditor should be able to trace what happened at each stage (
i.e. this invoice was voided because.... and here is the reversing transaction).