Implementation Guideline ISU2CI Integration

SAP S/4HANA Utilities: Integration of IS-U and
Convergent Invoicing
Implementation Guidelines
SAP S/4HANA Utilities 2021
CUSTOMER
Document Version 2.0 (August 2022)
© 2022 SAP SE. All rights reserved.
INTERNAL | SAP AND CUSTOMER USE ONLY

SAP S/4HANA UTILITIES: INTEGRATION OF IS-U AND CONVERGENT INVOICING
Contents
1 DISCLAIMER ............................................................................................................................... 3
2 INTRODUCTION .......................................................................................................................... 4
2.1 Different Invoicing Options for IS-U........................................................................................... 4
2.2 Documentation and Useful References ..................................................................................... 4
3 IMPLEMENTATION AND CONFIGURATION............................................................................... 5
3.1 Enhancement of the Database Table ERDK in IS-U Invoicing .................................................. 5
3.2 Several Prerequisites – Customizing in Convergent Invoicing ................................................ 5
3.3 Configuration of the Integration Category................................................................................. 8
3.4 Configuration of Posting Areas for IS-U and CI .......................................................................11
3.4.1 Maintain Account Assignments for Billable Items (Posting Area R480); optional) ..........................12
3.4.2 Maintain Transaction Determination for Billable Items (Posting Area R481); optional....................12
3.4.3 Allocation of Document Line Type to Type of Billable Item (Posting Area R482) ...........................13
3.5 Budget Billing ............................................................................................................................13
3.5.1 Offsetting .....................................................................................................................................13
3.5.2 Statistical and Partial Bill Procedure.............................................................................................14
3.6 Bill Print in CI .............................................................................................................................16
3.7 Reversal Processes ...................................................................................................................16
3.7.1 Option 1: Two phase reversal approach .......................................................................................16
3.7.2 Option 2: One step reversal approach ..........................................................................................18
3.8 Outsorting ..................................................................................................................................19
4 MIGRATION AND ACTIVATION .................................................................................................19
4.1 Default CI Integration Category for New Contract Accounts ...................................................20
4.2 Change of the Integration Category in the Contract Account .................................................20
4.3 Mass Change of Contract Accounts – Report ISU_CONTACCT_ISU2CI_FILL .......................20
© 2022 SAP SE. All rights reserved. 2

1 DISCLAIMER
The information in this document is confidential and proprietary to SAP and may not be disclosed without the
permission of SAP. This document is not subject to your license agreement or any other service or
subscription agreement with SAP. SAP has no obligation to pursue any course of business outlined in this
document or any related presentation, or to develop or release any functionality mentioned therein. This
document, or any related presentation and SAP's strategy and possible future developments, products
and/or platforms directions and functionality are all subject to change and may be changed by SAP at any
time for any reason without notice. The information on this document is not a commitment, promise or legal
obligation to deliver any material, code or functionality. This document is provided without a warranty of any
kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness
for a particular purpose, or non-infringement. This document is for informational purposes and may not be
incorporated into a contract. SAP assumes no responsibility for errors or omissions in this document and
shall have no liability for damages of any kind including without limitation direct, special, indirect, or
consequential damages that may result from the use of this document. This limitation shall not apply in cases
of intent or gross negligence.
All forward-looking statements are subject to various risks and uncertainties that could cause actual results
to differ materially from expectations. Readers are cautioned not to place undue reliance on these forward-
looking statements, which speak only as of their dates, and they should not be relied upon in making
purchasing decisions.

2 INTRODUCTION
The business models and business activities used by utilities companies are changing over time. The
revenue created by selling non-commodity products such as physical goods and service products is
increasing in relation to the revenue of commodity products in utilities divisions such as electricity, gas and
so on. These changes lead to changed software requirements for billing and invoicing solutions. Especially in
invoicing, nowadays commodity and non-commodity products that might be even sold together must be
processed consistently, in certain cases jointly. Specific product bundle requirement and discounts must be
considered. Central and functionally flexible invoicing solutions are most suitable in these circumstances.
Therefore, SAP Convergent Invoicing should be leveraged together with IS-U for commodity billing.
SAP S/4HANA Utilities 2020 provides an additional option for performing utilities-related invoicing: IS-U can
be integrated with Convergent Invoicing so that invoicing and creation of the customer bill is performed in
Convergent Invoicing. IS-U Invoicing is still performed with reduced functionally and acts as an interim,
technical process step to transfer data to Convergent Invoicing.
2.1 Different Invoicing Options for IS-U
SAP S/4HANA Utilities (IS-U) supports 3 different options:
• Option 1: Classic IS-U

