Skip to Content

Supply Chain Event Management (SCEM) Described

Supply Chain Event Management (SCEM) helps to monitor a sequence of steps in a business process by comparing reported events against their corresponding milestones.

  • It controls the correct sequence of business steps
  • It monitors the timings of reporting of expected events / milestones. i.e Were they reported on time? Were they reported at all? This is known as overdue monitoring.
  • It monitors data of reported events. Each event reports data to SCEM and SCEM can check that this data was expected and falls within pre-determined limits
  • It measures the quality of the process by comparing it to predetermined quality goals

Within a given process you have events that you expect to happen and then you have events that actually happen. In total there are 4 types of events:

  • On time Event: The first event is an event that you expect to happen at a certain time in relation to the process and it happens in that time frame.
  • Early / Late Event: The event is reported outside the limit that was set as the expected event. It could cause rescheduling of subsequent tasks, email notifications, alerts, …
  • Unexpected Event: This event is reported yet was not expected in the standard overall business process as defined.
  • Unreported event: An event that you expect to have been reported by a certain time, that is not reported at all, is referred to as an unreported event.

The Application System (AS) is any system that holds application objects managed by Event Management (EM). It need not be an SAP system. Event Management (EM): mySAP SCM Application for handling SCEM. When you process application objects in your AS you check to see if an event handler (EH) needs to be created in SCEM. This is referred to as AOT Relevance checking. Once relevance is determined then data is collected to pass to SCEM. Eg. Control parameters, Info, Query, expected events, business object reference, tracking ID.

What are the components of SCEM?

Business Process Types

The type of business process / object for which events are managed. The following is a list of the standard BPTs provided in ECC

BPT Description
EPL_EQUIPMT Equipment in SAP R/3 Enterprise
EPL_INSPLOT Inspection Lot in SAP R/3 Enterprise
EPL_NOTIF Notification in SAP R/3 Enterprise
ESC_DELIV Delivery in SAP R/3 Enterprise
ESC_FI_CLEARING FI Clearing in SAP R/3 Enterprise
ESC_MATDOC Material Document in SAP R/3 Enterprise
ESC_MM_INVOICE MM Invoice in SAP R/3 Enterprise
ESC_PURORD Purchase Order in SAP R/3 Enterprise
ESC_PURREQ Purchase Requisition in SAP R/3 Enterprise
ESC_SD_INVOICE SD Invoice in SAP R/3 Enterprise
ESC_SORDER Sales Order in SAP R/3 Enterprise
ESC_WOGMVT Workorder Goods Movements (Production, Service, Maintenance) in SAP R/3 Enterprise
ESC_WRKORC Workorder Confirmation (Production, Service, Maintenance) in SAP R/3 Enterprise
ESC_WRKORD Workorder (Production, Service, Maintenance) in SAP R/3 Enterprise

Application Object Types (AOT)

A distinct business object type / BPT, or parts thereof, that is relevant for EM makes up an AOT. 1 BPT can have several AOTs. You assign the SCEM-relevant application object types to the business process types. SAP Event Management (SAP EM) only creates event handlers for these types of objects. The sequential number for each application object type within a business process type should always be different and should follow in an ascending order, so that the processing order is clear. The application object ID is the technical key between the application object and the event handler, and, together with the application object type and the application system name, it forms the unique identification between the application object and the event handler.

Event Types

The application system evaluates your defined conditions and functions. It uses the evaluation results to determine whether the change to an application object requires an event to be sent to the relevant event handler in SAP EM. The sequential number for each event type within a business process type should be different and should follow an ascending order, so that the processing order is clear.

Event Handlers (EH)

Creating a test Event Handler

Transaction: /SAPTRX/EH_CREATE Enter the mandatory data:

  • AOT – Application Object Type relating to the specific instance of the BPT. e.g. Warehouse Sales Order Line Item
  • BPT – Business Process Type. e.g. Sales Order
  • Logical System – Where is the EH going to be created?
  • Tracking ID Code set – Code relating to the tracking ID.
  • Tracking ID – Identifier for that particluar EH
  • Use grid functions to add the following if required:
    • Control parameters – Information on the EH used in the business process
    • Info Parameters – Additional information for reporting
    • Additional Tracking Ids – Links to other Objects

Select Create EH to create the EH

Event Messages

The message can be transferred by:

  • IDoc: EVMSTA
  • XML
  • WCL – Web Communication Layer
  • RF Devices

One message can report various events.

  • Event / Status: What happened and who reported it?
    • ID: Which object is affected?
    • Locations: Where did the event take place?
    • Partners: Who is involved in what function?
    • Estimated time: When will subsequent events occur?
    • Delivery status: Confirmation of detail data
    • Subsequent status: Which unplanned events might be caused?
    • Load Transfer: Where is the object loaded / unloaded to
    • Measurement Result: Confirmation of measurement results
    • Text: Text messages


SCEM is used to monitor a business process end-to-end. It can alert you when things outside of the norm occur. With it’s links in to BW and archiving you can ensure that the data is available for analysis long after it’s been removed from the system. An example of where I have used it is in the monitoring of the Sales Order -> Billing Process. i.e. A sales order is created and I create an AOT for each line item. Each AOT creats an SCEM EH for which I set up expected events for SO Line Completed, Delivery Created, Delivery Packed, Delivery PGI and Invoice Created. If any one of these events don’t happen on time then alerts are sent out. When events happen early then the expected event times are adjusted accordingly. As messages are received I update the status of the Event Handler based on the status profile. This allows you to view the EH status (through the WCL for example) very quickly and easily. The WCL is used to report these events to the users. It can also be configured to report events manually that have not been received. Anyway, that’s enough for now. In subsequent posts I will go through the motions of implementing SCEM step by step.

You must be Logged on to comment or reply to a post.
  • sure we (I) have questions:)

    – is EM installed by default with SCM ?
    – can we invoke events via some standard interface? via XI for example?
    – will you show by any chance events started by AII ?

    Thank you:)

    also thanks for many of your articles about ALE, IDOCs, etc. – I’ve learned A LOT from them 🙂


  • Kevin:

    Have done any work modifying the WCL for customer specific requirements on front end?

    Ie: Multiple Dates per EH date entry? and reducing the milestone update screens from 5 to 3? Any idea what it would talk (ROM Level of Effort only).

    • I have only configured the standard WCL client. With regard to modifying the standard content there is a rather basic document describing how it’s done via java. It would be great to get some details from those java guys who have done this to modify the standard WCL….
  • hi Kevin,

    I’d ask this on question on SDN but there is no forum except general SCM I believe
    so I’ll try here (hope you don’t mind)
    can we create(post) event handler with
    IDOC EVMSTA ? or do we need to use EHPOST first
    and then EVMSTA just to add events?
    cause when I try EVMSTA first it goes to green
    but no EH gets created and it only updates
    EH when I first create it manually

    thank you,

    Michal Krawczyk