Algorithms Used in C1-RefundReq

The following table lists the algorithms which are attached to the C1-RefundReq business object:

System Event Algorithm Algorithm Type Description
Information C1-REFREQINF C1-REFREQINF This algorithm generates the refund and write off request information string which appears throughout the application. It concatenates the following fields:

  • Refund or Write Off Request Type Description

  • Refund or Write Off Request Status Description

  • Refund or Write Off Request ID
Post-Processing C1-REFWOPOSP C1-REFWOPOSP This algorithm recalculates and updates the total refund amount in the Refund Request zone when you change the refund amount against an entity while editing a refund request.
Validation C1-REFUNDVAL C1-REFUNDVAL This algorithm validates the following for each entity that you have selected in the refund request:

  • The mandatory data, such as refund amount and adjustment type, is specified.

  • The refund amount is not less than zero.

  • The refund amount is not greater than the entity amount.

  • The refund amount is not greater than the eligible refund amount.

  • The partial refund is not done at the payment event or bill level.

The following table lists the algorithms which are used in the lifecycle of the C1-RefundReq business object:

Status System Event Algorithm Algorithm Type Description
Draft Enter C1-REF-DFT C1-REF-DFT This algorithm fetches the account's main customer's name and address and displays in the Refund Request zone. In addition, when you refund the payments from the Payment Event Summary screen, this algorithm does the following:

  • The total eligible refund amount is calculated and accordingly displayed in the Refund Request screen.

  • The default refund adjustment type specified in the refund request type is fetched and displayed against the selected payment event or payments.

  • On selecting a payment event for refund, if all payments in the payment event are matched against the same suspense or excess credit contract, the payment event is added in the Refund Details zone. However, if the payments in the payment event are matched against different suspense or excess credit contracts, the payments of the payment event are added in the Refund Details zone.
Submitted Enter C1-REFUNDSUB C1-REFUNDSUB This algorithm checks the following:

  • Whether the approval is required for the refund request. If the approval is required for a refund request, the status of the refund request is changed to Approval In Progress. However, if the approval is not required for a refund request, the status of the refund request is changed to Creating Adjustment.

  • At least one entity, such as payment event, payment, or credit bill line item (such as credit bill segment or adjustment) is selected in the refund request.

  • Whether the approval profile attached to the refund request type has the credit hierarchy and C1-REFRQ To Do type defined.
Approval In Progress Enter C1-REFUNDAPP C1-REFUNDAPP This algorithm creates the following:

  • A To Do using the To Do type specified in the approval profile which is attached to the refund request type. The To Do is sent to the appropriate users in the approval hierarchy depending on whether hierarchical approval is required or not.

  • A log entry is added when a To Do is created using the To Do type.
Approved Enter C1-REFAPPRVD C1-REFAPPRVD This algorithm is triggered when the approver clicks the Approve button. It checks whether the approval is required from users at the next level in the approval hierarchy. If the approval is required from the next level in the approval hierarchy, the status of the refund request is changed to Approval In Progress and the algorithm attached to the Approval In Progress status is invoked. If further approval is not required, the status of the refund request is changed to Creating Adjustment.
Rejected - - - -
Creating Adjustment Enter C1-REFADJCRI C1-REFADJCRI This algorithm does the following:

  • Creates the refund adjustments for the refund request. These refund adjustments are created in the Frozen status. The adjustment ID is displayed corresponding to the entity in the Refund Details zone.

  • Stamps the bill ID of credit line item on the adjustment and the corresponding financial transaction.

  • If a match event is present for the credit bill line item and for payments which are matched against the excess credit contract, the existing match event is stamped on the refund or write up adjustment and the corresponding financial transaction. However, when a match event is not present for payments which are matched against the suspense contract or if the match event does not exist, a new match event is created and stamped on the refund or write up adjustment and the corresponding financial transaction.

  • If you are doing a partial refund for any entity, the corresponding match event status is set to Open. However, if you are refunding the entire eligible amount, the corresponding match event status is set to Balanced.

  • The details of the refund adjustments are added in the A/P Check Request (CI_​ADJ_​APREQ) table.

  • If a write up adjustment is created, the write up adjustment type specified in the refund request type is displayed corresponding to the entity in the Refund Details zone.
Processed - - - -
Voided Enter C1-REFVOID C1-REFVOID

This algorithm is invoked on click of the Void button for a refund request which is in processed state.

The algorithm cancels all the frozen adjustments created for the refund request.

The algorithm fetches the adjustment cancel reason required for cancelling the adjustments in the status reason characteristics (F1_​BUS_​OBJ_​STATUS_​RSN_​CHAR table). If the reason is not found, it will use the status reason selected by the user