Hi, everyone! My client is currently using Citrix server to run NF2.60, and encountering number series update issue with the purchase invoices/receipts, when multiple users are making entries. According to the client’s comments: The document numbers are not always updated for purchase receipts and purchase invoices when the documents are created, resulting in errors when Navision tries to assign a number that has already been used for each document. Anyway, I have discussed this matter with few other very experience developers here at work, and the only solution so far is: Tell the client that when this situation happens, verifies that the number that the system cannot assign does exist. Afterwards, go to the Purchase Invoice Heaader table and change the number. I told the client about this solution, and he does not accept it. Does anyone of you have another practical solution to this problem? Please let me know. Thanks in advance.
Originally posted by yummi
… The document numbers are not always updated for purchase receipts and purchase invoices when the documents are created, resulting in errors when Navision tries to assign a number that has already been used for each document. …
The question is: Why aren’t the numbers not always updated?
Originally posted by yummi
… Anyway, I have discussed this matter with few other very experience developers here at work, and the only solution so far is: Tell the client that when this situation happens, verifies that the number that the system cannot assign does exist. Afterwards, go to the Purchase Invoice Heaader table and change the number. I told the client about this solution, and he does not accept it. …
We are End - User and we wouldn’t accept this too. [;)] This would be a workaround and not the solution of the problem. Furthermore - to change a primary key (number) isn’t always a proper way. My suggestion is: try to find the error. bye Andre
Have you tried to search this forum for revelant topics? A simple search returned a thread which gave some further thoughts on this issue.
Hi, Andre! Okay, the problem does come with an error message (I forgot to mention that). It is: “The Purchase Invoice 12345 has already existed.” I have to make a correction here about the solution my colleages gave me: Instead of going into the Purchase Header table to change the primary key (the No. field), the users will have to go to the Document No. table (it is a customized table where the no. series are being obtained based on each user’s location) to change the No. to a new value in order to overwrite the error message. I looked through the codes on the OnInsert trigger of the table as follows: OnInsert() PurchSetup.GET; IF “No.” = ‘’ THEN BEGIN //NFS1.0 UserLoc.GET(USERID); DocNo.LOCKTABLE(TRUE,TRUE); TestNoSeries; NoSeriesMgt.InitSeries(GetNoSeriesCode,xRec.“No. Series”,“Posting Date”,“No.”,“No. Series”); END; //NFS1.0 DocNo.TESTFIELD(DocNo.“Last Document No.”); DocNo.“Last Document No.” := INCSTR(DocNo.“Last Document No.”); “No.” := DocNo.“Last Document No.”; DocNo.MODIFY; InitRecord; IF GETFILTER(“Buy-from Vendor No.”) <> ‘’ THEN IF GETRANGEMIN(“Buy-from Vendor No.”) = GETRANGEMAX(“Buy-from Vendor No.”) THEN VALIDATE(“Buy-from Vendor No.”,GETRANGEMIN(“Buy-from Vendor No.”)); I really don’t understand this, if the locktable function has been used in this situation, why doesn’t it help out when comes to multiple users entering orders/invoices? What is the deal? Thanks.
This was a known problem in V 2.XX. In heavy use environments, there was some type of latency that created a “hole” allowing two people to get the same number from the number series. We haven’t encountered it in 3.XX.
This problem occurs ramdomly in every auto-incrementing number series in Navision 2.01, 2.10 and 2.60 (Sales Order, Purchase Order, Sales Invoice, Purchase Invoice, Pick Slips …) - I can’t vouch for 3.xx (Attain) as we have not migrated. As to heavy environments - we have at most 2 users entering any particular document type (eg. Sales Order) at any given time on a system with at most 6 active users so I am less than convinced on this one. I am convinced that it is based in some sort of race condition. If I had to guess I would start by looking at ‘dirty read’ type problems in server cache and commit cache. We currently use Navision 2.60E (Australian customisation) with C/Side database on an NT4.0 server.
Hi all Peter and Allen credited. I had some of these problems (the number series table not being correcty updated), but after updating server and client exe’s to 3.60 the problem has vanishsed. (Objects are still the old 2.01B, so the improvement is not in the object code.) Pelle
Hi folks, I am kind of bummed out about the no. series update issue. If this is a known problem in v2.X, how come no one in Navision cares to fix the problem? I have been looking around the Navison partner site, and couldn’t find any associated help document on it. I hope someone would fix it soon, as not all the clients out there can afford to upgrade to v3.X. As for my situation, my boss made some corrections on the sequence of the code. He said by doing that would fix the problem. Nevertheless, our client still hasn’t got back to us. We will have to wait and see what is going on.
I assume Pelle means client version 2.60 not 3.60 ? I can conform it is still a problem at release 2.60E as it happened again yesterday and at that time there was only 1 (yes one) active user - it was lunch time ! We use both local Navision Client and Citrix and it happens on both.