Deferred Posting

Deferred posting batches are used for payments that are mailed or faxed to an organization. They are also used to audit order payments prior to posting the payment activity to the general ledger. Using control amounts and control counts, the system verifies that the amount of a deposit is actually the amount entered in the system. The control count is the number of checks in a deposit and the control amount is the total amount of those checks.

The batch of receipts can be posted and made official when the user validates that the correct number of receipts have been entered and the total of those receipts matches what is referenced in the deposit. The counts and amounts of orders paid are updated in the Batch Control Receipts table. Receipts associated with a deferred batch are applied via the Receipt Entry (FAR002) or Quick Pay (FAR011) screens. Payments to proforma orders made via a deferred batch are made active once the batch is posted.

When all of the payments contained in a deferred batch have been entered, the batch can be posted.  Posting a deferred batch is much more complex than finalizing a direct batch.  Also, unlike a direct batch, a deferred batch cannot be posted until the Control Count matches the Calculated Count, and the Control Amount matches the Calculated Amount.   

When a deferred batch is posted:

·       The batch status is set to posted, and the post date is updated Proforma orders in the batch to which payments were applied are activated, and detail transaction records are created.

·       The posting process may also set some INV orders to backordered, if available inventory for a product has been exceeded, and may set some meeting registration orders to waitlisted, if the available capacity for the meeting product has been exceeded.

·       Transactions and receipts are marked as posted.

Direct Posting

Users, such as the customer service representative answering the phone, enter the receipt immediately with no requirement for later posting of the batch. Transactions within direct batches are posted one at a time as they are created. They are also finalized by the user so that they can not be inadvertently used again for data entry. These batches do not require a control count or a control amount.   The counts and amounts of orders paid are updated in the Batch Control Receipts table. Proforma orders are made active once the cash is applied. Receipts associated with a direct batch are applied via the Receipt Entry (FAR002) or Quick Pay (FAR011) screens. You still need to close the batch by clicking Finalize Direct Batch.

A direct-posting batch does not need to go through a “posting” process, because transactions are already real to the system, and their posting flag is set to ‘Y’. A direct batch can be finalized without the need for control counts and amounts having to match actual counts and amounts. Finalizing a direct-posting batch simply makes it impossible for someone to use the batch again. When a direct-posting batch is finalized, the system simply changes the status of the batch to “Posted”, but none of the other processing that takes place when a deferred batch is posted is executed.

Adjustment

Captures the creation of order adjustments within a batch control environment and controls the date of the adjustments created while the adjustment batch is open. For example, to adjust orders and have the transactions show in last month’s books, you would create an adjustment batch with a date in the previous month. Transactions created while the batch is open will take on the date of the batch rather than the current date. Adjustment batches are direct-posting, meaning there is no posting process. While optional, associating batch numbers and dates with adjustment and refund transactions provides an effective audit trail and reporting mechanism. As of Personify360 7.5.0, if an adjustment batch is opened with a date which is less than receipt date, the system will prompt the user to close the adjustment batch before the system can create a refund predating the receipt date.

 The adjustment cannot precede the sales transaction.

E-Commerce

This receipt batch is used only by the Personify360 e-Commerce system, which includes credit card transactions captured for Web orders. All transactions created are posted immediately on credit card authorization, though credit card transactions go through a settlement process.

It is recommended that you do NOT set up an e-commerce batch with more than one receipt type per cart type (i.e.,  there should only be ONE Visa, ONE Mastercard, ONE Discover, etc.). While the system does not prevent you from doing so, this could be confusing to an online user who might not know which card type to choose.

Please keep in mind the following:

·       If the association and foundation are set up as financial companies, then you should set up their e-commerce batch to include a receipt type for only one of the financial companies. When receipts come in, the system can automatically leverage due-to/due-from setups to distribute receipts to another financial company(s) as appropriate.

·       If the association and foundation are set up as org units, then your websites MUST be distinct – so this is not an issue. The batches that support each website are also distinct, so there is no danger of overlapping receipt/card types.

·       If the association and foundation are set up as organizations, then again your websites MUST be distinct, and there is no danger of overlap.

If an e-Commerce batch is open in the back office and an order is created while that batch is open, the batch will not be written to the order or order line. This is because e-Commerce batches are specifically for Web orders.

EFT

Electronic Funds Transfer (EFT) transactions are posted directly after validation. The files, along with the EFT680 batch process, validate the information. This batch CANNOT be used to enter payments through any of the back office payment screens (e.g., FAR002, ORD001).

Lockbox

These batches are a mixture of direct and indirect batches, meaning they can have some transactions posted while others are not. The lockbox processing posts all transactions that clear validation and then allow the user to correct the remaining transactions necessary prior to posting. If the input option on Lockbox Batch Upload (LCK100) is “Table,” then a lockbox batch must be created before running the report.

Rapid Deferred

Batches defined as “rapid” are used to facilitate quick order entry when the order number associated with the receipt (payment) is known. Receipts associated with these batches are applied using the Rapid Receipt Entry (FAR010) screen. Proforma orders are made active once the batch is posted.

Rapid Direct

Batches defined as “rapid” are used to facilitate quick order entry when the order number associated with the receipt (payment) is known. Receipts associated with these batches are applied using the Rapid Receipt Entry (FAR010) screen. Proforma orders are made active once the screen is saved.

Refund

This type of batch deals with refund transactions and creates a specific transaction date for the refund. Refund batches do not allow entry of receipts or adjustments, but they do allow the use of the Refund Control (FAR003A) screen.