Introduction BAPI_ACC_DOCUMENT_POST is use for creating/posting accounting document for AP, AR and GL documents. This is an alternate solution in place of BDC which is used for posting documents through transactions like FB01 and FBB1. This BAPI can take input from legacy system and convert data into accounting document. A BTE has a predefined interface and it help us in adding custom functionality with help of a function module. This gets triggered after the BAPI calls and before the accounting document post, logics written in its FM executed and later reflected in the posted accounting document. This document explains the scenarios where implementation of BTE (Business Transaction Events) is required to populate certain fields in the posted accounting document, which are not possible to populate directly through standard BAPI ‘BAPI_ACC_DOCUMENT_POST’. Scenarios where implementation of BTE will be required Scenario 1 When there is requirement to get different Posting Key value in accounting document based on certain conditions. Explanation When posting happens through BAPI (BAPI_ACC_DOCUMENT_POST) then corresponding Posting Key is picked automatically by BAPI from the entries maintained in transaction 0B41. So, when there is requirement to overwrite this posting key for some conditions then we need to implement BTE RWBAPI01 to achieve this. Scenario 2 When there is requirement to get Reason Code value populated in the posted accounting document. Explanation For populating Reason Code via BAPI_ACC_DOCUMENT_POST there is not any respective field provided by BAPI in target table (Customer/Vendor). Here we will discuss 2nd scenario i.e. (populating Reason Code) in detail and in the same manner 1st scenario (changing posting key based on certain condition) can also be achieved with minor code change. Steps to populate reason code In order to get the reason code populated in the posted accounting document we need to implement BTE (Business Transaction Events). So we will discuss the flow to achieve the same. ◈ First of all, we need to enable extension that comes along with the BAPI as one of its parameter. ◈ There are two extensions, extension1 and extension2 ◈ Here, we need to enable extension1 to get our Reason Code populated in the Accounting document. ◈ We need to enable it in both the BAPI, BAPI_ACC_DOCUMENT_CHECK and BAPI_ACC_DOCUMENT_POST and rest of the parameters can be enabled as per the requirement. Let’s take an example where we are posting accounting document for AP, AR, GL. So, we will pass the parameters in below manner. Now, in order to use the extension1 we will first add this to the structure of accounting document which values we are passing to this BAPI to do the posting. Extension1 will be of type BAPIACEXTC_TAB which is a standard table type created by SAP. Highlighted part in the above snap can be removed by the target field where value of the ‘reason code’, which is to be populated is stored, similarly method name and other custom object name in above snap can be created as per the requirement. Now, we will proceed with implementation of BTE. Why BTE? When the BAPI is executed, Code written in the BTE – function module will be executed and the reason code of related line item will be changed/added before posting the documents. How to implement? Step1 ◈ Go to transaction FIBF, blank screen will appear with application tool bar, as shown below ◈ Hit on Settings tab and select ‘Process Modules’ -> …of a customer Below screen will appear. ◈ Here functional team need to add/configure process RWBAPI01. From Partner Enhancements tab, reference of process RWBAPI01 can be found and Z Function module needs to be created taking reference of standard Function module /OPT/BTE_RWBAPI01_BAPIEXTN (reference in below snap). ◈ Once the process (RWBAPI01) is enabled in process module of a customer, create A Function Group and later create one Function Module assigning this to created Function Group. ◈ Assign Z Function module (here Z_BTE_RWBAPI01_BAPIEXTN) to newly created Process. Here Product ZRWBAPI1 is company/organization specific. Reach out to your functional team to get this value. Different account maintains this custom Product specific to their businesses. Now we have our FM configured with the process RWBAPI01 in BTE for customer enhancements (as shown in above snap). Copy the changing and tables parameter to the new Z FM from the standard FM /OPT/BTE_RWBAPI01_BAPIEXTN (as shown in below snap). Now logic as required for populating Reason Code via extension1 can be added in Z function module leaving other parameters (Changing and Tables) intact. Note: Code in below snap can differ as per the requirements. Hence this way by implementing BTE we can populate Reason Code in the accounting document. What Exactly Happen/ How BTE really helped in above scenario Here we had to populate reason code in the accounting document but the challenge was the field which holds value of reason code (accit-rstgr) was not directly accessible to BAPI. Steps that took place in getting accit-rstgr value populated. 1. Extension is uncommented/enabled 2. Extension table is populated and later passed to BAPI 3 BAPI internally called the Process RWBAPI01 4. Z FM (Z_BTE_RWBAPI01_BAPIEXTN) gets called 5. Custom codes written inside the FM gets executed 6. accit-rstgr field gets populated and later same get reflected in the posted document. Some tips and tricks Scenario 1 You call BAPI_ACC_DOCUMENT_POST to post one accounting document with customer or vendor line item. You expect system to fill ‘payment term’ from the customer/vendor master data automatically, but it doesn’t happen. Solution Here we are passing Payment term value as blank to the BAPI (BAPI_ACC_DOCUMENT_POST) and expect BAPI to derive it from vendor/customer master data. In order to achieve this, we need to pass payment term value as ‘*’ instead of blank. IF Payment_term IS INITIAL. Payment_term = ‘*’. ENDIF. Thus BAPI will drive corresponding Payment term from the vendor/customer master data. Scenario 2 You call BAPI_ACC_DOCUMENT_POST to post one accounting document with customer or vendor line item. You expect system to fill ‘Baseline date from the customer/vendor master data automatically, but it doesn’t happen. Solution Here we are passing Baseline date value as blank to the BAPI (BAPI_ACC_DOCUMENT_POST) and expect BAPI to derive it from vendor/customer master data. In order to achieve this, we need to pass payment term value as ‘000000’ instead of blank. IF Baseline_date EQ space . Baseline_date = ‘00000000’.[YYYYMMDD] ENDIF. Thus BAPI will drive corresponding Baseline date from the OBB8 transaction where baseline date is maintained corresponding to Payment term.