Chris Travers wrote: > 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 <[EMAIL PROTECTED]> 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).
What about those companies that use alphanumeric invoice numbers? While I understand what you're saying and why you want to do it the way you're suggesting, it would force companies who don't use numeric, sequential numbers as invoice numbers to start using sequential numbers or find a way to continue using their alphanumeric invoice numbers by hacking the system in some fashion. I'd also like to suggest that, for reversing transactions, why not store the original invoice number, if each invoice will increment (whether it's a reverse or a credit)? Charley > 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 > Ledger-smb-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ledger-smb-users ------------------------------------------------------------------------- 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 Ledger-smb-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
