Transaction Processing

 
After the data has been processed, as discussed above in a transaction, the next step is to process
transaction itself on certain lines.  A transaction is processed with reference to business rules, i.e., a
transaction are scrutinized for conformance to the rules, policy or guidelines before it is taken up for
further processing. The rules may be directly related to the transaction or it may have some relation and
association with other transactions.  In any case, if the transaction does not conform to the set of
specified conditions governed by the rules the error is displayed for user to take corrective action.
 
The transaction is processed for adherence to business rules, correctness and consistency of data values
and for validity of transaction for acceptance.  It should be noted that these three aspects are applicable
to all the transaction for acceptance.  It should be noted that these three aspects are applicable to all the
transactions across the business management functions.
 
Let us take an example of the goods receipt as a transaction.  Having checked the individual data entities,
the goods receipt transaction is subjected to further checks for acceptance and execution. The business
rules in case of this transaction are:
 
The purchase order must be present and open and the item received should be present on Purchase
Order. Further, the receipt is as per the schedule date.
 
The supplier has sent the necessary supporting documents such as Excise Gate Pass, Octroi Challan,
Sales Tax Form, Certification by Third Party, etc.
 
Such other conditions that may be applicable.
 
One can add more business rules if necessary.  However, if the receipt transaction is to be processed, it
will first be processed for confirmation and conformance of these rules before it is taken to the next stage.
The rules are checked at the entry level processing after the individual data fields are checked.
 
The next check in transaction processing is to confirm internal consistency, correctness and
completeness of the data. In our example of receipt transaction, a consistency should be confirmed
between the quantity sent, the quantity received, the quantity accepted, and the quantity rejected.
 
The third check after confirming the data quality and observance of the business rules is for validity of the
transaction itself for its use in application and system processing. The validity of the transaction is
checked against the conditions present outside the domain of the transaction. For example, the
transaction of the Fixed Deposit might go through all checks at the data level and at the transaction level,
it is not acceptable as the tool deposit permitted is already received.  Hence, though the transaction is in
order but cannot be posted as it ceases to be valid at the Fixed Deposit application level.