Ship Confirm Record Locking Problems

[magpie]

We're experiencing record locking problems when we try to add an additional line in ship confirm (P4205). I'll try to attach Document ODS-01-0043, which explains our issue pretty well.

Neither of their workarounds sound very appealing:

1. Turn off transaction processing for the Shipment Confirmation (P4205) Application. NOTE: This resolution may cause data integrity issues between the item ledger (F4111) and the Item Location File (F41021) files when a transaction fails for any reason.

2. Extend the Transaction Procession boundary to the W4205D form. NOTE: This workaround may cause additional record locking issues if any other applications are trying to access the records that are locked by the W4205K and W4205D forms. If a user leaves open the Additional Line Items form for an extended period of time before clicking OK, this will increase the chance of the record locking. The Global Support Center will not support the proposed workaround.

They also mention that it's very rare for this problem to occur. It happens to us every single time we try to add a line! It's also happening to another customer of our business partner.

I'd love to hear any comments on the impact of these workarounds. I'm not sure I really understand what taking either of these steps will do.

It's disheartening to go through an upgrade finding applications that work in XE and don't work in 8.10.

Maggie

 

[Zoltan_Gyimesi]

Hi Maggie,

How can you "Turn off transaction processing for the Shipment Confirmation (P4205) Application"?

As far as I know, you can set Transaction Processing feature only on Form level, not on application level.

"I'm not sure I really understand what taking either of these steps will do"

If you haven't read, then the best time to read the Transaction Processing chapter in the Development Tools manual. It's about 30 pages long. It describes how forms inherit Transaction settings via form interconnect in different scenarios. There are something about Record Locking too, and many other transaction processing related info.

I know, my reply not too much help in your issue.

Regards,

Zoltán

 

[magpie]

Thanks for the suggestion. I'll have a look at that chapter. I want to be as educated as possible when I hash this out with my boss on Monday.

I'm also curious to know if this is as rare as PS claims it is.

Maggie

 

[sselman]

We ran into this same problem. In short, every time a user tried to add a record, they ended up locking against themselves. As a result, we force the user to go back into the order to add the freight line instead of using P4205.

We are using SQL2000 which locks records a little different than an AS400 or Oracle. The consultants we had on site never saw this problem before, but almost all of their experience was not with SQL 2000 and everyone was new to 8.9. It is my understanding that you CAN adjust how the database locks records to get around this problem. I would NOT recommended it. Who knows how other things will start functioning. I don't prefer moving the TP boundary either. Possible data corruption isn't an option and neither is creating more locks for others. A change of business process is the safest choice.

My 2 cents.

 

[magpie]

Thanks Sean. My boss is very reluctant to upgrade to something that worked before and now doesn't. It's just not very good PR for the upgrade as a whole.

This only affects a small number of our shipped orders. We have a custom interface with our UPS system. We only manually add freight lines for orders shipping via truck. Still, I don't want a guy on our shipping line editing sales orders!

I guess it's up to my boss at this point. I do appreciate hearing your perspective.

Maggie

 

[sselman]

You could also force them to enter a version of p4210 which locks down everything but freight lines so that they can't do anything else.

I would think you could add another OK button to show the user on P4205 that calls the real OK button, then calls this special version of P4210 (or a custom ap that does what you need). This way, you are not running into the lock since the records are released but you still force the entry of a freight line.

Might not be as easy as it sounds, just a thought.

 

[Craig_Potter]

Magpie,

What surprises me is that you don't have this problem in your Xe Upd 4 Live environment.

I recently turned on the Additional Line screen on P4105 at an Xe Upd 3 site and had to turn it off again due to Commitment failures - and the resulting database corruption that this causes.

You may want to check your F41021WF (if you are using this) or your reconciliations of F41021 and F4111 to see if this is a bigger problem than you think.

Unfortunately, I have no experience to offer with either of these 'so-called' workarounds. Neither sounds that palatable to me . We were able to re-engineer around this, although we weren't trying to enter Freight $.

Regards,

 

[carmantr]

Maggie,

Don't know if this will help, we are on OW XE Upgrade 5 SP20.

We had a lot of problems with ship confirm lock up espc. when pick slips was running (R42520). We installed ESU JD22282 and the problem was solved.

This is a list of the objects on the ESU:

B4102150 Item Master Real Time Event Notify - ESU ONLY
B4200370 Commit Sales Order To Inventory
B4200380 Inventory Availability And Commitment
B4200810 Load Or Unload Ship Confirm Cache
B4200920 F4211 Get Shipment Info
B4901400 Shipment Notice Real Time Event Notify Function ESU ONLY
X4111Z1 Inventory Transactions
X4114Z1 Inventory Issues/Adjustments

D4102150B Item Master Real Time Event Notify Load Data - ESU ONLY
D41B0160J Calculate Std. Cost Variance GainLoss
D4202100 F41021 Rollback Commitments
F41021WF F41021 Transaction Workfile
V41021WF F41021 Transaction Workfile - All Columns

N4101070 Update Item Process Data
N41B0160 Verify and Get Bulk Information 10 Functions
N4200790 Shipment Confirmation 7 Functions
N4202100 F41021 Commitments Processing

P4690 Warehouse Speed Group Maintenance
R42210 F41021 Commitments Recovery
R4690 Update Process and Item Dimesinsion Groups
R47091 EDI Request for Quote Edit/Create

B4102153 GetMathCurrencyCode
D3800110B Agreement Quantity Search Ship Confirm
D4102150F All F4102 Fields Change Check
D4102153 GetMathCurrencyCode
N3800111 Agreement Quantity Search Ship Confirm
V4102XPI2 XPI F4101/F4102 Join Business View Enhanced

Hope you get is solved.

/Chuck

 

[peter_hamilton]

Hi,
I think this is the way to solve this problem. I assume that it has starting locking after you have added transaction processing to P4205.
I had to do this about 3-4 years ago, to get around the same problem.

in Xt4111z1, add:
If called from P4205
JDEDBReturn =3D JDB_InitBhvr ( (void *)(lpBhvrCom), &hUser, (char *) NULL,
JDEDB_COMMIT_AUTO ) ;
Else
/* std*/
JDEDBReturn =3D JDB_InitUser( (HENV) lpBhvrCom->hEnv,
&hUser,
"XT4111Z1",
JDEDB_COMMIT_AUTO );
End if

The problem seems to be that the jdb_inituser issues a different connection to the db, and thus we get record lokcing.

 

[sselman]

Re: RE: Ship Confirm Record Locking Problems

Boy, if it is that simple to fix, I wonder why denver never addressed it....

 

[magpie]

Zoltan..thanks for recommending that documentation. It has been a nice refresher since the DB classes I took in college were a "few" years ago.

Sean...thanks for the suggestions. We might very well go with some sort of custom form.

Craig...adding the additional line at ship confirm has been working flawlessly for us since 732.1. If it hadn't, I've no doubt our accounting manager would have been all over it (as she is all other JDE integrity issues!).

Peter...this is out of the box, completely unmodified P4205.

Thanks for all the comments...I'm certainly open to more.

Maggie