Creating a Refund

Personify360 is a receivables system and does not issue checks. What we can do, however, is create vouchers, which are requests for checks from an external payables system. We generate a transaction against a Payables Transfer Account and this transaction is sent to the GL in the normal way. From there, the payables system would generate a check.

Personify360 has a number of interfaces to various AP systems and depending on the AP system, the transfer is handled in different ways, as allowed by that system. Typically, the AP system creates its own AP transaction which washes out the AP transfer account. The rest of the typical payables transaction, the offset accounts, is passed to the GL through the normal process.

Refunds can be made for the following receipt types:

· Cash - Refunds are made in full in the currency selected.

· Credit - Only the most recent receipt against the line item(s) in question will be refunded. Credit balances are always refunded first unless the user selects a specific line item. These are fundamentally different from refunds as generated from checks. When a receipt being refunded is a credit card, the refund must go to that credit card unless the user specifically requests this through the UI. A voucher transaction is still created but not against the payables transfer account. For credit cards, the transaction is a debit to AR (or PPL) and credit to the credit card receivable account from the original batch. If you are processing a refund that has been presettled, then it does not get processed through the credit card processing system (it already has been) but the same transaction gets created against the credit card receivables account.

· Check - A voucher is created that is transferred to the GL for payment through the AP system.

· PayPal - as of 7.6.1, the same functionality available for credit card payments is also available for PayPal payments so that staff can process receipt transfers, refunds, reversals, or void receipt authorizations.

If a full refund is indicated, then the full amount of the receipt will be refunded. The order line total should be $0. If there are multiple currencies involved and the full amount of one currency is refunded and the amount goes in the second currency, the system verifies that the full amount of the first currency was refunded without any rounding. All rounding issues are reflected and corrected in the base amount. Refunds are made based on the original receipt types referenced by specific orders and line items.

As of 7.6.1, you cannot transfer or refund a payment created by EFT680 until the number of days identified by the Days to Wait for EFT681 Results field on the org unit setup has passed since the payment was created (Far_Receipt.ADDDATE). Please note that real dates will be used in this scenario, not batch dates, because there has to be time allowed for the bank to return the file with information about payments that were not able to be successfully collected.

Transaction Structure

Refunding a receipt will create type ‘2’ transactions with the following format:

Voucher – Check Requests for Invoiced Order

DR	AR
CR	Accounts Payable Transfer

In the AP transfer a true AP transaction will be created:

DR	Accounts Payable Transfer
CR	Accounts Payable

Then the check is cut:

DR	Accounts Payable
C	Cash

Voucher – Check Requests for Un-invoiced Order

DR	PPL
CR	Accounts Payable Transfer

Credit Card Refunds for Invoiced Orders

DR	AR
CR	Credit Card Receivables

Credit Card Refunds for Un-invoiced Orders

DR	PPL
CR	Credit Card Receivables

Source of the Accounts

Debit:

The AR and PPL accounts are found at the order_detail level (order_detail.AR_Account and order_detail.PPL_Account). One FAR_TXN and two FAR_TXN_DETAIL records are created for each order_detail record referenced by a receipt.

Credit:

The Accounts Payable account is found by app_org_unit.payable_account for the order_master.org_id, order_master.org_unit_id combination. The Credit Card Receivables account is accessed by finding the batch number and receipt type from the far_receipt record and finding the reference far_batch_detail.debit_account.

Logic for Refund Creation

Minimum information needed for the process:

· Receipt_No

· Amount

· Collection of Order_No and Order_Line_No

1. Create the objects for the FAR_Voucher, FAR_Txn, and FAR_Txn_Detail records and populate with either default information or information passed in based on the templates below.

a. Verify that the receipt has been posted and that the receipt has not been transferred (the processing logic should have already prevented this, however.)

Refunds are typically created against specific receipts so that the refund transaction (FAR_Txn type=2) can carry with it the original receipt_no. Each FAR_TXN created must reference a specific receipt.

b. For each order/line number combination that the refund affects:

Note that the debit account is different depending on whether the order has been invoiced and the credit account will be different depending on whether this is a credit card.

i. If the refund is to a credit card

· If this is a credit card refund and the refund date is the same day as the credit card receipt, then process this as a credit card VOID or cancellation rather than a refund.

· If the “settled credit card” flag is set to ‘Y’, then do not send to the credit card company but still create the same TIMSS transaction.

· If this is a credit card refund and the refund date is not the same date as the credit card receipt, process the credit card transaction as a CC refund transaction.

ii. If the refund is NOT to a credit card, it is by definition a check request or voucher.

iii. Create a FAR_Txn type=2 record for each order against which the refund was applied.

iv. Create the FAR_Txn_Detail distribution as outlined above. The transaction templates indicate the source for the GL account and other information needed.

v. Verify that sum(FAR_Txn_Detail.base_amount) = zero. This verifies at least that debits=credits.

vi. Do intercompany processing to balance each transaction by company within each set of far_txn_detail records.

vii. FAR_Voucher record will be created for the refund itself.

For step-by-step instructions, please see Refunding an Order.