SAP EM - Events from Carriers that are Expected but with bad Locations

[Former Member]

Scenario: A carrier sends the Departure event through EDI and it is converted into a EVMSTA IDOC. The departure location provided by the carrier IS NOT the internal location ID within SAP EM. Through the event handler ruleset the event is sent to SAP TM FO and fails to propagate to FUs because the stop location does not match any stop within SAP TM.

What is the best way to get around this issue? Is custom development required to propagate the event without considering the stop location? If so, where is this done and is this the best approach?

The following is required:

1. The event must be reported on the FO handler.

2. The event needs to be propagated by the FO to the FUs within TM.

3. Once the event is propagated to the TM FU it will then be posted to the FU handler.

Thanks in advance for your guidance.

[Former Member · Accepted solution]

Hi Jacob,

If you know all the locations from carrier before hand, you can utilize the external and internal location code config ( EM->Event Handlers and Event Handlers Data->Codes->Location Codes and Partner Codes->Define Location Codes and how they are mapped ).

Other option is to use the pre-processing functionality where you can replace the location code on the event with code which is on the Expected Event ( EM->Event Messages, Status Queries, Web Interface and OData->Define Criteria for Event Message Processing). You can store carrier sent location in a message parameter.

If you use this option, for multiple legs with multiple expected events, you need to add little more logic to find the corresponding EE for location code and with few assumptions;) that the carrier is sending events as they happen and not out of sequence.

Thanks,

Vishnu

[Former Member · Accepted solution]

Vishnu,

Thanks for the response.

1st Option: Maintaining the carrier locations even if we had them doesn't seem to be that practical. There would just be so much data maintenance involved with this option.

2nd Option: I'm not familiar with this Preprocessing Functions configuration. So I would configure the same as the standard Delay event with all '*' values? Then use the function module to update the location to match the expected event location?

[Former Member · Accepted solution]

Hi Jacob,

Yep, for message pre-processing, you can use Delay as reference. You will have event code( es_evm_tables-header-int_ev_cod  ) which is getting posted. You can use this event code and corresponding expected event and copy that location. When you get the expected event try to see if it's already reported or not from /SAPTRX/EH_EXPEV-EVENT_STATUS and sort by dates so that you will pick up the next unreported expected event location if it's multi stop.

Just a note: During testing, if you keep reporting the same event for same location, it will pick up next location based on coding.

Thanks,

Vishnu

[Former Member · Accepted solution]

Forgot to add:

Use sender code set and sender code id to restrict the events from this logic. If use *, the event will hit pre-processing FM and it doesn't matter who is reporting the event. For example, if you manually report from TM document, it still goes through the pre-processing logic which is not required.

Thanks,

Vishnu

[Former Member · Accepted solution]

In addition the events are coming back to SAP EM through EDI 214 to be converted into EVMSTA IDOC. From what I can tell the EDI 214 doesn't even have a location of the EM/TM internal location numbers, correct? So the carrier couldn't even send it to us if we provided it to them?? The 214 EDI appears to send back City, State, Country. How will this map to the EVMSTA (loc1)??

[Former Member · Accepted solution]

Hi Jacob,

If you don't have multiple locations per city, just a thought, you can use City itself as LOCID1 and LOCCOD as EDI214 ( or something ). They will become your external locations.

Now you can have external to internal locations config with internal being your expected events locations ids.

But if you have multiple locations per city, then you should have additional pre-processing to figure out apart from having the external/internal config.

Thanks,

Vishnu

[Former Member · Accepted solution]

Hi Jacob,

As you said, if the carrier is going to send address then try below things.

1. Create Location determination custom table and define city, state and country.

2. Assign Unique ID as for each row or if one location id used by multiple address location then create LOC*.

3. Create custom functional module and call this custom table to validate.

4. Use Preprocessing program to post this event based on address fields value.

Check and let me know.

Regards

GGOPII

[Former Member · Accepted solution]

Vishnu,

As part of the preprocessing function is it possible to look up the Expected Events for the given FO and then extract the location. The developer I'm working with said it's not immediately available when referring to the 'Delay' function module.

