correcting posted sales invoice document

I also have problem with purchase invoice that has been posted.
I find that the item’s cost is empty but mistyped in price, but the invoice
has posted, could I correct the error in t he document…? I know I can correct using general journal that is directly reposting to G/L but I just want the document is reposted with the same document
number but can be posted to the same G/L without replacing the
value that has been posted beforehand.
Could you pls let me know the solution for this…?

Any help from you are appreciated. tku



Are you referring to the “Unit Cost (LCY)” field on the posted invoice lines (table 113)? If so this is pulled from the Item or SKU card Unit Cost field when the sales line is created and will post to the Cost Amount field in the item ledger, but will be adjusted when the “Adjust Cost” batch job is executed.

Why are you in need of updating the “Unit Cost (LCY)” on the Item Ledger? I am thinking it might be because of sales reporting issues, note that you should not base reports on the invoice and credit memo line tables, you should always base these kinds of reports on the ledger tables (Item Ledger, etc.).

I hope this helps.

You are correct. It surely pulled from item or SKU, but because cost is fluctuative, it is empty there and directly write in the sales invoice. I want to correct the posted sales invoice and reposting with the same invoice no. but not delete the first value entry that posted beforehand. Is it possible to correct the posted sales invoice document especially purchase item cost value…? I will not correct the G/L using general journal or create new invoice but copy document from the posted invoice and make the invoice no. as same as posted invoice.




The system will adjust the cost of goods sold autmoatically when you run the Adjust Cost and Post Inventory Cost to G/L batch routines.

Why do you need to correct the Unit Cost on the posted invoice line? There should not be a need for doing that, or?

Okay lets try and clear this up. [:D]

You booked in a receipt with the wrong cost, complicated it by processing the invoice through also incrrectly (to the invoice). What you really need to do is credit the purchase invoice and start again, but you have already sold the item so cannot? Then I recommend you revalue the COGS using the revaluation journal and manually adjust the creditors position with a dummy invoice to the GL.

Of course Andreas your problem has changed as you have posted, so it probably has again - can you be clear in your issue please if possible.

Hi Bruno,

I know that. The costing is FIFO, this problem also happened in posted purchase invoiced. they have posted the invoice but one of the item in the line is wrong unit cost, so they posted item with wrong unit cost, how to corrected it and how to prevent that they will not post wrong again?



Dear Steven,

I agree I can use revaluation journal and adjust the creditor position with a dummy invocie to G/L, but we want the posted purchase invoice or sales invoice document can be edit and reposted, but the first posted value will not erase, and also how to avoid wrong posting of the purchase invoice and or sales invoice, do I must use post batch…? what will be the post batch used for…?

I just can do colouring the column so that the admin staff can’t do wrong posting and remind her that the column is important, also I just improve the SOP so that the invoice can’t be posted without printed first, give to finance or purchase manager, assigned and then posted if the items ordered received. Do you know other solution for the problem…?


Essentially do not edit posted entries, you have the potential to corrupt the database and break numerous laws. I believe you have been told this in other postings. You cannot and should not edit and repost a posted document. Batch posting is irrelevant.

You cannot get the system to check for a “wrong” posting - how will it ever know. Your procedures that are backed up by Navision should resolve this - do you not press F9 andf validate the value before posting? If not how do you check your physical copy matches your system one?

As for other solutions - I would recommend getting some financial control on your processes irrelevant to the system being used.

Andreas, there is a simple and straight forward solution to this, and it does not even need programming. We int he Navision world call it training. [;)] (sorry but what were you expecting [:P] )

You must train users to do their job, and if they keep messing up, then they will keep fixing up. If you give them a tool that alows them to simply indo mistakes, then they will just mak more an more mistakes everyday. But if they need to fix the mistake manually, then they will very quickly learn not to make the same mistake again. Let me give you a simple analogy.

Hi Bruno,

Referring to what you said “note that you should not base reports on the invoice and credit memo line tables, you should always base these kinds of reports on the ledger tables (Item Ledger, etc.).” I would like to point out a situation where this is required (just to share my experience). Although this has to do with Unit Price / Amount rather than Unit Cost, the point I want to make is the same.

I am currently working on a custom Sales Analysis matrix report for our sales dept. I have to combine Outstanding Amount in Sales Order and Amount Invoiced in a Sales Invoice rather than get it from ledger entries since ledgers only record posted entries (after shipping).

