Receipt Transfers

Performing a receipt transfer is Personify creates transactions where FAR_Txn.Txn_Type_Code = 3.

“Transfers” are specific to the transferring of receipts from one order or one line item to another. They are always done in pairs of transactions that reference the specific line items and the specific receipt involved so that the audit trail can be tracked easily as a receipt may come in and get transferred around the system. Typically, a receipt transfer consists of an incorrectly applied posted receipt or over-payments from one order to another.

For multi-line orders with a credit balance, the amount will be transferred from the all of line 1 before moving on to the next line. For example, an order has two lines, one with a credit balance of $20 and the other with a $0 balance. If one transfer of $10 is created from the order, the $10 will be taken from line one. If another transfer is created from the same order, the credit will be taken from line one (with the remaining credit), not line two.

Verify the following before transferring a receipt:

·            The receipt to be transferred has been posted

·            A balance remains on the receipt and the transfer does not exceed that balance

Transaction Structure

Transfers will create two type ‘3’ transactions with the following format:

Order from which the receipt is being transferred (increases order balance)

Order to which the receipt is being transferred (reduces order balance)

The Receipt Transfer Account zeros itself out in terms of it’s affect on the GL.

Source of the Accounts

The AR and PPL accounts are found at the order_detail level (order_detail.AR_Account and order_detail.PPL_Account). Use the AR account if the order_detail.invoice_no is not null (i.e., the order is invoiced). Use the PPL account if the order_detail.invoice_no is NULL (i.e., the order is uninvoiced.) Use the Unapplied Receipt Account (app_org_unit.unapplied_receipt_account) if the subsystem referenced in the FAR_Txn record is ‘UAR’. There will be no order_detail record for an unapplied receipt.

One FAR_TXN and two FAR_TXN_DETAIL records are created for each order_detail record referenced by a transfer.

The Receipt Transfer account is found in app_org_unit.rcpt_transfer_account for the order_master.org_id, order_master.org_unit_id combination. It is a system account that should always have a zero balance in terms of any affect on the GL.

Logic for Receipt Transfer

Minimum information needed for the process:

·            Receipt_No

·            Amount

·            Order number and order line number from which the receipt is being moved

·            Order number and order line number to which the receipt is being moved

·            Application code

1.    Verify that the receipt being transferred has been posted. Only posted receipts can be transferred.

2.    Verify that a balance remains on the receipt and that the transfer doesn’t exceed that balance.  Though multiple transfers can be made against a receipt, the sum of the receipt and all transfers cannot be greater than zero. Note that receipts are negative numbers in FAR_Txn.base_amount and that transferring a receipt from that balance is a positive number. Therefore the sum must be less than zero. A zero sum means that the entire receipt has been transferred. You know a specific receipt based on FAR_Txn.Receipt_No which is carried in all transactions (receipts and transfers) that relate to the specific receipt.

3.    Create the objects for the FAR_Txn, and FAR_Txn_Detail records and populate with either default information or information passed in based on the templates below. Note that one FAR_Txn and 2 FAR_Txn_Detail records will be created for each of the two orders involved in the transfer.

4.    For each transaction:

a.    Determine if the order is invoiced, uninvoiced, or unapplied to decide on whether to use the AR account or PPL account for the transfer. They do not have to be the same for each order line item in the transfer.

b.    Verify that the sum of FAR_Txn.base_amount is zero. (debits must equal credits)

c.    Save the two sets of records as a single transaction in the database.

Special Issues for Transfers

• Receipts must be posted.

• Transfers can only be done between orders within the same organizational unit.

• You cannot transfer from an order line item more than was originally applied to that line item.

• Proforma versus Active Orders Situation
  If a receipt is applied to a proforma order, that order is made active, invoiced, and transactions are created. The problem comes when the receipt is misapplied. There is no way to reverse the movement from invoiced to uninvoiced given that there are financial transactions that you cannot simply delete. On the other hand, we have issued order numbers to customers so we can’t just cancel the order and create new ones. The only real way to deal with this is to cancel the order detail line items and create a new proforma order details.
  There are actually two situations, invoiced versus non-invoiced orders as a result of activation. For uninvoiced orders, the system simply reverts the order_status_code back to proforma since no financial transactions yet exist. This covers inventoried products, exhibition orders, and advertising orders. To accomplish this, the system needs an order_detail.original_status_code that is set to match the order_status_code when the order is created. Otherwise, the system doesn't know if the order was original proforma or not.
  For invoiced orders, this is more difficult since financial transactions have been created and cannot be deleted. Therefore, the system will cancel the first order and create a new one. This primarily happens in membership and subscriptions. The replacement order details match the previous ones in every respect including the original order number. If the short pay status is adjust on the product, then the full amount of the product will be replaced based on the product_pricing tables rather than copy the adjusted amount.