[Former Member · Accepted solution]

Hi Jacob,

In pre-processing you do not have model directly available. You can do select on /saptrx/eh_expev table using the TRXID which will most likely be your application object id ( FO Number ) or your System Parameter if you have FO number as you system parameter.

I prefer system parameter with FO number indexed for performance.

Your logic will look something like this:

READ TABLE es_evm_tables-header REFERENCE INTO lr_evm_hdr INDEX 1.

select ( req fields ) from /saptrx/eh_expev inner join on ZYOUR_SYSTEM_PARAM_TABLE as b

on /saptrx/eh_expev~eh_guid eq b~eh_guid into table lt_expev

          where FO_NUM eq  lr_evm_hdr-trxid. " FO_NUM is from system parameter table

Let me know if your developer needs more help and I can send the logic but let me know which table you want to use ( /SAPTRX/EH_HDR or System Parameter table ).

Thanks,

Vishnu

[Former Member · Accepted solution]

Vishnu,

So it would seem for Unexpected Events I'll also require a TOR stop location to be on the document otherwise within TM (when the event is sent from EM FO to TM FO) I get stuck in the queue with 'No matching stop found for location' even if I've got an assigned "stop" category within TM... Does this make sense?

Why does the TOR document require and unexpected internal location code in order to propagate the event from EM FO -> TM FO -> TM FU -> EM FU??? It's "unexpected" why would locations need to exist? Am I just crazy... haha

[Former Member · Accepted solution]

Hi Jacob,

I just posted an unexpected without location and have no issues( screen shot). I am guessing your TM event config might be an issue.

Can you let me know what transportation activity and stop category are you using? (TM->Integration_>Tracking and Tracing of prcocesses and Docs>Define Transportation Activities)

[Former Member · Accepted solution]

Unexepected "Departure" event with Stop Category = O Stop with Change of Main Resource - Outbound

[Former Member · Accepted solution]

That's the issue. I changed my event config to look like delivery event and I posted an unexpected event without location and see what it did. I have 2 events now( propagated and read ). Propagated shows up with location.

So, for unexpected events, change the config to Tras. Act to 99 and leave the stop category as blank. It will resolve your unexpected events issue which we had all these days:)

For expected Events which are coming as with different location, make sure pre-processing is picking up the location from planned events(expev).

Thanks,

Vishnu

[Former Member · Accepted solution]

Vishnu,

You are correct I now get "Propagated from SAP EM" and that's the only event I have; however the event is not propagating from the FB to the FU. I'm pretty sure this is because there is no assigned stop category.

[Former Member · Accepted solution]

Yeah, I didn't notice as I am doing resend to FU EH from FO EH. Let me see if I can find a solution for this scenario.

Thanks,

Vishnu

[Former Member]

Hi Jacob,

I have tried few things and nothing's helping. There is a hard check on stop id in TM class /SCMTMS/CL_TOR_A_PROC_EXEC which prevents propagation for Trans. Act = 99 and stop category = blank.

So, 2 options

1) Use RESEND ( RESEND MULTIPLE ) activity to send the event to FU ( propagate from EM rather than propagate from successor ) - preferred option which I use too.

2) Add location id to all events in pre-processing. It's a messy business if you have lot of events but still works( or consider message badi which was replaced by pre-processing config and is independent of event code ).

Thanks,

Vishnu

[Former Member]

Vishnu,

Well it's good to hear that I'm not crazy!!

Now I don't mind the RESEND_MULTIPLE being used and just keep the events within EM, however the issue we have is that require the TM FO/FB TOR_TYPE to be a parameter on the event message...

So, is there a way we can:

1. Get the FO/FB TOR_TYPE on the EM handler as a control parameter upon handler creation?

2. When an event message come in when/how would add that control parameter to the event message?

3. My idea is then the logic in the FU handler to look at the TOR_TYPE parameter on the event message wouldn't have to change.

I really can't think of any reason for me to propagate our events to TM if we can just get the TOR_TYPE on the handler upon creation.

[Former Member]

Hi Jacob,

You mean to say:

Add FO/FB Tor_Type as a parameter on FB/FO Event Handler and add this parameter to event message which is reported on FO/FB?

