SAP BDEx Config Guide

BDEx -
Configuration Guide
Release 4 Last update: 2016/03/02
Basis Technologies
Table of Contents
Introduction ................................................................................................................................................ 2
BDEx Overview ........................................................................................................................................... 3
BDEx Work Request Types ........................................................................................................................ 6

Device Management ............................................................................................................................... 8
Billing and Invoicing ............................................................................................................................... 9
FICA ..................................................................................................................................................... 11
SAP CRM ............................................................................................................................................. 13
IS-U Customer Service.......................................................................................................................... 14
Work Management ................................................................................................................................ 15
IDE/IDEX .............................................................................................................................................. 16
Cross Application .................................................................................................................................. 17
Installation and Activation ....................................................................................................................... 18
Configuration Options and the IMG......................................................................................................... 20
Customer Centric Hub Configuration ...................................................................................................... 25

System Configuration and Connectivity ................................................................................................. 26
Master Data Configuration .................................................................................................................... 28
Work Request Configuration ................................................................................................................. 29
Actions.................................................................................................................................................. 31
Root Cause Analysis ............................................................................................................................. 33
BDoc and IDoc configuration................................................................................................................. 35
Profile Management .............................................................................................................................. 39
Options ................................................................................................................................................. 43
Business Process and Context Configuration ........................................................................................ 44
Generic Object Services Configuration.................................................................................................. 45
Inform When Resolved .......................................................................................................................... 47
Closure Control ........................................................................................................................................ 49

Configuration ........................................................................................................................................ 50
Set up ............................................................................................................................................. 51
Case Objects ................................................................................................................................... 53
Condition Rules ............................................................................................................................... 55
Testing the conditions ...................................................................................................................... 57
Example................................................................................................................................................ 58
Background Processing ........................................................................................................................ 59
Displaying the Output ...................................................................................................................... 62
The Dynamic Work Center ....................................................................................................................... 64
Housekeeping .......................................................................................................................................... 65
BDEx Connect OData Service (SAP Gateway) ..................................................................................... 67

Metadata............................................................................................................................................... 70
Entity Types..................................................................................................................................... 71
GET Requests (Single Reads and Queries) .......................................................................................... 84
PUT Request (Update) .......................................................................................................................... 86
XML (Default) Format example.............................................................................................................. 88
JSON Format example .......................................................................................................................... 89
XLSX Format example .......................................................................................................................... 90
Appendices ............................................................................................................................................... 91
Out of the Box Actions .......................................................................................................................... 92
Basis Technologies BDEx - Configuration Guide - Release 4
Introduction
The purpose of this document is to provide a comprehensive guide to the configuration of the Business Data
Exceptions (BDEx) product. This document contains the in depth, step by step guides for the set-up and
configuration of each of the modules within BDEx:
The Customer Centric Hub

BPEM Closure Control
The Dynamic Work Center
This document can be used in conjunction with the BDEx Developers Cookbook, which provides the detailed
walkthrough of how to extend the product with custom enhancements.
Page 2 of 99
BDEx Overview
BDEx is designed for process optimization for Utilities running SAP CR&B, accelerating the investigation
and resolution of Back Office exceptions and significantly improving Front Office call handling. BDEx is a
certified add on to SAP for Utilities, designed to integrate with standard SAP BPEM and the Web UI.
BDEx consists of three modules, the Customer Centric Hub, BPEM Closure Control and the Dynamic Work
Center.
BDEx Customer Centric Hub:

Exceptions management in standard SAP is complicated, time consuming and takes multiple transactions
and systems to resolve the issues. Typically an agent will need to navigate across multiple transactions and
Page 3 of 99
systems to investigate and fix an exception. The Customer Centric Hub is designed to accelerate this
process by providing the user with a complete 360 degree view of the customer, showing all open work and
exceptions, past interactions and the history of completed work. The Customer Centric Hub provides the
following functionality:
A customer centric view of all open work and exceptions.

The summary notes screen that provides easy visibility of all notes across the BPEM Cases, CRM
Interaction Records, Business Contacts, Service Orders and Service Notifications.
A history screen that shows the previously resolved work and exceptions.
An invoice history screen, which provides the invoicing history for the customer.
The ability to log each activity that an agent performs, enabling a comprehensive and highly accurate view
of the time are taking to resolve exceptions, enabling accurate AHT measurements.
The root cause analysis screen, showing the interdependencies between exceptions, highlighting which
are the symptoms and which issues are the root causes.
The customer centric hub provides the ability to investigate and resolve exceptions through the provision
of right click actions. These are either accessed from a Master Data Object (e.g. Business Partner, Contract
or Installation) or a piece of work (e.g. BPEM Case, Service Order, Billing Outsorts) and provide the ability
to access all the relevant transactions from within BDEx.
BPEM Closure Control:

Standard SAP BPEM does not enforce the link between the exception (BPEM) case and the underlying root
cause issue. This means that an agent can close a case without having fixed the issue. It also means that
the underlying problem, for example an implausible read, can be resolved but the case may remain open.
BPEM Closure Control provides the ability to define the condition of when the case can or cannot be closed.
Preventing volumes of exceptions in the system without cases to track and manage these. If the condition is
not met the agent will not be able to close the case (it can be hard stop or a warning that the user can
override. This is configurable per rule). This prevents agents from closing cases where they havent fixed
the problem or followed all of the resolution steps. If the condition is met the agent is allowed to close the
case.
There is a regular (typically nightly) batch job that will automatically close cases where the condition has
satisfied, avoiding the need for an agent to manually work the case. This prevents cases hanging around
when they have already been fixed or unnecessary manual intervention where a case isnt actually a
problem anymore enabling the focus to be clearing issues rather than wasteful exceptions requiring no
action, ensuring an agents time is productive.
Dynamic Work Center:

The Dynamic Work Center is the inbox functionality within BDEx, focusing on delivering the right work, to
Page 4 of 99
the right people, at the right time and in the right sequence. It provides the ability for agents to receive
BPEM Cases and Work Items and for manager to view in real time the open work for their team.
Page 5 of 99
BDEx Work Request Types

Work Requests are the exceptions, errors or other pieces of work that appear in the Customer Centric Hub.
A work request maybe an implausible read that has triggered a BPEM exception. It could a technical failure,
such as a CRM Replication Failure. Work Requests may be work that a user should actively investigate and
resolve, or just an informational item that they need to have visibility of to effectively resolve an exception or
customer enquiry.
Currently BDEx supports 38 different type of work requests sub categorised into the following headings:
Device Management.
The Device Management module of SAP IS-U manages objects such as schedule records, meters / devices
and meter readings.
Billing and Invoicing.

The Billing and Invoicing functionality within SAP IS-U provides the ability to bill domestic, commercial and
industrial customers across a range of divisions (e.g. Electricity, Gas, Water, Waste Water).
FI-CA.
Contracts Accounts Receivable and Payable or FI-CA manages the processes for payment processing,
posting and dunning. FI-CA also includes the Enhancement Message Management function more commonly
known as EMMA or BPEM (Business Process Exceptions Management).
SAP CRM.
The CRM module of SAP offers complete customer relationship management. It manages a number of
objects such as Customers, Accounts / Business Agreements, Sales Orders and Interaction Records.
IS-U Customer Service.

The Customer Service module of SAP IS-U manages a number of objects such as business partners,
contract accounts and homemoves.
Page 6 of 99
Work Management.
The Work Management module of SAP IS-U manages work for engineers for replacing, inspecting, and
installing meters/devices. It manages objects such as Service Orders and Service Notifications.
IDE/IDEX.
The IDE module of SAP IS-U manages industry market messaging in deregulated environments.
Cross Application.
The cross application exception types are generic to all SAP ERM and CRM systems.
Page 7 of 99
Device Management
The Device Management module of SAP IS-U manages objects such as schedule records, meters / devices
and meter readings.
Implausible Meter Readings

Meter readings that have been successfully uploaded against the register(s) of a meter but are outside the
tolerance limits of the expected meter reading. These readings are not billable and will prevent further billing
causing delays to invoicing and payments.
Open Meter Reading Orders

Meter reads can be delayed for a number of reasons, for up to a number of weeks. Lack of a meter read can
cause billing to be delayed.
Installation Locks
Installation locks prevent meter reading orders from being created for the installation. If no meter reading
orders can be created, then any contracts moved in for the installation will not be billed.
Disconnection Documents
Disconnection documents represent the fact that a particular installation has been disconnected. This
prevents numerous business processes from executing for the given object(s) including meter reading
download/upload and billing.
No Device
A work request has been added to display if a device is not allocated to the installation, which is connected
to an active contract. Delays in flow processing can prevent devices from being installed meaning unbilled
consumption leading to potential lost revenue. This feature will highlight these issues immediately to the
agent in order for this to be fixed contributing to an effective meter to cash flow journey.
Smart Meter Communication (AMI Inbound / Outbound)

As metering technology improves and direct device communication becomes possible the need to keep an
eye on error messages in this area becomes more important. The consequences of these messages not
delivering their payload could impact the Customer in many ways ranging for device installation failures,
meter read upload delays and tariff change faults.
Page 8 of 99
Billing and Invoicing

The Billing and Invoicing functionality within SAP IS-U provides the ability to bill domestic, commercial and
industrial customers across a range of divisions (e.g. Electricity, Gas, Water, Waste Water).
Open Billing Orders

Also known as billing triggers, billing orders represent the fact that a contract/installation needs to be billed.
They are created at the time of meter reading order creation (if billing relevant) in a status of not billable.
Once a valid meter reading is entered (plausible) against the meter reading order, the billing order is
updated to billable. All billable billing orders are billed during the billing batch. The presence of a billable
billing order implies an issue is present during the billing process.
Billing Out-sorts
The output of the billing process is a billing document. Once produced, various checks can be performed
upon this billing document to ensure validity. This includes tolerance limits for monetary values (e.g. if it
exceeds a certain monetary amount). This ensures that very high bills are not sent out to customers
incorrectly or zero bills. Billing out-sorts must be resolved in order for invoicing to proceed.
Billing Check Failures

A billing check is performed to ensure that a given contract along with its associated billing required data is
present. If anything is wrong with either the billing master data or configuration, this is flagged up
appropriately.
Contract Billing Blocks

Contract billing bocks can be placed upon the contract to prevent billing from occurring. This can be done
for various reasons which are configurable such as customer complaints or during investigations.
Invoicing Out-sorts
This is similar to billing out-sorts except the entire invoice amount is considered as a part of the validation.
Invoicing out-sorts prevent large monetary values from being sent to residential customers. They stop the
billing/invoicing process and therefore have a material impact on customers and cash-flow.
Invoicing Triggers
Invoicing triggers are created after a billing order has been billed and a billing document produced. The
invoicing process runs off the presence of an invoicing trigger. The presence of an invoicing trigger indicates
that there is a potential problem in the invoicing process which is preventing the invoice from being
generated.
Page 9 of 99
Late Bill
If a bill order has not yet generated a billing/invoicing document past its due date the customer has become
late billed. Late billing is a main cause of lost/delayed revenue and also customer complaints. Visibility in
SAP is difficult particularly if the agent is resolving another work area. BDEx identifies these issues and
display them as a Late Bill work request. This enables agents to see periods of unbilled consumption and
ensure the customer is billed in timely a manner.
Invoice Print Document

