Adjust Cost Item Entries hangs

dn · 2010-07-13

Hi
I have a big trouble and hope some expert can give me some tips.
In our system we had implemented a scheduled running of low level code job. Yesterday we found that automatic job have not need executed for three weeks. So we started it manual yesterday.
Today when we started Adjust Cost Item Entries job, we found that job seems hangs.
Is any who have a clue if missed of running The low level code batch job can cause to Adjust Cost Item Entries hang?
How can I take me forward?? The Adjust Cost Item Entries job must could running without stop. ](*,)

Andwian · 2010-07-14

What do you mean with hang? Is it stop or running but never stop?

dn · 2010-07-14

Andwian wrote:

What do you mean with hang? Is it stop or running but never stop?

I mean it never stop..It came to some transaction and keep executes but the status window did not updated

Andwian · 2010-07-14

Maybe you experienced the Loop ACIE, a known issue in NAV 5.
What version of NAV did you use?
Have you tried to search the KB article?

One thing I remember, this issue happened if we have a items that are output of the Production Order.

dn · 2010-07-14

Andwian wrote:

Maybe you experienced the Loop ACIE, a known issue in NAV 5.
What version of NAV did you use?
Have you tried to search the KB article?

One thing I remember, this issue happened if we have a items that are output of the Production Order.

Hi
We are running Nav 4 SP1 database with Nav 5 Client.

What did u mean with know issue? How to fix it?

Andwian · 2010-07-14

I mean that it was bug.

There are a few KB Articles that try to explain and fix that issue.

Anyway, did you have any Production Order that are posted already?
What is your resolution at this time?
Is is still running? And what could you do then?

dn · 2010-07-14

Andwian wrote:

I mean that it was bug.

There are a few KB Articles that try to explain and fix that issue.

Anyway, did you have any Production Order that are posted already?
What is your resolution at this time?
Is is still running? And what could you do then?

I have cancelled the job and hope found some advise before I make a new try.
I am not sure if any Production order have been finished but a lot of Prod.orders have consumed materials.
Do u have some quick advise? Our database have object from NAV 4 SP1 but we running with Nav 5SP1 client

Andwian · 2010-07-14

Hi Dn,

I am not sure about the older DB version running in newer version would affect the performance issue.

Here is the link to the summary KB Article 979232:
https://mbs.microsoft.com/knowledgebase/KbDisplay.aspx?scid=kb;EN-US;979232

Anyway, I can suggest you some important points:
1. You should run the ACIE as often as possible, during the non-working hours, you can filter on specific Item or group to limit the runtime, but always recommended to adjust all items.

2. There are 2 issue in ACIE: the slow performance, and the endless loop in ACIE

3. I am not sure which one is yours. If yours is the slow performance, hence although you experience the slow performance, I think you still can finish the process, but unfortunately with a very time consuming. So, just go on with a test, using the testing environment to run the ACIE, just to make a figure, how long it will take time. Just to figure, is it possible to do the ACIE in production DB, and what is the proper time to do that. unfortunately, if yours is the endless loop one, there is no more we can do, instead of applying the hotfix.

4. Evaluate the Key Setting in Value Entry table (5802), compare it to the Cronus.

5. The general issue is often happen with the:

a. Average Costing Method

b. "Item & Location & Variant" Average Cost Calc. Type.

c. You use the Transfer Order and multiple location

d. You consume products that are produced on the same order (carry-over production), i.e. a finished production order whose production process consumes an average cost item and ends up with an output in the same day
6. These also could affect the performance:

a. Upgrade to the database

b. Customization

c. Add-in installed

e. Setup of the DB: "Lock Timeout" and "Always Row-lock"

f. The size of the DB file

g. The Build No. of the NAV application

h. The version of the SQL Server
That's all the best I can do. Good luck!

dn · 2010-07-14

Andwian wrote:

Hi Dn,

I am not sure about the older DB version running in newer version would affect the performance issue.