If yes, I can send you logic in a bit when but just a suggestion: System parameter will be better option instead of control parameter for TOR_TYPE.

Let me know and I will send you info.

Thanks,

Vishnu

Message was edited by: Vishnu Cheeti

[Former Member]

Vishnu,

You are correct:

1. Is it possible to pull down the TM FO Tor_Type down into the EM FO Handler? If it's a system parameter will it be available for use to add it to the event message let's say in the ZRESEND_MULTIPLE activity function?

2. Where on the event message would you suggest we add the TOR_TYPE?

3. Can I use standard activities in the FU ruleset to refer to this event message TOR_TYPE and put it on the FU handler as a control parameter? (We will then use the control parameter in further rule processing...)

[Former Member]

Hi Jacob,

Step 1: Add the following code to your FO/FB control parameter extractor:

*   Tor Type

"ls_control_data-paramname = 'TOR_TYPE'
ls_control_data-paramname =  /scmtms/cl_scem_int_c=>sc_control_parameters-bo_tor-tor_type.

ls_control_data-value     = <fs_tor_root>-tor_type.
APPEND ls_control_data TO e_control_data.

Step 2: If you have system param table ( EH header extension ), add TOR_TYPE as a field. If not

Step 3: Goto EH->PARAMTERS->Define system parameter ( Z<prefix>_TOR_TYPE) and select your table field from Event Handler header)

Step 4: Goto EH->PARAMTERS->Define Mapping Profile. goto your mapping profile and add

Source = TOR_TYPE and Target as Z<prefix>_TOR_TYPE

This will create system parameter on your FO/FB EH.

------------------------------

To your question: If it's a system parameter will it be available for use to add it to the event message let's say in the ZRESEND_MULTIPLE activity function?

System or control, You have to do in pre-processing if you need to add it onto Event message.

"2. Where on the event message would you suggest we add the TOR_TYPE? "

