CHAPTER 2- AIS

System flowcharts provide a more detailed illustration of relationships between processes and documents, depicting separation of functions. Various symbols are used to represent manual procedures (e.g., terminals, source documents, operations, connectors). An example of a sales order process using a system flowchart is described in detail, showing the flow from customer order to delivery.

Program flowcharts illustrate the logic used within computer programs. Common symbols include rectangles for logical processes, diamonds for decisions, and ovals for start/end operations, along with parallelograms for input/output. These charts focus on the internal logic of a program rather than the broader system flow.

The video introduces the second chapter on Accounting Information Systems (AIS), focusing on transaction processing. It defines financial transactions as economic events affecting assets, liabilities, and equity, measured monetarily. These transactions are grouped into three primary cycles: expenditure, conversion, and revenue, each with two subsystems: a physical and a financial component.

The expenditure cycle is explained as the acquisition of goods, materials, assets, or labor in exchange for cash. Its two subsystems are the physical component (acquisition of goods/services) and the financial component (cash disbursement to suppliers). This cycle is further broken down into purchases, accounts payable, cash disbursement, payroll, and fixed asset systems, which will be discussed in later chapters.

The conversion cycle involves the process of manufacturing a product from raw materials, labor, and factory overhead. It includes two major subsystems: the production system (planning, scheduling, and control of physical product manufacturing) and the cost accounting system (monitoring the flow of cost information related to production).

The revenue cycle focuses on receiving cash from customers after selling finished goods. Its subsystems are the physical component (sales order processing) and the financial component (cash receipts), encompassing aspects like accounts receivable.

A diagram illustrates the interconnectedness of the three cycles. The output of the expenditure cycle (materials, labor) becomes the input for the conversion cycle. The finished goods from the conversion cycle are sold in the revenue cycle, generating cash that feeds back into the expenditure cycle, creating a continuous loop.

The discussion shifts to manual accounting records, emphasizing their role as a foundational understanding before moving to computerized systems. Key records include source documents (e.g., receipts, checks, memos), product documents (e.g., payroll checks as outputs), and turnaround documents (product documents of one system that become source documents for another, like remittance advice).

Journals are presented as books of original entry, recording chronological transactions. They include special journals (for high-frequency transactions like sales or cash disbursements) and general journals (for infrequent or dissimilar transactions). Ledgers are books of final entry, comprising general ledgers (showing activity for each account) and subsidiary ledgers (detailing activity for control accounts like accounts receivable/payable).

The importance of an audit trail in manual systems is highlighted, allowing tracing of transactions from source documents to financial statements and vice-versa. This traceability ensures faithful representation, completeness, and freedom from error or bias in financial information. An example of tracing an accounts receivable control account is provided to demonstrate the process.

The transition to computer-based systems is addressed, noting that the audit trail is less observable but still present, often residing in data entry and computer programs. Data in these systems are stored in magnetic files, categorized into master files (account data), transaction files (temporary, recent transactions), reference files (constant information like customer addresses or tax tables), and archive files (past transactions for reference).

Documentation is crucial for computer-based systems due to their complexity. Five techniques are introduced: data flow diagrams (logical elements, processes, data flows, entities), entity relationship diagrams (relationships between entities using cardinality), system flowcharts (relationships among processes and documents, detailed), and program flowcharts (logic used in programs).

Data flow diagrams use symbols for entities, processes, data flows, and data stores, focusing on logical system elements. Entity relationship diagrams (ERDs) use the REA (Resources, Events, Agents) model to represent relationships between entities, including cardinality (one-to-one, one-to-many, many-to-many), reflecting business rules and numerical mapping.

The video discusses modern and legacy systems. Modern systems tend to be client-server, network-based, and process transactions in real-time, often using relational tables. Legacy systems are mainframe-based, often batch-oriented, and use flat files or hierarchical databases, promoting single-user environments. The importance of understanding both, especially when migrating or dealing with system failures, is emphasized.

Procedure and backup are critical in computerized systems due to destructive updates. Master files must be regularly updated and backed up. A recovery program uses backups to recreate and update master files in case of system failure. An example highlights the grave consequences of inadequate backup procedures, emphasizing the need for robust recovery plans.

Batch processing involves accumulating similar, independent transactions over time and processing them together. This method creates a time lag between the event and its recording. Steps include keystroke (capturing source data), edit run (identifying clerical errors), sort run (ordering transactions), and update run (changing master file values). Batch processing increases efficiency for high-volume transactions and provides better control through control figures.

Real-time systems process individual transactions immediately as they occur, eliminating time lag. While generally requiring more resources (hardware, programming, training) and longer development time, the cost differential is decreasing. An example includes immediate reflection of bank deposits. Real-time offers immediate feedback and higher operational efficiency due to instantaneous data reflection.

A comparison is made between batch and real-time processing across information time frame, resources, and operational efficiency. Batch processing has a time lag, requires fewer resources, and certain records are processed after the event. Real-time processing has no time lag, requires more resources, and processes all records immediately, offering immediate data visibility and higher operational efficiency, especially for critical decisions.

Data coding in AIS helps represent complex information concisely, ensures accountability, identifies unique instructions, and supports audit functions. Various coding schemes are discussed: sequential codes, block codes, group codes, alphabetic codes, and mnemonic codes, each with its own advantages and disadvantages.

Sequential codes represent items in sequential order, useful for tracking transactions and identifying out-of-sequence documents but offering arbitrary information and being difficult to change. Block codes assign specific ranges for whole classes, allowing easy insertion of new codes within a block (e.g., chart of accounts) but also provide arbitrary information.

Group codes represent complex items with multiple data pieces using fields with specific meanings (e.g., a sales tracking code). They facilitate diverse data representation, logical hierarchical structures, and detailed analysis but can be overused and complex. Alphabetic codes use alphabetical characters, offering more variations per field than numeric codes but can also be arbitrary and difficult to sort.

Mnemonic codes use alphabetical characters as abbreviations or acronyms that are informative and not arbitrary, making them easy to remember. They are useful for representing classes of items but have limited ability to represent all items within a class due to potential for ambiguity and overuse, similar to other coding schemes.