Our sales orders usually remain on the system for at least 2 months before we start shipping (or posting). We recently shipped our first drop out of 4 for the entire season. The Sales Manager now needs to know the dollar and unit sales for the entire season, which would include orders that have not been shipped as well as those that have already been shipped or partially shipped. Of course we could run a report by scanning all sales orders BEFORE we fill the first order or run a report AFTER all orders have been filled and shipped at the end of season. The interim is what’s giving me the challenge.


Hi Scott,

Brunno is actually quite correct, you really never should run any type of statistical reports based on Posted Document tables. (Of course there are exceptions, but you really should try to do it a different way). Although there are a number of reasons behind this, the two most important ones are that the Posted Documetns are not important in Navision, and can be simply deleted at any time. But more importantly is the indexing. Posted documents have complex primary keys, and primary keys are appended to all secondary keys, so basically reporting on these posted Document Line tables is going to in general slow down the system. Of course back when we were taught all this, its was with 486 servers, 10meg networks with hubs, and 286 DOS clients, so of course the old “get a bigger hammer” principle applies these days.

But anyway as a matter of practice, try to use ledger lines to get your core data, and if necessary link to the Posted Documents using their primary key (Document No), and all should be fine. In your case about, then the Shiped not invoice data shoudl really be coming form the Sales Line tables, not from the Posted Documents tables.

Hi Steve,

I am actually having the same problem with a few ledger entries—incorrect Unit Cost (because the person who maintains the Item table forgot to enter a Unit Cost of a few items). However, when I tried what you suggested—using Revaluation Journal—Navision doesn’t allow me to enter Unit Cost (Revalued) when the Quantity is zero. In other words if the inventory of an Item becomes zero after shipping, then I would not be able to adjust the Item Unit Cost retropsectively. Is it really the case?


Which costing method are you using?

Unfortnately the Revaluation jourrnal seems to add a number of limitations to what you can and can’t revalue. For example, you can use Charge Items to revalue items that you can’t revalue using the revaluation journal, this seems odd, and I suspect that it was done back in th eearly Value Entry Days, (3.01 and 3.10) when there were serious costing problems, and these limitations were probably added to prevent other problems.

I was called in to repair a rather disasterous 2.60->3.01 upgrade, and found the Revaluation journal of no use at all, so had to bascially re-write my own version to fix the costing in the database. In fact that was pretty easy to do, I just pulled finctionality from the Charge Items posting,

Keep in mind that the way the systme works, once a new Vlaue entry is in place, the Adjust Inventory cost and Post to GL routines will fix everythign up magically.

Are you revaluing by defining the entry or by running the batch routine function?

I cannot remember the definitive differences but by manually doing it I believe it posts the revaluation back affecting the accounts, whereas the batch routine is restricted to what it allows you to revalue. Sorry do not have Navision in front of me, but if you are doing it one way does it make any difference doing it the other? [:D]

Actually Steven this is the sort of peculiarities that I don’t get. As you say the final out come is the same, and in all cases, revaluation is really just a case of inserting a new Value entry, so why are there restrictions on doing things one way, and not another. Wierd huh [*-)]

Hi David,

Thanks for shedding some light on this problem. As for your suggestion: In your case about, then the Shiped not invoice data shoudl really be coming form the Sales Line tables, not from the Posted Documents tables, I have this question. What if some orders have been completely shipped? I would no longer be able to access the Shipped Not Invoiced field because these Sales Orders would have been deleted automatically. Then I would have to refer to either the Item Ledger Entry or Sales Shipment Line to get the same info anyway. My challenge here is reporting sales during the interim. If the Sales Manager had asked me for such a report BEFORE we began processing the first order for the season, I would only need to look into the Sales Line. Or AFTER we shipped all the orders for the entire season, then I would only need to look into Item Ledger Entry or Sales Shipment Line.

You are right that there is some performance issue as it will take around 2 or more minutes for me to create analysis entries for each analysis view.


The order is only deleted once the items have been invoiced, and then you would get the data from the Customer ledger entries. If the goods a fuly shipped, but not invoiced, then that is exactly what Shipped not invoiced is all about.

[:D] you are very funny David. I think it is too brutal but it should not exist repeat mistaken. Actually there is no change can be made if the sales or purchase invoice has been posted. I thought beforehand, I can revise or edit the posted purchase invoice in the history of purchase module. It can be delete but the data still exists in G/L. tku