Hi all;
One of the serious challenges in this sort of software is how to support
local regulates when different countries may have different or even
conflicting requirements, and without burdening everyone with everyone
else's local requirements. This is not an easy problem.
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).
Best Wishes,
Chris TRavers
------------------------------------------------------------------------
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
------------------------------------------------------------------------
_______________________________________________
Ledger-smb-users mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-users