Without knowing your project, I will say Message extension table. May need little logic for message extensions while resend ( let's revisit when we get there ).

"3.Can I use standard activities in the FU ruleset to refer to this event message TOR_TYPE and put it on the FU handler as a control parameter? (We will then use the control parameter in further rule processing...)"

Pre-processing is the best here if you need TOR_TYPE as control on FU but can be done.

Thanks,

Vishnu

[Former Member]

Vishnu,

I now have the TOR_TYPE on the FO/FB handler by adding the logic to the control parameter extractor.

Question 1:

Are "Steps 2 - 4" required? It seems to be working without these steps. In our solution we have not done any "mapping profiles" for parameters. I do maintain the parameters so that I get a description in the handler when the extractor uses the parameter. But do I "need" to be doing some sort of parameter mapping up under the handler settings?

Question 2:

I'm going to go back to our developer but I believe he told me that he didn't see any of the control parameters available within the pre-processing. I'm guessing this is because he needs to go look for them on the handler, correct?

Clarification:

So now that we have the TOR_TYPE as a control parameter within the FO handler we can add it to the event message via the message extension table, correct? I'm not very familiar with the message extension table at this time but it looks like I may need to learn. But then when the message hits the FU handler how from the resend will I be able to pull out the TOR_TYPE from the message and assign it to a control parameter? Or even in the rules can I refer to the TOR_TYPE as part of the extension? How would I do this using the config ruleset activities? haha

[Former Member]

Hi Jacob,

If it's working, then you are good and no need for additional mapping or steps. Is it showing in control or system tab?

For question 2, you need the do the same thing as we did for EXPEV.

READ TABLE es_evm_tables-header REFERENCE INTO lr_evm_hdr INDEX 1.

select tor_type

          from ZYOUR_SYSTEM_PARAM_TABLE

  into lv_tor_type

          where <FO_NUM> eq  lr_evm_hdr-trxid. " FO_NUM is from system parameter table

This will give you your parameters. If it's control parameter, then do select on /saptrx/eh_cntrl

For your clarification:

If you add it as a control in  EVM_PAR_STRUCTURE in pre-processing, these will be available in RESEND as well and will go to FU as control paramters as well. You might not need any additional logic. Just "Parameter update new" activity in your FU ruleset.

Thanks,

Vishnu

[Former Member]

Vishnu,

When you say: "If you add it as a control in  EVM_PAR_STRUCTURE in pre-processing, these will be available in RESEND as well and will go to FU as control paramters as well. You might not need any additional logic. Just "Parameter update new" activity in your FU ruleset."  I'm not certain this will work for us but let me try to give you some more clarification.

For preprocessing we have the function executing for events that are sent to 'TOR_TEC' codeset (all of our events will be reported to the FO/FB only). During the preprocessing we are able to see the FO TOR_TYPE that is now a control parameter on the FO Handler. Isn't the 'EVM_PAR_STRUCTURE' apart of the event handler itself not the "event message"? My initial impression was that we would need to put the TOR_TYPE on the event message somewhere and then one of the following would need to happen:

1. When the message is sent from the FO handler to the FU handler and then processed by FU Handler ruleset we "might" be able to add the FO TOR_TYPE from the event message to a control parameter on the FU. (I like this one better but is it possible to add to event message the TOR_TYPE of the FO and then use a standard rule in the FU handler to update a FU control parameter??)

2. We create an additional preprocessing function that will execute for events with 'FU' codeset. In this function the FO TOR_TYPE is taken from the event message and stored as a control parameter on the FU handler. (This option wouldn't be that bad either but again where should we put the FO TOR_TYPE information on the event message so that it can be used during the FU event preprocessing??)

3. Not sure if this option is possible. Would it be possible that when processing the TOR_TEC preprocessing we can directly add the control parameter to ALL of the FU handlers within the FO/FB?? Is this a good option or is it better to do option 1 or 2?

At the end of the day we require the TOR_TYPE on the FU handler to represent the last FO/FB TOR_TYPE  in which an event was reported. This is because 1 FU may be a part of multiple FO/FB document types.

[Former Member]

Hi Jacob,

I mean't ES_EVM_TABLES-PARAMETERS table in pre-processing function.

i.e EVM_PAR_STRUCTURE  = ES_EVM_TABLES-PARAMETERS.

Since you added it as control parameter in FO/FB, all you need is this logic:

--------------------------------------------------------------------

FO/FB side logic:

1) Event is generated

2) Event hits FO/FB Pre-processing. Here add your TOR_TYPE  to ES_EVM_TABLES-PARAMETERS with same index number. This is so that when you resend to FU, event retains TOR_TYPE in parameter structure. Reason for same index is not to create duplicates in FO/FB.
3) FO/FB ruleset with RESEND to FU

FU Logic:

1) Add PARAMETER_CHANGE_NEW activity in ruleset.

----------------------------------------------------------------------

If you summarize it, it's your option 3 which is easy and it's control parameter on your FU as well rather than message parameter which should be OK. If you need this to be a message parameter on your FU, then you need additional FU Pre-processing to convert the control parameter to Message Parameter in ES_EVM_TABLES-PARAMETERS.

Let me know if it's confusing.

Thanks,

Vishnu

[Former Member]

Vishnu,

Thanks again for all of the help on this matter. We appear to now have the TOR_TYPE coming to the FU handler through the event message parameters. AND, I'm RESENDing from the FO/FB handler to the FU handler. This take the frustrations of the TM propagation out of the picture. The only event, unfortunately, that we seem to require goes to TM is our 'Transportation Request Created' event. This event is triggered when the FO/FB is created. Right now our logic reports this event within the Actvt 2 function of the FO/FB handler. The issue seems to be that it's not going through the prepocessing function like the rest of the events when reporting through IDOC...

Question/Clarification:

Do you have some more insight on how to not duplicate the TOR_TYPE control parameter on the FU handler? Each time the event message reports on the FU it adds another TOR_TYPE control parameter.... :S

[Former Member]

Vishnu,

Additionally do you have any idea why the parameter table is starting with an initial value during preprocessing?

[Former Member]

Hi Jacob,

This looks like a bug to me. When you build/prepare event for posting ( before BAPI Message Post ), I guess there might be an empty append to parameter structure ( or with just evtcnt ).

