Dear SAPers !
With this post I continue the series of blog posts on the functionalities around bank statement & payment program. This post describes a variation of the payment process, where the payment program does not generate payment postings, only a payment order. The post describes the end-to-end process as well as the required customizing in the system.
Automatic payment program (APP) is the functionality that automates all aspects of the outgoing and incoming payments that are initiated by your company. I call it a functionality, not a program, because eventually it is not a single program, but a set of programs the are used together. Payment program is a powerful functionality, which can be configured to address the most popular payment scenarios.
The screenshot below provides a high-level overview of the target process. The key process steps are as follows:
For the purposes of this blog, I’ll not describe some common steps e.g., selection parameters of the payment program, execution of the proposal / payment run etc. These steps are described well in plenty of other blog posts on SCN. I’ll focus on the specific steps, which are relevant to the process under consideration.
As can be seen from the screenshot below, payment run was carried out:
Payment run included one vendor invoice:
As can be seen from the log of the payment run, the program did not post any payment document. But you can see that the program generated a payment order 1000000462 for the amount of the vendor invoice:
Vendor invoice is still displayed as an open item in the report FBL1N:
But when you drill down to the document line item, you’ll see a dedicated status saying, “Payment order created”. This status means that the open item is still technically open, but you’ll no longer be able to clear it manually via F-44. It is locked for manual clearing, because the program expects it to be processed automatically via the upload / processing of the bank statement.
If you double click on the line with the status, the program will open the report with this payment order. If necessary, you can use this feature to delete the payment order (e.g., if the payment did not through for some reason).
Standard open item reports do not show the payment order number in the report, but, if necessary, you can implement your own enhancement via BTE 00001650 or BADI FAGL_ITEMS_CH_DATA to address this requirement.
The feature above allows us to review the payment order for specific open item. Reporting capabilities of the payment program (under menu “Environment → Payment Orders”) provide reporting per payment run. Another option from this menu allows you to reverse / delete all payment orders for a specific payment run.
Technically speaking, the program stores the data about the payment orders in two tables with header & item data respectively. These tables are PYORDH & PYORDP. Screenshots below show the layout of both tables. Header table stores the information about the house bank / payment method & payment requisites:
The table PYORDP stores the information about open items included in the payment order. One payment order can include one or more open items of the business partner:
Note: the details in these tables are stored temporarily. As soon as the bank statement is uploaded & appropriate vendor open items are cleared, the content from both tables is deleted.
One final but important remark with regards to the payment program. The payment order number should be transferred to the payment file as a payment order or as a part of the note to payee. The screenshot below shows the example of the payment medium from transaction FDTA with the number of the payment order:
A sample bank statement (MT940-format) was prepared for the purposes of this post. As you can see from the screenshot below, the statement stores the payment order number in line 61. This is an ideal scenario for processing in the system.
During the upload of the bank statement, you should pay attention to the filling of the intervals on the selection screen of the upload program (i.e., FF_5). The interval for the reference document numbers should cover the interval of the payment order numbers and should be preceded by fixed prefix ZR. See example below. For more details refer to OSS note 2428443 “Electronic bank statement: Number range/interval in FF.5 / FF_5”.
Fill other parameters of the selection screen in FF_5 and upload the bank statement. As you can see from the log below, the program identified the reference to the payment order and successfully posted the payment document, which cleared the open items.
Technically speaking, bank statement used the selection of open items for clearing based on payment order number. You can review this information in the table FEBCL for the relevant line item. As you can see from the screenshot below, the table uses the field PYORD + payment order number as criteria for automatic clearing:
Automatic clearing of the open items via payment order number is based on interpretation mechanism 29 of the bank statement (see the screenshot of the line item from the table FEBEP, field INTAG). If payment order is stored in line 61, it will be automatically transferred to the field FEBEP-CHECT. If payment order number is part of the note to payee (i.e., is stored in the table FEBRE), you’ll need to setup a search string with the target field EBCHECT – “Check-/DME Reference-/Assignment Number”. Search string can identify the payment order number and move it to FEBEP-CHECT from note to payee. Thus, it will fulfill the technical prerequisite for the interpretation mechanism.
Let’s now focus on the customizing that is required for this process. Similarly, I’ll not describe all settings in FBZP, OBPMx or DMEE, because there are plenty of good posts describing these transactions. I’ll focus on specific settings for this process.
The first specific configuration required for this process is checkbox “Payment order only” in the settings of the payment method (country level). If the checkbox is activated, you no longer can indicate the document types for payment / clearing document. This checkbox will ensure that execution of the payment run does not generate any accounting postings. The settings can be maintained in transaction FBZP.
The second specific component is the definition of the posting rule for vendor payment with the clearing. The settings can be maintained in transaction OT83.
The last component of the solution is to assign the posting rule to the external (BTC) code and interpretation mechanism 29, which is based on the payment order number.
The screenshot below summarizes the accounting postings that will be executed in bank statement under the assumption that you use two posting areas (as in this example):
The best practice approach is to manage bank subaccounts for outgoing payments with open items management and use the background job for the program SAPF124 (t-code F.13) to clear the open items automatically. SAP facilitates this approach by filling in the same assignment number for open items in both posting areas from bank statement. Technically speaking the value in the “Assignment” is a concatenation of the sequential number of the bank statement (FEBEP-KUKEY), its line item (FEBEP-ESNUM) & currency (FEBEP-KWAER). OSS note 3077336 provides a lot of interesting details about the use of assignment in bank statement for the purposes of automatic clearing.
Note: automatic clearing via SAPF124 required additional settings in transaction OB74.
One last remark: it is not a strict requirement to configure the payment posting in bank statement with two posting areas. You can configure one posting area only (see the screenshot below). But in this case, the posting rule should be created in posting area 2 “Subledger accounting” only. This is caused by the limitations of the bank statement functionality. Please refer for further details to the OSS note 2890489 “FEB_BSPROC postprocessing payment order (PYORD) not working”.
Hope this post was useful and you found something of value. Please comment and let me know if you have any questions or suggestions. Please also check out my profile for other posts on this and related topics.
Regards
Bohdan
P.S. Disclaimer: vendor names / bank accounts used in this example were invented and do not represent actual companies.
With this post I continue the series of blog posts on the functionalities around bank statement & payment program. This post describes a variation of the payment process, where the payment program does not generate payment postings, only a payment order. The post describes the end-to-end process as well as the required customizing in the system.
Introduction
Automatic payment program (APP) is the functionality that automates all aspects of the outgoing and incoming payments that are initiated by your company. I call it a functionality, not a program, because eventually it is not a single program, but a set of programs the are used together. Payment program is a powerful functionality, which can be configured to address the most popular payment scenarios.
Process overview
The screenshot below provides a high-level overview of the target process. The key process steps are as follows:
- Payment program (i.e., F110) selects relevant open items of the vendor and prepares the payment proposal. The proposal is analyzed / processed by the payment specialist.
- Once the proposal is ready, the user executes the payment run. Payment run does not generate any accounting postings, but the user can generate payment file with the list of payment orders.
- Payment file is uploaded to the bank software for processing. On the next day, the bank generates the bank statement. Treasury specialist uploads the statement to the system.
- During upload / interpretation, the system identifies the vendor open items based on the reference to the payment order and posts the payment automatically. This payment also clears the associated vendor open items automatically.
Process steps: payment program
For the purposes of this blog, I’ll not describe some common steps e.g., selection parameters of the payment program, execution of the proposal / payment run etc. These steps are described well in plenty of other blog posts on SCN. I’ll focus on the specific steps, which are relevant to the process under consideration.
As can be seen from the screenshot below, payment run was carried out:
Payment run included one vendor invoice:
As can be seen from the log of the payment run, the program did not post any payment document. But you can see that the program generated a payment order 1000000462 for the amount of the vendor invoice:
Vendor invoice is still displayed as an open item in the report FBL1N:
But when you drill down to the document line item, you’ll see a dedicated status saying, “Payment order created”. This status means that the open item is still technically open, but you’ll no longer be able to clear it manually via F-44. It is locked for manual clearing, because the program expects it to be processed automatically via the upload / processing of the bank statement.
If you double click on the line with the status, the program will open the report with this payment order. If necessary, you can use this feature to delete the payment order (e.g., if the payment did not through for some reason).
Standard open item reports do not show the payment order number in the report, but, if necessary, you can implement your own enhancement via BTE 00001650 or BADI FAGL_ITEMS_CH_DATA to address this requirement.
The feature above allows us to review the payment order for specific open item. Reporting capabilities of the payment program (under menu “Environment → Payment Orders”) provide reporting per payment run. Another option from this menu allows you to reverse / delete all payment orders for a specific payment run.
Technically speaking, the program stores the data about the payment orders in two tables with header & item data respectively. These tables are PYORDH & PYORDP. Screenshots below show the layout of both tables. Header table stores the information about the house bank / payment method & payment requisites:
The table PYORDP stores the information about open items included in the payment order. One payment order can include one or more open items of the business partner:
Note: the details in these tables are stored temporarily. As soon as the bank statement is uploaded & appropriate vendor open items are cleared, the content from both tables is deleted.
One final but important remark with regards to the payment program. The payment order number should be transferred to the payment file as a payment order or as a part of the note to payee. The screenshot below shows the example of the payment medium from transaction FDTA with the number of the payment order:
Process steps: bank statement processing
A sample bank statement (MT940-format) was prepared for the purposes of this post. As you can see from the screenshot below, the statement stores the payment order number in line 61. This is an ideal scenario for processing in the system.
During the upload of the bank statement, you should pay attention to the filling of the intervals on the selection screen of the upload program (i.e., FF_5). The interval for the reference document numbers should cover the interval of the payment order numbers and should be preceded by fixed prefix ZR. See example below. For more details refer to OSS note 2428443 “Electronic bank statement: Number range/interval in FF.5 / FF_5”.
Fill other parameters of the selection screen in FF_5 and upload the bank statement. As you can see from the log below, the program identified the reference to the payment order and successfully posted the payment document, which cleared the open items.
Technically speaking, bank statement used the selection of open items for clearing based on payment order number. You can review this information in the table FEBCL for the relevant line item. As you can see from the screenshot below, the table uses the field PYORD + payment order number as criteria for automatic clearing:
Automatic clearing of the open items via payment order number is based on interpretation mechanism 29 of the bank statement (see the screenshot of the line item from the table FEBEP, field INTAG). If payment order is stored in line 61, it will be automatically transferred to the field FEBEP-CHECT. If payment order number is part of the note to payee (i.e., is stored in the table FEBRE), you’ll need to setup a search string with the target field EBCHECT – “Check-/DME Reference-/Assignment Number”. Search string can identify the payment order number and move it to FEBEP-CHECT from note to payee. Thus, it will fulfill the technical prerequisite for the interpretation mechanism.
Overview of the configuration
Let’s now focus on the customizing that is required for this process. Similarly, I’ll not describe all settings in FBZP, OBPMx or DMEE, because there are plenty of good posts describing these transactions. I’ll focus on specific settings for this process.
The first specific configuration required for this process is checkbox “Payment order only” in the settings of the payment method (country level). If the checkbox is activated, you no longer can indicate the document types for payment / clearing document. This checkbox will ensure that execution of the payment run does not generate any accounting postings. The settings can be maintained in transaction FBZP.
The second specific component is the definition of the posting rule for vendor payment with the clearing. The settings can be maintained in transaction OT83.
The last component of the solution is to assign the posting rule to the external (BTC) code and interpretation mechanism 29, which is based on the payment order number.
Concluding remarks & notes
The screenshot below summarizes the accounting postings that will be executed in bank statement under the assumption that you use two posting areas (as in this example):
The best practice approach is to manage bank subaccounts for outgoing payments with open items management and use the background job for the program SAPF124 (t-code F.13) to clear the open items automatically. SAP facilitates this approach by filling in the same assignment number for open items in both posting areas from bank statement. Technically speaking the value in the “Assignment” is a concatenation of the sequential number of the bank statement (FEBEP-KUKEY), its line item (FEBEP-ESNUM) & currency (FEBEP-KWAER). OSS note 3077336 provides a lot of interesting details about the use of assignment in bank statement for the purposes of automatic clearing.
Note: automatic clearing via SAPF124 required additional settings in transaction OB74.
One last remark: it is not a strict requirement to configure the payment posting in bank statement with two posting areas. You can configure one posting area only (see the screenshot below). But in this case, the posting rule should be created in posting area 2 “Subledger accounting” only. This is caused by the limitations of the bank statement functionality. Please refer for further details to the OSS note 2890489 “FEB_BSPROC postprocessing payment order (PYORD) not working”.
Hope this post was useful and you found something of value. Please comment and let me know if you have any questions or suggestions. Please also check out my profile for other posts on this and related topics.
Regards
Bohdan
P.S. Disclaimer: vendor names / bank accounts used in this example were invented and do not represent actual companies.
- SAP Managed Tags:
11 Comments
