Managing the operations or run phase of Central Finance can often be challenging. Errors can pile up in AIF and you can work through these using the great tools provided by AIF like “Message Summary” or assigning “Processors” who are responsible for specific errors messages. At times, this can get tedious because out of the box SAP only provide a single recipient CFIN_RECEPIENT for all messages.
Yep there it is, a huge amount of errors all lumped into a single group for each interface.
But what if you have multiple teams or responsibilities in your organisation and want to route specific errors messages to different groups of users? Do you have a customer master data team who should look after customer errors, another team for materials and so on? Well, lucky for you AIF can route messages to specific groups with an adjustment to the AIF configuration and/or use of a BADI.
The architecture below represents this approach, where source systems send data via Central Finance into S/4 HANA. AIF then uses its own framework to determine the message recipients in combination with the AIF message context, message categories and optionally a BADI.
Note: The method described in this blog is technically a modification to the SAP standard delivery of Central Finance content. If you are to install a new version of an interface with an updated BC set, then the same changes would need to be made on the new interface version.
Before you start, read of this excellent blog from michal.krawczyk2 that describes some of the steps involved. https://blogs.sap.com/2016/08/19/michal-s-tips-aif-alert-recipient-based-on-error-message-class-and-...
Step 1 – Unlock the /FINCF namespace
Before the namespace /FINCF can be changed via AIF configuration it must be unlocked with transaction FINS_CFIN_AIF_SETUP - AIF Setup for Central Finance with the step "Prepare Configuration". Once the updated configuration is completed the namespace should be locked with the "Complete Configuration" to avoid unintended changes being made.
Create a new custom table in SE11 that is a copy of /AIF/RECA_TMPL. This table will hold the assignment of message categories to the recipients intended to receive the error messages per interface. Create a maintenance view for this table and fill it with the intended relationships. Set the Fallback indicator for the recipient that is to receive any errors that cannot be assigned to other groups at runtime.
In the folder Configure Alerts, update configuration with the new custom table as the recipient assignment table for every interface and version.
In AIF you use recipients to define which users are responsible for which data messages. Define as many recipients as you require based on the teams/responsibilities of the organisation running Central Finance.
The recipient assignment of a user defines which data messages they will see in the Interface Monitor and for which data messages they will receive alert notifications. This is the content pre-delivered by SAP with only a single recipient CFIN_RECIPIENT.
Message categories group common error messages together in configuration, the transaction /AIF/MSG_CAT_DEF- Define Message Category is used. Define as your groups as required.
In this step assign the errors messages to message category groups in transaction /AIF/MSG_CAT_ASGN - Assign Message Category. This task is open in each system and messages can be added as they occur as part of operations. Example for COST_CENTRE message category.
In some cases, using step 6 and transaction /AIF/MSG_CAT_ASGN to assign a message class and message number to a recipient is not detailed enough to route the error to the correct recipient. Think of the generic messages shown below. These are encountered no matter what the context, it could be a document type mapping, customer, vendor, material, profit centre, functional area etc etc. Using the message class and message number to map these to a recipient will not work because recipients will get invalid error messages in their queue.
To handle this use BADI /AIF/ALERT_DET_RECIPIENTS, this will allow you to flexibly re-determine the recipients based off the context provided in the error, such as the message long text, the object impacted etc. My recommendation is to use this BADI with a BRF+ decision table for all errors so the management of the recipient determination is in one central BRF ruleset (in other words, do not use /AIF/MSG_CAT_ASGN - Assign Message Category). An example BRF is shown below when message FINS_CFIN_AC_DOC 017 is issued, then the rule re-determines the message category based on the key field value 1 from the AIF message.
Using either /AIF/RECIPIENTS - Recipients of a User or /AIF/MYRECIPIENTS - Recipients of Current User a user must be subscribed to the recipients they intend to monitor in AIF. Once assigned when a user starts the AIF monitor with transaction FINS_CFIN_AIF_IFMON - Interface Monitor (or /AIF/IFMON - Interface Monitor) the groups will be displayed and messages split by recipient for each group.
So how does this look in the AIF monitor?
Like this, you can see errors are assigned to the respective recipient groups.
Some Final AIF thoughts
AIF also provides custom functions that should be evaluated for any Central Finance project to see if they can provide value into the daily management of AIF. I have briefly mentioned these below along with an example use case.
Reprocessing actions are a powerful tool in AIF, these can be used to post process an error message and perform any tasks necessary to clear the error message. Potential use cases are to create activity type master data automatically, or to extend customers or vendors automatically without the need for any manual intervention.
Yep there it is, a huge amount of errors all lumped into a single group for each interface.
But what if you have multiple teams or responsibilities in your organisation and want to route specific errors messages to different groups of users? Do you have a customer master data team who should look after customer errors, another team for materials and so on? Well, lucky for you AIF can route messages to specific groups with an adjustment to the AIF configuration and/or use of a BADI.
The architecture below represents this approach, where source systems send data via Central Finance into S/4 HANA. AIF then uses its own framework to determine the message recipients in combination with the AIF message context, message categories and optionally a BADI.
Note: The method described in this blog is technically a modification to the SAP standard delivery of Central Finance content. If you are to install a new version of an interface with an updated BC set, then the same changes would need to be made on the new interface version.
Before you start, read of this excellent blog from michal.krawczyk2 that describes some of the steps involved. https://blogs.sap.com/2016/08/19/michal-s-tips-aif-alert-recipient-based-on-error-message-class-and-...
Step 1 – Unlock the /FINCF namespace
Before the namespace /FINCF can be changed via AIF configuration it must be unlocked with transaction FINS_CFIN_AIF_SETUP - AIF Setup for Central Finance with the step "Prepare Configuration". Once the updated configuration is completed the namespace should be locked with the "Complete Configuration" to avoid unintended changes being made.
Step 2 - Define a Custom Assignment Table
Create a new custom table in SE11 that is a copy of /AIF/RECA_TMPL. This table will hold the assignment of message categories to the recipients intended to receive the error messages per interface. Create a maintenance view for this table and fill it with the intended relationships. Set the Fallback indicator for the recipient that is to receive any errors that cannot be assigned to other groups at runtime.
Step 3 - Define Namespace-Specific Features – Configure Alerts
In the folder Configure Alerts, update configuration with the new custom table as the recipient assignment table for every interface and version.
Step 4 - Define Namespace-Specific Features – Define Recipients
In AIF you use recipients to define which users are responsible for which data messages. Define as many recipients as you require based on the teams/responsibilities of the organisation running Central Finance.
The recipient assignment of a user defines which data messages they will see in the Interface Monitor and for which data messages they will receive alert notifications. This is the content pre-delivered by SAP with only a single recipient CFIN_RECIPIENT.
Step 5 - Define Message Categories
Message categories group common error messages together in configuration, the transaction /AIF/MSG_CAT_DEF- Define Message Category is used. Define as your groups as required.
Step 6 - Assign Message Categories
In this step assign the errors messages to message category groups in transaction /AIF/MSG_CAT_ASGN - Assign Message Category. This task is open in each system and messages can be added as they occur as part of operations. Example for COST_CENTRE message category.
Step 7 - Advanced Message Determination using BADI
In some cases, using step 6 and transaction /AIF/MSG_CAT_ASGN to assign a message class and message number to a recipient is not detailed enough to route the error to the correct recipient. Think of the generic messages shown below. These are encountered no matter what the context, it could be a document type mapping, customer, vendor, material, profit centre, functional area etc etc. Using the message class and message number to map these to a recipient will not work because recipients will get invalid error messages in their queue.
To handle this use BADI /AIF/ALERT_DET_RECIPIENTS, this will allow you to flexibly re-determine the recipients based off the context provided in the error, such as the message long text, the object impacted etc. My recommendation is to use this BADI with a BRF+ decision table for all errors so the management of the recipient determination is in one central BRF ruleset (in other words, do not use /AIF/MSG_CAT_ASGN - Assign Message Category). An example BRF is shown below when message FINS_CFIN_AC_DOC 017 is issued, then the rule re-determines the message category based on the key field value 1 from the AIF message.
Step 8 – Assign Recipients to Users
Using either /AIF/RECIPIENTS - Recipients of a User or /AIF/MYRECIPIENTS - Recipients of Current User a user must be subscribed to the recipients they intend to monitor in AIF. Once assigned when a user starts the AIF monitor with transaction FINS_CFIN_AIF_IFMON - Interface Monitor (or /AIF/IFMON - Interface Monitor) the groups will be displayed and messages split by recipient for each group.
So how does this look in the AIF monitor?
Like this, you can see errors are assigned to the respective recipient groups.
Some Final AIF thoughts
AIF also provides custom functions that should be evaluated for any Central Finance project to see if they can provide value into the daily management of AIF. I have briefly mentioned these below along with an example use case.
| Object | Examples | System Admin Transaction |
| Custom Hints | Write a procedure on how to correct a common error and link it to a repository of guides held externally to SAP | /AIF/CUST_FUNC |
| Custom Functions | Call a transaction for a selected message e.g. FB03 document display | /AIF/CUST_HINTS |
| Custom Message Texts | Write you own text to replace the original text of a message | /AIF/CUST_TEXT |
| Custom Data Links | Enhance a message with your own custom data link | /AIF/CUST_LINK |
Reprocessing actions are a powerful tool in AIF, these can be used to post process an error message and perform any tasks necessary to clear the error message. Potential use cases are to create activity type master data automatically, or to extend customers or vendors automatically without the need for any manual intervention.
- SAP Managed Tags:
4 Comments
