BTE - Business Transaction Event
BTE - Business Transaction Event
Enhancement type developed for FI (Financial Accounting).
SAP Reference IMG -> Financial Accounting -> Financial Accounting Global Settings -> Business Transaction Events .
Customizing can be done via transaction FIBF.
Main steps for activating a BTE:
1.
Check OSS note for documentation and explanation
2.
Copy sample function module SAMPLE_INTERFACE_<event_number> to Customer namespace
3.
Make sure the application is active for Business Transaction Events , else maintain table TBE11.
4.
Maintain table TBE34 and TBE01
5.
Enter code to the BTE function module
How to check/debug?
To check the functionality, you can put a break-point in your BTE function module. If it's not called, put a breakpoint at FM
OPEN_FI_PERFORM_<BTE number>_E.
Related Transaction Code :
BERE Business Event Repository
BERP Business Processes
BF31 Application modules per Event
BF32 Partner Modules per Event
BF34 Customer Modules per Event
BF41 Application Modules per Process
BF42 Partner Modules per Process
BF44 Customer Modules per Process
BTE exits to add additional components to the SAP standard system, for example in the form of function modules. There
are two types of interface:
-
Publish and Subscribe interfaces
These give information that specific events have occurred in the SAP standard application and provide the data
generated to external software. However the external software does not return any data to the SAP standard system.
-
Process interfaces
These subject business processes to an external control function that is not part of the standard system; in other words the
process interfaces interrupt the standard process and deliver data to the SAP application.
A BTE exit is called up in the process, meaning that process modules check the events in Customizing for calling up the
BTE exits. In the BTE method, function modules are called up in specified events, to which they have been assigned in
Customizing. The event interface is predefined. To activate the process modules, choose _Settings for Process Interfaces ->
Assign Customer Function Modules to Process Interfaces.
Business Transaction Event - RWBAPI01 - For Accounting
Document Interface
usiness Transaction Event - RWBAPI01 - For Accounting Document
Interface
Link to Content's target Space :
http://wiki.sdn.sap.com/wiki/display/ABAP/BTE+-+Business+Transaction+Event
Applies to:
SAP 4.7x and above.
Summary
While Creating the Accounting document through BAPI - BAPI_ACC_DOCUMENT_POST posting keys are determined
automatically based on the configuration. Since this BAPI doesn't have any structure field to pass the posting key, posting
keys are picked up automatically based on the document type passed in BAPI header structure.
This document narrates how to change the default posting key while creating the Accounting document using the above
BAPI. This document also explains the steps involved in implementing a Business Transaction Event.
Author(s): Vinod Kumar T
Company:
NIIT Technologies Limited
Created on:
20.07.2010
Author(s) Bio
Vinod Kumar is an ABAP Consultant working with NIIT Technologies Limited.
Posting of Accounting Document Using BAPI - BAPI_ACC_Document
Post
Scenario
Create the accounting document for Customer advance payment against Net-banking transaction. Document is to be
created with the accounting document type (DZ-Customer Payment). Based on the Configuration, Customer line item is
posted against the posting key 01(Invoice-Debit) and GL Account line item is posted against the posting key 50(GL-Credit).
Since the FI documents of customer payment and Advance payment is to be separated, Customer line item of above entries
are to be posted with posting key 04 (Other Receivables - Debit) and GL Account line item to be posted with posting key 50
(GL - Credit)
Additional Structure for BAPI
For passing the additional data related to posting keys, Structure EXTENSION1 is to be filled with the required data.
Business Transaction Event used for changing the Posting key will be executed only when the record(s) are available in this
structure. See the Call to BTE in line number 59 of BAPI.
Code for Creating Account document using BAPI
1
REPORT zacctesting.
** Internal table and Work area declarations
DATA : wa_documentheader
it_accountgl
TYPE STANDARD TABLE OF bapiacgl09,
wa_accountgl
TYPE bapiacgl09,
it_accountreceivable TYPE STANDARD TABLE OF bapiacar09,
wa_accountreceivable TYPE bapiacar09,
it_currencyamount
8
9
10
11
16
TYPE bapiaccr09,
it_return
TYPE STANDARD TABLE OF bapiret2,
wa_return
TYPE bapiret2,
wa_extension1
TYPE STANDARD TABLE OF bapiacextc,
TYPE bapiacextc.
DATA : doc_amt_cr
TYPE bapiwrbtr VALUE '-50.00',
doc_amt_dr
TYPE bapiwrbtr VALUE '50.00'.
14
15
TYPE STANDARD TABLE OF bapiaccr09,
wa_currencyamount
it_extension1
12
13
TYPE bapiache09,
DATA:
lv_type
TYPE bapiache09-obj_type,
lv_key
TYPE bapiache09-obj_key,
17
lv_sys
18
** clear internal table
19
REFRESH :it_accountgl,
it_accountreceivable,
20
it_currencyamount,
21
it_return,
22
it_extension1.
23
24
25
26
27
28
29
30
31
32
33
34
35
36
TYPE bapiache09-obj_sys.
** Fill header data.
CLEAR : wa_documentheader.
MOVE sy-uname
TO wa_documentheader-username.
"Username"
MOVE 'Test'
TO wa_documentheader-header_txt."Header Text"
MOVE '0103'
TO wa_documentheader-comp_code. "Company Code"
MOVE sy-datum
TO wa_documentheader-doc_date.
MOVE sy-datum
TO wa_documentheader-pstng_date."Posting Date"
MOVE 'DZ'
TO wa_documentheader-doc_type.
"Doc Date"
"Doc Type"
MOVE 'Test'
TO wa_documentheader-ref_doc_no."Reference"
MOVE 'RFBU'
TO wa_documentheader-bus_act.
MOVE 'BKPFF'
TO wa_documentheader-obj_type.
MOVE '$'
TO wa_documentheader-obj_key.
MOVE sy-mandt
TO wa_documentheader-obj_sys.
"Comment for >= ECC5.0
"Comment for >= ECC5.0
"Comment for >= ECC5.0
**Fill GL Account Line item.
37
CLEAR : wa_accountgl, wa_currencyamount.
38
MOVE '0000000001' TO wa_accountgl-itemno_acc.
"Line Item No"
39
MOVE '0014000041' TO wa_accountgl-gl_account.
"G/L Account"
40
MOVE 'ItemTest'
TO wa_accountgl-item_text.
"Item Text"
41
MOVE '0103'
TO wa_accountgl-comp_code.
"Company Code"
42
MOVE '0000900390' TO wa_accountgl-profit_ctr.
"Profit Center"
43
MOVE 'Assign1'
44
APPEND wa_accountgl TO it_accountgl.
45
MOVE '0000000001' TO wa_currencyamount-itemno_acc.
46
MOVE '00'
TO wa_currencyamount-curr_type.
"Currency Type"
MOVE 'INR'
TO wa_currencyamount-currency.
"Currency"
MOVE doc_amt_cr
TO wa_currencyamount-amt_doccur. "Amount"
47
48
49
TO wa_accountgl-alloc_nmbr.
"Assignment"
"Line Item No"
APPEND wa_currencyamount TO it_currencyamount.
** Fill Customer Line item
50
51
52
CLEAR :wa_accountreceivable, wa_currencyamount.
MOVE '0000000002' TO wa_accountreceivable-itemno_acc. "Item No"
MOVE '0001000076' TO wa_accountreceivable-customer.
"Customer"
MOVE 'ItemTest'
TO wa_accountreceivable-item_text.
"Item Text"
54
MOVE '0103'
TO wa_accountreceivable-comp_code.
"Company Code"
55
MOVE 'Assign2'
TO wa_accountreceivable-alloc_nmbr. "Assignment.
56
APPEND wa_accountreceivable TO it_accountreceivable.
57
MOVE '0000000002' TO wa_currencyamount-itemno_acc.
58
MOVE '00'
TO wa_currencyamount-curr_type.
"Currency Type"
59
MOVE 'INR'
TO wa_currencyamount-currency.
"Currency"
60
MOVE doc_amt_dr
61
APPEND wa_currencyamount TO it_currencyamount.
53
"Line Item No"
TO wa_currencyamount-amt_doccur. "Amount"
62
**Fill Extension1 Structure used by BTE
63
**Posting key is to be changed for only for Customer line item
(0000000002)
64
**Records in this internal table will be checked in BTE
65
CLEAR : wa_extension1.
66
MOVE '000000000204' TO wa_extension1-field1.
67
APPEND wa_extension1 TO it_extension1.
68
** Call Bapi
69
70
71
72
73
74
75
76
77
78
79
80
CALL FUNCTION 'BAPI_ACC_DOCUMENT_POST'
EXPORTING
documentheader
= wa_documentheader
IMPORTING
"Comment for >=ECC5.0
obj_type
= lv_type
"Comment for >=ECC5.0
obj_key
= lv_key
"Comment for >=ECC5.0
obj_sys
= lv_sys
"Comment for >=ECC5.0
TABLES
accountgl
= it_accountgl
accountreceivable = it_accountreceivable
currencyamount
= it_currencyamount
extension1
= it_extension1
return
= it_return.
81
** Check for errors.
82
CLEAR : wa_return.
83
READ TABLE it_return INTO wa_return WITH KEY type = 'E'.
84
IF sy-subrc NE 0.
85
86
87
88
89
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'.
ENDIF.
** display the output
LOOP AT it_return INTO wa_return.
WRITE :/ wa_return-type,
wa_return-id,
90
wa_return-number,
91
92
93
94
wa_return-message.
ENDLOOP.
95
96
97
Implementing Business Transaction Event - RWBAPI01
Code for BTE Function Module
Step 1: Create a New function group using transaction code SE80
Step 2: Copy the standard function module of BTE "SAMPLE_INTERFACE_RWBAPI01" to a Z Function module, say
"ZSAMPLE_INTERFACE_RWBAPI01"
Step 3: Add Following Code into the new function module and activate
FUNCTION zsample_interface_rwbapi01.
*"--------------------------------------------------------------------
""Local Interface:
*" TABLES
*"
IT_ACCIT STRUCTURE ACCIT
*"
IT_ACCCR STRUCTURE ACCCR
*"
RETURN STRUCTURE BAPIRET2
*"
EXTENSION STRUCTURE BAPIACEXTC
*"
IT_ACCWT STRUCTURE ACCIT_WT
10
*" CHANGING
11
*"
12
*"--------------------------------------------------------------------
VALUE(DOCUMENT_HEADER) LIKE ACCHD STRUCTURE ACCHD
13
DATA : wa_extension TYPE bapiacextc.
14
CLEAR: wa_extension.
15
LOOP AT extension INTO wa_extension.
16
READ TABLE it_accit WITH KEY posnr = wa_extension-field1(10).
17
IF sy-subrc EQ 0.
18
it_accit-bschl = wa_extension-field1+10(2).
19
MODIFY it_accit INDEX sy-tabix.
20
ENDIF.
21
ENDLOOP.
22
ENDFUNCTION.
Configuration
Step 1: Go To Transaction code FIBF
Step 2: Add Customer Product. Use Menu Option : Settings -> Products -> ...of a
Customer
Step 3: Save the Product.
Step 4: Create a Link between BTE and Product created in Step2. Use the menu option : Settings -> Process Modules
-> ... of a
customer
Step 5: Save the Link.
Business Transaction Events for Filtering Outbound
Master IDOCs
Business Transaction Events for Filtering Outbound Master IDOCs
Summary
This post narrates the use of P/S (Publish & Subscribe) Business Transaction Events for Filtering of Outbound IDOCs of
Master Data.
Author(s): Vinod Kumar T
Company:
NIIT Technologies Limited
Created on:
16.10.2010
Author(s) Bio
Vinod Kumar is an ABAP Consultant working with NIIT Technologies Limited.
Scenario
Standard SAP program RBDMIDOC is used to trigger the Outbound IDOCs based on Change pointer concept. ALE
Distribution Model (BD64) and partner configuration (WE20) is used to determine the receiving partners. IDOCs are
transmitted to all the partners defined in above configuration.
Process Flow
Standard program RBDMIDOC refers the table TBDME to get the function module which is to be executed for creating
IDOCs. For example, the message type COND_A (Pricing conditions) , Standard function module
MASTERIDOC_CREATE_SMD_COND_A is executed to generate the IDOCs. The function module extracts all the records
which are not yet processed using the function module CHANGE_POINTERS_READ. These records will be converted as
per segments in the Basic IDOC type / message type and will be transmitted to all the Partners which are maintained in
WE20 (Partner Profile Configuration) and BD64 (Distribution Model).
Change Requirement
1.
IDOCs to be generated for specific Partners based on Business requirements. In this scenario, IDOCs need to
filters so that the unwanted Partner doesn't receive the IDOC.
2.
IDOCs to be generated based on some dynamic criteria based on the Data records of the IDOC. For example,
IDOCs need to be generated only if the pricing condition value is greater than 100 and Condition type is 'XXXX'.
Use of P&S (Publish & Subscribe) BTE.
Publish & Subscribe Business Transaction Event (P/S BTE) can be used to filter the generation of IDOCs. Customized
function module with complex filtering conditions can be assigned to this BTE which will be triggered during the Outbound
Processing of IDOC.
List of P/S Business Transaction Events attached to Outbound IDOC Processing
01.
CC000110 - ECMMAS : Outbound Processing for ALE Distrib. Unit
Message Type
ECMMAS - Engineering Change Management
Processing Function Module
MASTER_IDOC_CREATE_SMD_ECMMAS
BTE Function Module
SAMPLE_INTERFACE_CC000110
02.
CHR00100 - CHRMAS: Outbound Processing for ALE Distribution
Message Type
CHRMAS - Class system: Characteristics master
Processing Function Module
MASTERIDOC_CREATE_SMD_CHRMAS
BTE Function Module
SAMPLE_INTERFACE_CHR00100
03.
CLF00100 - CLFMAS : Outbound Processing for ALE Distribution
Message Type
CLFMAS - Class system: Classification master
Processing Function Module
MASTERIDOC_CREATE_SMD_CLFMAS
BTE Function Module
SAMPLE_INTERFACE_CLF00100
04.
CLS00100 - CLSMAS : Outbound Orocessing for ALE Distribn unit
Message Type
CLSMAS - Class system: Classes master
Processing Function Module
MASTERIDOC_CREATE_SMD_CLSMAS
BTE Function Module
SAMPLE_INTERFACE_CLS00100
05. CS000105 - BOMMAT: Outbound Processing for ALE Distribn unit
Message Type
BOMMAT - BOMs: Material BOM
Processing Function Module
MDM_IDOC_CREATE_SMD_BOMMAT
BTE Function Module
SAMPLE_INTERFACE_CS000105
06
CV000100 - DOCMAS : Outbound Processing for ALE Distribn unit
Message Type
DOCMAS - Master document
Processing Function Module
MASTERIDOC_CREATE_SMD_DOCMAS
BTE Function Module
SAMPLE_INTERFACE_CV000100
07. DEP00100 - DEPNET : Outbound Processing for ALE Distribn Unit
Message Type
DEPNET - Dependency net
Processing Function Module
MASTERIDOC_CREATE_SMD_DEPNET
BTE Function Module
SAMPLE_INTERFACE_DEP00100
08.
DOL00100 - DOLMAS : Outbound processing for ALE Distribn Unit
Message Type
DOLMAS - Document-object links
Processing Function Module
MASTERIDOC_CREATE_SMD_DOLMAS
BTE Function Module
SAMPLE_INTERFACE_DOL00100
09.
KNO00100 - KNOMAS : Outbound Processing for ALE Distribn Unit
Message Type
KNOMAS - Global object dependencies
Processing Function Module
MASTERIDOC_CREATE_SMD_KNOMAS
BTE Function Module
SAMPLE_INTERFACE_KNO00100
10.
MGV00100 - MATMAS : Outbound processing for ALE Distribn Unit
Message Type
MATMAS - Material master
Processing Function Module
MASTERIDOC_CREATE_SMD_MATMAS
BTE Function Module
SAMPLE_INTERFACE_MGV00100
11.
VFU00100 - VFNMAS : Outbound Processing for ALE Distribn Unit
Message Type
VFNMAS - Variant function
Processing Function Module
MASTERIDOC_CREATE_SMD_VFNMAS
BTE Function Module
SAMPLE_INTERFACE_VFU00100
12.
VKOA0100 - COND_A: Outbound Processing for ALE Distribn Unit
Message Type
COND_A - Conditions: master data for price determination
Processing Function Module
MASTERIDOC_CREATE_SMD_COND_A
BTE Function Module
SAMPLE_INTERFACE_VKOA0100
13.
VTA00100 - VTAMAS : Outbound Processing for ALE Distribution
Message Type
VTAMAS - Structure of variant table
Processing Function Module
MASTERIDOC_CREATE_SMD_VTAMAS
BTE Function Module
SAMPLE_INTERFACE_VTA00100
14.
VTM00100 - VTMMAS : Outbound Processing for ALE Distribution
Message Type
VTMMAS - Contents of variant table
Processing Function Module
MASTERIDOC_CREATE_SMD_VTMMAS
BTE Function Module
SAMPLE_INTERFACE_VTM00100
Configurations Required to Activate BTE
1.
a.
Create a Function group using Transaction code SE80.
b.
Copy the standard BTE Function module (for Eg. SAMPLE_INTERFACE_VKOA0100 for Pricing
conditions) to Z-Funtion module (Eg. ZSAMPLE_INTERFACE_VKOA0100) in the above function group using Transaction
code SE37 and activate it.
c.
Create Customer Product (Transaction code FIBF -> Settings -> Products -> ... of a customer)
d.
Add the appropriate P&S BTE and assign the Z-Function module created in Step-b using menu
option(Transaction code FIBF -> Settings -> P/S Modules -> ... of a customer)
e.
See this WiKi post which explains the steps to configure P&S BTE for Pricing conditions P&S BTE
settings for Pricing Conditions Outbound IDOC Filtering
Sample code Written in Z-FM : ZSAMPLE_INTERFACE_VKOA0100 (For Pricing
Conditions IDOC)
1
FUNCTION zsample_interface_vkoa0100.
*"----------------------------------------------------------------------
*"*"Local Interface:
*" TABLES
*"
IDOC_DATA STRUCTURE EDIDD
*" CHANGING
*"
*" EXCEPTIONS
*"
10
*"----------------------------------------------------------------------
11
* Event rissen by the ALE outbound process for COND_A.
REFERENCE(IDOC_HEADER) TYPE EDIDC
ERROR
12
13
* It allows to modify the idoc's control header the idoc data aswell
14
* as serialization information created by the standard SAP outbound
15
* process.
16
17
18
* Raising the EXCEPTION ERROR will prevent the IDOC from being
* submitted to the ALE layer.
19
20
21
22
23
* BE CAREFUL WITH ANY CHANGES TO IDOC_CONTROL. IT MAY EFFECT YOUR WHOLE
* ALE-SCENARIO
* Filtering of IDOCs based on Receiving Partner can be done using the
* validation in structure IDOC_HEADER.
24
25
26
27
DATA : lv_flag
lv_kbetr
TYPE char01,
TYPE kbetr.
28
CLEAR : lv_flag, lv_kbetr.
29
LOOP AT idoc_data.
30
31
IF idoc_data-segnam EQ 'E1KONP'.
MOVE idoc_data-sdata+64(16) TO lv_kbetr.
32
33
IF lv_kbetr LT 100.
MOVE 'X' TO lv_flag.
34
EXIT.
35
36
37
ENDIF.
ENDIF.
ENDLOOP.
38
39
40
41
IF lv_flag EQ 'X'.
REFRESH : idoc_data.
RAISE error.
ENDIF.
42
43
ENDFUNCTION.
44
Business Transaction Events - Process Interface - Event
00001030 - customer implementation for printing dunning
notice
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.
Business Transaction Events - Process Interface - Event
00001060 - customer implementation for customizing
dunning notice
Business Transaction Events Process Interface (Info-systems Process)
To refer detailed discussion on BTE and a scenario on printing of dunning notice refer my Wiki,
Business Transaction Events - Process Interface - Event 00001030 - customer implementation for printing dunning notice
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'.
Here, this scenario deals with the 'Process Interface' for event '00001060' (OPEN_FI_PERFORM_00001060_P) which as
per SAP documentation says,
"This process makes it possible to overwrite the fields that indicate whether the item is to be dunned. This means that you
can include just the items you require on the dunning notice, and exclude those you do not wish to appear on the dunning
notice. Unlike process 00001061, however, the item remains in the table and is processed according to the indicator
assigned to it".
Consider a business scenario in which a customer may have an 'Incoming payment' method active (say) 'AU' -
'Bankabbuchung' and 'berweisung' respectively.
In such a case dunning is not possible and to print a dunning notice.
But, in business aspects irrespective of the incoming payment method active the dunning notice has to be sent to the
customer as that will impact the business.
So, we have a BTE which will allows printing the dunning notice inspite of an 'Incoming payment' method active without
changing the method or the indicator.
Also, this BTE can block the entire customer to be dunned, although in the customer master shows 'Free for dunning'
indicator (that is space).
To start with we observe the standard process,
Go to transaction 'F150' for dunning and maintain the parameters first.
Make a dunning scheduling run and give the printing instructions.
After the run, observe the 'Dunning log', due the 'incoming payment' method there is no 'scheduling' and 'printing' of
dunning notice.
Now, to make it possible to send a reminder about the over-due items of the customer to be paid we need to send it
irrespective of any incoming payment method, BTE comes for the rescue.
Go to the BTE transaction 'FIBF'.
Execute the transaction and select the desired BTE for the requirement.
First after reading the documentation, analyze the sample function module.
Make a copy of the standard function module under 'customer' namespace.
Write the code as per requirement. Here, just to measure the extent of functionality to be achieved I have enabled or
disabled certain interface parameters available in this function module.
I have passed the value 'Space' to the parameter 'C_XZALB' which is 'Indicator: items payable (not to be dunned)?'
When there is a payment method 'Incoming' especially active then the value of the parameter 'C_XZALB' or 'MHNDXZALB' becomes 'X' and the dunning notice does not get printed.
To observe the overriding of the parameter 'MHND-XZALB' without actually changing the value in the master table,
debug the application.
First, go to transaction 'F150' - Dunning and fill in the necessary parameters,
Then schedule the dunning run.
After scheduling confirm that the run and the print is complete,
Also, confirm the log and the desired functionality has been achieved inspite of an incoming payment method.
I would suggest going for background debugging for understanding the complete process and the functionality
enhancement.
See the desired BTE process is in the list and as there is some active customer/partner product registered the value
'EMPTY' is not 'X'.
At last things must go perfect when you see an entry of our function module in the table (customer table) 'APCUSTAB',
check this out.
Before our customer enhancement code is encountered the status of the original functionality is 'Dunning notice not to be
printed', confirm it this way.
Observe the parameters 'C_XFAEL', 'C_XZALB' and 'C_MANSP' respectively.
Now, when our functionality is triggered, observe the change. The parameter 'C_XZALB' has been changed to (Space).
Observe the notice which gets printed inspite of 'incoming payment' method.
Here to utilize the functionality of BTE 00001060 process interface, we consider another scenario in the case when a
customer has to be blocked temporarily without changing the master data. Then this BTE can make a difference.
Note: I would suggest you to follow the same process for scheduling a dunning run and printing as demonstrated before.
In the customer master the 'Dunning block' is not active or the status is 'Freed for dunning'. Which means the customer
can be dunned and notice can be printed.
In order to block the customer without changing the customer master, creating our own customer implementation will
make this possible.
So, here the same process is followed,
Transaction 'FIBF' - Process Interface - Event 00001060 (Check MHND) - sample function module (with documentation)
Copy the standard sample function module to customer name space and observe the parameters set.
Here the parameter 'C_MANSP' indicates the dunning block. If this indicator is set 'X', then the customer status is set as
'blocked'.
Now, after dunning run is processed view the log to check the status.
As the customer is blocked the dunning notice will not be printed.
Business Transaction Event - VKOA0100 - For Outbound
Pricing IDOC Filtering
Business Transaction Event - VKOA0100 - For Outbound Pricing
IDOC Filtering
Summary
This post narrates the use of Business Transaction Event for filtering of Pricing Conditions Outbound IDOCs.
Author(s): Vinod Kumar T
Company:
NIIT Technologies Limited
Created on:
12.10.2010
Author(s) Bio
Vinod Kumar is an ABAP Consultant working with NIIT Technologies Limited.
Scenario
Pricing conditions are transmitted to different ALE Partners through the Program RBDMIDOC. Standard Message type
COND_A is used to create the IDOCs.
How IDOCs are Created?
Standard program RBDMIDOC refers the table TBDME to get the function module which is to be executed for creating
IDOCs. For message type COND_A, Standard function module MASTERIDOC_CREATE_SMD_COND_A is executed to
generate the IDOCs. Since this function module works on the concept of CHANGE POINTERS all the pricing condition
records which are not yet processed will be picked up using the function module CHANGE_POINTERS_READ. These
records will be converted as per segments in the Basic IDOC type / message type and will be transmitted to all the Partners
which are maintained in WE20 (Partner Profile Configuration) and BD64 (Distribution Model).
Business Requirement
As per the new requirement, Conditions records satisfying certain requirements are only to be transmitted (eg. All the
records with pricing condition value greater than 100 & Receiving Partner is XXXXX). Data filtering using BD64 (Distribution
Model) was not able to handle the such complex filtering of IDOCs.
BTE as a Solution
Business Transaction Event VKOA0100 can be used to filter the generation of IDOCs. Customized function module with
complex filtering conditions can be assigned to this BTE which will be triggered during the Outbound Processing of IDOC.
Configurations Required to Activate BTE
Create a Function group using Transaction code SE80.
Copy the standard function module SAMPLE_INTERFACE_VKOA0100 to ZSAMPLE_INTERFACE_VKOA0100 in
the above function group using Transaction code SE37 and activate it.
Create Customer Product (Transaction code FIBF -> Settings -> Products -> ... of a customer
Create Customer P&S Module (Transaction code FIBF -> Settings -> P/S Modules -> ... of a
Customer
Sample code Written in FM : ZSAMPLE_INTERFACE_VKOA0100
1
FUNCTION zsample_interface_vkoa0100.
*"----------------------------------------------------------------------
*"*"Local Interface:
*" TABLES
*"
*" CHANGING
*"
*" EXCEPTIONS
IDOC_DATA STRUCTURE EDIDD
REFERENCE(IDOC_HEADER) TYPE EDIDC
*"
10
*"----------------------------------------------------------------------
11
* Event rissen by the ALE outbound process for COND_A.
ERROR
12
13
* It allows to modify the idoc's control header the idoc data aswell
14
* as serialization information created by the standard SAP outbound
15
* process.
16
17
18
* Raising the EXCEPTION ERROR will prevent the IDOC from being
* submitted to the ALE layer.
19
20
* BE CAREFUL WITH ANY CHANGES TO IDOC_CONTROL. IT MAY EFFECT YOUR WHOLE
* ALE-SCENARIO
21
22
23
* Filtering of IDOCs based on Receiving Partner can be done using the
* validation in structure IDOC_HEADER
24
25
26
DATA : lv_flag
lv_kbetr
TYPE char01,
TYPE kbetr.
27
CLEAR : lv_flag, lv_kbetr.
28
LOOP AT idoc_data.
29
IF idoc_data-segnam EQ 'E1KONP'.
30
MOVE idoc_data-sdata+64(16) TO lv_kbetr.
31
IF lv_kbetr LT 100.
32
33
34
MOVE 'X' TO lv_flag.
EXIT.
ENDIF.
35
36
37
38
ENDIF.
ENDLOOP.
IF lv_flag EQ 'X'.
REFRESH : idoc_data.
39
40
RAISE error.
ENDIF.
41
42
43
ENDFUNCTION.
