- SAP Managed Tags:
Dear SAPers!
With my blog post “Enhancements in EBS – BADI FIEB_CHANGE_BS_DATA” I’ve started a series of posts around enhancements in electronic bank statement processing. This post is a continuation of this series. Please check out my previous post, because this post relies on the logic to split the implementation into two classes, which was described earlier.
This post explores the topic that I briefly mentioned in my previous post i.e., change of posting rules. As I explained earlier, you can use the field FEBEP-VGINT to assign an alternative posting rule for the operation. Let’s return to the example of incoming payment: based on the transactional details the enhancement should assign different posting rules for customer down-payments (i.e., rule with SGL-indicator A) and for customer post-payments. A bank is not able to distinguish between these payment types and provides just one BTC-code in the bank statement e.g., 031. This BTC-code is mapped to the posting rule for customer post-payments. The question is where do you maintain a posting rule for down-payments that should be used in the BADI?
There are four possible answers to this question:
Options 1 & 2 are straightforward, and I’ll not spend time on additional explanations. I’ll also not cover option 3, because everything depends on the tools & guidelines available for developers on a specific project. Some clients have rather complicated tools for management of constants, so you’ll need to check out with your developer / manager. Option 4 is a valid option, but I’d suggest avoiding it, because it is a rather heavy solution for such a simple requirement.
Let’s look at option 5. This option is essentially a mix of a simple workaround and enhancement. In the mapping of external transaction codes (BTCs) to posting rules add a new dummy transaction code e.g., INCDP (for incoming down-payment). Assign a posting rule for customer down-payments to this dummy transaction code.
As I mentioned earlier, BTC code for incoming payments is 031 and as you can see it is assigned to posting rule UA+1 with standard interpretation algorithm. Posting rule UA+2 for customer down-payments does not require any interpretation, since there is no open item in the system.
I've used similar approach based on the dummy transaction codes to solve the problem of missing posting rules in FEB_BSPROC (link).
Now let’s check about the enhancement part. In the private section of the BADI implementing class define a new structure MS_DEFAULT_POSTING_RULES and a method to cache default posting rules:
Source code for the new method is provided below. Essentially, the code is selecting the posting rules for incoming down-payments as well as default posting rules for miscellaneous payments (those with key UNASSIGNED) and storing them into the class attribute MS_DEFAULT_POSTING_RULES. The logic is implemented in such a way, that the selection will happen only once. It would be ideal to implement such code in the class constructor, but we need to know the transaction type associated with the bank statement (FEBKO-VGTYP) and it is not available when class constructor is executed.
Eventually, you’ll end up with a structure (i.e., class attribute) that stores the list of default posting for various cases. You can control yourself how many posting rules and for which cases you need via definition of the type TY_DEFAULT_RULES.
So, what are the main benefits of this approach? In my opinion, the benefits are as follows:
I hope that this post will be useful for you and will allow you to manage your enhancement more flexibly.
Regards,
Bohdan Petrushchak
With my blog post “Enhancements in EBS – BADI FIEB_CHANGE_BS_DATA” I’ve started a series of posts around enhancements in electronic bank statement processing. This post is a continuation of this series. Please check out my previous post, because this post relies on the logic to split the implementation into two classes, which was described earlier.
This post explores the topic that I briefly mentioned in my previous post i.e., change of posting rules. As I explained earlier, you can use the field FEBEP-VGINT to assign an alternative posting rule for the operation. Let’s return to the example of incoming payment: based on the transactional details the enhancement should assign different posting rules for customer down-payments (i.e., rule with SGL-indicator A) and for customer post-payments. A bank is not able to distinguish between these payment types and provides just one BTC-code in the bank statement e.g., 031. This BTC-code is mapped to the posting rule for customer post-payments. The question is where do you maintain a posting rule for down-payments that should be used in the BADI?
There are four possible answers to this question:
- You can define a new posting rule as a local constant directly in the source code.
- You can define a TVARVC-variable and assign a posting rule to it.
- You can use a project specific solution for management of constants.
- You can define a new configuration (Z) table to store the mapping.
- You can use the configuration option proposed in this post.
Options 1 & 2 are straightforward, and I’ll not spend time on additional explanations. I’ll also not cover option 3, because everything depends on the tools & guidelines available for developers on a specific project. Some clients have rather complicated tools for management of constants, so you’ll need to check out with your developer / manager. Option 4 is a valid option, but I’d suggest avoiding it, because it is a rather heavy solution for such a simple requirement.
Let’s look at option 5. This option is essentially a mix of a simple workaround and enhancement. In the mapping of external transaction codes (BTCs) to posting rules add a new dummy transaction code e.g., INCDP (for incoming down-payment). Assign a posting rule for customer down-payments to this dummy transaction code.
As I mentioned earlier, BTC code for incoming payments is 031 and as you can see it is assigned to posting rule UA+1 with standard interpretation algorithm. Posting rule UA+2 for customer down-payments does not require any interpretation, since there is no open item in the system.
I've used similar approach based on the dummy transaction codes to solve the problem of missing posting rules in FEB_BSPROC (link).
Now let’s check about the enhancement part. In the private section of the BADI implementing class define a new structure MS_DEFAULT_POSTING_RULES and a method to cache default posting rules:
" Definition part of the class
class zcl_ua_fieb_change_bs_data definition
public
final
create public .
public section.
types:
tt_febcl type standard table of febcl with default key .
class-methods process_line
importing
!iv_note_to_payee type string
changing
!cs_febko type febko
!cs_febep type febep
!ct_febcl type standard table .
protected section.
private section.
types:
begin of ty_default_rules,
inc_down_payment type febep-vgint,
default_in type febep-vgint,
default_out type febep-vgint,
end of ty_default_rules.
class-data: ms_default_posting_rules type ty_default_rules.
constants:
begin of c_operation_sign,
plus type t028g-vozpm value '+' ##NO_TEXT,
minus type t028g-vozpm value '-' ##NO_TEXT,
end of c_operation_sign.
class-methods cache_default_posting_rules
importing
is_febko type febko.
endclass.Source code for the new method is provided below. Essentially, the code is selecting the posting rules for incoming down-payments as well as default posting rules for miscellaneous payments (those with key UNASSIGNED) and storing them into the class attribute MS_DEFAULT_POSTING_RULES. The logic is implemented in such a way, that the selection will happen only once. It would be ideal to implement such code in the class constructor, but we need to know the transaction type associated with the bank statement (FEBKO-VGTYP) and it is not available when class constructor is executed.
class zcl_ua_fieb_change_bs_data implementation.
* <SIGNATURE>---------------------------------------------------------------------------------------+
* | Static Private Method ZCL_UA_FIEB_CHANGE_BS_DATA=>CACHE_DEFAULT_POSTING_RULES
* +-------------------------------------------------------------------------------------------------+
* | [--->] IS_FEBKO TYPE FEBKO
* +--------------------------------------------------------------------------------------</SIGNATURE>
method cache_default_posting_rules.
constants:
begin of lc_btc_keys,
inc_down_payment type febep-vgext value 'INCDP' ##NO_TEXT,
default_key type febep-vgext value 'UNALLOCATED' ##NO_TEXT,
end of lc_btc_keys.
if ms_default_posting_rules is not initial.
return.
endif.
" Select all assignments of BTC-codes to posting rules
data lt_rules type standard table of t028g with default key.
select *
from t028g
into table lt_rules
where vgtyp = is_febko-vgtyp.
if sy-subrc <> 0.
return.
endif.
data ls_rule like line of lt_rules.
" Get posting rule for incoming down-payments
read table lt_rules
into ls_rule
with key vgext = lc_btc_keys-inc_down_payment vozpm = c_operation_sign-plus.
if sy-subrc = 0 and ls_rule-vgint <> ''.
ms_default_posting_rules-inc_down_payment = ls_rule-vgint.
endif.
clear: ls_rule.
" Get default posting rule for miscellaneous incoming payments
read table lt_rules
into ls_rule
with key vgext = lc_btc_keys-default_key vozpm = c_operation_sign-plus.
if sy-subrc = 0 and ls_rule-vgint <> ''.
ms_default_posting_rules-default_in = ls_rule-vgint.
endif.
clear: ls_rule.
" Get default posting rule for miscellaneous outgoing payments
read table lt_rules
into ls_rule
with key vgext = lc_btc_keys-default_key vozpm = c_operation_sign-minus.
if sy-subrc = 0 and ls_rule-vgint <> ''.
ms_default_posting_rules-default_out = ls_rule-vgint.
endif.
endmethod.
* <SIGNATURE>---------------------------------------------------------------------------------------+
* | Static Public Method ZCL_UA_FIEB_CHANGE_BS_DATA=>PROCESS_LINE
* +-------------------------------------------------------------------------------------------------+
* | [--->] IV_NOTE_TO_PAYEE TYPE STRING
* | [<-->] CS_FEBKO TYPE FEBKO
* | [<-->] CS_FEBEP TYPE FEBEP
* | [<-->] CT_FEBCL TYPE STANDARD TABLE
* +--------------------------------------------------------------------------------------</SIGNATURE>
method process_line.
cache_default_posting_rules( cs_febko ).
" Assign a posting rule for customer down-payment
cs_febep-vgint = ms_default_posting_rules-inc_down_payment.
endmethod.
endclass.Eventually, you’ll end up with a structure (i.e., class attribute) that stores the list of default posting for various cases. You can control yourself how many posting rules and for which cases you need via definition of the type TY_DEFAULT_RULES.
So, what are the main benefits of this approach? In my opinion, the benefits are as follows:
- You use one configuration entity (OT83, table T028G) to store all assignments of posting rules. You will not need to look for some obscure TVARVC-variables or other Z-tables for information about additional posting rule assignments. All configurations in this area will be available in one place.
- You are essentially using the benefits of configurable constants i.e., the key for the constant is defined as local constant in the enhancement (e.g. LC_BTC_KEYS-INC_DOWN_PAYMENT), but actual value is configurable.
I hope that this post will be useful for you and will allow you to manage your enhancement more flexibly.
Regards,
Bohdan Petrushchak
