Price change in P4210 adds line with blank price to F4211

Hello, list! Have any of you witnessed this? Several users are reporting this intermittent problem:

"I look up an order in Customer Service Inquiry (P4210), display sales order detail revision (Form W4210A), change the Unit Price in a certain line, and click OK. Not every time, but sometimes, this adds a record to F4211, when it should have updated a record, and leaves the new record's Unit Price and Extended Price BLANK."

No one who experiences this reports any kind of on-screen error; we discover it on the printed Pick Slip or Shipping Invoice and can correct it by deleting the errant line.

Sorry for sounding like the support line, but "Do you have any mods in P4210?" We ran into some crazy errors early on in our XE implementation with P4210, most of them were caused by incorrect updates to the different Sales Order caches.

Hi, Todd. Yes, we have made modifications to certain aspects of P4210. Where would I begin looking for these incorrect updates?

Any place you made mods!

Any additional or modified calls to "F4211 Edit Line" or any of the other Sales Order Master Business Functions would be a good place to start looking. These functions use a work file index number. If this value is incorrect, you can update values to the wrong record.

The F4211 Edit Line uses an index value of '0' to indicate that a new record should be added to cache, sounds like this is a possibility in your case.

It will be tricky if you can't narrow down the problem a little more, let us know if you have any further details to pass along. If you can't reproduce the error, there's not much to go on.

Good luck!

Very good information, Todd, thank you. I'll be investigating today. One additional tidbit that might be helpful: Our programmers claim this problem did not start happening until we migrated from Windows NT terminal servers (Metaframe 1.8) to Windows 2000 terminal servers (Metaframe XPe 1.0 FR3).

What do you make of that?

Hello, and thank you for writing with ideas about this.

It turns out this issue has been on the books with OneWorld Support since September 2001.
This JDELIST discussion from 7/11/2001 refers to SAR #5498266, which was fixed in all service packs since 18.1. Since we're on Service Pack 15.1, I'm way behind.

Here is an updated description of my problem:

>>>

Most of my P4210 users, at one time or another since migrating to Windows 2000 terminal servers, have experienced doubling of certain lines when processing sales orders or credits. The "doubled" line is corrupted--some blanks contain no data or invalid data. I suspect that something in the application is trying to update a line, but instead adds this partial line--resulting, if not caught, in extra product being shipped to our customers.

We have been using OneWorld Xe since November '02 and did not have any problems like this on our Windows NT terminal servers. We have not modified P4210 and have tried, at various times in the troubleshooting process, deleting user overrides for the users in question.

<<<


The final word from OneWorld Support: The problem exists in the system Tools and cannot be fixed by customers.

I learned all this today from OneWorld Support, who directed me to Document ID ODS-02-0029 (PeopleSoft Solution #200782275) from 10/25/2002:

>>>

This notification is to inform you of a recent issue discovered in slower performing terminal server environments, in EnterpriseOne and ERP 8, where the primary symptom displayed is a duplicate line written when editing an existing sales order.

All releases of PeopleSoft EnterpriseOne and ERP 8.0 can be effected by slower performing terminal server environments.

This communication serves the purpose of making you aware of the issue and the service pack downloads that will assist you in a resolution in slower performing terminal server environments.

The following service packs can be downloaded from the Update Center on the Knowledge Garden under: Support/Update Center. Target release dates for these updates can also be viewed from the Update Center. The fix should also be included in any subsequent Service Packs that are released.
.
.
.
Please note, subsequent to applying the fix, you may notice a slight difference in processing time. Please be aware that you will not be able to return to a row and perform updates until the "asynch" event on that row is complete.

<<<


The tech support person said there is an asynchronous process running behind the grid all the time, and on "slower" machines it can get confused; when it gets lost, it ends up creating a new line. She also referred vaguely to "custom grids" (user overrides, I assume) contributing to slowing down the process -- and also clerks who go too fast. The fix actually forces the process to be synchronous: Line 2 cannot be changed until Line 1 is successfully updated.

It's strange because we really did just upgrade our terminal server hardware, so I'm unsure why that would be the bottleneck. Our team has been discussing, however, how much work has been added to our AS400/iSeries database server in just three years -- so maybe that's the real problem. Though, that still doesn't explain why I have a handful of users who see this 75% of the time during their week, but no one else.

The whole thing is just freaking bizarre. At least everyone, so far, has agreed about THAT.

-Tim

Hi,

we are experiencing similar thing now in E1 8.11! When entering a credit order in P4210 with proc option 6 in process tab set to '1' (template processing is on) we get an extra line inserted into the detail revisions grid.

I have created case for it with Oracle, we'll see what happens.

Rgds

Andrew Holder

Perhaps ESU PG3855 would help.

Russell Karnap
[email protected]
859 760 7332 Cell
801 340 6886 Fax