IS-U Invoicing with its full functionality
• Option 2: Classic IS-U with CI source documents invoiced in IS-U
IS-U Invoicing with its full functionality; CI used for non-IS-U products and resulting CI source
documents processed using IS-U Invoicing.
• Option 3: Integration of IS-U with CI (first released with SAP S/4HANA 2020)
Recommended option for leveraging CI most effectively for the utilities industry; integration based on
billable items; IS-U Invoicing is reused for the technical transfer from IS-U to CI. Here, IS-U Invoicing
does not post to FI-CA and does not print. Printing and posting are executed by CI.
2.2 Documentation and Useful References
The following sources provide useful information:
• SAP Road Map Explorer
• Note 2935426 discusses recommendations and restrictions

• Product documentation
• Demo video
3 IMPLEMENTATION AND CONFIGURATION
Please note that this document focuses on describing relevant steps in IS-U. The configuration related to
CI is only partially considered and is not described in detail. Please refer to the documentation published for
SAP Convergent Invoicing.
This document provides recommendations and suggestions about a possible system setup. SAP S/4HANA
Utilities including IS-U and SAP Convergent Invoicing support a wide range of options for configuration and
implementation of enhancements and specific events.
The examples provided in this document are generally kept relatively simple. Mappings, such as coding and
decoding of parameters in the transfer between IS-U and CI, are kept simple, the same parameter values
are widely used in IS-U and CI. In your implementation, you do not have to do the same.
3.1 Enhancement of the Database Table ERDK in IS-U Invoicing
Several new fields related to the CI integration must be added to the database table ERDK:
Please run the report REAINV_ENH_ISU2CI to create new fields in the customer Include CI_ERDK, which is
a part of the DB table ERDK.
Note: Additional database tables, such as ERCH (IS-U billing document header) and EABP (IS-U budget
billing plan), are now available that now contain the integration category as a new standard field.
3.2 Several Prerequisites – Customizing in Convergent Invoicing

Source transaction type ‘ERDK’ (IS-U Invoicing) is intended to be used for the IS-U / CI integration:
Transaction code SPRO

IMG menu Financial Accounting ->Contract Accounts Receivable and
Payable -> Convergent Invoicing -> Basic Functions -> Billable
Items -> Billable Item Management -> Define Source Transaction
Types
Source transaction type ‘ERDK’ is available in the standard delivery. No change is required.
A BIT class is required, such as ‘ISUB’ (Utilities Billing) used in our example:

IMG menu (CI) Financial Accounting ->Contract Accounts Receivable and
Payable -> Convergent Invoicing -> Basic Functions -> Billable
Items -> Billable Item Classes
The interface components must be chosen and activated according to the actual business requirements. For
example, if you want to process budget billing requests in CI, the interface component “Offsetting in
Invoicing” is relevant and should be activated.
The interface component RECEIV_PAY0 Receivables/Payables (Reduced Interface) does not support non-
posting relevant billable items. For these, the interface component RECEIV_PAY Receivables/Payables
(Extended Interface) must be activated.
Different subprocesses in CI Billing can be used to distinguish between periodic billing, final billing, interim
billing and budget billing. These subprocesses are required to distinguish between the different types of
processing, such as billing and invoicing that are executed automatically in CI.
Subprocesses are configured here:

IMG menu (CI) Financial Accounting → Contract Accounts Receivable and
Payable → Convergent Invoicing → Basic Functions → Billable
Items → Billable Item Management → Define Subprocesses of
Billing
Examples of subprocesses used throughout this document are shown below:
Subprocess Subprocess Description

SU01 Utilities Billing
SU02 Final Utilities Billing
SU03 Utilities Budget Billing Request
SU04 Interim Utilities Billing
The subprocesses are assigned to the BIT class:

Items → Billable Item Management → Assign Subprocesses to
Classes

Example:
The flag “Immediate Billing” enables the CI billing process to be executed automatically immediately after the
BIT is created, meaning that BITs that are to be invoiced collectively can already be aggregated here.
CI billing processes are configured here:

