I am sure many of you know that in OB52 SAP has provided option to keep two sets of posting period open at a time. Intention behind this is to help month end / year end closure activities. With the help of this function, first set of period can be closed for all end users and second set of period can be open for specific users to perform month end / year end activities smoothly. Now I am also sure that many of you don’t know how to do this setup. How to create Authorization group? How to assign authorization group to users? If you don’t know answer of these questions, keep reading..

Why two set of posting periods required in SAP FICO?

Let’s consider one scenario to understand importance of this second posting period with authorization group. In many big organizations month end / year end processes run through background job. Now usually posting periods closed for previous month in first five days of new month. Suppose a posting period of Nov closed on 4^th Dec. users keep posting transactions to last posting period (Nov) till the very last moment of 4^th Dec. and then suddenly the posting period is closed for everyone. Now backend job runs at a specific time, so in this case these jobs don’t get time to settle newly posted values on 4^th December and so it starts failing next day onwards.

This is very typical and frequent scenario in many organizations. And this can be easily sorted out with the help of special posting period with authorization group.

How to setup authorization group in OB52

If we check in OB52 for authorization group field there is no F4 (search help) button to select authorization group.

So it is confirmed that it is freely definable field. Or user is able to enter any 4 digit alphanumeric key as authorization group.

So here I have entered AE00 as authorization group for my company code. (We will come back to this part later)

There is one object SAP has provided to control posting periods i.e. F_BKPF_BUP (Accounting Document: Authorization for Posting Periods) in this object we will enter our authorization group i.e. AE00 (same text entered in OB52)

Further this Authorization object F_BKPF_BUP is assigned to security role

And the security role is assigned to users. (We will see this with SAP Screens also in few seconds)

Let’s understand this with below diagram:

From above graph, we have seen how to create authorization group in OB52. Now we will see how to assign authorization object to security roles.

Read eBook: Controlling Profitability Analysis – Comprehensive guide to SAP COPA

How to assign authorization object to roles?

Here we have to ask security team to create a role with list of MEC/YEC transaction codes. Or whatever transaction codes user will be performing.

We will ask Basis team to assign authorization object F_BKPF_BUP to newly created security role with authorization object AE00.

In PFCG transaction Basis team will assign this object F_BKPF_BUP

In above screen we can notice authorization group is entered in authorization object and it is assigned to security role ZABC_POPS.

We will need basis help to perform this activity, but it is also important for functional consultant to know the end to end process.

We can have different authorization group for different users, for different tcodes etc. it will just increase the number of security roles.

Also Read: Note to payee functionality in SAP DME

How to find which users have authorization to post in special posting period? Or

How to check OB52 authorization group assigned to which users?

Well this is actually tricky and most asked question, because creating authorization group and assign it to roles and further to users it straight forward, but we will see how to reverse engineer the process.

Below are the steps to find out users which have authorization group:

We have authorization group – AE00 & we know authorization object is F_BKPF_BUP

First thing we will find out the roles that have authorization object F_BKPF_BUP

Transaction code SUIM

Select roles by authorization object

Enter authorization object and value in our case we want to search AE00

We will be prompted with list of roles that have above authorization object:

Now we have to see what are the users assigned to these roles, they should be able to use second set of posting periods.

To do so go to SUIM transaction code and search users by role

Execute it

Enter all roles and execute it

And here we go with the list of users who have authorization to post accounting documents in second set of posting periods.

Conclusion

These are so useful technique that can be used across modules in SAP. Hope you enjoyed the post. you can save the link of this post or bookmark it for future reference. Also sign up to below newsletter to get weekly blogpost update.

What we learn in this blogpost:

• Two set of posting periods in OB52
• Authorization group setup in OB52
• Assignment of authorization object to roles
• Check OB52 authorization group assigned to which users

Get update of new blog posts

Name

