My Oracle Support Banner

E1: 40R: Split Shipments Against a Single Demand Detail Record Causes Orphaned Shipment when Quantity is Reduced in P40R10 Demand Detail and One Shipment is Confirmed in P4915/P4205 Shipment Confirmation (Doc ID 2993106.1)

Last updated on DECEMBER 14, 2023

Applies to:

JD Edwards EnterpriseOne Demand Scheduling Execution - Version 9.2 and later
Information in this document applies to any platform.

Symptoms

If there are multiple sales order lines against a single demand detail (F40R11) record with 2 shipments and the demand detail quantity is reduced either manually or due to a new release coming in, after ship confirming the first shipment line the second shipment line will become orphaned because all of the available quantity in demand detail gets consumed and the (F40R11) demand detail record gets deleted and moved to the F40R41. CUMs will not be adjusted in F40R12 for the 2nd shipment, and the ASN will be missing the Demand Detail related field in the ASN (F470371).

Replication Steps:

1) P47171. Create EDI data and send in a quantity of 21600.
2) R47171. Run R47171 to create the demand.
3) R40R010. Run the UBE to create the sales order. For the customer this is a scheduled job.
4) P40R10. Go into demand detail and increase the quantity to 43200. This is to simulate an automotive client sending in an EDI change to the original demand request to increase.
5) R40R010. Run the UBE to update the sales order. Note the same shipment was used.
6) P4210. Go into the order detail and change the scheduled and promised times for the 2nd line and click OK. This is to force line 2 onto a separate shipment to simulate the customer Transportation setup where separate shipments are used. Note the demand key is the same for both lines in the F4211.
7) P4915. Approve both shipments. Note the order statuses are at 527/560.
8) P4210.  Set the Status Code Limit for Changes processing option to 540 as the customer does want any changes after the shipment is approved.
9) P40R10. Go into demand detail and decrease the quantity to 21600. This is to simulate an automotive client sending in an EDI change to the original demand request to decrease as the original increase was a mistake.
10) Run R40R010 again so the demand detail is less than what is on the sales order. The sales order will not change because changes cannot be made past status of 540. For the customer this job is scheduled and it impossible to control when an automotive client changes demand requests.
11) P4915/P4205. Confirm the one of the shipments.
12) P40R10. Check the demand detail and note it has been deleted. Check F4211 and demand key is still populated.
13) P4915/P4205. Confirm the the other shipment as it is still open.
14) Check the F4942 and the shipped quantity shows as zero.
15) Check the F40R12 and only the first shipment is shown and there is no record for the 2nd shipment. This causes the CUM to be off by -21,600.

Changes

 

Cause

To view full details, sign in with your My Oracle Support account.

Don't have a My Oracle Support account? Click to get started!


In this Document
Symptoms
Changes
Cause
Solution
References


My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.