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
