You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by "David E. Jones" <de...@me.com> on 2009/07/08 17:38:24 UTC
Re: svn commit: r792188 - in /ofbiz/trunk/applications/accounting:
data/AccountingTypeData.xml widget/Menus.xml
This is interesting... what does it mean when you cancel a paid invoice?
-David
On Wed, 2009-07-08 at 15:35 +0000, ashish@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>
>
>
Re: svn commit: r792188 - in /ofbiz/trunk/applications/accounting:
data/AccountingTypeData.xml widget/Menus.xml
Posted by Adrian Crum <ad...@hlmksw.com>.
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
Re: svn commit: r792188 - in /ofbiz/trunk/applications/accounting:
data/AccountingTypeData.xml widget/Menus.xml
Posted by "David E. Jones" <de...@me.com>.
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, ashish@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>
> >>>>>
> >>>>>
> >>>>
> >
Re: svn commit: r792188 - in /ofbiz/trunk/applications/accounting:
data/AccountingTypeData.xml widget/Menus.xml
Posted by BJ Freeman <bj...@free-man.net>.
just as a note, I took a different approach to getting the ID numbers to
sequence with out gaps.
I added a two fields that line to the record ID previous and Record ID
next. I keep the first record and last record ID for each record type,
in preference.
The next was more for speed, when do a check that all is valid.
I have a service that runs nightly to check all the records can be
walked from first to last.
So the records Like invoice ID can have gaps but the integrity is
maintained..
David E. Jones sent the following on 7/9/2009 10:57 AM:
> 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, ashish@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>
>>>>>>>
>>>>>>>
>
>
--
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.
Re: svn commit: r792188 - in /ofbiz/trunk/applications/accounting:
data/AccountingTypeData.xml widget/Menus.xml
Posted by Adrian Crum <ad...@hlmksw.com>.
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, ashish@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>
>>>>>
>>>>>
>>>>
>
Re: svn commit: r792188 - in /ofbiz/trunk/applications/accounting:
data/AccountingTypeData.xml widget/Menus.xml
Posted by "David E. Jones" <de...@me.com>.
In that scenario could we just allow the user to change which invoice a
payment is applied to (but leave the invoice as-is otherwise)? This may
fall into the issue that Adrian mentioned, but it sounds reasonable.
-David
On Thu, 2009-07-09 at 11:43 +0200, 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, ashish@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>
> >>>>
> >>>>
> >>>
>
Re: svn commit: r792188 - in /ofbiz/trunk/applications/accounting: data/AccountingTypeData.xml widget/Menus.xml
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
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, ashish@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>
>>>>
>>>>
>>>
Re: svn commit: r792188 - in /ofbiz/trunk/applications/accounting:
data/AccountingTypeData.xml widget/Menus.xml
Posted by Adrian Crum <ad...@hlmksw.com>.
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, ashish@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>
>>>
>>>
>>
>
Re: svn commit: r792188 - in /ofbiz/trunk/applications/accounting:
data/AccountingTypeData.xml widget/Menus.xml
Posted by Ashish Vijaywargiya <vi...@gmail.com>.
Thanks Jacopo for taking care of this.
--
Ashish
On Wed, Jul 8, 2009 at 10:24 PM, Jacopo Cappellato <
jacopo.cappellato@hotwaxmedia.com> 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, ashish@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>
>>>
>>>
>>>
>>
>
Re: svn commit: r792188 - in /ofbiz/trunk/applications/accounting: data/AccountingTypeData.xml widget/Menus.xml
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
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, ashish@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>
>>
>>
>