EDI Inbound 850 - How to deal with one PO that needs to create multiple sales orders


We are on JDE E1 9.2 and have a customer that wants us to implement EDI with them. For us, this would include an inbound 850, outbound 855, inbound 860, outbound 856 and outbound 810.

We are struggling with the initial piece of the inbound 850 because when this customer provides the order details to us, they don't know what type of sales order it is (SA or SO) and they don't know what Branch/Plant we will be producing the material at. It's not as easy as saying that a certain material always comes from one branch/plant because our customer service currently makes the decision based on what is going on at the various plants and which ones have the bandwidth to do the production.

For example, the customer will send a request (one Customer PO) that has 5 detail customer PO lines and it will result in 3 different sales orders for us. Typically we do one sales order per truck load so let's say two of the lines needed to be produced at one plant (one truckload) and 3 needed to be produced at another plant but 1 of the lines represented 1 full truck load while the other two represented 1 full truck load. This is how we'd get 3 sales orders resulting from 5 lines. Since the customer doesn't know the branch plant for the sales order and there is no logic to be built for picking the correct branch plant (since it requires analysis by customer service), how can we use the EDI process (specifically with the 850, 855, and 860)?
Short answer is... there is no short answer.
What is difference between SA and SO order types in your environment?
Do you use Transportation?
You could nominate a default warehouse for all EDI orders (processing options) and let customer service decide the warehouses and the truck splits and then Acknowledge, but then what about Change Orders.
There is also Inventory Commitment Preferences to automatically do this warehouse allocation, but it treats each line independently and is happy to send a 5 line order to 5 different warehouses. Transport can identify orders that will not fit on a truck and need to be manually split. But then someone needs to split them.
Moving to EDI often means that you need to change the way you think, the business rules, the roles people play and the way you use your systems.
E.g. What are the rules for order changes. How much of this can be automated and how much should be?
Sounds like you are already aware of some of the issues, but I think you will find that so many JDE implementations handle this differently and getting the right mix for you and your customers is the real challenge.
I know you will get many of your specific questions answered in this forum, but I would recommend seeking experienced assistance for the overall design and proess change discussions that often need to be had first.
Hope this helps
One option would be to do some customization in the R47002C before the POs become SOs. You can stop the POs from fully processing and do some modifications in Review/Edit EDI Purchase Order (P47010) before creating the sales orders. If your customer service team can define what branch plants each line needs to come from before the order is actually an SO, you might be able to have them update branch plants on the lines. (big assumption here - lines on same SO with different branch plants will still work - haven't tried that).

I have added a custom section to R47002C on the F47011 and F47012 tables that has data selection on EDSP = N and is called in the end section event of the existing section before the call to R47011. This allows me to make any/all customizations I need per customer or scenario before the order is placed. It is very handy. You can even change the EDSP to some other value to set the PO aside for further review. For example, I have a check for duplicate PO number that sets the EDSP to Z. So, the csr sees the PO didn't place and the Z tells them why.

So, if you can define which POs need this type of review, you could either put code in to make the changes or have the EDSP on the PO changed to set it aside for human review.

We haven't automated the 860, so not sure there. 855,856 and 810 I would expect could be made to work with proper statuses, shipment numbers and data selection without much customization.