The idea of mapping arises because of the modular nature of information system designed for businesses. And the reason why the design concept is modular is to simplify the interconnected process by segregating the process to manageable logical portions and ease the programming required behind the system. It is also to isolate any bugs in the programming during debugging process.
The critical factor in modular design for a system is the integrity of the system as a whole which must be assured. Data passed from on module to another must be intact and as expected. If this is not happening, then the integrity of the whole system is suspect. When integrity is suspect, then the system is inevitably a failure since reliability and accuracy cannot be assured. Factors which are important in a business information system.
Since the modular concept requires data to be inputted only once in a particular module, the source data represents the details captured in the said module. Once the data is captured in detail, there is no necessity for the same detailed data to be passed on to another module. Very seldom in system design that this is done.
Details are maintained in one module. Summary of the details that has been pre-defined and mapped to the corresponding detailed data is maintained in another module. By the process called “drill-down”, the clicking on the summary data will bring the user to the detailed data and displayed on-screen by the system.
Imagine a module that maintains the details on inventory. The list of inventory names, quantity-in-hand, unit cost, etc. is managed here. When quantity is added from purchases or manufacturing, the source data on the details is captured in the inventory module. This inventory process will subsequently trigger an accounting entry in the accounting module. The summary is captured in the accounting module on the total inventory added. This is reflected by the increase in the monetary value of the Inventory Account balance.
If there is no “mapping” established, then each and every item in the inventory module will have a corresponding account created in the accounting module. So, if there are, say, 300 inventory items then there will be 300 corresponding accounts for inventory in the accounting module. This is wasteful and cumbersome to manage. A better way to manage is to “map” the items in the inventory module to a particular accounts code in the accounting module. Hence the whole list of 300 products could be map to say, 3 or 4 accounts codes; depending on the requirements of the business. This will be a much more elegant and cleaner method to manage the situation.
Thus, when details of the data are transferred to the other module, the other module will capture and reflect summary balances only. The data transfer can either be performed automatically or manually; depending on the system data flows.
An example is illustrated as below:
Let’s say that there are nine (9) product codes in the inventory module. The details such as description, stock balance, price and unit cost are managed in this Inventory Module. These nine items are “mapped” to one accounts code in the Accounting Module, i.e. to “Inventory – Fashion Products”.
Suppose that there is an Inventory-In transaction where finished items are received from Manufacturing. The details are recorded in the Inventory Module to the corresponding product. In this instance, only three items are manufactured and hence three amounts are recorded (i.e. the details) with total amount of RM1,750. When these transactions are imported into Accounting Module, the total recorded in the accounts code for “Inventory – Fashion Products” is RM1,750 (i.e. in summary); without identifying the details.
The “import” process when triggered can be performed automatically or manually. An automatic process is preferred when importing the data to another module. Nonetheless, a manual process for “import” will do just fine so long the correct accounts codes are identified.
With this arrangement, the details are in Inventory Module. The accounts code in the Chart of Accounts will then not unnecessarily be a long and cumbersome list. Other “mapping” can also be performed subject to the capability of the business information system.
Finally, note that the “mapping” in the example above is known as “many-to-one” relationship. Other types of relationships are one-to-one relationship, one-to-many relationship and many-to-many relationship.
Please be informed that we shall be conducting our monthly seminar for SME entrepreneurs on enhancing Accounting and Finance knowledge and skills on the 18 April 2017 at Bangi Gateway. Interested business owners and guests are welcome to attend and participate in this sharing session.