Check Framework

 

The change of supplier process requires a number of different checks to be made. These checks can be triggered by critical errors or warnings.

In the event of an error, you must be able to handle different exceptions.

Example Example

Reject notification automatically

Agent decision

Inform agent

Continue process automatically

Exception handling can depend on the participating service providers.

End of the example.

Example Example

If your own supplier does not act as required within a specified period, the agent can decide how to proceed.

You can define different ways of handling exceptions for different point of delivery groups (by agreement).

End of the example.

Example Example

If an error occurs, registrations for residential customers are rejected automatically. For commercial and industrial customers, the agent can decide how to proceed.

Project-specific checks are also necessary.

The check framework provides flexibility for defining, executing, and logging checks as well as for handling exceptions.

End of the example.

Example Example

Change of supplier checks from the distributor’s view:

Check registration period and move-in date

Check termination period and move-out date

Is interval reading possible?

Does the new supplier already supply energy to the point of delivery?

Does the former supplier still supply energy to the point of delivery?

Check permissibility of settlement unit

Is there a supply scenario switch after the move-in date?

Are there multiple registrations?

End of the example.

Integration

The check framework is used by the change of supplier workflow templates:

  • Cancellation processing from the supplier’s view

  • Registration for supply from the new supplier’s view

  • Change of supplier from the distributor’s view

The workflows use the check framework using the BOR interface to carry out checks and determine exception handling. Depending on the exception handling, the responsible agent receives a notification or a decision for processing in the SAP Business Workplace.

You can find the SAP Business Workflow in the SAP Easy Access menu, transaction SBWP.

Features

The check framework provides the following functions:

  • Executing the checks

  • Determining exception handling from Customizing (standard handling) and from the service provider agreement (specifically for the participating service providers).

  • Exception handling for errors determined by the check method

  • Exception handling for errors from the process flow (independent of check methods)

  • Automatically logging data in the switch document

  • Logging check results (successful checks, warnings, errors)

  • Logging error messages, including long text

  • Logging exception handling (termination, inbox work item, agent decision)

Note Note

For each individual check, you can set which activities are to be logged in the switch document:

  • Logging all messages (check and exception handling results)

  • Log all results (success messages, warnings, and errors)

  • Only log warnings and errors

  • Only log errors

  • Incorporating project-specific checks

The check framework is a single workflow interface for all checks. This enables a generic exception handling. The standard sample processes use check framework subworkflow WS20500208 (ISUSuSwCheck) for exception handling. The check framework interface and the check framework subworkflow for generic exception handling are described in the Technical Reference. The check framework also includes the following functions:

  • Automatic repeat of checks if temporary errors occur (for example, if data is locked)

  • Generation of a dialog step for agent decisions or information, using the switch document and check log as object references

End of the note.

Note Note

If you use the check framework subworkflow, you do not need to implement new dialog steps for inbox work items when carrying out project-specific checks.

Automatic logging of user decisions in the switch document.

End of the note.

Note Note

A switch document activity contains agent information such as who terminated the message processing and who resumed the process.

End of the note.