Problem With Adjust Cost In Navision 4.0 Sp3

vecais

Hello,


There is a problem with the Adjust Cost - Item Entries in the version SP3 of Navision 4.0?

When I run the job, takes a lot of time and never ends?
Is a bug?

Too, I filter only by a item, but doesn`t solve my problem, because the process loops in other item and don´t stop.

Is a good solution, delete the entries in table 5804 for this item?.

Do you know a solution/s?

I need help!!

Thanks you

kine

How you know that it is looping and not that it just need more time to finish?
How often you are running the job?
Which costing method you are using?
How many documents you are posting per day?

We need to know more to be able to answer...

vecais

Hello,

I answer you questions:

How you know that it is looping and not that it just need more time to finish?

Because I run the job in a weekend and when I see on Monday, the job is still running.
Moreover, I try running with a particular item that I saw has a lot of entries in Item Ledger Entry and Value Entry, and the process will never stops.
It takes all the afternoon and all the night, but not stop. Only for a item.

The principal reason that the job is not very well is that I change the version of Navision approximately 1 month ago, and in the version 4.0
I don´t have any problem and takes a "normal time".

We have 4.0 SP3 with SQL 2000 SP4.

How often you are running the job?
Approximately a month.

Which costing method you are using?
Average cost in all the items.

How many documents you are posting per day?
Approximately 1000 entries/day.

We need to know more to be able to answer...

kine

In some cases, when you are using average costing, and you will post some document into history (e.g. if you today post purchase invoice with posting date 1.1.2008) the adjust batch can took hours and days. Mainly if the database and system is not optimized. Running the batch once per month is TOO LONG time. Our customers are running it each day and it sometimetook 2 hours (and they are using FIFO and other costing methods, which are not so complex for costing). It means that if you run the batch after one month on average cost and with 1000 entries per day on not optimzed system, the time can be in days...

vecais

Ok Kine,

I know that running the batch once per month is not the better thing.

Although I defend that we don´t have problems with version 4.0, and so I think that can be anywhere type of problem with this version.

Probably I think wrong with this, but I see a lot discussion in the forum with this topic.

Then, What Can I do?
Running the job the next weekend.

Another thing I prove deleting a entry for a single item in table 5804, and when I repeat the process for this item.
It takes less 1 second and updates in the item's card, the field unit cost with the average cost. Is makes sense?

Thanks,

kine

Deleting the entries in table 5804 will lead to wrong costing for the item. This table is used to flag earliest date to which NAV must look at to count new average cost for the item. It is the earliest date used to post some value entry for the item since last adjust batch. If you delete that, NAV will take it as nothing was posted for that item...

Of course, you can be in situation, when the adjust batch is really in Never-ending loop. But I never see that on NAV 4.0 and up.

Have you some support from partner? Are they able to look at your problem? Can they test the performance? NAV 4.00SP3 can be slower than pre-SP3 versions in some situations if optimization is not done.

vecais

Hi again!

Today I'll try running the job only for a group of items this night.
If the situation continues equal, I'll try to optimize, passing a test for the database, reindex SQL ,etc...

Another question:
Is possible that the problem in a particular item that takes a lot of time in the job, (for example), is that the inventory of the item must be equal than the Remaining Quantity for the sum of all the item ledger entry for the item?

Logically, the inventory = sum (quantity) item ledger entry = sum (Remaining Quantity) item ledger entry
No?

A friend tell me that verify this.

I'll tell you.

kine

Logically, the inventory = sum (quantity) item ledger entry = sum (Remaining Quantity) item ledger entry
No?

Yes, it MUST be equal. If not, you have inconsistent data - but I do not know how that can be related to length of adjustment batch.

Check the date in table 5804 for the problematic item - if the date is too old, it means that somebody posted something back into history and that means whole recalculating of all entries posted after that date... and it can be big amount of entries. If you are using average costing, you need to manage the people to post all things as earlier as possible and to try not back-dating the documents if possible.

i4tost

If you want to analyse is it problem with optimization you can create backup and restore on native database. Then try to do the same on this database. If it still takes a lot of time means - some issues with calculation. If not, you need to optimize calculation for SQL server (believe it is possible and can reduce total time a lot (means tens of times)).

idiot

Check if you a blank item no......