• Introducing Dark Mode! Switch by clicking on the lightbulb icon next to Search or by clicking on Default style at the bottom left of the page!

Strange Direct Ship Error in Credit Memo processing


Reputable Poster
Hello All,

We have a new error that showed up late last week in our batch stream for credit memos. The text below shows up in workcenter for the R42565 and R42800 when credit memos are processed. I narrowed it down to CM document types and CM line types.

Cause. . . . . Errors were encountered when assuring order integrity between
sales order 121253 CM 00001 , line 1.000 and
purchase order , line .000 .
Resolution . . Please review the following errors to determine the source of
the integrity issue. The purchase order will need to be
manually updated to maintain integrity with the sales order.

Our CM line type has an inventory interface value of D, but it has that value in PY as well so it is not new. Also, the lines with CM line type have SO11 as a 2, but they have had that value previously. I compared the processing options from the R42565 job that ran last night with one from last month and there are no differences.

It is not affecting the actual posting or updating of the transactions which is good.

Does anyone have any suggestions as to where else to look for a setting that could be affecting this process?

Thank you,



Legendary Poster
Yeah, table event rule on F4211 update. Calls B4201310 when a transfer/direct ship/interco (SO11 is 1,2,3) to ensure the data is consistent across the related PO and SO. In some cases, the buffer holding the record image doesn't contain all the column values so it passes a blank and zeros for the related order. TER's can be fussy. That or the related order info is indeed blank on the SO



Reputable Poster
Thank you for the reply, Craig. It points out a flaw in my original post. We don't have a related PO for these CMs. I surmise we are using the D interface to keep them from affecting inventory. They are a sales only document. As you point out, SO11=2 should have it look for the related PO. Given that we have had D interface and SO11=2 in the past, it acts like some other component/flag/switch has changed to cause this error to show up. We haven't done any code changes and I don't know of any business process changes given our reduced staff in JDE.


Reputable Poster
Turns out this is a case of trusting the user - she is a long time detailed user, so she merits trust - and not checking that it is new behavior. We have been getting these messages all along due to Line Type setup of D with Generate PO unchecked. Seems like some new behavior may be in work center presentation of the errors.