The FAR670 batch process updates deferred revenue transactions so that revenue that is due to be recognized is moved to real revenue GL accounts.
"Deferring revenue" is an accounting practice process which postpones recognition of revenue until the purchased product of service is provided or delivered to the customer. In the case of memberships that span a period of time, such as 12 months, revenue is typically recognized after each month of the membership. For subscriptions that span a period of time, using the same example of 12 months, revenue is typically recognized after each issue is fulfilled (or sent) to the subscriber. Revenue from meeting registrations is usually deferred until either the meeting start date or end date.
Revenue recognition, then, is the process whereby the revenue amount that is shown on an organization's income statement is "recognized" either over the life of an order or some triggering event. The revenue amounts are moved from deferred revenue GL accounts to real revenue GL accounts based on the product revenue account setup defined in the PRODUCT_REVENUE_DISTRIBUTION and FGL_Shipping_Account tables for the purchased product. If an order line includes discounts or shipping charges, those amounts are also deferred and recognized using the same recognition method as the revenue on the order line. For instance, a subscription for $120 for 12 issues will move $10 per issue from the deferred revenue account to the real revenue account.
As
of 7.4.2, whenever the Revenue Distribution on the product is set to "By
Priority" and the order quantity is greater than 1, then the revenue
will be distributed amongst the accounts in the following manner:
Revenue a/c 1: [Total revenue on the order-(Amt within Priority 1*order
qty)-(Priority 2*order qty)]* % within the priority
Revenue a/c 2: [Total revenue on the order-(Amt within Priority 2*order
qty)-(Priority 1*order qty)]* % within the priority
When the FAR670 batch process is run, the process evaluates each selected order line where revenue has not been completely recognized and determines what amount of deferred revenue can now be recognized, based on the date entered for the Transaction Date parameter. Then, financial transaction records are created for the amount of revenue that can be recognized and for the amount of revenue that is still deferred. If all revenue is recognized, the process updates the recognition status code on the order line to 'C' (for Complete).
Deferred revenue is usually recognized by issue for subscriptions, but can be done monthly as well. For subscription orders where revenue is being recognized by issue, revenue is recognized after the issue date where records exist in Sub_Issue_Fulfillment for the order line for the issue. If a subscription is back-dated, revenue recognition does not happen until after back-issues have been generated.
The FAR670 process is "self-correcting", which means that if the amount of the order changes over time, or if the term of the membership or subscription changes, the next time the revenue recognition process runs, it will recalculate the correct amount that should have been recognized to date, adding or subtracting from the recognized amount to bring it in line with the new amount or new term length.
FAR670 skips cancelled orders, because the process of cancellation adjusts (if necessary) and completes revenue recognition.
The
FAR670 batch process does recognize revenue for expired order lines.
FAR670
will not recognize revenue for transactions prior to the GL close date.
If you try to run FAR670 for the same, FAR607 will fail with the following
error message: “Transaction Date for the revenue recognition transaction
cannot be equal to or prior to the GL Close Date”. If you want to run
the FAR670 for a specific date that is prior to the GL Close Date, you
must reset the GL Close Date, run the FAR670, and complete the month-end
close reconciliation process again as of that date.
As of 7.5.2, the new Subscription Recog. Date field has been added to the GL Accounts screen in Product Maintenance, which identifies whether subscription revenue should be recognized by issue date or fulfill date.
The new Subscription Recog. Date only applies to subscription products where the Recognition Method field is set to "Issue". If the Recognition Method field is set to "Monthly", FAR670 will recognize subscription revenue as it currently does.
When the Subscription Recog. Date field is set to “Fulfill Date” and the Recognition Method field is set to "Issue", FAR670 will recognize revenue for fulfilled issues for subscription orders where the issue Fulfill Date is <= the value entered for the FAR670 "Transaction date" parameter. What this means is that as of 7.5.2 the logic that excludes orders where the Cycle Begin Date is > than the FAR670 "Transaction date" parameter has been changed for subscription orders where Recognition Method field is set to "Issue" and the Subscription Recog. Date field is set to “Fulfill Date” to exclude subscription orders where the issue Fulfill Date is > the FAR670 "Transaction date" parameter.
When the Recognition Method field is set to “Issue Date”, FAR670 will recognize subscription revenue as it currently does by issue date.
When memberships and subscriptions are created, they can be created to start from the order date, rather than the first of the month, if desired. When revenue is recognized monthly, the user can specify whether revenue for memberships and subscriptions that have a short month should be recognized at the beginning of the membership or subscription term or at the end of the membership or subscription term.
Personify360 provides a number of ways that revenue can be deferred and recognized. The recognition method for each product is defined on the GL Accounts screen in Product Maintenance:
· On Invoice – All revenue is recognized on invoicing. This recognition method can be used for all subsystem products. Order_Detail.RECOGNITION_STATUS_CODE is set to 'C' on order creation.
· Specific Date – This is typically used for meeting (MTG) and exhibition (XBT) products. With this recognition method, a date is also set for when revenue can be completely recognized. This recognition method can be used for all subsystem products. Order_Detail.RECOGNITION_STATUS_CODE is set to 'A' on order creation. When FAR670 is run on or after the specified date, all revenue is recognized and Order_Detail.RECOGNITION_STATUS_CODE is updated to 'C'.
· Year End – All revenue is recognized at year end. This recognition method can be used for all subsystem products, but is rarely used. Order_Detail.RECOGNITION_STATUS_CODE is set to 'A' on order creation. When FAR670 is run on or after 12/31 of any year, all revenue from that year is recognized and Order_Detail.RECOGNITION_STATUS_CODE is updated to 'C'.
· Begin Date – All revenue is recognized on the begin date of the order. This can be used for advertising, exhibition, facility, meeting, membership, or subscription products. For products using the "Begin Date" recognition method, FAR670 evaluates Order_Detail.CYCLE_BEGIN_DATE. Order_Detail.RECOGNITION_STATUS_CODE is set to 'A' on order creation if the Order Date is before Order_Detail.CYCLE_BEGIN_DATE. FAR670 updates Order_Detail.RECOGNITION_STATUS_CODE to 'C' when it is run on or after Order_Detail.CYCLE_BEGIN_DATE.
· End Date – All revenue is recognized on the end date of the order. This can be used for advertising, exhibition, meeting, membership, or subscription products. For products using the "End Date" recognition method, FAR670 evaluates Order_Detail.CYCLE_END_DATE. Order_Detail.RECOGNITION_STATUS_CODE set to 'A' on order creation if the Order Date is before Order_Detail.CYCLE_END_DATE. FAR670 updates Order_Detail.RECOGNITION_STATUS_CODE is updated to 'C' when it is run on or after Order_Detail.CYCLE_END_DATE.
· Monthly – Revenue is recognized monthly based on the order date for some specified number of months. Monthly recognition is typically the smallest unit of time over which revenue is recognized. The only time a smaller unit of time might be needed is for publications, which may be weekly and organizations may want to recognized revenue after each issue is fulfilled. This method is available for advertising (web orders), membership, subscription, and transcript products. Order_Detail.RECOGNITION_STATUS_CODE is set to 'A' on order creation.
· By Issue – Used for publications where the batch process references the issues fulfilled table. Available for subscription products only. Order_Detail.RECOGNITION_STATUS_CODE is set to 'A' on order creation.
FAR670 uses the GL accounts in effect for real and deferred discounts, real and deferred agency discounts, and real and deferred shipping charges at the time for the order date for all subsystem order lines. FAR670 uses GL accounts for real and deferred revenue in effect at the time of the order date for all subsystems except for Memberships and Subscriptions. FAR670 selects real and deferred revenue GL accounts in effect at the time of the "Cycle Begin Date" of Membership or Subscription order lines.
FAR670 will process transactions for order lines that have a LINE_STATUS_CODE where 'REVERECOGNITION' is in App_Code. OPTION_1 for the line status code. In the base application, only line status codes of 'A' have 'REVRECOGNITION' in the OPTION_1 column. This was executed for organizations that customize order entry to use different line status codes.
Revenue recognition is typically run on a monthly basis.
Before FAR670 is run, the following activities should be done:
· The SUB670/SUB671 processes should be run for the month before running revenue recognition, because revenue is typically defined to be recognized by issue on Subscription orders, which means that revenue is recognized after the issue is fulfilled.
· If revenue is deferred for web advertising orders that span multiple months, ADV620 should be run to invoice the web ad orders.
· All deferred batches should be posted, so that order lines that will be activated and invoiced because of a payment will have appropriate financial transactions created.
· If the organization has pending adjustments to make to AR or PPL, those should be done before running FAR670.
FAR670 should be run before running FAR700 to transfer transactions to GL.
Parameter |
Description |
Required? |
|---|---|---|
Subtitle |
This field is used to enter in a subtitle that appears as part of the report header on each page. |
No |
Run Mode |
· EDIT: this mode will not update the database; it will only generate the report using input parameters · PROD: this mode will produce a report of records selected, but will additionally update the order tables · REGENERATE: this mode will only produce output reports for an already processed JOB_ID |
Yes |
Transaction date |
The FAR_TXN.txn_date. This is also the date that is used when comparing to “Specific Date” recognition method. For Monthly recognition use only the month value to determine which month, then recognize for the last day of that month.
|
Yes |
Subsystem |
The subsystem (product type) for which to run the revenue recognition. Select "ALL" to allow the process to run against all orders at one time. |
Yes |
Organization |
The Organization ID for which to run the process. |
Read-only |
Organization Unit |
The Organization Unit ID for which to run the process. |
Read-only |
Parent Product Code |
The parent product code for which to run the revenue recognition (optional). |
Yes |
Product Code |
The product code to limit the revenue recognition for a specific product (optional). |
No |
Report Format |
· Summary: will only print a listing of account totals. · Detail: will also print summary information but will also include detail order information to back up summary totals. |
Yes |
Short Month Processing |
This parameter only applies to MONTHLY revenue recognition method code. MONTHLY revenue recognition is applicable for MBR or SUB Subsystems. The valid values are "BEGIN" or "END". Enter BEGIN to recognize the short month at the beginning of the Membership/Subscription term. Enter END to recognize the short month at the end of the Membership/Subscription term. |
No |
Advanced Job Parameters |
||
Filter |
Enter in an SQL statement to be included in record selection as an additional clause in the report query. The criteria can be based on far670_vw view. For example: FAR670_VW.PRODUCT_CODE = 'NEWBOOK' |
No |
Commit Frequency |
Enter the commit frequency. This determines the frequency after which the database changes are committed. |
No |
Sort Order |
Enter the sort order for the report. Detailed report will be sorted based on this parameter.
|
No |
Regenerate Job ID |
Enter the TRS Job ID from the previous run of FAR670. This is required in REGENERATE mode only. |
No |
You can add further filter criteria using the "Select Criteria" filter in the Advanced Job Parameters tab. You can select any field from the FAR670_VW view for additional filtering.
The FAR670 batch process selects records from the FAR670_VW view for order lines that are active*, invoiced, and that have not had revenue completely realized (i.e., Order_Detail.RECOGNITION_STATUS_CODE <> 'C'). Note that fundraising order lines and package order lines are not selected for deferred revenue recognition. Technically, the process selects records Order_Detail where LINE_STATUS_CODE = App_CODE.CODE and App_Code.SUBSYSTEM = Order_Detail.SUBSYSTEM and App_Code.TYPE = 'LINE_STATUS' and App_Code.OPTION_1 = 'REVRECOGNITION'. Amounts are calculated from sales (Far_Txn.TXN_TYPE_CODE = '4') and adjustment (Far_Txn.TXN_TYPE_code = '6') transactions for posted transactions (Far_Txn.POSTED_FLAG = 'Y').
Order lines with products defined to have revenue recognized on a specific date are excluded if the date defined for revenue to be recognized is in the future.
Additionally, subscription and membership orders where the begin date is in the future are excluded.
The process also filters records based on values entered for the FAR670 parameters. The process selects Order_Detail records where the INVOICE_DATE is less than or equal to the date selected for the "Transaction Date" parameter. If the user has entered a value other than ALL for the subsystem parameter, or if the user has entered any parameter values for "Parent Product" or "Product Code", FAR670 will selected order lines with those subsystem, parent product, and/or product code values.
The FAR670 batch process uses the FAR670_SP stored procedure. Records are selected from the FAR670_VW view and inserted for processing into the following tables:
· FAR670_Table
· FAR670_FTD_DEF
· FAR670_FTD_REAL
· FAR670_INTER_COMP
· FAR670_FAR_TXN
· FAR670_FAR_TXN_DETAIL
· FAR670_SUB_ORDERS
· TMP_FAR670_FAR_TXN
For all order lines where revenue is being recognized by issue, the process calculates the number of issues fulfilled for each subscription order line where the Subscription issue date is less than or equal to the FAR670 "Transaction Date" parameter and subscription issue fulfillment type is either P (production), B (back issue), S (single issue sale), or T (grace issue transferred).
For membership order lines where revenue is being recognized monthly, the process calculates the number of months between the begin date and the FAR670 transaction date.
The process then creates new Type 7 (Far_Txn.TXN_TYPE_CODE = '7') records in Far_Txn and Far_Txn_Detail for the new revenue amount that can be recognized and for the same amount to reduce the deferred revenue amount remaining. If any Due-To/Due-From transactions are required, those are also created. A value is updated to Far_Txn.BATCH that is a tilde (~) followed by 8 numbers that represent the year (YYYY), the month (MM) and the day (DD) the process was run, and "FAR670" followed by the same 8 digits that identify the date the process was run is set as the value in the ADDOPER field. The Far_Txn.TXN_DATE is set to the date value defined for the FAR670 "Transaction Date" parameter.
For all subscription order lines, the process updates the Sub_Issue_Fulfillment record for each issue for which revenue was recognized, settling the value for Sub_Issue_Fulfillment.TRS_JOB_ID to the FAR670 TRS Job ID, Sub_Issue_Fulfillment.REVENUE_RECOGNITION_TXN to the Far_Txn.FAR_TXN_NO of the Type 7 transaction and Sub_Issue_Fulfillment.REVENUE_AMOUNT to the amount of revenue that was recognized for that issue.
If all revenue will be completely recognized, Order_Detail.RECOGNITION_STATUS_CODE is updated to 'C'.
Last, the process inserts records into the following tables to be used to generate the FAR670 reports:
· FAR670_SUMMARY_REPORT
· FAR670_SKIPPED_ORDERS
The Detail report is generated off of the FAR670_Table table.
The FAR670 Detail report can be sorted by any field used in the report; for example, by Order_No, Product_Code, or Parent_Product.
When run in PROD mode, the process updates creates records in Far_Txn with a TXN_TYPE_CODE = '7' and the BASE_AMOUNT set to $0. Records are also created in Far_Txn_Detail with TXN_FUNCTION_CODE values of REVENUE and DEFFREV, with the Far_Txn_Detail.BASE_AMOUNT for the 'REVENUE' record equal to the amount of revenue that was able to be recognized for the order line, and Far_Txn_Detail.BASE_AMOUNT for the 'DEFREV' record equal to the revenue amount that is still deferred.
If all revenue has been recognized on an order line, the process updates Order_Detail.RECOGNITION_STATUS_CODE to 'C' (for complete).
For subscription order lines, TRS_JOB_ID, REVENUE_RECOGNITION_TXN, and REVENUE_AMOUNT are updated in the Sub_Issue_Fulfillment table for all issues for which revenue was recognized.
This batch process generates the following reports (see below for sample reports):
· FAR670 Summary: displays a listing of totals by GL account. On the reports, deferred accounts should mostly have debit numbers and revenue accounts should mostly have credit numbers.
· FAR670 Detail: gives details about real revenue accounts, not deferred revenue accounts, which means that most of the amounts should be credit amounts.
Do a search
for "Total for", which will bring you to the subtotal line of
the next GL account. Continue to find "Total for" to review
GL account subtotals for recognized revenue.
· FAR670 Skip: displays a list of orders that could not have revenue recognized because of one of the following reasons:
o Invalid Account - Either deferred or AR account is no longer valid
o Mismatch - This mostly will apply to back-issues for publications where there is no issue inventory to send. This will occur when periods to recognize income exceed the number of rows in SUB_ISSUE_FULLFILLMENT table for an order. Therefore, revenue cannot be recognized
o Data entry errors, such as a membership or subscription end date is before the begin date.
Make sure to check the FAR670Skip exception report and resolve errors.