The invoice document generated in IS-U. Includes open, posted and reversed invoice documents. This work
request details the payment status for the invoice indicating whether the invoice amount has been paid in
full, partially paid or is open and due.
Page 10 of 99
FICA
Contracts Accounts Receivable and Payable or FI-CA manages the processes for payment processing,
posting and dunning. FI-CA also includes the Enhancement Message Management function more commonly
known as EMMA or BPEM (Business Process Exceptions Management).
BPEM/EMMA Cases
Business Process Exception Management Cases (BPEM). The analysis of message from the application log
and the generation of BPEM Cases for agents to work the underlying exceptions. BPEM Cases can be
created from the messages in the application log or manually in IS-U or CRM. These exception cases
typically form the majority of Back Office processing in SAP for Utilities.
Contract Account Locks

Locks can be placed upon a Contract Account for various reasons. These locks can have validity periods
and also be deactivated (but the history of them retained). Common locks include preventing outbound or
inbound payments being applied to the account. Invoicing locks can be applied to avoid invoicing being
produced. Also dunning locks can be placed. The presence of a lock can immediately indicate to the user
why a given issue exists.
Collection Agency Items

After dunning has attempted to collect outstanding debt, the debt can be handed over to external collection
agencies. This exception type highlights any collection items that have been transferred to collection
agencies and are currently outstanding.
Collection Work-Items
Collection work-items can be generated as standard SAP workflow work-items to be routed to agents to
perform collection activities. These collection work-items are displayed as exceptions if they are currently
outstanding and awaiting either allocation or completion.
Instalment Plans
Instalment plans ensure the receivables are not included in the dunning run. Instead, dunning activities are
implemented for the due instalments that have fallen into arrears. This work request type provides the
instalment plan information for all active instalment plans on the contract account.
Failed Dunning Proposals

A dunning activity step sometimes fails i.e. one of the activities have tried to run but something has gone
wrong and it cannot execute, which then halts any further dunning activities from being triggered. This might
happen, for example, if there is a problem with posting a late payment charge, or a connection to CRM or
Page 11 of 99
another system has failed. This means the customer would not receive any future dunning reminder letter or
communications having a significant impact on the customer and potential lost/revenue to the business. This
exception allows agents to see the failed activities and dunning history for the customer. Enabling the agent
to fix the issue and continue the dunning process. This will ensure lost/delayed revenue is prevented.
Page 12 of 99
SAP CRM
The CRM module of SAP offers complete customer relationship management. It manages a number of
objects such as Customers, Accounts / Business Agreements, Sales Orders and Interaction Records.
CRM Replication Failures (ECRMREPL)

When replicating contracts from CRM to IS-U, replication errors can occur. This exception type high-lights
these failed replications and the reason for their failure. CRM replication failures cause inconsistencies
between data in the CRM and IS-U systems, which in turn cause downstream validation failures, exceptions
and other process interruptions.
Failed BDocs (Inbound & Outbound)

BDoc processing can error for numerous reasons and is one of the most common issues in the CRM
Middleware communication. This can prevent customer details from being updated such as name changes
and address details leading to customer impact. ISU BDocs are also displayed when failed.
Interaction Records / Business Activities

An interaction record is created for every customer interaction in CRM. An interaction typically starts with
and inbound or outbound contact and completes when the agent ends the interaction. Interaction Records
can also be generated by background processes, such as the sending of a piece of correspondence.
Marketing Leads
Any marketing leads that are currently outstanding can be displayed as an exception type. This indicates
that an opportunity is currently under way for the given customer/account.
Page 13 of 99
IS-U Customer Service

The Customer Service module of SAP IS-U manages a number of objects such as business partners,
contract accounts and homemoves.
Parked Move-In Documents

Parked Move-In documents are effectively documents for storing the information relating to a Move-In.
Parked Move-In documents can then be executed (e.g. at a later date). The presence of a parked Move-In
document can help an agent support issues relating to why a customer yet to be moved out and receive
their first bill.
Parked Move-out Documents

Parked Move-Out documents are effectively documents for storing the information relating to a Move-Out.
Parked Move-Out documents can then be executed (e.g. at a later date). The presence of a parked Move-
Out document can help an agent support issues relating to why a customer yet to be moved out and receive
their final bill.
Business Contact
Customer contacts provide visibility to agents activities previously undertaken and outstanding tasks.
Important information can be obtained from a customers call such as meter readings, device details or
complaints. In SAP CR&B, Business Contacts are typically replicated up to become Interaction Records in
CRM.
Correspondences
Correspondence records that have not yet been printed could be of relevance to the Customer; their
handling could be crucial to the Customer relationship. Manifesting these as items for the user to be aware
of and if need be take direct action upon can be a very useful way of bringing them out into the light and not
remain buried in technical back-end tables.
Page 14 of 99
Work Management
The Work Management module of SAP IS-U manages work for engineers for replacing, inspecting, and
installing meters/devices. It manages objects such as Service Orders and Service Notifications.
Service Orders
Service orders represent a piece of work that must be carried out. Via the service order itself, the process of
initiation through to implementation can be tracked. An open service order or one in an error state can high-
light to the user that some task has yet to be carried out.
Service Notifications
The Service notification is for planned or unplanned work. From a service notification a service order can be
generated. An open service notification or one in an error state can high-light to the user that some piece of
planned/unplanned work has yet to be carried out.
Page 15 of 99
IDE/IDEX
The IDE module of SAP IS-U manages industry market messaging in deregulated environments.
Switch/Process Documents
Switch or Process documents manage the industry processes in the deregulated environment, in particular
the switching of a customer from one utility supplier/retailer to another. All industry communication are
logged against the switch document as data exchange tasks. Activities are also recorded to transcribe the
events that take place during the switch process. An in process or in error switch document indicates that a
deregulation process requires investigation. In the latest version of IDE (IDEX), switch documents have
been renamed process documents and manage more deregulation processes that just switching from one
supplier to another.
Data Exchange Tasks

Industry messages are related to the Switch Document via IDE Data Exchange Tasks. These have their own
status which can be either in an error state or an on-hold/pending state. Messages in IDE can be put on
hold in the case where it is waiting for another message (or event) to occur but the industry message (IDoc)
must be processed.
Page 16 of 99
Cross Application
The cross application exception types are generic to all SAP ERM and CRM systems.
SAP Workflow
Workflows are used to model business processes within SAP. Triggered by events in the system, they
combine automated processes with the manual allocation of work items, deadline monitoring and
escalations. Workflows can range from simple refund approvals to highly complex end to end industry
processes.
Work Items
Work Items are the activity steps within a workflow, that are either executed by a user to carry out a
business or technical function manually, or a background process to perform an automated action. These
can range from Approve Refund, to Trigger Industry flow or Perform Device Installation.
iDocs (Inbound & Outbound)

IDocs (Intermediate Documents) which have failed to process successfully. An IDoc is an interface into the
IS-U/ERP system, typically used for the Meter Read upload or the sending and receiving of industry flows.
Page 17 of 99
Installation and Activation

The first step to install BDEx is to import the transport files provided by Basis Technologies into the relevant
systems. Depending on your architecture this may be a single set of transports to be applied to all
environments, or multiple e.g. one set of transports for ECC and one set of transports for CRM.
Once the BDEx software has been installed on the required system in the SAP landscape, you will need to
install the license key to begin use of the product.
This is performed in transaction /BTI/MDELICENSE.
Within the transaction, click on install and paste in the Basis Technologies supplied Licence Key.
Please contact Basis Technologies Support ([email protected]) to request a license key for
the given system(s) into which you are installing BDEx. You need to provide the following information:
SAP System ID: 3 character system SAP system ID (e.g. SD1)

SAP Installation Number: 10 character installation number
BDEx uses the Mass Data Runtime (MDR) framework for reporting purposes and for the extraction of some
work request types (iDocs and BDocs).
Page 18 of 99
The software for MDR will applied to the SAP system as part of the BDEx install. As with BDEx, MDR will
then need to be activated via a supplied licence key. Open transaction /BTR/MDRLICENSE and click on
install to apply the supplied license key.
Page 19 of 99
Configuration Options and the IMG

The configuration for the BDEx family of apps is maintained using the standard SAP customizing transaction
SPRO. If exceptions are to be retrieved from external systems, then certain configuration is required within
these external systems also.
The following steps can be applied to add the BDEx IMG structure to the standard configuration menu:
Page 20 of 99
BDEx is configured using a series of customizing tables. In order to provide access to these tables via the
standard SAP configuration transaction SPRO, the BDEx node must be added as an enhancement to the
SAP IMG.
1. Go to transaction S_IMG_EXTENSION
2. Use the search help function to find SAP Customizing Implementation guide.
3. Use the search help function to select a new Enhancement ID.
4. Create a new enhancement ID.
Page 21 of 99
5. Give the enhancement a name in the customer namespace (e.g. ZBDEX) and add it to a relevant
customer package. This enhancement must be included on a transport request so that it can be transported
to other environments.
Page 22 of 99
6. Once the enhancement has been created, select it from the list, and then press Enhance Structure.
7. Select the top line item SAP Customizing Implementation Guide then select Edit -> Nodes -> Insert IMG
Structure -> As Subnode
8. Use the search function to select Business Data Exceptions (BDEx) IMG structure, and name it
accordingly.
Page 23 of 99
9. The node is now available in the SAP customizing menu.
10. Repeat this process for all external systems (e.g. CRM) and transport the changes as required.
Page 24 of 99
Customer Centric Hub Configuration
Page 25 of 99
System Configuration and Connectivity

In order for BDEx to run correctly, collating work and exceptions from across the SAP landscape, it is
necessary to configure the various systems and the connectivity between them.
Define systems and RFC destinations

This configuration option manages the list of systems in the landscape, and how these are to be reached.
Every client that will be using BDEx must be entered into this table, so include all development, QA, training,
pre-production and production clients where applicable. This can be maintained in SPRO or via
configuration table /BTI/MDE_C_SYST.
Field Description
System ID The BDEx system ID
SAP System ID The SAP system ID
Client The client number
System Name A descriptive name for the system
Application The application class ID
Appl class The BDEx application class name
Destination The RFC destination to the source system
Source System Whether this system is the primary BDEx system
Source sys ID The source system ID for this system
Source client The source client number for this system
Icon The icon to display for this system
Active No longer used
WF used Whether inform when resolved should use workflow or email notification
For example, the following configuration would be appropriate for an ISU system EP1 client 100 and a CRM
system CP1 client 100:
Field Example value

