I would think that using a link list of some sort would address most of
the issues.
the SequenceValueItem entity could had last and next added however you
would need a separate entity for each document that needs sequencing.
you could add last next to each entity, like
PartyAcctgPreference.lastInvoiceNumber and
PartyAcctgPreference.thisInvoiceNumber
PartyAcctgPreference.NextInvoiceNumber
this would allow the services to implement different numbering systems
so you would have a
PartyAcctgPreference.InvoiceNumberSequenceSystem flag
and to speed up the process
you could convert the
SequenceValueItem to add fields for all the different entities that
would have the last Invoice Number like
PartyAcctgPreference would be a field in SequenceValueItem
Jacopo Cappellato sent the following on 7/11/2008 7:07 AM:
> Hi all,
>
> Based on the feedback I got from various Italian customers/contacts it
> seems that enhancing the way invoice sequence ids are managed is one of
> the most desired features.
> The main requirements can be summarized with:
> * strictly sequential invoice ids (no gaps): this is required (or just
> common practice) in some countries, including Italy
> * the ability to reset the invoice id (i.e. "starting again from 1")
> when a new financial period starts; this is typically done at the
> beginning of the year in Italy
> * the ability to define more than one sequences; for example: one for
> invoices for UE customers, one for invoices for extra UE customers etc...
>
> I know there is already some support for this stuff in the existing
> codebase, but I think there are still issues (some technical and some
> functional) and so there is room for enhancements to the existing code.
>
> In its current implementation the system allows you to maintain the
> following sequences:
>
> A) "Standard (faster, may have gaps, per system)"
> B) "Enforced Sequence (no gaps, per organization)"
> C) "Restart on Fiscal Year (no gaps, per org, reset to 1 each year)"
>
> Technical issue (after a review of the "getNextInvoiceId" service):
> method A is implemented in the right way, i.e. using the
> SequenceValueItem and related service; on the other hand method B and C
> don't use the SequenceValueItem entity/service and instead handle the
> sequence generation using the getNextInvoiceId service and the field
> PartyAcctgPreference.lastInvoiceNumber: this is an issue because these
> methods are not thread safe and there is no reason to not use the
> SequenceValueItem stuff for them too; for example we could maintain in
> the SequenceValueItem entity one sequence for each of the divisions or
> methods that we need ("Invoice_Company", "Invoice_SubDivisionA" etc...)
> and then just call the sequenced-id-to-env passing the right sequence
> name and stagger-max="1" (to avoid gaps). And we could easily implement
> the "Restart on Fiscal Year" method by resetting the proper sequence in
> the SequenceValueItem entity (and this could be done by the service that
> closes a Financial time period).
>
> However also this method will not guarantee a strictly sequential id
> series: for example, if an error happens during the invoice generation,
> everything is rolled back, but not the id in the SequenceValueItem,
> because it is committed in a separate transaction... hmmmm... any ideas
> on how to resolve this issue?
>
> Functional issue:
> the same division may have to maintain more than one sequence for
> invoices; I still don't have all the requirements/details about the way
> the right sequence is used (by customer classification? by billing
> address? by product store? by sales channel?) and I would like to get
> some requirements by you? Do you have similar needs? Speak up!
>
> After that we have better defined all the requirements we can draft a plan.
>
> Cheers,
>
> Jacopo
>