Country Your country Afghanistan Aland Islands Albania Algeria American Samoa Andorra Angola Anguilla Antarctica Antigua and Barbuda Argentina Armenia Aruba Australia Austria Azerbaijan Bahamas Bahrain Bangladesh Barbados Belarus Belgium Belize Benin Bermuda Bhutan Bolivia Bonaire, Saint Eustatius and Saba Bosnia and Herzegovina Botswana Bouvet Island Brazil British Indian Ocean Territory British Virgin Islands Brunei Bulgaria Burkina Faso Burundi Cambodia Cameroon Canada Cape Verde Cayman Islands Central African Republic Chad Chile China Christmas Island Cocos Islands Colombia Comoros Cook Islands Costa Rica Croatia Cuba Curacao Cyprus Czech Republic Democratic Republic of the Congo Denmark Djibouti Dominica Dominican Republic East Timor Ecuador Egypt El Salvador Equatorial Guinea Eritrea Estonia Ethiopia Falkland Islands Faroe Islands Fiji Finland France French Guiana French Polynesia French Southern Territories Gabon Gambia Georgia Germany Ghana Gibraltar Greece Greenland Grenada Guadeloupe Guam Guatemala Guernsey Guinea Guinea-Bissau Guyana Haiti Heard Island and McDonald Islands Honduras Hong Kong Hungary Iceland India Indonesia Iran Iraq Ireland Isle of Man Israel Italy Ivory Coast Jamaica Japan Jersey Jordan Kazakhstan Kenya Kiribati Kosovo Kuwait Kyrgyzstan Laos Latvia Lebanon Lesotho Liberia Libya Liechtenstein Lithuania Luxembourg Macao Macedonia Madagascar Malawi Malaysia Maldives Mali Malta Marshall Islands Martinique Mauritania Mauritius Mayotte Mexico Micronesia Moldova Monaco Mongolia Montenegro Montserrat Morocco Mozambique Myanmar Namibia Nauru Nepal Netherlands New Caledonia New Zealand Nicaragua Niger Nigeria Niue Norfolk Island North Korea Northern Mariana Islands Norway Oman Pakistan Palau Palestinian Territory Panama Papua New Guinea Paraguay Peru Philippines Pitcairn Poland Portugal Puerto Rico Qatar Republic of the Congo Reunion Romania Russia Rwanda Saint Barthelemy Saint Helena Saint Kitts and Nevis Saint Lucia Saint Martin Saint Pierre and Miquelon Saint Vincent and the Grenadines Samoa San Marino Sao Tome and Principe Saudi Arabia Senegal Serbia Seychelles Sierra Leone Singapore Sint Maarten Slovakia Slovenia Solomon Islands Somalia South Africa South Georgia and the South Sandwich Islands South Korea South Sudan Spain Sri Lanka Sudan Suriname Svalbard and Jan Mayen Swaziland Sweden Switzerland Syria Taiwan Tajikistan Tanzania Thailand Togo Tokelau Tonga Trinidad and Tobago Tunisia Turkey Turkmenistan Turks and Caicos Islands Tuvalu U.S. Virgin Islands Uganda Ukraine United Arab Emirates United Kingdom United States United States Minor Outlying Islands Uruguay Uzbekistan Vanuatu Vatican Venezuela Vietnam Wallis and Futuna Western Sahara Yemen Zambia Zimbabwe

Email address:

Leave this field empty if you're human:

If you enjoy the blogpost, then you can stay connected with us on below platforms:

YouTube

LinkedIn FICO Page

LinkedIn ABAP Page

LinkedIn Logistics Page

Instagram

Derivation rule is widely used function in SAP COPA. In this blogpost we will explore all the aspects of derivation rule. Below is the taste of blogpost:

• Introduction & use of derivation rule
• Types of derivation rules
• Step by step configuration of derivation rule
• Conclusion

Introduction & use of derivation rule

In COPA documents we know that system collects characteristics and value fields. Derivation rule helps to determine/derive characteristics by having different conditions and rules. It also helps to override what has been derived by the system, you can create a derivation step to determine the characteristic values during posting of the CO-PA documents.

Disclaimer: This blogpost is a chapter of eBook Controlling Profitability Analysis. In order to consume this blogpost more efficiently, you should have fair understanding of COPA. If you are new to SAP COPA or want to deep dive into this sub-module, then you can consider reading this eBook.

Below infographic helps to understand, how derivation helps to determine/manipulate determination of characteristics in COPA document.

Note: Derivations are used only for characteristics. You can’t modify value fields using derivations.

The CO-PA derivations are defined by five different types of derivation steps:

• Derivation rule – This rule is based on an “if-then” where you define a condition and a derivation to use if the condition is met.

In above image, we can notice product group and strategic business unit is maintained in combination. So it will be like, if product group is ‘100’ then derive strategic business unit ‘electronic’

