OFBiz › OFBiz - Dev

Re: svn commit: r792188 - in /ofbiz/trunk/applications/accounting: data/AccountingTypeData.xml widget/Menus.xml

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

17 messages Options

David E. Jones-2

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, [hidden email] 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"/>
>
> 
> <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>
>
>

Jacopo Cappellato-4

Re: svn commit: r792188 - in /ofbiz/trunk/applications/accounting: data/AccountingTypeData.xml widget/Menus.xml

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, [hidden email] 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"/>
>>
>> 
>> <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>
>>
>>
>

smime.p7s (3K) Download Attachment

Adrian Crum

Re: svn commit: r792188 - in /ofbiz/trunk/applications/accounting: data/AccountingTypeData.xml widget/Menus.xml

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, [hidden email] 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"/>
>>>
>>> 
>>> <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>
>>>
>>>
>>
>

Ashish Vijaywargiya

Re: svn commit: r792188 - in /ofbiz/trunk/applications/accounting: data/AccountingTypeData.xml widget/Menus.xml

In reply to this post by Jacopo Cappellato-4

Thanks Jacopo for taking care of this.

--
Ashish

On Wed, Jul 8, 2009 at 10:24 PM, Jacopo Cappellato <
[hidden email]> 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, [hidden email] 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"/>
>>>
>>> 
>>> <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>
>>>
>>>
>>>
>>
>

Jacopo Cappellato-4

Re: svn commit: r792188 - in /ofbiz/trunk/applications/accounting: data/AccountingTypeData.xml widget/Menus.xml

In reply to this post by Adrian Crum

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, [hidden email] 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"/>
>>>>
>>>> 
>>>> <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>
>>>>
>>>>
>>>

smime.p7s (3K) Download Attachment

Adrian Crum

Re: svn commit: r792188 - in /ofbiz/trunk/applications/accounting: data/AccountingTypeData.xml widget/Menus.xml

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, [hidden email] 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"/>
>>>>>
>>>>> 
>>>>> <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>
>>>>>
>>>>>
>>>>
>

David E. Jones-2

Re: svn commit: r792188 - in /ofbiz/trunk/applications/accounting: data/AccountingTypeData.xml widget/Menus.xml

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, [hidden email] 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"/>
> >>>>>
> >>>>> 
> >>>>> <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>
> >>>>>
> >>>>>
> >>>>
> >

David E. Jones-2

Re: svn commit: r792188 - in /ofbiz/trunk/applications/accounting: data/AccountingTypeData.xml widget/Menus.xml

In reply to this post by Jacopo Cappellato-4

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, [hidden email] 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"/>
> >>>>
> >>>> 
> >>>> <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>
> >>>>
> >>>>
> >>>
>

Adrian Crum

Re: svn commit: r792188 - in /ofbiz/trunk/applications/accounting: data/AccountingTypeData.xml widget/Menus.xml

In reply to this post by David E. Jones-2

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

Vince Clark

Re: svn commit: r792188 - in /ofbiz/trunk/applications/accounting: data/AccountingTypeData.xml widget/Menus.xml

In reply to this post by David E. Jones-2

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
[hidden email]
(303) 493-6723

----- Original Message -----
From: "Adrian Crum" <[hidden email]>
To: [hidden email]
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

Adrian Crum

Re: svn commit: r792188 - in /ofbiz/trunk/applications/accounting: data/AccountingTypeData.xml widget/Menus.xml

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
> [hidden email]
> (303) 493-6723
>
> ----- Original Message -----
> From: "Adrian Crum" <[hidden email]>
> To: [hidden email]
> 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

Re: svn commit: r792188 - in /ofbiz/trunk/applications/accounting: data/AccountingTypeData.xml widget/Menus.xml

In reply to this post by David E. Jones-2

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:

--
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.

Adrian Crum

Re: svn commit: r792188 - in /ofbiz/trunk/applications/accounting: data/AccountingTypeData.xml widget/Menus.xml