System ID 0001
SAP System ID EP1
Client 100
Page 26 of 99
System name ECC production client 100

Application IS-Utilities
Appl class /BTI/MDE_CL_MD_APPL_ISU
Destination
Source system X
Source sys ID
Source client
Icon
Active
WF used
Field Example value

System ID 0002
SAP System ID CP1
Client 100
System name CRM production client 100
Application
Appl class
Destination EP1CLNT100
Source system
Source sys ID EP1
Source client 100
Icon
Active
WF used
Page 27 of 99
Master Data Configuration

Master Data Objects are at the core of BDEx. They represent the link between the hierarchies of master
data through to the exceptions which are generally transactional data.
Master data objects
/BTI/MDE_C_MDOBJ
This table contains all of the master data objects stored at application level. However, this table should
mostly be left as supplied as it is required for BDEx to run correctly. The main scenario where this table can
be modified is to suppress certain master data objects from being shown by using the No display flag. This
is the correct way to hide master data objects from the end-user (e.g. for POD in a regulated environment).
Entries should never be removed from this table, and only added in order to extend to additional or custom
master data objects.
Page 28 of 99
Work Request Configuration

Work requests represent the data that is to be retrieved, analyzed and presented to either users or reports
for numerous purposes. A work request can either be a technical issue or a functional/business issue.
Typical work requests include failed IDoc errors, BDoc errors and either in process or failed workflows or
work-items.
Functional issues are generally specific to the module(s) of SAP that is in use. These might include in
process sales orders, in process or failed service orders (or service notifications), plus numerous others that
represent either the business process starting point or a failure that might have happened within a business
process.
Work request classes
/BTI/MDE_C_WRCLS
BDEx comes with 40 different exception types available for use. The work request classes table provides
the basic configuration for these. The main configuration activity for this table will be to set the Inactive flag
for work request classes that are not required.
Note that custom exception types or third-party exception types can be added to this table; for further
information on developing your own exception types within the BDEx framework, please refer to the BDEx
Developers Guide
Selection options
/BTI/MDE_C_WRSEL
This table contains the selection options for each work request class and subclass. This is primarily where
the project-specific status values can be configured (e.g. for process/switch documents).
Relate work requests to BOR objects
/BTI/MDE_C_WRBOR
This creates the link between work request classes and related BOR objects. By default BDEx comes
preloaded with a standard list of BOR object mappings, this table should be updated with any custom or
additional BOR objects used. It is very important that all relevant BOR objects used are maintained in this
table, as missing entries will cause unexpected behavior in BDEx.
Page 29 of 99
Classifications
/BTI/MDE_C_WRTYP
This provides a list of classifications available for work requests. BDEx comes pre-configured with two
classifications, Information and Problem.
Other configurations are possible, for example some customers classify their work into Active process,
Exception, and Outstanding work.
Work Requests relating to BOR objects
/BTI/MDE_C_WRBOR
In this table the BOR objects are mapped to the work request types. All the standard objects are configured
out of the box however any Z or custom BOR objects need to be added to this table to enable the Customer
Centric Hub to pick them up.
Work Request estimated resolution times
/BTI/MDE_C_WRRES
The estimated resolution times can be added to this table. This information is displayed in the Customer
Centric Hub and assists in coordinating data for the Productivity Report BDi App. In this table you can enter
the time period the work request is anticipated to take to resolve and the unit type can be selected. The data
in is table displays not only the estimated resolution times for the work requests but also the elapsed time is
calculated using these values.
Work Request Primary Object Priorities
/BTI/MDE_C_WRPRI
This table enables the primary objects to be defined. If left blank the objects will be sourced from the work
request type. However, in the case where there are multiple objects this can be used to prioritize and list
them against the work request. This cannot be used for all object types only the work requests that can use
different object types I.e. BPEM cases.
Page 30 of 99
Actions
Actions are the resolution steps that can be executed in BDEx in order to either investigate or resolve
exceptions. The purpose of actions is to stream-line the navigation of the user from the BDEx framework
into the appropriate transaction within the underlying system where the exception resides (e.g. SAP ECC,
SAP CRM, XI/PI etc.). Note that this might also include a non-SAP system.
Further more, they may instead call standard BAPIs or other internal function modules rather than
navigating to the standard transaction(s) in order to perform the required function.
Action Header Configuration

Actions are configured within the table /BTI/MDE_C_ACT. This represents the header information of the
action.
Field Description
Action ID Unique reference to the action
Function Code The function code of the action
Reference Class The actions executing class
Reference
The actions executing method
Method
Icon Not longer supported
A flag to indicate that the list of work requests should be refreshed after the action has
Refresh
executed
Inactive Deactivates the action
Custom actions not delivered in the standard product should have their Action ID within the customer
name space (i.e. starting with Z or Y).
Refer to the BDEx developers guide.
Master Data Actions

Master data actions are those actions that can be executed upon the master data objects within the
hierarchy. This table provides the link between a master data object and the relevant action, plus the order
the actions will appear in the relevant context menu.
Field Description
Master Data Object ID The ID of the master data
Page 31 of 99
Action ID The ID of the action

Sequence number Determines the order in which master data actions will appear
Work request actions

Work request actions are those actions that are executable upon the work requests themselves. These take
the user into the appropriate underlying transaction for the exception itself in order to resolve the issue. As
mentioned earlier, however, this may actually just call a BAPI or perform some underlying functionality
without navigating to a separate screen.
Field Description
Work request class The work request class ID
Work request subclass The work request subclass ID
Status The work request status ID
Action ID The action ID
Action sequence The order this action should appear in the context menu
Work request history relevance Whether this action is available for work requests in the historical view
Similarly to the master data actions, exception actions are linked from the action header to the work request
via this table.
Page 32 of 99
Root Cause Analysis

Work Request root cause analysis
/BTI/MDE_C_WRRCA
Root cause analysis shows the interdependencies between exceptions and identifies which are the
symptoms and which are the root causes. BDEx provides different relationship types which can be
configured. Depending upon the relationship type a relationship method must also be configured. Each type
is explained along with the appropriate methods.
Relationship Types:
Symptom A primary work request is listed along with a secondary work request. This is used to signify a
hierarchical relationship between the exceptions for example a meter exchange work item is the primary
root cause and an implausible reading and a BPEM case for the reading are symptoms of the meter
exchange work items.
Created by This should be used to identify an exception breeder whereby 100% of the time a work request
triggers another work request to be created.
Dependent This displays the interdependencies between the work request types in the Customer Centric
Hub.
Duplicated This displays duplicated items. This can be used if there are multiple exceptions for the same
object that should have a unique key or for cases which occur on the same date.
Linkage This indicates a one to one relationship between two work request types. Whereby the secondary
object should not exist if the primary object is not present. This relationship type creates a link within BDEx
and if the primary object is closed this triggers a information box requesting to close the secondary object.
Relationship methods:
MATCH_ALL_SEC_OBJECTS
Match all secondary objects This method checks all of the secondary objects on the case and if all the
objects on the primary work request type are a match will show the objects have a relationship.
Page 33 of 99
MATCH_SEC_WR_KEY
Match secondary work request key This method checks the primary work request objects contain the
secondary objects key. This could be relevant if both work requests share the same object keys such as a
bill block and the BPEM created for the bill block.
MATCH_ANY_OBJECT
Match any object This checks the work requests share any objects.
MATCH_DUPLICATES
Match duplicates Checks the primary work request is the same as the secondary.
MATCH_DUPLICATES_COMP_TIME
Match duplicates by completion time Compares the creation times of the work requests to search for a
match.
MATCH_ON_MAIN_DATE
Match on main date Checks the work requests share the same main date.
MATCH_ALL_PRI_OBJECTS
Match all primary objects Checks all the primary objects match to the secondary objects.
MATCH_PRI_WR_KEY
Match primary work request key Checks if a primary object work request key is contained in the secondary
objects.
MATCH_CREATED_BY
Match created by This checks the created by ID for both the work request items and if there is a match
shows there is a relationship between the two.
Page 34 of 99
BDoc and IDoc configuration

Note: The following sections only apply to Client implementations where BDoc and/or IDoc Work Requests
require extraction and treatment in BDEx.
BDoc Configuration
Table /BTI/MDE_C_BDOC is provided and pre-loaded with configuration settings for many of the standard
CRM BDoc Types that would normally qualify for consideration either in their Classic or Extended
Payloads or sometimes both. New entries may be necessary to support additional BDoc Types for the
specific Client implementation. Alternatively the active flag settings for these entries may need adjustment
from time to time depending on the desire to need to continue analysing specific BDoc Types going forward.
Each record in this table should indicate:
1. BDoc Type For example BUPA_MAIN

2. Payload Type Which payload the data is located in: C classic data or E extended data
3. Component name 1 The first-level structure to inspect
4. Component name 2 The second-level structure to inspect
5. Component name 3 The third-level structure to inspect
6. Field name The field name of the master data key
7. Component field 0 name Field name where-clause field name
8. Component field 0 value Field name where-clause field value
9. Component field 1 name Component name 1 where-clause field name
10. Component field 1 value Component name 1 where-clause field value
15. Master Data Object ID The BDEx object ID of the master data key, e.g. ISU0009 (Device)
16. Master Data Key Type The BDEx key type of the master data key, e.g. 100 (Manufacturer serial
number)
17. Active Whether this configuration should be active.
The name of the field containing the relevant key should be recorded in the Field name field. If this field is
located within another structure, define the structure name in the component name field. For example, in
the BUAG_MAIN BDoc the business partner number is located in the field partner, inside the
Page 35 of 99
CRMT_BUAGS_MW_HEAD. For BDocs with multiple line items, where-clauses may be required for each of
the parameters.
For example, a SI_POD BDoc contains the point of delivery number in the OBJKEY field, but only on the
line where the value BAPI_EUI is found in the TABNAME field. This configuration entries required would
thus be:
Field name OBJKEY

Component field 0 name TABNAME
Component field 0 value BAPI_EUI
These settings influence the behaviour of the BDoc Analysis Report (/BTI/
MDE_REP_BDOC_ANALYSE_MDR) which should be scheduled in the front-end CRM environment to run
as frequently as required to maintain the necessary table entries in the Additional Work Requests Table
(/BTI/MDE_ADD_WR) that are interrogated by the BDEx Transaction.
The BDoc Analysis Report can be run in 3 different modes: New Errors, Interim Errors and Old Errors. The
former and latter modes are always required if BDocs require analysis. The second mode is entirely optional
and depends on Client preferences about whether BDocs in an intermediate state for an extended period of
time are to be considered as errors.
Page 36 of 99
Typically the BDoc Analysis Report will be scheduled to run in the background as a periodic batch job
(composed of up to 3 steps, one for each mode) with appropriate (system) variants to control the BDoc
Types to be analysed.
IDoc Configuration
An IDoc Configuration generator program (/BTI/MDE_REP_IDOCCONFIG) is provided as standard. This
report can be executed with the following runtime criteria:
1. IDoc Message Type

2. IDoc Basic Type
3. Segment Type
4. Field Name
When executed the output generated will allow for the selection and maintenance of settings stored in
configuration table /BTI/MDE_C_IDOC and allow IDoc fields to be related to a Master Data Object.
For example, a Meter Read IDoc might provide via the Manufacturers Serial Number of the device. To
configure this link, enter the desired IDoc type (and optionally segment type) for a list of the fields available.
Use the dropdowns provided to select the correct master data object and key type, and press the save
button to update the configuration:
These settings influence the behaviour of the IDoc Analysis Report (/BTI/
MDE_REP_IDOC_ANALYSE_MDR) which should be scheduled the appropriate environment(s) and run as
frequently as required to maintain the necessary table entries in the Additional Work Requests Table (/BTI/
MDE_ADD_WR) that are interrogated by the BDEx Transaction.
Page 37 of 99
The IDoc Analysis Report should be run in both modes: New Errors and Old Errors.
Typically the IDoc Analysis Report will be scheduled to run in the background as a periodic batch job
composed of at least 2 steps (one for each mode) with appropriate (system) variants to control the IDoc
Types to be analysed.
Page 38 of 99
Profile Management
All users who use BDEx can be linked to a Profile which controls a number of aspects of the behavior of
BDEx including which work request classes are displayed, the actions that are available, and the defaults
for certain BDEx options. Managing the list of profiles and their related options is done via the Profile
Manager, which is accessed via SPRO or transaction /BTI/MDE_PROF_MGR.
The Profile Manager transaction allows an administrator to add, remove and customize profiles as required.
The BDEx profiles provide the ability to define distinct views for different teams or business units. It allows
the view in the BDEx Customer Centric Hub to be configured to reflect the different operational needs of the
business teams.
Profile Header
This section defines the profile name and enables customizing of filters and defaults available for the tabs
within the Customer Centric Hub.
Tab views:
Page 39 of 99
Enable Action Logging This feature enables all actions and activities carried out by a user to be tracked in
the Action Log. This is a useful audit trial to assist with quality control and productivity reporting.
History disabled This feature hides the work request history items. These are all the work requests which
have been resolved (if the work request type has been configured to display in the history tab) within the
Customer Centric Hub.
Process disabled This feature is the Business Process arrange by option. Within the Work Request tab of
the Customer Centric Hub you can sort/filter the items in here by Business Process. If this option is selected
this filter will be removed from the CCH.
Context disabled This feature is the Customer Context arrange by option. Similar to the Business Process
filters you can also filter/sort by customer context. Again if this option is selected this filter will be removed
from the CCH.
Root cause analysis disabled This function enables work requests to be linked together and highlights the
interdependencies between the exceptions. This can be disabled within the profile and therefore any users
assigned to this profile would not have this option available.
Page 40 of 99
History view default filter The default can be set to define the history time period for the work requests
which will be displayed in the history tab. The default date periods available are today/week/two weeks/
month/two months/year/two years. Usually the recommended default is six months.
Options:
Retrieve switch documents Switch documents can be deactivated at the profile level, you may wish to
deactivate for non metering users.
BDEx Documentation link Here you can specify a link to the BDEx documentation to enable the users to
access the BDEx user guide directly within the CCH.
Display custom tab 1 This is the Invoice history tab which can be disabled at each profile level by
removing the X from this field.
Display action technical names Within BDEx we have right click actions which can be accessed against
each master data object, work request types including historical items and the invoice history items. The
right click actions have a description and also a technical name. If the preference is to display the technical
name as well as the description this field can be populated to do this for each profile e.g. action name
Display Contract Account, technical name CAA3.
Enable pause button Offline activities can be recorded within BDEx to track an agents time when carrying
out activities outside of the Customer Centric Hub. For example an agent can record if carrying out an
offline activity i.e. Meeting to do this they will select the pause button and pick the activity type from the
drop down list. This button can be enabled or switched off using this option.
Page 41 of 99
Work requests
This tab defines which work requests are retrieved when using this profile, and which ones are retrieved as
part of a historical view. Work request subclass and status can also be specified to further tune which
requests are visible to profile users.
In most cases, all active work request classes should be added to each profile, so that agents working an
account can see all possible issues, even if they are not likely to work them.
An Add all button has been provided to quickly add all active work requests to the profile. This adds each
active class, unrestricted by subclass or status. If more granular additions are needed, these need to be
done one by one.
Users
In order to use a profile, a user must be assigned to it. This tab gives the list of assigned users, plus
settings for whether or not their actions should be logged, whether they should have their user-level settings
locked to the profile defaults, and whether this profile is their default.
Excluded master data and work request actions

These tabs provide the ability to restrict master data and work request actions by profile. For example, the
Full device removal might not be desired on a billing agent profile, and can be disabled via this tab.
Page 42 of 99
Options
There are a number of options available for BDEx, such as whether to default to a grid or tree based
structure, whether to display inactive contracts, etc. Some options are set at a system-wide level, while
others can be set at a profile or user level. The configuration of parameters table contains the master
configuration for the options in the system, plus system-wide defaults for more specific options. This means:
System-level options must be set in this table.

Profile-level options should be set in the relevant profile (see Profile Management earlier for details).
Any entries in this table serve as defaults if the profile isnt configured.
User should be set by the user from within BDEx. Profile defaults can be set (and optionally locked) in
Profile Management. Entries in this table serve as defaults if neither the profile nor the user has
specified a value.
The list of options available is provided by Basis Technologies and should not be modified, beyond setting
the VALUE field in this table.
Page 43 of 99
Business Process and Context Configuration

Business Process
Most work requests can be categorized into business processes along functional lines. For example, a utility
company may loosely categorize work as being billing, metering or finance related. This configuration allows
these groupings to be reflected within the Business process tab in BDEx.
Context Management
Business contexts provide a different way of grouping work requests. Whereas business processes are for
categorizing work down functional lines, contexts can provide a very different view of the work requests. For
example, a business context could be high bill complaint or late billing, with work requests that may
cause these issues assigned accordingly.
Page 44 of 99
Generic Object Services Configuration

With a minor amount of configuration, it is possible to allow users access to BDEx from any exception case
or master data object via the standard SAP generic objects services (GOS). This means that when a user is
within an exception case or displaying a master data object (e.g. a business partner) related transaction;
they are then able to launch BDEx from the GOS menu available in the title-bar.
Page 45 of 99
Once selected from the menu path, the user will be taken into the BDEx transaction passing through the
context of the case, or master data object they were in.
To make this function available, add the following entry to standard SAP table SGOSATTR:
Once this is done, a reference to the new service must be added in the Next service field of the last item in
the existing generic object services menu. This will be an entry with a blank Next service field currently,
usually ESJI_GW_SUB in an unmodified system.
The generic object services linkage code is largely based on the BOR object bindings to master data and
work requests (see the relevant chapters in this guide). If selecting the GOS menu item causes a Linkage
not found error, this is likely due to missing configuration in these tables.
Page 46 of 99
Inform When Resolved

BDEx is able to send notifications to individuals when issues are resolved. This is also known as the Inform
when resolved functionality of BDEx. A common use of this functionality is when an agent is unable to work
a particular exception (or customer/object) because further information is waiting to be received (for
example, a service order/notification is waiting to be completed). The intention is to provide proactive
notifications, to avoid agents having to regularly perform manual searches, to find out if issues have been
fixed.
Notifications are done via SAP Connect, which must be set up using transaction SCOT.
To receive inform when resolved messages as emails, in the BDEx system configuration, within table /BTI/
MDE_C_SYST, the USE_WORKFLOW field should be set to blank. Otherwise BDEx will send the
notifications as SAP workflow work items.
Scheduling the Notifications

Schedule report /BTI/MDE_REP_PROCESS_WR_WATCH for BDEx to regularly monitor completed items.
This job would normally be scheduled to run on a regular basis, e.g. hourly or daily.
Schedule the notification SAP Connect report RSCONN01 to generate the email alerts.
Configuring Recipient Email Addresses

Notifications are sent from the central system upon which BDEx is running, typically the IS-U ECC system.
The recipients email address is taken from the user master record in this system. In order to have these
notifications delivered as emails, then the user master record must have an email address maintained. If it
does not, then the notification will be sent as a document to the users SAP Business Workplace.
Page 47 of 99
Page 48 of 99
Closure Control
Purpose of closure control
Closure Control determines the rules when a BPEM Case can or cannot be closed. When an agent attempts
to close the case, the rule will be assessed to determine if the case can be closed.
If the condition has not been met, the case cannot be closed and the user will be prompted with an error
message. If the condition has been satisfied, the case will close as expected.
A batch job will be made available for the business to process as per their requirements. This uses the
same rules and checks the BPEM cases. Again determining if the condition has not been met, no changes
will be made to the cases. If the condition is satisfied, the cases will be mass completed. The results of the
job can be viewed in a report providing full visibility of what has been mass closed or untouched.
The rules can be enforced either as a warning or an error. Check with a warning means the the user will
receive a pop up message and this can be overridden. However, check with error is a hard stop and will
prevent the case from being closed.
For example you may wish to use a check with error if under no circumstances should a case be closed if
the condition is not met i.e. if a user is attempting to complete a BPEM case for an implausible reading the
rule to be enforced is if an implausible reading has not been reversed or released prevent the closure of the
case. However, you may want a user to check if a bill block has been removed. In this instance you can use
the check with warning to prompt the user to check for a bill block.
Page 49 of 99
Configuration
This topic will demonstrate how to configure a closure control condition and provide an example.
Closure controls can be configured for any rules whereby the rule relates to the objects within the
BPEM/EMMA case category and where the object in the case has a one to one relationship with the
attributes used for the rules e.g. If a billing outsort BPEM/EMMA case contains multiple billing document
objects and the rule checks the status of the billing doc, standard configuration is not suitable for this rule.
One BPEM/EMMA case must be created each billing document to enable standard configuration.
However, for unrelated rules or scenarios whereby you have multiple objects of the same type to be
checked a BAdI is available to enable these rules to be set up.
Please see the Developers Cookbook for more information on the Closure Control BAdI:
Developers Cookbook
Page 50 of 99
Set up
Closure control configuration is accessed using transaction /BTI/MDE_BPEMCOND
This loads the closure condition screen
From this screen the case category to be set up can be selected and you can create a closure condition.
There are three options to be completed in this screen:
Completion Type:
This is selecting the completion type for the BPEM/EMMA case. The recommended approach would be to
use Complete however Cancel is also an option depending upon the business process that is being
applied.
Foreground check type:
Check with error

