Transaction Posting

Posting Overview

Monetary transactions that are not system-generated enter CMS in batches either through online functions or through user input tapes and transmissions.  Online sources of monetary batches include:

• The Monetary Batch Transactions screens (ARAT) or the Payment Transaction Entry screens (ARAP). ARAT accepts all types of transactions, including payments.  ARAP accepts only global payments (transactions linked to Logic Module 30).  These functions have maintenance modes (ARMT and ARMP) which allow you to modify batches.
• The Frequent Shopper Points entry screens (ARAH). Although points transactions do not affect account balances, they are treated as a sub-category of monetary transactions.
• The Account Services Management system (ASM). As customer service representatives enter Monetary and Points actions through the ASM Work screen (ASMW), the system automatically organizes them into batches that are later passed to CMS for posting.

When a transaction is presented for posting to a cardholder account, there can be one of three possible outcomes.  The transaction will be:

• Posted immediately in the day’s batch processing
• Non-posted (rejected)
• Warehoused for posting on a later processing day.

The particular action taken by CMS (post, reject, or warehouse) depends in large part on transaction posting parameters that you establish in the control records.

Batch Processing

A batch of transactions consists of a batch header record and the batch detail (contents).  The header record contains the batch number, the sum total of all transactions in the batch, and the debit and credit amounts that are included in the batch.  The contents are the records of the individual transactions.

• During batch processing, the system checks the contents of each batch against the batch’s header record.
• A completed batch is a batch that was properly closed at its source. An in-balance batch is one whose contents and header match.
• When a batch is both complete (closed) and in balance, the system takes one transaction at a time and attempts to post it.

 

 

Normal Posting

In most circumstances, there are five parts of a transaction record that must be present and correct for normal posting to occur:

• Account number
• Transaction code
• Amount of the transaction
• Credit plan number
• Store number.

An exception to this rule is a global payment on an account.  Because a global payment is not directed to a particular credit plan segment on the account, CMS will accept it without a plan number or a store number.

If the transaction is complete and correct and the account has no condition on it to prevent posting, the transaction will post.  When it posts, the transaction leaves the batch.  Transactions that are rejected remain in the batch, which then becomes a reject batch.

Non-Posting

Any batches or transactions that are not posted or warehoused are considered rejected and are placed in the Reject/Reentry file.  CMS provides the Reject/Reentry file to enable you to adjust an entire rejected batch or individual rejected transactions.

CMS will reject an entire batch if:

• The batch is incomplete
• The batch is out of balance.

If a batch was not properly closed at its source, CMS rejects it as incomplete.  The entire batch is placed in the Reject/Reentry file.  The batch will not post until you close it online using the ARMT function.

If a batch’s header and contents do not match, the system rejects the batch as out-of-balance.  The entire batch is placed in the Reject/Reentry file.  The batch will not post until you reopen it using the online Batch Control function (ARBC) and balance it using ARMT.  Balancing is accomplished by modifying the header and/or contents so that they match each other, then closing the batch again.

CMS will reject an individual transaction if:

• The transaction is incomplete (missing information needed for normal posting) or incorrect (contains invalid information)
• A condition on the account prevents normal posting.

 

Example 1:  A sale transaction has no credit plan number on it.  CMS rejects the transaction because it is missing information needed for normal posting.

Example 2:  The account number is not on file.  CMS rejects the transaction because it contains invalid information.

Example 3:  A credit balance refund transaction is in an amount greater than the actual credit balance on the account.  CMS rejects the transaction because of a condition on the account.

Those rejected transactions that contain correctable errors can be modified online using the ARMT function.  Once a rejected transaction has been corrected, CMS will automatically resubmit it for posting.  It is not necessary to manually reenter the transaction.

Those rejected transactions that cannot be corrected can be purged online using transaction codes that evoke special logic modules (Logic Module 88 to purge a non-post debit and Logic Module 89 to purge a non-post credit).

You can use the control record posting parameters covered in this section to force transactions to reject in a variety of circumstances.

Warehousing

Based on control record posting parameters and the current date, CMS may withhold certain transactions from posting until some later date.  Warehousing routinely occurs when an institution uses Active/Inactive Processing or Call Cycle Billing.  Warehoused transactions do not require any online correction.