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.