Database Design for Invoicing using REA Data Model

In the contemporary business environment, the accounting profession has undergone a fundamental change, and the traditional accounting systems are no longer adequate to satisfy a recent accounting domain. Thus, a call has been made to expand the scope of accounting information systems. In response to the call, the REA data model was launched to support the accounting information systems. The REA data model is identified as the conceptual modeling tool that assists in designing the AIS (accounting information system) database.

The REA model is specifically good to develop an invoicing and billing process. The objective of this project is to use the REA data model to develop the database for the billing and invoicing process. Entity Relation Diagram The entity relation diagram is required for the database of the billing and invoicing process. The entity relation diagram is a graphical illustration to portray the database schema. The ER diagrams show the entities and the relationships between the entities. Typically, ER diagram depicts the content of the database.

However, the REA data modeling is defined as the process to define the database to represent all aspects of business organization, which include the business transactions with the external environment. Thus, the REA identifies the entities to be included in the AIS database and the relationship between the entities. The fig reveals the entity relation diagram for the for the billing and invoicing process As being revealed in Fig 1, the customer sends the order, after the customer has paid, the invoice is issued to the customer.

The company sends the order to supplier and supplier invoice is issued after the payment. Fig 1: ER Diagram for Billing and Invoicing Process REA Database Design for Billing and Invoicing Process The following process is used to design the REA database for the billing and invoicing process. The first step is to identify the entities for the billing and invoicing process. Entities • Salesperson • Customer. In this process, the event is the sale events that involves taking customer orders.

The study uses the hypothetical example of New York Merchant to demonstrate sales processing leading to billing and invoicing process. There are two events to complete the transaction. The first is A SALE event. The second event is DELIVER ORDER for the economic event. The additional business event is TAKE CUSTOMER ORDER showing that employee must committee these two economic events in the future. It is a promise that the New York Merchant must fulfill to the customer.

To complete the CUSTOMER orders the SILK, the CUSTOMER should provide some cash for a unit of SILK. While taking the CUSTOMER ORDER, there is no increase or decrease of resources, and it does not involve an economic event. After the order is placed, the new information will be passed to the management to evaluate and monitor the operation. The diagram in Fig 2 provides the logical flow diagram of the events. The next business event is to CALL ON CUSTOMER.

The event is carried out by the SALESPERSON who makes a call and after the agreement is reached, the SALESPERSON issued a billing, after the CUSTOMER has paid for the item, the INVOICE is issued, and the cash receipt is issued to the CUSTOMER after the CUSTOMER has paid. Fig 2: Logical Flow Diagram of Process Fig 3 reveals the database for the order and cash receipt system showing the strategy that the database employs in processing the transactions.

As being revealed in Fig 3, the customer orders through the terminal, and the customer table is formed. The system checks the customer order in the inventory to examine whether the order is available in the inventory.