– Array Element 0: Stores the reason code used to determine the G/L ID of the payment being moved to the payment suspense account.
– Array Element 1: Stores the action owner code for suspended or failed payments.
– Array Element 2: Stores the original reason code for failed payments that BRM suspended. This ensures that the reason initially associated with the financial failure is not lost if BRM places the payment in suspense. Element 2 is used only for Payment Suspense Manager; if payment suspense is not enabled, only element 0 will be present.
When the failed payment leaves suspense and PCM_OP_BILL_RCV_PAYMENT creates new payment objects to record the corrected payment, Elements 0 and 1 are no longer needed. The object does not contain the elements 0and 1 recorded for suspense, and Element 2 becomes the new Element 0.
■ When processing multiple resource voucher top-ups that include non-currency
resources, PCM_OP_BILL_RCV_PAYMENT retrieves the non-currency balance impacts from the PIN_FLD_TOPUP_RESOURCE_INFO substruct in the PCM_ OP_PYMT_COLLECT input flist and passes them to the PCM_OP_ACT_USAGE opcode so that they are recorded in the corresponding
/event/billing/payment/voucher object. See "How BRM Performs Top-Ups". PCM_OP_BILL_RCV_PAYMENT uses the PIN_FLD_SESSION_OBJ field in the input flist to reference the type of session in which the event occurred: either
/event/billing/batch/refund or /event/billing/batch/payment, depending on the batch.
How BRM Reverses Payments
Payments are directly reversed from BRM by using Payment Tool. To process a
payment reversal batch, the PCM_OP_BILL_REVERSE opcode performs the following operations:
1. Opens a transaction and checks the appropriate /config/business_params objects to find out if Payment Suspense Manager is enabled.
2. Validates that the PIN_FLD_FLAGS field is not present in the input flist or, if the flag is present, that it is not set to PIN_REVERSE_FLAG_REVERSE_AS_
UNALLOCATED (1). If the flag is set, the operation fails because payments that were removed already from BRM as unallocatable cannot also be reversed.
3. Checks the PIN_FLD_STATUS field of each reversal associated with the payment being reversed.
4. Calls the PCM_OP_PYMT_RECYCLED_PAYMENTS_SEARCH opcode, which
performs the following operations:
■ Validates that the payment does not have a SUB_TRANS_ID value, and is
therefore the original payment. If the payment has a SUB_TRANS_ID value, the operation will fail.
Note: PCM_OP_BILL_REVERSE is a wrapper for the PCM_OP_ BILL_REVERSE_PAYMENT opcode, and it is the recommended opcode to use. Custom client applications should not directly call PCM_OP_BILL_REVERSE_PAYMENT.
How BRM Reverses Payments
■ Finds all distributed payment events that have the same SUB_TRANS_ID
value as this payment’s TRANS_ID value, and have not been reversed already due to the recycling process.
■ Assigns a reversal TRANS_ID value to each payment returned by the search
and populates the reversal flist with each TRANS_ID value.
5. Checks the PIN_FLD_STATUS field of each /event/billing/reversal object
associated with the payment being reversed to ensure that no part of the payment has been removed from suspense as unallocatable.
6. Calls PCM_OP_BILL_REVERSE_PAYMENT to reverse the list of payments.
■ If the payment was originally made to a customer account, the list includes
any recycled payment generated if the payment was moved into the suspense account after it posted to the customer account.
■ If the payment was originally made to the suspense account, the list contains
all payments generated from the original payment, including distributed payments and any payment remaining in the suspense account.
In both cases, the sum of all the payments reversed in this operation should equal the amount of the original payment.
If the reversal is called for a SEPA payment transaction, the opcode creates the /sepa/dd/reversal object only if the original payment request is in the
REQUESTED status. If the charge event, /event/billing/charge/sepa, does not exist, it records the reversal only (the /sepa/dd/reversal object is not created assuming that the payment request has not been sent to the bank).
PCM_OP_BILL_REVERSE_PAYMENT verifies that the reversal operation was successful for all of the payments. It uses the PIN_FLD_SESSION_OBJ field in the input flist to reference the reversal batch event.
It also checks the /config/business_params object to determine whether payment incentives are enabled. If so, PCM_OP_BILL_REVERSE_PAYMENT calls the PCM_OP_PYMT_REVERSE_INCENTIVE opcode, which removes the payment incentive trigger in the /billinfo object, thus eliminating the payment incentive.
7. Populates the payment batch with the sum of the reversal flist.
8. Returns the reversal information for all the payments in the PIN_FLD_MULTI_ RESULTS array.
The PIN_FLD_RESULTS field of the output flist indicates whether the reversal was successful. Direct reversal is not allowed if either of the following conditions is true:
■ The payment has a SUB_TRANS_ID value and, therefore, is not an original
payment.
■ PCM_OP_BILL_REVERSE is called from the PCM_OP_PYMT_RECYCLE_
PAYMENT opcode. In this case, a reversal takes place, but it is not a direct reversal. See "How Payments Are Reversed".
To customize how written off payments are reversed, use the PCM_OP_BILL_POL_ REVERSE_PAYMENT policy opcode. See “Customizing Reversal of Payments Allocated to Written-Off Accounts” in BRM Managing Accounts Receivable. If you have Payment Suspense Manager enabled, you can reverse only original payments. For information on payment reversals that occur during payment suspense processing, see "How Payments Are Reversed".
For information on processing a payment reversal batch by using Payment Tool, see