Problematic code

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Problematic code

SkipDever
There is some problematic code in InvoiceServices.xml

    <simple-method method-name="getNextInvoiceId" short-description="Get
Next invoiceId">

If type is INVSQ_ENF_SEQ (most jurisdictions require no-gap invoice
numbers), it is possible to not have the write complete.  I am not sure how
as this is a simple method and I have not taken the time to fully understand
it.

All I know is that I successfully got the PartyAcctgPreference record
written incorrectly, i.e. it did now write out the last lastInvoiceNumber
used.

I expect that this happened because a transaction got rolled back and the
call to getNextInvoiceId was not matched with the create invoice call and
they were not rolled back together.

Note that I have seen lots of exceptions as I am importing some bad customer
data.  However, it is my view that a robust bit of code should survive the
abuse without these failures.


I believe that this simple-method should be moved to a java routine
surrounded by a begin/commit (can it be done in simple-method?) and a second
routine should be written to decrement it in case of an exception before the
Invoice record is committed.

I am happy to deal with this at some point in the future when I get closer
to fully functional.  In the mean-time, I expect that others will want to be
aware of this because it causes users to experience a great big exception
message when trying to write an invoice and they have no idea what it means.

The fix is simple, use the Entity Data Maintenance tool and look at Invoice.
Note the last number.  Then edit PartyAcctgPreference and set
lastInvoiceNumber to the value noted above.

Skip

Reply | Threaded
Open this post in threaded view
|

Re: Problematic code

David E Jones


skip@theDevers wrote:
> I believe that this simple-method should be moved to a java routine
> surrounded by a begin/commit (can it be done in simple-method?) and a second
> routine should be written to decrement it in case of an exception before the
> Invoice record is committed.

This doesn't really have anything to do with the simple-method implementation, which is a fine way to go. It probably has to do with how the service definitions are setup and how the services are called. Chances are this is mistakenly setup to run in a different transaction than the rest of the invoice creation.

I can't really fit this in with other priorities right now, so if no one responds with a fix soon the best action is probably to file an issue in Jira and hopefully it will be fixed by the time you need it...

-David