With the advent of deregulation, smart meters, and the need for prompt and efficient demand response, the utility industry faces an increasingly complicated landscape. Many utilities have begun implementing SAP CRM front ends to help them service their customers. Integrating this system with an SAP Industry Specific Solution – Utilities (SAP IS-U) back end, however, presents its own challenges, and many data and replication errors may occur during this integration.

Most data errors when replicating between SAP CRM and SAP IS-U are due to inadequate understanding of the SAP CRM/SAP IS-U data model or incorrect data. This data model is at the core of cross talk between SAP CRM with SAP IS-U for both regulated and deregulated utilities.

We provide a high-level overview of business processes in the utilities industry. We then introduce the SAP CRM–SAP IS-U data model and explain the various connections between objects in each system and how they integrate. Finally, we note various sources of data replication errors between SAP CRM and SAP IS-U, and outline best practices for avoiding them.

Data Model, Data Flow, and Data Validation

The SAP CRM IS-U data model is fundamental to the integration of the SAP CRM front end with SAP IS-U processes. Figure 1 shows the SAP CRM objects, such as a business agreement, the interrelationship between the different objects, and the corresponding object in SAP IS-U. A clear understanding of the corresponding objects in SAP CRM and SAP IS-U offers insights and an approach to resolve issues and problems. Note that there is no leading system (i.e., a system in which the data originates) for technical master data because you can create the technical master data in both SAP CRM and SAP IS-U.

Figure 1

The relationship between SAP CRM objects and SAP IS-U objects in the SAP CRM IS-U data model

Technical Master Data versus Business Master Data

Before we proceed, we need to define installation, premise, connection object, device location, point of delivery, and the Electrical Service Identifier (ESI ID). An installation is a connection between the premise, device, and a utility contract. It contains data relevant to billing. It is not a technical object. A premise is a place where electricity is delivered. A connection object is a building, property, or physical location such as a construction site. It is allocated an address; thus, it links premises, device locations, and connections. A point of delivery (POD) describes the point or place where a utility service is supplied for a customer. A device location is a place within a connection object where devices are installed. A device, in a limited sense, represents a meter. A meter has a unique identification number allocated to the meter or device. In the electrical industry, the ESI ID is the number uniquely allocated to the meter.

All the aforementioned terms, except installation, are examples of technical master data. Technical master data contains the address location for the premise and installation, not to be confused with the business partner address, which is the customer’s contact address. Finally, business master data is created and changed in SAP CRM, whereas technical master data is created and changed in SAP IS-U, or in the SAP CRM Interaction Center. Table 1 lists the connections between SAP CRM master data and SAP IS-U master data.

Table 1

Connections and integrations for technical master data between SAP CRM and SAP IS-U

* For each line item (POD ID) in an SAP CRM service contract, an SAP IS-U contract is created. An SAP CRM service contract as a whole does not have a corresponding object in SAP IS-U. An SAP CRM service contract acts as a container for all the line items (corresponding to SAP IS-U contracts) in it.

Business Partner

A business partner is an entity, such as a customer or supplier, with whom a business has a relationship. In SAP CRM, a business partner is an object under which business agreements, service contracts, and other objects are organized. The corresponding object for a business partner in SAP IS-U is also called a business partner, or a sold-to party.

SAP CRM Business Agreements and SAP IS-U Contract Accounts

A business agreement is an SAP CRM object used by several SAP IS solutions, including Public Sector, Waste, Telecommunications, and Utilities. It is used to capture data about long-term business relationships with a business partner. A business partner may have one or several business agreements. Business agreements are relevant for billing purposes: Controlling data in a business agreement is used for invoicing, contract accounts receivable and payable, taxation, dunning, account balance, and other processing to the active Contract Accounts Receivable and Payable (FI-CA) in the SAP landscape.

The corresponding object for a business agreement in SAP IS-U is the contract account within FI-CA. The two objects are linked to each other via their GUID, the unique identifier for each object in SAP CRM. Having a sold-to party role created and replicated in both SAP CRM and SAP IS-U is a prerequisite for the successful creation of a contract account in SAP IS-U from a business agreement in SAP CRM and vice versa. A 1:1 relationship exists between each business agreement and contract account. A 1:1 relationship between the business agreement class in SAP CRM and the contract account category in SAP IS-U is also technically possible, but not a requirement.