• Table lookup – System will read a specified table that contains a key that must exist as a characteristic, and then it will derive the field content from this table to the characteristic if the characteristic has the same definition as the table field. It can be used, for example, to derive a value from the material master table that is not present in the posting document. (it will be more clear when we will see config in upcoming section)

• Move – This step will move a characteristic value or a constant to a target field.

• Clear – This step will delete the characteristic value.

• Enhancement – If you want to create a custom program to define the characteristic derivation, use COPA0001.

In below sections we will see the configuration for each characteristics derivation type.

Also read: Functioning of CO-PA in make to order scenario

Step by step configuration of derivation rule

Access the activity using the following navigation options:

SAP Easy Access	Controlling -> Profitability analysis -> Master data -> Define characteristics derivation
Transaction code	KEDR

Click on the create button

Select the derivation rule and hit enter

You will be prompted with the above screen

In this screen, you’ll enter the step description and then build the derivation rule. In the Source Fields area, you select the “If” condition for the derivation, and in the Target Fields area, you select the “Then” field.

After defining the “If and Then” for the derivation rule, click on Maintain Rule Values button

 to update the values for the Source Fields and Target Fields.

Here you can see the rule, as per the rule, whenever the characteristic customer containing value 105 then the sales district characteristics will be updated as NORTH

Read eBook: Manual and electronic bank reconciliation in SAP

Returning to the first customizing screen, two more tabs are left to discuss: Condition and Attributes.

In the condition tab, you can further restrict the derivation rule by defining user filters for the derivation selection. The last tab, Attributes, shows additional options for the derivation rule.

With this condition, now the above derivation rule only be valid for IN country key

In the Attributes tab, you can define whether the system will issue an error when the derivation doesn’t find a value to derive, define if the validation will have a starting date, and restrict the validation by removing the from-to option.

Common error in practice

If you indicate that an error will be issued when no value is found for the derivation, it will block the creation of the CO-PA document, and consequently the FI document. Make sure this is the desired outcome before choosing this option.

Table Lookup

Click on the create button

Select the table lookup and hit enter

Enter the table name, from which table you want the value in COPA field.

Source Fields

In the below image we can see that following information has to be maintained:

• Origin (Table Name) and Origin Field (Field Name) from standard table
• Origin (CO-PA) and Origin Field (Field Name)

This information works as the basic condition, in the below example we can see the KNA1-KUNNR as source in standard tables and COPA-KNDNR in CO-PA Tables. This means the value in COPA-ARTNR is to be passed on to table KNA1 under field KUNNR to identify the information under target field.

Target Fields

In the below image we can see that following information has to be maintained:

• Origin (Table Name) and Origin Field (Field Name) from standard table
• Origin (CO-PA) and Origin Field (Field Name)

This information under KNA1-KTOKD i.e. Customer account group is identified in the table for KTOKD value available from source field and is passed on to KDGRP field under CO-PA.

This rule will get the customer number from COPA document and search it in KNA1 table, it will find out the customer account group and enter in COPA Field KDGRP.

The functioning of other two tabs condition and attributes is same here also; in condition tab we can assign more condition to apply this rule, e.g. making this rule valid only for specific sales org.

1. Move

Hit enter

Here we are moving the product number to material number field

And as required condition tab is also available as this kind of rule cannot be applicable for everyone you can make it specific to any smallest object. E.g. you can validate this rule to one customer also.

• Clear

Select clear

As the name suggest, it will remove the values from field region in COPA.

These are all use cases and config of derivation rule in COPA.

Conclusion

Derivation rule is very important function of SAP COPA and it is used very often. At start the maintenance of rule may seem complicated, but once you configure it and test the result it becomes very easy and useful tool. You will find this structure of derivation rule configuration in multiple submodules like treasury & logistics.

Watch same blogpost in video format::

Hope you enjoyed reading the post. You can subscribe to our newsletter to get update of new blogpost.

Get update of new blog posts

Name

Country Your country Afghanistan Aland Islands Albania Algeria American Samoa Andorra Angola Anguilla Antarctica Antigua and Barbuda Argentina Armenia Aruba Australia Austria Azerbaijan Bahamas Bahrain Bangladesh Barbados Belarus Belgium Belize Benin Bermuda Bhutan Bolivia Bonaire, Saint Eustatius and Saba Bosnia and Herzegovina Botswana Bouvet Island Brazil British Indian Ocean Territory British Virgin Islands Brunei Bulgaria Burkina Faso Burundi Cambodia Cameroon Canada Cape Verde Cayman Islands Central African Republic Chad Chile China Christmas Island Cocos Islands Colombia Comoros Cook Islands Costa Rica Croatia Cuba Curacao Cyprus Czech Republic Democratic Republic of the Congo Denmark Djibouti Dominica Dominican Republic East Timor Ecuador Egypt El Salvador Equatorial Guinea Eritrea Estonia Ethiopia Falkland Islands Faroe Islands Fiji Finland France French Guiana French Polynesia French Southern Territories Gabon Gambia Georgia Germany Ghana Gibraltar Greece Greenland Grenada Guadeloupe Guam Guatemala Guernsey Guinea Guinea-Bissau Guyana Haiti Heard Island and McDonald Islands Honduras Hong Kong Hungary Iceland India Indonesia Iran Iraq Ireland Isle of Man Israel Italy Ivory Coast Jamaica Japan Jersey Jordan Kazakhstan Kenya Kiribati Kosovo Kuwait Kyrgyzstan Laos Latvia Lebanon Lesotho Liberia Libya Liechtenstein Lithuania Luxembourg Macao Macedonia Madagascar Malawi Malaysia Maldives Mali Malta Marshall Islands Martinique Mauritania Mauritius Mayotte Mexico Micronesia Moldova Monaco Mongolia Montenegro Montserrat Morocco Mozambique Myanmar Namibia Nauru Nepal Netherlands New Caledonia New Zealand Nicaragua Niger Nigeria Niue Norfolk Island North Korea Northern Mariana Islands Norway Oman Pakistan Palau Palestinian Territory Panama Papua New Guinea Paraguay Peru Philippines Pitcairn Poland Portugal Puerto Rico Qatar Republic of the Congo Reunion Romania Russia Rwanda Saint Barthelemy Saint Helena Saint Kitts and Nevis Saint Lucia Saint Martin Saint Pierre and Miquelon Saint Vincent and the Grenadines Samoa San Marino Sao Tome and Principe Saudi Arabia Senegal Serbia Seychelles Sierra Leone Singapore Sint Maarten Slovakia Slovenia Solomon Islands Somalia South Africa South Georgia and the South Sandwich Islands South Korea South Sudan Spain Sri Lanka Sudan Suriname Svalbard and Jan Mayen Swaziland Sweden Switzerland Syria Taiwan Tajikistan Tanzania Thailand Togo Tokelau Tonga Trinidad and Tobago Tunisia Turkey Turkmenistan Turks and Caicos Islands Tuvalu U.S. Virgin Islands Uganda Ukraine United Arab Emirates United Kingdom United States United States Minor Outlying Islands Uruguay Uzbekistan Vanuatu Vatican Venezuela Vietnam Wallis and Futuna Western Sahara Yemen Zambia Zimbabwe

Email address:

Leave this field empty if you're human:

If you enjoy the blogpost then you can stay connected with us on below platforms:

YouTube

LinkedIn FICO Page

LinkedIn ABAP Page

LinkedIn Logistics Page

Instagram

First let’s discuss transaction type in ECC.

What is the use of transaction types in Asset Accounting?

On high level, we can say that transaction types in Asset Accounting are used to differentiate business transactions like acquisitions, retirements etc. if we see the configuration screen of transaction type, one can notice that it controls Debit/Credit posting of asset, document type, asset history sheet group etc.

Transaction type configuration Tcodes

• AO76
• AO75
• AO74
• AO73

Apart from this, there is one more important function of transaction type in ECC, i.e. to restrict postings to specific depreciation area.

How to restrict transaction type to depreciation area?

To use this feature companies, have to configure thousands of transaction types.

Transaction code OAYA to restrict transaction type to specific depreciation area:

Let’s spend few seconds to understand why it is important to restrict some of the postings to specific depreciation area.

You know that, we assign leading and non-leading ledgers to depreciation areas. And accordingly depreciation areas post to that leader. Further ledger represents the valuation area e.g. Local Valuation, US GAAP valuation, Group Valuation. In many instances, user has to post specific entries in specific valuation area. In those cases, depreciation area leads the way by using correct transaction type.

In ECC Asset Accounting there is not dedicated transactions that allows to post documents ledger wise. So the transaction key plays the vital role in posting documents to appropriate ledgers.

Transaction type determines depreciation area to be posted and depreciation area determines ledger to be posted.

Also Read: Note to Payee Functionality in SAP DME

This is cool to know the structure, but multiple countries have multiple chart of accounts, which further have many depreciation areas and this leads to creation of many transaction types depending of the geographical size of organization.

This problem has been solved in S4HANA.

Asset Accounting Transaction Types in S4HANA

In new Asset Accounting, it is not possible and also not necessary to restrict transaction types to depreciation areas. This is not necessary since, in end user transaction codes itself SAP has provided option to restrict the posting to depreciation area or accounting principle level. This means you have option to select the depreciation areas to be posted while posting document.

This change has significantly reduced the number of transaction types that need to be defined in the system along with the time consultant has to spend configuring these transaction types.

Let’s see some end transaction codes in Asset Accounting:

Transaction code ABAON

You can notice in above screenshot the highlighted area shows the option of manually entering Accounting principle (Ledger) and Depreciation area.

So no need to stay dependent on transaction type. Accounting principle itself determines ledger to be posted.

Read eBook: Manual and electronic bank reconciliation in SAP

Conclusion

In S4HANA transaction type is still relevant for its configuration control of AO7* setup. But the dependency to post ledger specific documents is being reduced. This become possible because S4HANA has option to have multiple leading depreciation area at a time and all depreciation area can post real-time.

If you want to know more about changes in S4 compared to ECC, you can give try to this eBook.

Also enjoy this free eBook – End user manual for New Asset Accounting.

This brings us to end of the blogpost. Hope you enjoyed reading it. You can subscribe below to get email of new blogpost. Also you can connect with us on below platform.

If you enjoy the blogpost, then you can Subscribe to our newsletter and receive email notification for new blogpost, also stay connected with us on below platforms:

Get update of new blog posts

Name

Country Your country Afghanistan Aland Islands Albania Algeria American Samoa Andorra Angola Anguilla Antarctica Antigua and Barbuda Argentina Armenia Aruba Australia Austria Azerbaijan Bahamas Bahrain Bangladesh Barbados Belarus Belgium Belize Benin Bermuda Bhutan Bolivia Bonaire, Saint Eustatius and Saba Bosnia and Herzegovina Botswana Bouvet Island Brazil British Indian Ocean Territory British Virgin Islands Brunei Bulgaria Burkina Faso Burundi Cambodia Cameroon Canada Cape Verde Cayman Islands Central African Republic Chad Chile China Christmas Island Cocos Islands Colombia Comoros Cook Islands Costa Rica Croatia Cuba Curacao Cyprus Czech Republic Democratic Republic of the Congo Denmark Djibouti Dominica Dominican Republic East Timor Ecuador Egypt El Salvador Equatorial Guinea Eritrea Estonia Ethiopia Falkland Islands Faroe Islands Fiji Finland France French Guiana French Polynesia French Southern Territories Gabon Gambia Georgia Germany Ghana Gibraltar Greece Greenland Grenada Guadeloupe Guam Guatemala Guernsey Guinea Guinea-Bissau Guyana Haiti Heard Island and McDonald Islands Honduras Hong Kong Hungary Iceland India Indonesia Iran Iraq Ireland Isle of Man Israel Italy Ivory Coast Jamaica Japan Jersey Jordan Kazakhstan Kenya Kiribati Kosovo Kuwait Kyrgyzstan Laos Latvia Lebanon Lesotho Liberia Libya Liechtenstein Lithuania Luxembourg Macao Macedonia Madagascar Malawi Malaysia Maldives Mali Malta Marshall Islands Martinique Mauritania Mauritius Mayotte Mexico Micronesia Moldova Monaco Mongolia Montenegro Montserrat Morocco Mozambique Myanmar Namibia Nauru Nepal Netherlands New Caledonia New Zealand Nicaragua Niger Nigeria Niue Norfolk Island North Korea Northern Mariana Islands Norway Oman Pakistan Palau Palestinian Territory Panama Papua New Guinea Paraguay Peru Philippines Pitcairn Poland Portugal Puerto Rico Qatar Republic of the Congo Reunion Romania Russia Rwanda Saint Barthelemy Saint Helena Saint Kitts and Nevis Saint Lucia Saint Martin Saint Pierre and Miquelon Saint Vincent and the Grenadines Samoa San Marino Sao Tome and Principe Saudi Arabia Senegal Serbia Seychelles Sierra Leone Singapore Sint Maarten Slovakia Slovenia Solomon Islands Somalia South Africa South Georgia and the South Sandwich Islands South Korea South Sudan Spain Sri Lanka Sudan Suriname Svalbard and Jan Mayen Swaziland Sweden Switzerland Syria Taiwan Tajikistan Tanzania Thailand Togo Tokelau Tonga Trinidad and Tobago Tunisia Turkey Turkmenistan Turks and Caicos Islands Tuvalu U.S. Virgin Islands Uganda Ukraine United Arab Emirates United Kingdom United States United States Minor Outlying Islands Uruguay Uzbekistan Vanuatu Vatican Venezuela Vietnam Wallis and Futuna Western Sahara Yemen Zambia Zimbabwe

Email address:

Leave this field empty if you're human:

YouTube

LinkedIn FICO Page

LinkedIn ABAP Page

LinkedIn Logistics Page

Instagram

Note to Payee is a functionality available in SAP DME to meet legal / bank requirements of additional details along with payment file.

Also, many times, note to payee information is required by bank/supplier, along with DME XML/FLAT file.

Basically, note to payee is information of paid line items for each vendor/business partner. Note to payee can be any information about payment as per the requirement of bank.

Below are few e.g.

• Legally required information of each payment
• Official document number, which is being paid
• Common reference number between business partner

So note to payee is just additional information you have to print in output file. Just like we print other payment related details. Hence it is possible to do same kind of mapping in DMEE tcode itself and print these details. But SAP has provided separate function of Note to Payee to have greater flexibility.

Note: As a prerequisite to have fair understanding of this blog post, one should be familiar with DME functionality and DME tree structure. If you are new with DME then you can refer this eBook to learn DME.

Configuration steps for Note to Payee functionality in SAP:

Below transaction codes need to configure Note to payee in SAP:

• Payment medium format (OBPM1)
• OBPM2
• FBZP
• DMEE

1. Payment medium format (OBPM1)

Select the concern payment format and go to tab ‘Text fields for reference information’

Here enter the information like type, field length, no of fields.

Field length will depend on requirement, where as No. of fields will depend on payment file structure. Let’s say if you have configured DME tree like separate line for each invoice then No. of fields 1 is sufficient.

But if you have configured DME tree for separate line for each vendor (multiple invoices) then No of fields should maximum like 99.

1. Note to Payee (OBPM2)

From the same screen you can either click on Note to Payee button or go to transaction OBPM2

Create note to payee nodeCreate Note to Payee node

Then select option – Note to payee layout using function module and enter the function module name

Before this step as prerequisite this function module should be available/created. When you will ask ABAPer to develop such function module below are the things you should ask for apart from field and data logic:

1. This function module should be called at the time of payment run
2. Whenever Create payment medium checkbox is ticked
3. Data of Note to Payee should be stored in table DFPAYHT

DFPAYHT table should store values as per the structure of Note to payee

Table DFPAYHT

Note: Reference FM for creating ZFM is – FM FI_PAYMEDIUM_SAMPLE_DETAILS

Well, if you want to go for customizing option, then it includes below steps:

Go to ‘Default Note to Payee’ section in OBPM2 after ticking ‘Note to payee using customizing’ option

Here in this tab we have option to play with SAPScript data. As you can see in notification type we can select the behaviour of output for Note to payee text field values. Values can be taken from three structures FPAYP, FPAYHP & FPAYHX. If you are confused about variables or other signs then just click F4 in Note to Payee text field and just select required fields.

You can also check the preview by selecting preview button for your payment medium format

These fields will be updated in table DFPAYHT.

Also Read: Functioning of CO-PA in make to order scenario

• Maintain payment program FBZP

Select payment method in country

Select Country and payment method and go to tab Note to payee origin

Here in note to payee field enter the note to payee name which we created in OBPM2 transaction. This will help trigger FM and correct note to payee.

After this go to DMEE tree

Here we have to modify DMEE Tree and link note to payee in DME.

Create a node for Note to Payee where note to payee details should appear. This node is based on exit function. We need new function module for this node. Remember the function module we created and assigned in OBPM2 settings, that FM updates table DFPAYHT right. Here we need FM that can pull the information updated in DFPAYHT.

Checkout eBook: Manual and electronic bank reconciliation in SAP

a

If you remember previous screenshot of DFPAYHT table, there all the fields of note to payee is stored in separate line. So this FM should concatenate these fields into one single line.

