Why R47011 (EDI Inbound Purchase Order Edit/Create) and P4210 (Sales Order Entry) set different PDDJ (Scheduled Pick Date) when Promised Shipment Date is to be computed during Transportation interface?
Refer to below knowledge documents on detail,
Note
This issue is fixed using <Bug 25610951> - SHIPMENT STATUS NOT UPDATED PROPERLY WHEN MULTI ORDER CONSOLIDATION IS TURNED ON. Note that the description of this bug is very much different from what this case study discusses.
A1> Direct reason for different dates (where the outcome from P4210 is correct) is that the End Doc routine fails to gets data on below query,
SELECT * FROM PRODDTA.F4942 T0,PRODDTA.F4211 T1 WHERE ( T0.ISSHPN = 4007457.000000 ) AND ( T0.ISKCOO = T1.SDKCOO AND T0.ISDOCO = T1.SDDOCO AND T0.ISDCTO = T1.SDDCTO AND T0.ISLNID = T1.SDLNID )
: Note that the simple join between F4942 (Shipment Detail) and F4211 (Sales Order Detail File) is based on the primary key of F4211. For this case study, when the sales order is created using R47011, F4942.LNID is set with value 0.
The reason R47011 fails to set F4942.LNID is,
Calling Business function R47011DetailDoSectionProcess from Level 1 for JDE. Application Name [R47011], Version [ZJDE0001] (BSFNLevel = 1)
IN->[ 1] LastLineNumberUsed [0]
IN->[ 2] cKitProcessed []
IN->[ 3] cEdiSuccessfullyProcess []
IN->[ 4] mnEdiDocNumber [321856]
IN->[ 5] OrderNumber [0]
IN->[ 6] szEdiDocCo [00000]
IN->[ 7] szOrderCompany [ ]
IN->[ 8] szEdiDocType [SO]
IN->[ 9] szOrderType [ ]
IN->[ 10] szalphaName []
IN->[ 11] szAlphaName2ndRow []
IN->[ 12] OrderLineNumber [.000] ************* This value sets 0 because F47012.LNID is not specified *****************************
IN->[ 13] mnEdiLineNumber [1.000]
IN->[ 14] mnQuantity [1.000]
...
Note that R47011 runs without issuing any error even though F47012.LNID is not specified and this is functioning as designed likewise P4210 where user does not specify order line number.
A2> The simplified routine which computes the data described in E1: 49: Promised Shipment and Delivery Date Calculation (Doc ID 625513.1) is,
R47011
---| R47011DataBaseUpdateSection
------| F4211FSEndDoc
---------| F4215EndDoc (N4900010, FS F4215 End Doc)
------------| RouteShipment (N4900080, RouteShipment)
---------------| LoadRoutingOptions (N4900200, Load Routing Options)
-----------------| F4950SelectRoutingEntries (B4900400, F4950 Select Routing Entries)
---------------------| VerifyRoute (N4900420, Verify Route)
------------------------| CalculateDates (N4901350, Calculate Dates)
B. Update
---| R47011DataBaseUpdateSection
------| F4211FSEndDoc
---------| F4215EndDoc (N4900010, FS F4215 End Doc)
------------| RouteShipment
---------------| LoadRoutingOptions
------------------| UpdateShipmentRouting
---------------------| UpdateSalesDetailwithRouting
------------------------| UPDATE PRODDTA.F4211 SET SDRSDJ=116077,SDPPDJ=116070,...
Note: this information can be useful when you need to check all objects associated with a certain issue because your Change Assistant allow you to search ESU based on the object listed here.
A3> Then simplified call stack can be,
R47011 (EDI Inbound Purchase Order Edit/Create) which runs based on F47011/F47012 (EDI Purchase Order Header - Inbound/EDI Purchase Order Detail - Inbound)
---| R47011DetailDoSectionProcess (B4700110) which is a wrapper function to call the sales order master business functions (e.g., F4211FSBeginDoc, F4211FSEditLine, F4211FSEditDoc, and F4211FSEndDoc)
------| F4211FSEditLine (B4200311) this function validates the information written in F47012 to validate/defaults and write it into work file F42UI11/F42UI12.
---------| ProcessOrderLine (N4900180) --- this routine comes when SY49 Transportation is ON in P99410 (EnterpriseOne System Control)
------------| ProcessOrderLineAdd (N4900180) the cache for shipment header and detail got initiated from here.
---------------| F4215EditLine (N4900010) which calls cache function below to fetch, add, update and delete
------------------| ProcessShipmentDetailCache (B4900130) *** this is routine to write shipment detail cache which is used in inserting F4942
A4> Then this issue is resolved through It seems likely that your issue is resolved through <Bug 25610951> : SHIPMENT STATUS NOT UPDATED PROPERLY WHEN MULTI ORDER CONSOLIDATION IS TURNED ON. Note that the description of bug is different but actual implementation appears as below,
*** Break In Code B4900130 ***
/* 25610951 - mnLineNumber is replaced with mnWorkLineNumber */
Index->CacheKey[3].nOffset = offsetof(DSD4900130B, mnWorkLineNumber);
Index->CacheKey[3].nSize = sizeof(dsCacheKey.mnWorkLineNumber);
Index->CacheKey[3].idDataType = EVDT_MATH_NUMERIC;
*** End of Code ***
: Without above bug, if the input mnOrderLineNumber is not specified, F4942.LNID remains zero. Through this function, the key for cache will be mnTransportationJobNumber, mnShipmentNumber, mnRoutingStepNumber, and mnWorkLineNumber (without this bug the index for cache - which is identical to the primary key of a certain table - mnLineNumber which is 0 for the cache B490013002).