In SAP IS-U, a contract account combines all contracts that have the same payment and customer class. A business agreement can be used in future contracts as well. Thus, a business agreement can also be reused in other business transactions. The number range of the SAP CRM business agreement and its corresponding SAP IS-U contract account can be the same depending on business requirements and configuration. Thus, for billing and invoicing purposes, only a few relevant fields from the business agreement are replicated to the contract account, although this also depends on business requirements and configuration.

SAP CRM Service Contracts

SAP CRM service contracts are documents used to specify the terms of a long-term service agreement between a company and a customer. As noted in Table 1, there is no corresponding object in SAP IS-U. The components of an SAP CRM service contract are detailed later.

Electric Service Identifiers (ESI IDs)

An ESI ID represents a unique location at which electric service is provided. In other words ESI IDs are the POD identifier for an electrical utility. ESI IDs are also objects in SAP CRM, and they are attached as line items on an SAP CRM service contract. An SAP CRM service contract can have one or several line items, and each represents an ESI ID.

In SAP IS-U, an installation is attached to an SAP IS-U contract. Each contract has a 1:1 relationship with an installation. The installation represents an ESI ID or POD and is attached to an SAP IS-U contract. An SAP IS-U contract is an agreement between a utility company and the customer that forms the basis for billing the customer. All SAP IS-U contracts belonging to a particular customer that are invoiced collectively are grouped under the same SAP IS-U contract account.

ESI IDs under the same service contract can be grouped under one or more business agreements. In other words, each item of a service contract may have different payment terms and be invoiced differently from others if required.

Connection Objects

In service contracts, the installed base (IBase) is represented by a connection object. Within the connection object, a POD is allocated, thus making the connection object and POD a two-level hierarchy. PODs cannot be replicated without the corresponding connection objects. An IBase POD in the object list is allocated to an SAP CRM contract line item that is equivalent to the SAP IS-U contract (table EVER) or simply a contract header in SAP IS-U (table EVERH).

PODs and ESI IDs have unique GUIDs to identify them. The GUID serves as a common key (linking SAP CRM and SAP IS-U). For successful replication, linking the key in both systems is mandatory. This linkage is done by a code snippet. Consequently, any error in which GUIDs are absent is classified as a program error, and you should search the relevant SAP Notes or raise an OSS message. You can see errors associated with contracts in SAP IS-U using transaction code ECRMREPL.

Master Agreements

Master agreements hold values for aggregate contracted volume, which is represented by a virtual POD (VPOD). A VPOD is a POD with a master agreement indicator. It reflects an aggregated contracted volume for all the ESI IDs or PODs under that master agreement. It is used for cross-contract billing. As mentioned earlier, the corresponding object for the SAP CRM master agreement in SAP IS-U is the outline contract. The relationship between a master agreement and service contract is detailed later.

Figure 2 illustrates how several SAP CRM service contracts can use contracted volume from the same master agreement. Each of these service contracts can have multiple line items, each representing an ESIID.

Figure 2

The relationship between a master agreement and an SAP CRM service contract

Thus, a master agreement can hold contracted volume that can be used by one or several ESI IDs of the same or multiple service contracts. The master data template CRMOUTLCONTRACT is available for creating master agreements in SAP IS-U. You can integrate condition types in the price agreement of an outline agreement using the prices in the master data template. If the parameter OUCONT is not used correctly in the master data templates for ESI IDs and PODs, then it creates data inconsistencies.

Technical Object Relationships

Connection objects and PODs or ESI IDs represent technical objects and can be created and changed in the SAP IS-U and SAP CRM. ESI IDs (which represent technical objects) can be generated in SAP CRM in the Interaction Center (never using the Easy Access menu) and created in SAP IS-U via the master data generator. When technical master data is generated in the Interaction Center, it has to be linked to an SAP IS-U contract before uploading. Not understanding this requirement creates replication errors that are seen under the Business Document (BDoc) BUS_TRANS_MSG (via a Business Add-In [BAdI]). Thus, to ensure data consistency, technical objects can be changed in SAP CRM only after they have been replicated successfully from SAP IS-U. Figure 3 shows the correlations of master data between the two systems explained in previous sections.

Figure 3

Mapping of SAP IS-U data in SAP CRM

Replication Errors: Master Data Template and Master Data Generator

