For more information, please see CCP610 - Credit Card Settlement.All the reports should be run separately in each org unit on a daily basis.
For more information, please see CCP610 - Credit Card Settlement.
1. Personify recommends that this process be scheduled to run overnight. However, it is important for someone to review the report the next day to make sure that there are no errors. For more information, please see Scheduling a Report Job.
a. Alternative: run this process immediately before your credit card processing network settles (e.g., ten minutes).
i. This is the best option for cash flow.
ii. In this manner, most of the transactions for the day will settle on the same day. This includes the daily back office batches, as well as those transactions received via the web.
b. Alternative: run this process at 11:50 P.M.
i. This is the best option for cash reconciliation.
ii. In this manner, the maximum number of transactions for the same day will settle between Personify360 and VeriSign. However, these transactions will settle within the processing network a day later unless the processing network settles at midnight.
2. Personify recommends that the Process Deferred Payments parameter be set to "Y" to hold the receipts for inventoried products that are created after shipping and paid via credit card.
a. This parameter will automatically create a batch for the inventoried product receipts. You won’t need to create or post a batch every day, nor enter the batch ID as a parameter on this process. The system will take care of this for you.
b. Alternative: create the batch to hold receipts for inventoried products that will be created after shipping for the CCP610 process.
i. If you do shipping on a daily basis, perform this step every day.
ii. Create a deferred batch.
iii. Set up all the possible credit card receipt types on the batch.
iv. The batch date should be the current date.
v. It is not necessary to enter the control count and amount at this point.
vi. Each morning, post the deferred credit card batch that was created for the previous day’s run of CCP610. Before posting, update the control count and amount with the actual count and amount values.
3. When this process is run, the credit card is actually charged and Personify360 assigns a settlement number. The settlement number format is month, day, year. If the process is run more than once a day, the same settlement number is assigned.
4. The report produced by this process may display the following two types of errors:
· Red Errors: these indicate there was an issue with the card or with VeriSign and need to be addressed in order for the payments to settle. If this type of error keeps appearing on the report even though the transaction has settled, notify your Personify representative because it may need to be deleted from the back-end.
· Warning Errors: these display at the bottom of the report and occur because there is an authorization but the receipt doesn’t exist in Personify360. This would be due to a receipt reversal to void the charge. Review this to make sure there should have been a receipt reversal. Nothing else needs to be done for this type of error. If you see this error for any other reason, notify your Personify representative.
For more information, please see CCP504 - Credit Card Transaction Analysis and FAR505 - GL Account Summary.
1. Run the Credit Card Transaction Analysis report, CCP504.
a. Enter the previous day’s date in both the begin and end date parameters.
b. Enter settlement date as the primary break.
c. Enter batch as the secondary break.
d. If you have multiple merchants, enter merchant as the primary break and move the other breaks one level down.
e. Enter the following filter: 1=1 AND CCP_REQ_ANS_INFO_VW.REQ_TYPE_CODE <> 'PRE-AUTH'
f. The report will print in sequence by the settlement date and by batch within settlement date.
2. All payments on the report should have a status of SALE.
a. If any payments have a pre-sale status, the payment did not settle. If this is the case, research why it did not settle.
b. If you choose to run the settlement process in the manner that is best for cash flow rather than reconciliation, there may be web transactions that came in after settlement and before midnight that did not settle. If this is the case, make sure those transactions are taken into account.
c. If you choose to run the settlement process in the manner that is best for cash reconciliation, everything from the previous day should have settled.
d. It is possible that there was an error in red (see above section) and that is the reason a payment did not settle. Check your VeriSign user's guide if you need more information on the error.
3. Run the GL account summary, FAR505.
a. Enter the previous day’s date in both the begin and end date parameters.
b. Enter txn date as the primary break.
c. Enter batch as the secondary break.
d. If you have unique accounts that are used for credit cards only, enter the following filter: far_txn_detail.account in ('CREDIT CARD ACCOUNT NUMBER 1', 'CREDIT CARD ACCOUNT NUMBER 2'). Enter all the credit card accounts that you have regardless of the type of card.
e. If you use the same cash account for credit cards as well as other types of payment (e.g., checks, cash, etc.), enter the following filter: far_txn_detail.account in ('CREDIT CARD ACCOUNT NUMBER 1', 'CREDIT CARD ACCOUNT NUMBER 2') and exists (select 'a' from far_receipt (NOLOCK) where far_txn.receipt_no = far_receipt.receipt_no and far_receipt.receipt_type_code in ('CC RECEIPT TYPE 1',’CC RECEIPT TYPE 2’)). Enter all the credit card accounts and receipt types that you have regardless of the type of card.
f. This report will print in sequence by the receipt date and by batch within receipt date.
4. The batch on both reports refers to the same batch ID.
5. However, the date on both reports refers to different date fields. If procedures are being followed, these dates should be the same.
a. When a credit card payment is entered, it goes into two queues, the receipt queue and the credit card queue.
i. Credit cards in the credit card queue are settled using the current date regardless of the batch status or the batch date.
b. CCP504 refers to the settlement date.
c. FAR505 refers to the receipt date, which matches the batch date.
6. Match the FAR505 report for each day to the same day on the CCP504 report.
7. If the total for a day does not match, match the batches for that day to determine which batch has the discrepancy.
8. The typical reason for a mismatch is that a credit card payment was entered in a previous day’s batch.
This process will typically be run on a daily basis. Please see LCK100 - Lockbox Batch Upload Control Report for information.
1. How lockbox payments are processed depends upon the lockbox parameters setup. This section assumes that only the following checkboxes are checked:
· Auto Create Batch
· Create Unapplied Receipt
2. A file and the accompanying paperwork will be received from the bank one or more days after the money has been deposited. The number of days will depend upon your bank’s policy.
3. Upload the file onto your network. It might be a good idea to include the date in the file name.
4. Run the lockbox process: LCK100_A. It is recommended that the Finance department runs this process because the deposit date must be entered as a parameter.
a. From the Job Submission screen, open the LCK100_A process.
b. Click the Upload Input File task and enter the path where the file exists.
This will automatically put this file in the proper area to run the process.
c. Enter the bank deposit date as the batch date parameter.
d. Enter the input file name.
5. The process will automatically create a batch for the receipts on the file. It will figure out the control count and control amount based on the receipts on the file.
6. Running this process in List mode is similar to running other processes in Edit mode. It puts the data into the lockbox holding table, creates the batch, and produces a report, but receipts will not be created until the transactions are posted.
7. The process will apply the money to each line in the order up to the line amount according to priority or line number if all priorities are the same.
8. Review the report.
9. If there are no errors on the report:
a. Skip Lockbox Error Correction section.
b. Run the process in Post mode.
10. If there are errors on the report:
a. Email the report to the staff member who will be correcting them.
i. This will notify the person that the process has been completed and is ready for him/her to correct the errors.
ii. The person performing the corrections will typically be someone in Customer Service or in the department for which the payments are being received. The person would need to know how to enter orders for payments.
1. Search for the batch on the Lockbox Processing and Error Correction screen and filter for errors only.
a. Based on the error message, consult the paperwork from the bank to perform the corrections.
One example of an error is a missing order number and customer number. The member might not have returned the proper paperwork with the payment, and, therefore, the order and customer number might be missing.
i. In this case, look up the customer by name.
ii. Find the relevant order, probably the latest membership order.
iii. Enter the order number on the Lockbox Processing and Error Correction screen.
iv. If there is no order and/or you are not sure to what order to apply the money, create an unapplied receipt for this payment.
v. If the customer is not in the system, create a customer based on the name and address on the copy of the check.
2. After all corrections are performed:
a. Re-query for all transactions in the batch.
b. Click on select all rows.
c. Select the Post Transactions task.
This is not the same as posting the batch. The Post Transactions task creates unposted receipts.
1. When the scheduled payments feature of Personify360 is used, FAR680 needs to be run on a periodic basis. How often will depend upon the policy for due dates.
2. This feature also includes charging someone’s credit card on a periodic basis (e.g., membership renewals).
See Also:
· Overview: Accounting Best Practices
· Weekly Financial Reporting Best Practices
· Financial Data Entry Best Practices
· Batch Creation Best Practices