List the three possible outcomes when a transaction is presented for posting
Normal posting, rejected, ware housed for x days for later posting
List the five parts of a transaction record that are usually necessary for normal posting
Account nbr,tran code,credit plan,amount,store number
Explain how Active/Inactive Processing affects the posting of transactions
Have an internal status of D (dormant) for the number of months defined in INACTIVE
MONTHS on ARML13.
Have a current balance of zero
Not be in collections
Have no insurance
Have no plan segments
Have no outstanding authorizations.
Explain how account close and purge parameters affect the posting of transactions
To maintain the efficiency of CMS, you can close and purge accounts that you no
longer need to track or maintain. In CMS, you can close an account manually, or you can
specify parameters for CMS to close accounts automatically
Account Auto Close Months, Account auto Purge Months,
Explain how plan segment purging affects the posting of transactions
CMS enables you to purge credit plan segments that have no activity on the
account.
PLAN PURGE DAYS
Explain how Logo record transaction controls affect the posting of transactions
CMS provides two billing methods at the organization level: demand and call cycle.
Demand Billing produces the statement as if the day you produce it was the actual
billing cycle date. Any transactions posted through the statement date will be
included on the statement, regardless of the actual billing cycle date.
Call Cycle Billing produces the statement as of the billing cycle date but allows you
to physically produce the statement a number of days later than the account’s
established billing cycle date. This feature will allow transactions to be posted to the
customer’s account after the billing cycle date passes.
Any transaction with an effective date between the billing cycle date and the call cycle date can
be posted, rejected or warehoused based on the TRANSACTION CONTROL on page 12 of the Logo
record
Explain how block codes affect the posting of transactions
Block Code on LOGO07,08 SCREENS that determines how
CMS posts transactions to accounts assigned this block code
(including charged-off accounts). The values are:
0 = Post normally (Default)
1 = Post normally and report
2 = Non-post all transactions
3 = Non-post all transactions and report on the
Transactions by Block Code report (004)
4 = Non-post debits and report
5 = Non-post debits.
POSTING OVERVIEW - ONLINE
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 –ENTIRE BATCH REJECTION, INDIVIDUAL TRANSACTION REJECTION
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.
CMS – Every program opens a data file, the program verifies file integrity. The program reads the first
record of the file to ensure that it is a header record and the date and time stamps match those of the
System Control (AMCR) file
AMCR SYSTEM CONTROL FILE ARD100
ARD100 Sort Transactions to Posting The program then reads the records in the ATNS and ATVT files and
passes the records to the sort file. The output procedure of the program writes the records to the ATPT
and ATUC files. The program then closes the files and terminates processing
ATNS New Sales Transactions
ATVT Various Transaction
ATPT Posted Transactions
ATUC Update Billing Cycle
ARD140
ATPT Posted Transactions ATUC Update Billing Cycle -INPUT
AMRT Rate Table I VSAM AMSC Secured A
AMSP Frequent Shopper Program
ATBT Balance Transfer
ATGT Generated Transactions
ATSM Statement Master Transactions
debug tracking feature - debug tracking feature ARD140 can perform an entry/exit program that traces
progress during execution and provides the ability to track errors if the program abends. This entry/exit
program, called the debug tracking feature, is optional and must be activated in the System record
(POSTING PROGRAM DEBUG on ARMS01). If the tracking feature is active, ARD140 will use additional
CPU time to execute Move statements in D140-Z9999-PARA-ENTRY and D140-Z9999-PARA-EXIT, which
are executed in all paragraphs in ARD140. If the tracking feature is not active, CPU time is decreased and
the trace option in ARD140 is not provided. If the debug tracking feature is active and ARD140 abends,
select the DUMP dataset from the output listing. From the command line, find “+++” (plus symbols) to
locate the paragraph in which ARD140 abended and a brief trace of the paragraphs that executed prior
to the abend. In copybook AR40WS, WS-D140-PPC-PGM-ID identifies the copybook in which the abend
occurred, WS-D140-PPC-PARA-ID identifies the paragraph within that copybook, and WS-D140-2-20
identifies the paragraphs executed prior to the abend.