The master data template generates the master data for the SAP IS-U system. Changes are often made to the master data template. Changes to the master data template or missing master data template (dependent) parameters in the SAP IS-U back end system may result in mass BDoc errors. While testing the master data template for changes, the system creates or changes master data. You must exercise caution while testing, as these changes cannot be reversed. You can monitor the changes using transaction code ECRMREPL. Once you fix an error in the master data template (MDT), transactions with replication errors can be reprocessed. Figure 4 illustrates how master data is created and subsequently replicated across the system.

Figure 4

Origin and flows of master data (SMW01, SMQ2, and SMQ1 are common transaction codes to view SAP CRM middleware.)

Replication Errors: Process Maturity

Process maturity is a state of the production landscape in which business processes are optimized for performance to the expected standards. Proper controls are implemented around the system so that redundancies and inconsistencies are removed beforehand to achieve optimal performance for business transactions. In other words, this is the ideal state of a system landscape in which change processes are designed in such a way that although the system is highly customized to meet unique business requirements, the overall performance and sanctity of system is not compromised. Some of the issues standing in the way of a mature landscape are described in the next section.

Master Data Duplication

Occasionally, multiple business partner records are for the same customer. This duplication leads to issues in account reconciliation and eventually to asynchronous data between systems. Several add-ons are available from SAP and other certified vendors that help in reconciling master data. Repairing master data duplication or other issues with master data should be a top priority because it affects downstream processes and dependencies. Best practices dictate dedicated centralized teams should be responsible for creating master data.

Appropriate Workflows for Business Scenario

Building validations that provide alerts when inconsistencies are created in the system and triggering workflows appropriately help in avoiding replication errors. An example is a product swapped by a customer midway in the Meter Read (MR) cycle without ascertaining the pending billing. If the dates are changed and replicated to SAP CRM, this would ideally throw an error, handled by Business Process Exception Management (BPEM). Then the dates would be populated manually after billing issues were addressed.

Similarly, inappropriate workflows may populate data in SAP CRM if adequate validations are not carried out. In the preceding example, an inappropriate workflow may cause the swap dates to be populated without the sales associate evaluating them. This inappropriate workflow would lead to asynchronous data and replication errors. Thus, validations and workflows are critical in capturing the logical sequence of the relevant business processes.

Another example would be a change of plan. When a change of plan is effected, settlement is carried out in the back end for the previous plan. Once the settlement is done, the security deposit associated with the old plan needs to be transferred to the new plan. Security deposits transferred using workflows need to populate both SAP CRM and SAP IS-U simultaneously. If workflows are populating only one system or the other, that causes asynchronous data and results in replication errors.

Kernel Patches, Support Packages, and SAP Notes

Within a highly customized environment, you need to evaluate several possibilities before implementing kernel patches, Support Packages, or updates in accordance with SAP Notes. There is an obvious risk in incorporating any of these, as they may cause integration issues.

Kernel errors sometimes cause data inconsistency owing to errors in update requests. An example from the past is Kernel 700 patch level 221 (SAP Note 1223994). SAP Note 1223994 offers an explanation of the issues involved with SAP CRM and SAP IS-U. Inconsistent business data in the application tables can throw replication errors. A permanent workaround for such errors is upgrading to the recommended kernel, a routine procedure. Refer to SAP Note 19466 for additional information. The update should be thoroughly tested and progressively moved to higher environments (for integration and other issues) before putting it into production. However, environments where upgrades are not possible, such as those with heavily customized code, may require a workaround depending on the scenario.

Queue Blocked Because of Unavailability of SAP IS-U

Locking can happen for several reasons, including the logical disconnect of data. Locking can also occur owing to multiple accesses to data, whether from manual connections, through interfaces, or by workflows. Any further triggering without resolving the root cause for blocking is scarcely worth the effort.

Occasionally, an infinite loop in an enhanced program locks an object. This locked object is not available for further transactions. Data open in SAP Key Account Manager is always in edit mode. Unless the transaction is closed and the buffer is cleaned, it is not available for further processing. This access issue can be resolved by adequate controls on enhanced programs. Users should be made aware that they need to properly log out of a transaction.

SAP Middleware Tables

Specific middleware tables need regular maintenance. Middleware tables SMW3_BDOC, SMW3_BDOC1, SMW3_BDOC2, SMW3_BDOC4, SMW3_BDOC5, and SMW3_BDOC6 grow quickly to enormous sizes. These tables thus need regular maintenance. Business and IT need to have a common strategy and consensus on deleting BDocs. Both sides should collaborate to clear those Basis tables. This is often the most neglected task in an IT organization.

Authorization for Move-In Cancellation

