This batch report selects pending scheduled payments and updates them for processing. FAR680 picks only those records whose process date is null or Rejected flag is Yes with status code= "Pending". Any updated scheduled payments being paid by credit card are then authorized for payment. Updated scheduled payments not paid by credit card are ready for invoicing or direct debit payment processing via the associated batch process (e.g., EFT680 or CCP610).
If
a payment schedule has credit card info, FAR680 is going to collect scheduled
payments that are due/overdue, regardless whether an invoice or a notice
was sent to the customer. The payment is overdue based on the due date
of the scheduled payment.
If
a status is "PAID", this means that a payment or transaction
has been applied to reduce the balance. Usually, this happens as a result
of a Type 1 payment transaction, but this status can also result from
a reversal of a Type 2 refund, Type 3 transfer transaction, or Type 5
write-off.
FAR680
does not look for the CVV result when it performs a reference transaction.
When FAR680 is run, it sets the Order_Detail.DUE_DATE based on the payment due date of associated scheduled payments. FAR680 selects order lines based Order_Detail.DUE_DATE, so that all of the scheduled payments that are due are selected. When FAR680 is run to process credit card payments, it will select all payment amounts that are due that do not have a payment status of 'PENDING'. A scheduled payment that is due that has a payment status of INVOICED is still due; if FAR680 can collect the payment by processing the credit card, that's what it will do.
Along with updating the scheduled payments, FAR680 adjusts the deferred receipt transaction amount to the amount still considered due in the future.
For scheduled payments, the FAR680 process is run periodically to reset the deferred receipt amount against an Order_Detail line based on a specific due date. For instance, if the customer has a schedule of $10/month for 12 months and has paid $20 for the first two months and the current date is within that second month, there would be a single deferred receipt transaction for -$100. If you sum FAR_Txn.Base_Amount for that order line, you should return a balance of zero, i.e., the customer does not owe anything at the current time. At the beginning of month three, the process would reset the deferred receipt amount to -$90 to reflect that $10 is now due. If you now sum FAR_Txn.Base_Amount, you will have a balance due of $10. At the same time, the due date for the Order_Detail line is reset to the earliest of any scheduled payment due.
· Order at two months:
o Sales $120
o Receipt ($20)
o Deferred Receipt ($100)
· Due today Balance $0
o Order at three months (after running FAR680)
o Sales $120
o Receipt ($20)
o Deferred Receipt ($90)
o Due today Balance $10
FAR680 performs different tasks to update the schedule payment for processing depending on the type of order the scheduled payment is associated with. The types of orders that FAR680 affects differently (including the associated follow-up batch process needed to complete the transaction) are the following:
· Scheduled Payments with No Automatic Payments (ORD660)
· Fundraising Pledge Payments (CCP610, then FND660)
· Membership Renewal Order Payments (ORD650)
· EFT Payments (EFT680)
· Credit Card Payments (CCP610)
For scheduled payments that are not set up to be automatically paid (for example, exhibitions), running FAR680 completes the following tasks:
· Creates the Notice_Invoice_Date
· Sets the Processing Date on the order line
· Sets the Due Date on the order line
· Decrements the Type 9 deferred receipt transaction by the amount of the scheduled payment.
After you run FAR680, you need to run ORD660 to invoice the scheduled payments due.
Please
be sure to post deferred batches before running this batch process. FAR680
will NOT update the payment status for any scheduled payments where the
receipt was taken with a deferred batch and the batch has not been posted.
For fundraising pledge scheduled payments that are not automatically being paid, running FAR680 completes the following tasks:
· Sets the Processing Dates on the order line
· Creates the Notice_Invoice_Date
After you run FAR680, you need to run CCP610 or EFT680 to pick up any automatic payments, and then FND660 to pick up payments not set up for automatic payment.
When you run the Renewal process (ORD650) on membership renewal orders, the application creates a proforma order and a deferred receipt for a membership order defined to automatically renew by credit card.
After running ORD650, you need to run FAR680 to get the authorization for the deferred receipt.
For EFT payments, running FAR680 completes the following tasks:
· Sets the Processing Date on the order line
· Updates the Type 8 transaction by the amount of the scheduled payment
After running FAR680, you need to run EFT680 to collect the direct debit. If the EFT680 cannot successfully process the direct debit payment successfully, the REJECTED_PAYMENT_FLAG on the scheduled payment is updated to ‘Y’ and the payment status is set to ‘PENDING’.
For selected scheduled payments that are being paid by credit cards, the process sends an authorization request to the credit card processor. If the credit card is authorized, the system performs the following tasks:
· Creates a Far_Txn type 1 receipt (credit card only)
· Creates a Far_Txn_Detail record (credit card only)
· Creates a Far_Receipt record (credit card only)
· Decrements Type 9 deferred receipt transaction by the amount of the scheduled payment
· Updates the scheduled payment with a status of “Paid”
As of 7.6.1, for organizations using Vantiv as their payment handler, FAR680 checks the PROCESS_EXPIRED_CC merchant parameter to determine whether expired credit cards should be selected for processing. If the credit card defined for a payment schedule has expired, if the PROCESS_EXPIRED_CC merchant parameter is set to "N", FAR680 will not select scheduled payments with expired credit cards that are due to be paid. Ccp_Req_Ans.REJECT_REASON will be filled with “Credit card is expired.” Ccp_Req_Ans.ERROR_CODE will be set to 24 for Verisign, 202 for Cybersource, and 305 for Vantiv. If the PROCESS_EXPIRED_CC merchant parameter is set to "Y", FAR680 will transmit credit card payments to Vantiv even if the credit card is expired. When Vantiv returns the authorization request response, if the organization is using Vantiv’s "Account Updater" service, the response file will include the updated credit card expiration date, as well as any other changes that may have been made to the credit card, such as change of name, change of credit card number or change of credit card type.
After running FAR680, you need to run CCP610 to settle the credit card.
If FAR680 is not able to successfully process a credit card scheduled payment successfully, the REJECTED_PAYMENT_FLAG on the scheduled payment is updated to ‘Y’ and the payment status is set to ‘PENDING’. If the receipt cannot be finalized (bad credit card, paper invoice, etc.) when you run FAR680, then the deferred receipt is still updated, resulting in a balance due today for the order.
Payments
which result in an overpayment of the order will check for deferred receipt
transactions and make the appropriate correction.
The FAR680 batch job must be run on a monthly basis to update the deferred receipt based on the schedule. That same job automatically creates credit card receipts if the order was defined to do this and the credit card information exists.
The workflow that appears next walks you through processing scheduled
credit card payments made for pre-shipped product orders. This includes
steps necessary to complete before running FAR680 and what happens after
you run FAR680.
You can find this workflow and similar credit card functionality workflows, such as Shipping INV Products with Deferred Credit Card Payments, in the Credit Card Processing Data Flow Diagrams section.
FAR680
must be run separately for every merchant account.
Parameter |
Description |
Required? |
|---|---|---|
Organization |
The Organization ID for which the report will be run. The system sets this to the organization ID of the logged in user running the batch process. |
Read-only |
Organization Unit |
The Organization Unit ID for which you want to run the report. The system sets this to the organization unit of the logged in user running the batch process. |
Read-only |
Run Mode |
Mode in which the report runs: · EDIT – prints the report. · PROD – prints the report and updates the database tables. |
Yes |
Batch |
If a batch is entered, the system will use this batch to create the receipts. If the Create Batch parameter below is set to ‘N’, this field is required. |
No – if Create Batch = Y Yes – if Create Batch = N |
Process Date |
This date is used to select scheduled payments that have a due date on or before the date selected and that have a payment status of “Pending”. |
Yes |
Create Batch |
Determines whether the process creates a new batch. · Y
– creates a new batch to process the payments into based on the
App_Next_Number naming convention.
· N – does not create a new batch, instead you must enter an existing batch number in the Batch parameter. You may want to use this option as a way to maintain your organization’s naming conventions or designate a batch as being a result of running this process. |
Yes |
Use Vantiv Batch Processing? |
As of 7.6.1, if you are using Vantiv as your credit card processor/payment handler, you have the option to submit credit card pre-authorization transactions in a single batch file instead of individual transactions. If using the batch processing option, you also have the option to activate authorization recycling so that Vantiv can attempt for a period of days (typically 16 for VISA, 28 for all other credit cards) to obtain authorizations for declined transactions. To enable the authorization recycling option, set this parameter to "Y" AND also set the AUTH_RECYCLING_MERCHANT merchant parameter to ''Litle'' for the selected Vantiv payment handler.
If it is set to "Y", then recycling will be activated for all receipts where the Vantiv payment handler record is active. If it is set to "N", or if it is set to "Y" and Vantiv is not being used, then the system will disregard this parameter.
This parameter is ignored if the organization is not using Vantiv as their credit card payment handler. |
Yes |
Advanced Job Parameter |
||
Filter |
Reduces the record selection further based on the SQL statement entered. The filter can be applied on the order_detail table. For example, "order_detail.product_code = 'BOOK' " would select only those orders which are placed for BOOK.
|
Yes |
Orders
that have NOT been paid will display on the report even if you previously
ran FAR680 (e.g., you ran FAR680 on 4/30/2014 and again on 5/31/2014).
The reason for this is so you can easily identify the total balance owed
by the customer to date.
This report displays the records processed where Auto Pay Method = "CC" (i.e., payment received through credit card). It will display records that actually PAID in the FAR680 run and will NOT display already paid records.
As of 7.6.1, this report has been updated to show details about scheduled
payments that have been processed for payment, including details about
the record created for the deferred payment in CCP_Req_Ans. The report
will display "Pending FAR681" next to the Authorization
and Reference fields if those
fields are null. If the fields are not null, the values in the CCP_Req_Ans.CC_AUTHORIZATION
and CCP_Req_Ans.AUTH_REFERENCE fields will display on the report. All
receipts going through authorization recycling will show a value of "Processed"
in the Status field.
This report displays all failed orders. Failure could be due to expired token, data corruption such as missing type 9 transaction, zero due amount or any generic exception in the process.
This report displays all orders with payment schedule and Auto Pay Method
is either "NULL" or "NONE".
This report displays the same orders from FAR680_Manual_Invoice for which type 9 was updated. Action depends on the error reported. Some may need data correction or token update, etc.
