tl;dr

I show you how to add two types of receiver determination filters to an SAP delivered ALE BAPI that does not support filtering in the standard delivery. The extension process is modification free and requires only customizing and trivial coding. I also deliver some background information on the workings of the ALE / IDoc machinery. The example is bad on the ALE function for SEPA mandate distribution.

Business scenario

Our company employs a central master data server (MDS) for several FI/CO master data objects, like Customer and Vendor. The MDS distributes the master data to the operational systems executing business processes like payments or dunning. While the MDS holds the enterprise view on all master data, the operational systems shall receive only those parts that are relevant to them. Relevancy is determined by a combination of criteria, like account group and company code(s) the data is relevant for.

Enter SEPA Mandate

The unification of the Euro payment area (SEPA) brings about new processes for direct debit payments. In future, it is necessary to establish a so-called Mandate, which is basically an agreement between you and your Customer that allows you to debit from your customer’s account. The Mandate is therefore linked to your Customer, both in the business as well as the IT sense.

Requirements

Combining the above scenario description for the master data landscape and the SEPA direct debit process leads to the following requirements:

  • Maintain Mandates on MDS together with Customer
  • Distribute Mandates alongside Customer to the relevant target systems
  • Relevancy criteria for SEPA Mandate are derived from the Customer it is linked with
    (in English: “Mandate goes where Customer goes”)

Background information

This section will help you understand the implementation. If you only want to add a message dependency for SEPA messages, you can skip ahead to the Implementation section.

IDoc “receiver determination”

IDoc is the oldest form of message based SAP system connection. While this technology offers powerful filtering and data translation functions, a receiver determination can only be applied indirectly, by adding a data filter on a field in the top-level segment of the IDoc. We use the following criteria:

  • Account group of Customer
  • Classifications (these are modeled after the company codes / BUKRS)

Filtering is done in the distribution layer and does not require changes on the application programm side, i.e. it is always possible to add additional data filters (even to SAP delivered IDoc types) via customizing without modifications.

ALE BAPI receiver determination

During the mid 90s of the last century, SAP introduced ALE for connecting business processes across several systems. This is achieved by automatically generating IDoc message types (the technical foundation) from BAPI methods that are connected to BOR objects. All ALE BAPIs automagically take use of the common ALE layer, that provides the same functionality as classic IDoc, but adds a receiver determination function.

2 types of receiver filters are supported:

  • Value filter: Data is sent to receiver if the message contains a given value
  • Dependent message filter: Data is sent if it is linked to another message

The ALE BAPI receiver determination does require changes on the application program using the ALE BAPI. This is necessary as unlike with IDoc, the filter values are not read from the IDoc message, but have to be provided by the application program (whilst calling ALE_ASYNC_BAPI_GET_RECEIVER). This provides greater flexibility, but also means you have to rely on your favorite software vendor to provide some extension points for you.

Implementation

The following implementation adds a value-based and a message dependency-based receiver determination filter to the SEPA.SaveReplica ALE BAPI. The following SAP notes are prerequisites for the implementation:

The filters created will be:

  • SEPA Mandate sender type (Z_SEPA_MANDATE_SND_TYPE)
    This contains the BOR type of the payer. For Customers, this field contains the value BUS3007
  • Mandate sender ID (Z_SEPA_MANDATE_SND_ID)
    This contains the key of an object paying an invoice and will be used for the message dependency. For Customer, this is the Customer number (KNA1-KUNNR).

Add receiver determination filters

  1. BD95: Create filter objects. Reference tables with DDIC help assigned if possible:
    /wp-content/uploads/2013/10/bd95_308392.png
  2. BD96: Assign filters to ALE BAPI. This setting is based on the BOR object name and verb (method). For distribution, we are only interested in SEPAMandate.SaveReplica:
    /wp-content/uploads/2013/10/bd96_308417.png

Now the filter objects are known, but the SAP application program does not populate them, as the programmer at SAP have no way of knowing these filters. This is rectified in the next step.

Extend SAP application program

SAP has to provide an extension point so that you can populate your filter values. This usually involves coding some function module or implementing a BAdi and making your implementation known to the SAP implementation.

  1. SE80: Copy function module SEPA_MANDATE_GEN_ALE_FILTER to a Z* name and implement it, like this:
    /wp-content/uploads/2013/10/se80_308418.png
  2. SM30: To make the SAP Standard aware of your filter population function, add your newly created function to the view V_SEPA_CUST:
    /wp-content/uploads/2013/10/sm30_308419.png

Add message dependency

The filter for the sender ID should not be used directly in the ALE distribution model as a value filter. Instead, it is used an input to a function module that in turn creates the filter values (here: attributes of Customer) needed to determine if the dependent message (here: DEBMAS) would be sent to the same receiver system.

  1. BD48: Add the dependent message and the filter value containing the object ID to make the correlation to that message
    /wp-content/uploads/2013/10/bd48_308429.png
  2. BDA4: Ensure that the referenced message type is in turn assigned to a BOR type. This is necessary as one object (here: Customer) can be distributed by several different IDoc messages. Luckily, this is already provided in the standard for DEBMAS / Customer:
    /wp-content/uploads/2013/10/bda4_308430.png
  3. BD71: Assign a function module to the BOR object that reads out filter values for this message. The function module needs to return values for all the IDoc data filters specified for the top-level segment (here: E1KNA1M of DEBMAS). Luckily, this is already provided in the standard for DEBMAS / Customer:
    /wp-content/uploads/2013/10/bd71_308431.png

Change ALE distribution model

You are now able to add additional filters for SEPAMandate.SaveReplica in the ALE distribution model (BD64):

/wp-content/uploads/2013/10/bd64_308447.png

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply