Adjust cost - item entries

Waldo

When our client runs the adjust cost - item entries functionality the system is busy for approx 2 days. There are +-20.000 items in the database and +- 110.000 finished production orders.
How long does it normally take to run this batch and what are the necessary steps ?
What can we do to speedup this process ?

Timo_Lässer

Waldo wrote:

[...]
What can we do to speedup this process ?

• Stop the server and open the database local
• Open the database direct on the server (not over LAN)

Waldo

We already tried that, and it still takes too long (about two days).

We have a database of 30Gb. The Item Ledger Entry and the Value Entry are the two biggest tables in the database. I mean: very very much data!

Now it takes about two days. I was more thinking about two ours that is should take ... .

craigbarbs

Firstly, what version are you running.

Secondly, there are two legs, namely the Adjust Cost Item Entries and the Post Inventory Cost to G/L. Which is the slowest leg?

Julian_Dalton

We're experiencing similar problems with this job taking a long time to run. Did you find a solution :?:

Erik_E

Well in 2.60 that batch job was terrible in combination with the posting of it. In 3.60/3.70 it seems better since the filtering seems to work better.

Has this job never been run at that company?? If not well u could split the batch into let's say first you do 2000 items and days later the nect 2000. When all has been done. run this batchjob every month or so . It will speed up then .

fjhxl

It seems ACIE scan all the history data.
IMO, it is not a good idea and not practical if the database expand terribly.

hvalev

In Navision 3.60 with 5 GB Database Adjust Cost works about 15 hours. But we found problem with costing of the components by wrong date. Very sorry of there is not decision with start date of the batch.

kine

We have customer with many transfers - 1st batch go over 30 hours. It was possible to run this batch only in weekend. But they needed to know costs. Problem was in 10 items, which was often transfered and this transfer was posted 2 months backward (with old posting date) = we made changes into 1st batch to skip this items when selected - on work day they run 1st batch without this items - 3 hours - on weekend all items - 30 hours...

Problem is the backward posted documents, because 1st job go through all entries posted with newer date... if you post something with posting date two month back, whole two month for this item will be adjusted... 8)

RobertMo

Aprox counts:
DB size: 7GB
Items: 3700
Item Ledger Entries: 150.000
Vaue Entries: 350.000

ACIE takes less then 0,5 hour.
(No production or assembly, just purchase, transfer, sell and consume)

kine

RobertMO: How many new entries from last ACIE? Some backward posting (how much back)? - this is main informations... 8)


Thx

RobertMo

not a lot of backward postings, it's pretty straight-forward and for sure everything cleared up to 15-th in month for previous month.

Usually around 18.000 new Value entries created per month, ACIE is run 2x,3x a month, but first run generates >90% new entries. And this run takes 0,5 h.

kine

Can you send some HW spec?
SQL or Native?

Using FIFO, Average or other costing method?

RobertMo

Using FIFO.
SQL Server 2000.
I don't know exact HW spec (customer restrictions - has also other applications/DB (~10) running on the same server), but for sure it's fast.

Lucky to have that kind of customer...

kine

ah.... now it is all clear... :-)

Long batch is only for Average.... FIFO is without problems... :-)

8)

Alex_Chow

Maybe try optimizing the item ledger and value entry tables?