"Posting No." and sales posting

ma

Hi everybody,

When sales order posting happens and an error occurs, posting will be rolled back but "Posting No." and "Shipment No." in the Sales Header are filled with numbers. Customer doesn't want these fields to be filled (every time NAV should look up a new number, but not keep posting numbers in the docu header).

Do you think if it's really tricky to move "Posting No." and "Shipment No." numbers assignment in CU 80 after all COMMIT in the OnRun() trigger? This means physically these numbers will be saved only after COMMIT in the end of the OnRun() trigger.

We've tested, general posting seems to work in correct way, but I just wonder if there are any places in the whole posting procedure, where they call SalesHeader.GET() with which they receive SalesHeader with blank "Posting No." and "Shipment No.". Do you think it can cause problems somewhere?

Thx.

Alex_Chow

No, that's fine. The only thing I would keep an eye on is if there are skipping of posted invoice and shipment numbers. But depending on the country you're from, it's nothing earthshattering.

kine

There is just one side-effect > the nos. series table will be locked for much longer time and it can have effect to all other processes, mainly on proesses using the nos. series which are right before and after the nos. serie.

ma

Well, let's consider SQL Server option variant:
we're posting Sales Order (50 lines), it can take e.g. 10 seconds. Concurrently (on the 3rd second of our posting) another user starts posting another Sales Order. What will happen to it?
As I see they fisrt use NoSeriesLine.LOCKTABLE and afterwards NoSeriesLine.FINDFIRST. So second user seem to receive an error because the Nr. Series Line table is already blocked? Am I right?
Just need to understand this to avoid numbers skipping or using the same number situation.
Thx.

P.S. NAV 5.0, Italian localization

kine

Yes, it will be blocked and if the posting will not end before timout, the user get error about timeout...

But it is problem that it can be another scenario:

You have no. series named "SALESINVOICE". You have another series with name "SALESORDER" which is right before the "SALESINVOICE". If user 1 start posting, and user 2 hit F3 and will want to create new Sales Order, he can end on the lock timeout error too... because both NoSeriesLine are locked (actual, previous and next one). It means that the locking problems can be much wider than just posting...

ma

kine, Alex, thank you.
Really for some reasons I decided that the records before and after are to be locked only when we use NEXT when going within the recordset.

But, according AppDesGuide:

However, the locking implementation used in SQL Server means that the record before and the record after this record set are also locked.

which works with FINDFIRST as well.

For now need to think if it really worth - let leave Posting No. blank, but casue that much possible locks.