• Multi-Currency Issues
  If the foreign currency is locked-in for the order, the system accepts the amount in the foreign currency, but may make currency correction transactions if the exchange rate changes by the time the receipt is received. If there have been currency correction transactions applied to the original order, those will be reversed for the amount of the receipt being transferred. If there is a foreign currency locked in to the new order, then the system recalculates any currency conversion that results from the application of the receipt to the new order based on the exchange rate at the time of the receipt (i.e., from the FAR_Receipt record with the exception of where an exchange rate is already locked into the “To” order). An example of the complexity is where the money is misapplied to the first order where there was no currency correction and then moved to the correct order where the foreign currency is locked in. Basically, the system looks at this as a transfer of the foreign currency, the actual amount, rather than a transfer of the base currency amount. By doing this, the system will verify that we are reversing any currency correction that may have taken place in the original order.
  
  Scenarios where this situation may occur:

• • The receipt is applied to the correct customer but wrong order. The currency exchange rate for one order or the other may be locked in and if so needs to be followed.

  • If the receipt caused a currency correction, then this needs to be reversed for the amount of the receipt transfer.

  • If the receipt is moved to an order with a different locked in currency, then rules for that must be followed.  
    The system reverses a receipt based on the currency of the original receipt and the exchange rate captured with that receipt regardless of where it is transferred to, except for where it is applied to an order that itself has the exchange rate defined. If a currency correction was done, the system has all the information it needs to reverse the receipt. In fact, the system might look at this as a receipt “reversal” against the original order rather than try to work out the metrics behind moving part of it. That is, the system would reverse the first one and reapply the remaining portion is a remaining portion exists.
    For the “To” order, the system treats the transfer just like a new receipt in the currency of the original receipt. This then makes a difference to the transaction in terms of currency correction.

Original Receipt against the “To Order”

Receipt Transfer away from the “To Order”

• Short-Pay issues
  When receipts are applied to orders where the short pay flag is “ADJUST”, then the incorrect application of cash will cause the balance to automatically adjust. When all receipts are moved from an order where the ADJUST flag is set to ‘Y’, the amounts columns are updated from the product_pricing tables as if a new line was created and as if the original receipt was never applied. This means that you may be left with an invoiced transaction rather than what may have originated as a proforma transaction.
  If the short pay flag is “Reject” and the application of the receipt has NOT activated any order_detail lines where sufficient money has been applied, then the order_detail.order_line_status remains ‘P’ (proforma) and continues to show up on the Receipt Entry (FAR002) screen as an open order until either sufficient amount is paid or the line is cancelled. This is really the same as a transfer of an unapplied receipt against a proforma order so doesn’t really change anything from the standard approach to transfers.

• Write-offs
  There is also the concept of writing off a balance if the payment comes within a certain tolerance that we must deal with in terms of transfers since the sales amount may have been affected by this. If the receipt has created such a write-off and is reversed or transferred, that write-off must automatically be reversed as well. Below is the comparison of transfers with cancellation of source line and cancellation with write-off:

• • When any line (MTG/MBR) is cancelled, whether or not there is a payment against the order or if there is any write-off against that line, it gets reversed.

  • When any line is transferred (MTG and MBR with same begin date and different ship-to) and there is no payment against the line and there is a write-off for the line, the system cancels the line, zeros out the write-off, and transfers the write-off to the target line. However, if there is a payment and write-off for that line, the system creates two zero amount write-off entries on the source line and cancels it, but does not transfer the write-off to the target line.

  • If you transfer a MBR line with different begin date and different ship-to which has a write-off, the write-off is prorated on the source line and target line.

• Payment Collection Issue
  As of 7.6.1, if the organization is using Vantiv, when a receipt created by FAR680 has a date value in Far_Receipt.AUTHORIZATION_RECYCLING_END_DATE, it cannot be transferred. If the user attempts to transfer a payment created by FAR680 before the FAR681 response has been processed (i.e., while Far_Receipt.AUTHORIZATION_RECYCLING_END_DATE is not null, because FAR681 will update the Far_Receipt.AUTHORIZATION_RECYCLING_END_DATE to NULL), the user will be presented with a message: The payment you are attempting to refund cannot be refunded until on or after [Far_Receipt.AUTHORIZATION_RECYCLING_END_DATE] because the payment has not yet been collected. For more information, please see Vantiv Authorization Recycling.

• EFT681 Results
  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.

This section covers the following:

·            Transferring a Receipt

·            Transferring a Credit Balance or Unapplied Receipt

·            Transferring a Deferred Credit Card Receipt

See Also:

·            Overview: Customer Financial Analysis

·            Viewing Financial Summary

·            Writing Off a Balance

·            Creating a Refund

·            Paying the Selected Order

·            Paying Open Orders

·            Creating an Advanced Adjustment

·            Viewing Transaction Details

·            Reversing a Receipt

·            Reversing a Refund