- This is a hard stop and will prevent the case from being closed.
Check with warning

- This is a soft option and allows the user to complete the case but provides a prompt in the form of a pop-
up box to ensure certain processes have been followed e.g. have you removed all billing blocks could be a
message to be displayed though the case is unrelated to this. Therefore, you do not want a hard stop but a
reminder message instead.
Description In this field the message to be displayed to the user if they have attempted to complete a
BPEM case without fulfilling the rule.
Page 51 of 99
This is a free text box and the message should explain to the user why they cannot complete the BPEM
case.
Page 52 of 99
Case Objects
Case objects are usually master data or work request keys assigned to the BPEM/EMMA case to provide a
data reference for the case. The Business Object Repository (BOR) is the object-oriented repository in the
R/3 System. It contains the SAP business object types and SAP interface types as well as their
components, such as methods, attributes and events. BOR types are added to the case container within the
BPEM/EMMA configurations to reference the key and pull through attributes for the case.
Case objects are used in closure control to define the conditions. The conditions will use the attributes from
the object to enable the rules to be set up.
The editor allows new attributes to be added to the case container for the purposes of closure control. For
example if you are configuring closure control for an implausible reading you may need to add a rule to
check the meter reading is active. In the standard BOR MR Document the meter reading active field is not
an attribute on this object. However, using the condition editor you can add this field from the table as an
attribute to enable rules to be defined for this.
Any new attributes added must have the binding added to ensure the attribute is linked to the case object.
Page 53 of 99
Once the attributes have been linked to the case objects the rules can now be configured.
Page 54 of 99
Condition Rules
Clicking the link in the Condition box launches the rule editor to enable the conditions to be configured.
The change condition screen allows the closure control expressions to be set up which is the pivotal part of
configuring the rules.
Page 55 of 99
The container attribute should be added to the expression and the operators to manage the rule i.e.
Meter reading active NE (not equal) 1
This rule is saying for this BPEM/EMMA case type if the meter reading document has an active reading the
case cannot be closed. If the case is inactive then it can be closed.
Multiple rules can be defined in here and there is a test function to enable you to ensure the rules are
correct which is explained in the next topic.
Page 56 of 99
Testing the conditions
In the condition editor there is a test function to ensure the rule is defined correctly and is working as
design.
Firstly test data can be added by selecting:
Once the test data has been added the rule can be checked by selecting:
If the result returned is True this means the case would be completed and the rule has been met.
If the result has returned False the case cannot be completed and the rule has not been met.
Page 57 of 99
Example
Example Closure Condition
Exception Type:
BPEM/EMMA Case Category: XXXX

Case description: Contract is blocked from billing
Error closure condition type will be applied will the following rule(s):
Closure condition is false and the case cannot be closed if:

A bill block exists on the contract associated to the XXXX BPEM case.
Closure condition is true and the case can be closed if:

There is no bill block type on the contract associated to the XXXX BPEM case.
Configuration Details
BPEM Case Category: XXXX

BPEM Case Object: Meter Reading Document
Attribute required Active field from EABL table
Table Name: EABL
Field: AKTIV
Completion Type: Complete
Foreground Check Type: Check with Error
Message to be displayed if condition is false and the case cannot be closed:

This implausible read must be released, reversed, or marked as inactive.
Page 58 of 99
Background Processing
Technical_settings_guide control rules can also be ran in the background to check the BPEM/EMMA cases
are still valid and even re-open any cases which may have been completed in error prior to the condition
being applied.
Program name: /BTI/MDE_BPEM_CLOSURE_MDR
This program is designed within our Node 5 framework and the technical settings need to be defined.
You can find the instructions on setting up the technical settings here:
Technical settings guide
This program can be executed on-line or in the batch run.
Once the program has been executed the selection screen as follows will be displayed:
Page 59 of 99
Options available:
Case Category Specific category types can be entered here if the program should only be run for certain
case categories. If this field is left blank all categories that have been configured will be checked.
Completion date The completion date of the BPEM/EMMA cases can be entered to restrict the data to be
checked and only run the rules against cases completed on a particular date or date range.
Check box options:

Complete cases If this is selected any cases checked whereby the rules are met will be mass completed
Page 60 of 99
by the program.
Reopen cases If this is selected any cases that have been completed already however the rules are not
met will be re-opened.
Confirm completed cases Cases in status completed will be set to confirmed (this enables the status
changes to be completed in bulk).
Test mode If this option is selected the cases will be checked however no changes will be applied in the
system.
Page 61 of 99
Displaying the Output
The results are displayed in a report.
Program name: /BTI/MDE_BPEM_CLOSURE_TRANS
There are two options available to sort the results
Result Summary This provides an aggregated view by case category of the total volume unchanged
(these cases have been determined to be valid and still required to be worked), reopened, completed,
confirmed, errors, invalid, total.
Detail view This provides the full list of BPEM cases with their case numbers.
Page 62 of 99
Page 63 of 99
The Dynamic Work Center

In a SAP Utilities environment back office work can come from many different sources, like work items,
BPEM cases and front office activities.
With limited time and resources its important to prioritize these efficiently, this can prove to be difficult using
spreadsheets or searching case lists manually.
Work is prioritized based on pre-determined rules, and then allocated to the correct agents single inbox
automatically without requiring lots of manual steps.
The Dynamic Work Center streamlines the process of allocating back office work in an SAP Utilities
environment, enabling greater efficiency, reducing cherry picking of work and enabling back office managers
to gain complete visibility and control of their teams workload.
Activating a work request in Dynamic Work Center requires the relevant SAP code to be enhanced, enabling
the DWC architecture to be updated in line with the underlying data. This document contains instructions
and sample code for each supported work request to be enabled if required.
All of the complex logic resides within the /BTI/MDE_CL_BWC_DB class; the enhancements need merely
call the relevant methods and passing all available parameters. All work retrieval and routing is performed
using the standard SAP PFAC infrastructure and the SAP Organisational Structure, so these must be fully
configured for all work types that require specific routing.
Configuration settings:
There are two BDEx Profile Option settings (/BTI/MDE_C_OPT) that are relevant to the DWC that are not
maintainable using the BDEx Profile Manager (Transaction /BTI/MDE_PROF_MGR) and so must be
maintained at the Configuration level (either via the IMG or using Transaction SM30):
Option 10 Max results when searching => defaulted to 50
Option 11 Get work button size limit => defaulted to 5
Page 64 of 99
Housekeeping
Additional Work Requests (Database Table /BTI/MDE_ADD_WR)
IDocs
Configuration settings: /BTI/MDE_C_IDOC
Report: /BTI/MDE_REP_IDOC_ANALYSE_MDR
Schedule the Report as frequently as desired to identify IDocs as Work Requests for BDEx consideration
according to the Configuration settings defined.
Note that the report must be executed in both modes (New and Old) by means of separate runtime variants.
This can be achieved as consecutive steps in the same batch job to simply scheduling.
BDocs (CRM Installations only)

Configuration settings: /BTI/MDE_C_BDOC
Report /BTI/MDE_REP_BDOC_ANALYSE_MDR
Schedule the Report as frequently as desired to identify BDocs as Work Requests for BDEx consideration
according to the Configuration settings defined.
Note that the report must be executed in all 3 modes (New, Intermediate and Old) by means of separate
runtime variants. This can be achieved as consecutive steps in the same batch job to simply scheduling.
Archiving
The following Archiving Objects are provided as standard:
Dynamic Work Center: /BTI/MDEBW => Database Tables /BTI/MDE_BWC_HDR, /BTI/MDE_BWC_ASN and
/BTI/MDE_BWC_FWD.
BDEx Action Log: /BTI/MDELG => Database Table /BTI/MDE_ACTLOG
BDEx Additional Work Requests: /BTI/MDEAD => Database Table /BTI/MDE_ADD_WR
As with all Archiving Objects these can be managed using SAP Transaction SARA, with following actions
supported:
Page 65 of 99
> Write Allows for Archive File creation using Variant settings
> Delete Executes DB Table deletion according to Archive File content
> Read Displays Archive File content
> Management Allows for Administration of Archive Files
How these Archiving Objects are used will depend entirely on the growth rate of the underlying Database
Tables and the data retention requirements for the individual client implementation.
For the Dynamic Work Center DB Tables an additional consideration will be the data retention of the Parent
work request object, e.g. the BPEM Case itself.
For the Additional Work Requests a similar consideration will be the data retention of the Parent work
request object, e.g. the BDoc or the IDoc.
Page 66 of 99
BDEx Connect OData Service (SAP

Gateway)
Inspired by the SAP Multichannel Foundation for Utilities and Public Sector, BDEx Connect exposes the
functionality of our Customer-Centric Hub as an OData Service.
This means that regardless of technology, platform or application, BDEx Connect provides answers to
questions about Customers (or Technical Locations) using the universally-accepted and browser-friendly
language of HTTP without the need for complex interfaces, file formats or even operational scheduling.
With BDEx Connect, common questions such as:
Q. What open work needs to be resolved for this Customer?
become simple HTTP requests instead:
Q. GET: BusinessPartnerSet([BP Number])/ToWorkRequests?
BDEx Connect possesses an Entity Model replete with technical objects designed to expose the capabilities
of BDEx functionality as well as more Business-oriented objects that encapsulate common functions and
services normally expected of SAP Utilities implementations.
In this way we provide access to features such as full Master Data Context building from a single Master
Data Object reference, whilst at the same time being able to answer specific Business questions, such as
What the was the value of the last Bill we sent to the Customer?.
Similarly, we can provide a set of Customer-related Note texts from a range of sources from deep within the
entire SAP Estate (e.g. SAP IS-U and SAP CRM) and at the same time answer the simple question Whats
the current Balance of the Customers Account?.
How this OData Service is exposed in the Clients System Landscape is also entirely flexible, thus allowing
for various degrees of data security to be met without compromise.
SAP Gateway provides an open, REST-based interface that implements simple access to SAP systems via
the Open Data Protocol (OData) released under the Microsoft Open Specification Promise (OSP) for
querying and updating data.
Page 67 of 99
OData builds on broadly known and used industry standards such as Atom Publishing Protocol (AtomPub),
XML, and JSON (JavaScript Object Notation), which makes it easier to understand and use.
Its consistent with the way the web works and follows its core principles, allowing for a new level of data
integration and interoperability across traditional platform and manufacturer boundaries.
Its easy to understand and extensible, and provides consumers with a predictable interface for accessing a
variety of data sources.
In short, OData can be seen as Online Database Connectivity (ODBC) for the web. It opens up the silos of
traditional IT and increases the value of data by allowing for easier and broader data access.
The diagram below shows how SAP Gateway can act as a single solution that replaces all other point-to-
point solutions:
Page 68 of 99
Page 69 of 99
Metadata
When SAP Gateway is active the Metadata for the BDEx Connect OData Service can be found via
Transaction SEGW in the back-end system using the following simple HTTP Request:
/sap/opu/odata/BTI/MDE_ODATA_ISU_SRV/$metadata
Page 70 of 99
Entity Types
The following Entity Types are supported within BDEx Connect:
Address (Abstract) Cannot be queried or read directly. See BusinessPartner, ContractAccount and
ConnectionObject below.
=> Properties:
- AddressNumber (key)
- AddressUniqueID
- AddressGroup
- PersonalAddress
- StandardAddress (filterable)
- Alternative
- DateFrom
- DateTo
- Nation
- Title
- Name1
- Name2
- Name3
- Name4
- NameText
- NameCareOf
- Location
- Building
- Floor
- RoomNumber
- HouseNumber1
- HouseNumber2
- HouseNumber3
- Street1
- Street2
- Street3
- Street4
- City1
- City2
- Region
Page 71 of 99
- PostCode1
- PostCode2
- PostCode3
- PoBox
- Country
- SearchTerm1
- SearchTerm2
- MDObjectID
- MDObjectKey
Balance (Abstract) Cannot be queried or read directly. See ContractAccount below.

=> Properties:
- ContractAccount (key)
- Partner
- Details:
Description
Amount
Currency
BillingDocument Can be queried or read directly using Billing Document numbers (BELNR):
=> Properties:
- DocumentNumber (key)
- InvoiceNumber
- Division
- Partner
- ContractAccount
- Contract
- BillingPeriodStart
- BillingPeriodEnd
- CreatedOn
- Estimated
.
=> Navigation Properties:
/ToEstimatedReadsFromBillDoc => Fetches the Estimated Meter Reads (note that property
Estimated will indicate whether this is likely to be successful).
BudgetBillingPlan Can be partially queried with either a Business Partner (PARTNER), a Contract
Account (VKONT) or a Contract (VERTRAG) key or read directly using Budget Billing Plan Document
numbers (OPBEL). Note: only Active Plans are considered.
Page 72 of 99
=> Properties:
- NextDueDate
- ContractAccount
- BusinessPartner
- Contract
- StartBBPeriod
- EndBBPeriod
- Status
- Amount
- OpenAmount
- Currency
BusinessPartner Can be queried or read directly using Business Partner keys (PARTNER):
=> Properties:
- PartnerNumber (key)
- Category
- Type
- Group
- ExternalNumber
- AuthorizationGroup
- Title
- Salutation
- LastName
- FirstName
- OtherLastName
- BirthName
- MiddleName
- GenderMale
- GenderFemale
- GenderUnknown
- CreatedOn
- ChangedOn
- PartnerGuid
- AddressNumber
.
/ToActiveBBPFromBP => Fetches all active Budget Billing Plans for the Business Partner;
/ToAddressesFromBP => Fetches all Correspondence Address details for the Business Partner;
Page 73 of 99
/ToBusinessPartnerActions => Fetches all of the background BDEx Master Data Actions for the
Business Partner. Note: The Actions returned can be managed using BDEx Profile ODATA;
/ToCommDetailsFromBP => Fetches the Communication details for the Business Partner;
/ToLastInvoiceFromBP => Fetches the most recent printed Invoice (Print Document) for the
Business Partner;
/ToMasterDataObject => Returns the Master Data Object details according to BDEx;
/ToWorkRequests => Fetches the open Work Requests by executing BDEx (Master Data Context
will be derived at runtime). Note: The Work Requests returned can be managed using BDEx Profile
ODATA.
CommunicationDetails (Abstract) Cannot be queried or read directly. See BusinessPartner

above.
=> Properties:
- BusinessPartner (key)
- CommunicationType (key, filterable)
- SequenceNumber (key)
- Country
- CountryISO
- StandardIndicator (filterable)
- HomeFlag
- TelephoneNumber
- TelephoneExtension
- TelephoneCombined
- CallerNumber
- FaxNumber
- FaxExtension
- FaxCombined
- SenderNumber
- FaxGroup
- EmailAddress
ConnectionObject Can be queried or read directly using a Connection Object key (HAUS):
=> Properties:
- ConnectionObjectNumber (key)
- CRMGuid
.
/ToAddressFromCO => Fetches the Address details for the Connection Object;
/ToConnectionObjectActions => Fetches all of the background BDEx Master Data Actions for the
Page 74 of 99
Connection Object. Note: The Actions returned can be managed using BDEx Profile ODATA;
/ToMasterDataObjectFromCO => Returns the Master Data Object details according to BDEx.
/ToWorkRequestsFromCO => Fetches the open Work Requests by executing BDEx (Master Data
Context will be derived at runtime). Note: The Work Requests returned can be managed using BDEx
Profile ODATA.
Contract Can be queried or read directly using a Contract key (VERTRAG):

