Skip to Content
Author's profile photo Christian Drumm

The Utilities Check Cockpit (UCC) and the Check Repository in the process framework

In my previous blog (Testing some of the new features in SAP CRM EhP1, EhP2 and EhP3) I explored some of the general features delivered with SAP CRM EhP1, EhP2 andEhP3. In contrast to that I’ll explore utilities industry specific features in this blog, namely the Utilities Check Cockpit (UCC) and the Check Repository in the process framework.

The Utilities Check Cockpit as well as the Check Repository are part of the business function CRM_UT_ER_2 (Energy Retailer 2 – Business Functions for SAP Customer Relationship Management – SAP Library) delivered with SAP CRM EhP2. In order to use these features the business function CRM_UT_ER_2 needs to be activated using transaction SFW5.

However, the Utilities Check Cockpit has also been down ported to SAP CRM 7.0 EhP0 and EhP1 (cf. SAP Note 1742546 – Utilities Check Cockpit for further details).

Utilities Check Cockpit (UCC)

The Utilities Check Cockpit is a tool to automatically perform comprehensive consistency checks of utilities specific application data. In particular the Utilities Check Cockpit can be used to check the consistency of contract and technical data across SAP CRM and SAP IS-U. Inconsistencies of the utilities specific application are usually sources  process problem. An Example of such an inconsistency is a contract that has been cancelled in SAP IS-U and were the  cancellation has not been replicated to SAP CRM correctly for whatever reason. This will most likely cause a process problem if an agent tries to create a move out for the contract in SAP CRM. The Utilities Check Cockpit aims to identify such inconsistencies before they can lead to process problems.


The initial setup of the Utilities Check Cockpit is pretty easy. Besides the activation of the business function CRM_UT_ER_2 the only thing I had was to implement SAP Note 1919089 – CRM-IU: Utilities Check Cockpit – Creation of a Check Run causes a dump. This note contains only the instruction to create two number range intervals for the number range objects CRM_UOCM and CRM_UOCM_I.

After this, the Utilities Check Cockpit can either be started using transaction CRM_IUCMON or via the Check Cockpit -> Check Run in the UTIL_SALES business role.


Executing Check Runs

In order to execute an individual check run or schedule a periodic check run click “New” and select the check run category. SAP delivers three check categories in the standard delivery of the Utilities Check Cockpit, namely:

  • UORD – Utilities Business Transaction Document
  • USLO – Utilities Service Location
  • USET – Utilities Object Set.


After the selection of the check run category one needs to set the parameters for the check run as well as the scheduling parameters for the batch process executing the checks. In the example below I’ve selected two check classes and scheduled the background job for immediate start. Furthermore, it is possible to provide an email address for a notification upon completion of the check run.


Upon completion of a check run the Utilities Check Cockpit provides an overview of the found issues for each of the selected check classes. For each issue it is possible to create a task and assign it to some agent in order to get the issues resolved. In the screen shot below the results of the check class CL_CRM_ISU_CM_CHECK_CANC are shown. This check class searches for contracts which are cancelled in IS-U but not in CRM. In the example check run 10 such cases were identified.


Furthermore, the Utilities Check Cockpit also offers the possibility to implement automatic corrections for each issue. However, none of the check classes delivered in the SAP standard provides functionality for an automatic correction.


Extending the Utilities Check Cockpit

In the standard SAP delivers the following set of check classes:

  • Check category UORD
    • CL_CRM_ISU_CM_CHECK_CANC – Search contracts cancelled in IS-U but not in CRM
    • CL_CRM_ISU_CM_CHECK_DATES – Compare appointment ‘CONTSTART’ with its value in the CRM Utilities-Index
    • CL_CRM_ISU_CM_CHECK_EVERH – Compare IS-U-contract history (EVERH) with the CRM Utilities-Index
    • CL_CRM_ISU_CM_CHECK_I1030 – Check if status I1030 ‘errors’ is correctly set
    • CL_CRM_ISU_CM_CHECK_I2413 – Check if status I2413 is correctly set
    • CL_CRM_ISU_CM_CHECK_POD_OCC – Search for Points of Delivery with multiple assigned Contracts
    • CL_CRM_ISU_CM_CHECK_POD_REPL – Check IS-U Replication Error Monitor for Point of Delivery and Connection Object issues
    • CL_CRM_ISU_CM_CHECK_REPL – Search for Contract related issues in IS-U Replication Error Monitor
    • CL_CRM_ISU_CM_CHECK_STAT – Generate IS-U Order error message statistic
  • Check category USLO
    • CL_CRM_ISU_CM_CONS_DL_CONNOBJ – Check Connection Objects for consistent Download
    • CL_CRM_ISU_CM_TO_WITHOUT_IB – Check for Technical Objects without an IBase component.

In addition to those check classes it is quite easy to extend the Utilities Check Cockpit with custom check classes. In order to create a custom check on needs to implement the custom check in a class implementing the interface IF_CRM_ISU_CM_CHECK. The check classes delivered in the SAP standard (e.g. CL_CRM_ISU_CM_CHECK_I2413), which are located in package CRM_IU_CM_API, provide plenty of code examples how to implement a custom.

After a custom check class has been implemented it only needs to added to the customizing at SPRO -> Customer Relationship Management -> Industry-Specific Solutions -> Utilties Industry -> General Settings -> Utilities Check Cockpit -> Define Settings for Utilities Check Cockpit. After this, the custom check class can be selected when a new check run is scheduled.


In order to provide an automated correction, the two methods IF_CRM_ISU_CM_CHECK~CORRECT and IF_CRM_ISU_CM_CHECK~IS_CORRECTION_SUPPORTED need to be implemented in the custom check class.

Check Repository

The second feature I want to focus on in this blog is the check repository in the process framework. If additional checks needed to be performed in the standard process classes (like e.g. CL_CRM_IU_PR_CNTR_END) the only way to do this was via the following approach:

  1. Create a subclass of the standard process class
  2. Implement the additional check in the appropriate method of the process framework (e.g. IF_CRM_IU_PROCESS~IS_EXECUTABLE)
  3. Use the custom process class in the customizing of the process framework instead of the standard class.

There are a large number of scenarios requiring the implementation of custom checks in the process classes. In the systems of our clients custom checks are implemented, for example, to check the market communication deadlined before the creation of a move in or check if contract was billed after the date of a planned move out. The check repository in the process framework focuses exactly on this use case. It enables the addition of custom checks to the standard process classes without the need to create a custom process class implantation. Instead a custom check is implemented using the following approach:

  1. Implement a custom check by subclassing CL_CRM_IU_PROCESS_CHECK and implementing the method IF_CRM_IU_PROCESS_CHECK~CHECK
  2. Add the custom check to the customizing of one or several processes in the process framework.

In the following sections I’ll describe these steps in more detail.

Implementing a custom check

The class CL_CRM_IU_PR_CHK_CNTR_BILL_END in the package CRM_IU_IC_6X_SI_PROC_IMPL provides an example of a custom check implemented using the check repository. In the method IF_CRM_IU_PROCESS_CHECK~CHECK a check for a existing bill after the planned move out date is performed. In order to implement the check the method IF_CRM_IU_PROCESS_CHECK~CHECK has access to the process context. Furthermore, a reference to the log object is available in order to raise error messages to the user if necessary.

Adding a custom check to the process framework

The customizing of the check repository is locates at SPRO -> Customer Relationship Management -> Industry-Specific Solutions -> Utilties Industry -> Settings for User Interfaces -> Transaction Processing -> Processes -> Define Processes.


In order to add a custom check to the check repository first a Check ID needs to be created. In the example below the check ID UCBILLEN is assigned to the implementation class CL_CRM_IU_PR_CHK_CNTR_BILL_END.


Next the check can be added to a process. In order to add a check to a process the execution time and the execution frequency within the process framework needs to be specified. The execution time is specified within the methods of the process framework, i.e.. checks can be executed before or after the following methods of the process framework are called for the process implementation class


In the example below the check UCBILLEN is executed after the method IS_COMPLETE of the process framework is called. Furthermore, the check will only be called once per execution of a process. In contrast to that it is also possible to execute a check for each item of a process.


In summary, the check repository provides a nice, clean way to extend the standard process classes with custom checks.


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Jānis B
      Jānis B

      I'm sorry for sounding so negative and dismissive, but is this functionality not an utter  technological surrender and an admission of inability to create the processes and software that simply work and do not leave the data in inconsistent state..? What's next - Utilities Check Cockpit Self-check?

      Author's profile photo Christian Drumm
      Christian Drumm
      Blog Post Author

      Hi Janis,

      I guess one has to admit that you comment is are at least partially right.

      Due to the system setup consisting of SAP CRM and SAP IS-U including the master data replication using the CRM middleware some of the utilities process become incredibly complex. This is especially true in deregulated scenarios like in the German utilities industry, where external communication processes takes place in even the most basic processes like performing a move in. Given the system setup consisting of two independent systems with it's large number of possible customizations (e.g. CRM product configuration, middleware replication and filtering, the IS-U master data templates and master data generator, ...) things are bound to fail in some special cases.

      However, having said this, I'm sure that all these customizations have been implemented for some reason. So either based on requirements of several customers or the requirement to support a large number of similar but different processes across different countries, SAP introduced this flexibility into the standard software. As a consequence, there will always be some bugs leading to some inconsistent data in a large system.

      Up to now one had two options. Either performed a correction of these data inconsistencies after they led to process problems and were discovered by some agent or develop some custom check programs to identify the problems beforehand.

      In summary I think the UCC is a valuable addition to the standard functionality and will helping IT departments ensure a smooth operation of the system. In the end it is not different from running a Nagios installation to ensure a high availability server cluster is up and running without a problem.


      Ps.: The check I executed in the example was actually performed in one of our customer systems containing some 250.000 active contracts. 10 errors in these 250.000 contracts is not a bad number. So I don't think we have totally surrendered, yet 😉

      Author's profile photo Jānis B
      Jānis B

      I'm maintaining and supporting a highly customer modified and extended (aka shooting one-self in all extremities) IS-U only installation, where the business people run three dozen or so reports to check and fix the data as part of yearly billing process. The people actually preferred running them to having to sit down and talk business with the inhabitants of all those other silos, capture the company wide processes (or at least the parts supported by IS-U), try to fix the software, then test it again. Until the time company had to start saving and they could not replace all retiring staff anymore, that is 🙂 So the check if all SEPA Mandates are there with the right statuses has to run in batch now... I guess I should use this as another argument why they should want the SAP CRM - there you'll consolidate your checks and work in a nice Cockpit!

      Author's profile photo Christian Drumm
      Christian Drumm
      Blog Post Author

      Hi Janis,

      i'm not sure if the UCC is really a good argument for introducing SAP CRM in the landscape 😉 . With a highly customized IS-U system implementing CRM. In a way satisfying the business will be really challenging.

      have you had a look at BPEM/EMMA to consolidate checks and issue handling? It's available in the IS-U standard and currently used, e.g. for issue tracking in the IDEX Common Layer. Might be a easier start then a full fledged CRM implementation 😀


      Author's profile photo Jānis B
      Jānis B

      No, no - not on top of a broken backend system of course - that's mission impossible. When our Customer Service are ready for a clean slate, change and compromises, if the multiple backends can work out to their satisfaction (because electricity and gas deregulation and market communication platform is just unnecessary pain for heating), leaving in "legacy" IS-U the biggest reason for breaking the heating IS-U in the first place - "proprietary" heating grid with lots of funky transmission loss distribution calculations and the "proprietary" reading interface, which was recently re-implemented. We tech folks may also sometimes dream big, can't we 🙂 if there will be money that is...

      EMMA now forwards me most of the annoying correspondence printing exceptions just fine, CCMS checks if EMMA is well..., so I'm a happy camper, plotting how I could sweet-talk the respective silos into doing the actual handling.

      Author's profile photo Former Member
      Former Member

      Good article, thanks. We have CRM EHP1, if implemented UCC as you mentioned at beginining of the article, can we have archive the capability on IC Web Client as EHP2 does? Thanks.

      Author's profile photo Christian Drumm
      Christian Drumm
      Blog Post Author

      Hi Michael,

      I don't know if the WebUI component is already available in SAP CRM 7.0 EhP1. You could try to search for the UI component IUCCRS. If it is available, simply give it a try. Alternatively you could also check the Improvement Finder.


      Author's profile photo Nic Teunckens
      Nic Teunckens

      Thank you for this BlogPost, as it introduced me to this thus far unknown business function. We're running ISU & CRM 7.0 EhP3 so this could be a great addition for Monitoring / Correcting PoD data.

      Author's profile photo Suman Biswas
      Suman Biswas

      Hello Christian,

      Great Blog!

      Just wondering if this tool would cease to exist , if SAP follows their road map and puts crm as an add on to the S4 Hana system... 🙂


      Suman Biswas

      Author's profile photo Christian Drumm
      Christian Drumm
      Blog Post Author

      Hi Suman,

      I'm not sure what will happen in the future with respect to CRM and IS-U. If CRM is integrated in S/4HANA there is (hopefully) no need for the CRM middleware anymore. This would eliminate one source for problems that the UCC tries to detect.

      However, not all checks might become obsolete and it is also possible to add additional custom checks. Therefore, I don't think the UCC itself will be obsolete.