My NAV has created two invoices to two different customers, however these invoices has the same invoice number! One is already posted but the other one failed because the number has already been posted. How do I sort this out?
The not booked invoice holds (table 36) a field 65 Last Posting No., to reserve the next invoice.
If you blank this field, the invoice will post with a new number.
IF User.Loves('Edo') THEN ok() ELSE currReport.genSkip;
If you want to post both invoices, you need to clear the field in the order/not booked invoice (table 36, field 65). As this field is not on the screen, you might want to do that, as a developer, by running table 36, and blank it from there.
If you run into this issue over and over again (like I once had), you can also change COD80 to not re-use the previous invoice number, if it already exists as a posted invoice (in table 112).
IF User.Loves('Edo') THEN ok() ELSE currReport.genSkip;
If the posted invoices are really old, you can also print them (if they're not printed yet), and delete them. Most companies keep posted invoices for audit reasons, but after 5 or 10 years you can delete them, or store the hardcopy in a folder.
Maybe you want to revise the number series for posted invoices also. A brand new range might solve your issue for future invoices.
This is how NAV generates a number, when posting an invoice:
* in COD80, it will first check the field Last Posting No. in the order/invoice (TAB36). If it is blank, it will get a new number from the nr.series, and store it in this field, and commit this to the database, to avoid long term locking of the nr.-series table during the posting process.
* if this field is already filled, it will skip the process of getting a new number, it will use the value in this field for the posted invoice. In case the posted invoice already exists with this number, it will cause an error, like you encountered. With a clean process and well defined number series, you will theoretically never get an issue with this. Real life is always more troublesome, as you experienced.
What you just wrote, gives me the idea that you will get more invoices with these issues in the near future, as your number series clashes with old series used in the past. In that case: define a new nr.-series for posted invoices, and make sure that the field Last Posting No. on the orders/invoices in table 36 Sales Order is blank, so COD80-post invoice will take a new number for future orders/invoices to be posted.
IF User.Loves('Edo') THEN ok() ELSE currReport.genSkip;
The not booked invoice holds (table 36) a field 65 Last Posting No., to reserve the next invoice.
If you blank this field, the invoice will post with a new number.
IF User.Loves('Edo') THEN ok() ELSE currReport.genSkip;
Hello Edoderoo, thanks for your concern. I think it sounds well on reversing the invoice and reposting it for the new number. Could you please let me know on how to do this...? I am still learning the NAV environment...
If you want to post both invoices, you need to clear the field in the order/not booked invoice (table 36, field 65). As this field is not on the screen, you might want to do that, as a developer, by running table 36, and blank it from there.
If you run into this issue over and over again (like I once had), you can also change COD80 to not re-use the previous invoice number, if it already exists as a posted invoice (in table 112).
IF User.Loves('Edo') THEN ok() ELSE currReport.genSkip;
Hello Edoderoo, I have noticed that the invoices are very old and several invoices have already passed with the correct sequence of numbers from the erroneous ones. Do I need to go with the proposed solutions?
If the posted invoices are really old, you can also print them (if they're not printed yet), and delete them. Most companies keep posted invoices for audit reasons, but after 5 or 10 years you can delete them, or store the hardcopy in a folder.
Maybe you want to revise the number series for posted invoices also. A brand new range might solve your issue for future invoices.
This is how NAV generates a number, when posting an invoice:
* in COD80, it will first check the field Last Posting No. in the order/invoice (TAB36). If it is blank, it will get a new number from the nr.series, and store it in this field, and commit this to the database, to avoid long term locking of the nr.-series table during the posting process.
* if this field is already filled, it will skip the process of getting a new number, it will use the value in this field for the posted invoice. In case the posted invoice already exists with this number, it will cause an error, like you encountered. With a clean process and well defined number series, you will theoretically never get an issue with this. Real life is always more troublesome, as you experienced.
What you just wrote, gives me the idea that you will get more invoices with these issues in the near future, as your number series clashes with old series used in the past. In that case: define a new nr.-series for posted invoices, and make sure that the field Last Posting No. on the orders/invoices in table 36 Sales Order is blank, so COD80-post invoice will take a new number for future orders/invoices to be posted.
IF User.Loves('Edo') THEN ok() ELSE currReport.genSkip;
Hi Edoderoo, as you predicted in your earlier message we are now getting more of the problem in the mean time. I thought the issue was to do with the old invoices but now the problem is with new ones. More than one invoices are having repeated numbers.
I am trying to see if the above solution would resolve the situation mean while could you suggest how to sort the invoices with repeated numbers so that I may be able to post them?
In COD80, there is a piece of code to "reuse" the reserved invoice number. What I programmed before: add a check there, and get a new number if the reserved number is blank, *OR* if the reserved number does already exist as a posted invoice. You need to add a variable of type=REC 112, and check if you get do a checkPostedInvoice.GET("Last Posting No.").
Right now I have no developer license (changed job, will come again soon). Else I could lookup the exact place in the code. But if you search in COD80 for "Last Posting No." you will find the place.
IF User.Loves('Edo') THEN ok() ELSE currReport.genSkip;
Answers
If you blank this field, the invoice will post with a new number.
If you run into this issue over and over again (like I once had), you can also change COD80 to not re-use the previous invoice number, if it already exists as a posted invoice (in table 112).
Maybe you want to revise the number series for posted invoices also. A brand new range might solve your issue for future invoices.
This is how NAV generates a number, when posting an invoice:
* in COD80, it will first check the field Last Posting No. in the order/invoice (TAB36). If it is blank, it will get a new number from the nr.series, and store it in this field, and commit this to the database, to avoid long term locking of the nr.-series table during the posting process.
* if this field is already filled, it will skip the process of getting a new number, it will use the value in this field for the posted invoice. In case the posted invoice already exists with this number, it will cause an error, like you encountered. With a clean process and well defined number series, you will theoretically never get an issue with this. Real life is always more troublesome, as you experienced.
What you just wrote, gives me the idea that you will get more invoices with these issues in the near future, as your number series clashes with old series used in the past. In that case: define a new nr.-series for posted invoices, and make sure that the field Last Posting No. on the orders/invoices in table 36 Sales Order is blank, so COD80-post invoice will take a new number for future orders/invoices to be posted.
I am trying to see if the above solution would resolve the situation mean while could you suggest how to sort the invoices with repeated numbers so that I may be able to post them?
Right now I have no developer license (changed job, will come again soon). Else I could lookup the exact place in the code. But if you search in COD80 for "Last Posting No." you will find the place.