I agree with supporting the ability to void an invoice. A voided invoice
would have to be replaced with a new one. This is common practice when a
customer is billed in error.
-Adrian
Vince Clark wrote:
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
vcl...@globalera.com
(303) 493-6723
----- Original Message -----
From: "Adrian Crum" <adri...@hlmksw.com>
To: dev@ofbiz.apache.org
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
