Meaning of PartyAcctgPreferences.useInvoiceIdForReturns

[Jacopo Cappellato-3]

While cleaning up some code related to returns, I've noticed the  
PartyAcctgPreferences.useInvoiceIdForReturns flag: if set to Y then  
the returnId is generated using the id sequence of the invoices.
Does this make sense? My guess is that this code is there as an hack  
to use the return as a "credit invoice"... however in my opinion we  
should get rid of this because it seems more suited for a  
customization and not worth of a flag/field in the data model.
I'd suggest to:
1) remove the PartyAcctgPreferences.useInvoiceIdForReturns field
2) remove the code that uses it (in the createReturnHeader service)

There is already some code that creates a real invoice from a return  
and, even if it needs to be enhanced, this is really the way to go:  
with a real invoice we can use and apply payments etc...

What do you think?

Jacopo

[David E Jones]

This came from a requirement where a certain country (I don't remember  
which...) requires strict sequencing and even registry with the govt  
of invoices. Skipping an invoice number was considered an audit  
trigger and a possible means for committing fraud (or tax evasion, or  
something).

Because returns have a financial impact but no invoice they wanted to  
include returns in that sequence to strictly control them.

We may very well be able to remove this, I don't know. It was a bit of  
a hack, and if we are generating invoices from returns now then it  
probably isn't necessary.

Is anyone reading this email actually using this anymore?

-David


On Jul 1, 2008, at 7:44 AM, Jacopo Cappellato wrote:

> While cleaning up some code related to returns, I've noticed the  
> PartyAcctgPreferences.useInvoiceIdForReturns flag: if set to Y then  
> the returnId is generated using the id sequence of the invoices.
> Does this make sense? My guess is that this code is there as an hack  
> to use the return as a "credit invoice"... however in my opinion we  
> should get rid of this because it seems more suited for a  
> customization and not worth of a flag/field in the data model.
> I'd suggest to:
> 1) remove the PartyAcctgPreferences.useInvoiceIdForReturns field
> 2) remove the code that uses it (in the createReturnHeader service)
>
> There is already some code that creates a real invoice from a return  
> and, even if it needs to be enhanced, this is really the way to go:  
> with a real invoice we can use and apply payments etc...
>
> What do you think?
>
> Jacopo
>
>

[Jacopo Cappellato-3]

David,

thanks for your comment, that makes a lot of sense to me because Italy  
is a country in which a strict sequencing of invoices is required as  
well.
However, as you mention, the sequence should be that of the invoice  
associated to the return (that in Italy is named "nota di  
credito"/"credit note"), instead of the returnId.
By the way it is not a big issue and we can postpone the decision.

Jacopo

On Jul 1, 2008, at 9:47 PM, David E Jones wrote:

>
> This came from a requirement where a certain country (I don't  
> remember which...) requires strict sequencing and even registry with  
> the govt of invoices. Skipping an invoice number was considered an  
> audit trigger and a possible means for committing fraud (or tax  
> evasion, or something).
>
> Because returns have a financial impact but no invoice they wanted  
> to include returns in that sequence to strictly control them.
>
> We may very well be able to remove this, I don't know. It was a bit  
> of a hack, and if we are generating invoices from returns now then  
> it probably isn't necessary.
>
> Is anyone reading this email actually using this anymore?
>
> -David
>
>
> On Jul 1, 2008, at 7:44 AM, Jacopo Cappellato wrote:
>
>> While cleaning up some code related to returns, I've noticed the  
>> PartyAcctgPreferences.useInvoiceIdForReturns flag: if set to Y then  
>> the returnId is generated using the id sequence of the invoices.
>> Does this make sense? My guess is that this code is there as an  
>> hack to use the return as a "credit invoice"... however in my  
>> opinion we should get rid of this because it seems more suited for  
>> a customization and not worth of a flag/field in the data model.
>> I'd suggest to:
>> 1) remove the PartyAcctgPreferences.useInvoiceIdForReturns field
>> 2) remove the code that uses it (in the createReturnHeader service)
>>
>> There is already some code that creates a real invoice from a  
>> return and, even if it needs to be enhanced, this is really the way  
>> to go: with a real invoice we can use and apply payments etc...
>>
>> What do you think?
>>
>> Jacopo
>>
>>
>