Configuring an End-to-End SCEM scenario (1/3)
If you need to develop an end to end SCEM scenario then hopefully this will guide you on your way. This is the first of a series of 3 papers that will go through the entire process. I have broken it down as follows:
1. SCEM overview and general Config. Scenario description
2. ECC Config
3. SCM Config
To implement SCEM you will need a good knowledge of ABAP!
- Supply Chain Event Manager is:
– A monitoring tool that enables end-to-end visibility, decision support and performance management across your configured process
– A coupling between the operation and planning activities performed for your configured process. Any deviations between this coupling can be addressed through SCEM
– A close to real-time monitoring tool for time-based process milestones, matching those up to expected times for those milestones. i.e. You can now take action based on exceptions
- Supply Chain Event Manager is not:
– An operational system (e.g. R/3) …although it may take information from operational systems
– A planning system (e.g. APO) …although it constantly monitors against a plan
– A data warehouse (e.g. BW) …although it provides data for BW for analysis purposes and keeps the event history until it is archived
Some terminology we’ll be using going forward….
- Event Handler
– Is tied to the Application Object Type (AOT) (defined in the application system).
– Rule Set – List of rules that are executed whenever an event is received for that event handler. These rules allow you to manipulate all aspects of the EH.
– Status profile – List of possible statuses that your EH can go through
– Expected events – Events that are expected to occur during the process. If an event is as a result of an exception to the process it is considered an unexpected event. If an expected event does not occur at the planned time then action can be taken. The Overdue monitor monitors expected events and compares them with their planned times/
– Tracking ID’s – ID identifies an event handler. Need not be unique. E.g. Sales Order number, PO Number
– Parameters – Attributes describing the EH instance. Information Parameters are used for info and passing though to BW. Control Parameters are used in rule processing and can also be passed to BW.
- Application Object Type
– A classification of the application object by defining a condition. You can define multiple application object types for a business process type (BPT)
– EHs are only created for AOTs
– You use the AOT to determine the tracking IDs that identify objects.
- 2 types of events:
– Events that you expect to happen – Milestones
– Events that actually happen
• These can be broken down further into types of event messages:
– Regular event
– Early / Late event
– Unexpected Event
– Unreported event
- The message can be transferred by:
– BAPI: /SAPTRX/BAPI_EH_ADDEVENTMSG_02,
– IDoc: EVMSTA,
– 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?
– Est. time: When will subsequent events occur?
- Parameters are used to store attributes of the event handler. There are several types of parameters that are described below:
– Info Parameter: Texts to be displayed / retrieved for reporting purposes, Org data that may be used to structure KPI info passed to BW
– Control Parameter: Info that may be used to determine or decide process steps
– System Parameter: Are control parameters that are stored in an explicit extension table. They exist only in SCEM and are defined as control parameters in the application system
– Query id: Can be used to query status data
– Tracking ID: Used to identify an EH outside of SCEM, In our instance it relates to an AOT
- Status Profile
– You use status attribute profiles to gain a quick overview of the status of event handlers
– You group one or more status attribute types in the status attribute profile
– The status attribute value (for example, completed, delivered, invoiced) forms the default value that the system assigns when creating the event handlers
- Rule Sets
– You define in rule sets how the system reacts to a reported or an unreported event.
– A rule set is constructed as follows:
• Rules: Determine whether to react to an event, and if so how to react. A rule can contain a condition and an activity
• Activities: Define how event messages are processed (single or Multi-step)
• Conditions: By defining rule conditions, you specify which tasks are executed within a rule set.
THE SCENARIO – ORDER TO CASH IN ECC
- The following expected and unexpected events will be tracked
– Sales Order Created
• Credit On
• Credit Off
– Sales Order Completed
– Delivery Created
– Delivery Picked
– Delivery Packed
– Delivery PGI
– Invoice Created
– POD Created
- The scenario status values:
– Phase 1: SO Create
• Sales Order Created
– Phase 2: Internal Review (IR)
• Internal Review Complete
• Credit Block On
– Phase 3: Being Processed (BP)
• Delivery Created
• Delivery Picked
• Delivery Packed
• Being Processed Complete
– Phase 4: Invoice
• Invoice Created
– Phase 5: POD
• POD Created
– Phase 6: Deactivate
• Deactivate Event Handler
- The scenarios Parameter Values:
• Control Parameters (For searching)
– Customer Number KUNNR CUSTOMER_AG
– Sales Org VKORG SALES_ORG
– Creation Date ERDAT CREATE_DATE
– Creation Time ERZET CREATE_TIME
– Item Category PSTYV ITEM_CAT
– Sales Order Number VBELN SALES_ORDER_NO
– Sales Order Line POSNR SALES_ORDER_LINE
• Info Parameter (Additional Detail)
– User creating object ERNAM CREATE_USER
– Price NETWR NET_PRICE
– Material Number MATNR MATERIAL
– Sold To Name NAME1 SOLD_TO_NAME
• Query ID
– Customer PO Number BSTNK PO_NUM
- The Scenario – Delivery Scheduling
We’ll be using the sales order’s delivery schedule to determine the planned times for delivery create, pick, pack and PGI.
We now know what we are going to be doing…. Time to configure the generic pieces in ECC and SCM.
Each step is labeled. Those starting with E are steps in ECC and those starting with S are steps in SCM.
ECC INITIAL CONFIGURATION
Step E1 – FIBF – Activate EM BAdIs
• Activate SCEM Add-On
– Tx: FIBF
– Choose Settings->Identification->SAP applications
– Mark the flag for PI-EM
Step E2 – RFC and Logical System
• Define RFC Connection to SAP EM
– Create RFC Destination to SCM server
• Define Logical System
– Define a logical system name for the SCM server
Step E3 – Define event manager
• Define SAP Event Manager
– Give the event manager a name (SAPSCM)
– Link the logical system and RFC destination to the name (E2). Make it synchronous in a DEV environment to assist in debugging but asynch in other environments
Step E4 – Define BPT
• Define Business Process Types (BPT) – Copy std SO BPT: ESC_SORDER (ZBPT_SORDER)
• Must match with SCEM BPT (S3)
• See (E100 & E200) for the other BPTs
SCM INITIAL CONFIGURATION
Step S1 – RFC and Logical System
• Define RFC connection to ECC
• Define logical system for ECC
Step S2 – Define Application System
• Define the Application System
– Give the application system a name (SAPECC)
– Link the name to the logical system and RFC destination created for that application system (S1)
Step S3 – Define BPT
• Define Business Process Types (BPT)
– Add entry with the same name as created in Create BPT on ECC (E4) (ZBPT_SORDER)
“That’s the initial configuration….. I’ll continue with the ECC configuration and development in part 2 of the paper shortly. Part 3 will handle all the SCM configuration as well as the WCL configuration and close off with some nice tips.”