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