Payable → Convergent Invoicing → Basic Functions → Billing →
Billing Processes → Define Billing Processes
Example:
Further entities, such as selection variants or grouping variants, can be defined in CI Customizing according
to the project-specific requirements.
Note: The entry of an invoicing process as shown for the subprocess SU03 (Budget Billing) enables invoicing
to be executed automatically for billing documents in this subprocess. This is discussed in chapter 3.5.2 as
an option to always invoice budget billing requests separately from other source documents.
Invoicing processes are maintained here:

Payable → Convergent Invoicing → Basic Functions → Invoicing
→ Invoicing Processes → Define Invoicing Processes
Specific invoicing functions should be considered. For example, if you want to use the budget billing
functionality, you must activate the offsetting functionality:

3.3 Configuration of the Integration Category
The integration category is an entity specifically used to define the integration with Convergent Invoicing. A
Customizing activity is provided for its definition. It is assigned at contract account level, and controls which
invoicing option is applied to this contract account. During creation of IS-U billing documents, the integration
category is copied from the contract account to the billing document and the related invoicing trigger record.
It classifies IS-U billing documents regarding the invoicing process that processes these documents. You
use the integration category for Convergent Invoicing (CI), if the billing document is to be invoiced in CI. This
contains the rules for integration with CI and information about the system to which data in the billing
document is to be forwarded for CI invoicing.
An integration category must be defined. Please access the Customizing activity transaction:

IMG menu (IS-U) SAP Utilities ->Contract Billing ->Invoicing -> Integration with
Convergent Invoicing -> Generation of Billable Items in
Convergent Invoicing -> Maintain Integration Categories
(Note: As an alternative, you can use the view cluster VC_TE482 (transaction SM34).)
Create a new integration category, such as ‘UBCI’ (Utilities Billing - Con. Inv. Integration):
• The CI integration type entered here is a default value. The integration type is discussed in the next
paragraph.
• "Logical System" is left blank if CI and IS-U are found in the same system.
Note: An integration of IS-U and CI across different systems is technically possible but is not
supported by the delivered standard solution. Project-specific code developments would be required
in this case.
• "Transfer Process" is set to the value of "Data Transfer Performed By IS-U Invoicing"
(recommended). This enables BITs to be created synchronously when IS-U invoicing is performed.
Note: The value “Data Transfer executed asynchronously to IS-U Invoicing”, means that BITs are not
created during IS-U invoicing, but as a separate step, for example by executing transaction

EA2CI_TRANS (report REAINV_TRANSFER_ISU2CI). Transaction EA2CI_MON provides a monitor

for the open transfer requests.
• Another entity known as the integration type is found below the integration category. The integration
type connects the integration category with the BIT class, the CI billing subprocess and the source
transaction type. Depending on your requirements, you can assign one or more integration types to
the integration category. This allows a high degree of flexibility for the processes in CI. 4 integration
types for periodic billing, final billing, budget billing, and interims billing, respectively, are assumed in
our example below.
The different integration types are assigned under the respective node to distinguish transfer data from IS-U
in CI as shown in the following example:
Various texts, subprocesses and source transaction types can be defined on the respective detail screens
for each integration type:

These values for the integration types are used for data mapping to BITs in Convergent Invoicing (CI).
In addition to Customizing settings, an implementation of the FI-CA event R581 is required if more than one
integration type is customized, as in the example above. If event R581 is not implemented, the default
integration type is always applied. A function module must be implemented for the event, which determines
the integration type according to input parameters, such as the integration category, clearing category, run
parameters for invoicing and invoice unit data (includes attributes like the contract account, business partner,
contract, and so on).
Code example related to the overall example configuration:
IF x_isu2ci_category = 'UBCI'.
IF x_wa_iiu-unit_param-verart = 'R4'.
CHECK sy-tcode = 'EA45'.
ENDIF.
CASE x_wa_iiu-unit_param-verart.
WHEN 'R41' OR 'R42'.
xy_isu2ci_type = 'SU1'. "periodic bill
WHEN 'R43'.
xy_isu2ci_type = 'SU2'. "final bill
WHEN 'R6' OR 'R5' OR 'R4'.
xy_isu2ci_type = 'SU3'. "BBP
ENDCASE.
ENDIF.
Assign your function module to the event "R581" in transaction FQEVENTS.

