Sales Person on EDI Sales Orders

[RogerH]

I'm having problems identifying how to populate the sales person via a EDI order.
My client is currently migrating from XE to 9.1 and I'm aware that the sales person has been moved from F4201 and F4211, SLSM and SLCM are stored in the Commission Header (F42150) and Commission Detail (F42160).
When an order is taken via EDI, my client is currently using F47011 & F47012 in XE, they are populating SLSM as this is an available field. This field is not available in 9.1, any ideas how to populate?

Thanks

Roger

 

[JMast]

Roger,

I am assuming that you are talking about inbound EDI POs that you are processing into Sales Orders in JDE.
My first question would be does the salesperson truly come in on the EDI PO and could be different for a given customer from PO to PO? Where I am headed is why not just let JDE apply the sales rep(s) defined on the customer address book records? I know I don't know nearly enough about your processes and culture, but I will throw general thoughts at you.

If that is a true requirement, it sounds to me like you may be headed for some serious custom coding in the R47011. You would probably have to understand the logic that happens when a user interactively changes the rep(s) on an order and figure out how to replicate that in R47011 after the order is placed. I don't know the complexity of the JDE commission process when a change is made since we have a custom commission process. We do, however, have some code to handle some small updates we need on the SO after the order is placed.

My recommendation would be to look at how often the incoming rep is different than what is on the address book. If possible, find an unused field on the F47011 to hold the rep. You can use this value to compare against the address book rep. If there is not a match, print it as an exception. A user can then see it on the exception report and go into JDE and make the necessary changes to the SO interactively.

I know that EDI is supposed to be automated and manual processes should be avoided. However, there are times where JDE simply does not provide an option without significant code change which can be more risky and expensive for initial development, future process change, and future ESU/upgrades than manual processes that don't take a user much time.

Which circles me back to understanding what the requirement truly is for this situation.

Jer