How are you triggering the event? WEBUI/IDOCS/XML/ZREPORT ? Check at the source level for this bug.

Thanks,

Vishnu

[Former Member]

Hi Jacob,

To avoid duplicate, always use parameter index = 1. This will make sure you do not have duplicates.

For the question on "Transportation Request Created".

All events should go via pre-processing. Somehow/somewhere I came across or heard similar thing in the past but not sure what we did.

Anyway what was the original reason of creating this event in UA2? Can you move it back to Event types as you seem to resolve lot of issues around stops/propagation/resend/parameters.

Let me know if you still need UA2, then I can go ahead and try to think of a solution for this.

ALso, for your previous thread question of empty parameter, check the IDOC and see if there is a empty line is the parameter segment.

Thanks,

Vishnu

[Former Member]

Hi Vishnu,

When you say always make sure index = 1. Does this mean I also need to specify parameters in the 'PARAMETER_CHANGE_NEW' in order to stop duplicates?

[Former Member]

No need. For FO/FB EH, you can add index 1 in the control parameter extractor on AO Type. For FU, just add 1 to param_index in your screen shot in pre-processing.

Message was edited by: Vishnu Cheeti

[Former Member]

Vishnu,

Events seem to be flowing pretty well now. We have move back to the Event Data for the ZTREQ_CREATED event that is to be reported upon FO/FB document creation. The event appears to report now on the FB/FO handler and then on the FU handler; however after this event is report no other events will report... We are getting an ST22 (CX_SY_OPEN_SQL_DB) execption... I also notice that the ZTREQ_CREATED event is not putting the TOR_TYPE on the FU event handler.... Not sure why because it should go through the preprocessing and then add it.

Beyond the above concerns I do have this question; is it ok in the FU ruleset to have the 'PARAMETER_CHANGE_NEW' activity first with no prior checks? This wouldn't be causing any issues would it? I mean if there aren't any parameters to update it won't do anything right?

[Former Member]

Hi Jacob,

1)

Since you moved ZTREQ_CREATED to Event Type, you can directly add the TOR_TYPE here itself in

CT_TRACKPARAMETERS and you don't need pre-processing for this specific event.

Here is the code:

LS_par-EVTCNT = CT_TRACKINGHEADER-EVTCNT " shud be same as your ZTREQ_CREATED "evtcnt.

LS_par-PARTYP = 'C'

LS_par-PARAM_NAME = '<Yor Par Name >'.

LS_par-PARAM_INDEX = 1.

LS_par-action = 'C'.  " Might not need it but check it try between S and C as actions.

append ls_par to CT_TRACKPARAMETERS .

2) Now you can remove your pre-processing config for this event code unless you have other functionality.

3) Yeah, you can have PARAMETER_CHANGE_NEW even if there are no changes to add. If there are no entries, no harm is done but very very little issue with the performance.

Let us know what kind of ST22 it is, if you haven't figured out.

Also, Were you able to resolve events not showing up in FU Execution but showing in FU EM?

Thanks,

Vishnu

[Former Member]

I forgot the PARAM_VALUE in my previous post.

Please pass the TOR_TYPE to this field.

[Former Member]

Vishnu,

Again thanks for the response. I'm aware that we could add the parameter in the Event Data logic but shouldn't this be going through the preprocessing logic? Is there any reason it may not be going through the preprocessing logic? When you send events through Event Data is preprocessing logic executed?

The Error:

DBSQL_DUPLICATE_KEY_ERROR (CX_SY_OPEN_SQL_DB) within program /SAPTRX/SAPLEH_FUNCS.

[Former Member]

Hi Jacob,

The primary reason I think is sndcod/sndid mismatch in Event values and pre-processing config.

Check the fields trxcod, sndcod, sndid from /saptrx/evm_hdr and compare it with your config for that event. If they do not match, then it won't pre-process.

Check and let me know.

Thanks,

Vishnu

[former_member186607]

Hi Jacob,