In reply to this post by Adrian Crum

Looking back through the commit and re-reading Jacopo's comments, I
believe Vince is correct about semantics: voiding an invoice is called
canceling an invoice in code.

So, canceling (voiding) an invoice is fine, but my preference would be
to keep the restriction that paid invoices can not be canceled or
voided. Voiding paid invoices in mom-and-pop businesses might be fine,
but it won't fly in large enterprises.

-Adrian

Adrian Crum wrote:

> 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 [hidden email] (303) 493-6723
>> ----- Original Message -----
>> From: "Adrian Crum" <[hidden email]>
>> To: [hidden email]
>> 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

Re: svn commit: r792188 - in /ofbiz/trunk/applications/accounting: data/AccountingTypeData.xml widget/Menus.xml

In reply to this post by Adrian Crum

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, [hidden email] 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"/>
>>>>>>>
>>>>>>> 
>>>>>>> <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.

Vince Clark

Re: svn commit: r792188 - in /ofbiz/trunk/applications/accounting: data/AccountingTypeData.xml widget/Menus.xml

In reply to this post by Adrian Crum

I agree, some companies may not want to allow voiding of paid invoices. But I think something like that should be optional, more like a business rule that can be configured.

Vince Clark
[hidden email]
(303) 493-6723

----- Original Message -----
From: "Adrian Crum" <[hidden email]>
To: [hidden email]
Sent: Thursday, July 9, 2009 1:36:51 PM GMT -07:00 US/Canada Mountain
Subject: Re: svn commit: r792188 - in /ofbiz/trunk/applications/accounting: data/AccountingTypeData.xml widget/Menus.xml

Looking back through the commit and re-reading Jacopo's comments, I
believe Vince is correct about semantics: voiding an invoice is called
canceling an invoice in code.

So, canceling (voiding) an invoice is fine, but my preference would be
to keep the restriction that paid invoices can not be canceled or
voided. Voiding paid invoices in mom-and-pop businesses might be fine,
but it won't fly in large enterprises.

-Adrian

Adrian Crum wrote:

Vince Clark

Re: svn commit: r792188 - in /ofbiz/trunk/applications/accounting: data/AccountingTypeData.xml widget/Menus.xml

In reply to this post by BJ Freeman

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
[hidden email]
(303) 493-6723

----- Original Message -----
From: "BJ Freeman" <[hidden email]>
To: [hidden email]
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:

--
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.

Adrian Crum

Re: svn commit: r792188 - in /ofbiz/trunk/applications/accounting: data/AccountingTypeData.xml widget/Menus.xml

In reply to this post by Vince Clark

It can be easily configured by including/excluding the appropriate
StatusValidChange record.

-Adrian

Vince Clark wrote:

> I agree, some companies may not want to allow voiding of paid invoices. But I think something like that should be optional, more like a business rule that can be configured.
>
>
> Vince Clark
> [hidden email]
> (303) 493-6723
>
> ----- Original Message -----
> From: "Adrian Crum" <[hidden email]>
> To: [hidden email]
> Sent: Thursday, July 9, 2009 1:36:51 PM GMT -07:00 US/Canada Mountain
> Subject: Re: svn commit: r792188 - in /ofbiz/trunk/applications/accounting: data/AccountingTypeData.xml widget/Menus.xml
>
> Looking back through the commit and re-reading Jacopo's comments, I
> believe Vince is correct about semantics: voiding an invoice is called
> canceling an invoice in code.
>
> So, canceling (voiding) an invoice is fine, but my preference would be
> to keep the restriction that paid invoices can not be canceled or
> voided. Voiding paid invoices in mom-and-pop businesses might be fine,
> but it won't fly in large enterprises.
>
> -Adrian
>
>
> Adrian Crum wrote:
>> 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 [hidden email] (303) 493-6723
>>> ----- Original Message -----
>>> From: "Adrian Crum" <[hidden email]>
>>> To: [hidden email]
>>> 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
>>>
>>>
>