Ship Confrim(P4205) Performance

[tomjr93]

We have just gone live and are getting feedback from our users about ship confirm being very slow. It is taking approximately 1+ minutes to ship confirm an order of 50 lines. Is this a normal amount of time to ship confirm this many lines? Has anyone else experienced ship confirm being a very slow process?

 

[malaia]

Tom,

Is it cirtix or fat client? any mods on ship confirm or commitments? I had some performance issue with one of my clients becuse of citrix connection... but without mods in fat client, 1+ minute sounds slow to me... It also depends on the timing of running some huge batch jobs that might be running on the schedule or by some other department.

You might want to monitor all the jobs running in server and the memory usage by job and application with CNC's help.

Malai Annamalai
Deloitte & Touche
OneWorld Xe Update 6, SP20

 

[tomjr93]

This is coming through citrix. There can also be some inventory reports running at the same time. We are running standard JD Edwards without any mods. What did your client do to increase the speed?

 

[vlaria]

Hello,
it is funny since we run much faster in Citrix.
How many users have you got? Are Citrix machines well dimensioned? Which environment are you using WPD7333 or PD7333?

 

[tomjr93]

We have about thirty users with three citrix servers with an average load of 7 users per server. Our server are Win2k with two 1 Ghz processors and 2 GB of RAM. We are using the WPD7333 environment with the BSFN logic mapped to run on the citrix server.

 

[vlaria]

Why don't you try using PD7333? It improves sometimes.

 

[jdesmm]

Shipment confirmation is based on data in the F41021 (Item Location) table. Are you by any chance creating many item / lot combinations that zero out over time but are not purging the table? Our company has found that we take performance hits in shipment confirmation and in item availability / segmented availability due to the amount of data in the F41021. It is not the amount of data alone that causes the slowdown - if you run a raw SQL statement similar to what JDE sends, you should see a very fast return. Rather it is how the grid processing occurs when there are many records at a 0 quantity on hand - these are suppressed at the grid level rather than at the SQL level, and it slows the application performance down immensely.

We got an immediate return by purging the F41021, but there are some gotchas, so if you are interested in going that route, I can communicate more with you offline. Another option we were able to use in some cases was to performance tweak the application itself. I can go into more detail there as well.

--Shelley M. Maas
--Apio, Inc.

 

[tmackin]

We are also experiencing poor performance in the same areas. We have only 50k records and was told that it was not the sql that was the problem but how the table was processed.

I have a task to set up a complete database purge process but have found that JDE does not have totally "complete" purge processes, meaning that not all related tables are purged. What have you found? Do you know of any documents on the KG or do you have a documented procedure to handle the purging/archiving of old data?

At our last users group meeting we had a session on purging and archiving led by a JDE business partner. He stated that JDE does not have a complete process for purging/archiving. He mentioned some 3rd party companies, Priceton and Iterra that may have solutions but are not JDE partners.

Since I am not astute in the programming side of things, I do not think I could write the necessary programs to do a complete job. He also stated that purging has a detrimental effect on integrity reports. Also he feels that JDE has "washed their hands" of this whole process!!

Any info or suggestions would be greatly appreciated!!

PS. Maybe the users should start a SIG on the subject to see if we can put any pressure on JDE to make OW a complete system!!

 

[jdesmm]

Yes, it's the grid processing that kills performance. Regarding purging, our company launched a project last year to determine which tables we needed to purge and whether or not JDE provided purge routines for them. The slowdown we experienced in shipment confirmation was in the Select Multiple Locations program (P42053), which is based on the F41021 (Item Location table). JDE does provide a purge UBE for the F41021 - it is the R4102P.

You can run the R4102P two different ways: 1) purge F4102, F41002, F41021, and F4105 or 2) purge F41021 only. We implemented # 2. As the R4102P does not archive data, I strongly recommend that you copy the entire table(s) that you intend to purge over to a holding database.

We found after the purge, that we had to put some of the records back into the production table. This was largely due to how our company handles things procedurally - we create locations that are used as staging areas until the "real" lot is identified, and we create locations for future use - but there were also some records deleted that we hadn't planned for. Now that we know our exceptions, we plan to script out the re-inserts for the next time we purge.

I can forward our purge documentation to you if you like. We have documents that describe in layman's terms what the R4102P will do based on the different processing options, describe our test plans and their results, and provide a cross reference of applications and reports based on the table(s) to be purged.

Re: your P.S. - Very good idea!

 

[jdesmm]

Just wanted to add a bit more information about some of the unexpected issues we encountered post purge:

1) We procedurally sometimes ship items at zero price and then later go back to price the orders. When users attempted to re-price order lines that had been attached to a purged item location record, they were unable to do so - price history would not open for those lines.

2) In some cases, users change information at the sales order header level, such as the customer PO on orders that have been invoiced. If the order had lines associated with a purged item location record, the P4210 deleted the lot number on the detail line. One of our developers tracked this back to a business function and placed a call to JDE on it, but they weren't very supportive.

Because we had backed up the data, we copied the particular records back into the table via SQL, but next time, we plan to have a script ready that will check purged records for associated sales orders, and if they are within a certain date range, will automatically put them back into the table.