My AP clerks are running into a problem with duplicate document numbers. Seems that Navision assigns the document number as they open a document to enter. The problem occurs when both open a new document, and they end up with the same document number. They only discover this when they post, when the 2nd one gets rejected due to a duplicate document number. Does anyone with more than 1 AP clerk have a method that they use to avoid this problem. thanks Gary
Hi Gary, If you are talking in terms of PAyment Journal, then Use unique No. Series for each batch. That way, System will create a new Document No. per line, based on the No. Series. Naveen Jain
It is in the invoice entry > Purchasing & Payables > Invoices In the top left corner of the window is the field labeled “No”, which is prepopulated by the system. From the AP clerks, this field appears on reports as “Internal Invoice Number.” thanks Gary
- Are you sure that both users are pressing F3 or pushing the Insert button when they want to create a new Invoice? 2) Has the Purchase Invoice Form been modified by your company or your MBS-Partner?
When they input an invoice, they then click on [>] (next button), then hit [Enter], then the new internal invoice number is displayed. Is this an incorrect procedure that they are following? I don’t know if the form has been modified by our vendor. Gary
Hi Gary, The problem is not very clear. 1. The Purchase Invoices cannot have 2 documents for the same Number. As soon as the one of the users try to modify. They would get a message saying another user has modified. 2. The primary key do not allow 2 invoices with the same number. 3. Which version are you using? 4. What is the Internal Invoice Number?
When posting the invoice there is a check to ensure the Invoice No. is not already used in the Customer Ledger Entries. Perhaps your problem occurs because someone manually posted an invoice with the same invoice no. ?
Tell us a little more: - The error only occurs when a user tries to post an invoice, correct? - If that user tries to post the same invoice imediately after getting the error message, will it then be successful? - Can you tell us the exact error message, please?
Normally I set up the invoice numbers and the posted invoice numbers to use the same number sequence (an inland revenue thing) I have seen this error message before, but only after I hacked around with dataporting into the table
Thanks for the response guys. The duplicate number occurs up-front. When the clerk hits the [>] (next key) then [Enter] she gets a blank invoice screen to enter the invoice. If the other clerk does same, it is at this point that there is a duplicate (internal invoice) number condition. It appears to me, that Navision is taking the next available number and assigning it. But it is not tracking the numbers that are assigned but not yet entered into the system. So the next available number is not incremented until an invoice is entered. What actually gets into Navision is whichever clerk finishes first. The entry from the 2nd clerk gets rejected because of a duplicate (internal invoice) number. At this point the 2nd clerk has to reenter the invoice from the beginning. What gets them upset is if the invoice is LONG, then the reentry could take a significant amount of time. Right now, the workaround for a LONG invoice is, the clerk tells the other clerk to not enter any invoices until she has finished. If Navision could either track the document numbers assigned but not yet entered and not reassign these numbers, or assign document numbers in blocks. For example blocks of 10 numbers tied to each user. So a user would then have a sequence of number available that the other users won’t use. The problem with blocks is that there could be the problem of possble gaps in the number sequence if the entire block is not used. I will ask the clerk for the exact error message she gets. We are running 3.10a executables w a 2.6 database. We plan to upgrade in late Oct/early Nov. thanks Gary
The correct procedure for creating a new Invoice is to open the invoices form and either: - Press F3; - On the toolbar, click the Insert button; - From the Edit menu, select the Insert item. Any of these actions will cause the Invoice form to clear all previous informations and set focus on the “No.” field (the one you call “Internal Invoice No.”, I believe). As soon as the user moves out of the “No.” field, a new Invoice will be inserted and a new “No.” will be assigned from the corresponding No. Series. If both users follow these instructions, then they will never get an error message like the one you describe - but it would still be nice if you could tell us exactly what the message is. Of course, this is the standard, out-of-the-box, application behaviour. If the Invoice entry process has been somehow customized by you NSC, there is the chance for something to have been wrongly modified. Take particular notice on when the “No.” field gets filled in. If it is as soon as the user moves out of it, then the problem needs to be better checked. If it is after that stage or even only when the invoice is completely filled in, then your NSC has activated the property DelayedInsert of the Purchase Invoice form and you must ask them to revert this change. Check with them why they did it, because there can be an important reason.
thanks Nelson One of the clerks is out the rest of the week. I’ll have them try this on Monday. thanks much Gary
Maybe you can get them both to take alternated holidays each week, completely avoiding the problem? [:D][:p] Just kidding, post back next week! [;)]
Oh it will get worse. They want to hire a 3rd clerk.
Hi Gary I agree with Nelson in that your clerks should be using the insert function (F3, Insert Button on the tool bar or Insert from the Menu) to create new invoices. By selecting the next record (>) button they are merely moving to the next record (which probably has just been created by the other clerk)and will appear with the number and no detail if the other clerk hasn’t entered details. So when they finish the invoice a message that the record has been modified by another user will appear and changes will be lost. Good luck with the 3rd clerk… Cheers Peter
Here is the error message they get: Another user has modified the record for the purchase header after you retrieved it from the database. Enter your changes again in the update window, or start the interrupted activity again. Ident field + values Doc type=“Invoice” No.=“38420” I had them try the “INSERT” procedure, and it seems to be doing what we want, incrementing to a new number that does not conflict with the other clerk. [:)] They will be try out the new procedure today. They just have to “unlearn” what they had been taught before. Thanks much everyone. Gary
Just noticed I never told you the reason for this behaviour, only how to fix it. [|)] But I think Peter correctly explained why this was happening.
I have a client that this happens to as well. They never have any open invoices, so they always create and post. What will happen to them is this. One will create and post and then the system will produce a blank form (no other invoices). However since the other AP clerk is entering invoices as well a number will appear on the blank form (which is the number that the other AP clerk is currently working on). My client has a bad habit of seeing the number and thinking wow I already have a number - now I just need to enter the data. Then it is a race to see who gets done first. I couldn’t get that information out of the client when talking to them. I actually had to watch them do it several times to catch on to their little ‘trick’. I have since pounded the idea of the F3 key in their heads and the problem has disappeared. Hope that makes since… Really it just confirms what has already been said.
Doug That is the same way I have to work. I have to WATCH the user. What they do is usually different than what they say or is in the procedures. Just like what you mentioned, I have to watch out for the “shortcuts” that they managed to figure out. Gary
Maybe those users can run for “http://www.mbsonline.org/forum/topic.asp?TOPIC_ID=11208” [:p]