That's an interesting issue Adrian, and actually different from the one I was thinking about which was breaking a sequence of invoice IDs, and also if you change the ID you would technically need to reissue the invoice to the customer/client (especially if it was already paid chances are they have already received, approved, and of course paid the previous one).
This additional issue makes me wonder if we should allow canceling of invoices at all. We would want to make sure you can "write off" an invoice when you don't think it will be paid, but otherwise it is probably best to work with the existing one and do additional adjusting ones (kind of like the idea of adjusting GL entries) instead of cancel/create. -David On Thu, 2009-07-09 at 10:34 -0700, Adrian Crum wrote: > So you create a credit memo for the invoice that has the incorrect > payment. You issue a debit memo to the party who made the payment, then > apply the credit balance to the correct invoice. I still don't see a > need to cancel a paid invoice. > > I spoke with our accountant - he has never heard of "canceling" an > invoice. He said your approach will open the door for "lapping" - where > payments are intentionally applied to the wrong invoices to make the > receivables look better (cooking the books). > > -Adrian > > Jacopo Cappellato wrote: > > Well, > > > > a credit memo is the right way of doing it if the company is giving back > > some money to the customer (a payment was really received etc...); the > > process we are working on should address the situation where a user, by > > error, applied a payment to a wrong (never issued to customers) invoice, > > and wants to cancel the invoice and use the real payment for other > > invoices. > > All the cancel processes we are implementing for payments/invoices are > > really addressed at fixing user errors. > > > > Jacopo > > > > > > > > On Jul 8, 2009, at 7:58 PM, Adrian Crum wrote: > > > >> Wouldn't a credit memo work in that scenario? Canceling paid invoices > >> introduces a control problem. > >> > >> -Adrian > >> > >> Jacopo Cappellato wrote: > >>> What we would like to implement is the ability to cancel an invoice > >>> to which payment are already applied (by error of the user); the > >>> process, behind the lines, will do the following tasks: > >>> 1) cancel the invoice > >>> 2) post "reverse" GL transactions to reset the invoice transactions > >>> 3) unapply payments (applications) from the invoice (the payment will > >>> then be ready to be applied to other invoices) > >>> 4) post "reverse" GL transactions to reset the payment application > >>> transactions > >>> Jacopo > >>> On Jul 8, 2009, at 5:38 PM, David E. Jones wrote: > >>>> > >>>> This is interesting... what does it mean when you cancel a paid > >>>> invoice? > >>>> > >>>> -David > >>>> > >>>> > >>>> On Wed, 2009-07-08 at 15:35 +0000, ash...@apache.org wrote: > >>>>> Author: ashish > >>>>> Date: Wed Jul 8 15:35:10 2009 > >>>>> New Revision: 792188 > >>>>> > >>>>> URL: http://svn.apache.org/viewvc?rev=792188&view=rev > >>>>> Log: > >>>>> Added one more StatusValidChange record for invoice. > >>>>> Thanks Sumit & Jacopo. > >>>>> > >>>>> Modified: > >>>>> ofbiz/trunk/applications/accounting/data/AccountingTypeData.xml > >>>>> ofbiz/trunk/applications/accounting/widget/Menus.xml > >>>>> > >>>>> Modified: > >>>>> ofbiz/trunk/applications/accounting/data/AccountingTypeData.xml > >>>>> URL: > >>>>> http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/data/AccountingTypeData.xml?rev=792188&r1=792187&r2=792188&view=diff > >>>>> > >>>>> > >>>>> ============================================================================== > >>>>> > >>>>> > >>>>> --- ofbiz/trunk/applications/accounting/data/AccountingTypeData.xml > >>>>> (original) > >>>>> +++ ofbiz/trunk/applications/accounting/data/AccountingTypeData.xml > >>>>> Wed Jul 8 15:35:10 2009 > >>>>> @@ -846,6 +846,7 @@ > >>>>> <StatusValidChange condition="" statusId="INVOICE_READY" > >>>>> statusIdTo="INVOICE_WRITEOFF" transitionName="Write Off"/> > >>>>> <StatusValidChange condition="" statusId="INVOICE_PAID" > >>>>> statusIdTo="INVOICE_READY" transitionName="Unpay"/> > >>>>> <StatusValidChange condition="" statusId="INVOICE_READY" > >>>>> statusIdTo="INVOICE_CANCELLED" transitionName="Cancel"/> > >>>>> + <StatusValidChange condition="" statusId="INVOICE_PAID" > >>>>> statusIdTo="INVOICE_CANCELLED" transitionName="Cancel"/> > >>>>> > >>>>> <!-- payment status --> > >>>>> <StatusType description="Payment Status" hasTable="N" > >>>>> parentTypeId="" statusTypeId="PMNT_STATUS"/> > >>>>> > >>>>> Modified: ofbiz/trunk/applications/accounting/widget/Menus.xml > >>>>> URL: > >>>>> http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/widget/Menus.xml?rev=792188&r1=792187&r2=792188&view=diff > >>>>> > >>>>> > >>>>> ============================================================================== > >>>>> > >>>>> > >>>>> --- ofbiz/trunk/applications/accounting/widget/Menus.xml (original) > >>>>> +++ ofbiz/trunk/applications/accounting/widget/Menus.xml Wed Jul 8 > >>>>> 15:35:10 2009 > >>>>> @@ -297,6 +297,8 @@ > >>>>> <if-compare field="invoice.statusId" > >>>>> operator="equals" value="INVOICE_IN_PROCESS"/> > >>>>> <if-compare field="invoice.statusId" > >>>>> operator="equals" value="INVOICE_SENT"/> > >>>>> <if-compare field="invoice.statusId" > >>>>> operator="equals" value="INVOICE_RECEIVED"/> > >>>>> + <if-compare field="invoice.statusId" > >>>>> operator="equals" value="INVOICE_READY"/> > >>>>> + <if-compare field="invoice.statusId" > >>>>> operator="equals" value="INVOICE_PAID"/> > >>>>> </or> > >>>>> </and> > >>>>> </condition> > >>>>> > >>>>> > >>>> > >