Here is the link to the summary KB Article 979232:
https://mbs.microsoft.com/knowledgebase/KbDisplay.aspx?scid=kb;EN-US;979232

Anyway, I can suggest you some important points:
1. You should run the ACIE as often as possible, during the non-working hours, you can filter on specific Item or group to limit the runtime, but always recommended to adjust all items.

2. There are 2 issue in ACIE: the slow performance, and the endless loop in ACIE

3. I am not sure which one is yours. If yours is the slow performance, hence although you experience the slow performance, I think you still can finish the process, but unfortunately with a very time consuming. So, just go on with a test, using the testing environment to run the ACIE, just to make a figure, how long it will take time. Just to figure, is it possible to do the ACIE in production DB, and what is the proper time to do that. unfortunately, if yours is the endless loop one, there is no more we can do, instead of applying the hotfix.

4. Evaluate the Key Setting in Value Entry table (5802), compare it to the Cronus.

5. The general issue is often happen with the:
a. Average Costing Method
b. "Item & Location & Variant" Average Cost Calc. Type.
c. You use the Transfer Order and multiple location
d. You consume products that are produced on the same order (carry-over production), i.e. a finished production order whose production process consumes an average cost item and ends up with an output in the same day

6. These also could affect the performance:
a. Upgrade to the database
b. Customization
c. Add-in installed
e. Setup of the DB: "Lock Timeout" and "Always Row-lock"
f. The size of the DB file
g. The Build No. of the NAV application
h. The version of the SQL Server

That's all the best I can do. Good luck!

Many thanks for yours respons. I'll read kb ..thx again

NAV_Doctor · 2010-07-17

Hey Champ,

Did u fix your problem?

If not please provide details of what you know to date.

Doc

dn · 2010-07-17

NAV Doctor wrote:

Hey Champ,

Did u fix your problem?

If not please provide details of what you know to date.

Doc

I still have not fixed the problem. I've read the KB but it was for Nav 4.0 SP3 and above. We are running Nav 5 SP1 client with Nav 4 SP1 objects.
I found some a kb978605 that may solve my problem but MS said in Prerequisites

"You must have Service Pack 3 for Microsoft Dynamics NAV 4.0 installed to apply this hotfix."
I really don't know what the could happened if I just apply the change in cu 5895.

Do u facing same problem Nav Doctor?

David_Singleton · 2010-07-17

Find the item that the routine is stopping on. Review that item in detail to see why it is taking so long to adjust. It could be becasue it has an infinite loop (product using itself as a component in production), it might be a lot of complex transfers (transfer 1000 to a location, sell them one at time, credit them then transfer them back will play havoc with some versions of Adjust cost) , or serial numbers.

If there are open positives, like purchases not invoiced, close them out. Then filter the routine and adjust that one item.

dn · 2010-07-17

David Singleton wrote:

Find the item that the routine is stopping on. Review that item in detail to see why it is taking so long to adjust. It could be becasue it has an infinite loop (product using itself as a component in production), it might be a lot of complex transfers (transfer 1000 to a location, sell them one at time, credit them then transfer them back will play havoc with some versions of Adjust cost) , or serial numbers.

If there are open positives, like purchases not invoiced, close them out. Then filter the routine and adjust that one item.

How can I just adjust that Item?? Where should I put the code, in rep 795 or cu 5895?
I also wonder if I cancelled the ACIE routine, what happened with the transactions that been calculated before it went into the infinite loop.
I mean if I cancel the routine there will not be any posted adjust transaction or I am wrong?

David_Singleton · 2010-07-17

dn wrote:

David Singleton wrote:

Find the item that the routine is stopping on. Review that item in detail to see why it is taking so long to adjust. It could be becasue it has an infinite loop (product using itself as a component in production), it might be a lot of complex transfers (transfer 1000 to a location, sell them one at time, credit them then transfer them back will play havoc with some versions of Adjust cost) , or serial numbers.