The node “Program Extensions” is used to assign function modules – standard sample function modules are
available – and their execution in specific FI-CA events:
• (Event 30) The sample function module ISU_INV_ISU2CI_EVENT_30_CI01 can be assigned for
mapping and transfer purposes.
• (Event 35) The sample function module ISU_INV_ISU2CI_EVENT_35_CI01 can be assigned for
additional actions
• The (Event 50) sample function module ISU_INV_ISU2CI_EVENT_50_CI01 can be assigned to
display BITs.
3.4 Configuration of Posting Areas for IS-U and CI
The maintenance transaction for posting areas in IS-U is applied using transaction FQC0.
The following posting areas are relevant for value mapping of certain attributes from IS-U to values in CI. In
the first 2 lines, encoding in the IS-U is done by converting attribute values into a set of up to 4 external keys.
In CI, these key values are decoded using another posting area where those key values are converted into
specific semantic attribute values. Line item types are directly converted in IS-U:
IS-U Attributes Encoding Decoding Comment

Company Code, Posting Area R480: Posting Area 8120 The attributes named on the left
Division, Business ISU2CI: Account can be mapped according to the
Area, Segment, assignments for billable activated key fields in table
Profit Center items, depending on the TFK033E.
integration category,
Main transaction, Posting Area R481: Posting Area 8121 The main transaction and
Subtransaction ISU2CI: Transaction subtransaction values can be
determination for billable mapped using posting areas
items, depending on the R481 and 8121.
target process, company
code, division.
Line Item Type Posting Area R482: BITTYPE IS-U print document line item
ISU2CI: Assignment Line types can be mapped to a
Item Type / Billable Item billable item type using posting
Type area R482.
In the following subchapters, the corresponding Customizing activities (also accessible using transaction
FQC0) are described.
Mappings using posting areas R480 and R481 are optional if you transfer the same values to Convergent
Invoicing.

3.4.1 Maintain Account Assignments for Billable Items (Posting Area R480); optional)

Convergent Invoicing -> Maintain Account Assignments for
Billable Items
The suggested Customizing content exports company code U100 and divisions 01, 02 unconverted as
“external keys” (keys that have no semantics).
You can use the button “Simulation” to check whether the access works correctly for a representative key. If
it does not work, choose “More->Environment-> Access Sequence” to define an appropriate access
sequence.
For the mapping (Decoding) in CI, you need to provide configuration in the CI Customizing activity “Define
Account Assignments” for posting area 8120:

Items → Billable Item Transfer -> Account Assignment Derivation
→ Define Account Assignments
You must activate all key fields for displaying all relevant fields
If one of the key fields used contains the value ‘*’, you must create an ”Access Sequence” using the menu
path More -> Environment -> Access Sequence.
3.4.2 Maintain Transaction Determination for Billable Items (Posting Area R481); optional

Convergent Invoicing -> Maintain Transaction Determination for
Billable Items
Use the “Simulation” button to check whether the access works correctly for a representative key. If it does
not work, define an appropriate access sequence using the menu path “More->Environment-> Access
Sequence”.

Mapping (Decoding) in CI:

CI Customizing “Define Main Transactions and Subtransactions” for posting area 8121 must be maintained:

Items → Billable Item Transfer -> Account Assignment Derivation
→ Define Main Transactions and Subtransactions
Use the “Simulation” button to check whether the access works correctly for a representative key. If it does
not work, define an appropriate access sequence using the menu path “More->Environment-> Access
Sequence”.
3.4.3 Allocation of Document Line Type to Type of Billable Item (Posting Area R482)
As a prerequisite, define billable item types:

Items → Billable Item Management → Define Item Types
Allocation of document line types to billable item types:

Convergent Invoicing -> Allocation of Document Line Type to
Type of Billable Item
3.5 Budget Billing
The following budget billing procedures in IS-U are supported:
• Statistical budget billing procedure

• Partial billing procedure
3.5.1 Offsetting
Report/Customizing if the offsetting function is to be used:

IMG menu Financial Accounting → Contract Accounts Receivable and
Payable → Convergent Invoicing → Program Extensions ->
Prepared Extensions -> Add Fields for Offsetting in Invoicing to
Billing Document
This report generates the necessary fields in the CI billing document.

IMG menu Financial Accounting → Contract Accounts Receivable and
Payable → Convergent Invoicing → Invoicing → Additional

