In my introduction post I described the flexible possibilities of integration between BRIM (CI more in particular) and Utilities. We now have finally arrived at the fourth case which would be the most interesting one for many:
How can I turn things around and integrate IS-U to CI? As I described in my introduction post, this way of working has its limitations (not supporting adjustment reversals for now, for example). But, if you want to leverage the billing and invoicing in CI at a maximum, you could use IS-U to calculate and create the billable items, and use CI to perform billing and invoicing, together with non-commodity components integrated.
As a reminder, below you find the process chain for IS-U and CI integration:
In my previous blogs, I explained how to do the customizing from CI side. This I will not discuss again in this blog. For example, you could create one billable item class ZISU with a subprocess per type of IS-U billing (like Periodic, Interim, Final or Budget bill).
Note that, if you want to send your print document to CI, additional fields are required in ERDK. You should first generate particular fields in customer include CI_ERDK. You can do this using report REAINV_ENH_ISU2CI. If you don't do this, you will not get an error but multiple logging fields will be missing.
The Integration category is what defines the IS-U to CI integration. This must be configured on contract account level. By default, BAdI ISU_INTEGRATION_TO_CI is called to check if the contract account is allowed to switch to an integration category. The default check looks for existing Budget Billing Plans that are active. If found, you cannot enter an integration category for consistency reasons. Of course, this can be overruled by your own BAdI implementation. You can also use this BAdI to set a default Integration Category proposition when creating new contract accounts.
To define the Integration Cagegory, typically you can play with Integration Types. These integration types are used to pilot (for example) the IS-U document type to the correct Billable Item Class and Subprocess. You can enter your own logic in event R581. If you don't choose to do so (like my example), then always the default Integration Type will be chosen. For Budget Billing Plans, a different SubProcess is advised, because the CI invoicing should always be seperate from the normal documents.
An example of piloting would be:
You also define if the transfer is done during IS-U Invoicing (real-time) or in Batch via report REAINV_TRANSFER_ISU2CI. This report is also used if the direct transfer fails (due to missing customizing, for example).
Last thing to define in the Integration Category is the function module to effectively transfer the billable items to CI. By default, SAP provides function module ISU_INV_ISU2CI_EVENT_30_CI01.
This customizing is done under SAP Utilities ->Contract Billing ->Invoicing -> Integration with Convergent Invoicing -> Generation of Billable Items in Convergent Invoicing -> Maintain Integration Categories
In this customizing, you do the mapping to assign the lines of the IS-U Print document to a Billable Item Type in CI. The most logic way is to do the mapping based on line item type, but you can also add the Integration Category as an extra indicator in the customizing.
You can find this customizing under SAP Utilities ->Contract Billing ->Invoicing -> Integration with Convergent Invoicing -> Generation of Billable Items in Convergent Invoicing -> Allocation of Document Line Type toType of Billable Item
Some other remarks and tips include:
For the reversal of Billable Items, this should not be allowed to be done manually. This will lead inevitabely into inconsistencies between CI and IS-U. There should be a customizing be done to avoid this. In this customizing, you also define the reversal method of Billed Items. Note that as of
As a reminder; only full reversal is currently supported. Adjustment reversal will currently not work with IS-U to CI transfer. There are two ways you can reverse the IS-U invoice document:
The details are not discussed in this blog. If there are specific demands for a more in detail blog, please let me know.
Partial bills follow the same procedure as the "normal" IS-U invoicing transfer to CI. The following Budget Billing procedures are supported:
To ensure correct processing, the used Billable Item Class shoud contain interface component "Offsetting in Invoicing", and define the offsetting categories in customizing.
Further details are not discussed in this blog. If there are specific demands for a more in detail blog, please let me know.
By default, the account determination as of the IS-U Invoicing is taken over. If this proves to be insufficient, you can use posting area 8120 (from CI side) and posting area R480 from IS-U side to add keys for the Account Assignment mapping.
For main/subtransaction determination, you can use posting area R481 from IS-U side and 8121 from CI side to perform additional mapping.
As these are optional steps, they are not detailled in this blog.
The extra field (default hidden) to set the Inegration Category can be found here:
In my example, I'll do a simple billing of meter in IS-U. In the invoicing process, you can already see that this print document is flagged for transfer to CI. This is because I chose not to do this real-time. To avoid inconsistencies, in most scenario's the direct transfer to CI is the best option.
Next step is the transfer using REAINV_TRANSFER_ISU2CI, which shows following protocol after completion:
Now the Billable Items are created in CI. From here, the CI billing & invoicing process takes place. On a IS-U print document level, we find additional fields. You also see that a specific print block is created for these cases. The print document also is not posted, no FICA document can be found:
The SourceTransaction field is a hotspot, you can acces the linked CI invoice document by double clicking this field:
This wraps up my cases of BRIM integration with IS-U, and the other way around. I hope you found this informative and interesting, and I hope that you are now convinced that CI is an easy and complete solution to integrate commodity and non-commodity for IS-U. If you have specific questions, don't hesitate to comment or to contact me.
How can I turn things around and integrate IS-U to CI? As I described in my introduction post, this way of working has its limitations (not supporting adjustment reversals for now, for example). But, if you want to leverage the billing and invoicing in CI at a maximum, you could use IS-U to calculate and create the billable items, and use CI to perform billing and invoicing, together with non-commodity components integrated.
As a reminder, below you find the process chain for IS-U and CI integration:
Customizing
Preparation
In my previous blogs, I explained how to do the customizing from CI side. This I will not discuss again in this blog. For example, you could create one billable item class ZISU with a subprocess per type of IS-U billing (like Periodic, Interim, Final or Budget bill).
Note that, if you want to send your print document to CI, additional fields are required in ERDK. You should first generate particular fields in customer include CI_ERDK. You can do this using report REAINV_ENH_ISU2CI. If you don't do this, you will not get an error but multiple logging fields will be missing.
Integration category
The Integration category is what defines the IS-U to CI integration. This must be configured on contract account level. By default, BAdI ISU_INTEGRATION_TO_CI is called to check if the contract account is allowed to switch to an integration category. The default check looks for existing Budget Billing Plans that are active. If found, you cannot enter an integration category for consistency reasons. Of course, this can be overruled by your own BAdI implementation. You can also use this BAdI to set a default Integration Category proposition when creating new contract accounts.
To define the Integration Cagegory, typically you can play with Integration Types. These integration types are used to pilot (for example) the IS-U document type to the correct Billable Item Class and Subprocess. You can enter your own logic in event R581. If you don't choose to do so (like my example), then always the default Integration Type will be chosen. For Budget Billing Plans, a different SubProcess is advised, because the CI invoicing should always be seperate from the normal documents.
An example of piloting would be:
- Periodic or interim billing --> SubProcess 1
- Final Billing --> SubProcess 2
- Budget Billing Plan --> SubProcess 3
You also define if the transfer is done during IS-U Invoicing (real-time) or in Batch via report REAINV_TRANSFER_ISU2CI. This report is also used if the direct transfer fails (due to missing customizing, for example).
Last thing to define in the Integration Category is the function module to effectively transfer the billable items to CI. By default, SAP provides function module ISU_INV_ISU2CI_EVENT_30_CI01.
This customizing is done under SAP Utilities ->Contract Billing ->Invoicing -> Integration with Convergent Invoicing -> Generation of Billable Items in Convergent Invoicing -> Maintain Integration Categories
Document Line Type Assignment
In this customizing, you do the mapping to assign the lines of the IS-U Print document to a Billable Item Type in CI. The most logic way is to do the mapping based on line item type, but you can also add the Integration Category as an extra indicator in the customizing.
You can find this customizing under SAP Utilities ->Contract Billing ->Invoicing -> Integration with Convergent Invoicing -> Generation of Billable Items in Convergent Invoicing -> Allocation of Document Line Type toType of Billable Item
Other Notes
Some other remarks and tips include:
Reversal of BIT
For the reversal of Billable Items, this should not be allowed to be done manually. This will lead inevitabely into inconsistencies between CI and IS-U. There should be a customizing be done to avoid this. In this customizing, you also define the reversal method of Billed Items. Note that as of
IS-U Reversal process
As a reminder; only full reversal is currently supported. Adjustment reversal will currently not work with IS-U to CI transfer. There are two ways you can reverse the IS-U invoice document:
- Manual: you reverse the CI invoice and billing document. Then, if needed, you can on top of that reverse the IS-U Invoice document.
- Automated: You can also automatically reverse the original BIT when the IS-U print document is reversed. This requires some additional work:
- You need to pass the reversal reason. This can be done via a custom defenition of sample function module function module ISU_INV_ISU2CI_EVENT_30_CI01.
- You need to properly set up the Reversal Reason mapping and customizing
The details are not discussed in this blog. If there are specific demands for a more in detail blog, please let me know.
Partial bills
Partial bills follow the same procedure as the "normal" IS-U invoicing transfer to CI. The following Budget Billing procedures are supported:
- Stastistical Budget Billing
- Partial Billing
To ensure correct processing, the used Billable Item Class shoud contain interface component "Offsetting in Invoicing", and define the offsetting categories in customizing.
Further details are not discussed in this blog. If there are specific demands for a more in detail blog, please let me know.
Account determination
By default, the account determination as of the IS-U Invoicing is taken over. If this proves to be insufficient, you can use posting area 8120 (from CI side) and posting area R480 from IS-U side to add keys for the Account Assignment mapping.
For main/subtransaction determination, you can use posting area R481 from IS-U side and 8121 from CI side to perform additional mapping.
As these are optional steps, they are not detailled in this blog.
DEMO screens
Contract account
The extra field (default hidden) to set the Inegration Category can be found here:
Billing and Invoicing
In my example, I'll do a simple billing of meter in IS-U. In the invoicing process, you can already see that this print document is flagged for transfer to CI. This is because I chose not to do this real-time. To avoid inconsistencies, in most scenario's the direct transfer to CI is the best option.
Next step is the transfer using REAINV_TRANSFER_ISU2CI, which shows following protocol after completion:
Now the Billable Items are created in CI. From here, the CI billing & invoicing process takes place. On a IS-U print document level, we find additional fields. You also see that a specific print block is created for these cases. The print document also is not posted, no FICA document can be found:
The SourceTransaction field is a hotspot, you can acces the linked CI invoice document by double clicking this field:
Conclusion
This wraps up my cases of BRIM integration with IS-U, and the other way around. I hope you found this informative and interesting, and I hope that you are now convinced that CI is an easy and complete solution to integrate commodity and non-commodity for IS-U. If you have specific questions, don't hesitate to comment or to contact me.
- SAP Managed Tags:
1 Comment
