Item charge assignment

I was given to understand that upon running a periodic activity, any item charge assignment done during, later after purchase or sale of the main item, the costs will go to G/L.

For eg. , I receipted a vehicle into the system - 12th Dec 2008

I did an item charge on the receipted vehicle on 14th Dec 2008

I did the invoice for the vehicle on 15th Dec 2008.

I sold the vehicle on 18th Dec 2008.

I did another item charge on the receipted vehicel on 21st Dec 2008.

After running the periodic activity, I find that the 2nd item charge is still stuck in inventory and not moved to G/L COGS.

Any help. I was given to understand that for any item charge on a receipt item done at any time, if the system finds it is sold, it automatically sends it to COGS rather than keeping in the inventory. Now I find a huge fictitious asset (as these are expenses) sitting in my inventory. Any solution.


Did you run BOTH batch jobs - “Adjust costs” and “post to GL” ?

Can you please check the value entries of the sale of the vehicle?
You should find the additional costs there.

Yes, both were done. In fact, it is on a daily (night time) periodic activity scheduled to run automatically. The problem comes when the vehicle is sold and then the item charge assignement is done. The system is not able to check that the vehicle is sold and push it to COGS. We have Navvision 3.1 and Incadea 3.7.


Is the vehicle an item or a fixed asset?

3.1 is the first release of item charges??? there will have been a lot of changes since then, can you contact your partner and see? Is there any impact from Incadea?

It is an inventory item. The support is scratchy. We have not been able to find an expert on both incadea/navvision together who can put the mind on many of our issues.

It is not a version I have access to, or a configuration with Incadea, so you will either need someone here with the same setup, which is unlikely, or you will have to go through your partner.

My guess is that it is an issue resolved, assuming it is not a setup issue, but I would put the responsibility for this on my partner as i am paying for support! Lets face it, it does not take long to test it, test it in standard and then search the MS database for known issues. Not sure if 3.1 is supported by MS anymore, but that does not stop you searching for known issues.

We checked with one of our support partners. We found if it is done manually, it works. But if it is put on auto it does not work.

But there is another problem. The system goes and assigns the cost to G/L on the date of vehicle sold. Thus if I had sold a vehicle in 2006 or 2007 and do a posting date of today, the system asks the old period to be opened and then posts it in 2006 or 2007. This is unacceptable as the integrity of accounts is lost. We close every year and a balancesheet/P&L is prepared everyyear which is audited and filed. Now if the system goes and makes the changes to earlier period, then integrity of our accounts is at stake. It should post to G/L on the posting date. The support is still working on this.


Yes I believe they resolved that issue in version 4 from memory, but it was a long time ago, I believe the costs now get posted to the period of the original transaction if the financial period is open, but to the posting date if it is closed.


It works fine with Nav Version 4.0 & 5.0. Any Item Charges assigned later will always fall in the current month if the "Allow Posting From & Allow Posting To are locked for posting to backwards as what Adam Roue also mentioned. If it is asking to open and post backwards then this is not correct!!

If a Purchase Item Charge is assigned after the Items are completely sold, then it should (Cr Inventory & Dr COGS) there by making the Inventory Value to Zero and expensing it out, thus making the COGS Correct. This works fine with Version 4.0 & 5.0, I quite don’t remember in Nav 3.0 Version. Not sure, why this isn’t working in your version. Your Partners should give you a solution…


So what is their answer - have they solved the problem?

Please share with fellow forum members - maybe someone else is still using 3.xx version - as stated in some above posts, versions from 4 up don’t suffer from this problem.

We did find another partner, who has since resolved it. Like Bluesky mentioned it is working like that.

Thanks for all your time and effort in understanding and suggesting the solutions (as we could convince the new partner that this solution was there)