it would be interesting on which DB Insert the short dump occurs. If I understand correctly you are using the RESEND activity to send the event message as well to the FU event handlers, right? You must ensure that the event message is not processed again by the FO/FB event handler by the RESEND -> this will definitely lead to a DBSQL_DUPLICATE_KEY_ERROR short dump! This meand the new tracking ID must only match the FU EHs and NOT the FO/FB EHs.

Best regards, Daniel

[Former Member]

Daniel,

Doing some debugging it looks like the dump is occurring on table l_task_ins during /saptrx/eh_update within the FU AOT. These tasks appear to be the EH rule tasks. Interesting that this would be dumping. Any ideas?

I've confirmed that my resend in the FO is not doing a resend back to the FO but rather to the FUs as expected.

[Former Member]

Hi Jacob,

Can you split this dump issue into a different thread so that SAP can also pitch in? This thread is too big now:) rest of the community stopped following it I guess. Let's keep this thread for pre-processing and transferring events questions.

Also, can you add the resend activity screen shot. Just want to see the trxcod value to this activity.

For the sake of narrowing it down, try a test without resend activity and with resend activity. Then we will know if the dump is due to resend or not.

Thanks,

Vishnu

[Former Member]

Vishnu,

Good point please refer to

I have laid out the scenario.

[Former Member]

Hi Jacob,

Were you able to check the pre-processing values based on my last note?

Thanks,

Vishnu

[Former Member]

Vishnu,

I did some debugging and it looks like the ZTREQ_CREATED is going through the preprocessing logic after the Event Type trigger.

The issue is that we have a section of code that is stopping the processing, apparently when the TREQ_CREATED event is processed lt_control must be Initial...:

*Get the Event Handler data.

     CALL FUNCTION '/SAPTRX/BAPI_EH_GET_DATA'

       EXPORTING

         activeonly        = 'X'

       TABLES

         requestids        = lt_req_id

         expectedevents    = lt_ee_data

         controlparameters = lt_control

         bapireturn        = lt_bapiret_em.

IF lt_control[] IS NOT INITIAL.

*Populate the info parameter for last trigger event location.

       lt_param =  es_evm_tables-parameters.

       SORT lt_param DESCENDING BY seq_num.

       READ TABLE lt_param INDEX 1 INTO lwa_param.

       IF   lwa_param IS NOT INITIAL.

         lv_seq_num = lwa_param-seq_num.

       ELSE.

         lv_seq_num = 0.

       ENDIF.

*Create custom Control parameter.

[Former Member]

Hi Jacob,

I did not understand the question but do you mean't to say that you are not getting parameters here in pre-processing. Please let me know.

Also, 2 things here:

1) Using /SAPTRX/BAPI_EH_GET_DATA in pre-processing is bad for performance.

Use direct select's ( joins if required ) for the tables instead.

2) Try not to build any sequence numbers. Just build index numbers and let system take care of sequence numbers.

Thanks,

Vishnu

[Former Member]

Vishnu,

I've informed my developer of your points. What I was saying that is when the TREQ_CREATED comes into preprocessing to pick up the 'TOR_TYPE' parameter it is not getting added because the 'EH_GET_DATA' is coming back with no control parameters on the FO event handler.

[Former Member]

Hi Jacob,

I think it's timing issue between EH commit and your pre-processing. What I mean is even before your EH data is created in database, your event pre-processing is trying to read the data which might not yet be committed to database.

See if your selects on EH_CNTRL will help after you replacing the /SAPTRX/BAPI_EH_GET_DATA. If not then better to build those parameters in Event Type itself for this ZCREATE event atleast.

Let me know if it helps.

Thanks,

Vishnu

[Former Member]

Vishnu,

I was actually figuring you'd come back and suggest the Event Type adding of the parameter. We implemented the "select" logic and confirmed that the control parameters and expected events table are not committed for the ZCREATE event so we implemented the TOR_TYPE back into the Event Type.

The issue is we are getting a dump though when we unassign the FO and then replan it. We get a duplicate key dump on table '/saptrx/eh_evmsg'.

If I have the following code commented out everything works; is anything you notice in this code that could be wrong or causing the issue?