=> Properties:
- ContractNumber (key)
- CompanyCode
- Division
- JointInvoicing
- BilllBlockReason
- BillBlockRelease
- CreatedOn
- Installation
- ContractAccount
- MoveInDate
- MoveOutDate
.
/ToActiveBBPFromC => Fetches all active Budget Billing Plans for the Contract;
/ToContractActions => Fetches all of the background BDEx Master Data Actions for the Contract.
Note: The Actions returned can be managed using BDEx Profile ODATA;
/ToMasterDataObjectFromC => Returns the Master Data Object details according to BDEx.
/ToWorkRequestsFromC => Fetches the open Work Requests by executing BDEx (Master Data
Profile ODATA.
ContractAccount Can be queried or read directly using a Contract Account key (VKONT):
=> Properties:
- AccountNumber (key)
- JointInvoicing
- Application
- BudgetBillingPlan
- Category
- Partner
- LegacyNumber
Page 75 of 99
- Name
- Currency
- Class
- BillForm
- Language
- IncPayMethod
.
/ToActiveBBPFromCA => Fetches all active Budget Billing Plans for the Contract Account;
/ToAddressesFromCA => Fetches all Correspondence Address details for the Contract Account;
/ToBalancesFromCA => Fetches all Contract Account Balances;
/ToContractAccountActions => Fetches all of the background BDEx Master Data Actions for the
Contract Account. Note: The Actions returned can be managed using BDEx Profile ODATA;
/ToLastInvoiceFromCA => Fetches the most recent printed Invoice (Print Document) for the
Contract Account;
/ToMasterDataObjectFromCA => Returns the Master Data Object details according to BDEx;
/ToOpenBalanceFromCA => Fetches only the Open Balance for the Contract Account;
/ToWorkRequestsFromCA => Fetches the open Work Requests by executing BDEx (Master Data
Profile ODATA.
Device Can be queried or read directly using an Equipment number (EQUNR only):
=> Properties:
- EquipmentNumber (key)
- Division
- CreatedOn
- ManufacturerSerialNumber
- MaterialNumber
- SerialNumber
.
/ToDeviceActions => Fetches all of the background BDEx Master Data Actions for the Device. Note:
The Actions returned can be managed using BDEx Profile ODATA;
/ToMasterDataObjectFromD => Returns the Master Data Object details according to BDEx;
/ToWorkRequestsFromD => Fetches the open Work Requests by executing BDEx (Master Data
Profile ODATA.
Page 76 of 99
DeviceLocation Can be queried or read directly using key (TPLNR):

=> Properties:
- FunctionalLocationNumber (key)
- StructureIndicator
- Category
- CreatedOn
.
/ToDeviceLocationActions => Fetches all of the background BDEx Master Data Actions for the
Device Location. Note: The Actions returned can be managed using BDEx Profile ODATA;
/ToMasterDataObjectFromDL => Returns the Master Data Object details according to BDEx;
/ToWorkRequestsFromDL => Fetches the open Work Requests by executing BDEx (Master Data
Profile ODATA.
Installation Can be queried or read directly using Installation key (ANLAGE):

=> Properties:
- InstallationNumber (key)
- Division
- Premises
- MeterReadBlockRsn
- Type
- CreatedOn
.
/ToInstallationActions => Fetches all of the background BDEx Master Data Actions for the
Installation. Note: The Actions returned can be managed using BDEx Profile ODATA;
/ToMasterDataObjectFromI => Returns the Master Data Object details according to BDEx;
/ToWorkRequestsFromI => Fetches the open Work Requests by executing BDEx (Master Data
Profile ODATA.
Invoice Can be queried or read directly using Invoice key (OPBEL):

=> Properties:
- BillingPeriod
- Estimated
Page 77 of 99
- Partner
- ContractAccount
- TotalAmount
- TotalCurrency
- CreatedOn
- PostingDate
- DocumentDate
- PrintDate
.
/ToBillDocsFromInvoice => Fetches the Billing Documents associated with an Invoice (if available).
/ToEstimatedReadsFromBillDoc => Fetches the Estimated Meter Reads (note that Attribute
Estimated will indicate whether this is likely to be successful).
InvoiceHistory (Partially Abstract) Full Invoice History can be generated by using a Master Data
Object reference to execute BDEx with or an individual Invoice key (OPBEL) can be specified if
known.
=> Properties:
- MDObjID
- MDObjKey
- ContractAccount
- BillingPeriodStart
- BillingPeriodEnd
- BillingPeriod
- PostingDate
- TotalAmount
- TotalCurrency
- CreatedBy
- NameText
- ClearingDate
- ClearingDocument
- ClearingPostingDate
- ClearingReason
- ReversalDocument
- ReversalReason
- ReversalDate
- Status
- HistoryIndicator
Page 78 of 99
LastInvoice (Abstract) Cannot be queried or read directly. See BusinessPartner and

ContractAccount above.
=> Properties:
- BillingPeriod
- Estimated
- Partner
- ContractAccount
- TotalAmount
- TotalCurrency
- CreatedOn
- PostingDate
- DocumentDate
- PrintDate
MasterDataAction (Abstract) Cannot be queried or read directly. See all Entity Types that
represent Master Data Objects.
=> Properties:
- ObjectID (key)
- ObjectKey (key)
- ActionID (key)
- ActionText
- Execute
MasterDataObject (Abstract) Cannot be queried or read directly. See all Entity Types that
represent Master Data Objects:
=> Properties:
- ObjectID (key)
- ObjectKey (key)
- ParentObjectID
- ParentObjectKey
- IconName
- NodeTooltip
- NodeText
- AddInfo
- AddInfo2
.
/ToInvHistFromMDObj => Fetches Invoice History by executing BDEx, deriving the full Master Data
Page 79 of 99
Context at runtime and analysing the Work Requests related to Invoices. Note: The Work Requests
returned can be managed using BDEx Profile ODATA;
/ToMasterDataContext => Derives and returns the full Master Data Context that would be used by
BDEx if executed;
/ToMasterDataObjectActions => Fetches all of the background BDEx Master Data Actions for the
Master Data Object. Note: The Actions returned can be managed using BDEx Profile ODATA;
/ToNotesFromMDObj => Fetches all of the Notes by executing BDEx (Master Data Context will be
derived at runtime). Note: The Work Requests returned can be managed using BDEx Profile ODATA;
/ToWorkRequestsFromD => Fetches the open Work Requests by executing BDEx (Master Data
Profile ODATA.
MeterReadingResult Cannot be queried directly but can be returned using Billing Documents and
Invoices via navigation properties. Read directly using Meter Reading Document Number key
(ABLBELNR).
=> Properties:
- BillDocNumber
- InvoiceNumber
- EquipmentNumber
- RegisterNumber
- ReadingDate
- ReadingTime
- ResultPredecimal
- ResultPostdecimal
- Active
- ScheduledDate
- Status
- IndependentValidation
- DependentValidation
- DocumentType
- DocumentCategory
- CreatedOn
- CreatedBy
- ChangedOn
- ChangedBy
Note (Abstract) Cannot be queried or read directly. See MasterDataObject above.

=> Properties:
Page 80 of 99
- NoteID (generated key)

- Text
- UserID
- NoteDate
- NoteTime
- UserName
- ClassID
- WrKey
- MDObjID
- MDObjKey
- HistoryIndicator
PointOfDelivery Can be queried or read directly using the PoD Internal Unique ID (INT_UI):
=> Properties:
- InternalID (key)
- Type
- CreatedOn
- ExternallID
.
/ToMasterDataObjectFromPoD => Returns the Master Data Object details according to BDEx;
/ToPointOfDeliveryActions => Fetches all of the background BDEx Master Data Actions for the
Point of Delivery. Note: The Actions returned can be managed using BDEx Profile ODATA;
/ToWorkRequestsFromPoD => Fetches the open Work Requests by executing BDEx (Master Data
Profile ODATA.
Premises Can be queried or read directly using the Premises key (VSTELLE):
=> Properties:
- PremisesNumber (key)
- ConnectionObject
- Type
- CreatedOn
.
/ToMasterDataObjectFromP => Returns the Master Data Object details according to BDEx;
/ToPremisesActions => Fetches all of the _background BDEx Master Data Actions for the
Page 81 of 99
Premises. Note: The Actions returned can be managed using BDEx Profile ODATA;
/ToWorkRequestsFromP => Fetches the open Work Requests by executing BDEx (Master Data
Profile ODATA.
WorkRequest (Abstract) Cannot be queried or read directly. See all Entity Types that have
navigation properties relating to Work Requests:
=> Properties:
- ClassID (key)
- WrKey (key)
- ObjectID
- ObjectKey
- TypeIcon
- TypeID
- TypeText
- ClassIcon
- ClassText
- SystemId
- SystemIcon
- SystemName
- SubclassID
- SubclassText
- PrimaryMDObjID
- PrimaryMDObjIcon
- PrimaryMDObjKey
- PrimaryMDObjText
- StatusID
- StatusText
- MainDate
- CreationDate
- Currproc
- CreatedBy
.
/ToWorkRequestActions => Fetches all of the background BDEx Work Request Actions for the
Work Request. Note: The Actions returned can be managed using BDEx Profile ODATA.
WorkRequestAction (Abstract) Cannot be queried or read directly. See WorkRequest above.

=> Properties:_
Page 82 of 99
- ClassID (key)
- WrKey (key)
- ActionID
- ActionText
- Execute
Page 83 of 99
GET Requests (Single Reads and Queries)

As with any OData Service, BDEx Connect obeys the OData Standard conventions of supporting HTTP
Requests with the following types: Create, Read, Update, Delete and Query.
However while this is theoretically true, at present only Queries, Reads and one very specific Update
Request are currently supported.
We fully expect BDEx Connect to expand with new Entities, EntitySets and Navigation properties in future
as and when the need arises to do so.
Queries and Single Reads are two forms of GET Requests.
Typically they take the form of specifying an Entity key or providing Select-Option values to be used as part
of a Filter.
Here are some notable examples:
READ All of the Notes for a specific Master Data Object reference, e.g. a Business Partner:
MasterDataObjectSet(ObjectID=ISU0001,ObjectKey=[BP Number])/ToNotesFromMDObj?
READ The Invoice History for a specific Master Data Object reference, e.g. a Business Partner:
MasterDataObjectSet(ObjectID=ISU0001,ObjectKey=[BP Number])/ToInvHistFromMDObj?
READ All of the Estimated Meter Readings (Entities) for a given Invoice (where the Estimated
property is True):
InvoiceSet([Invoice Document Number])/ToEstimatedReadsFromInvoice?
QUERY All open BPEMs for a specific Business Partner:

BusinessPartnerSet([BP Number])/ToWorkRequests?&$filter=ClassID eq ISU_BPEM
QUERY Find Contract Accounts that have an old Legacy Account reference
ContractAccountSet?&$filter=LegacyNumber eq OLDACC101
QUERY Find Standard Addresses for a specific Business Partner:

BusinessPartnerSet([BP Number])/ToAddressesFromBP?&$filter=StandardAddress eq true
Page 84 of 99
QUERY Find Standard Telephone Numbers for a specific Business Partner:

BusinessPartnerSet([BP Number])/ToCommDetailsFromBP?&$filter=CommunicationType eq TEL
and StandardIndicator eq true
Page 85 of 99
PUT Request (Update)

BDEx Connect currently supports a single Update Request designed to support the execution of
Background Actions (for Master Data Objects or Work Requests).
As a proof of concept the example illustrated below is supplied as standard which is the background closure
of a BPEM Case.
In order to succeed the composition of this type of HTTP Request needs to be precise. To keep things as
simple as they can be weve made sure the payload is light, so only the Action Entity itself is needed along
with its Execute property set to True. This way BDEx Connect can be certain the Action Entity is being
executed.
Once the appropriate Action Entity has been identified, this could be gleaned from a previous GET Request,
the submission of the PUT Request requires no additional effort other than the explicit setting of the
Execute property.
Note that upon successful execution the HTTP Response will be simply a status of 204 with no actual
message content:
Page 86 of 99
Note: The Background Action setting can be found in Configuration Table /BTI/MDE_C_ACT
Page 87 of 99
XML (Default) Format example

BDEx Connect acts in a similar fashion to the Customer Centric Hub in that it can be provided with a single
Master Data Object and from that object build a Master Data Context and search for related Work Requests
as a response.
In the example below the starting Master Data Object is a Business Partner:
http://[server]/sap/opu/odata/BTI/MDE_ODATA_ISU_SRV/
BusinessPartnerSet(0000000650)/ToWorkRequests?&$format=xml
The OData Service response in XML might resemble the following:
Note: The addition of the Uniform Resource Identifier (URI) Option &$format=xml is always assumed as the
default by SAP Gateway if not actually specified in the HTTP Request.
Page 88 of 99
JSON Format example

By the addition of a simple Uniform Resource Identifier (URI) Option the output of BDEx Connect can be
switched to JSON.
BusinessPartnerSet(0000000650)/ToWorkRequests?&$format=json
Page 89 of 99
XLSX Format example

By the addition of a simple Uniform Resource Identifier (URI) Option the output of BDEx Connect can be
switched to XLSX and displayed in a Browser session.
BusinessPartnerSet(0000000650)/ToWorkRequests?&$format=xlsx
Page 90 of 99
Appendices
Page 91 of 99
Out of the Box Actions

Out of the Box BDEx Actions:
BDEx provides 295 out of the box right click actions available in the Customer Centric Hub. These actions
are:
Master Data Object or Work

Action ID SAP Transaction Code Action Description
Request
AC0001 CAA2 Display contract account Contract Account
AC0002 CAA3 Change contract account Contract Account
AC0003 EASIBI Invoicing Contract Account
AC0004 FPM3 Display dunning history Contract Account
AC0005 FPR3 Display installment plans Contract Account
AC0006 FPPHN Display prenotification history Contract Account
AC0007 ECENV_BP Data environment Contract Account
AC0008 CORRHIST Display correspondence history Contract Account
AC0009 FPL9 Display account balance Contract Account
AC0010 EA40 Display print documents Contract Account
AC0011 FPR1 Create installment plans Contract Account
AC0012 FPR2 Change installment plans Contract Account
AC0013 EABICO Billing correction Contract Account
AC0014 FPE1 Post Document Contract Account
AC0015 FPE3 Display Document Contract Account
AC0016 FPE2 Change Document Contract Account
AC0017 FP08 Reverse Document Contract Account
AC0018 EA13 Full Reversal Contract Account
AC0019 Change move-in document Contract Account
AC0020 EASIBI Bill and Invoice Contract Account
AC0021 EA19 Create or Simulate Invoice Contract Account
AC0022 CAA1 Create Contract Account Contract Account
Page 92 of 99
AC0023 FPSEC3 Display Security Deposit Contract Account

AC0024 FPSEC2 Change Security Deposit Contract Account
AC0025 FP04 Write off History Contract Account
AC0026 FP40 Transfer Items Contract Account
AC0027 FP07 Reset Cleared Items Contract Account
ACTI0001 Display activity Interaction Record
ACTI0002 Change activity Interaction Record
ALCK0001 CAA2 Maintain contract account lock Account Lock
ALCK0002 CAA2 Remove contract account lock Account Lock
ALCK0003 CAA2 Change contract account lock Account Lock
ALCK0004 CAA3 Display contract account lock Account Lock
ALCK0005 FPL9 Display account balance Account Lock
ALCK0006 FPM3 Display dunning history Account Lock
ALCK0007 Display Invoice Lock Account Lock
ALCK0008 ES22 Display contract Account Lock
ALCK0009 ES21 Change contract Account Lock
ALCK0010 Display document Account Lock
ALCK0011 Change document Account Lock
ALCK0012 Display line item Account Lock
ALCK0013 Change line item Account Lock
BCHK0001 ES32 Display installation Billing Check Failure
BCHK0002 ES31 Change installation Billing Check Failure
BCHK0003 ES22 Display contract Billing Check Failure
BCHK0004 ES21 Change contract Billing Check Failure
BCHK0005 CAA2 Change contract account Billing Check Failure
BCHK0006 EG71 Display rate Billing Check Failure
BCHK0007 EASICH Re-run billing check Billing Check Failure
BDCI0001 Display BDoc BDoc (IS-U)
BDCO0001 Display BDoc BDoc (IS-U)
BDOCDISCL Display classic BDoc message BDoc (CRM)
BDOCDISEXL Display extended BDoc message BDoc (CRM)
Page 93 of 99
BDOCDISP Display BDoc BDoc (CRM)

BDOCOL Display object links BDoc (CRM)
BDOCREP Reprocess BDoc BDoc (CRM)
BORD0001 EASIBI Bill billing order Billing Order
BORD0002 Display billing order Billing Order
BORD0003 ES22 Display contract Billing Order
BORD0004 ES32 Display installation Billing Order
BORD0005 EASIBI Perform billing Billing Order
BORD0006 Display billing order trigger Billing Order
BORD0007 EL37 Reverse Meter Readings Billing Order
BOUT0001 EA05 Display billing outsort Billing Outsort
BOUT0002 EA05 Release billing outsort Billing Outsort
BOUT0003 EA22 Display billing document Billing Outsort
BOUT0004 EA20 Reverse billing document Billing Outsort
BOUT0005 Display log Billing Outsort
BOUT0006 FPL9 Display account balance Billing Outsort
BOUT0007 EA21 Adjustment Reversal Billing Outsort
Delete Adjustment Reversal Doc.
BOUT0008 EA24 Billing Outsort
Number
BP0001 BP Display business partner Business Partner
BP0002 BP Change business partner Business Partner
BP0003 BCT2 Display most recent contact Business Partner
BP0004 CORRHIST Display correspondence history Business Partner
BP0005 FPL9 Display account balance Business Partner
BP0006 ECENV_BP Data environment Business Partner
BP0007 FPM3 Display dunning history Business Partner
BP0008 ECVBP02 Customer data Business Partner
BP0009 EA40 Display invoice/print documents Business Partner
BP0010 ESWTMON01 Display related switch documents Business Partner
BP0012 EC50E Create move-in Business Partner
BP0013 EC52E Display move-in documents Business Partner
Page 94 of 99
BP0014 BCT0 Create contact Business Partner

BP0015 BCT2 Display contacts Business Partner
BP0016 FPCR1 Display credit worthiness Business Partner
BP0017 ES51 Create owner allocation Business Partner
BP0018 ES53 Display owner allocation Business Partner
BP0019 ES54 Reverse owner allocation Business Partner
BP0020 INVMON Inbound bill monitoring Business Partner
BPEM0001 EMMAC3 Display case BPEM Case
BPEM0002 EMMAC2 Change case BPEM Case
BPEM0003 Close case BPEM Case
BPEM0004 EMMACL Display case list BPEM Case
BPEM0005 Assign case BPEM Case
BPEM0006 Accept case BPEM Case
BPEM0007 Forward case BPEM Case
BPEM0008 Cancel case BPEM Case
BPEM0009 Reopen case BPEM Case
BPEM0010 Put case back in queue BPEM Case
BPEM0011 Complete case BPEM Case
BPEM0012 Change case note BPEM Case
BPEM0013 Reassign case BPEM Case
BPEM0014 Complete case (with note) BPEM Case
BPEM0015 Confirm Case BPEM Case
BPEM0016 Complete and confirm (with note) BPEM Case
CBLK0001 ES22 Display contract Contract Bill Block
CBLK0002 ES21 Change contract Contract Bill Block
CBLK0003 ES21 Remove block Contract Bill Block
CBLK0004 FPM3 Display dunning history Contract Bill Block
CBLK0005 CAA3 Display contract account Contract Bill Block
CBLK0006 CAA2 Change contract account Contract Bill Block
CBLK0007 FPL9 Display account balance Contract Bill Block
CIWI0001 FP03H Display collection history Collection Work Item
Page 95 of 99
CIWI0002 FPM3 Display dunning history Collection Work Item

CIWI0003 FPR3 Display installment plan overview Collection Work Item
CIWI0004 CORRHIST Display collection item history Collection Work Item
CIWI0005 FPL9 Display account balance Collection Work Item
CO0001 ES57 Display connection object Connection Object
CO0002 ES56 Change connection object Connection Object
CO0003 ECENV_CO Data environment Connection Object
CO0004 IW51 Create Service Notification Connection Object
COLI0001 CORRHIST Display collection history Collection Item
COLI0002 FPM3 Display dunning history Collection Item
COLI0003 FPR3 Display installment plan overview Collection Item
COLI0004 FP03H Display collection item history Collection Item
COLI0005 FPL9 Display account balance Collection Item
CONT0001 BCT2 Display contact Business Contact
CT001 ES22 Display contract Contract
CT002 ES21 Change contract Contract
CT003 CAA3 Display contract account Contract
IN0015 EG71 Display Rate Data Installation
IN0016 EA05 Perform Billing Installation
IN0017 Reverse bill order Installation
IN0018 Display Installation Facts Installation
IN0019 EL29 Correct Plausible Meter Reads Installation
INVO0001 EA05 Display invoice outsort Invoice Outsort
INVO0002 Change invoice document Invoice Outsort
Release invoice document
INVO0003
Invoice Outsort
INVO0004 EA13 Reverse invoice document Invoice Outsort
INVO0005 Invoice overview Invoice Outsort
INVO0007 Display log Invoice Outsort
INVO0008 EA22 Display billing document Invoice Outsort
INVO0009 FPL9 Display account balance Invoice Outsort
Page 96 of 99
INVO0010 EA21 Adjustment Reversal Invoice Outsort

INVO0011 EABICO Billing Correction Invoice Outsort
INVT0001 EA22 Display billing document Invoice Trigger
INVT0002 FPL9 Display account balance Invoice Trigger
INVT0003 CAA3 Display contract account Invoice Trigger
INVT0004 BP Display business partner Invoice Trigger
INVT0005 EA22 Reverse billing document Invoice Trigger
INVT0006 EASIBI Perform invoicing Invoice Trigger
INVT0007 EASISI Simulate invoicing Invoice Trigger
INVT0008 EASICH Overall billing check Invoice Trigger
INVT0010 CAA2 Change contract account Invoice Trigger
INVT0011 Display invoice trigger Invoice Trigger
INVT0012 EA21 Adjustment Reversal Invoice Trigger
Delete Adjustment Reversal Doc.
INVT0013 EA24 Invoice Trigger
Number
INVT0014 Display Installation Facts Invoice Trigger
IPLN0001 FPR3 Display Installment Plan Installment Plan
IPLN0002 View history Installment Plan
IPLN0003 FPR2 Deactivate installment plan Installment Plan
LEAD0001 Display lead CRM Marketing Lead
MOVI0001 Display parked documents Parked Move In Document
MOVI0002 Change parked documents Parked Move In Document
MOVO0001 Display parked documents Parked Move Out Document
MOVO0002 Change parked documents Parked Move Out Document
MTRO0001 EL37 Reverse meter reading order Meter Reading Order
MTRO0002 EL28 Enter meter reading Meter Reading Order
MTRO0004 ES32 Display installation Meter Reading Order
MTRO0005 IQ03 Display device Meter Reading Order
MTRO0006 EL01 Create meter reading order Meter Reading Order
No Device Installed (for active
NODV0001 Full device installation
Contract)
Page 97 of 99
No Device Installed (for active

NODV0002 Billing-related installation
Contract)
PO0001 EEDM11 Display point of delivery Point of Delivery
PO0002 EEDM10 Change point of delivery Point of Delivery
PO0003 ESWTMON01 Display related switch documents Point of Delivery
PO0004 EEDMIDESERVPROV03 Display service providers Point of Delivery
PO0005 EDATEXMON01 Data exchange monitoring Point of Delivery
PR0001 ES62 Display premise Premise
PR0002 ES61 Change premise Premise
PR0003 ECENV Data environment Premise
PRDC0001 Display invoice Invoice Print Document
PRDC0002 Correct invoice Invoice Print Document
PRDC0003 Display account balance Invoice Print Document
PRDC0004 Preview invoice Invoice Print Document
PRDC0005 Reverse Invoice Invoice Print Document
CRM Replication Failure
REPL0001 ECRMREPL Display replication error
(ECRMREPL)
CRM Replication Failure
REPL0002 ECRMREPL Display replication queue
(ECRMREPL)
SNTF0001 IW53 Display service notification Service Notification
SNTF0002 IW52 Change service notification Service Notification
SORD0001 IW33 Display service order Service Order
SORD0002 IW32 Change service order Service Order
SWDC0001 ESWTMON01 Display switch document Switch/Process Document
SWDC0002 ESWTMON01 Switch document overview Switch/Process Document
SWDC0003 EEDM11 Display related point of delivery Switch/Process Document
SWDC0004 BP Display related business partner Switch/Process Document
SWDC0005 EDATEXMON01 Data exchange monitoring Switch/Process Document
SWDC0006 EEDMIDESERVPROV03 Display related service providers Switch/Process Document
WFLW0001 Display workflow Workflow
WFLW0003 Restart workflow Workflow
WITM0001 Execute work item Work Item
Page 98 of 99
WITM0002 Display work item Work Item

WITM0003 Forward work item Work Item
WITM0004 Replace work item Work Item
WITM0005 Display parent workflow Work Item
WITM0006 Reserve work item Work Item
Page 99 of 99

SAP BDEx Config Guide

Uploaded by

Copyright:

Available Formats

SAP BDEx Config Guide

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SAP BDEx Config Guide

Uploaded by

Copyright:

Available Formats

BDEx -

BDEx Overview ........................................................................................................................................... 3

BDEx Work Request Types ........................................................................................................................ 6

Installation and Activation ....................................................................................................................... 18

Configuration Options and the IMG......................................................................................................... 20

Customer Centric Hub Configuration ...................................................................................................... 25

Closure Control ........................................................................................................................................ 49

The Dynamic Work Center ....................................................................................................................... 64

BDEx Connect OData Service (SAP Gateway) ..................................................................................... 67

The Customer Centric Hub

BDEx Customer Centric Hub:

A customer centric view of all open work and exceptions.

BPEM Closure Control:

Dynamic Work Center:

BDEx Work Request Types

Billing and Invoicing.

IS-U Customer Service.

Implausible Meter Readings

Open Meter Reading Orders

Smart Meter Communication (AMI Inbound / Outbound)

Billing and Invoicing

Open Billing Orders

Billing Check Failures

Contract Billing Blocks

Invoice Print Document

Contract Account Locks

Collection Agency Items

Failed Dunning Proposals

CRM Replication Failures (ECRMREPL)

Failed BDocs (Inbound & Outbound)

Interaction Records / Business Activities

IS-U Customer Service

Parked Move-In Documents

Parked Move-out Documents

Data Exchange Tasks

iDocs (Inbound & Outbound)

Installation and Activation

SAP System ID: 3 character system SAP system ID (e.g. SD1)

Configuration Options and the IMG

3. Use the search help function to select a new Enhancement ID.

4. Create a new enhancement ID.

9. The node is now available in the SAP customizing menu.

Customer Centric Hub Configuration

System Configuration and Connectivity

Define systems and RFC destinations

Field Example value

System name ECC production client 100

Field Example value

Master Data Configuration

Master data objects

Work Request Configuration

Work request classes

Relate work requests to BOR objects

Work Requests relating to BOR objects

Work Request estimated resolution times

Work Request Primary Object Priorities

Action Header Configuration

Master Data Actions

Action ID The ID of the action