Functions → Offsetting in Invoicing -> Define Offsetting

Categories
The following offsetting categories are part of the standard delivery:
The offsetting level “Contract” is suitable to support changes between joint invoicing and separate invoicing
of contracts in a multi-division scenario.
Offsetting category R01 is applied in case of the statistical budget billing procedure, R04 in case of partial
billing procedure.
3.5.2 Statistical and Partial Bill Procedure
IS-U Invoicing processes budget billing requests and creates BITs for further processing in CI. Due dates for
the budget billing requests are determined by IS-U invoicing.
Budget billing requires specific configurations of the processing in CI with some differences compared to
periodic, interim and final billing as described in the previous chapters.
3.5.2.1 Separated Invoicing of Budget Billing Requests in CI
For consistent processing in CI, it is necessary to bill and invoice BITs related to a budget billing request
separately from all other IS-U related BITs, to observe the different due dates for budget billing requests and
utilities bills consistently. Due to the high flexibility of CI, this can be achieved using various options.
3.5.2.1.1 Option 1: Immediate Billing and Processing of Budget Billing-Related BITs
IS-U Invoicing sends budget billing requests as separated BITs to CI. If these BITs are immediately billed
and invoiced in CI, the result is one separated invoicing document for each budget billing request. As shown
in chapter 3.2, you can set up the system accordingly to achieve this goal:
• Definition of a separated subprocess for budget billing

• Assignment of the subprocess to the BIT class for immediate billing
• Assignment of the subprocess to the billing process for immediate invoicing
This option has the disadvantage that separated processing of the budget billing request-related BITs cannot
be ensured if exceptions occur during billing or invoicing (such as for invoicing locks).
3.5.2.1.2 Option 2: Grouping Variant for the Invoicing Process

IMG menu Financial Accounting→ Contract Accounts Receivable and
Payable → Convergent Invoicing → Invoicing → Invoicing
Processes → Maintain Grouping Variants
The grouping variant must be assigned to the invoicing process:

IMG menu Financial Accounting→ Contract Accounts Receivable and

Processes → Define Invoicing Processes
3.5.2.1.3 Option 3: Implementation of Event 2601 (Creation of Invoicing Unit)
Event 2601 can be used to implement the logic for separated processing of budget billing requests in CI
Invoicing. This option entails implementation effort but provides a high level of flexibility.
3.5.2.2 Due date determination for budget billing requests
For a correct due date determination for budget billing requests, FI-CA event 2640 should be activated using
function module "ISU_SAMPLE_2640".
3.5.2.3 Suppress Printing Budget Billing Requests in CI
If you do not want budget billing requests to be printed, you must suppress their printing. Two options are
available to achieve this suppression.
3.5.2.3.1 Option 1: Usage of Different Invoicing Types

Processes → Define Invoicing Types
The parameter “No Document Print” is available at invoicing process level.
Usage of different invoicing types requires an implementation of event 2603.
3.5.2.3.2 Option 2: Implementation of Event 2645
Event 2645 can be implemented to set a print lock for budget billing requests in CI.
3.5.2.4 Interim Utilities Invoicing
To ensure that interim utilities invoicing is processed consistently in CI with budget billing, it is necessary to
implement the FI-CA event 2739. The implementation is delivered by the function module
ISU_SAMPLE_2739. The prerequisite here is to define a customer-specific source document type “SU4”
(Interim Utilities Billing) for classifying interim utilities billing documents for invoicing in CI.

Payable → Billing → Invoicing → Billing Documents → Define
Source Document Types for Billing Documents
Further implementations for supporting an interim utilities invoicing are required, such as the implementation
of FI-CA event R581 and so on.

3.6 Bill Print in CI
The invoice is printed in SAP Convergent Invoicing. You must implement your own forms. The standard form
UTIL_BILL_PDF is only an example form, which you may use as a basis for your own forms. You must
always implement your own bill layout in which you can combine data from IS-U and CI. Unfortunately,
existing forms you may have implemented for IS-U invoicing cannot be reused.

Processes → Define Bill Form

Processes → Define Specifications for Determination of Bill Form
The following customizing activity is only optional:

Processes → Enter Keys for Determining Alternative Bill Forms
3.7 Reversal Processes
If corrections are required, the chain of documents must be reversed down to the appropriate level where the
corrections are to be applied. In certain cases, it might be sufficient to reverse the CI invoicing document to
apply the corrections to the business partner or contract account. This is straightforward. If corrections are to
be applied to IS-U objects or documents, this is more complicated. If meter readings are to be corrected, all
documents down to the IS-U billing document must be reversed. The reversal affects objects in both CI and
IS-U.
IS-U and CI support two different options for executing the reversal:
1. Two phase reversal approach

2. One step reversal approach
You should choose one of the two options above and adhere to it for the implementation and usage. In the
following chapters, both options are described.
3.7.1 Option 1: Two phase reversal approach

If corrections in IS-U are to be applied, and CI Invoicing already took place, you can apply this manual
process:
1. Reverse the CI invoicing document and the CI billing document
2. Execute full reversal in IS-U (reversal of IS-U invoicing document and, if required, IS-U billing document)
• BITs with negative amounts are created and trigger the reversal of the original BITs
3. Apply corrections, such as meter readings, rate data and so on.
4. Execute IS-U billing and IS-U invoicing again
• New BITs based on the corrected data are created with references to the original documents
Please note that step 2 should be executed immediately after step 1. If you do not process step 2
straightaway, the next CI billing mass run reprocesses the BITs again. Furthermore, CI billing mass runs
should be executed outside of office hours.
3.7.1.1 Disablement of incorrect full reversal application in IS-U

To disable incorrect execution of the full reversal in IS-U (step 2 above), events 10 AND 33 can be
implemented, see the Customizing activity Financial Accounting -> Contract Accounts Receivable and
Payable -> Convergent Invoicing -> Basic Functions -> Billable Items -> Billable Item Management -> Define
Processing Rules for Billable Items.
Sample implementations are provided by function modules ISU_TFK8101EV_10 and ISU_TFK8101EV_33.
3.7.1.2 Suppress BIT Reversal
BITs created by IS-U must not be reversed because this leads to inconsistencies. Accordingly, you can
configure a suppression of the BIT reversal at the level of the corresponding subprocesses.

Items → Reversal of Billable Items → Make Basic Settings

3.7.2 Option 2: One step reversal approach
Here, a full reversal is executed for the IS-U print document. The reversal of BITs, the CI billing document
and the CI invoicing document is executed automatically:
This approach requires you to configure and implement the following:
1. Configuration of reversal reasons

2. Configure basic settings of BITs to enable automatic reversal depending on the reversal reason
3. Implementation of mappings between reversal reasons in IS-U and CI
3.7.2.1 Configuration of reversal reasons

Items → Reversal of Billable Items → Define Reasons for
Reversal for Billable Items
The parameter “Reversal Method for Billed items” provides different options for automated reversals. As
shown below, the value 4 reverses the invoicing document, the billing document, and the BITs.
3.7.2.2 Enable automatic reversal according to the reversal reason

In the following Customizing activity, the following aspects are relevant:
• BITs created by IS-U must not be reversed because this leads to inconsistencies. Accordingly, you
can configure a suppression of the BIT reversal at the level of the corresponding subprocesses.
• Enable the reversal activity according to the way in which the reversal reason has been configured.

Items → Reversal of Billable Items → Make Basic Settings
3.7.2.3 Implementation of mappings between reversal reasons in IS-U and CI
Transfer of the appropriate CI reversal reason to the BITs can be achieved by implementing event 30. You
can adjust the sample function module ISU_INV_ISU2CI_EVENT_30_CI01 by copying the sample function
module into the customer namespace and adjusting it.
3.8 Outsorting
Outsorting in IS-U invoicing is still applicable but is not really suitable from a business perspective. IS-U
invoicing has the character of a technical transfer process that should be kept in the background as far as
possible. Therefore, we recommend applying outsorting capabilities in Convergent Invoicing.

Payable → Convergent Invoicing → Invoicing → Clarification in
Invoicing → Validation
4 MIGRATION AND ACTIVATION

The activation of the integration of IS-U and CI depends on the assignment of an appropriate CI integration
category to a contract account. The CI integration category is stored on the contract account time-
independently. When IS-U invoicing is next executed for that contract account, invoicing is executed in CI. In
the case of reversal, the initial integration category is retrieved from the reversed IS-U billing document and
applied during the repeated billing and invoicing. The activation must be prepared thoroughly and with
caution.
Parallel usage of classic IS-U invoicing and CI Invoicing in one client is possible, as the control is on the level
of each individual contract account. In some cases, parallel usage is applied temporarily or permanently.
Examples:
• Temporary usage of both options in case of stepwise migration of contract accounts with budget billing
• Restrictions for the migration of budget billing plans
• Migration of contract accounts after the periodic invoicing took place
• Permanent usage of both options, such as customer group 1 in classic IS-U, customer group 2 in CI