lwa_trackparameters-partyp      = 'C'.
lwa_trackparameters-param_name  = 'Z_TOR_TYPE'.
lwa_trackparameters-param_index = '0000000001'.
lwa_trackparameters-param_value = <fs_tor_root>-tor_type.
lwa_trackparameters-action      = 'C'.
APPEND lwa_trackparameters TO ct_trackparameters.

[Former Member]

. I must admit that your dumps are unique and hard to resolve without actually seeing it myself .

Don't know why parameters are causing SAPTRX/EH_EVMSG dumps though. That's strange.

What's the value of EVTCNT in the trackingheader and trackingparameters? I do not see it in your code.

Also, not sure what happens during replan but can you check if anything retained in the Event Type structures after replan.

Thanks,

Vishnu

[former_member186607]

Hi Jacob,

the dump because of duplicate entry in /SAPTRX/EH_EVMSG indicate that one event message is processed twice for the same EH (because key of this table is EH_GUID and MSG_GUID).
It is hard to analyze how this can happen w/o system access and debugging...

What definitely should not be done is calling the EM BAPIs in your own coding of the event extractors - the communication from application system to EM should be handled completely by the EM application interface of the application system.

Best regards, Daniel

[sukumar_perumalsamy]

Hi Jacob,

few options for carrier  event reporting .

1) Use default EM location mapping if carrier  execution is meant for fixed location deliverable.

2) Ask carrier partner to report the events with location information , TM internal location information available in TM ES TransportationRequestConfirmation_Out, this option is viable only if you  sending the order information to carrier using TM ES .

Use ship from  location for departure event and ship to location for arrive events.

     <ShipFromLocation>

       <InternalID>source location </InternalID>

<ShipToLocation>

  <InternalID>destination location</InternalID>

3) Use EM prepossessing or IDOC enhancement spot to populated the default location information apply the custom logic in enhancement using event code and carrier number ( available at EH system or control param )

/SAPTRX/BADI_EH_S  .

4) un-check the "Check Location" check box in Expected event profile ->event item , to ignore the location validation for all event reporting.

thanks and regards

Sukumar

[Former Member]

Sukumar,

Thanks for the information.

Option 2) This would be ideal however the standard 214 doesn't really have a place for our internal location IDs. Locations on a 214 seem to be City, State, Country.

Option 4) Will unchecking this box mean that the expected event will always be reported? Then propagated to TM with the real internal location ID? What happens if there are multiples of the expected event with different locations?

Thanks again for the advice.

[Former Member]

Hi Jacob,

Asking Carriers to enhance their EDI's for a customer is close to impossible unless they are small carriers and involves cost based on my experience.

For option 4, removing location match is a big no no unless you have only one expected event of each kind (event) like only one departure, one arrival and so on.

If you have multiple planned events based on your legs, then you should have Location or Partner or Dataid check to make it unique when a event is posted.

If there is matching check, and lets say you have 2 Departure planned events. If you post one Departure event, both the planned departure will be reported.

For the sake of testing, you can remove location matching and test it out. You will know the difference:)

I suggest pre-processing route.

Thanks,

Vishnu

[Former Member]

Also, sometime back I posted this info in linkedin for one of the similar question. It had more info.

SAP Event Management. Alternative to Posting Location codes via EDI 214 to post events | LinkedIn

[Former Member]

Vishnu,

This is a helpful article however I don't think extracting "City" for example as a location rather then the location ID would not allow for standard propagation to TM FO/FB and over the FUs, correct?

[Former Member]

I haven't tested it lately after 9.0 but I guess you may be right. I will check and let you know.

Thanks,

Vishnu

[sukumar_perumalsamy]

Hi Jacob,

Option 2 : it depends on the how you adopt the process methodology , basic key data for event posting is  event code , event location , date and time and reason. reporting event without the location is meaning less and it requires additional development in pre-processing and badi's.

Option 4 : suits well for expected event posting with single stage execution and it requires additional custom validation based on the event reporting process model aligned with business SLA's.

i won't recommend this step for multistage execution.

you can use IS_EVENT_REPORTED activity in rule set  for unexpected event and quit the event message processing after validating the IS_EVENT_REPORTED.

~Sukumar