If there are open positives, like purchases not invoiced, close them out. Then filter the routine and adjust that one item.

How can I just adjust that Item?? Where should I put the code, in rep 795 or cu 5895?

Take a look at a later version of Navision and copy the way it is done.

Someone posted the code here quite some time back (I think Rashed = ara3n) probably in Tips and Tricks if you want to search.

NAV_Doctor · 2010-07-18

Hey Champ and ChampS,

Looks like there is a lot of good feedback here from everyone.

I will not discourage you from trying what the others are saying as all the comments are correct.

I noticed in your initial post that you mentioned that you noticed that automatic cost posting was not working so you ran it manually. Correct me if I am wrong but is this one of the first times you are running the ACIE batch job?

As per the advise others have given you, if this is the first time you are running it "manuelly" you really do need to test how long it actually runs for. Set up a C/Side database on a machine with heaps of muscle. Let the batch job run for about 3 days or till it errors. If it hasn't finished by then, I would definetly say you have a loop.

If at any point the average cost valuation method has changed from "Item" to "Item, location, variant" this would also cause many entries for the ACIE to adjust. The good thing here is after it is ran once, speed will generally return to normal.

Check for any suspect entries in Tables 32, 339, 5802 and 5804. Look for funny dates.

The others have mentioned carry over Production as well. This is a very common cause of looping. If the system has entries of Production Orders that consume themselves, this can be a problem especially when the both the output and the consumption occur on the same date. There are some KB's out there for later versions that address simplified examples of this occuring.

Finally, you can get one of your developers to put a hit counter in the Value Entries, Item Ledger Entries and Production Order Tables that will commit a hit everytime that specific transaction is hit whilst running the ACIE. As David mentioned, sometimes the batch job is generous in that it will indicate the entries it is looping on, however this may not always be the case.

Good Luck, and do feel free to provide additional information as to the systems, items and production set-ups.

Regards,

Doc

Tetos · 2010-07-19

I experienced a similar problem before and found that if there is a blank itemcode, then the ACIE would run into an infinite loop. Pls check if you have a blank itemcode in the item master.

When this was executed for the first time, the process took almost 16 hours to complete. So if you are running it for the first time, it would take some time. As Nav doctor suggested load the database on a native client and perform the process to check how long it takes.

dn · 2010-07-29

Tetos wrote:

I experienced a similar problem before and found that if there is a blank itemcode, then the ACIE would run into an infinite loop. Pls check if you have a blank itemcode in the item master.

When this was executed for the first time, the process took almost 16 hours to complete. So if you are running it for the first time, it would take some time. As Nav doctor suggested load the database on a native client and perform the process to check how long it takes.

Normally it took around 45minutes, but by some reason it seems took forever. We don't have any blank item and neither prod.order that consume it output either.

NAV_Doctor · 2010-07-29

Do you have multiple transfer orders?

Doc

dn · 2010-08-04

NAV Doctor wrote:

Do you have multiple transfer orders?

Doc

Just transfers from one location to another location

Alex_Chow · 2012-09-06

I was able to resolve this problem (I think) by changing the posting date of the Output transaction on the Item Ledger and the Value Entry to the date AFTER the consumption entries. Now the adjust cost process does not go into infinite loop.

I'm still monitoring the future transaction of this item to see if any abnormal costing will occur.

NOTE! This is NOT Microsoft approved and you do this at your own risk!

Hano · 2012-09-10

I have a similar problem when i run "adjust cost item entries" batch job. The system is shown message " There is insufficient memory (Stack) to execute this function". I tried to find something strange in item application entry, value entry, item ledger entry but records seems to be ok.

I am using the nav database 2009 sp1 version W1. My company is in the distribution industry. We have not any assembled product and we are not using any manufacturing functionality.

We have a big number of transfer orders between locations.

The problem is happening only with 1 item.

Adjust Cost Item Entries hangs

Comments

Categories