Skip to end of metadata
Go to start of metadata

Business Transaction Events → Process Interface (Info-systems Process)

Business Transaction Events -

Like SD user exits, BTE are the enhancement techniques that are designed and used mainly for FI (Finance) module.

Unlike BADI, business transaction events are implemented specifically (individually) for 'SAP', 'Partner' and 'Customer'.

Each (SAP, Partner and customer) will have different implementations which will not intervene into each other.

This is what makes it more functionally business oriented and allows different external as well as internal applications to connect via interfaces.

Each (SAP, Partner and customer) will develop its own function module which will uniquely identify its logic and will register with the system (as a product with the custom or standard function module).

This facilitates the system to check each ones (SAP, Partner and customer) implementations.

After all, the main requirement lies in enhancing the standard process.

Now, when we talk about BTE data exchange, we have interfaces playing a vital role.

There are two BTE interfaces,

Publish & Subscribe interfaces (Informing Interfaces)

Process Interfaces (Process)

I would suggest referring to the SAP documentation available for the two interfaces.

Here, this scenario deals with the 'Process Interface' for event '00001030' (OPEN_FI_PERFORM_00001030_P) for replacing the standard dunning form supplied during the 'Customizing settings' at runtime without actually replacing the entry in 'Customizing settings'.

Our implementation will act as a 'Hook' point which will trigger the customized form at runtime.

Business Area: Dunning (FI-FI)

Dunning -
It is a process by which reminders are sent to the customers requesting them to pay their dues for their respective 'Open items'. These reminders are automatically sent based on the 'Dunning procedure', 'dunning area' and 'dunning level' mainly which are maintained in the 'Customized settings'.
Also, the form (notice) to be printed based on the logic of 'dunning level' is assigned in the customized settings.
If the customer fails to pay the requested amount within the due dates, firstly the customer loses the opportunities to avail some discount schemes as well as when the final gentle notice a 'Legal notice' is sent to the customer with some surcharge based on certain calculations.

These settings are performed by the FI consultant, but just to show the standard form maintained observe the entry, 'Financial Accounting' - 'Accounts Receivable and Accounts Payable' - 'Business transactions' - 'Dunning' - 'Printout' - 'Assign dunning forms'

→ Another way to do that is 'Dunning' - 'Dunning Procedure' - 'Dunning Texts'.

→ Now, the 'dunning procedure' maintained for a customer (say) 'TS66A08' is '0001' which is (say) 'Four-level dunning, every two weeks' for country code (say) '1000'.

→ We can maintain 'dunning procedure' for a specific dunning area too, like '01' for 'domestic customer' and '02' for 'foreign customer',

→ First, we will observe the standard functionality,

→ The transaction for dunning is 'F150'.

→ Here, we maintain the necessary dunning parameters which are essential to 'Dunn' for a customer/vendor.

→ Save the parameters,

→ After all the parameters are maintained, generate an 'Individual Dunning Notice' and enable the printing 'checkbox'.

→ Observe the standard dunning notice generated,

→ Now, to enhance the standard process, we take help of the BTE.

→ The all-in-one place for BTE is transaction 'FIBF'.

→ Navigate to the 'Info system (Processes)' module,

→ For the attribute type 'A' that is 'Application Component', execute to find the possible 'BTE' under it.

→ Locate the suitable BTE (here 00001030) and observe the functional documentation as how the BTE will work?
→Secondly, click on the 'Sample function module' to reference the custom with the standard.

→ Here is the functionality this BTE will offer (Refer documentation).

→ Copy the sample function module into function module in customer namespace,

→ Write the source code which needs to be trigger at runtime, 'C_FORNR' denotes the 'form name'.

→ Activate the function module.

→ Now it's the time to register this product as a 'Customer' or 'Partner' ...

→ First create a product, navigate to the products. Observe,

→ Create any entry for the product,

→ The next most important step would be to register the 'Event' with the product (say) 'ZDAVE',

→ So based on the category (partner or customer) register,

→ Make a new entry,

→ Well, that's it! The time has come to observe the desired functionality achieved.

→ As like maintained in the previous stages of this 'Wiki', maintain parameters of the 'Dunn' run and generate the 'Individual' dunning notice.

→ Try possibly 'Debugging' the application so as to understand the complete replacement form BTE,

→ Observe,

→ After drilling deep into the function module, observe the table 'APCUSTAB' which denotes the customer table populated if the BTE is implemented as a 'Customer'. Whereas, the table 'APPRTTAB" denotes the partner table and 'APSAPTAB' denotes SAP implementation table respectively.

→ Generally, when there is no BTE implementation (Customer or Partner), then the SAP implementation which is a standard one is triggered.

→ The good news is that! The table 'APPCUSTAB' contains some entry. But, what does it have in it. Observe to find out.

→ To confirm with, the status for customer implementation can be verified during debugging.

→ The indicator 'C' indicates 'Customer' implementation.

→ Once again,

→ Here it is! This confirms that our implementation function module has triggered and used by the system for the dunning form printing procedure.

→ Observe the customer implementation code where the values of the custom form have been accepted.

→ Observe the BTE function module accessed,

→ Finally, observe the print notice after the BTE has triggered.

→ The indications in 'RED' show the added text in the 'Z' form supplied (hard-coded) in the BTE.