Agreed. The original postings should not be modified, no records should be deleted, and the transaction information on the document should not be modified such as the invoice amount and line items. However it would need to be updated with a status of void and preferably a comment written into some column on the invoice (same for payment or shipment if that is what is being voided.)
As far as associating everything with the original record, I think the AcctgTrans table already takes care of this. It has fields for invoiceId, paymentId, invoiceId, workeffortId, etc. I would expect the reversing entries to store the original doc id just like the original accounting entries. I do not see the need for another column. Vince Clark [email protected] (303) 493-6723 ----- Original Message ----- From: "BJ Freeman" <[email protected]> To: [email protected] Sent: Thursday, July 9, 2009 1:17:41 PM GMT -07:00 US/Canada Mountain Subject: Re: svn commit: r792188 - in /ofbiz/trunk/applications/accounting: data/AccountingTypeData.xml widget/Menus.xml what is important, regardless of the name is the process. there should NOT be: 1) modification of a record already created even if done in error. 2) deletion of a record, even if done in error. I believe Vince, Adrian and I are all saying do a reverse entry with appropriate association to the original record. having a field that is used to link to another record in the entity would be a way to accomplish this. Vince Clark sent the following on 7/9/2009 11:31 AM: > Maybe this is just semantics, but the term I am more familiar with (and > comfortable with) is "void." Any "document" in the system that has accounting > consequences should support a void function. This includes payments, > invoices, and shipments. The exception is direct GL entries, which if done > incorrectly should be manually reversed with another entry. > > When a document is voided all associated GL entries should be reversed. This > means that a duplicate entry with opposite debit and credit should be created > and associated with the same document id. Other things should also be undone, > such as payment applications to an invoice. > > This is a quick summary of my view, and is based on quite a bit of experience > with other accounting systems. The main point is that yes, OFBiz should > support the ability to void or "cancel" an invoice. > > Vince Clark > [email protected] > (303) 493-6723 > > ----- Original Message ----- > From: "Adrian Crum" <[email protected]> > To: [email protected] > Sent: Thursday, July 9, 2009 12:17:48 PM GMT -07:00 US/Canada Mountain > Subject: Re: svn commit: r792188 - in /ofbiz/trunk/applications/accounting: > data/AccountingTypeData.xml widget/Menus.xml > > David E. Jones wrote: >> This additional issue makes me wonder if we should allow canceling of >> invoices at all. > > The argument I'm trying to make is this: No, we should never allow an > invoice to be canceled. There are other methods of dealing with these > situations - and those methods have been around for a long time and are > generally accepted as good controls of a company's assets. > > -Adrian > > -- BJ Freeman http://www.businessesnetwork.com/automation http://bjfreeman.elance.com http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro Systems Integrator.