Move-In represents the physical installing of electrical service. Move-In cancellation should not be carried out when billing is pending. Move-In cancellation without adequate authorization may lead to replication errors because users may not have visibility over other existing future-dated contracts that overlap.

Replication Errors: Data Inconsistency

Master and transactional data should be consistent across the system. Data that is synchronized across systems is a critical requirement for conducting business transactions. However, data  often falls out of sync and creates bottlenecks for subsequent transactions. Some examples of this are detailed in the next section.

Missing Outline Contract

When an outline contract is missing, an SAP CRM service contract throws errors during replication. Evaluation of the master data from CRMD_ORDER reveals that the master agreement has an error. Generally, errors are either associated with overlapping dates or expired dates, or else the ESI ID is with another sold-to party. Correcting the errors and changing the status help resolve the issue. Once the corrected data is saved, the master agreement is checked in SAP IS-U in the relevant tables (EVERH and EANL) for errors or association with nonrelevant transactions. If the data is consistent, you can proceed to transaction code ECRMREPL and reprocess the transaction. Figures 5 and 6 show an error associated with replication of a master agreement.

Figure 5

Master agreement not replicating to SAP IS-U

Figure 6

Correct dates and reprocess the BDoc

Contract Dates

In Figures 5 and 6, SAP CRM service contract dates were out of sync with the master agreement. After correcting the dates, you resolve the replication issue. Correcting the dates and reprocessing the BDoc corrected the replication issue (Figure 5). Incorrect contract dates, often owing to lack of training, commonly contribute to replication errors. A contract should have a planned term end date and a contract start date. Both these dates reflect the duration of the contract. When the contract is renewed, the contract is given an end date, a start date, and a planned term end date. The contract can be successfully renewed or the switch successfully made only after the contract is given these three attributes. Different ESI IDs may also have different MR cycles and consequently different SAP IS-U contract end dates. SAP IS-U contract end dates reflect the MR cycle. Errors may ensue if the dates are overlapping or incorrect. Correcting the dates in SAP CRM as per SAP IS-U dates (from tables EVERH/EANL) and saving the data in SAP CRM should help resolve problems associated with date issues.

Business Agreement with Missing GUID

As cited in the “Connection Objects” section of this article, missing GUIDs are a program error. The initial issue was discovered in the SAP CRM service contract. Evaluating the SAP CRM service contract data revealed that there were no issues with transactional data. Transaction code ECRMREPL displayed an error with technical data. An error message in a service order revealed issues with the master agreement. All data from the master agreement was in sync in both SAP CRM and SAP IS-U. However, the business agreement was found to have errors. The BDoc revealed a message showing the root cause to be an error with the program. SAP Note 1298097 was a permanent fix. This Note deals with an error involving the linkage of the GUID from SAP CRM with a corresponding ISU object.

Inadequate Authorization

While using a few transaction codes such as EEDM10, you change from the display mode to the change mode or create mode and get the message that you are not authorized to use this transaction code (Figure 7). This blocked access is due to a program error, and the relevant codes are incorporated with the latest upgrade. Researching and implementing the relevant SAP Notes for earlier versions is required.

Figure 7

Inadequate authorization error in SAP IS-U

Mandatory Field Missing

When contracts are created by batch or by a standard Web user (JCOUSER), the Employee Responsible (or Sales Agent), which is a mandatory field per the configuration, is missing. This issue prevents downstream actions such as creating switch documents from being executed. One possible workaround is scripting, which is time-consuming to query and run. Manual inputting of data into this field may add to the total cost of ownership (TCO). Also, training issues have been identified around this issue. Both issues may occur individually or coexist. Adequate knowledge of the concept of a business partner is a must, as users often input their names into the Contact Person field, despite their not having the contact person role assigned to them. A proper validation and alert at the front end or data source that validates data before saving it as a transaction is a possible fix to such issues.

Move-In Cancelled Not Deleted

Ideally, after a contract is created, Move-In is triggered, and billing documents are created. Occasionally, Move-In is canceled. However, if settlement is pending, then it won’t let the Move-In cancel until the pending bills are settled. Thus, if settlements are pending, if users are trying to cancel Move-In, and if the user has no visibility of these pending settlements (charges), then he or she tries to cancel the Move-In. This attempt to cancel the Move-In results in a replication error. The problem can be resolved by implementing a validation that checks the pending bill in the back end (FI-CA) and throw an alert before cancelling the Move-In in SAP CRM. Inadequate validation at the front end results in sales associates cancelling the Move-In and creating asynchronous data as a consequence.

