Enhancing knowledge integration with REA modeling in an AIS project.
The ability to document information systems and process mapping are important skills, and are critical to understanding the accounting system and its controls. In this project, students use the REA modeling approach to construct an extended ER model for supporting the core business activities of DataTech, a hypothetical small-sized enterprise in Ireland. The purpose of the project is to further student understanding of accounting and information technology (IT) concepts and illustrate how these concepts can be applied in practice; to connect the IT theory and skills with enterprise practices of today. These skills include: data organization, storage, analysis, presentation, and the safeguarding of accounting data, in addition to business processes and system design issues. The project described below is more comprehensive than many currently available as end of chapter exercises and projects described in Accounting Information Systems (AIS) textbooks, such as Romney and Steinbart 2012; Gelinas, Dull, and Wheeler 2012; Bagranoff, Simkin, and Norman 2010; and Kay and Ovlia 2012.
The project requires students to integrate two business processes, sales and purchase. It also requires students to combine the theory underlying the business processes with database creation and accounting applications. Students create a model based on business needs, use the model to create a workable database, and use the database to answer management questions. The project has been piloted tested over the course of three semesters and modifications made based on student feedback and instructor assessments and experience. Typically the project is completed by small groups of students (ideally three) but it can also be completed individually.
Acting as accounting consultants, students design, create, and populate a database system so that the company can better track and analyze its growing number of clients, agents, transactions and contracts. Students are given basic information about the company and its operations and what information management would like to see in order to more effectively manage its operations. Based on this information, students must determine what information to capture in the database, and design a schema for this purpose. To accomplish this, students need to use a different approach from the more familiar, historical double-entry system of capturing accounting information in journals and ledgers. Employing an entity-relationship (E-R) approach, students use the REA model to capture and store complex events in a robust model that will serve as a blueprint for a relational database.
2. REA MODELING
The REA framework, first introduced by McCarthy in 1982, is based on accounting theory, including Sorter's (1969) work on events accounting, and on database theory, including Chen's (1976) work on entity-relationship databases. Complex systems often cannot be understood in their entirety so a model is a useful tool for minimizing this complexity. Models are built so that the system being developed can be better understood. In essence, a model is a simplification of reality, an "abstraction." Every model can be expressed at different levels of precision (abstraction). The reality of most (perhaps all) enterprises conforms to the same pattern at the business process level. A business process is a series of activities that accomplish the business objective of adding value to input resources. The term transaction cycle is often used interchangeably with business process. The commonly interconnected business processes are financing, acquisition/payment, human resources, conversion (manufacturing), and sales/collection (Dunn et al. 2005).
At the value chain level, the REA model shows the interconnection of the business processes in an enterprise and the resource flow between them. McCarthy (2003) described the semantic modeling of accounting phenomena where each economic event in each transaction cycle corresponds to a resource inflow or outflow. The resulting REA diagram can then be used to understand database design by identifying which entities should be included in the AIS database and prescribing how to structure relationships among them. Recent studies have shown that the REA modeling approach results in a more accurate understanding of the business processes and policies as users are better able to recognize the model's core pattern of enterprise information in the diagram (Poels et. al., 2011). Additionally, companies that purchase rather than develop software in-house still follow the systems development life cycle (SDLC) process. An important aspect of the SDLC is determining AIS requirements and whether or not software that meets these requirements is commercially available in the marketplace.
The REA model captures the interaction of economic resources, economic events and economic agents. Accordingly, there are three main entity types in the REA ontology: Resources, Events, and Agents. A resource has economic value to the enterprise, such as inventory, cash, or other assets. An agent is a person or organization involved in events and can include a vendor, employee, or customer. Events can be classified into three types: economic events, business events, and information events. Economic events are those which change the quantity of a resource, such as sale and cash receipt. Business events are additional events that provide the organization with new information which management can use to better plan, monitor, and control the economic events. For example, placing a purchase order is a business event because it provides management with new information: goods are scheduled for receipt, and prices are negotiated. Information events are processes that are performed solely to capture or communicate information about the business and economic events. These include activities such as generating an invoice, printing an accounts receivable aging report, and displaying customer history. Economic events encompass three main relationship types: duality (D), stockflow (sf), and participation (P). A duality relationship is a causal relationship between two economic events, a Give and a Get Event, or an Event-Event relationship. Stockflow is a relationship between an Event and a Resource depicting either an inflow or outflow of a resource. A participation relationship is between an Event and an Agent, where an agent is either an internal or an external agent. Figure 1 illustrates the REA model in its most basic configuration from the perspective of the business entrepreneur (McCarthy 2003). Besides duality, business events include three more relationship types: fulfillment, commitment, and proposition.
[FIGURE 1 OMITTED]
In short, the REA model is a pattern for business processes that answers the what, the when, the who, and the why (duality + stockflow = value chain) questions about an accounting transaction. This is accomplished through a series of business events that move a transaction through to completion. Greets and McCarthy (1997) describe duality relationships as the glue that binds a firm's separate economic events together into rational economic processes, and stock-flow relationships as weaving these processes together into an enterprise economic chain.
The primary difference between an E-R diagram and a REA is how entities are defined. In an E-R diagram entities are business objects or events. In REA, entities can be resources, events, or agents. The business object in the E-R diagram is basically subcategorized in the REA model as either a resource or agent. An event is the same as under the E-R modeling. Like E-R models, the database components included in REA modeling are entities, relationships, attributes, and cardinalities. Cardinalities are assigned to represent business rules. The basic REA business process level model can be extended to include commitments and types, and relationships involving those commitments. Typification relationships can link resources, events, agents, and commitments to "entity-types". This is needed when attributes of category level entities need to be stored. Both REA and ER diagrams should result in the same number of entities and relationships.
2.1 Converting Conceptual Data Model to Relational Database
To create well-behaved database tables, students must consider entities, relationships, conversion rules for cardinalities, and the "one fact-one place" rule as follows: 1) for each entity in the REA model, create a separate table with an entity identifier field called a primary key (pk) which uniquely identifies each record, and 2) for each relationship in the REA model, determine whether a separate bridge table requiring a composite primary key (cpk) should be created or whether the relationship be represented with a foreign key. A foreign key (fk) is a field in a table that matches a primary key in another table and is used to cross-reference tables. Redundancy and Load (percentage of non-null values in a foreign key column), and cardinalities are key factors in this determination.
3. PROJECT DESCRIPTION
You have been asked to design and implement a relational database application for DataTech's sales/collection and purchase/payment subsystems, based on the following narrative.
3.1 Company Background
DataTech is an IT consultancy business based in Dublin, Ireland. The company provides IT solutions to small and medium size enterprises (SME) throughout Ireland. IT consulting has seen huge growth in recent years due to an increased demand among companies in the SME sector to modernize their operations. From a single owner/employee in early 2009, DataTech has grown to a current staffing level of 15. It now looks to upgrade its accounting information system.
3.2 Current System
DataTech's management originally implemented a flat-file MS-Excel based information system. While this system met the requirements of the nascent operation, it has become inadequate to effectively track and analyze the company's growing number of agents and transactions, with limited relationships between separate worksheets. Additionally, when entering data, the current spreadsheet system is prone to human error that may stem from insert, delete, or update anomalies.
3.3 DataTech's Basic Operating Procedures
A detailed examination of DataTech's business processes is essential for gaining a better understanding of what a new system would require. This project focuses on two such processes: the sales/collection process and the purchase/payment process.
3.3.1 Sales Cycle: The sales and collection cycle contains activities designed to market and sell IT solutions (product and service), as well as collect on these sales. Therefore, it contains activities involved in marketing and sales, sale transaction processing, delivery of product, collection of payments, and the processing of returned product (if any). The key economic goals of these activities are to maximize sales revenues and the cash flow generated by the collection of sales revenues.
In order to align the company's proposed IT solutions seamlessly with the business objectives of its customers; DataTech must first gain an understanding of the IT requirements of each customer. To that end, prospective customers are afforded a complementary consultation by one of the company's three IT Consultants. The consultation is the first point of contact between a customer and DataTech. The Consultant's task is to impress upon the client the wide range and superior quality of DataTech's products. Consultants are encouraged to discuss a wide range of options at any given consultation, before recommending specific products based on the observed needs of the customer. Consultants are tasked with obtaining customer information at this initial consultation. This information includes a contact person and credit limit, as well as standard company information. Consultants are also expected to record the different products which are recommended at each consultation. Quantities of each item are not discussed at this point. Not all consultations necessarily relate to new customers, as some customers require more than one consultation before committing to placing an order. However, only final consultations are linked to the culminating orders. When a customer decides to place an order, they do so by contacting one of DataTech's five Sales Assistants, whose main responsibility is to receive an order and ensure that it is dispatched correctly and efficiently. Once a customer places an order, it is recorded in the sale order file.
A Sales Assistant arranges for the order to be assembled and shipped. At times, one or more of the inventory items ordered by a customer are not in stock. In these cases, DataTech ships partial orders. A sales order can be for many different items, and an item can be ordered many times. Discounts are often extended to repeat customers and larger orders. As standard product prices are stored for each product, Sales Assistants enter discounts in percentage terms for each line item in an invoice. For example, if a product's list price is 100[euro] and the agreed selling price for an invoice is 95[euro], a Sales Assistant enters a discount of five percent onto the sales entry form.
For various reasons, products are sometimes returned. For example, it sometimes happens that products are damaged in transit, or that the customer overestimated their IT requirements. A customer may return sales items in one or many batches. When a Sales Return is received, one of the five Accounts Administrators ensures that the return is correctly recorded. The Accounts Administrator must then update the Sales Return and Accounts Receivable ledger balances. This is a very laborious and a time-consuming process. It is desirable that any new information system be capable of integrating the Sales Return event with these functions.
DataTech's collection activities include documenting the receipt of payments and depositing the payments in the company's bank account. A critical feature of the collection process is linking the payments back to invoices to make sure all invoices are ultimately paid in full. Customers are expected to pay their invoices within thirty days. Most customers pay on time with only one payment. However, some customers arrange to make partial payments over two or three months (i.e., installment payments). Each customer payment is for only one invoice. Customers do not run a tab (i.e., combine several invoices into one payment), as most are not frequent, repeat customers. Payments received are deposited into only one bank account, the operating account. DataTech may receive cash from sources other than customers for sales (e.g., a loan from a bank).
The REA model for DataTech's sales cycle is presented in Exhibit 1. Major events of interest modeled are consultation (aka sales call), receive sale order, sales (aka shipment), sales return, and cash receipt. Each entity (resource, event or agent) is represented by a rectangular box. The attributes are contained within the boxes.
The first event in the REA model is Consultation, an initiating and a business event. A relational schema for this event is provided in Figure 2. It shows typical relationships between the Employees, Consultations, Inventory, and Customers.
The relationships between the Customer and Consultation tables; Employee and Consultation tables; Employee Type and Employee tables; and the Inventory Type and Inventory tables are one-to-many (1--N). For example, each employee type can have many employees, hence a 1: N relationship. The relationship between the Consultation and Inventory tables is many-to-many (N--N). That is, a given consultation can involve several inventory items. Any particular inventory item can be the subject of several consultations. Note that a relationship table (ConsultationItem) is required when necessary to convert one N--N relationship into two 1--N relationships.
3.3.2 Purchase Cycle: The purpose of the purchase and payment cycle is to secure economic resources that DataTech uses to provide services. The main goal is to secure economic resources of sufficient quality and quantity to meet DataTech's needs at the lowest possible cost and to pay for them on time. The major activities of the purchase and payment cycle parallel those of the sales and collection cycle because they present the view of the sales transaction from the standpoint of the purchaser instead of the seller.
[FIGURE 2 OMITTED]
Inventory is generally acquired by DataTech from wholesalers and software vendors. Purchasing Agents ensure that sufficient levels of inventory are maintained in the company. Inventory levels are not currently recorded automatically, but it is expected that any prospective information system will incorporate this feature. This will greatly reduce the burden on DataTech's two Purchasing Agents. Once a Purchasing Agent decides that an order needs to be placed with DataTech's suppliers, a Purchase Order form is completed. This form records an expected Delivery Date as well as generic purchase order information, to enable DataTech to gauge which suppliers are meeting delivery schedules.
A supplier may fulfill a purchase order over one or many shipments. When a shipment arrives at the receiving dock, a receiving clerk must count the inventory items and record which items were received and their quantities on an inventory receipt. Completing this receipt reduces the possibility of error (e.g., receiving unordered goods). The inventory receipt record includes a notation of the purchase order on which the inventory items were ordered.
DataTech makes payments after an invoice has been received from the supplier. The Accounts Administrator compares the purchase order, receiving reports, and invoices to ensure a three-way match. Once the Administrator verifies the three-way match, a payment check is generated within ten days of receiving the inventory. Although DataTech usually pays for inventory receipts in full, on rare occasions, the company makes installment payments for large orders. DataTech does not pay for multiple invoices with only one check (i.e., it does not run a tab). Payments are usually made from the operating account.
3.3.3 Cash Management: Accounts Administrators oversee the sales returns, cash receipt, cash disbursement and accounting functions of the company. Effective cash flow management is very important to DataTech, and Accounts Administrators endeavor to maintain healthy liquidity ratios at all times. Collecting information regarding total debtor and creditor levels is currently a laborious task, and DataTech would like the new accounting information system to automate this process as much as is possible.
DataTech has two current accounts; one at Bank of Ireland and one at Allied Irish Bank. Payments are made to/from each account in accordance with the preferences of the company's customers and suppliers. With the current climate leading to reduced margins, effective management of Working Capital items has been designated as a key competency required for the continued success and growth at DataTech.
3.4 Query Objectives
Good information systems provide relevant, timely, and accurate information, and are flexible and easy to use. Often management's focus is on the bottom line, such as cost savings and possible benefits provided to the decision maker, while employees are primarily focused on ease of operations, ease of use, ease of learning, and user-friendliness.
Management at DataTech has the following specific objectives, some of which were alluded to in the narrative above:
1) DataTech's accounting period runs from January 1 to December 31. The accounting system records data from January 1. Management would like to run queries and reports which contain transactions from January 1 to a specified date. The user should be prompted to enter a specific date when running queries and reports.
2) A user should be able to check accounts receivable and accounts payable balances at any date.
3) A user should be able to check specific supplier and customer balances at any date.
4) It is desirable that inventory levels are automatically adjusted as each transaction is entered into the database. This will ensure that both Management and Purchasing Agents have up-to-date information regarding "current" inventory levels.
5) Management would like to be able to access real-time summary financial data such as gross margin, liquidity and efficiency ratios. Satisfying this objective will require an extensive use of queries across multiple tables.
6) Speed of dispatch is important to DataTech. Management would like to keep track of the company's average delivery time.
7) In order to increase Sales Revenue, it is essential for Consultants to suggest both core and peripheral products to prospective customers. Management would like to determine which Inventory Types are being most frequently recommended by each Consultant.
Using data to make decisions depends on an organization's ability to collect, organize, and otherwise transform data into information that can be used to support those decisions. Queries are useful in extracting and analyzing business data. In relational databases, querying and reporting are key business intelligence activities. Business intelligence is a concept, loosely understood to mean 'software applications used to analyze an organization's raw data' (Business Intelligence website, 2012).
3.5 Forms of Interest
DataTech is interested in creating forms for various facets of the business; from New Customer Entry to Sales and beyond. There are a number of important issues to consider when designing these forms, in order to enhance both the security and functionality of the system:
1) Access to forms should ideally be restricted to those employees who require use of the forms on a day-to-day basis. As sensitive information should be accessed by authorized personnel only, this feature would reduce the risk of fraud and error. DataTech intends to achieve this by implementing a log-in system.
2) It is important to retain an audit trail. Authorized personnel will need to examine past transactions at a later date. For this reason, it should not be possible to "delete" an invoice from the system. Rather than reversing an invoice, a Sales Return should be recorded and Inventory levels and Accounts Receivables adjusted to reflect the sales return; crucially, a record of the original transaction should remain.
3) Deletion of specific non-transactional records should, however, be possible. For example, customers or suppliers may be deleted if no transactions relating to them have been recorded.
4) The system should avoid hard entry of derivable attributes. For example, an Invoice form/table should not contain the final price as this is derivable from quantity sold, standard list price and discount allowed (i.e. line price = Quantity x Unit Price x [1-Discount])
5) When completing a sale or purchase, the system should be able to auto-complete information from the Order form. Ideally, supplier/customer details and the inventory items ordered should be transferred to the Invoice or Purchase form by inputting the Order ID. For example, if the Purchasing Agent enters the Purchase Order ID and presses the "Update Supplier and Inventory Information" button, the supplier's details as well as the items selected will be automatically entered.
Figure 3 shows DataTech's Switchboard. It incorporates internal control features such as requiring users to log-in to access the new information system. In this way, access to each form and report would be restricted to those employees who require it for their work. Included in Figure 3 are screenshots of the Log-in page, the Consultant menu, and the Management Menu. There are five such menus in all (of which two are in Figure 3), one for each employee type, which are accessed by entering username and password information.
[FIGURE 3 OMITTED]
3.6 Reports of Interest
Management at DataTech is eager for reports detailing current inventory levels and summary financial information to be made available to them. A report indicating inventory levels would greatly assist the Purchasing Agents on a daily basis, and help to ensure that inventory levels sufficient to enable the quick dispatch of Sales Orders are maintained.
A "ready-made" printable Invoice is also desirable. Accounts Administrators currently have to type up invoices manually. Automating this process would increase efficiency and reduce potentially costly errors.
A report summarizing key financial information would ideally provide a timely, relevant and accurate "snapshot" of company performance at any given point in time. A sample report, in Exhibit 2, captures key financial indicators that management wants to have readily available. Working capital information, gross margin and important accounting ratios are included in this report.
1. Conceptual Model: Based on the company narrative, develop an REA model depicting DataTech's purchase cycle, namely: 1) the entities about which to store data, and 2) business rules and policies governing interrelationships between these data entities (i.e., cardinalities). Assume that DataTech does not currently require a Purchase Return process. The deliverables should include the following:
a. A list of entities (resources, events, agents) for the purchase and payment process.
b. A REA diagram showing connectivity and cardinalities (including whether participation is optional or mandatory). When describing cardinalities, three issues to consider are:
* What does the cardinality measure?
* What are the minimum and maximum cardinalities?
* Explain why the chosen minimum and maximum were selected.
2. Relational Schema--Determine a relational schema (table structure) from the REA diagram (i.e., the tables to set up in the database, the data elements (fields) to include in each table, designating primary and foreign keys, and specifying the properties of each field). The deliverable should provide the following:
a. Using the model developed in Deliverable 1 (entities, relationships), identify the attributes of interest and specify the relations. Provide the relational schema for each relation in the form: TABLE_Name ([KEY_ATTRIBUTE.sub.1], [ATTRIBUTE.sub.2],... [ATTRIBUTE.sub.N])
b. The design goal for your relational schema must be to create tables that are in third normal form. Generally, items that can be calculated (or derived) from other elements in a table should not be included in the table itself.
c. Indicate the primary key in each relation by underlining; and double-underline or italicize foreign keys.
3. Table Creation/Data Entry--Using the table layout from Deliverable 2, create a database in MS-Access[TM] for DataTech's purchase processes. The steps to follow are:
a. Using the relational schema above, create each table. Ensure all primary keys, foreign keys, and referential integrity constraints are clearly set.
b. Establish links between tables based on the relationships specified in Deliverable 2.
4. Data Entry Forms--Using tables developed in Deliverable 3, design and create at least two data entry forms. The steps to follow are:
a. Design and create data entry forms (e.g., Supplier Entry Form, Inventory Entry Form). Test the forms to be sure data is entered correctly.
b. When designing forms, consider which data items can have their values supplied through a selection in the list box, such as inventory type.
c. Use Macros to make navigation and operation as user-friendly as possible. On each data entry form, include a form navigation button which can close the data entry form and return to the switchboard.
5. Query Design--Create a set of queries from the list of query objectives identified by management. Design and run a minimum of five queries. Use parameters, expressions, and grouping and summarizing operations. Provide printouts of the query results.
6. Reports--Create at least two reports (e.g., Inventory Report, Purchase Order) as they appear in the narrative.
An instructor may follow one of two approaches. Students may complete the entire project using self-created data. After pilot testing the project, the authors recommend that rather than using student-created data, the instructor should provide common data before Deliverable 5 for students to use for writing queries and generating reports. Use of a standardized database ensures that student answers to queries are correct, and facilitates grading and comparison of results between students. This approach requires that the project be graded in phases, not as one finished project. Data is available from the authors in two different formats: 1) a spreadsheet format that requires that students learn to import data into the database, and 2) a database format. Instructors also have the flexibility to tailor the project to their desired level of difficulty. Instructors may vary the number and complexity of the queries assigned to students, as well as the level of detail required in the forms and reports assigned.
Comprehensive teaching notes, including grading rubrics, for the above deliverables, including the conceptual REA model with cardinalities, relationship schema, tables, forms and reports, are provided. In addition, a MS-Access[TM] database including forms, queries, and reports for DataTech is available upon request from the authors.
In the digital age, it is critical that accountants and auditors understand complex business processes and automated information systems. As data modeling proficiency is an essential skill, this semester long project gives students hands on practice in conceptualizing, designing, populating and querying a database that supports the core business processes of a small enterprise. By the assignment of deliverables throughout the semester, beginning with a conceptual model, leading to a relational schema, and the creation of a database in MS-AccessTM for DataTech's sales and purchase cycles, students develop an understanding of the interrelated nature of business processes and practice in using data to answer business questions.
Exhibit 1: REA Model of Sales Cycle
Summary Key Financial Information Report
Summary Financial Information Management Trading Account Sales Revenue sales Return Net Sales Opening Inventory $90811.00 Purchases 194,898.88[euro] 285,709.88[euro] Closing Inventory 93,383.00[euro] Cost of Sales Gross Profit Working Capital Items Account Receivable 159,713.38[euro] Account Payable 157,818.88[euro] Cash balance 25,633.82[euro] Ratio Analysis Current Ratio 1.17 Quick Ratio 1.77 Gross Margin % 0.2093 Inventory Days 1.7478 Debtor Days 2.3966 Creditor days 2.9556 Operating Cycle (Days) 1.1889 Management Trading Account Sales Revenue 266,851.90[euro] sales Return 23,610.57[euro] Net Sales 243,241.33[euro] Opening Inventory Purchases Closing Inventory Cost of Sales $192326.88 Gross Profit $50914.45 Working Capital Items Account Receivable Account Payable Cash balance Ratio Analysis Current Ratio Quick Ratio Gross Margin % Inventory Days Debtor Days Creditor days Operating Cycle (Days)
Bagranoff, N., Simkin, M., and Norman, C. (2010). Core Concepts of Accounting Information Systems, 11th Ed., Wiley.
Business Intelligence Definition and Solutions (2012). CIO, Retrieved March 15, 2012, from http://www.cio.com/article/40296/Business Intelligence Definition and Solutions
Chen, P. (1976). "The Entity-Relationship Model--Toward a Unified View of Data," ACM Transactions on Database Systems, Vol. 1, Issue 1 (March): 9-36.
Dunn, C., Cherrington, J., and Hollander, A. (2005). Enterprise Information Systems: A Pattern Based Approach, 3rd Ed., McGraw Hill Irwin.
Gelinas, U., Dull, R., and Wheeler, P. (2012). Accounting Information Systems, 9th Ed., Cengage.
Greets, G., and McCarthy, W. E. (1997). "Modeling Business Enterprises as Value-Added Process Hierarchies with Resource-Event-Agent Object Template," in Business Object Design and Implementation, London: Springer-Verlag, pp. 94-113.
Kay, D., and Ovlia, A. (2012). Accounting Information Systems: The Crossroads of Accounting & IT, Pearson Prentice-Hall Inc.
McCarthy, W. (2003). "The REA Modeling Approach to Teaching Accounting Information Systems," Issues in Accounting Education, Vol. 18, Issue 4, pp. 427.
McCarthy, W. (1982). "The REA Accounting Model: A Generalized Framework for Accounting Systems in a Shared Data Environment," The Accounting Review, Vol. 57, Issue 3, pp. 554-579.
Poels, G., Maes, A., Gailly, F., and Paemeleire, R. (2011). "The Pragmatic Quality of Resources-Events-Agents Diagrams: An Experimental Evaluation," Information Systems Journal, Vol. 21, Issue 1, pp. 63.
Romney, M. B., and Steinbart, P. J. (2012). Accounting Information Systems, 12th Ed., Pearson Prentice-Hall Inc.
Sorter, G. (1969). "An Events Approach to Basic Accounting Theory," Accounting Review, 44 (1), January, pp. 12-19.
School of Business
The College of New Jersey
2000 Pennington Road, Ewing, NJ 08628-0718
Sunita Ahlawat is Chair and Associate Professor of Accounting and Information Systems at the College of New Jersey. A 2008 Fulbright fellow, Dr. Ahlawat holds a PhD from the Pennsylvania State University and an MBA from the University of Massachusetts. She has published in various journals including Advances in Accounting Behavioral Research, Auditing: & Theory, Critical Perspectives on Accounting, International Journal of Technology Management, Journal of American Academy of Business, Journal of Behavioral Decision Making, Socio-Economic Review, American Journal of Business Education, and The Accounting Educators' Journal.
Joyce Vincelette is a Professor of Management and the Coordinator of Management and Interdisciplinary Business Programs at The College of New Jersey. Dr. Vincelette holds a DBA from Indiana University and an MBA from Michigan State University. She has authored and co-authored various articles, chapters and cases that have appeared in management journals and strategic management texts and casebooks. She is also active as a consultant and trainer for a number of local and national business organizations as well as for a variety of not-for-profit and government agencies.
|Printer friendly Cite/link Email Feedback|
|Title Annotation:||Teaching Case|
|Author:||Ahlawat, Sunita; Vincelette, Joyce|
|Publication:||Journal of Information Systems Education|
|Date:||Jun 22, 2012|
|Previous Article:||Simulated audits to engage students in IT governance and assurance courses.|
|Next Article:||Directors Guild of America Health Plan eligibility: an IS analysis and design case.|