Inventory Closing Performance problem
egervais
We are unable to complete the inventory closing procedure. The process is
very long (over 6 hours.). The InventClosingLog records are huge
(InfoLogData), it is over 100Mb. and we are unable to open it.
Also, we have the following event id on the server:
Event Type: Warning
Event Source: Dynamics Server 01
Event Category: None
Event ID: 178
Date: 4/22/2008
Time: 12:00:42 AM
User: N/A
Computer: DEV2-AOS-01
Description:
Object Server 01: Performance info: The complete data cache has been flushed
due to request from session 1 (-AOS-).
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
we are running:
AX 4.0 sp2
Thanks for your help
egervais
Max throughputs 100
min throughputs adjustment 1.0
Mark Blevins
Date weighted average can take the longest time.
Also, Are you indexing your tables on a regular basis?
# of Items & Levels in your BOM's can also have an impact as well as a large
number of internal inventory transfers (warehouse moves).
Regards,
MB
"egervais" <eger...@discussions.microsoft.com> wrote in message
news:1DDCC232-2DCC-4573...@microsoft.com...
egervais
We are using FIFO. We have a few BOMs but not many since we don't use
production modules.
I will Find out a bit more about the indexing we do. Which tables would need
indexing in this case? (Transactions, InventoryClosing...?)
We do have quite a few inventory transfers, I will check that out too.
Thanks again
Eric
Mark Blevins
maintenance plan.
We have seen varying times from 2 hours to 12 hours using standard. We have
16k SKU's
Also depends on your set up. I'd try the indexing first and see if there was
a time difference.
When it is running, you can also monitor SQL for blocking transactions.
"egervais" <eger...@discussions.microsoft.com> wrote in message
news:98B33526-F9D6-47F1...@microsoft.com...
egervais
We tried running Inventory Closing this weekend. We started the process at
10:51 am saturday. At 00:00 the data cache was flushed and the server
restarted. This is normal it seems in AX 4 sp2.
So the inventory closing ran for 13hrs 9 mins and it still was not done. The
log size was only 30 Mb though compared to the 100+ mb logs we were getting.
There are a lot of warning concerning non-stock transactions in the log.
These refer to an amount which cannot be settled. Is this normal? Should
non-stock transactions be treated at all or should they be closed already and
not be processed by the inventory closing procedure?
We will try running it next weekend starting at 00:15 to see how long it
will go for. In the mean time I will check with our DBA for regular indexing.
Thanks again.
egervais
Mark Blevins
Without knowing your implementaiton, that would be a hard call to make.
I have noticed the more it writes to the info log the slower it gets.
If you do a lot of warehouse transfers, and your cost does not change with
the transfers, you could write a script that closes those transactions
before you attempt the close. Basicall it will process the transfers In &
Out even though they balance.
"egervais" <eger...@discussions.microsoft.com> wrote in message
news:7E62A964-B98A-4EEC...@microsoft.com...
Sloth
If you have a test sytem comment out the Close Infolog and try another run.
You can also enlist Helpers on a Close. See Calculation button.
If you have a prior Close go to the "Closing and Adjustment" form | Session
tab and note the "Number of Program Sequences". This would be the actual
number of Throughputs (BOM levels and Transfers) of that Close. You can make
an adjustment to your Close Throughput setting based on that number and get
an idea of how much work the Close is doing.
Ensure you have no locking and blocking processes (e.g. batches, users,
etc.) during a Close run.
Close "Settles" (matches) Issues to Receipts, on Financially updated
transactions (Invoiced, Costed, etc.), by Inventory Dimension (InventDimID).
Are the Items really Service (Item Type) or non-stock by virtue of the Model
Group set up but really Item Type of Item or BOM?
Sloth
mlitwin
I would recommend to proceed with inventory recalculation, fg. 4 times per
month (each end of week), then one closing at month end. It should improve
inventory closing.
egervais
The problem.
We transfer sales orders from another system. That other system has BOMs set
up and detailed on the orders but only the BOM item is transfered over to AX.
What happens is that this item is type BOM in AX, but it has no BOM attached
or configured. The transaction lines generate errors during the inventory
close, which were being written(appended) to the log. These transactions stay
open and are just increasing (we now have over 100 000 transactions of this
type). This has been jamming our inventory closing process.
The solution.
Since these items are mono-level in AX, we will switch their type to
non-stock (service). Our tests reveal that the open transactions will be
closed this way. We will also be running the recalculation to see if it
improves the runtime.
Thanks for all you help!
PvO_be
Do you mean your problem is the following:
You have sales orders that contain BOM type items on the SO lines
These BOM type items do not have any BOM lines associated with the parent
item
IM->Items->BOM button->Lines
We have this situation but never had a problem closing the inventory in Ax
3.0 SP3, only in Ax 4.0 SP2 are we experiencing a much slower process (8x
longer).
In a test system (smaller db size) we were able to speed up the process by
commenting out the writeLog method on the InventClosing table.
Patrick
Egervais
This is exactly the problem and we were unable even to open the
inventclosing form because of this. The problem is, we want to be able to see
the log generated, so commenting out the writelog wasn't an option for us.
The problem has since been fixed in a production environment by switching
these parent BOM items to type service. We were able to close the open
transactions and now run time is under 45 minutes. We also modified the form
so that it doesnt check if a log exists for each inventory closing journal.
We are able to open the form now even though we have huge logs for past
inventory closings.
A BOM just isn't a Bom if it doesn't have and BOM lines....so I think our
solution worked out well;-)
PvO_be
With the help of Microsoft, we have overcome our slow invent closing problem.
We applied one new cluster index to the InventSettlement table and applied
two new indexes to the InventTrans table.
Now our invent closing process (using weighted average cost) is running in
Ax 4.0 at the same speed as we had in Ax 3.0.
Patrick
zacky74
I'm looking for a solution for this problem.Could you give me a details
which indexes you added to the inventtrans and inventsettlement table?
Thanks
PvO_be
InvenSettlement
SettleTransIdx (set as ClusterIndex on table properties)
SettleTransId
Cancelled
SettleType
QtySettled
InventTrans
InventRefTransIdx
ItemId
ValueOpen
InventRefTransId
StatusIssueIdx
ItemId
ValueOpen
StatusIssue
We have not yet completed testing to ensure the closing results provide us
with the same inventory value and settlement/adjustement, but at least the
speed problem got solved.
Patrick
zacky74
We will try it too and keep you informed if helped or not.
zacky74
gnanendrareddy
I had similar situation with my client.
where they did run the Recalculation and then AX hanged. On the session tab showing it has completed some lines and still some are there to be completed. but the recalculation process has been stopped. Then cancelled the line & again run same process.
Even this time the process stopped and thrown an error in event viewer that application hanged.
Please let me know if anybody knows how to resolve.
Thaks in advance.
regards,
gnanendra.
zacky7 wrote:
Many thanks Patric!
15-Sep-08
Many thanks Patric!
We will try it too and keep you informed if helped or not.
zacky74
"PvO_be" wrote:
Previous Posts In This Thread:
On Friday, April 25, 2008 9:33 AM
egervai wrote:
Inventory Closing Performance problem
Hi,
We are unable to complete the inventory closing procedure. The process is
very long (over 6 hours.). The InventClosingLog records are huge
(InfoLogData), it is over 100Mb. and we are unable to open it.
Also, we have the following event id on the server:
Event Type: Warning
Event Source: Dynamics Server 01
Event Category: None
Event ID: 178
Date: 4/22/2008
Time: 12:00:42 AM
User: N/A
Computer: DEV2-AOS-01
Description:
Object Server 01: Performance info: The complete data cache has been flushed
due to request from session 1 (-AOS-).
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
we are running:
AX 4.0 sp2
Thanks for your help
On Friday, April 25, 2008 9:43 AM
egervai wrote:
RE: Inventory Closing Performance problem
We are running Inventory Closing with:
Max throughputs 100
min throughputs adjustment 1.0
"egervais" wrote:
On Friday, April 25, 2008 4:13 PM
Mark Blevins wrote:
The log is not surprising. What costing method are you using?
The log is not surprising. What costing method are you using?
Date weighted average can take the longest time.
Also, Are you indexing your tables on a regular basis?
number of internal inventory transfers (warehouse moves).
Regards,
MB
"egervais" <eger...@discussions.microsoft.com> wrote in message
news:1DDCC232-2DCC-4573...@microsoft.com...
On Friday, April 25, 2008 4:43 PM
egervai wrote:
Re: Inventory Closing Performance problem
Hi mark, thanks for the reply. To answer your questions:
We are using FIFO. We have a few BOMs but not many since we don't use
production modules.
I will Find out a bit more about the indexing we do. Which tables would need
indexing in this case? (Transactions, InventoryClosing...?)
We do have quite a few inventory transfers, I will check that out too.
Thanks again
Eric
"Mark Blevins" wrote:
On Friday, April 25, 2008 4:52 PM
Mark Blevins wrote:
I would put the indexing on a regular schedule for the entire DB on a
I would put the indexing on a regular schedule for the entire DB on a
maintenance plan.
We have seen varying times from 2 hours to 12 hours using standard. We have
16k SKU's
Also depends on your set up. I'd try the indexing first and see if there was
a time difference.
When it is running, you can also monitor SQL for blocking transactions.
"egervais" <eger...@discussions.microsoft.com> wrote in message
news:98B33526-F9D6-47F1...@microsoft.com...
On Monday, April 28, 2008 1:47 PM
egervai wrote:
Re: Inventory Closing Performance problem
I have checked Indexing. It is done every day.
"egervais" wrote:
On Tuesday, April 29, 2008 1:10 AM
Mark Blevins wrote:
I would assume you would not want nonstock items to close and calculate.
I would assume you would not want nonstock items to close and calculate.
Without knowing your implementaiton, that would be a hard call to make.
I have noticed the more it writes to the info log the slower it gets.
If you do a lot of warehouse transfers, and your cost does not change with
the transfers, you could write a script that closes those transactions
before you attempt the close. Basicall it will process the transfers In &
Out even though they balance.
"egervais" <eger...@discussions.microsoft.com> wrote in message
news:7E62A964-B98A-4EEC...@microsoft.com...
On Wednesday, April 30, 2008 5:16 AM
mlitwi wrote:
Hi EgervaisI would recommend to proceed with inventory recalculation, fg.
Hi Egervais
I would recommend to proceed with inventory recalculation, fg. 4 times per
month (each end of week), then one closing at month end. It should improve
inventory closing.
"Sloth" wrote:
On Wednesday, June 18, 2008 5:43 PM
PvOb wrote:
Re: Inventory Closing Performance problem
Hi Egervais,
Do you mean your problem is the following:
You have sales orders that contain BOM type items on the SO lines
These BOM type items do not have any BOM lines associated with the parent
item
IM->Items->BOM button->Lines
We have this situation but never had a problem closing the inventory in Ax
3.0 SP3, only in Ax 4.0 SP2 are we experiencing a much slower process (8x
longer).
In a test system (smaller db size) we were able to speed up the process by
commenting out the writeLog method on the InventClosing table.
Patrick
"egervais" wrote:
On Wednesday, June 18, 2008 7:04 PM
Egervai wrote:
Hi PvO_be,This is exactly the problem and we were unable even to open the
Hi PvO_be,
This is exactly the problem and we were unable even to open the
inventclosing form because of this. The problem is, we want to be able to see
the log generated, so commenting out the writelog wasn't an option for us.
The problem has since been fixed in a production environment by switching
these parent BOM items to type service. We were able to close the open
transactions and now run time is under 45 minutes. We also modified the form
so that it doesnt check if a log exists for each inventory closing journal.
We are able to open the form now even though we have huge logs for past
inventory closings.
A BOM just isn't a Bom if it doesn't have and BOM lines....so I think our
solution worked out well;-)
"PvO_be" wrote:
On Thursday, September 11, 2008 12:07 PM
PvOb wrote:
FYIWith the help of Microsoft, we have overcome our slow invent closing
FYI
With the help of Microsoft, we have overcome our slow invent closing problem.
We applied one new cluster index to the InventSettlement table and applied
two new indexes to the InventTrans table.
Now our invent closing process (using weighted average cost) is running in
Ax 4.0 at the same speed as we had in Ax 3.0.
Patrick
"PvO_be" wrote:
On Monday, September 15, 2008 8:57 AM
zacky7 wrote:
Hi Patric,I'm looking for a solution for this problem.
Hi Patric,
I am looking for a solution for this problem.Could you give me a details
which indexes you added to the inventtrans and inventsettlement table?
Thanks
"PvO_be" wrote:
On Monday, September 15, 2008 9:55 AM
PvOb wrote:
Re: Inventory Closing Performance problem
The following added indexes did the trick for us:
InvenSettlement
SettleTransIdx (set as ClusterIndex on table properties)
SettleTransId
Cancelled
SettleType
QtySettled
InventTrans
InventRefTransIdx
ItemId
ValueOpen
InventRefTransId
StatusIssueIdx
ItemId
ValueOpen
StatusIssue
We have not yet completed testing to ensure the closing results provide us
with the same inventory value and settlement/adjustement, but at least the
speed problem got solved.
Patrick
"zacky74" wrote:
On Monday, September 15, 2008 10:03 AM
zacky7 wrote:
Many thanks Patric!
Many thanks Patric!
We will try it too and keep you informed if helped or not.
zacky74
"PvO_be" wrote:
Submitted via EggHeadCafe - Software Developer Portal of Choice
Load Testing ASP.NET Applications with Visual Studio 2010
http://www.eggheadcafe.com/tutorials/aspnet/13e16f83-4cf2-4c9d-b75b-aa67fc309108/load-testing-aspnet-applications-with-visual-studio-2010.aspx
Erick Zumararag
Describe please, and registros.
> On Friday, April 25, 2008 9:33 AM egervai wrote:
> Hi,
>
> We are unable to complete the inventory closing procedure. The process is
> very long (over 6 hours.). The InventClosingLog records are huge
> (InfoLogData), it is over 100Mb. and we are unable to open it.
>
> Also, we have the following event id on the server:
>
> Event Type: Warning
> Event Source: Dynamics Server 01
> Event Category: None
> Event ID: 178
> Date: 4/22/2008
> Time: 12:00:42 AM
> User: N/A
> Computer: DEV2-AOS-01
> Description:
> Object Server 01: Performance info: The complete data cache has been flushed
> due to request from session 1 (-AOS-).
>
> For more information, see Help and Support Center at
> http://go.microsoft.com/fwlink/events.asp.
>
> we are running:
> AX 4.0 sp2
>
> Thanks for your help
>> On Friday, April 25, 2008 9:43 AM egervai wrote:
>> We are running Inventory Closing with:
>>
>>
>> Max throughputs 100
>> min throughputs adjustment 1.0
>>
>>
>> "egervais" wrote:
>>> On Friday, April 25, 2008 4:13 PM Mark Blevins wrote:
>>> The log is not surprising. What costing method are you using?
>>> Date weighted average can take the longest time.
>>>
>>> Also, Are you indexing your tables on a regular basis?
>>> number of internal inventory transfers (warehouse moves).
>>>
>>> Regards,
>>> MB
>>>
>>> "egervais" <eger...@discussions.microsoft.com> wrote in message
>>> news:1DDCC232-2DCC-4573...@microsoft.com...
>>>> On Friday, April 25, 2008 4:43 PM egervai wrote:
>>>> Hi mark, thanks for the reply. To answer your questions:
>>>>
>>>> We are using FIFO. We have a few BOMs but not many since we don't use
>>>> production modules.
>>>>
>>>> I will Find out a bit more about the indexing we do. Which tables would need
>>>> indexing in this case? (Transactions, InventoryClosing...?)
>>>>
>>>> We do have quite a few inventory transfers, I will check that out too.
>>>>
>>>> Thanks again
>>>> Eric
>>>>
>>>> "Mark Blevins" wrote:
>>>>> On Friday, April 25, 2008 4:52 PM Mark Blevins wrote:
>>>>> I would put the indexing on a regular schedule for the entire DB on a
>>>>> maintenance plan.
>>>>> We have seen varying times from 2 hours to 12 hours using standard. We have
>>>>> 16k SKU's
>>>>> Also depends on your set up. I'd try the indexing first and see if there was
>>>>> a time difference.
>>>>>
>>>>> When it is running, you can also monitor SQL for blocking transactions.
>>>>>
>>>>>
>>>>> "egervais" <eger...@discussions.microsoft.com> wrote in message
>>>>> news:98B33526-F9D6-47F1...@microsoft.com...
>>>>>> On Monday, April 28, 2008 1:47 PM egervai wrote:
>>>>>> I have checked Indexing. It is done every day.
>>>>>>
>>>>>> "egervais" wrote:
>>>>>>> On Tuesday, April 29, 2008 1:10 AM Mark Blevins wrote:
>>>>>>> I would assume you would not want nonstock items to close and calculate.
>>>>>>> Without knowing your implementaiton, that would be a hard call to make.
>>>>>>>
>>>>>>> I have noticed the more it writes to the info log the slower it gets.
>>>>>>>
>>>>>>> If you do a lot of warehouse transfers, and your cost does not change with
>>>>>>> the transfers, you could write a script that closes those transactions
>>>>>>> before you attempt the close. Basicall it will process the transfers In &
>>>>>>> Out even though they balance.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> "egervais" <eger...@discussions.microsoft.com> wrote in message
>>>>>>> news:7E62A964-B98A-4EEC...@microsoft.com...
>>>>>>>> On Wednesday, April 30, 2008 5:16 AM mlitwi wrote:
>>>>>>>> Hi Egervais
>>>>>>>>
>>>>>>>> I would recommend to proceed with inventory recalculation, fg. 4 times per
>>>>>>>> month (each end of week), then one closing at month end. It should improve
>>>>>>>> inventory closing.
>>>>>>>>
>>>>>>>> "Sloth" wrote:
>>>>>>>>> On Wednesday, June 18, 2008 5:43 PM PvOb wrote:
>>>>>>>>> Hi Egervais,
>>>>>>>>>
>>>>>>>>> Do you mean your problem is the following:
>>>>>>>>> You have sales orders that contain BOM type items on the SO lines
>>>>>>>>> These BOM type items do not have any BOM lines associated with the parent
>>>>>>>>> item
>>>>>>>>> IM->Items->BOM button->Lines
>>>>>>>>>
>>>>>>>>> We have this situation but never had a problem closing the inventory in Ax
>>>>>>>>> 3.0 SP3, only in Ax 4.0 SP2 are we experiencing a much slower process (8x
>>>>>>>>> longer).
>>>>>>>>>
>>>>>>>>> In a test system (smaller db size) we were able to speed up the process by
>>>>>>>>> commenting out the writeLog method on the InventClosing table.
>>>>>>>>>
>>>>>>>>> Patrick
>>>>>>>>>
>>>>>>>>> "egervais" wrote:
>>>>>>>>>> On Wednesday, June 18, 2008 7:04 PM Egervai wrote:
>>>>>>>>>> Hi PvO_be,
>>>>>>>>>>
>>>>>>>>>> This is exactly the problem and we were unable even to open the
>>>>>>>>>> inventclosing form because of this. The problem is, we want to be able to see
>>>>>>>>>> the log generated, so commenting out the writelog wasn't an option for us.
>>>>>>>>>>
>>>>>>>>>> The problem has since been fixed in a production environment by switching
>>>>>>>>>> these parent BOM items to type service. We were able to close the open
>>>>>>>>>> transactions and now run time is under 45 minutes. We also modified the form
>>>>>>>>>> so that it doesnt check if a log exists for each inventory closing journal.
>>>>>>>>>> We are able to open the form now even though we have huge logs for past
>>>>>>>>>> inventory closings.
>>>>>>>>>>
>>>>>>>>>> A BOM just isn't a Bom if it doesn't have and BOM lines....so I think our
>>>>>>>>>> solution worked out well;-)
>>>>>>>>>>
>>>>>>>>>> "PvO_be" wrote:
>>>>>>>>>>> On Thursday, September 11, 2008 12:07 PM PvOb wrote:
>>>>>>>>>>> FYI
>>>>>>>>>>>
>>>>>>>>>>> With the help of Microsoft, we have overcome our slow invent closing problem.
>>>>>>>>>>> We applied one new cluster index to the InventSettlement table and applied
>>>>>>>>>>> two new indexes to the InventTrans table.
>>>>>>>>>>>
>>>>>>>>>>> Now our invent closing process (using weighted average cost) is running in
>>>>>>>>>>> Ax 4.0 at the same speed as we had in Ax 3.0.
>>>>>>>>>>>
>>>>>>>>>>> Patrick
>>>>>>>>>>>
>>>>>>>>>>> "PvO_be" wrote:
>>>>>>>>>>>>>> Many thanks Patric!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We will try it too and keep you informed if helped or not.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> zacky74
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> "PvO_be" wrote:
>>>>>>>>>>>>>>> On Monday, June 28, 2010 11:49 AM gnanendra reddy wrote:
>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I had similar situation with my client.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> where they did run the Recalculation and then AX hanged. On the session tab showing it has completed some lines and still some are there to be completed. but the recalculation process has been stopped. Then cancelled the line & again run same process.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Even this time the process stopped and thrown an error in event viewer that application hanged.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Please let me know if anybody knows how to resolve.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thaks in advance.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> gnanendra.
>>>>>>>>>>>>>>> Submitted via EggHeadCafe
>>>>>>>>>>>>>>> Entity Framework Code-First Library CTP 5 Quick Facts
>>>>>>>>>>>>>>> http://www.eggheadcafe.com/tutorials/aspnet/1be19af6-7384-4eca-9076-d19c2d0638cc/entity-framework-codefirst-library-ctp-5-quick-facts.aspx