Note: Reference FM to create ZFM is – DMEE_EXIT_TEMPLATE_ABA

Alternate to this option, if you don’t want to use exit function module, is to call structure DMEE_PAYD – TEXT

You can also visit this similar blogpost on Note to Payee functionality.

Below are some important points to note in Note to payee functionality:

• Most of the times to match the requirement, standard customizing is not enough so in that case custom FM is much better and useful way to configure Note to Payee
• Note to Payee is like free form text, it changes from bank to bank, organization to organization. In some cases, it is mandatory to print note to payee info in DME file. In some cases, it is not even required

This is simpler than how it looks; you just need to try this once. If you want to know more about DME then consider reading this eBook.

If you enjoy the blogpost, then you can stay connected with us on below platforms:

YouTube

LinkedIn FICO Page

LinkedIn ABAP Page

LinkedIn Logistics Page

Instagram

Also subscribe below to receive update of new blogpost

Get update of new blog posts

Name

Country Your country Afghanistan Aland Islands Albania Algeria American Samoa Andorra Angola Anguilla Antarctica Antigua and Barbuda Argentina Armenia Aruba Australia Austria Azerbaijan Bahamas Bahrain Bangladesh Barbados Belarus Belgium Belize Benin Bermuda Bhutan Bolivia Bonaire, Saint Eustatius and Saba Bosnia and Herzegovina Botswana Bouvet Island Brazil British Indian Ocean Territory British Virgin Islands Brunei Bulgaria Burkina Faso Burundi Cambodia Cameroon Canada Cape Verde Cayman Islands Central African Republic Chad Chile China Christmas Island Cocos Islands Colombia Comoros Cook Islands Costa Rica Croatia Cuba Curacao Cyprus Czech Republic Democratic Republic of the Congo Denmark Djibouti Dominica Dominican Republic East Timor Ecuador Egypt El Salvador Equatorial Guinea Eritrea Estonia Ethiopia Falkland Islands Faroe Islands Fiji Finland France French Guiana French Polynesia French Southern Territories Gabon Gambia Georgia Germany Ghana Gibraltar Greece Greenland Grenada Guadeloupe Guam Guatemala Guernsey Guinea Guinea-Bissau Guyana Haiti Heard Island and McDonald Islands Honduras Hong Kong Hungary Iceland India Indonesia Iran Iraq Ireland Isle of Man Israel Italy Ivory Coast Jamaica Japan Jersey Jordan Kazakhstan Kenya Kiribati Kosovo Kuwait Kyrgyzstan Laos Latvia Lebanon Lesotho Liberia Libya Liechtenstein Lithuania Luxembourg Macao Macedonia Madagascar Malawi Malaysia Maldives Mali Malta Marshall Islands Martinique Mauritania Mauritius Mayotte Mexico Micronesia Moldova Monaco Mongolia Montenegro Montserrat Morocco Mozambique Myanmar Namibia Nauru Nepal Netherlands New Caledonia New Zealand Nicaragua Niger Nigeria Niue Norfolk Island North Korea Northern Mariana Islands Norway Oman Pakistan Palau Palestinian Territory Panama Papua New Guinea Paraguay Peru Philippines Pitcairn Poland Portugal Puerto Rico Qatar Republic of the Congo Reunion Romania Russia Rwanda Saint Barthelemy Saint Helena Saint Kitts and Nevis Saint Lucia Saint Martin Saint Pierre and Miquelon Saint Vincent and the Grenadines Samoa San Marino Sao Tome and Principe Saudi Arabia Senegal Serbia Seychelles Sierra Leone Singapore Sint Maarten Slovakia Slovenia Solomon Islands Somalia South Africa South Georgia and the South Sandwich Islands South Korea South Sudan Spain Sri Lanka Sudan Suriname Svalbard and Jan Mayen Swaziland Sweden Switzerland Syria Taiwan Tajikistan Tanzania Thailand Togo Tokelau Tonga Trinidad and Tobago Tunisia Turkey Turkmenistan Turks and Caicos Islands Tuvalu U.S. Virgin Islands Uganda Ukraine United Arab Emirates United Kingdom United States United States Minor Outlying Islands Uruguay Uzbekistan Vanuatu Vatican Venezuela Vietnam Wallis and Futuna Western Sahara Yemen Zambia Zimbabwe

Email address:

Leave this field empty if you're human: