SAP EM knowledge Bites 5 - Events vs. Messages

In our last blog we discussed the different types of events that SAP EM deals with. Now it’s time to delve a little deeper and look in to event messages as they relate to events. SAP EM makes the distinction between events and event messages. The difference is subtle yet very significant and compelling.

An event is the recording of “something that occurs in a certain place during a particular interval of time”.   An example of an event would be a post goods issue (PGI) occurring in Warehouse A at 3:00 PM (See No. 4 in Figure 1).  A plan for the event is stored in SAP EM, and the event is measured against this plan.  ‘The Plan’ states: ‘the PGI event should happen at Warehouse A between 2:00 PM and 4:00 PM’ (See No. 1 in Figure 1).  In this example, the event is considered a regular event.

An event message provides the detail surrounding the actual occurrence that gets recorded in SAP EM.  When the event message is received in SAP EM, it is processed using the rule set.  The status of the Event Handler is potentially updated to allow visibility of the change to others.  (See No. 7 in Figure 1).  The PGI event message was received at 5:00 PM (See No. 6 in Figure 1), telling SAP EM that the PGI event was raised at 3:00 PM.  In ‘The Plan’, for the event message, a rule stating that the event message needed to be received by 4:00 PM (See Nos. 2 and 3 in Figure 1).  In this example, the event itself would be on time but the event message would be late by one hour.  The last status in the Event Handler would reflect, ‘PGI received late’.

Event message information can, and should, differ from the actual event detail.  The event message information may be very significant in its own right.

Capturing the date and time stamp of event messaging information allows for determination of a partner’s communication compliance in the supply chain, to see if there is a delay in the sending of information (See No. 5 in Figure 1).  Exchanges between Electronic Data Interchange (EDI) partners need to have this information recorded as penalties may be incurred when messages are not delivered on time.

Figure 1: Event and Event Message Relationship Described

Note: Attachments can accompany an event (See Nos. 4 and 6 in Figure 1).  A digital signature can be recorded and attached to the Proof of Delivery event.  SAP EM will then have a record of when the POD occurred together with the business’ signature on file.

The overdue monitor is a scheduled job that looks for planned event messages (See No. 3 in Figure 1) that are late according to ‘The Plan’.  Once an expected event is found to be late, a rule can be configured to update the Event Handler to reflect that an event message has not been received in a timely manner.  (See No. 8 in Figure 1).

Components of an Event Message

An event message is the mechanism to report an event that has occurred.  The message consists of several parts as described below.

• The Event Code – What happened?  Delivery was packed
• Event Date, Time and Time zone – When did the actual event take place? Note: The timezone plays a critical part in SAP EM because it allows the date and time to be “normalized” against GMT. This allows events to be sorted in the sequence in which they occur no matter what the timezone was that the event occurred in. E.g. A Sales Order created at 8am in San Francisco actually happened after an event that took place at 9am in London due to the timezone difference.
• Message Date, Time and Time zone – When was the message created to communicate the details of the event? This is a very important date and time when it comes to the overdue monitor. This is the first date and time that it looks at to uncover unreported events. It makes sense to have the overdue monitor wait for when the message is expected to be received before deeming it to be overdue. E.g. We expect a supplier to ship the product at 8am in the morning but we allow them 2 hours to send us the message to tell us about the shipment. This allows for latency in the communication between the 2 parties. If you look at the order at 9am you would see that the shipment was due to leave at 8am but that you have yet to receive it. From the outside it looks like it’s late but in fact we still have another hour to wait for the message before it is in fact late. This is a very key point and a very powerful nuance of SAP EM. This piece of functionality, alone, provides all the needed information to hold your suppliers accountable for the EDI messaging service level agreements. E.g. you agree with your supplier to send the ASN within 2 hours of shipping the goods, or 24 hours for sending an EDI 855 (ORDRSP) in response to receiving an EDI 850 (ORDERS)
• Tracking ID – What objects are affected?  Delivery 0008000000, Line 000010 was packed so the Tracking ID would be set as the concatenation of these two fields, i.e., 0008000000 + 000010. If all the items of delivery are affected by the same event (e.g. PGI) then the tracking ID would be the Delivery itself without the line. Note: The tracking ID is used in conjunction with a Tracking ID Code Set. The code set gives context and ensures uniqueness of the Tracking ID. E.g. Delivery 800 is not the same as Sales Order 800.
• Location ID – Where did the event occur?  The delivery was to be packed in Location 10, in the Los Angeles Warehouse. The location ID is used in conjunction with a Location ID Code Set. The code set gives context and ensures uniqueness of the Location. E.g. Plant 800 is not the same as Port 800.
• Partner ID – Who is the carrier that will take the package to its final destination?  The Partner ID is used in conjunction with a Partner ID Code Set. The code set gives context and ensures uniqueness of the Partner. E.g. Vendor 800 is not the same as Carrier 800.
• Subsequent time adjustment – Are there changes to subsequent event timings?  New delivery date scheduled, or a completely different process behavior is to be expected. This is a very key piece of functionality. As mentioned earlier, the further down the supply chain you go, the more accurate your plan for future events become. This is the functionality that enables the change of future expectations based on the latest piece of information.
• Subsequent status adjustment – Does the current event lead to a change in status?  The rule set is typically used to perform this activity but SAP has provided this detail here to force a specific status change based on the event message data itself. This could be useful if complex logic, leveraging application system data, is needed to determine the new status of the Event Handler.
• Measurement Result – Confirmation of physical measurements results. E.g. The delivery was received at Warehouse A with a temperature of -4 degrees Celsius.
• Reason – A text message accompanying the event was used to provide more details around why the event occurred.  For the event ‘Delivery Refused’, a typical reason could be ‘Customer not home’. Note: The reason code comes with a configurable ID that allows for easier aggregate reporting as well as “free text” to capture those obscure reasons.
• Parameters – Are there any changes to the Event Handler attributes that the event needs to communicate to SAP EM?  A Proof of Delivery (POD) event should pass in the business’ signature name to the Event Handler so that the SAP EM Web UI report can give visibility to this information. Another example is to send a Delivery Create event with the delivery number as a parameter to the referenced sales order. This allows the Sales Order Event Handler to display the referencing delivery number. This number can be configured to be clickable to take the user to the corresponding Delivery Event Handler.
• Attachments – Any binary file that forms part of the event detail. E.g. The Proof of Delivery (POD) event should attach the image of the person who signed for the package.

Phew, pretty intense stuff… So let’s lighten it up a little and dive in to some benefits of SAP EM. Keep an eye out for the next blog in the series covering SAP EM benefits.