Mismatching Date on SAP CRM Contracts

Occasionally, data is changed forcibly (in debug mode) without following the established process. Such changes to data cause inconsistency because data follows processes. Validating and fixing the overlapping contract start and contract end dates in contracts and other relevant transactions by using adequate processes should clear the replication errors.

Best Practices

Replication errors can significantly increase the TCO and compromise the performance of the concerned business unit. Conversely, streamlined replication can significantly decrease the TCO and help improve the key performance indicators (KPIs) for the business units in question. In addition to the tangible benefits, several intangible benefits – such as user satisfaction – can add to user acceptance and better customer value. Thus, adopting best practices and addressing replication issues in a timely fashion are critical steps in building a virtuous cycle.

SAP Test Data Migration Server (SAP TDMS) mimics the production data in a limited way. For testing purposes, a heavily customized landscape needs data (for testing purposes) that mimics a production environment. SAP TDMS helps fill in this gap. In addition, SAP TDMS can be used to refresh test systems regularly with master and transactional data based on data reduction rules. SAP TDMS does require a separate license.

We recommend following best practices for problem resolution in landscapes using SAP CRM and SAP IS-U:

1. Focus on training sessions and increase process knowledge within the user community. Understanding the functionality and using the recommended processes prevent replication issues.
2. Keep the process lean to match business (process) needs. Processes should successfully capture the logical sequence of transactions, such as workflows and validations. Limit the scope to your core business process so that processes are captured realistically.
3. Have a clear strategy between IT and business users on housekeeping and maintenance of the Basis tables. Break down the silos – coordination between business and IT is critical.
4. Logging, classification, prioritization, tracking, and service restoration for issues and problems are key to service operations.
5. A known errors repository or database for problems should be created and referenced for any and all future issues.
6. Adopt objective means of measurement and metrics to track the performance of IT support.
7. Proactive problem management identifies problems by reviewing incident trends and nonincident data to predict that an incident is likely to recur.
8. Always focus on identifying the main and contributing root causes for a problem and set up a review process for addressing root causes and corrective actions.
9. Always have a centralized team for creation of master data. Performance and load tests are advised after significant software and especially interface changes. There are several tools also available in the market to do this step.

Ash (Shashank) Heda

Ash Heda is working as a Principal for Managing Consulting Services within the SAP energy (utilities), communication, and services (SAP ECS) practice for Infosys Ltd. He has been responsible for managing portfolio for different initiatives within the generation, transmission, and distribution for the utilities market. As an SAP consultant, Ash has worked within the SAP IS-U/CREB and SAP CRM for utilities, retail, and other verticals for more than 15 years. He has worked on implementing several utilities projects (regulated and deregulated) from design to implementation and support. He has significant understanding of the SDLC cycle, application lifecycle management and ITIL framework. He has keen insight on the challenges within the utility industry and deep hands-on experience in implementing a seamlessly integrated meter-to-cash customized solution. Ash has worked extensively on integrating prospect-to-cash processes for various verticals such as consumer products, fast-moving consumer goods, pharmaceuticals, and healthcare. Additionally, he is a thought leader contributing to smart meter, demand response management, pricing signal, and realigning and modeling processes. His LinkedIn profile can be viewed here: LinkedIn.

You may contact the author at ash1201@gmail.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.

Shailesh Sinha

Shailesh Sinha is a senior SAP Application consultant specializing in SAP CRM, CRM billing, CRM-IS-UT, and SD and LE (ECC) and its integration with modules such as materials management, production planning, and plant maintenance, for over14 years. Having worked end to end on several implementations, roll-outs and upgrades, Shailesh is keenly aware of the critical success factors. As a subject-matter expert within the commercial industrial market for the regulated and deregulated utilities, Shailesh has designed end-to-end solutions encompassing CRM and IS-U/CRB. He has also worked in various verticals such as utilities, steel, real estate, hi-tech, and processing. As an architect, he has extensive hands-on experience in technical integration across various SAP modules and also third-party software. He is well versed in scoping, blueprinting, realization, cut-over, and go-live. Having worked end to end on implementations and production support, Shailesh has developed an innate ability to capture clients’ pain points and convert them into successful configuration. His understanding of the SDLC methodology and ITIL framework offers him a unique methodical and procedural perspective.

You may contact the author at sinhashailesh08@gmail.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.