Exchange
rates are stored in the APP_Exchange_rate table. The calculation
involved is:Foreign Currency Amount divided by Exchange Rate = Base Currency
or
Base Currency Amount times Exchange_Rate = Foreign Currency Amount
Receipt transactions have a FAR_TXN.TXN_TYPE of ‘1’.
In an accrual based accounting system, receipt transactions are very simple. There are only two different situations that need to be outlined:
For Pre-Payments of Uninvoiced Orders |
||
|---|---|---|
DR |
Cash |
(positive number) |
CR |
PPL- Pre-paid Liability account |
(negative number) |
For Payments against invoiced orders |
||
DR |
Cash |
(positive number) |
CR |
AR - Accounts Receivable |
(negative number) |
Debit: To record any receipt, the user must open a batch. This batch will contain a list of receipt types valid for the batch. Each receipt type will be associated with an asset account that will be used for creation of receipt transactions. You must identify the batch, receipt type, currency, and this in turn provides the system with the GL account to use where “Cash” is indicated above.
Credit: Receipt transactions are created against one of two types of accounts, both of which are defined with the product being ordered:
· Prepaid Liability Account: This account is used for any order where there is no sales transaction (i.e. no invoice number).
· Receivable Account: This account is used when a receipt is applied to an invoiced order.
Cash Basis Transactions for Fund Raising: There are a couple of instances in Personify360 where you have the option to create a cash basis transaction. This is primarily used in the Fundraising module. In this case, the debit will still be the same as described above but the credit will be the same as the distribution of a typical accrual type of sales transaction.
In Personify360, you can create orders as either proforma or active, and in most cases the system will automatically activate a proforma order when a receipt is applied. You can also set short-pay parameters as you define pricing for products that can prevent this behavior from happening.
The rules are fairly simple:
1. If the subsystem = ADV or XBT, then the line item is not made active by application of cash.
2. If the short-pay flag = ‘REJECT’, the amount of the receipt must be greater than or equal to the total amount on the order for the line item to be activated.
An unapplied receipt is a receipt maintained by the system on behalf of a specific customer but NOT associated with a specific order_detail line. These are stored as FAR_TXN and FAR_Txn_Detail records with a system generated order_no and order_line_no, and a FAR_Txn.subsystem=’UAR’ with the amount stored as would be standard for receipts.
The structure for this transaction is as follows:
DR |
Cash |
|---|---|
CR |
System Unapplied Receipt Account (app_org_unit.unapplied_receipt_account |
When a receipt is applied to a customer on the Receipt Entry (FAR002) screen or to a specific order via the Quick Pay (FAR011) screen, the system automatically applies cash to a sequence of orders rather than to a specific order. The sequence should be:
· Oldest orders get paid first.
· Within an order, pay by pay-priority for “current” balances. Current balances are line items where there are no deferred receipts due to scheduled payments.
· After this, apply money to line items in pay-priority that have scheduled payments.
· Anything left over, create a deferred receipt.
On the Quick Pay (FAR011) screen, the customer explicitly applies cash to an order, it should apply cash to all line items in the order and not over pay one and ignore the one with scheduled payments. Order details "current" amounts due (i.e. without future scheduled payments should be paid first), and then the rest applied to lines with deferred receipts.
Minimum information needed for the process:
· Batch number
· Receipt type
· Order_No
· Order_Line_No
· Customer number
· Application code
· Amount
1. In creating the FAR_Receipt, FAR_Txn, and FAR_Txn_Detail objects with the data necessary to process receipts, verify that the foreign currency issues have been addressed. Typically, the system defaults the actual current code to the base currency code unless the user changes it. Then, the system calculates the base_amount by actual_amount * XRate. Transactions are created in the base currency though the system captures the actual currency information.
a. If the currency_code is different from the base currency in the system (order_detail.currency_code), then the system captures the exchange rate and exchange date in force at the time of the order date which is typically the batch date. (order_detail.XRATE)
b. Based on these exchange rates, the system calculates the base_amount resulting from this exchange rate and foreign currency amount.
Exchange
rates are stored in the APP_Exchange_rate table. The calculation
involved is:
Foreign Currency Amount divided by Exchange Rate = Base Currency
or
Base Currency Amount times Exchange_Rate = Foreign Currency Amount
c. When creating the FAR_Txn_detail records, the system creates the profit or loss to exchange rate.
2. The system creates the objects for the FAR_Receipt, FAR_Txn, and FAR_Txn_Detail records and populates with either default information or information passed in based on the templates.
a. For each order that the receipt is applied to, the system:
i. Determines if the amount is real or deferred. If the order line item is for a backordered product (order_detail.line_status_code=’B’), then the amount is summed to the deferred amount column in the far_receipt record.
ii. Creatse a FAR_Txn record for each order detail line against which the receipt was applied. Note that it can be either a type=1 (Receipt) or type=9 (Deferred Receipt).
iii. Creates the FAR_Txn_Detail distribution. The transaction templates indicate the source for the GL account and other information needed.
iv. Verifies that sum(FAR_Txn_Detail.base_amount) = zero. This verifies at least that debits=credits.
v. Processes intercompany to balance each transaction by company within each set of far_txn_detail records.
b. FAR_Receipt record will be created for the receipt itself,
i. Based on how the receipt was applied, there may be deferred receipt information that needs to be calculated based on the sum of deferred amounts at the line item level. In any case, the amount and deferred amount information is summed from the far_txn records.
ii. If there is an unapplied receipt amount, create an unapplied receipt transaction which is assigned an order number but does not actually reference and order_detail record and has a FAR_Txn.subsystem =”UAR”.
3. If the receipt_type_code is a credit card and,
a. If this is a credit card and the pre-settled flag is ‘Y’, the system skips the credit card processing. The authorization should already be recorded and the credit card has already been charged.
b. If this is a receipt reversal and a “charge back”, then the system skips the credit card processing since the bank has already cancelled the transaction.
c. The system verifies the credit card and creates a transaction based on the summed totals in the FAR_Receipt record and NOT based on the individual FAR_Txn records. In this way, there will be a single credit card transaction rather than one for each line item.
d. If there are deferred amounts, the system gets a pre-authorization for the deferred amounts.
4. The system updates the amounts and counts in FAR_Batch_Detail for the open batch.
In this section:
· Viewing Payor Change History
· Personify360 Payment Distribution