Kontakt

Ansicht
Dokumentation

FI_PAYM_PROPOSAL_WF - BAdI: Connection of Workflow for Payment Proposal Processing

FI_PAYM_PROPOSAL_WF - BAdI: Connection of Workflow for Payment Proposal Processing

Addresses (Business Address Services)   SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up  
This documentation is copyright by SAP AG.
SAP E-Book

This Business Add-In (BAdI) is used in the Payment Transactions (FI-AP-AR-PT, FI-BL-PT-AP) component. You can use this BAdI to influence the structure of the work packages for the maintenance of the proposal run of payment runs in transactions F110 and F111. You can control the assignment of agents to the work packages. When all users involved have confirmed the completion of the maintenance of the proposal run, you can determine which closing operations the system is to perform.

To enhance or replace the standard implementation delivered, implement the following methods:

  • CHECK_WF_ACTIVE
Check whether the maintenance of the proposal run with workflow is activated.
In this method, for each company code you decide whether the system supports processing the payment proposal with a workflow. You can also use the list of payment methods specified in the parameters of the payment run for the decision.
The standard implementation makes the decision using the settings in table T042WF, the content of which you change using transaction F110WFR, for example.
  • GET_WF_PACKAGE_1
Event 1: Determine work package during the proposal run.
If the rules for structuring the work packages allow, you can determine the work package during the proposal run for a payment. The advantage of event 1 is faster processing since the system needs to read the payment data at event 2.
All payments and exceptions for a business partner (payment recipient or payer) must be in one work package per company code. Therefore, you can use event 1 for the decision only if the content of the fields for decision making is the same for all payments.
The standard implementation uses the settings in table T042WFR to structure the work packages (maintenance in transaction F110WFR). The standard implementation makes the decision in event 1 for criteria for master data fields, for example:
  • Account Number

  • Name

  • City

  • Country

  • Language

  • Telecommunications

  • Tax Number

Run date and run identification are also allowed as criteria in event 1. For all other criteria, the standard implementation determines the work packages in event 2.
  • GET_WF_PACKAGE_2
Event 2: Determine work package after the proposal run.
For all payments for which the implementation could not determine a work package during the proposal run, the system calls the determination after the proposal run. In addition to the payment data (REGUH), you can also use the line item paid (REGUP) for the decision making. The system has also determined the total amount of all payments and exceptions of the business partner that you can use as a criterion.
If the workflow for the company code is active (decision as method CHECK_WF_ACTIVE), the implementation must assign each payment to a work package in event 2 at the latest. Otherwise, the proposal run terminates with a corresponding message.
The standard implementation assigns each payment a work package and uses the settings described in event 1 for this (table T042WFR). Work package 9999999999 contains all payments for which none of the rules apply.
The standard implementation stores the information for all of the work packages generated in events 1 and 2 in table REGUH_WFR.
  • GET_WF_PACKAGE_ACTORS
Determine agent of the work packages.
For each work package, you determine the list of agents that are to receive the task for the maintenance of the proposal run of this package. An agent can have the following role:
  • User

  • Work Center

  • Job

  • Organizational Unit

  • Person

  • Position

The system creates the corresponding workflow with workflow template 23200018. The agents can edit and confirm their work packages via the Business Workplace or using the payment programs F110 and F111.
The standard implementation determines the agents of a work package using the settings described in event 1 (table T042WFR). For the work package 9999999999, the standard implementation assigns all agents from the company code, provided you have not defined an entry for this work package in the settings.
  • GET_WF_PACKAGE_DESCRIPTION
Determine description of a work package.
To provide the agent with a better understanding of which content a work package has, you can generate a description of the work package in this method. The system uses this description in the dialog box, for example, to select the work packages during maintenance of the proposal run in the payment programs.
The standard implementation determines the description using the information in table REGUH_WFR.
  • DELETE_WF_PACKAGES
Delete work packages.
If a user or a reorganization program deletes a payment proposal, the system calls this method. You can then delete all data that you saved while determining the work packages.
The standard implementation deletes the related entries from table REGUH_WFR.
  • START_WF_POSTPROCESSING
Start postprocessing after the last release.
Shortly after all involved parties have confirmed completion of maintenance of the proposal run, the workflow system starts the closing operations.
The standard implementation starts the update run for the proposal run. In a custom implementation, you can call the standard implementation and use method SET_JOB_DETAILS to specify different start criteria for the update run. For example, this can be a start time in the next evening or a certain computer for the background job.

For the payment processes, you use either payment program F110 for vendor or customer payments or payment program F111 for payment assignments. You use the maintenance of the proposal run. You want to allow parallel processing of the proposal data for multiple agents and after maintenance of the proposal run automatically trigger other program steps (for example, the update run).

The standard system offers you the full scope of functionality for editing and releasing the proposal, and for automatically scheduling the update run after maintenance of the proposal run.

For this, you can activate the workflow at company code level and configure the work packages (transaction F110WFR).

From a technology perspective, the BAdI calls the methods of sample class CL_IM_PAYMENT_PROPOSAL_WF as the default implementation class (fallback). The sample class calls the default implementation (class CL_FI_PAYMENT_PROPOSAL_WF). If you copy the sample class to your namespace, you can continue to use the standard implementation and make adjustments or enhancements only in the necessary areas. For examples and suggestions, see the methods GET_WF_PACKAGE_2 and START_WF_POSTPROCESSING of the sample class.

If in your custom implementation, you continue to call the default implementation as recommended, you can also make the following adjustments, for example:

  • Deactivate the workflow for F110 payment runs with a certain run identification (method CHECK_WF_ACTIVE). In addition, you can then check in BAdI FI_F110_SCHEDULE_JOB whether a user is authorized to start a proposal with this identification (meaning without a workflow).
  • Alternative calculation of the total amount of the payments and exceptions of a business partner (method GET_WF_PACKAGE_2).
  • Alternative closing operations after the users have confirmed the maintenance of the proposal run of all work packages (method START_WF_POSTPROCESSING).

For more information about how to implement BAdIs in the Enhancement Framework, see SAP Library for the SAP NetWeaver Platform on SAP Help Portal at http://help.sap.com/nw_platform. Select a release and then choose Application Help. In SAP Library, choose SAP NetWeaver Library: Function-Oriented View -> Application Server -> Application Server ABAP -> Application Development on AS ABAP -> ABAP Customer Development -> Enhancement Framework.






SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up   PERFORM Short Reference  
This documentation is copyright by SAP AG.

Length: 10654 Date: 20240607 Time: 091912     sap01-206 ( 159 ms )