In the next chapters, assignment of the CI integration category to new contract accounts upon creation and
change of the integration category in existing contract accounts is discussed.
4.1 Default CI Integration Category for New Contract Accounts
If you create new contract accounts using transaction CAA1, for example, you can automatically populate
the CI integration category with an appropriate default value. For the automatic determination of the default
value, you must implement the method CA_DETERMINE_ISU2CI_CATEGORY in the BAdI
ISU_INTEGRATION_TO_CI. The method imports contract account header data and contract account
partner-specific data and exports the integration category determined.
4.2 Change of the Integration Category in the Contract Account
The integration category in the contract account can be changed:

• Using report ISU_CONTACCT_ISU2CI_FILL
This report can change the integration category for the contract account and adjust corresponding
budget billing plans accordingly. For the statistical and partial bill procedure, checks exist to prevent
the change for both the contract account and the budget billing plan if budget billing requests have
already been created or payments were made for the budget billing plan. Please read the system
report documentation for further technical details.
• Using transaction CAA2 (Change Contract Account)
This is only applicable for new contract accounts or contract accounts without active budget billing
plans.
The integration category is stored time-independently at header level of the contract account. After the
change, the next billing and invoicing run will use Convergent Invoicing.
If the integration category has been changed and a full reversal takes place, billing and invoicing will
consider the integration category in the original documents for the bill and invoice correction. If you have
changed the integration category from logically “IS-U Invoicing” to “Convergent Invoicing”, the original
invoicing run is based on “IS-U Invoicing”. You perform the reversal and bill and invoice again, “IS-U
Invoicing” will be applied again.
Changing the CI integration category in the contract account is critical. For safeguarding, it is possible to
check the CI integration category before saving the contract account. This can be achieved by implementing
the method CA_CHECK_ISU2CI_CATEGORY in the BAdI ISU_INTEGRATION_TO_CI. This method can be
used to implement customer-specific checks for a new or changed integration category value in a contract
account. It imports the contract account header data and partner-specific data, with the values related to
both before and after the change.
Please note that SAP has implemented the method CA_CHECK_ISU2CI_CATEGORY in the fallback class
CL_DEF_IM_ISU_INTEGR_TO_CI in the BAdI ISU_INTEGRATION_TO_CI to provide some default checks.
If a customer-specific check is implemented, the default checks will be overwritten. We strongly recommend
copying the entire code in the default check method into the customer-specific implementation. Any
customer-specific check can be extended to complement the default checks.
4.3 Mass Change of Contract Accounts – Report ISU_CONTACCT_ISU2CI_FILL
ISU_CONTACCT_ISU2CI_FILL performs a mass conversion of contract accounts to specific integration

categories:

The report uses the BAdI ISU_INTEGRATION_TO_CI and its 2 integration category-related methods to
determine default values and perform checks. In the section “Set Integration Category”, if you select the
option “Integration Category from BAdI”, the logic implemented in the BAdI is used:
• The value for a default integration category is determined using the BAdI. If no customer-specific
determination method exists, an error message is provided in the application log.
• The determined integration category is checked in the BAdI if a customer-specific check is provided.
If active budget billing plans with statistical or partial bill procedure related to the contract accounts exist, the
change of the integration category works well if the budget billing plans are new. A good point in time for the
change of the integration category is shortly after the last invoicing run took place.

www.sap.com
© 2016 SAP SE or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form
or for any purpose without the express permission of SAP SE or an SAP
affiliate company.
SAP and other SAP products and services mentioned herein as well as their
respective logos are trademarks or registered trademarks of SAP SE (or an
SAP affiliate company) in Germany and other countries. Please see
https://www.sap.com/corporate/en/legal/copyright.html?source=exp#copyrigh
t-trademark-notice for additional trademark information and notices. Some
software products marketed by SAP SE and its distributors contain
proprietary software components of other software vendors.
National product specifications may vary.
These materials are provided by SAP SE or an SAP affiliate company for
informational purposes only, without representation or warranty of any kind,
and SAP SE or its affiliated companies shall not be liable for errors or
omissions with respect to the materials. The only warranties for SAP SE or
SAP affiliate company products and services are those that are set forth in
the express warranty statements accompanying such products and services,
if any. Nothing herein should be construed as constituting an additional
warranty.
In particular, SAP SE or its affiliated companies have no obligation to pursue
any course of business outlined in this document or any related presentation,
or to develop or release any functionality mentioned therein. This document,
or any related presentation, and SAP SE’s or its affiliated companies’
strategy and possible future developments, products, and/or platform
directions and functionality are all subject to change and may be changed by
SAP SE or its affiliated companies at any time for any reason without notice.
The information in this document is not a commitment, promise, or legal
obligation to deliver any material, code, or functionality. All forward-looking
statements are subject to various risks and uncertainties that could cause
actual results to differ materially from expectations. Readers are cautioned
not to place undue reliance on these forward-looking statements, which
speak only as of their dates, and they should not be relied upon in making
purchasing decisions.

Implementation Guideline ISU2CI Integration

Uploaded by

Document Information

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

Implementation Guideline ISU2CI Integration

Uploaded by

Copyright:

Available Formats

SAP S/4HANA Utilities: Integration of IS-U and

© 2022 SAP SE. All rights reserved.

INTERNAL | SAP AND CUSTOMER USE ONLY

© 2022 SAP SE. All rights reserved. 2

INTERNAL | SAP AND CUSTOMER USE ONLY

© 2022 SAP SE. All rights reserved. 3

INTERNAL | SAP AND CUSTOMER USE ONLY

2.1 Different Invoicing Options for IS-U

SAP S/4HANA Utilities (IS-U) supports 3 different options:

• Option 1: Classic IS-U

2.2 Documentation and Useful References

The following sources provide useful information:

• SAP Road Map Explorer

• Note 2935426 discusses recommendations and restrictions

© 2022 SAP SE. All rights reserved. 4

INTERNAL | SAP AND CUSTOMER USE ONLY

3 IMPLEMENTATION AND CONFIGURATION

3.1 Enhancement of the Database Table ERDK in IS-U Invoicing

3.2 Several Prerequisites – Customizing in Convergent Invoicing

© 2022 SAP SE. All rights reserved. 5

INTERNAL | SAP AND CUSTOMER USE ONLY

Transaction code SPRO

Transaction code SPRO

Subprocesses are configured here:

Transaction code SPRO

Examples of subprocesses used throughout this document are shown below:

Subprocess Subprocess Description

The subprocesses are assigned to the BIT class:

Transaction code SPRO

© 2022 SAP SE. All rights reserved. 6

INTERNAL | SAP AND CUSTOMER USE ONLY

CI billing processes are configured here:

Transaction code SPRO

Invoicing processes are maintained here:

Transaction code SPRO

© 2022 SAP SE. All rights reserved. 7

INTERNAL | SAP AND CUSTOMER USE ONLY

3.3 Configuration of the Integration Category

Transaction code SPRO

© 2022 SAP SE. All rights reserved. 8

INTERNAL | SAP AND CUSTOMER USE ONLY

EA2CI_TRANS (report REAINV_TRANSFER_ISU2CI). Transaction EA2CI_MON provides a monitor

© 2022 SAP SE. All rights reserved. 9

INTERNAL | SAP AND CUSTOMER USE ONLY

Code example related to the overall example configuration:

Assign your function module to the event "R581" in transaction FQEVENTS.

© 2022 SAP SE. All rights reserved. 10

INTERNAL | SAP AND CUSTOMER USE ONLY

3.4 Configuration of Posting Areas for IS-U and CI

IS-U Attributes Encoding Decoding Comment

© 2022 SAP SE. All rights reserved. 11

INTERNAL | SAP AND CUSTOMER USE ONLY

Transaction code SPRO

Transaction code SPRO

Transaction code SPRO

© 2022 SAP SE. All rights reserved. 12

INTERNAL | SAP AND CUSTOMER USE ONLY

Mapping (Decoding) in CI:

Transaction code SPRO

As a prerequisite, define billable item types:

Transaction code SPRO

Allocation of document line types to billable item types:

Transaction code SPRO

3.5 Budget Billing