Open Collections

UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

A computer-based approach for resolving budget discrepancy Chun, Fan 1997

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
831-ubc_1997-0226.pdf [ 4.31MB ]
Metadata
JSON: 831-1.0087622.json
JSON-LD: 831-1.0087622-ld.json
RDF/XML (Pretty): 831-1.0087622-rdf.xml
RDF/JSON: 831-1.0087622-rdf.json
Turtle: 831-1.0087622-turtle.txt
N-Triples: 831-1.0087622-rdf-ntriples.txt
Original Record: 831-1.0087622-source.json
Full Text
831-1.0087622-fulltext.txt
Citation
831-1.0087622.ris

Full Text

A COMPUTER-BASED APPROACH FOR RESOLVING BUDGET DISCREPANCY by  FAN CHUN B.Com. (Hon.), Memorial University of Newfoundland, 1994  A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE in  THE FACULTY OF GRADUATE STUDIES (Faculty of Commerce and Business Administration) We accept this thesis as conforming to the required standard  THE UNIVERSITY OF BRITISH COLUMBIA APRIL 1997  © Fan Chun, 1997  In  presenting  degree freely  at  this  the  available  copying  of  department publication  of  in  partial  University  of  British  for  this or  thesis  reference  thesis by  for  his  this  thesis  and  f u l f i l m e n t ' of Columbia,  study.  scholarly  or for  her  of  /  *P  T h e U n i v e r s i t y o f British Vancouver, Canada  financial  Date  DE-6  (2/88)  ^^ll^c^i^' Columbia  further  purposes  gain  shall  requirements  agree  that  agree  may  representatives.  permission.  Department  I  |  the  It not  be  that  the  Library  permission  granted  is  by  understood be  for  allowed  an  advanced  shall for  the that  without  make  it  extensive  head  of  my  copying  or  my  written  u  ABSTRACT Information technologies (IT) have drastically transformed many business activities in the past 30 years. Among the numerous business activities in organizations, the budget preparation process plays a very important role. Although there are many developed systems available to automate certain aspects of the budgeting process, there is much more that can be done. This thesis studies the budgeting process and certain behavioral factors involved in the preparation of the budget. Knowing the complications inherent in budgeting, effort has been directed towards automating the mechanistic portion of the process; narrowing down the differences; and identifying the sources of discrepancy by using a computer-based system. Based on an algorithm derived from a manually solved budgeting case, the requirements of automation were studied, a computer based system was developed and tested. In addition, directions for future studies are suggested in this thesis.  Hi  TABLE OF CONTENTS  ABSTRACT  ii  TABLE OF CONTENTS  iii  LIST O F T A B L E S  v  LIST O F FIGURES  vi  ACKNOWLEDGMENT  vii  INTRODUCTION  1  1 MOTIVATION OF THIS PROJECT  1  2 CHAPTER SUMMARY  3  DIFFICULTIES A N D C H A L L E N G E S INT H E B U D G E T I N G  5  1 T H E B U D G E T PREPARATION PROCESS  1.1 1.2 1.3 1.4 1.5  6  Organization Issuance of guidelines Initial budget proposal Negotiation Review and Approval  6 7 7 8 8  2 BUDGET NEGOTIATION - A CLOSER LOOK  9  2.1 Incentive to Build Slack 2.2 Asymmetric Distribution of Information 2.3 Unwillingness to Disclose and Share Information 2.4 Other Difficulties 2.5 Conclusion  9 10 11 12 13  CASE STUDY - NATIONAL M O T O R S INC  15  1 C A S E SUMMARY  /./ 1.2 1.3 1.4 1.5 1.6 1.7  16  Organizational structure before consolidation Organizational structure after consolidation Original budget after consolidation Manufacturing Office: Supplemental budget proposal Controller's Office: Supplemental budget proposal Protest from the Manufacturing Office Discrepancies to be reconciled  2 T H E DIFFICULTIES OF THE C A S E  21  2.1 Incentive to Build Slack 2.2 Asymmetric Distribution of Information 2.3 Unwillingness to Disclose and Share Information versus Information Overload 3 T H E REAL ISSUE OF THE C A S E  16 17 17 18 19 19 21  :  21 22 22 23  4 RECONCILIATION ALGORITHM  23  5 A SIMPLIFIED SOLUTION OF T H E C A S E  26  AUTOMATION - CURRENTLY AVAILABLETECHNOLOGIES  28  iv  1 POTENTIAL FOR AUTOMATION  28  2 SPREADSHEET  29  3 RELATIONAL DATABASE M A N A G E M E N T SYSTEMS ( R D B M S )  30  4 OBJECT-ORIENTED DATABASE M A N A G E M E N T SYSTEM ( O O D B M S )  31  5 ACCOUNTING SOFTWARE  32  6 SOFTWARE AVAILABLE SUPPORTING NEGOTIATION  32 34  IMPLEMENTATION 1 ALGORITHM FOR IMPLEMENTATION  1.1 1.2 1.3 1.4 1.5 1.6  35  Assumptions Used in the Algorithm Initial Checking Further Analysis - Departmental Accounts Further Analysis - Categorical Sub-accounts Further Analysis - Equation Iterative Approach  37 37 39 41 42 43  2 STRUCTURAL DESIGN OF THE SYSTEM  43  2.1 Main Reasoning Engine 2.2 The Equation Simplification Engine 2.3 The Account Database  44 44 45  3 KNOWLEDGE REPRESENTATION  46  3.1 Basic Components of an Account 3.2 Account Key 3.3 Account Number  46 47 48  4 TESTING  49  4.1 The Screen Capture 4.2 Log 4.3 Personnel Discrepancy Reconciliation  51 55 56 57  CONCLUSION AND FUTURE WORK 1 LIMITATIONS OF THE STUDY  59  2 FUTURE W O R K  59  3 CONCLUSION  60  BIBLIOGRAPHY  61  APPENDK A  63  APPENDIX B  74  APPENDIX C  75  1 M A I N REASONING ENGINE  75  2 EQUATION SIMPLIFICATION ENGINE  83  3 DIVISIONAL SUBTOTAL  :  100  4 CORPORATE HIERARCHY.,  100  5 CONTROLLER'S DATABASE  101  6 MANUFACTURING OFFICE'S DATABASE  103  APPENDIX D 1 T E S T RESULT  106 106  V  LIST OF TABLES T A B L E l . T H E ORIGINAL COMBINED BUDGET  18  T A B L E 2. MANUFACTURING OFFICE: SUPPLEMENTAL BUDGET PROPOSAL  18  T A B L E 3. CONTROLLER'S OFFICE SUPPLEMENTAL BUDGET PROPOSAL  19  T A B L E 4. SUMMARY OF T H E C A S E  20  T A B L E 5. DISCREPANCIES TO BE RESOLVED  21  T A B L E 6. SOURCES OF DISCREPANCIES IN DOLLAR A M O U N T  27  T A B L E 7. DISCREPANCY CAUSED BY ONE-TIME COSTS  27  T A B L E 8. DISCREPANCY CAUSED BY SALARY M I X C H A N G E  27  T A B L E 9. EXAMPLES OF KEYWORDS USED IN THE NATIONAL MOTORS C A S E  48  T A B L E 10. HIERARCHICAL ORDER OF ACCOUNT NUMBERS  49  LIST OF FIGURES FIGURE 1. BUDGET PREPARATION PROCESS FIGURE 2. ORGANIZATIONAL CHART OF NATIONAL MOTORS BEFORE CONSOLIDATION (PARTIAL)  6 16  FIGURE 3. ORGANIZATIONAL CHART OF NATIONAL MOTORS AFTER CONSOLIDATION (PARTIAL)  17  FIGURE 4. LOGICAL F L O W OF ACTIVITIES  25  FIGURE 5. LOGICAL DESIGN OF SYSTEM  36  FIGURE 6. FURTHER ANALYSIS - CHECKING DIVISIONAL SUB-ACCOUNTS  39  FIGURE 7. FURTHER ANALYSIS - CATEGORICAL SUB-ACCOUNTS  41  FIGURE 8. FURTHER ANALYSIS - EQUATION  42  FIGURE 9. SYSTEM STRUCTURE  44  FIGURE 10. RELATIONSHIPS BETWEEN TESTING SYSTEMS  50  FIGURE 11. CONTROLLER'S INITIAL RESPONSE  51  FIGURE 12. MANUFACTURER U N A B L E TO PROVIDE INFORMATION  52  FIGURE 13. QUERY SENT AFTER SECOND T E S T  53  FIGURE 14. MANUFACTURING OFFICE'S REPLY  53  FIGURE 15. A N E W ROUND OF EXAMINATIONS  54  vii  ACKNOWLEDGMENT I am indebted to many people for their assistance with this thesis. First I would like to thank my supervisor, Dr. Carson Woo, for his continuous guidance and invaluable support throughout every phase of this thesis. I would also like to thank Dr. A l Dexter and Dr. Mitchell Farlee for reading through this thesis and providing me with constructive comments. Special thanks to Dr. Sunil Dutta and Dr. Vasu Krishnamurthy who provided me guidance for the accounting part of this thesis. Special thanks to Mr. Lin ZhuHai at South Bank University for allowing me to include his equation simplification which is an essential part of my final system. I am also grateful to those people who have provided me help in writing this thesis: Ms. Gina Lee, Mr. Darrell Jung and Mr. Ken Leung. There are those who continuously supported me. I cannot express my thankfulness in any words. I can only thank God for having them around: mom, sis, and my lovely wife, Mei. Finally, I thank our heavenly father for His provision.  Chapter One INTRODUCTION  1 Motivation of This Project Information technologies (IT) have automated and transformed many business activities drastically in the past 30 years. So far much effort has been devoted to developing tools such as relational databases and spreadsheets that can be employed to support various business activities. We have seen many successful examples of how technologies and tools dramatically improved performance and speed.  These tools, in most cases, not only  improved but also revolutionized the way business activities are conducted in organizations. Among the numerous business activities in organizations, the budget preparation process plays a very important role because "budgets are an important tool for effective short-term planning and control in organizations" (Anthony, Dearden, and Govindarajan,  1992, p. 436). Typically, organizations and their subsidiaries make estimates of future revenues to be realized over a certain time period and plan their expenses accordingly. Traditionally, budget preparation is conducted on an annual basis. With the aid of modern IT tools, budget preparations now can also be done on a semi-annual, quarterly or even monthly basis. Although there are systems, such as SAP , already developed to automate 1  certain aspects of the budgeting process, much more can be done to research and develop appropriate and specific tools. The authors of the book "Management Control Systems" point out that budget preparation has four principal purposes and they are described in the following section: (1) to fine tune the strategic plan; (2) to help coordinate the activities of the several parts of the organization; (3) to assign responsibility to managers, to authorize the amounts they are permitted to spend, and to inform them of the performance that is expected of them; and (4) to obtain a commitment that is a basis for evaluating a manager's actual performance.  (Anthony et al., 1992, p. 438)  The final products of the budgetary process, the prepared budgets, represent the organizational consensus about future operating goals and how each department is designed to work towards achieving the overall goals of the company. They act as an internal communication vehicle linking the different departments with each other and with upper management. Finally, budgets serve as standards, control devices and motivation tolls that influence employees to act in ways that are consistent with effective and efficient operations  1  Information on the SAP system can be found at the company's website: http://www.sap.com  P. 3  and in congruence with organizational goals (Siegel, Ramanauskas-Marconi, 1989, pp. 125126). Judging from the important nature of budget preparation and the use of budgets, one can safely conclude that timeliness becomes an essential element in terms of delivering the budget.  Therefore, it is worth devoting time and resources to study the possibility of  automating the budgeting process. The objective of this thesis is to study the possibility of automating the budgeting process by employing information technology.  2 Chapter Summary  The topic was dealt with first by studying the specific procedures and elements involved in budget preparation and approval. Difficulties and challenges involved in preparing the budgets were studied and discussed in the chapter immediately following this one.  They were identified as the incentives in understating revenues and overstating  expenses, unwillingness to share information, and the responsibility issue. All these stated issues play a role in how information is presented and handled by the different parties involved in the budget preparation (Chapter Two). Much of this research work was spent in selecting, analyzing and solving a budget preparation case prepared by J. Hekimian under the supervision of R. N. Anthony of Harvard Business School (Anthony et al., 1992, pp. 456 - 467) which is summarized in Chapter  P. 4  Three. An algorithm was generated after in-depth manual analysis of the budgeting case. The algorithm is presented in the format of a flowchart (Chapter Three). Next the popular IT tools currently employed in assisting in budget preparation were researched and summarized in Chapter Four of this paper. These tools did bring in a certain degree of automation to the budget preparation process but they did not address all the automation issues adequately. Any non-addressed issues were subjected to further study in order to identify the potential for automation. No specific tools were available to help negotiation parties pinpoint budget discrepancies. Due to the inadequacies of the current available tools, a system was designed and implemented in PROLOG language based on the algorithm stated in Chapter Three. A l l design and implementation details and experiences are documented in Chapter Five, which serve as the ground work for future studies. Since budget preparation is such a broad topic, we devoted our research efforts to narrowing the scope of differences and pinpointing the discrepancies for the budget preparation parties so that they can focus on the real "agendas" on the bargaining table. Chapter Six outlines issues that are not addressed by this study. This chapter also contains suggestions and opinions for future research.  Chapter Two DIFFICULTIES AND CHALLENGES IN T H E BUDGETING Budget preparation is an important business process which serves the purposes of finetuning corporate strategic plans, coordinating the activities of different departments, assigning responsibility to managers, and obtaining a commitment (Anthony, Dearden, and Govindarajan, 1992). The administration of such an important process that has a high impact on the sustainability of an organization often involves grave delicacy. Therefore, it is appropriate for us to look at the process of budget preparation.  The following sections  describe this business process, and certain human factors that complicate the process will be reviewed. The last section of this chapter will identify the focus of automation.  1 The Budget Preparation Process Though there are no standard rules for corporations to follow, the budgetary process normally involves the following steps described in Management Control System (Figure 1): organization, issuance of guidelines, initial budget proposal, negotiation, and review and approval (Anthony et al., 1992, pp. 445-449).  Review and Approval  Budget Proposal  Organization  Guidelines  Negotiation  Figure 1. Budget Preparation Process  1.1 Organization A budgetary control system is usually administered by the budget department which publishes procedures and defines assumptions as the basis for budget preparation. The budget department coordinates communication between interrelated departments for better sharing of information. During the budget preparation process, the department analyzes the proposed budgets and makes recommendation to the budget committee. The department  P.7  also monitors the execution of the budget by analyzing the reported performance throughout the operating period. "The budget committee consists of members of senior management ... and the financial vice president" (Anthony et al., 1992, p. 446). The committee plays a key role in budget preparation. It reviews, rejects or approves the final budget.  In addition, any  revisions deemed necessary during the year must also be reviewed and approved by the committee.  1.2 Issuance of guidelines This is usually the first step in the budget preparation process. The budget department develops guidelines that govern the preparation of the budget. The lower-level managers are expected to follow these guidelines when preparing budgets. In some cases, lower level management are consulted before guidelines are approved.  1.3 Initial budget proposal Based on the guidelines issued by the budget committee, the responsibility center managers compile a budget request. The formation of the budget has to go through the following steps: 1. Estimation based on current period data. 2. Adjustment for changes in external factors. 3. Adjustments for changes in internal policies and practices.  P.8  1.4 Negotiation The negotiation stage is described as the "heart of the [budgeting] process" by Anthony et. al. The following paragraph describes a typical scenario of budget negotiation: the budgetee discusses the proposed budget with his or her superior. The superior attempts to judge the validity of each of the adjustments ... The superior recognizes that he or she will become the budgetee at the next level of the budget process, and therefore, must be prepared to defend the budget that is finally agreed to. (Anthony et al., 1992)  1.5 Review and Approval As the budget proposals travel up the corporate hierarchy, they are put together for analysis. If the big picture provides unsatisfactory results, the proposals would be sent back for reworking. There are numerous tools available to automate the budgeting process. However, there are no specific tools available to automate the negotiation stage of the budgeting process. In addition, negotiation is likely to be intensified by the growing trend of globalization under the current economy environment since more variables are to be considered in a decentralized, international environment. Therefore, it is worthwhile to direct our efforts to studying the budget negotiation process.  P.9  2 Budget Negotiation - A closer look  Business budgets are similar to personal budgets in that they both serve the comparable purposes of "(1) making estimates of income, (2) planning expenditures, and (3) restricting spending in accordance with the plan" (Garrison, Chesley, and Carroll, 1990, p. 411). However, business budgets differ from personal budgets in terms of their size and scope. The former involves activities which are larger in size and more detailed in scope. The second significant difference between business and personal budgets is the presence of extensive negotiation between the divisions and corporate headquarters during the preparation of business budgets. There are certain behavioral factors that complicate the budget negotiation process such as the incentive of building slack, asymmetric distribution of information, and unwillingness to share information. We will review these factors in this section because they are relevant to this thesis.  2.1 Incentive to Build Slack Budget processes can be initiated either "top down" or "bottom up". Both of these approaches involve certain degree of participation. The participation gives line managers the power to establish the content of their budgets which would eventually be used as an operational yardstick to evaluate the performance of their divisions. Knowing this fact, managers tend to build "slack" into their budgets by "underestimating revenues,  P.10  overestimating costs, or overstating the amount of inputs necessary to manufacture a unit of output"( Siegel, Ramanauskas-Marconi, 1989, p. 140). Cyert and March (1963, pp. 36-38) defined slack as the difference between "the total resources available to the firm and the total necessary to maintain the organization coalition" (Ezzamel, Hart, 1987, pp. 358). Therefore, "slack is the difference between the resources that are actually necessary to efficiently complete a task and the larger amount of resources that are earmarked for the task" (Siegel et al., 1989, p.140). Budgetary slack represents a degree of padding introduced into budgets so as to guard against possible failure to reach targets (Arnold, Hope, 1983, p. 290). Essentially, by doing so, the budgetees are making the budget an easier target for them to achieve. Since the 1960's, numerous studies have been constructed to investigate this topic.  It became  apparent that slack exists within even the most efficient and tightly controlled organizations. Some researchers argue that the existence of slack is unavoidable "because human nature requires it to exist" (Arnold et al, 1983, p. 290). In addition, it was suggested that if budgetees are given no flexibility in managing their budgetary constraints, "conflict will quickly arise between the individual's personal goals and those of the firm" (Ibid.).  2.2 Asymmetric Distribution of Information Building slack is made possible because of the asymmetric distribution of information in corporations. This phenomenon is particularly true in a budgeting situation considering the budget is prepared and submitted by budgetee regarding their own situation and predictions.  Since managers possess more accurate and up-to-date information (either  P.U  quantitative or qualitative) on their own divisions when comparing to headquarters, this imbalance in information gives them the ability to legitimately manipulate data in order to build slack.  For example, let's consider the case of an international company with  headquarters located in North America and one of its divisions operating in Asia. Compared to headquarters, the divisional manager in Asia will always likely have more up-to-date information on local economic conditions, government regulation changes and labor movement trends. The divisional manager, upon receiving the information, can decide to react, and communicate this information to headquarters in a manner that benefits the local division. This level of autonomy and flexibility can only be carried out under the premise of not violating the internal control policies of the corporation.  2.3 Unwillingness to Disclose and Share Information Managers are not motivated to share and fully disclose information under the current participatory budgeting practice.  "Argyris noted that emphasis on budget attainment  resulted in many employees being task-centered and many supervisors being departmentcentered" (Ezzamel, Hart, 1987. p. 352). Thus, the relationship between departments is ignored and focus is placed on individual departmental success. In order to excel over their organizational counterparts and divisional rivalries, managers will not likely share information with each other. In addition, participatory budgeting encourages the manipulation of data and the selective disclosure of information, as proven in the case of building slack into budgets. Thus, managers are unwilling to make known what seems to be their "own" portion of  P.12  information since the disclosure of this information, regarded as the private property of the divisional manager, will likely leave them in a "vulnerable" position when challenged and asked to justify the validity of their budgeted figures.  2.4 Other Difficulties Researchers advised us that, in the administering of the budget program, management should not use it as a pressurizing tool to force employees to unfairly assume responsibility for certain problems (Carruth, McClendon, and Ballard, 1983). However, the very same study also told us that budgeting is often used as a pressure device and great emphasis is placed on meeting the budget under all circumstances. Negative emotions, hostility, tension, and mistrust rather than greater cooperation and productivity often accompany the budgeting process (Garrison et al., 1990, p. 417). "Similarly, Hughes (1965) described the endless cycle of the conventional budgetary control process" (Ezzamel, Hart, 1987, p.352). In Hughes' analysis, the endless cycle of unresolved conflict is caused by the failure of top management and lower management to recognize one another's needs. In an organization, he concluded that, lower management needs flexibility and top management needs control. "Thus, top management pursues its need for control by placing greater emphasis on the use of budgets and rules ... Lower management pursues its quest for flexibility by general avoidance of controls and rules, particularly budgets" (Ezzamel, Hart, 1987. p. 352). The more lower management violates the rules, the more top management sees itself losing control. As a result, more rules are  P.13  introduced to the organization in hope of regaining control. Therefore, lower management violates these rules to gain flexibility, and so the cycle repeats itself. Although, strictly speaking, the issues identified in this section are not related to this thesis directly, they serve as background information to illustrate the degree of complexity of the budgeting process.  2.5 Conclusion Among all the above discussed difficulties and challenges encountered in the budgeting process, it is suggested that budgeting is a complicated process, thus making automation more difficult. Since human participation in the budgeting process is essential, it would be neither practical nor efficient to try to automate and eliminate human involvement in every stage of the budgeting process. Effort should be diverted to design a set of protocol and a system to assist human participants in communicating and preparing budgets. "Thus, by automating certain ... activities, human involvement is limited to those aspects that cannot be automated" (Chang & Woo, 1994). Specifically, effort should be focused on automating the information clarification aspect of the budgetary process and this will be discussed throughout the remainder of this paper. In other words, one cannot completely eliminate the human factor in negotiation. Automation can only be applied in the mechanistic steps of the budget negotiation, the narrowing down of differences by exchanging information so that the budgetees and budgetors can reach a common ground for negotiation.  P.14  Based on the identified difficulties and challenges of the budget process, and the knowledge of behavioral aspects of the participants, it should be a safe strategy to automate to the extent that encourages the parties to share a sufficient amount of information. In other words, automation should allow the parties to share and exchange only those data necessary in solving the problems and leave the rest alone. Also, with automation in place, budgeting parties should also be guaranteed autonomy. It would be impractical to expect the divisional managers to surrender all their information. Automation can be viewed as a vehicle to strip away authority.  P.15  Chapter Three CASE STUDY - NATIONAL MOTORS INC. The National Motors Inc. Case (Anthony, Dearden, and Govindarajan, 1992, pp. 456467), prepared by J. Hekimian under the supervision of R. N . Anthony, serves as an excellent example to illustrate the typical budget preparation process with concentration on the information clarification aspect.  The case describes a typical budgeting situation  involving two parties, a division controller as the budgetor, and the manufacturer's office as the budgetee.  The process is initiated by the manufacturer's office which submitted a  supplemental budget proposal. Each of these parties then presented their own reasoning by exchanging data and clarifying information. Finally, after all information was presented, the controller was left with several alternatives to proceed to the next step, which is either to  PJ6  concur with the supplemental budget request or to continue his position. The National Motors Inc. Case is summarized as follows: 2  1 Case Summary 1.1 Organizational structure before consolidation National Motors exercised strong budgetary control.  Proposed budget and  supplemental budgets were to be analyzed, revised, consolidated, reviewed and approved first within a division and then at the corporate level. Panther and Starling were two separate division of the National Motors Inc. Each of them had its own manufacturing activities and budgets. The partial organizational structure of National Motors is outlined in the following figure (Figure 2).  National Motors Inc.  Controller  Panther Division  Starling Division  Panther Manufacturing (manual system)  Starling Manufacturing] (computerized system)  Before Consolidation Figure 2. Organizational Chart of National Motors Before Consolidation (Partial)  2  A copy of the National Motors Inc. case is included in the appendix of this thesis.  P.17  1.2 Organizational structure after consolidation During the last quarter of 1982, Panther Automobile Division had absorbed the manufacturing activities of the Starling Automobile Division (Figure 3).  National Motors Inc.  Controller  Panther Division  Panther & Starling Combined Manufacturing Activities (Computerized System)  Starling Division  After Consolidation  Figure 3. Organizational Chart of National Motors After Consolidation (Partial)  1.3 Original budget after consolidation The approved budgets for 1983 for these two departments had already been submitted and approved separately prior to consolidation. Therefore, there were two separate budgets for the two manufacturing departments. In addition, the manufacturing activities of Panther division was making the transition from a manual system to a fully computerized system, similar to what Starling had already been practicing for a period of time.  P.18  The budgets of the two manufacturing offices were combined upon consolidation and treated as the revised budget for Panther's manufacturing office (Table 1). The  Panther  Starling Personnel $'000 Personnel $'000 Personnel $'000  Budget before Consolidation  76  $1,444  55  $1,336  131  $2,780  (24)  Savings from consolidation Savings from computerization  (368) (276)  (23) 84  $2,136  Table 1. The Original Combined Budget  combined budget was created by combining the original budgets of the two divisions with adjustment for savings from consolidation and savings from computerization.  1.4 Manufacturing Office: Supplemental budget proposal Due to a change in the activity level, in April  1983,  the  new  Personnel  consolidated 109  manufacturing  office  Dollar Amount  submitted  $2,916,000  a  Supplemental budget proposal (Table 2) tO  Table 2. Manufacturing Office: Supplemental Budget Proposal  request an increase in personnel levels in order to handle the combined work load. The request was supported by detailed breakdowns of each department.  P.19  1.5 Controller's Office: Supplemental budget proposal However, the controller's office did not concur with the  manufacturing  office's proposal. It disagreed with the  Personnel 84  Dollar Amount $2,256,000  manufacturing office's interpretation of Table 3. Controller's Office Supplemental Budget Proposal  the numbers. Therefore, it proposed its own version of the revised budget (Table 3) which was also supported by detailed calculation and breakdowns. This version of the budget proposal had a slight increase in dollar figures which narrowed the dollar discrepancy between the two parties. The controller insisted on the same staff levels. 1.6 Protest from the Manufacturing Office The manufacturing office did not accept the controller's proposal. They attacked the invalidity of the controller's proposal and presented more supporting data to justify their original supplemental budget proposal. A summary of the case is included in the following table (Table 4).  P.20  Stage  ACTION: • Presented manufacturing's supplemental budget proposal. ARGUMENTS: 1. There was a direct relationship between number of parts and personnel levels 2. The increase in parts to be handled caused the need to increase personnel levels 3. Therefore, the increase in budget was justifiable Stage N/A 2 1  Stage  3  ACTION: • Presented more reasons and additional supporting data. ARGUMENTS: 1. Although a computerized system should not cost more than a manual system, the increase in budget they requested was justifiable due to the following reasons: • Work-load increase which was more than the estimated figure used by controller's office. • Increase in Salary Mix • Non-recurring cost penalties 2. The computerization plan would bring in future savings which was not currently taken into consideration.  Table 4. Summary of the Case  N/A  ACTION: • Declined the manufacturing office's proposal. • presented controller's supplemental budget proposal. ARGUMENTS: 1. Computerization should bring forth major improvements when compared to a manual system. 2. The manufacturing office had committed to saving personnel, therefore the revised budget should maintain this commitment. N/A  P.21  1.7 Discrepancies to be reconciled Finally, after three rounds of information exchange, the two parties were left with discrepancies in number of personnel and dollar amount of budget to be resolved (Table 5).  Personnel Manufacturing Office Controller's Office Discrepancy  Amount (000s)  109 84  $  2,916 2,256  25  $  660  Table 5. Discrepancies to be Resolved  2 The Difficulties of the Case The National Motors Inc. is such a complicated case that it took us a relatively lengthy period of time to comprehend and to solve the case manually. The complexity of the case is rooted in the difficulties of the budgeting process identified in Chapter 2 of this thesis; namely; incentive to build slack, asymmetric distribution of information, and unwillingness to disclose data. In addition, the abundant information presented in the case, whether they were relevant or irrelevant to the real issues, also contributed to the case's complexity.  2.1 Incentive to Build Slack Based on the limited amount of information given in the case, we do not know whether the manufacturing office had in fact an incentive to build slack into their supplemental budget proposal, however, the controller's office perceived the situation in this fashion. The controller's responded to the manufacturing office by making the comment that "the manufacturing office had committed itself to a saving  whereas the current proposal was  P.22  ... over the levels committed" (Anthony et al, 1992, p.462). This presupposition caused the controller's office to partially dismiss the manufacturing office's proposal and to present their own supplemental budget proposal.  2.2 Asymmetric Distribution of Information Being closer to the source of information, in this case, the manufacturing office had more updated data on the average salary mix and the activity level after reorganization. Therefore there were essentially two versions of data residing in National Motors Inc. internally. One set of data was owned by the controller's office and the other, more updated version, by the manufacturing office. This difference caused two different sets of beliefs to arise within the controller's office and the manufacturing office.  2.3 Unwillingness to Disclose and Share Information versus Information Overload In this case both parties demonstrated their willingness to share information as needed. However, the very same willingness to disclose information caused another problem information overload. It was observed that, very often, a massive amount of additional information was provided to explain a point. This information overload would only cause the other party to ignore the piece of information entirely. For example, at the beginning of the case, the detailed calculations provided by the manufacturing office to support their request to increase personnel were largely ignored by the controller's office. On the other hand, the details of the controller's recommended budget which presented more detailed support to justify its supplemental budget proposal was also dismissed by the manufacturing office.  P.23  3 The REAL Issue of the Case The manufacturing and controller's office focused their attention on the differences in their total budgeted figures and the total number of personnel. However, the scope of these differences was so large that the two parties did not even have common ground for negotiation. In addition, the two parties jumped on budget negotiation so prematurely that they failed to recognize the real agenda of their negotiation.  Unless the asymmetric  distribution of information was clarified and the sources of discrepancies pinpointed by tracing the detailed composition of the overall figures, no real negotiation could begin.  4 Reconciliation Algorithm The logic for reconciling the differences in the budget approval process were studied. By studying the process, the mechanistic steps involving in the process of narrowing down the differences of the two parties during the budget negotiation can be identified since the mechanistic steps are the best candidates for computer automation. In other words, studying the mechanism of the mechanistic portion of the budget negotiation cycle helps to identify the activities that have the potential to be automated. An algorithm of the process and logic are summarized in the following flowchart. The algorithm includes such functions as comparing the request against known data, raising intelligent questions to request supporting data, and marking the request with the status of "approved" or "source of discrepancy". The result of the algorithm, will essentially help to identify a list of discrepancies which can be used a basis for the two sides involved to start  P.24  their negotiations. The ultimate goal of automation should support the activities outlined in the flowchart (Figure 4). The algorithm was constructed based on the view of the controller's office which started by comparing the total budget figures and personnel levels submitted by the manufacturing office against his/her own version of the numbers. If the numbers fell in a reasonable range, the budget would be approved and no further checking would be needed. However, if the submitted numbers did not match the controller's own version or exceeded the preset limit, a request would be sent to the manufacturing for more information. If there was no additional information available for a number, it would be marked as a source of discrepancy. If additional information were supplied, the algorithm would be repeated to check the validity of these subsequent supplied data.  Figure 4. Logical Flow of Activities  P.26  5 A Simplified Solution of the Case In order for the two parties to have a common basis for negotiation, the causes of discrepancies must first be identified. Only after the differences were reconciled, the factors accounting for differences identified, and the dollar impact of each factor understood, could the two parties negotiate on the real agenda. The solution seems trivial and straightforward enough that no automation is needed. However one should bear in mind that this sense of straightforwardness is achieved after lengthy analysis and gathering of relevant data from the case. Though the manual process is time-consuming and requires a high level of sophistication in accounting knowledge, the mechanistic portion of it can be automated to save time and resources so that the human players of the process can devote their time to more meaningful tasks such as the negotiation of the budget by concentrating on the list of numbers marked as "source of discrepancy". According to the analysis of the case, some of the disputed differences can be attributed to workload increase, and other parts attributable to salary mix change and unanticipated one-time computerization implementation costs.  These pieces of  information are, however, scattered throughout the case. The activities and data cited to support both parties' claims during the 3 stages of information exchange are outlined in the following table:  P.27  S o u r c e s of DescreDencv  Amount  One-Time Cost Salary Mix Change Work Load Increase Descrepency (given)  $224,610 183,120 252,270 $660,000  Table 6. Sources of Discrepancies in Dollar Amount  The sources of discrepancy come from three main areas: one-time computerization costs, salary mix changes and work load increases due to reorganization. The detailed dollar figures are presented in the next table (Table 6).  The following table shows the  discrepancies attributable to one-time costs, from computer and salaries (Table 7) calculated based on information supplied in the case. One-Time Cost (Stated in the Case, D.4651  Computer Salaries  $80,000 144,610 $224,610  Table 7. Discrepancy Caused by One-time Costs  In Table 8 discrepancies caused by changes in salary mix are calculated and presented. Salary Mix Chanae Average Salary 83 Average Salary 82  # Personnel Total Salary $15,768 $14,088  109 109  $1,718,712 1,535,592 $183,120  Table 8. Discrepancy Caused by Salary Mix Change  Solving the case manually helps to identify the objective of successfully automating the budgeting process. Specifically, an automated system should help the negotiation parties to identify and focus their negotiation efforts on the sources of discrepancy identified in the above three tables.  P.28  Chapter Four AUTOMATION - CURRENTLY AVAILABLE TECHNOLOGIES  1 Potential for Automation The budgetor and budgetee had to manually go through all the steps of exchange of information as described in the Case Summary chapter in order to clarify differences in information. They then had to identify the sources of discrepancy by performing a series of calculations, some of which are described in the Case Solution section of the last chapter. Unless these steps were carried, they could not begin their negotiation on the "real agenda". Therefore, if this process was automated, time and resources could be saved so that efforts could be directed towards resolving the real issues. Ideally, an automated system could be designed by following the algorithm described in the last chapter to handle the task of  P.29  narrowing the scope of differences. That is to say, the automated system should be able to "pull" relevant information from both parties databases and narrow the differences until the specific sources of discrepancy are pinpointed so that decision makers can be called upon to carry out negotiations. Therefore, the final product of automation must provide information storage, mathematical calculation and logical reasoning capabilities. This chapter evaluates a number of information technology tools available on the market to support budget automation. Some of these tools are already employed extensively in the field of accounting, or more specifically, budgeting. On the other hand, some of the tools still in the stage of research and development and are not yet widely adopted by the business world.  The following tools are being evaluated individually in terms of  functionality they provide and how well they address the areas of information storage, mathematical calculation and logical reasoning capability.  2 Spreadsheet Spreadsheet applications are computer programs that allow you to create and manipulate spreadsheets electronically. In a spreadsheet application, data are organized on a cell basis. The type of data and value in each cell can be defined individually. In addition, the relationships between cells are defined by formulas, which could be mathematical formulas, statistical formulas or financial formulas. Once the data is entered, and values and formulas are defined, any changes made to the individual cell will automatically be reflected in the related cells. This feature enables the user to perform various types of analysis. Lotus 1-2-3 and Microsoft Excel are the most popular spreadsheet applications on the market. There are other advanced features, such as graphical representation and macro language,  P.30  present in the spreadsheet to allow users to manipulate data and perform analysis in order to extract more meaningful and informative facts. The ease of use of spreadsheets has contributed to their popularity in the business world today. It brings a certain degree of automation to the budgeting process by acting as a powerful calculator. However, it fails to deliver an answer to our requirements since it does not address the logical reasoning capability. The budgetor and budgetee can store their data and perform calculations by using spreadsheets. However, they still have to compare figures and trace differences manually.  3 Relational Database Management Systems (RDBMS) Relational databases "organize data in simple two-dimensional tables ... which can support powerful data manipulation ... and is much more flexible" (Reynolds, 1992) because the same database can be viewed in many different ways. RDBMS is a group of applications that allow users to perform data management , which are "data collection, storage, and retrieval" (Rob, 1993), on relational database. Although there are a number of different types of DBMS, RDBMS is still by far the most popular one in the market and in fact "almost every vendor's announcement for new database management software is a relational product" (Reynolds, 1992). For the purpose of budget automation, again like spreadsheets, RDBMS can provide a partial solution by providing data storage and retrieval capabilities. However, they suffer from a similar drawback as spreadsheet applications.  Using RDBMS, users are still  expected to calculate and compare results manually. In addition, this technology does not  P.31  provide the budgetee and budgetor a mechanism for interacting and communicating. A higher degree of automation, which exceeds the capability of RDBMS, is required.  4 Object-Oriented Database Management System (OODBMS) "During the past few years the data-management and application environment has become far more complex" (Rob, 1993) and such complex application environment called for a new type of DBMS, Object-Oriented Database Systems. OODBMS "use a subset of Object-Oriented concepts and the Object-Oriented data-model features"(Rob, 1993). Although OODBMS is still in the infancy stage of research and development, it offers a much needed versioning feature for automating budgeting process. It is not unusual for negotiating parties to revise the estimates of their accounts when preparing budgets many times, therefore for recording purposes, it is necessary to maintain the record of different versions of the account. Versioning was originally designed "to allow the tracking of the evolution of object states" (VERSANT ODBMS, 1995, p. 7-1) and "allow multiple users to share access to the same objects, enabling each to update those objects as necessary without interfering with other users" (Loomis, 1995). When automating the budgeting process, this feature provides a convenient way to keep track of the changes made to accounts. However, OODBMS fail to provide a mechanism for users to reconcile differences. It is far from satisfactory to support the budgeting process.  P.32  5 Accounting Software Accounting software is the name of a class of computer programs that perform accounting operations.  Popular accounting software packages available on the market  generally support the functions for general ledger, accounts receivable, and accounts payable.  More sophisticated systems also support functions for payroll, inventory,  invoicing, and fixed assets. Some high-end systems even support sales analysis, budgeting and forecasting. Products like SAP, PeopleSoft, ACCPAC Simply Accounting etc. provide a spectrum of choices for businesses (information of these applications can be found at their company websites).  The size of these applications range from providing support for  business transactions of large corporations to small grocery stores. Using these products, users can carry out detailed accounting functions, generate reports and perform advanced analysis, but none of them provide support for budget negotiation.  6 Software Available Supporting Negotiation Narrowing the scope of difference is both studied and documented by other researchers.  However, no work has been done to automate this stage.  For example  Researchers, such as ManKit Chang and Carson Woo, recognized that clarification of information and narrowing of differences before negotiation are important steps involved in negotiation. However, their Speech-Act-based Negotiation Protocol (Chang and Woo, 1994) only lay down communication protocol. Because the actual automation of narrowing the differences is only one small step in the negotiation protocol study, it is not covered here in depth.  P.33  In addition, the concept of narrowing down the scope of differences introduced in budgeting is not the same as "Narrowing the difference" in Gulliver's 1979 paper since his eight-phase procedural model of negotiation does not involve the exchange of information. The negotiators mentioned in his model are merely trying to narrow the differences by examining identical sets of data, whereas in budgeting new data can be introduced by one of the negotiation parties at any point in time. Narrowing the differences consists purely of exchange of information and no tactics are involved. Yet, this is an essential step that the negotiators must go through before two parties can have common ground for negotiation. Group decision support systems such as PERSUADER (Sycara, 1991) and NEGO (Kersten, 1991) that support negotiation attempted by researchers do not help in narrowing down the differences between negotiation parties, rather they try to help the players win the negotiation. However, this is not the objective of the automation proposed in this thesis.  P.34  Chapter Five IMPLEMENTATION Based on the information collected and analysis performed on the National Motors Case, a system is created to demonstrate the use of information technology in automating part of the budgeting process. In addition, this system is used as a prototype to study the benefits and limitations of this type of system and to uncover the difficulties encountered during the development of the system for future reference. The system runs on a Windows platform with SWI-Prolog installed. This system is written in Prolog language in order to take advantage of its "powerful inference mechanism based on resolution" (Van Le, 1993). Also the declarative style of predicate calculus of the language provides a convenient way for data storage. This chapter explains the logical and structural design of the system by presenting the design algorithm and the system structural chart. In order to store the accounting data in the  P.35  system so that the system can function based on the existing known data, a mechanism for representing the knowledge in Prolog was developed and presented in the chapter. The data provided in the National Motors case were fed into the system for testing. Finally the testing results are summarized in the last section of this chapter.  1 Algorithm for implementation The information clarification process and budget approval process summarized in Chapter Three (Figure 4) of this thesis were analyzed and revised to serve as a foundation algorithm for building the system. The revised algorithm is summarized in the flowchart below (Figure 5).  P.36  Compare the first item in the budget proposal against data stored in knowledgebase  Select the next item  Marked as approved  Marked as a source of discrepancy  Query budget initiator for departmental account information  i  Query budget initiator for subaccounts information  J  4i  Query budget initiator for the equation used  Figure 5. Logical Design of System  P.37  This revised algorithm contains detailed step by step logical design of how a budgetary request would be handled, for example the supplementary budget proposal in the National Motors Case. The algorithm explains certain critical steps that must be undertaken before an item can be approved or stamped as a source of discrepancy.  1.1 Assumptions Used in the Algorithm Certain assumptions are made in the algorithm: 1. The term "item" in the algorithm refers to a particular account submitted by the budget initiator in a pre-defined format that is understood by all parties involved. 3  2. The term "limit" refers to a tolerance level that specifies the percentage of deviation allowed for in a budget request. This piece of knowledge is predefined for and specific to each account and can vary from account to account. For example, a 5% limit for the Total Expense account means the account will be approved as long as the requested amount falls within ±5% of the predefined amount.  1.2 Initial Checking The system is started after receiving an initial budget request. To begin with, it checks the first requested item against the data stored in its own database. For example, a request for a budget of $120,000 is received from an Asian operation at the corporate headquarters. The system compares this amount against the amount of the same account stored in the headquarters' database. If the headquarters' data agrees with the requested item, it would be approved and the next item in the requested item list will be  P.38  checked following the sequence of the list. However, if the headquarters' data specifies that the estimated amount should only be $100,000 for the Asian operation, the system will continue to perform more checking in order to determine what causes the $20,000 discrepancy. Further checking procedures are being conducted by disassembling the item into smaller sub-accounts according to certain schemes that are understood by all parties. These checking procedures are not conducted in any particular order. However, an account cannot be labeled as a source of discrepancy unless it has failed all the tests in the subsequent checking procedures.  3  The format of the account will be further discussed in the latter part of this chapter.  P.39  1.3 Further Analysis - Departmental Accounts Following the failure of initial checking, the system analyzes the budget item by breaking it down into smaller components and requesting Request for d e p a r t m e n t a l account information  the  budget  initiator to  information on them.  submit  The system  then checks these components by going through the returned data. For example, following the  Read reply  example in the previous section, the system checks the headquarters' database to see if the total budget figures can be broken down into departmental accounts, i.e. Asian Yes  1 Store the additional information in a list for checking  division A budget, Asian division B budget.  The system then sends a  request to the budget initiator for breaking  the  $120,000  into  subsequent Division A and Division B accounts. If the initiator does not Figure 6. Further Analysis - Checking Divisional Sub-Accounts  want to submit the data in the  P.40  requested format, he/she can simply choose to refuse the request. The system will attempt to perform other tests by asking for information organized in another format.  P.41  1.4 Further Analysis - Categorical Subaccounts If the total budget cannot be broken down into departmental accounts, the system will attempt to analyze the total 1  Reque st for subaccount information  budget figures by breaking  them down  into sub-accounts of types of expense or revenue. For example, if the information of division A and B is not available from the  Read reply  Asian operation, the system will attempt to check if the total budget can be broken into sub-accounts, i.e. Asian Marketing Expense, Asian Salary and Wages, Asian -No-  Office Expenses. The system then sends a request to the budget initiator for breaking Yes  the $120,000 into the following categories: Store the additional information in a list for checking  •  Asian Marketing Expense  •  Asian Salary and Wages  •  Asian Office Expenses. If no information is returned from the  budget initiator, the next test will be Figure 7. Further Analysis - Categorical Sub-accounts  carried out.  P.42  1.5 Further Analysis - Equation If  the  information of sub-  Request for equation  accounts of expenses or revenue is not available, the system  Read reply  checks whether the item -No-  is calculated  according  to some  equations stored in Yes  the Compare the equations used by budgetor initiator and the current system  system.  system  The  sends  a  request to the budget initiator  for  information  on the  equation. receiving Store the equation components in a list for checking  from  the  After a  reply budget  initiator, the system will  compare  submitted Figure 8. Further Analysis - Equation  the  equation  and figures against  P.43  the ones stored in its own database. For example, the system checks whether the $120,000 is calculated based on an equation, i.e. L a s t Year's A c t u a l Budget x I n f l a t i o n Rate x Currency F l u c t u a t i o n + Contingency Allowance = C u r r e n t Year Budget Proposal  If the result is affirmative, the system sends a request to the Asian operation's system for submitting the equation used by the budget initiator and the numbers they used when calculating the total budget.  1.6 Iterative Approach The above 3 analysis methods are performed on every piece of information submitted by the budget initiator, regardless of whether it is part of the original budget proposal or an answer in reply of a query. An item will be marked as "Source of Discrepancy" when all 3 analyses performed and the item cannot be further divided into smaller components.  2 Structural Design of the System The structure of a running instance of the final complete system that supports all the activities described in the previous section is represented in the following diagram (Figure 9). The system consists of a main reasoning engine which performs the three analyses outlined in the previous section on submitted items. The Main Reasoning Engine also contains an Input/Output Handler module which provides the functionality of querying other systems for information needed and interpreting any replies from other systems.  P.44  There are also a number of modules that are external to the Main Reasoning Engine, namely; the Account Database and its subsequent components, and the Equation Simplification Engine. These modules are explained in the following sections.  2.1 Main Reasoning Engine Main Reasoning Engine  This module contains the main reasoning process which goes  through  the  list  of  submitted items and performs analysis Account Database  Equation Simplification Engine  on  each  of  the  individual items.  It sends a  query to other  systems for  additional information required to  pinpoint  the  source of  discrepancy.  2.2 The Equation Simplification Engine Corporate Hierarchy  This module supports one of the analyses performed by the  Figure 9. System Structure  Main Reasoning Engine - the equation analysis. The equation analysis test to checks whether the equations used by two parties to calculate an account are the same. This particular module simplifies equations in their simplest terms. For example:  P.45  2x(3X + Y ) - 2 Y = 6X By using this module, we can also check the equality of any two equations. For example, two different equations are used in two departments to calculate the value of an account: Asian Division: 2 X (3X + Y) Singapore: 6X + 2Y The equality of these two equations can be tested by combining them in the following way and feeding the combined equation into the Equation Simplification Engine: 2x(3X + Y ) - 6 X - 2 Y  Since the engine always tries to simplify the equation in its simplest terms, in this case the result will be 0. Therefore, as long as the individual variables of the equations are defined, we can safely conclude that two equations are identical if their difference is 0.  2.3 The Account Database This is the database that contains all the account records. For each account, the following information is stored in the database; namely, the account number, account owner, measurement, version number, account value. The account representation will be discussed in detail in the following section. There are two pieces of modules used by the Account Database to record and establish the relationships among accounts. As can be seen in the System Structure diagram (Figure 9), they are the Divisional Sub-total module and the Corporate Hierarchy module. Using  P.46  the information stored in these two modules, the system establishes the relationship that the value of any account is the sum of the corresponding account of all divisions under the control of the owner of this account. For example, for a company with an Asian division established to control operations in Hong Kong, China, Singapore, the system will automatically treat all accounts under the Asian division as the sums of their corresponding accounts in the three regions, i.e. Asian Operational Expenses = Hong Kong Operational Expenses + China Operational Expenses + Singapore Operational Expenses.  3 Knowledge Representation This section discusses how account information is stored in the database. In order for the system to perform analysis on budgetary items, certain information must be contained in the database such as the account number, account value and account owner.  A l l this  knowledge that is specific to this case are represented as facts. A system is designed to represent the knowledge for storing and retrieving the data efficiently. This knowledge representation convention is developed by following the chart of accounts outlined in the Principles of Accounting by H. A. Finney (Finney, Miller and Mitchel, 1965).  3.1 Basic Components of an Account The facts are stored in a nomenclature system that allows the system to identify the information related to accounts. The facts generally take the following form: account(KEY,  [VALUE], DEVIATION ALLOWED)  where as KEY allows the system to uniquely identify the account, [VALUE] is a list of numbers containing the account's current and any historical values, and DEVIATION  P.47  ALLOWED tells the system how much deviation in this account can be tolerated by the reasoning engine when analyzing a budget proposal containing this account. For example, account(KEYl,  [ 9 9 . 5 , 90, 8 2 ] ,  0.025)  represents the fact that the account which can be uniquely identified as K E Y l has a current value of 99.5 and its historical values are 90 and 82 respectively, and this account can still be approved if it is exceeded by no more or less than 2.5%. Currently the deviation allowed is interpreted as plus or minus the percentage of the original value. It is possible to adjust the system to just having an upper level limit or one lower level limit depending on the nature of account.  3.2 Account Key In order to identify and compare accounts, we need more information than just values and deviation allowance. Using the above example, the knowledge of "account K E Y l has a value of 99.5" can be established. However, the system has no knowledge whether this number, "99.5", refers to dollar amount or number of personnel. Therefore, the KEY component is expanded to contain the following four pieces of data: TYPE, ACCOUNT NUMBER, UNIT and OWNER. The complete structure of the account is as follows: account(key(TYPE, DEVIATION ALLOWED)  [ACCOUNT NUMBER], UNIT, OWNER),  [VALUES],  This is best illustrated by the following example: account(key(exp,  [2916000], 0.1)  [1,  0,  0,  0],  dollar,  manufacturing),  This fact tells the system that the account it is dealing with is, in fact, an expense account (represented by the keyword exp) which has the account number of [1, 0, 0, 0], is owned by  P.48  the manufacturing office (manufacturing), has a value of $2,916,000, and cannot exceed or fall below 10% of its original value. The following table (Table 9) provides examples of some of the keywords used to represent the information in the National Motors Case for each account component.  ACCOUNT COMPONENT '"Type"'  Unit  Owner  :  KEYWORDS  •J j•  exp • rev • asset • person • dollar • parts • Manufacturing ] • Controller  LEGEND • • • • • • • •  Expense Revenue Asset Number of people Dollar amount Parts count Manufacturing Office Controller's Office  Table 9. Examples of Keywords Used in the National Motors Case  3.3 Account Number The last example shows a list representation of the account number ([1, 0, 0 , 0]). An important feature of this list representation of the account number is that it allows the representation of a hierarchical order of accounts and sub-accounts (Table 10). This hierarchical structure of account numbering provides a convenient method of representing the relationship between master account and sub-accounts.  P.49  ACCOUNT Total Expenses  ACCOUNT NUMBER [1,0, 0, 0]  Total Expenses - Accounting  [1,1,0, 0]  Total Expenses - Production  [1,2, 0, 0]  Production - Personnel Exp  __  Production - Machinery Exp  [1, 2, 2, 0]  Table 10. Hierarchical Order ofAccount Numbers  4 Testing The system is developed and tested using the data provided in the National Motors Case. The goal of the testing is to solve the case with the assistance of the system. The implementation is deemed successful if the system is able to identify the sources of discrepancy.  In other words, the system is successfully implemented if its final result  matches the results derived manually in Chapter 3 of this thesis.  P.50  In order to simulate communication and exchange of information between the controller's office and the manufacturing office, we assume that both the manufacturing office and the controller's office possess their own copies of the system with separate databases containing data that reflects their knowledge of the situation. The communication between two parties is achieved through file sharing. The following diagram depicts the  Main Reasoning Engine  Main Reasoning Engine  _ Communication "(Qutry and Submit InlormatlonT"  Equation Slmpllllcallon Englna  DMilonal Subtotal  DMtlonal Subtotal  Corpora), Hlararctiy  Contnlhr'f  Corporatt Hierarchy  Dtltbttt  Manufacturing  DtUbatt  Figure 10. Relationships Between Testing Systems  relationship of the two systems (Figure 10). As illustrated in the above diagram, the two systems have identical components except for the account data residing in the database. These two versions of databases are necessary since the two parties possess different knowledge of the situation. The different knowledge causes diff erences in beliefs when they develop and evaluate the initial budget proposal. The purpose of the system is to narrow differences by exchanging and sharing information between the two parties.  P.51  4.1 The Screen Capture The system is tested by using data from the National Motors Case. Two instances of the system are being run under Windows95 environment to simulate the situation of two separate systems used by the budgetor and budgetee.  The following screen (Figure 11)  shows the initial response of the Controller's system after receiving the initial supplemental budget proposal. It attempts to check the submitted proposal against its own record. Upon realizing that its own record does not seem agree with what has been submitted, it sends a request to the manufacturing office's system for more information.  f l S W I - P r o l o g (version 2.1.14) | sys / subtotal compiled, 0.05 sec. 956 bytes. | sys / simplify compiled. 0.50 sec. 57.472 bytes. |: sys / engine compiled. 0.82 sec. 76.844 bytes. \ main compiled. 0.99 sec. 83.812 bytes.  I Yes \ 2 ?- t. \ Checking the f o l l o v i n g item: account(key(exp, [1.0,0,0], d o l l a r , manufacturing), j [2916000]. 0.100000. Manufacturing t o t a l budget) \ The requested item: Manufacturing t o t a l budget (key(exp, [1,0,0,0], d o l l a r , manu { facturing)) exceeds l i m i t . | Ask the originator to supply information on subsidiary d i v i s i o n s . \ Writing command f i l e to request d e t a i l of Manufacturing t o t a l budget (key(exp, [ i 1,0,0,0], d o l l a r , manufacturing))  |  | Please s t a r t another instance of prolog to generate response. \ When response i s received, type 1 to continue the current process.  Figure 11. Controller's Initial Response  ii§ll  P.52  The manufacturing office's system attempts to answer the request by checking its own database for information. It finds out that the requested information is not available, and sends a reply back to the requester (Figure 12). The Controller's system then applies the second test to the budget proposal by reorganizing the account in the format of categorical sub-accounts and sends a second query  I j j S W I - P r o l o g ( v e r s i o n 2.1.14) Welcome to SWI-Prolog (Version 2.1.14) [ Copyright (c) 1993-1995 University of Amsterdam. A l l r i g h t s reserved. | For help, use ?- help(Topic). or ?- apropos(Word). 1 ?- [nan]. sys / man_acc compiled. 0.06 sec, 7,692 bytes. sys / control compiled. 0.05 sec. 932 bytes. I sys / subtotal compiled. 0.00 sec, 956 bytes. | sys / s i m p l i f y compiled, 0.39 sec, 57.608 bytes. \ sys / engine compiled, 0.55 sec. 76.980 bytes. | man compiled, 0.66 sec, 85,068 bytes. Yes \ 2 ?- respond. I The requested data i s not available. (  Ho data v i l l be provided.  \ request compiled, 0.05 sec, 120 bytes. Yes 3 7-  Figure 12. Manufacturer Unable to Provide Information  to the manufacturing office's system (Figure 13) to ask for information in this format.  P.53  iMSWI-Prcilcuj ( v e r s i o n 2 . 1 . 1 4 ) Ask the o r i g i n a t o r to supply information on subsidiary d i v i s i o n s .  i|jl§ff  Writing command f i l e to request d e t a i l of Manufacturing t o t a l budget (key(exp, [ 1,0,0.0], d o l l a r , manufacturing))  5  Please s t a r t another instance of prolog to generate response. When response i s received, type 1 to continue the current process.  I: 1. The requested data The requested item acturing)) exceeds Ask the o r i g i n a t o r  „(V  i s not available. Continue to perform the next test. Manufacturing t o t a l budget (key(exp, [1.0.0,0], d o l l a r , manuf limit. to supply information on any c a t g o r i c a l sub-accounts.  1  Writing command f i l e to request d e t a i l of Manufacturing t o t a l budget (key(exp. [ 1.0.0.0], d o l l a r , manufacturing)) Please s t a r t another instance of prolog to generate response. When response i s received, type 1 to continue the current process.  I:  Figure 13. Query Sent After Second Test  This time the manufacturing office finds an answer in its database. It writes the reply to a text file so that the controller's system can read the necessary information from it (Figure 14).  iUSWI-Proloy ( v e r s i o n 2.1.14)  respond. C o l l e c t i n g c a t e g o r i c a l sub-accounts Writing c o l l e c t e d accounts to f i l e request compiled. 0.10 sec, -100 bytes. Yes 4 ?- I  Figure 14. Manufacturing Office's Reply  1  P.54  After reading the reply from the manufacturing office, the controller's system starts to analyze the items included in the reply. It then attempts to either approve or disapprove the items by applying the same type of test (Figure 15).  fiSW.  P r o l o g ( v e r s i o n 2.1.14)  1.0.0.0], d o l l a r ,  manufacturing))  Please s t a r t another instance of prolog to generate response. When response i s received, type 1 to continue the current process.  I: 1. »*• Checking the following item: account(key(exp. [1,1,0,0], d o l l a r , manufacturing), [2320000], 0.100000, Manufacturing personnel expense) The requested item Manufacturing personnel expense (key(exp, [1.1,0.0], d o l l a r , manufacturing)) exceeds l i m i t . Ask the o r i g i n a t o r to supply information on any c a t g o r i c a l sub-accounts.  J  Writing command f i l e to request d e t a i l of Manufacturing personnel expense (key(e xp, [1,1,0,0], d o l l a r , manufacturing)) Please s t a r t another instance of prolog to generate response. When response i s received, type 1 to continue the current process.  J L _ _ ^ ^  „  zl  Figure 15. A New Round of Examinations  When the system encounters an item calculated according to an equation, such as salary expenses, it asks originator to supply the equation. It then sends the returned equation and its own equation to the equation simplification engine to test if the two equations are indeed identical. If they are identical, the system will continue to compare the equations component by component. Otherwise, the system will label them as a source of discrepancy. The following section shows a log file which records the whole process of how the system solves the National Motors Case.  P.55  4.2 Log  This section shows the result of the system which has successfully identified the sources of discrepancy in the National Motors Case. The complete log file is available in the appendix section which was designed to be as self explanatory as possible for each and every step that the system went through. The system was able to identify all discrepancies in the dollar amount. As we recall from Chapter 3, the discrepancies are as follows: Sources of DescreDencv One-Time Cost Salary Mix Change Work Load Increase Descrepency (given)  Amount $224,610 183,120 252,270 $660,000  The system identified the discrepancy caused by One-Time Costs in the following operation: C o n t r o l l e r : *** C o n t r o l l e r : Checking the following item: account(key(exp, [ 1 , 1 , 1 , 0 ] , d o l l a r , manufacturing), [ 1 4 4 6 1 0 ] , 0 . 1 0 0 0 0 0 , Onetime personnel cost) C o n t r o l l e r : One-time personnel cost = 144610 (key(exp, [ 1 , 1 , 1 , 0 ] , d o l l a r , manufacturing)) exceeds l i m i t > NOT APPROVED  C o n t r o l l e r : .*** C o n t r o l l e r : Checking the following item: account(key(exp, [ 1 , 3 , 2 , 0 ] , d o l l a r , manufacturing), [ 8 0 0 0 0 ] , 0 . 1 0 0 0 0 0 , One time computer cost)  P.56  C o n t r o l l e r : One time computer cost =80000 (key(exp, [1,3,2,0], d o l l a r , manufacturing)) exceeds l i m i t > NOT APPROVED Salary Mixed change is identified as: C o n t r o l l e r : *** C o n t r o l l e r : Checking the following item: account(key(exp, [1,9,9,9], d o l l a r , manufacturing), [15768,14088], 0.100000, 1983 Average salary) C o n t r o l l e r : 1983 Average salary = 15768 (key(exp, [1,9,9,9], d o l l a r , manufacturing)) exceeds l i m i t > NOT APPROVED And the increase due to workload is identified as: C o n t r o l l e r : *** C o n t r o l l e r : Checking the following item: account(key(exp, [1,1,3,2], d o l l a r , manufacturing), [252270], 0.100000, Workload increase) C o n t r o l l e r : Workload increase = 252270 (key(exp, [1,1,3,2], d o l l a r , manufacturing)) exceeds l i m i t > NOT APPROVED 4.3 Personnel Discrepancy Reconciliation As shown in the previous section, the system successfully identified the discrepancies in terms of dollar amount, it was not able to identify cause of discrepancy in terms of number of personnel. However, this is not a deficiency of the system. Although the manufacturing office's system contains this data, the controller's system does not have enough knowledge to ask the right questions in order to identify the source of discrepancy in number of personnel.  P.57  Chapter Six CONCLUSION AND FUTURE WORK In this thesis, our interest is in studying the automation of budget negotiation. But since the budget negotiation process is such a broad topic and is also complicated by the many behavioral issues involved in it, we decided to focus our efforts on the mechanistic aspects of budgeting. Traditionally much time and effort have been spent in identifying the real issues and reconciling discrepancies in order to prepare the budgeting parties for negotiation. In other words, although budgeting is a well studied area, not enough effort has been paid to studying the automation of processing. Therefore, we concentrated our research efforts on narrowing the differences in preparing the budgeting parties for negotiation. This chapter concludes this thesis and research. The corporate budgetary process was first studied and behavioral factors complicating the budgeting process were identified. The  P.58  goal of automation is not to completely eliminate human involvement in the budgeting process, rather the goal of automation is to provide human players with more relevant information, and to free up more time and resources for them to concentrate on the relevant issues of budget negotiation. This study utilizes a case that was created based on a real-life situation. Based on the findings in this case, a set of criteria for automation were identified. A series of existing information systems and tools readily available on the market were evaluated and criticized based on this set of criteria. We have came to the conclusion that as with all fine systems on the market, they fail to meet one or more of the following criteria: information storage, mathematical calculation and logical reasoning capability. A system was then designed to automate the task of narrowing the differences. The system was implemented on a Windows 95 platform and written in Prolog language. Throughout the implementation, a convention was developed to represent the knowledge of budgeting process and accounting information. This thesis demonstrates usage of the system by applying it in a "bottom-up" budget preparation scenario. The example shows how the controller can approve or disapprove budgets prepared by a subsidiary. However, the system also works in a "top-down" scenario in which the corporate controller prepares the budget and forces the subsidiary to comply with it. The system has the ability to identify source of discrepancy between any two budgets regardless of the budgeting parties' position in the corporate hierarchy.  For  example, the subsidiary can use the system to identify any sources of discrepancy between controller's prepared budget and its own understanding of the financial situation.  P.59  In order to evaluate the effectiveness of the system, data of the National Motors case were then fed into the system for a test run. Through the implementation and testing of the system the following areas were identified:  1 Limitations of the Study Due to time and resource constraints, only one case was used to test the usability of the system in this study. To provide more meaningful results, more real life cases can be used for the testing process.  It is desirable to test the system, possibly in a real business  organization setting. The system successfully provides a list of source of discrepancy to user. However, it lacks an explanation engine. Users cannot query the system on how it arrives to a particular set of answer.  2 Future Work The research can be extended in several ways. First, the system and concept of budget automation can be tested in business organizations to study how well the business world will adopt the concept of budget automation. Second, an explanation engine can be added to the system to allow users to query the reasoning behind each recommendation. Third, we also recognize there are behavioral factors that inhibit users from disclosing and sharing information. The system can therefore be perfected by adding a function which allows users to attach an access level to each piece of data so that data can be retrieved  P.60  selectively based on the discretion of the owner of the data. By doing so, users are provided with the flexibility of disclosing only the information they think is suitable. Last but not the least, this thesis provide information clarification concept that can be extended to develop a general inquiry tool. Effort could be directed towards studying the integration of this inquiry tool with the existing accounting systems.  3 Conclusion As stated in the beginning of this thesis, this study attempts to bring automation to the budget negotiation process by employing a computer-based system. As shown by the developed system, this automation is brought to the area of narrowing the scope of differences in the budget negotiation process. Although information clarification is a small step in budget negotiation, it results in a significant amount of saving in time and resources, once this process is automated. More effort could be made towards studying the automation of the budget negotiation process based in this thesis.  P.61  BIBLIOGRAPHY 1. Anthony, R. N., Dearden, J., and Govindarajan, V. Management Control Systems (7 Edition), Irwin: Boston, Massachusetts, 1992.  th  2. Arnold, J., Hope, T., Accounting for Management Decisions (2 Edition), Prentice Hall: Hertfordshire, 1983. nd  3. Carruth, P. J., McClendon, T. O., and Ballard M . R., "What Supervisors Don't like about Budget Evaluations," Management Accounting, February 1983, p. 42. 4. Chang, M . K. and Woo, C , 1994, A C M Transactions on Information Systems. 12, 4, 60382. 5. Cyert, R. M . and March, J. G., A Behavioral Theory of the Firm: 1963: Prentice Hall. 6. Finney, H . A., Miller, H. E., and Mitchell, C. L., Principles of Accounting - Canadian Edition, Prentice-Hall: New Jersy, 1965. 7. Garrison, R. H., Chesley, G. R., and Carroll, R. G., Managerial Accounting - Concepts for Planning, Control, Decision Making, Irwin: Boston, Massachusetts, 1990. 8. Kersten, G. E., Michalowski, W. Szpakowicz, S., and Koperczak, Z., 1991, Restructurable representations of negotiation, Management Science, 37, 10(Oct.), 12691290. 9. Loomis, M . E. S., 1995, Object Databases The Essentials: Addison-Wesley Publishing Company 10. Reynolds, G. W. "Information Systems for Managers," West Publishing Company, 1992 11. Rob, P and Coronel, C , 1993 Database Systems: Design, Implementation, and Management: Wadsworth Publishing Company. 12. Schiff, M . and Lewin, A. Y., 1968 Where traditional budgeting fails. Financial Executive, May, pp. 50-62. 13. Siegel, G., Ramanauskas-Marconi, H., 1989, Behavioral Accounting: South-Western Publishing Co. 14. Sycara, K. P., 1991. Problem restructuring in negotiation. Management Science, 37, 10 (Oct), 1248-1268.  P.62  15. Van Le, T., 1993, Techniques of Prolog Programming with Implementations of Logical Negation and Quantified Goals, 1993, John Wiley & Sons, Inc. 16. Versant ODBMS, VERS ANT Concepts and Usage Manual, 1995, July.  P.63  APPENDIX A  P.64  Case 9-1 National  Motors,  William Franklin, controller of the Panther Automobile Division of National Motors, a manufacturer of numerous products including a wide line of automobiles and trucks, was faced with a difficult decision in 1983. The manufacturing office had submitted a supplemental budget in which it had requested additional funds for increased administrative costs in its operations control department. The controller's office had written a memorandum in reply, explaining why it thought this request was not justified, and the manufacturing office had now answered this memorandum. Mr. Franklin now had three possible courses of action: (1) to concur with the manufacturing offices' position, in which case the request would undoubtedly receive the necessary approval of the general manager; (2) to continue his opposition, in which case his views and those of the manufacturing office would be placed before the general manager, who would decide the issue; and (3) to reply with a further analysis in the hope that the manufacturing office would become convinced of the soundness of his position. During the last quarter of 1982, the Panther Automobile Division had absorbed the manufacturing activities of the Starling Automobile Division. Responsibility for product planning and marketing of Starling cars, however, remained with the Starling Division. A major reason for the consolidation of manufacturing activities was to reduce operating costs. There had been an anticipated annual saving in  Inc.*  the operations control department, for example, of $368,000 from ajreduction in the number of salaried personnel by 24. There also had been an expected saving from computerization of parts control in that department. Prior to the consolidation, the Starling Division had a computer system of parts control in its operations control department. The Panther Division, on the other hand, had been using a manual system in its corresponding department. In December 1982, a study was made to determine which system would serve the division best. On the basis of an estimated reduction of 23 salaried people and of $276,000 in salary and other costs in the operations control department, because of computerization, the decision was made to completely computerize the Panther Division's system of parts control. The results of this study were concurred by the manufacturing office of the Panther Division. Strong budgetary control was exercised throughout the National Motors organization. In the fall of each year, every department manager developed his or her proposed budget for the next year. Each proposed budget then entered an extensive process of analysis, revision, consolidation, review, and approval by higher levels of management, first within a division and then at the corporate level. At each management level, budgets for subordinate units were consolidated prior to submission to the next higher management level. Controllers at the divisional and corporate levels participated actively in this process.  * This case was prepared by J. Hekimian under the supervision of R. N. Anthony, Harvard Business School. Copyright © by the President and Fellows of Harvard College. Harvard Business School case 161-004. 456  P.i  National Motors, Inc.  457  Exhibit 1 shows the Starling Division's personnel ceiling commitment as of December 31, 1982, the expected saving in numbers resulting from the consolidation, and the proposed ceiling for 1983. Since the manufacturing office believed that the new consolidated system of parts control in the operations control department was going to be about the same as the Starling Division's computerized system, the standards that it used to develop the proposed personnel requirements were based on the Starling Division's work load and authorized personnel levels for 1982.  Once formal approval had been given a budget, it became a firm commitment for the responsible manager. He or she could not exceed this budget except by submitting and obtaining approval of a supplemental budget. A supplemental budget was prepared and processed in essentially the same way as the original budget/Policy prescribed that a supplemental budget be justified on the basis of changes in conditions after the original budget was approved. The 1983 budgets had been approved prior to the consolidation of the Panther and Starling Divisions, so there was a separate budget for each division and, consequently, for the operations control departments of the two divisions. The approved budgets for 1983 for these two operations control departments are summarized below, together with the estimated savings resulting from consolidation and control computerization.  Specifications Control Section (25 People) The work load determinant used in this activity was the number of specifications requests to be processed. In the previous year, 20 employees had been approved in the Starling Division's specifications control section: 5 were clerical and  Panther  Starling  Division  Division  Total  Dollars  Dollars Number  (000s)  Number  (000s)  76  $1,444  55*  $1,336  Dollars Number  (000s)  131  $2,780  Savings from consolidation  (24)  (368)  Savings from computerization*  (23).  (276)  Budget before consolidation  84  Total  $2,136  * After the transfer of five specifications follow-up personnel out of the specifications control section, t Based on the study completed in December 1982, concurred by the manufacturing office.  Manufacturing Office's Proposed Supplemental Budget In April 1983, the manufacturing office proposed in a supplemental budget that the Panther operations control department, now servicing both Starling and Panther automobiles, be allotted for 1983 a personnel ceiling of 109 people to handle the combined work load. Its proposal and reasoning are summarized in Exhibit 1 and in the following paragraphs.  supervisory, 10 processed specifications requests, and 5 were involved in specifications follow-up. The specifications control procedure currently used in the Panther Division operations was generally the same, as that used by Starling. But in the future, the specifications follow-up procedure would no longer be done in this section or, for that matter, in the operations control department. In 1982, the 10 analysts in the Starling specifications control section had processed 2,964 spec-  458  Case 9-1  ifications requests, or an average of 296 specifications each. In the Panther Division, 3,680 specifications requests had been processed during 1982. The manufacturing office believed that a comparison of both Starling and Panther data, as shown in Exhibit 2, indicated that there was a definite relationship between the number of specifications requests processed and the number of unique, new model parts. On the basis of the above calculations, the manufacturing office estimated the total number of specifications requests for 1983 for both Panther and Starling automobiles, and the personnel required to handle this work load as in Exhibit 3.  this section. In 1982, for 6,584 parts there were 27 specifications coordinators in the Starling Division budget for an average of 242 parts per coordinator. According to Exhibit 4, which was drawn up in the manufacturing office, 58 specifications coordinators would be required to handle the combined work load in 1983 plus 9 supervisors and clerical workers. Planning and Control Section (15 People) The requirements for this section were determined by the manufacturing office as shown in Exhibit 5, based on an overall work load indicator of number of parts to be handled.  Manager's Office (2 People) Design Parts Section (67 People) A personnel ceiling of two was requested: the The number of unique parts to be processed was used as the general work load determinant in manager and his secretary.  EXHIBIT 1  Personnel Ceilings for Operations Control Department in 1983 (proposed by manufacturing office) Starling  Positions  V  12131182  Savings  Starling  Panther  2 25 67 15 109  2 20 31 7  2 12 12 3  —8 19 4  2 17 48 11  Total  60  29  31  78  '•^ P ''  Starling  Manager and secretary Specifications control Design parts control Planning and control  EXHIBIT 2  1<(  Proposed Levels  Commitment  Division  Panther Starling Total  Totals  Relationship of Number of Parts to Specification Requests Number of  Number of  Specifications  Unique  Specifications  Requests per  Parts  Requests  Unique Part  3,680 2,964  0.42 0.45  6,644  0.43  8,810 6,584 15,394  P.67  National Motors, Inc.  EXHIBIT 3 A.  459  Estimates of Personnel Requirements for Specifications Control Section, 1983  Specifications requests and equivalent personnel: Estimated Number of  Specifications  Actual  Unique  Requests per  Output per  Equivalent  Division  Parts'  Unique Part  Worker  Personnel  Panther  11,600  0.42  296  16.5  Starling  4,800  0.45  296  7.3  Total B.  16,400  23.8  Salaried personnel requirements: Less Planned  V  Less Planned  Salaried  Equivalent  Efficiency  Overtime  Ceiling  Division  Personnel  (approx: 10%f  (approx: 5%)  Required  Panther  16.5  1.7  Starling  7.3  0.8  s,. '  23.8  2.5  f  Total C.  \' .  1  K  r  0.9  14  /  0.4  6  +  ..3  20  I  Other personnel requirements: Position  Panther  Section supervisor and secretary  2  Unit supervisor  1  Clerk-typist Total fixed  3  Total salaried and other  Starling  Total 2  1  2  1  1  2  ~5* 25  * The Panther Division had added a new car to its line, and the Starling Division had dropped one. "Planned efficiency" reduces the calculated personnel requirements to a level approximately consistent with the lowest work load level anticipated during the coming year. In order to handle periodic work load increases during a year, the department is forced to improve its efficiency and, if necessary, to utilize overtime or temporary clerical help from outside agencies. * Same as Starling commitment of December 31, 1982. f  Estimated Dollar Requirements The manufacturing office estimated that a total of $2,916,000 would be needed to operate the consolidated operations control department for 1983. This figure was broken down as follows: Personnel Material and supplies  $2,320,000 90,000  Computer services  490,000  Miscellaneous. . .  16,000  Total  $2,916,000  Personnel expenses. This estimate was based on the figure for actual salaries plus approved fringe benefits, in accordance with the level of requested salaried personnel ceilings. Materials and supplies. This expense was about $20,000 higher than the 1982 Starling actual. According to the manufacturing office, the job to be accomplished now was about two-andone-half times the job accomplished by the Starling Division in 1982, but the expense was only 30 percent greater. This was aresultof efficiencies in programming andreporting,which, in  4«)  Case 9-1  EXHIBIT 4  A.  Estimates of Personnel Requirements for Design Parts Section, 1983  Specifications coordinators requested:  1983 Parts  Estimated Output  per  Less  Less  Planned  Planned  Equivalent  Efficiency  Overtime  Personnel  (approx:  (approx:  Ceiling  5%)  Required  Division  Panther Starling  11,600 4,800  Total  16,400  B.  242 242  Supervisory and clerical workers requested: Position  Section supervisor and secretary Unit supervisors Clerk-typists  48.0 19.8  4.7 1.9  2.3 .9  41 17  67.8  6.6  3.2  58  Panther  Starling  Total  2 3  Total for the section  3 4  2  Total Unit supervisors to coordinators Clerk-typists to coordinators  1  1:20 1:13  1:17 1:17  1:19 1:15 67  turn, would result in savings in materials and both the 1983 Panther Division's budget and the Starling Division's budget as approved prior to supplies. the consolidation, and compared these figures Computer services. Starling had spent with those proposed by the manufacturing office. $380,000 in 1982 to accomplish a job that was This summary is shown in Exhibit 6 and is exabout 40 percent as great as the combined Star- plained in the following paragraphs. ling-Panther job. Included in the proposed Although the proposed combined Panther and amount was $68,000 for start-up cost associated Starling budgets for 1983 showed a decrease of with the conversion of the manual Panther system 22 salaried personnel, there was an increase in to a computerized system. Therefore, the real cost of $136,000. cost was $422,000, or only about 10 percent The manufacturing office had referred to a more than the 1982 Starling actual. The manu- saving of 24 people and $368,000 in the Starling facturing office was proposing to do a job 150 Division. This reduction, according to the conpercent greater than done at Starling for only troller, was the result of (a) a reduction in the 10 percent more money. This was said to be the 1983 parts count and (b) a reduction of superviresult of efficiencies in programming and report- sory and clerical personnel. This saving of 24 ing. people, therefore, had nothing to do with computerization and would have occurred under either a Analysis by the Controller's Office computerized or a manual system. Although the main reason for computerizing The controller's office did not concur with the the Panther Division's system of parts control had manufacturing office's proposal. It summarized  National Motors. Inc.  461  E X H I B I T 5 Estimate of Personnel Requirements for Planning and Control Section, 1983 Number of Starling Position  Personnel  Programming computer Programming timing and coordination  Unique Parts for  Parts per  Starling. 1982  Person  3 2  6,584 6,584  2,195 3,292  Number of  Program timing and coordination Programming  Unique Parts.  Estimated  Equivalent  Personnel  1983  Output  Personnel  Ceiling Requested  Panther Starling  per Person  Panther  Starling  Panther  3,292 2,195  3.5 5.3  1.5 2.2  4 5  2 2  6 7  8.8  3.7  9  4  13  11,600 11,600  4,800 4,800  Total  Starling Total  Section supervisor and secretary Total for the section  2 15  E X H I B I T 6 Budget Comparison for Salaried Personnel Prepared by Controller Panther Division Budget Status  Starling D vision  Dollars Number  Total  Dollars  (000s)  Dollars  Number  (000s)  Number  55* 31  1,336 968  131 109  24  368  22  (136)  —  —  23  276  (000s)  Budget before consolidation Proposed  76 78  Net change Explanatation of changes: Savings from computerization of Panther system Savings from consolidation Proposed increase to Panther budget  (2)  (504)  23 *  276  —  —  24  368  24  368  (25)  (780)  —  —  (25)  (780)  Net change  J2)  $ (504)  24  22  $ (136)  $1,444 1,948  f  $ 368  ( ) = Adverse effect on profit. Reflects the transfer of five specifications follow-up personnel out of the specifications control system. Based on study of December 1982, concurred in by manufacturing office. t  $2,780 2,916  P.70  462  Case 9-1  E X H I B I T 7 Controller's Revised Budget Comparison for Salar/ed Personnel, 1983 Panther Division  Starling Division Dollars  Dollars System  Combined manual systems Proposed computerized systems Difference between cost of computerized system and manual system  Number  (000s)  76  $1,444  78  1,948  (2)  Total  Number  Dollars  (000s)  Number  (000s)  $812  111  $2,256  31  960  109  2,916  4  (156)  2  / j  (504)  (660)  E X H I B I T 8 Controller's Proposed Budget, 1983 Salaried Personnel  Panther  Starling  Total  Number Budget dol lars (000s)  53 $ 1,168  31 $968  84 $2,136  been financial savings, the controller calculated what the combined budget would have been if, in fact, the Starling Division's system had been changed to a manual one comparable to the one in use by the Panther Division prior to the consolidation. The budget requirement for the Panther Division, of course, would not change. However, /f 35 people and $812,000 would be required for the / ^-Starling Division, on the basis of Panther Division's standards as developed in the manufacturing office's analysis. Thus, a comparison between the manual system and the computerized system was as shown in Exhibit 7. According to Exhibit 7, the effect of the computerization and the consolidation on the 1983 Panther budget, which was based on a manual system, was to increase the 1983 salaried personnel level by two people and to increase costs by $504,000. The controller was at a loss to know why these increases should result from computerization. Moreover, the manufacturing office had committed itself to a saving of 23 people and $276,000 in the Panther Division, whereas the  current proposal was 25 people and $780,000 over the levels committed. The controller believed that budgetfiguresunder a combined computerized system, instead,  should be as shown in Exhibit 8. In this calculation, the Panther Division's number of salaried personnel was based on the precomputerization figure (76) minus the saving agreed to by the manufacturing office as a result of computerization (23). The Panther Division's budget dollars were based on the same sort of analysis—$1,444,000 minus $276,000. Starling Division's figures were those used in Exhibit 7, based on a reduced parts count, supervisory savings, and the functional transfer of personnel. The budgetfiguresfor the new division should be 84 people and $2,136,000. On the basis of its analysis, the controller's office recommended that the manufacturing office at least not increase its 1983 costs for the operations control department over the level that would have occurred under a combined manual system. This meant a dollar budget of $2,256,000. Per-  National Motors, Inc.  EXHIBIT 9  463  Detail of Controller's Recommended Budget, 1983 Panther  Starling Dollars  Proposals  Manufacturing office's request Controller's recommended reductions: Salary mix Overtime Required personnel (to meet financial objective) Total recommended reductions Total recommended level  Number  .  (000s)  78  $1,948  — —  170 54  25  394  25  618  53  1,330  Total Dollars  Number  31  Dollars  (000s)  Number  $968  109  — .  31  $2,916  170 96  42  —  (000s)  —  25  394  42  25  660  926  84  2,256  E X H I B I T 10 Revised Estimates of Number of Unique Parts 1983 Original Division  Budget  Estimates  Current  Known  Conditions  Panther Starling  10.200 —  11,600 4,800  Total  10,200  16,400  sonnel reductions would be required to contain costs within recommended levels; these were set forth in Exhibit 9.  work-load volume increases over the estimated levels used in developing the 1983 Panther budget for a manual system. The parts counts estimates used in developing the 1983 annual budget and Protest from the Manufacturing Office the proposed consolidated computerized budget The manufacturing office did not accept the were as shown in Exhibit 10. According to the manufacturing office, in addicontroller's recommendation of a reduction of 25 salaried people and $660,000, though it agreed tion to increased work as a result of the added that, generally speaking, a computerized opera- work load of the Starling Division, there had tions control system should not be any more been an increase of 1,400 parts in the Panther Division as a result of understated original esticostly than the previously used manual system. mates. This increased parts count would have Work-Load Content and Volume Adjustments resulted in a requirement for at least 10 more peoOne of the arguments of the manufacturing of- ple under the manual system, at a cost of about fice was that its proposed Starling-Panther bud- $180,000, plus an estimated $8,000 for operating get included additional people to handle actual expenses.  P.72  464  Case 9-1  E X H I B I T 11 Budget Increase Due to Salary Mix Proposed Salary  Base  Ceiling  At approved budget rates At proposed budget rates  109 109  X  Average  Total  Annual  Annual  Salary  Salaries  $14,088 15,768  Total.  $1,535,592 1,718,712 ($  Unavoidable Increases in Salary Mix As a result of Starling-Panther consolidation and the consequent personnel changes, the average salary per employee retained in the operations control department had increased significantly. This resulted from the retention of employees on the basis of seniority. The approved budget provided for an average salary of $14,088. The Starling-Panther budget, proposed by the manufacturing office for 1983 based on actual salaries, provided for an average annual salary in excess of $15,600. Therefore, if average salaries had remained unchanged after the consolidation, the manufacturing office's budget proposal would have been $183,120 less, as shown in Exhibit 11.  E X H I B I T 12  183,120)  Association with Integrated Data Processing Plan By implementing the computerized operations control system, the manufacturing office contended that it had taken an inevitable step included in the company's integrated data processing plan, which provided for eventual establishment of a completely computerized master parts control system. This step would make it possible to reduce significantly the original expense estimates associated with setting up this master system. The original proposal, submitted prior to the consolidation of the two divisions, contained cost estimates of $189,774 during 1983 and $209,344  Effective Cost Decrease Due to Mechanization 1984  Revised  Cost  Factors  Original cost estimates Cost of consolidation and revised assumptions based on manual system Total cost estimates to include effect of consolidation based on a manual system Reduction in cost estimates to give effect to consolidation Savings directly associated with a computerized versus manual system  Going  1983  uvel  $189,774  $209,344  33,970  109,138  233,744  318,482  17,400  122,020  203,344  196,462  National Motors, Inc.  I x a c h year thereafter f o r providing a master parts [control system to preproduction control. Accord; ing to the manufacturing office, these cost estimates would have been increased to $223,744 and $318,482, respectively, as a result o f the consolidation i f a manual system were used. As a direct benefit o f implementing a computerized operations control system, however, the manufacturing office believed that it could show a saving o f about $206,000 during 1983 and $196,000 f o r each year thereafter. See Exhibit 12.  Nonrecurring Cost Penalties  465  tem offered certain other advantages over a manual system. 1. It provided a single and better integrated program progress report that reflected the status of engineering, manufacturing, and purchasing actions against schedules on a more timely basis than did a manual system. 2. It provided a master file that, once stored in the computer, could be used to produce other useful information. 3. It was compatible with the objective to mechanize the issuance of specifications and would result in a more efficient method o f handling this activity. The manufacturing office said that it could not put a dollar value on these advantages, but that it was reasonable to expect them to yield cost savings.  The manufacturing office's proposed budget included a nonrecurring cost penalty o f $224,610, resulting from the change in organization and procedure. This was comprised o f $144,610 i n Summary salaries and wages and $80,000 in computer expense. I f work volume remained at the same levA cost comparison for a manual versus a comels in future years, the manufacturing office felt puterized operations control system, based on the that its budget could be revised as shown in Ex- above adjustments, was as shown in Exhibit 14. hibit 13. The manufacturing office concluded its arguments by pointing out that the computerized sysFunctional Improvements and Advantages tem cost only $82,000 a year more than a manual system, as shown i n the preceding table, rather The manufacturing office contended, furtherthan $660,000 more, as stated by the controller. more, that a computerized operations control sys-  E X H I B I T 13  Future Savings of Nonrecurring Costs  Budget Items  1983  Future Years  Reductions  Average personnel ceiling Personnel costs Computer expense Other operating costs  117 $2,317,752 490.000 108,272  109 $2,173,142 410,000 108,272  9 $144,610 80,000 —  Total  $2,916,024  $2,691,414  224,610  I  11CM  CM CD  O CM  w o" CO (0 oo"CinO C T— in (A "co CO  o  co at  c c o  o CD in of  CD r— w  CM ,  o O  CD  00 CO  o O  in  CO 1  ^ I  CD  a.  o o o T" o o CO CD o CM 00  CO C O CO C O  r- o in  CD C  co  CM  c o  CM  CD  Q. CO  o  -o <D  CD D rz CO  35 03  o  CO CO  CO CO CO CO  E « O  O  CO CD  33  (0 CD  Oh  c .© *s jfl •© o>  3  u  o ©  "eS e o  S5  o O o CM o C O T — CM o o C O CM" o" CM CO in CC OD CM CM  CO  ofcS CD  Qfl E  JO  "D CD Q . CO c CO O 3  £ Q. CD  ^  CO c_ 5£ CD Om <o COc Q £ co _ CO CD . 2 O 03c CL CO i_ Z3 0  3  ?  o  03  CO CO  rage  3 W  O  rage  O CD E •CD~ 5  CO CM CO 0 0  i |  CO >  o  CD c o - * CO CO *3 "5 3 C D i_ £ 8 CJ CD CO c "£ o "D CO CD v> c  o  O  c  o  CD CD  E  c  •= § & ««  b O o_  P.75  APPENDIX C  1 Main Reasoning Engine :::-  consult(sys/control). consult(sys/subtotal). consult(sys/simplify).  %The r e q u e s t h a s b e e n s u c c e s s u f u l y p r o c e s s e d i f t h e r e i s n o m o r e i t e m s the l i s t request([]):w r i t e ( ' n o more i t e m s i n t h i s l i s t ' ) / n l , n l , append('log.txt'), write ('Controller: no more i t e m s i n t h i s l i s t ' ) , n l , n l , told. request(-99999):nl, w r i t e ( ' * * * ' ) , n l , write('The requested data i s not available, Continue t o perform next t e s t . ' ) , n l , append('log.txt'), write('Controller: The r e q u e s t e d d a t a i s n o t a v a i l a b l e , Continue t o perform the next t e s t . ' ) , n l , told, f a i l .  i n  the  %Handling t h e request by s t a r t i n g from the f i r s t and process recursively request([Head|Tail]):nl, w r i t e ( ' * * * ' ) , n l , write('Checking the following item: ' ) , write(Head), n l , append(•log.txt'), nl, write('Controller: * * * ' ) , n l , write('Controller: Checking the f o l l o w i n g item: ' ) , write(Head), n l , told, approve(Head) , request(Tail). %The r e q u e s t e d i t e m i s a p p r o v e d i f i t f a l l s w i t h i n t h e d e v i a t i o n limit approve(account(Key, [Value|_], _, Desc)):read_Val_Dev(Key, [ M y V a l ] , MyDev, _ ) , Max i s M y V a l * ( M y D e v + 1 ) , Min i s MyVal*(1-MyDev), Value<Max, Value>Min, write(Desc), write(' ('), write(Key), w r i t e ( ' ) ' ) , write(' = ' ) , write(Value), write(' >'), w r i t e ( ' APPROVED'), n l , n l , append('log.txt'),  P.76  write('Controller: w r i t e ( ' ) ' ) , write(' = ' ) , w r i t e ( ' APPROVED'), told.  ' ) , write(Desc), write(' ('), write(Value), write(' >')/ nl, nl,  %reads i n t h e v a l u e and d e v i a t i o n o f an a c c o u n t read_Val_Dev(Key, [ V a l u e ] , D e v i a t i o n , _) : account(Key, [Value|_], Deviation, _ ) .  stored  in  write(Key),  our  database  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%% % I f t h e r e q u e s t e d i t e m can be b r o k e n down i n d e t a i l s , q u e r y t h e r e q u e s t originator %for d e t a i l e d i n f o r m a t i o n b y b r e a k i n g t h e i t e m down a c c o r d i n g t o t h e control hierarchy. %Check t h e s u b s i d i a r y accounts. approve(Item):subsidiary(Item), display_msgl(Item), request_subsidiary(Item, Subsidiary_List), request(Subsidiary_List). %Check t o s e e i f o u r d a t a b a s e c o n t a i n s d e t a i l e d s u b s i d i a r y s u b s i d i a r y ( a c c o u n t ( k e y ( T , A , M, 0 ) , _ , _ , _ ) ) : control(0, S), a c c o u n t ( k e y ( T , A , M, S ) , _ , _ , _ ) , ! .  breakdowns  % w r i t i n g t h e s u b s i d i a r y q u e r y command t o a f i l e request_subsidiary(Item, Return_List):write_request(Item, Return_List, 'subsidiary_account'). %output request t o f i l e write_request(account(Key, _, _, Desc), L i s t , Function):w r i t e ( ' W r i t i n g command f i l e t o r e q u e s t d e t a i l o f ' ) , w r i t e ( D e s c ) , write(' ('), write(Key),write(')'), nl, tell('request.pi'), w r i t e ( ' : - ' ) , write(Function), w r i t e ( ' ( ' ) , write(Key), w r i t e ( ' ) . ' ) , nl, told, write('Please s t a r t another instance of prolog to generate response.'), nl, write('When response i s received, type 1 to continue the current process.'), nl, nl, append('log.txt') , write('Controller: W r i t i n g command f i l e t o r e q u e s t d e t a i l of ' ) , w r i t e ( ' C ) , w r i t e (Key), w r i t e ( ' ) . ' ) , nl, write('Controller: Please s t a r t another instance of p r o l o g to generate response.'), nl, write('Controller: When r e s p o n s e i s r e c e i v e d , t y p e 1 t o continue the current p r o c e s s . ' ) , n l , nl, told, read(Command), read_response(Command, List). %get t h e r e s p o n s e b y r e a d i n g t h e read_response(1, Return_List):see('response.pi'), read(Return_List), seen.  returned  data  f i l e  P.77  %respond t o the r e q u e s t respond:consult(request) . %finds a l l s u b s i d i a r y accounts and s t o r e d i n t o a l i s t and w r i t e i t t o a f i l e subsidiary_account(Key):subsidiary(account(Key, _, _, _ ) ) , nl, write('Collecting related accounts'), nl, bagof(Subsidiary, find_subsidiary(Key, Subsidiary), Subsidiary_List), w r i t e ( ' W r i t i n g collected d i v i s i o n a l sub-accounts to f i l e ' ) , n l , nl, append('logl.txt'), nl, write('Manufacturing: Collecting related accounts'), nl, write('Manufacturing: Writing collected divisional subaccounts to f i l e ' ) , n l , nl, told, tell('response.pi'), writeq(Subsidiary_List), w r i t e ( ' . ' ) , nl, told. subsidiary_account(_):write('The requested data is not available. No d a t a w i l l b e provided.'), nl, nl, append('logl.txt'), write('Manufacturing: The r e q u e s t e d d a t a i s n o t available. No d a t a w i l l b e p r o v i d e d . ' ) , n l , nl, told, tell('response.pi'), write(-99999), write('. '), nl, told. f i n d _ s u b s i d i a r y ( k e y ( T , A , M, 0 ) , a c c o u n t ( k e y ( T , A , M, Desc)) : control(0, S), a c c o u n t ( k e y ( T , A , M, S ) , [ V a l | _ ] , Dev, D e s c ) . %Inform user about sending a query display_msgl(account(Key, _, _, Desc)):write('The requested item: '), write(Desc), write(' ('), write(Key), w r i t e ( w r i t e ( ' exceeds l i m i t . ) , nl, w r i t e ( ' A s k the o r i g i n a t o r to supply informati divisions.'), nl, nl, append('log.txt'), write('Controller: The r e q u e s t e d i t e m ' ) write(Desc), write(' ('), write(Key), w r i t e ( write(' exceeds l i m i t . ' ) , nl, write('Controller: Ask the o r i g i n a t o r t o subsidiary divisions.'), nl, nl, told.  S),  [Val],  Dev,  ' ) ' ) ,  1  on  on  subsidiary  , ' ) ' ) , supply  information  on  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%  P.78  % I f t h e r e q u e s t e d i t e m c a n be b r o k e n down i n t o s u b - a c c o u n t s , originator % f o r sub-account i n f o r m a t i o n . Check t h e sub-accounts approve(Item):subaccount(Item), display_msg2(Item), request_subaccount(Item, Subaccount_List), request(Subaccount_List).  query the  %Check t o see i f o u r database c o n t a i n s sub-accounts o f t h e c u r r e n t i t e m s u b a c c o u n t ( a c c o u n t ( k e y ( T , [ A l , A2, A3, 0 ] , M, O), _, _, _ ) ) : a c c o u n t (key (T, [ A l , A2, A3, A4] , M, O) , _, _, _) , A4 > 0, ! . s u b a c c o u n t ( a c c o u n t ( k e y ( T , [ A l , A2, 0, 0 ] , M, O), _, _, _ ) ) : a c c o u n t (key (T, [ A l , A2, A3, 0 ] , M, 0 ) , _, _, _) , A3 > 0, ! . s u b a c c o u n t ( a c c o u n t ( k e y ( T , [ A l , 0, 0, 0 ] , M, 0 ) , _ , _ , _ ) ) : a c c o u n t (key (T, [ A l , A2, 0, 0 ] , M, 0 ) , _, _, _) , A2 > 0, ! . % I n f o r m u s e r about s e n d i n g a query d i s p l a y _ m s g 2 ( a c c o u n t ( K e y , _, _, D e s c ) ) : write('The requested item ' ) , w r i t e ( D e s c ) , w r i t e ( ' ('), w r i t e ( K e y ) , w r i t e ( ' ) ' ) , w r i t e ( ' exceeds l i m i t . ' ) , n l , w r i t e ( ' A s k t h e o r i g i n a t o r t o s u p p l y i n f o r m a t i o n on any c a t e g o r i c a l sub-accounts.'), n l , n l , append('log.txt') , write('Controller: The r e q u e s t e d i t e m ' ) , w r i t e ( D e s c ) , w r i t e ( ' ('), w r i t e ( K e y ) , w r i t e ( ' ) ' ) , w r i t e ( ' exceeds l i m i t . ' ) , n l , write('Controller: Ask t h e o r i g i n a t o r t o s u p p l y i n f o r m a t i o n on any c a t e g o r i c a l s u b - a c c o u n t s . ' ) , n l , n l , told. % w r i t i n g t h e subaccounts query command t o a f i l e request_subaccount(Item, R e t u r n _ L i s t ) : write_request(Item, Return_List, get_subaccount'). 1  % c o l l e c t s u b a c c o u n t s and s t o r e i n a l i s t get_subaccount(Key):s u b a c c o u n t ( a c c o u n t ( K e y , _, _, _ ) ) , n l , w r i t e ( ' C o l l e c t i n g c a t e g o r i c a l sub-accounts'), n l , w r i t e ( ' W r i t i n g c o l l e c t e d accounts t o f i l e ' ) , n l , n l , append('logl.txt'), nl, write('Manufacturing: C o l l e c t i n g c a t e g o r i c a l subaccounts ' ) , n l , write('Manufacturing: W r i t i n g c o l l e c t e d accounts t o f i l e ' ) , nl, n l , told, b a g o f ( S u b a c c o u n t , f i n d _ s u b a c c o u n t ( K e y , Subaccount), Subaccount_List), tell('response.pi'), writeq(Subaccount_List), write('.'), n l , told. get_subaccount(_):write('The requested data i s not a v a i l a b l e . provided.'), n l , n l ,  No d a t a w i l l be  P.79  tell{'response.pi'), write(-99999), w r i t e ( ' . ' ) , nl, told, append('logl.txt') , write('Manufacturing: No d a t a w i l l b e p r o v i d e d . ) , told. 1  nl,  The nl,  requested  data  is  not  available.  %find sub-accounts find_subaccount(key(T, [ A , 0 , 0 , 0 ] , M, O ) , a c c o u n t ( k e y ( T , [ A , B, M, O ) , [ H e a d ] , Dev, Desc)):account(key(T, [ A , B, 0 , 0 ] , M, O ) , [ H e a d | _ ] , Dev, D e s c ) , B > 0.  0,  0],  find_subaccount(key(T, [ A , B , 0 , 0 ] , M, O ) , a c c o u n t ( k e y ( T , [ A , B, M, O ) , [ H e a d ] , Dev, Desc)):account(key(T, [ A , B , C , 0 ] , M, O ) , [ H e a d | _ ] , D e v , D e s c ) , C > 0.  C,  0],  find_subaccount(key(T, [ A , B , C , 0 ] , M, O ) , a c c o u n t ( k e y ( T , [ A , B, M, O ) , [ H e a d ] , Dev, Desc)):account(key(T, [ A , B , C , D ] , M, O ) , [ H e a d | _ ] , D e v , D e s c ) , D > 0.  C,  D],  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%% % I f the requested item is calculated according to originator for the % e q u a t i o n a n d c o m p a r e i t a g a i n s t o u r own approve(Item):equation_exist(Item), display_msg3(Item), request_equation(Item, Returned_Equation), check_equation(Item, Returned_Equation).  some  %Check t o s e e i f o u r d a t a b a s e c o n t a i n s f o r m u l a o f t h e e q u a t i o n _ e x i s t ( a c c o u n t ( k e y ( T , A , M, 0 ) , _ , _ , _ ) ) : e q u a t i o n ( k e y ( T , A , M, 0 ) , _ ) .  equation,  current  ask  the  item  % w r i t i n g t h e f o r m u l a q u e r y command t o a f i l e request_equation(Item, Equation):write_request(Item, Equation, 'get_equation'). get_equation(Key):equation(Key, Equation), write(*The requested equation w r i t e ( ' W r i t i n g the requested tell('response.pi'), write(Equation), w r i t e ( ' . ' ) , told, append('logl.txt') , write('Manufacturing: nl, write('Manufacturing: f i l e . ' ) , nl, nl, nl, told.  is found.'), nl, equation to text f i l e . ' ) ,  nl,  nl,  nl,  nl,  The  requested  Writing  the  equation  requested  is  found.'),  equation  to  text  P.80  get_equation(_):write('The requested equation is not available. No d a t a w i l l be provided.'), nl, nl, tell('response.pi'), write(-99999), w r i t e ( ' . ' ) , nl, told. append('logl.txt'), write('Manufacturing: The r e q u e s t e d equation is not available. No d a t a w i l l b e p r o v i d e d . ' ) , n l , nl, told. %Inform user about sending a query display_msg3(account(Key, _, _, Desc)):write('The requested item '), write(Desc), write(' ('), write(Key), write(•)'), write(' exceeds l i m i t . ' ) , nl. write('Ask the originator to supply equation.'), nl, nl, append('log.txt'), write('Controller: The r e q u e s t e d i t e m '), write(Desc), write(' ('), write(Key), w r i t e ( ' ) ' ) / write(' exceeds l i m i t . ' ) , nl. write('Controller: Ask the o r i g i n a t o r t o s u p p l y e q u a t i o n . ') , nl, nl, told. %check t h e r e t u r n e d f o r m u l a a g a i n s t o u r s , i f t h e f o r m u l a e a r e t h e same, check the components check_equation(Item, Returned_Equation):same_equation(Item, Returned_Equation, List), w r i t e ( ' E q u a t i o n checked, proceed to check the value of individual component.'),nl, append('log.txt'), write('Controller: * * * ' ) , nl, write('Controller: Equation checked, proceed to check the value of i n d i v i d u a l component.'),nl, told. get_c(List). get_c([]). get_c([Head|Tail]):write_request(account(Head, request([Returnltem]), get_c(Tail).  _,  _,  _ ) ,  Returnltem,  'get_component'),  get_component(Key):a c c o u n t ( K e y , V a l , Dev, Desc), write('Manufacturing: Writing the components of requested eqation to f i l e . ' ) , n l , nl, append('logl.txt'), write('Manufacturing: Writing the components of requested eqation to f i l e . ' ) , n l , nl, told, tell('response.pi'), writeq(account(Key, V a l , Dev, D e s c ) ) , w r i t e ( ' . ' ) , nl, told.  the  1  the  P.81  get_component(_):w r i t e ( ' T h e r e q u e s t e d e q u a t i o n (component) i s n o t a v a i l a b l e . No d a t a w i l l be p r o v i d e d . ' ) , n l , nl, append('logl.txt'), write('Manufacturing: The r e q u e s t e d e q u a t i o n (component) not available. No d a t a w i l l . b e p r o v i d e d . ' ) , n l , nl, told, tell('response.pi'), write(-99999) , write(' . ' ) , nl, told.  is  % i f t h e e q u a t i o n u s e d a r e n o t t h e same, i n f o r m u s e r check_equation(account(Key, _, _, _ ) , Returned_Equation):w r i t e ( ' D i f f e r e n t equations are used f o r t h i s account >'), nl, write('Their equation: ' ) , write(Returned_Equation), nl, write('Our equation: ' ) , equation(Key, Equation), write(Equation), nl, append('log.txt'), write('Controller: D i f f e r e n t equations are used for this account >'), nl, write('Controller: Their equation: ' ) , write(Returned_Equation), nl, write('Controller: Our e q u a t i o n : ' ) , equation(Key, Equation), write(Equation), nl, told. %Compare e q u a t i o n s same_equation(account(Key, _, _, _ ) , Equation, equation(Key, Our_Equation), simplifyl(Our_Equation-Equation, 0), extract(Our_Equation, List). % extract(+Expr, -AccList). %extract(Alias, Key):% alias(Alias, Key). %extract(Alias, Key). extract(A+B, L i s t ) : extract(A, extract(B, append(Lis extract(A-B, L i s t ) : extract(A, extract(B, append(Lis extract(A*B, L i s t ) : extract(A, extract(B, append(Lis  !, Listl) , List2), tl,List2,List). !, Listl), List2), tl,List2,List). !, Listl), List2) , tl,List2,List).  extract(A/B, L i s t ) : extract(A, extract(B, append(Lis extract(-B, L i s t ) : extract(B,  -  !, Listl), List2), tl,List2,List). !, List).  L i s t ) : -  P.82  extract(Expr, L i s t ) : atom(Expr), ! , alias(Expr, Key), bagof(Key, alias(Expr,  Key),  List).  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%% %if a l l the above t e s t s f a i l e d , the i t e m i s n o t approved % approve(account(Key, [ V a l | _ ] , _, Desc)):write(Desc), write(' = '), write(Val), write(' ('), w r i t e ( ' ) ') , w r i t e ( ' exceeds l i m i t >'), w r i t e ( ' NOT A P P R O V E D ' ) , n l , nl, append(•log.txt'), write('Controller: '), write(Desc), write(' = ' ) , write(Val), write(' ('), w r i t e ( ' ) ' ) , w r i t e ( ' exceeds l i m i t >'), w r i t e ( ' NOT A P P R O V E D ' ) , n l , nl, told.  write(Key),  write(Key),  P.83  2 Equation Simplification Engine /* ALGEBRA SIMPLIFIER This f i l e encloses a code SIM v5.5 for algebra c a l c u l a t i o n . Please send me your comments and suggestions. Note: The code i s developed under SWI-Prolog 1.9.5, need to change power/3 f o r BIN-Prolog. Copyright: 1, Using t h i s f i l e for commercial purpose without my i s not allowed; 2. the f i l e may be d i s t r i b u t e d f r e e l y .  permission  Example: */ go:-  expression(E), nl,pp(E), simplify(E,NewE), pp('=',NewE), fail.  expression(E):E = (a 2-b 2)/(a+b). expression(E):E = 3*x*y+2*a*b-2*y*x-b*a*2. expression(E):E = 0+l*a/l-b 0. expression(E):E = (a-b) 5/(b-a) 3 . expression(E):E = (2*a+3*a*b)/a. expression(E):E = 6/(a*2*b+6). expression(E):E= (a*a-b*(2*a-b))/(a-b). expression(E):E = a 3/(c*(b/c*a (-2))). A  A  A  A  A  A  A  gol: expressionl(El,E2) , simplifyl(El*E2,E3) , simplify(E3/E1, Enew), n l , p p ( ' E l =',E1),pp('E2 =',E2),pp('E3 = El*E2 ='),pp(E3), pp('E3/E1 =',Enew), fail. expressionl(El,E2): E l = 3*a 3+b*c+4*a*b*c-2*c, E2 = 5*a*a-b*c. expressionl(El,E2): E l = a*b*c*d-b*c*3+a 4*2-c 3*3, E2 = 2*a*b 2+3*d 3*b*c. A  A  A  A  yv  P.84  /* -for p o w e r ( A , B, AB i s A B .  SIM v 5 . 5 */ /* made b y /* zhuhail@vax.sbu.ac.uk /* 18/7/96 any comment welcome */ SWI-Prolog  */ */  AB):-  A  sort_all(List, Lsor):msort(List, Lsor). rev_sort(List, Lsor):sort(List, Ll), reverse(Ll, %  Lsor).  /* % for BIN-Prolog p o w e r ( A , B, A B ) : - i n t e g e r ( A ) , integer(B), p o w ( A , B, C ) , i n t e g e r ( C , AB). p o w e r ( A , B, A B ) : p o w ( A , B, A B ) . sort_all(List, Lsor):prolog:merge_sort(<, List,  Lsor).  rev_sort(List, Lsor):prolog:merge_sort(>, List,  Lsor).  % */ any_f(sin(_)). a n y _ f ( c o s (_)•) . any_f(exp(_)). any_f(log(_)). simplify(E, NewE):check(E), sim(E, NewE). s i m ( E , NewE) - n u m b e r f ( E , N u m ) , ! NewE = N u m . sim(E, N e w E ) :-- a t o m _ n _ e x p ( E ) , !, NewE = E. sim(E, NewE):e21(E, List), del_list(List, Ldel) 12e(Ldel, El), minus_inv_b(Esigninv, El), sim_again(E, Esigninv, NewE s i m _ a g a i n ( E , E, NewE = E . s i m _ a g a i n ( _ , E, sim(E, NewE). simplifyME, check(E),  NewE):NewE):-  NewE):-  !,  B > 0,  !,  P.85  siml(E,  NewE).  siml(E, NewE):expand(E, El), sim(El, E2), s i m l _ a g a i n ( E , E2, NewE). s i m l _ a g a i n ( E , E, N e w E ) : !, NewE = E . s i m l _ a g a i n ( _ , E, N e w E ) : siml(E, NewE). e21(E, Ldiv):removep(E, Erem), minus_inv(Erem, Einv), e211(Einv, List), sum_plus_list(List, Lsum), factorise(Lsum, Lfac), sort_list(Lfac, Lsor), collect_like(Lsor, Lcol), simplify_division(Lcol, Ldiv). factorise(List, prime(Prime),  Lfac):-  factor_list(List,  Prime,  Lfac).  prime(Prime):Prime = [2,3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59,61,67,71,73,79, 83,89,97,101,103,107,109,113,127,131,137,13 9,149,151,157,163, 167,173,179,181,191,193,197,199] . factor_list([], _, []). factor_list([H|T], Prime, [Hl|Tl]):f _ l i s t ( H , Prime, Hi), factor_list(T, Prime, Tl). f_list([Sum|T], Prime, [NewS|NewT]):f_li(T, Sum, P r i m e , NewS, N e w T ) . f _ l i ( [ ] , Sum, _ , Sum, []). f_li([H M|T], Sum, P r i m e , NewS, [ H l " M | T l ] ) : - i n t _ l i s t ( H ) , list_div_prime(Prime, H, H i , 1 , S I ) , p o w e r ( S I , M, S M ) , S2 i s S u m * S M , f_li(T, S 2 , P r i m e , NewS, Tl). f_li([H|T], Sum, P r i m e , NewS, [ H l | T l ] ) : - i n t _ l i s t ( H ) , !, list_div_prime(Prime, H, H i , Sum, S I ) , f_li(T, S I , P r i m e , NewS, Tl). f_li([H|T], Sum, P r i m e , NewS, [H|.Tl]):f_li(T, Sum, P r i m e , NewS, Tl). A  i n t _ l i s t ( [ ] ) . int_list([[H|_]|T]):integer(H), int_list(T). list_div_prime([ ] , List, list_div_prime([H|_], Lis big_than_list(List, H), list_div_prime([H|T], Lis  List, Sum, S u m ) . t, List, Sum, S u m ) : !. t , N e w L , Sum, N e w S ) : -  !,  P.86  l i s t _ d _ p ( L i s t , H, list_div_prime(T,  Ll, Ll,  Sum, SumH), N e w L , SumH,  NewS).  l i s t _ d _ p ( L i s t , H, N e w L , Sum, S u m H ) : l i s t _ d i v _ i n t ( L i s t , H, L l ) , !, S I i s Sum*H, l i s t _ d _ p ( L l , H, NewL, S I , SumH). l i s t _ d _ p ( L i s t , _ , L i s t , Sum, S u m ) . big_than_list([[0| big_than_list(T, b i g _ t h a n _ l i s t ( [ [H b i g _ t h a n _ l i s t ( [ [H big_than_list([_|T big_than_list(T,  _]|T] P). _] _ ] ] _] ], P) P).  P)  l i s t _ d i v _ i n t ( [ ] , _ , []). list_div_int([[H|T]|TT], N, r e a l _ i n t _ d i v ( H , N, H i ) , l i s t _ d i v _ i n t ( T T , N, TTl). real_int_div(A, D i s A mod B, D = 0, C is A//B.  B,  H H  P) P)  0, 0,  > <  H, H,  [[HI|T] |TTl]) : -  C):-  collect_like(List, Lcol):collect_like_term(List, Lcot), collect_like_factor(Lcot, Lcof), collect_again(List, Lcof, Lcol). collect_again(L, L c o l = L. collect_again(_, collect_like(L,  L,  Lcol):-  !,  L, Lcol):Lcol).  sort_list([H|T], [H|Tsor]):sort_time_list(T, Tsot), h2t(Tsot, Tl), sort_all(Tl, T2), h2t(Tsor, T2). h2t([], []). h2t([[H|Tt]|Tp], h2t(Tp, Tnew).  [Tt-H|Tnew]):-  sort_time_list([], []). sort_time_list([H|T], [Hsot|Tsot]):sort_time(H, Hsot), sort_time_list(T, Tsot). sort_time([H|T], [H|Tsor]):sort_plus_list(T, Tsop), sort_all(Tsop, Tsor). sort_plus_list([], []). sort_plus_list([H M|T], [Hsol^MlTsop]):sort_list(H, Hsol), sort_plus_list(T, Tsop). A  H =  [_|_],  !,  P.87  sort_plus_list sort_list(H, sort_plus_lis sort_plus_list sort_plus_lis minus_inv(A, B = N. minus_inv(A, A B = A 1. minus_inv(A, minus_inv(A, A B = A 1. minus_inv(A,  ([H|T], [Hsol|Tsop]):Hsol), t(T, Tsop). ([H|T], [H|Tsop]):t(T, Tsop).  B):-  numberf(A,  B):-  atom(A),  B):B):-  min_inv(A, any_f(A),  N),  !,  B), !,  !.  !,  A).  m i n _ i n v ( A + B , AB) : minus_inv(A, Al), minus_inv(B, Bl) , AB = A l + B l . min_inv(A-B, AB):minus_inv(A, Al), minus_inv(B, Bl) ,  !,  AB = A l + B l * ( - 1 ) .  min_inv(-A, B):minus_inv(A, Al),  B = Al*(-1).  min_inv(A*B, AB):minus_inv(A, Al), minus_inv(B, Bl),  AB = A1*B1. min_inv(A/B N, AB):Nneg i s -1*N, minus_inv(A, Al), minus_inv(B, Bl) , AB = A l * B l N n e g . min_inv(A/B, AB):minus_inv(A, Al), minus_inv(B, Bl), A  !,  A  AB = A1*B1 (-1). A  min_inv(A M, B ) : - atom_num(A), B = A M. min_inv(A M, B ) : - any_f(A), !, B = A M. min_inv(A M, B):minus_inv(A, Al), B = Al M. A  A  A  A  A  A  minus_inv_b(B, A):m i n _ i n v _ b ( B , A) - > ; B = A. min_inv_b(AB, A+B):minus_inv_b(Al, A), minus_inv_b(Bl, B), AB = A l + B l . min_inv_b(AB, A - B ) : minus_inv_b(Al, A), m i n u s _ i n v _ b ( B l , B) , AB = A l - B l .  true  !,  !,  H =  [_|_],  P.88  min_inv_b(B, -A): minus_inv_b(Al, A ) , B = - A l . min_inv_b(AB, A*B (-1)):minus_inv_b(Al, A ) , m i n u s _ i n v _ b ( B l , B) , AB = A l / B l . min_inv_b(AB, B"(-1)*A):minus_inv_b(Al, A ) , m i n u s _ i n v _ b ( B l , B) , AB = A l / B l . min_inv_b(AB, A*B):minus_inv_b(Al, A ) , m i n u s _ i n v _ b ( B l , B), AB = A l * B l . A  min_inv_b(B,  A (-1)):A  !,  !,  !,  minus_inv_b(Al, A ) , B = 1/A1. min_inv_b(B, A M):minus_inv_b(Al, A ) , A B = A1 M. A  PP ( A ) : write(A),nl. pp(A, B ) : write(A),write(' p p ( A , B , C) : write(A),write(' p p ( A , B, C, D ) : write(A),write(' write(D),nl. atom_num(A):atom_num(A):-  '),write(B),nl. '),write(B),write(' '),write(B),write(•  '),write(C),nl. 1  ),write(C).write(•  atom(A), !. number(A).  zero(A):-  number(A),  A < 0.0000001,  A > -0.0000001.  unit(A):-  number(A),  A < 1.0000001,  A >  0.9999999.  not_deal(A):atom_n_exp(A). not_deal(A):any_f(A). not_deal(A _):any_f(A). A  atom_n_exp(A _):- atom_num(A), atom_n_exp(A):atom_num(A). A  !.  collect_like_factor(A, [Sum|Tnew]):collect_factor(T, Tnew). collect_like_factor(A, A). collect_factor([], [ ] ) . collect_factor([H|T], [Hnew|Tnew]):collect_fact(H, Hnew), collect_factor(T, Tnew). collect_fact([Sum|T],  [Sum|Tnew]):-  A =  [Sum|T],  !,  ' ),  P.89  collect_fac(T,  Tnew).  collect_fac([], []). collect_fac([H|T], [Hnew|Tnew]):collect_like_factor(H, HH), collect_f(T, HH, Hnew, Tl), collect_fac(Tl, Tnew). collect_f([], H, H, []). collect_f([Hi|Tt], H M , Hnew, Tnew):collect_like_factor(Hi,HH), HH=H"N, !, MN i s M + N , collect_f(Tt, H MN, Hnew, T n e w ) . collect_f([Th|Tt], H, Hnew, [Th|Ttl]):collect_f(Tt, H, Hnew, Ttl). A  A  c h e c k ( X ) : - atom_num(X), !. check(X):- var(X), !, pp('Encounter a variable!'), p p ( ' ( B e g i n w i t h a lower case f a i l , check(A+B):! , check(A), check(B). check(A-B):!, check(A), check(B). check(A*B) :- ! , check(A) , check(B). check(A/B):!, check(A), check(B). check(-B) :!, check(B). check(A B):!, check(A), check_numl(A"B). check(F):- any_f(F), !, a r g ( l , F, A ) , check(A). check(X):-  letter  for  elements  in  expression.)'),  A  pp('Either f a i l .  a wrong  expression  or  I  do  check_numl(_ B):- numberf(B, _ ) , !. check_numl(A"B):p p ( B , ' m u s t b e a n u m b e r f o r me t o d e a l f a i l .  not  like  i t : ' , X ) ,  A  removep(X, T ) : - atom_n_exp(X), T = X. removep(A+(B+C),T):!, removep(A+B+C,T). removep(A+(B-C),T):!, removep(A+B-C,T). removep(A-(B+C),T):!, removep ( A - B - C T ) .  !,  with',A B), A  P.90  removep(A-(B-C),T):!, removep(A-B+C,T). removep(A+B,T) :- ! , removep(A,NewA), removep(B,NewB), T = NewA+NewB. removep(A-B,T):!, removep(A,NewA), removep(B,NewB), T = NewA-NewB. r e m o v e p ( - B ,.T) : - ! , removep(B,NewB), T = -NewB. removep(A/(B/C),T):!, removep(A/B*C,T). removep(A/(B*C),T):!, removep(A/B/C,T). removep(A/(-B),T):!, removep(-A/B,T). removep(A*(B/C),T):!, removep(A*B/C,T). removep(A*(B*C),T):!, removep(A*B*C,T). removep(A*(-B),T):-!, removep(-A*B,T). removep(A/B,T):!, removep(A,NewA), removep(B,NewB), T = NewA/NewB. removep(A*B,T):!, removep(A,NewA), removep(B,NewB), T = NewA*NewB. removep((A B) C,T):!, removep(A,NewA), removep(B,NewB), removep (CNewC) , T = NewA (NewB*NewC). removep(A B,T):!, removep(A,NewA), T = NewA B. removep(T,T). A  A  A  A  A  simd([], []). s i m d ( [ [ H ] | T ] , L s i m d ) : - atom_num(H), Lsimd = [[H]|NewT], simd(T, NewT). simd([H|T], [Hsimd|Tsimd]):sim_div(H, Hsimd), simd(T, Tsimd). sim_div([H|T], simdivision(T,  !,  [H|NewT]):NewT).  simdivision([],[]). simdivision([H],NewL):!, NewL=[H]. simdivision([H|T],NewL):- simdiv(H,T,ReduceL), simdivision(ReduceL,NewL).  !,  P.91  simdivision([H|T],[H|NewT]):simdivision(T,NewT). simdiv(Ll M,[L2 N|T],New):divide_list(Ll,L2,Ldiv), Ldiv = [[A]], numberf(A,Num), !, MN i s M + N , N l i s -1*N, A  A  M > 0, N < 0,  New = [[[Ll MN,Num Nl],[0]]|T]. s i m d i v ( L l M , [ L 2 N | T ] , N e w ) : - M < 0, N > 0, divide_list(Ll,L2,Ldiv), Ldiv = [[Num]], number(Num), !, MN i s M + N , New = [[[Ll MN,Num~N],[0]]|T]. simdiv(A (-1),[H|T],New):divide_list(H,A New = [ D i v L | T ] . simdiv(A,[H (-1)|T],New):divide_list(A,H New = [ D i v L | T ] . simdiv(A (-1),[H|T],New):divide_list(A,H New = [DivL (-1)|T]. simdiv(A,[H (-1)|T],New):divide_list(H,A New = [ D i v L ( - 1 ) T ] . s i m d i v ( A , [ H | T ] , [ H NewT]) simdiv(A,T,NewT) A  A  A  A  A  A  A  A  ,DivL), ,DivL), ,DivL),  A  A  ,DivL),  A  simplify_division(List,Lsim):Lsim = L i s t . simplify_division(List,Lsim):Lsim = L i s t . simplify_division(List,Lsim):simdl(List,Listl), simd(Listl,Lsim).  List  =  [[_]],  List  =  [_,[_,_]],  simdl([],[]). simdl([H|T],[Hc|Tc]):simd2(H,Hc), simdl(T,Tc).  simd2 ( [ ] , [ ] ) . simd2([H|T],[H2|T2]):- n o t _ d e a l ( H ) , H2 = H , simd2(T,T2). simd2([H M|T],[H2|T2]):- number(M), simplify_division(H,Hi), H2 = H l M , simd2(T,T2). simd2([H|T],[H2|T2]):simplify_division(H,H2) , ! , simd2(T,T2). simd2([H|T],[H2|T2]):H2 = H , simd2(T,T2). A  A  collect_like_term([H|T],[H|Tcol]):collectl(T,Listl), collect(Listl,Tcol).  !,  !,  !, !,  P.92  c o l l e c t K [] , []) . collectl([H|T],[He|Tc]):collect2(H,Hc) , collectl(T,Tc). collect2([],[]). collect2([H|T],[H2|T2]):- not_deal(H), H2 = H , collect2(T,T2). collect2([H^MlT],[H2|T2]):!, collect_like_term(H,Hi), H2 = H l M , collect2(T,T2). COllect2([H|T],[H2|T2]):collect_like_term(H,H2), !, collect2(T,T2). COllect2([H|T],[H2|T2]):H2 = H ,  !,  A  collect2(T,T2). collects [ ] , []) . collect([H0|Listl],[NewH|NewT]):HO=[ParaO|ListO], coll(Listl,ParaO,ListO,List2,NewPara), NewH=[NewPara|ListO], collect(List2,NewT). coll([],ParaO,_,[],ParaO). coll([HI|Tl],ParaO,ListO,T2,NewPara):- Hl=[Paral|Listl], i NewP i s ParaO+paral, coll(Tl,NewP,ListO,T2,NewPara). coll([Hl|Tl],ParaO,ListO,[Hl|T2],NewPara):coll(Tl,ParaO,ListO,T2,NewPara). sum_plus_list(A, B):- any_f(A), !, B = A. s u m _ p l u s _ l i s t ( A , B ) : - atom_num(A), B = A. sum_plus_list(List,Lnew):s u m _ p l u s ( L i s t , Sum, R e s t ) , Ll = [[Sum]|Rest], sum_again(List, L l , Lnew).  !,  s u m _ a g a i n ( L , L, L n e w ) : !, Lnew = L. s u m _ a g a i n ( _ , L, Lnew):sum_plus_list(L, Lnew). sum_plus(List,Sum,Rest):-  sum_p(List,0,Sum,Rest).  sum_p([],SoFar,SoFar,[]). sum_p([[H]|T],SoFar,Sum,Rest):- numberf(H, New i s S o F a r + N e w H , sum_p(T,New,Sum,Rest). sum_p([H|T],SoFar,Sum,Rest):sumt(H,Htime), sump_or_not(Htime,T,SoFar,Sum,Rest).  NewH),  !,  ListO  =  Listl,  P.93  sump_or_not(Htime,T,SoFar,Sum,Rest):New i s S o F a r + N e w H , sum_p(T,New,Sum,Rest). sump_or_not(Htime,T,SoFar,Sum,Rest):Rest = [Htime|RestT] , sum_p(T,SoFar,Sum,RestT).  numberf(Htime,  NewH),  !,  NewH),  !,  sumt(List,NewList):sum_time(List,Sum,Rest), NewList = [Sum|Rest]. sum_time(List,Sum,Rest):sum_t(List,1,Sum,Rest). sum_t([],SoFar,SoFar,[]). s u m _ t ( [ H | T ] , S o F a r , S u m , R e s t ) : - n u m b e r f ( H , NewH), New i s S o F a r * N e w H , sum_t(T,New,Sum,Rest) sum_t([H T],SoFar,Sum,Rest):- not_deal(H), !, R e s t = [H R e s t T ] , sum_t(T,SoFar,Sum,RestT). sum_t([H M|T],SoFar,Sum,Rest):!, sum_plus_list(H,Hplus), sumt_or_not(Hplus M,T,SoFar,Sum,Rest). sum_t([H|T],SoFar,Sum,Rest):sum_plus_list(H,Hplus), sumt_or_not(Hplus,T,SoFar,Sum,Rest).  !,  A  A  sumt_or_not(Hplus,T,SoFar,Sum,Rest):New i s S o F a r + N e w H , sum_t(T,New,Sum,Rest). sumt_or_not(Hplus,T,SoFar,Sum,Rest):Rest = [Hplus|RestT] , sum_t(T,SoFar,Sum,RestT). expand(E, Eexp):timeinto(E, Etime), expand_again(E, Etime, e x p a n d _ a g a i n ( E , E, E e x p = E. e x p a n d _ a g a i n ( _ , E, expand(E, Eexp).  Eexp).  Eexp):Eexp):-  timeinto(A * ( B + C ) , ABC = A * B + A * C . t i m e i n t o ( ( B + C) * A , ABC = B * A + C * A . t i m e i n t o ( A * (B - C ) , ABC = A * B - A * C . t i m e i n t o ( ( B - C) * A , ABC = B * A - C * A . t i m e i n t o ( A + B, A B ) : timeinto(A, Al), timeinto(B, Bl), AB = A l + B l . t i m e i n t o ( A - B, A B ) : timeinto(A, Al), timeinto(B, Bl),  ABC) ABC) ABC) ABC) !,  !,  !,  numberf(Hplus,  P.94  AB = A l - B l . t i m e i n t o ( - B, A B ) : !, timeinto(B, Bl), AB = - B l . t i m e i n t o ( A * B, A B ) : !, timeinto(A, Al), timeinto(B, Bl), AB = A l * B l . t i m e i n t o ( A / B, A B ) : !, timeinto(A, Al), timeinto(B, Bl) , AB = A l / B l . timeinto(F, NewF):- any_f(F), a r g ( l , F, A ) , timeinto(A, NewA), r e p l a c e ( N e w A , F, N e w F ) . timeinto(A, A). numberf(A, N ) : - number(A), N i s A. numberf(F, N ) : - any_f(F), a r g i l , F, A ) , numberf(A, NA), r e p l a c e ( N A , F, N e w F ) , N i s NewF. numberf(A, N):numf(A, N). numf(A+B, N):numberf(A, NA), numberf(B, NB), N i s NA+NB. numf(A-B, N ) : !, numberf(A, NA), numberf(B, NB), N i s NA-NB. numf(-B, N):numberf(B, NB), N i s -NB. numf(A*B, N):numberf(A, NA), numberf(B, NB), N i s NA*NB. numf(A/B, N):numberf(A, NA), numberf(B, NB), d i v _ t o _ i n t ( N A , NB, numf(A B, N):numberf(A, NA), numberf(B, NB), p o w e r ( N A , NB, N ) .  !,  !, !,  N).  A  divide_list(List, List, Div):!, Div = 1. divide_list(Listl,List2,Div):deal_list(Listl, Ldeall), deal_list(List2, Ldeal2), (divide(Ldeall,Ldeal2,L) -> true ; list_time_into(Ldeall, Ltimel),  P.95  list_time_into(Ldeal2, Ltime2), divide(Ltimel,Ltime2,L)) , sum_plus_list(L,Lsum), sort_list(Lsum, Div). deal_list(A, L d e a l ) : - atom(A), Ldeal = [[0],[1,A 1]]. deal_list(List, List).  !,  A  list_time_into(List, 12e(List, E), siml(E, Esiml), e21(Esiml, Ltime).  Ltime):-  rev_sort_list(List, Lnew):rev_time(List, Ll) , r e v _ s o r t ( L l , L2) , t2h(L2, Lnew). rev_time([], []). rev_time([H|T], [Hrev|Trev]):rev_sort(H, Hrev), rev_time(T, Trev). t2h([], []). t2h([H|T], [Ht2h|Tt2h]):t2hl(H, Ht2h), t2h(T, Tt2h). t2hl(List,  [Last|Rest]):-  t2hl(List,  t 2 h l ( [ L a s t ] , L, R ) : - ! , L = L a s t , t 2 h l ( [ H | T ] , L, [H|Tr]):t 2 h l ( T , L, Tr).  R = • [ ] .  divide(Listl,List2,L):rev_sort_list(Listl,Lsorl), rev_sort_list(List2,Lsor2), div(Lsorl,Lsor2,L). div([[A]],_,T):zero(A), !, T = div(Listl,List2,[H3|T3]):divl(Listl,List2,H3), H3=[H3H|H3T], H3negH i s - 1 * H 3 H , H3neg=[H3negH|H3T], time_list2(List2,H3neg,L), append(Listl,L,AppL), sum_plus_list(AppL,SumpL), sort_list(SumpL, Lsort), collect_like(Lsort,Lcoll) , zero_term(Lcoll, Lrem), rev_sort_list(Lrem, Lsorti), div(Lsorti,List2,T3). divl([Hl|_],[H2|_],H3):dd(Hl,H2,H3). d d ( [ H 1 | T 1 ] , [H2 | T 2 ] , [H3 | T 3 ] ) : -  Last,  [].  Rest).  P.96  div_to_int(Hi, d(T2,Tl,T3).  H2,  H3),  d( [ ] , L i s t l , L i s t l ) . d([H2|T2],Listl,Ldivision):dl(Listl,H2,NewLl), NewLl \= L i s t l , d(T2,NewLl,Ldivision). d l ( [] ,_, [] ) . dl([A M|T],A N,Lnew):MN i s M - N , Lnew = [ A M N | T n e w ] , dl(T, A N,Tnew). dl([A|T],A,Lnew):!, dl(T,A,Lnew). dl([H|T],A,[HINewT]):dl(T,A,NewT). A  N >=  A  0,  M > N,  !,  A  A  i n t _ t o _ i n t ( A , B, integer(A), integer(B) , real_int_div(A, div in div C  C):-  B,  C).  _ t o _ i n t ( A , B, C):t _ t o _ i n t ( A , B , C) , _ t o _ i n t ( A , B, C):is A/B.  !.  time_list2([],_,[]). time_list2([H2|T2],H3,[H|T]):find_h(H2,H3,H), time_list2(T2,H3,T). time_list2([H2|T2],H3,[H|T]):append(H3,H2,AppH), sumt(AppH,H), time_list2(T2,H3,T).  number(H2),  find_h(H2,[H3|[]],H):!, H i s H2*H3. find_h(H2,[H3|T3],[H|T3]):H i s H2*H3. zero_term([H|T],[H|NewT]):zero_terml(T,NewT). zero_terml([],[]). zero_terml([[A|_]|T],NewL):zero_terml(T,NewL). zero_terml([H|T],[H|NewT]):zero_terml(T,NewT).  zero(A),  del_list(List, Ldel):del_plus_list(List, Ldelp), reduce_plus_list(Ldelp, Ldel). del_plus_list(Ll, L2):del_plus(Ll, L3), (L3 = [ ] - > L2 = [ [ 0 ] ] ;  L2  = L3)  !,  !,  P.97  d e l ^ p l u s ( [ ] , L) : - ! , L = [ ] . del_plus([[A|_]|T], Ldelp):- zero(A), del_plus(T, Ldelp). del_plus([[A] T], L d e l p ) : - number(A), L d e l p = [ [A] NewT], del_plus(T, NewT). del_plus([H|T], [NewH|NewT]):!, del_time_list(H, NewH), del_plus(T, NewT). del_plus(A, A).  ! !,  del_time_list(List, Lnew):del_time(List, Ldel), (Ldel  =  []  ->  Lnew  =  [1];  Lnew  =  Ldel).  d e l _ t i m e ( [ ] , [ ] ) . del_time([H|T], Ldelt):- unit(H), !, del_time(T, Ldelt). del_time([_ M|T], L d e l t ) : - zero(M), !, del_time(T, Ldelt). del_time([H M|T], [NewH|NewT]):- u n i t ( M ) , not_deal(H) NewH = H, del_time(T, NewT). del_time([H M|T], [NewH|NewT]):!, del_plus_list(H, HI), NewH = H l ^ M , del_time(T, NewT). del_time([H|T], [NewH|NewT]):del_plus_list(H, NewH), del_time(T, NewT). reduce_plus_list([], L ) : - !, L = [ ] . reduce_plus_list([[-1,A]|T], Lred):- A = [_|_], !, insert_neg(A, L r e d , NewT), reduce_plus_list(T, NewT). reduce_plus_list([[A]|T], Lred):- A = [_|_], !, a p p e n d ( A , NewT, Lred), reduce_plus_list(T, NewT). reduce_plus_list([H|T], [NewH|NewT]):!, reduce_time_list(H, NewH), reduce_plus_list(T, NewT). reduce_plus_list(A, A). A  A  A  reduce_time_list([], []). reduce_time_list([[A]|T], Lredt):- ! , a p p e n d ( A , NewT, Lredt), reduce_time_list(T, NewT). reduce_time_list([H|T], [NewH|NewT]):- not_deal(H), NewH = H , reduce_time_list(T, NewT). reduce_time_list([H|T], [NewH|NewT]):reduce_plus_list(H, NewH), reduce_time_list(T, NewT). i n s e r t _ n e g ( [ ] , Tneg, Tneg). insert_neg([H|T], [Hinv|Tinv], neg(H, Hinv), insert_neg(T, Tinv, NewT).  NewT):-  !,  P.98  neg([-1, A ] , B ) : - ! , B = [A] . neg([-1|A], B ) : - ! , B = A. neg(A, [-1|A]). e211(E, L i s t ) : e2_plus_list(E,  [ ] ,  List).  e2_plus_list(A+B, Sofar, L i s t ) : e2_plus_list(B, Sofar, ListB), e2_plus_list(A, ListB, List). e2_plus_list(A, Sofar, List):e2_time_list(A, ListA), List = [ListA|Sofar]. e2_time_list(E,  List):-  !,  e2_time(E,  [ ] ,  List).  e2_time(A*B, Sofar, L i s t ) : !, e2_time(B, Sofar, ListB), e2_time(A, L i s t B , List). e2_time(A, Sofar, L i s t ) : - atom_num(A), !, List = [A|Sofar]. e2_time(A, Sofar, L i s t ) : - any_f(A, A l ) , !, List = [Al|Sofar]. e2_time(A M, Sofar, L i s t ) : - any_f(A, A l ) , !, List = [Al M|Sofar]. e2_time(A M, Sofar, L i s t ) : !, e211_or_not(A, L i s t A ) , List = [ListA M|Sofar]. e2_time(A, Sofar, List):e211_or_not(A, L i s t A ) , List = [ListA|Sofar]. A  A  A  A  any_f(F, Fl) : any_f(F), a r g ( l , F, A ) , sim(A, A l ) , r e p l a c e ( A l , F, F l ) . r e p l a c e ( N e w , T l , T2):f u n c t o r ( T l , N a m e , 1), f u n c t o r ( T 2 , N a m e , 1), a r g ( l , T2, N e w ) . e211_or_not(E, L N ) : - atom_num(E), LN = E. e211_or_not(E, L N ) : - a n y _ f ( E ) , !, LN = E. e21l_or_not(E, L N ) : -  !,  e211(E, L N ) .  plus_or_minus(Sofar, 12el(T, S o f a r - E T , E plus_or_minus(Sofar, 12el(T, S o f a r + E T , E  ET, T, ). ET, T, ).  positive_or_negtive(ET,  T,  E,  EThead):-  E, _ ) : -  E,  EThead):-  numberf(EThead,Num),  Num < 0 ,  !  P.99  numberf(EThead,Num), ETneg i s - E n , 1 2 e l ( T , ETneg, E ) . positive_or_negtive(ET numberf(EThead,Num), ETneg = -ET, 1 2 e l ( T , ETneg, E ) . positive_or_negtive(ET 1 2 e l ( T , ET, E ) .  Num <  0,  numberf(ET,En),  , T , E, EThead):Num < 0 , !,  ,  12e(List"M, E):- List = 12e(List, El). 12e([H|T], E):!, 12eT(H,ET,EThead) , positive_or_negtive(ET, 12e(A, A).  T,  E,  [_|_],  T,  E,  _)  :-  !,  E =  El M, A  EThead).  1 2 e l ( [ ] , Sofar, Sofar). 12el([H|T], Sofar, E):12eT(H,ET,EThead), plus_or_minus(Sofar,ET,T,E,EThead). 1 2 e T ( [ H | T ] , E, H ) : - n u m b e r f ( H , H n ) , Hpositive is -l*Hn, 12eTl(T, Hpositive, E). 1 2 e T ( [ H | T ] , E, H ) : - 1 2 e ( H , H e ) , 1 2 e T l ( T , He, E ) . 12eTl([], Sofar, Sofar). 12eTl([H|T], Sofar, E):12e(H, He), (unit(Sofar) - > 1 2 e T l ( T , H e , E) ; 12eTl(T, Sofar*He, E)).  Hn <  0,  !,  !  P.100  3 Divisional Subtotal %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % % % Divisional Subtotal % % % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% f i n d _ V a l ( k e y ( T , A , M, 0 ) , V a l ) : c o n t r o l ( 0 , S) , a c c o u n t ( k e y ( T , A , M, S ) , [ V a l | _ ] ,  _, _ ) .  sum_list(0, [ ] ) . sum_list(Total, [H|T]):sum_list(NTotal, T), Total i s NTotal+H.  4 Corporate Hierarchy %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % % %  Superior  and Subordinate  Relationship  %  % % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % CONTROL(SUPERIOR,  SUBSIDIARY)  direct_control(manufacturing, direct_control(manufacturing,  panther). starling).  control(Superior, Subsidiary):direct_control(Superior, Subsidiary). control(Superior, Subsidiary):direct_control(Superior, Intermediate), control(Intermediate, Subsidiary).  P.lOl  5 Controller's Database %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % % % C o n t r o l l e r ' s Database % % % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % ACCOUNT(KEY(ACCOUNT*, DEVIATION_ALLOWANCE)  MEASUREMENT,  TYPE,  OWNER),  % E S T I M A T E D MANUFACTURING BUDGET I N PERSONNEL account(key(exp, [1, 1, 0, 0], p e r s o n , p a n t h e r ) , personnel'). %panther personnel account(key(exp, [1, 1, 'Starling personnel').  0, 0], p e r s o n , s t a r l i n g ) , %Starling personnel  VALUE,  [53,  [31,  76],  55],  0.10,  'Panther  0.10,  account(key(exp, [1, 1, 0, 0], p e r s o n , m a n u f a c t u r i n g ) , [84, 131], 0.10, •Manufacturing personnel'). % m a n u f a c t u r i n g p e r s o n n e l - h o r i z o n t a l sum  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % E S T I M A T E D MANUFACTURING BUDGET I N DOLLAR account(key(exp, [1, 0, 0, 0], d o l l a r , p a n t h e r ) , 1444000], 0.10, ' P a n t h e r b u d g e t ' ) . %panther  [1330000, 1168000,  account(key(exp, [1, 0, 0, 0], d o l l a r , s t a r l i n g ) , [926000, 968000, 1336000], 0.10, 'Starling budget'). %Starling account(key(exp, [1, 0, 0, 0], d o l l a r , m a n u f a c t u r i n g ) , [2256000, 2136000, 2780000], 0.10, ' T o t a l , m a n u f a c t u r i n g b u d g e t ' ) . %manufacturing h o r i z o n t a l sum %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %TOTAL E S T I M A T E D BUDGET I N DOLLAR account(key(exp, [1, 1, 'Manufacturing personnel  0, 0],  dollar, manufacturing), [1740000], expenses'). %manufacturing personnel  0.10,  account(key(exp, [1, 2, 0, 0], d o l l a r , m a n u f a c t u r i n g ) , [90000], 0.10, 'Manufacturing material and supplies expense'). %manufacturing material and s u p p l i e s account(key(exp, [1, 3, 0, 0], d o l l a r , m a n u f a c t u r i n g ) , [410000], 0.10, 'Manufacturing computer services expenses'). %manufacturing computer services account(key(exp, [1, 3, 1, 0], d o l l a r , m a n u f a c t u r i n g ) , [410000], 0.10, 'Regular s e r v i c e s ' ) . %regular services account(key(exp, [1, 4, 0, 0], d o l l a r , m a n u f a c t u r i n g ) , [16000], 0.10, 'Manufacturing miscellaneous expenses'). %manufacturing miscellaneous  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % T 0 T A L E S T I M A T E D PERSONNEL EXPENSES account(key(exp, [1, 1, 2, 0], d o l l a r , m a n u f a c t u r i n g ) , [1535592], ' S a l a r y b a s e d o n 1982 a v e r a g e ' ) . %salary based on average account(key(exp, [1, 1, 3, 0], d o l l a r , m a n u f a c t u r i n g ) , [204408], 'Other expenses') . %other  0.10, 0.10,  P.102  account(key(exp, [1, 'Misc. expenses ' ) .  1, 3, 1],  dollar,  manufacturing),  [204408],  0.10,  %other  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %FORMULA TO C A L C U L A T E AVERAGE SALARY equation(key(exp, [1, 1, 2, 0], d o l l a r , manufacturing), ave_salary*man_personnel). alias(man_personnel, key(exp, [1, 9, 8, 8], p e r s o n , manufacturing)), alias(ave_salary, key(exp, [1, 9, 9, 9], d o l l a r , manufacturing)), account(key(exp, [1, 9, 9, 9], d o l l a r , m a n u f a c t u r i n g ) , [14088], 0.10, '1982 average s a l a r y ' ) . %average salary account(key(exp, [1, 9, 'Number o f p e r s o n n e l ' ) .  8, 8], p e r s o n , m a n u f a c t u r i n g ) , [109], %Number o f p e r s o n n e l f o r s e n s i t i v i t y  0.10, analysis  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %MANUFACTURING PARTS COUNT account(key(asset, [2, 0, 0, 0], p a r t s , parts count'). %panther p a r t s count account(key(asset, [2, 0, parts count'). %starling  0, 0], parts  panther),  parts,starling), count  [10200], 0.10, [0],  0.10,  'Panther  'Starling  % T O T A L OF T H E ABOVE I T E M S I S USED TO C A L C U L A T E T O T A L PERSONNEL EXPENSE account(key(asset, [2, 0, 0, 0], p a r t s , m a n u f a c t u r i n g ) , [10200], 0.10, 'Manufacturing parts count'). %manufacturing parts count  %%%%%%%%%%%Department Subtotal%%%%%%%%%%%% %%%%sum o f s a m e a c c o u n t a t a h i g h e r l e v e l o f t h e o r g a n i z a t i o n a l a c c o u n t ( k e y ( T , A , M, O ) , T o t a l , _ , _ ) : b a g o f ( V a l , f i n d _ V a l ( k e y ( T , A , M, O ) , V a l ) , L ) , sum_list(Total, L ) .  hierarchy  P.103  6 Manufacturing Office's Database %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % % %  Manufacturing's  Database  %  % % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % A C C O U N T ( K E Y ( T Y P E , ACCOUNT#, MEASUREMENT, DEVIATION_ALLOWANCE, DESCRIPTION)  OWNER),  VALUE,  % S T A R L I N G PERSONNEL account(key(exp, [ 1 , 1, 2, 0 ] , person, s t a r l i n g ) , [8], 0.10, spec c o n t r o l p e r s o n n e l ' ) . % S t a r l i n g spec control account(key(exp, [ 1 , 1 , 3, 0 ] , person, s t a r l i n g ) , [19], 0.10, design parts control personnel'). %Starling design parts con account(key(exp, [ 1 , 1, 4, 0 ] , person, s t a r l i n g , 'Starling pla control personnnel'), [4], 0.10). %Starling planning and con %SUBTOTAL OF T H E ABOVE S T A R L I N G ACCOUNTS account(key(exp, [ 1 , 1 , 0, 0 ] , p e r s o n , s t a r l i n g ) , total personnel'). %Starling total personnel  [31], 0.10,  'Starling 'Starling trol nning and trol  'Starling  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %PANTHER PERSONNEL account(key(exp, [ 1 , 1, 1, 0 ] , person, panther), [2], 0.10, manager a n d s e c r e t a r y ' ) . %panther manager a n d s e c r e t a r y account(key(exp, [ 1 , 1, 2, Spec C o n t r o l p e r s o n n e l ' ) .  0 ] , person, panther), %panther spec control  [17], 0.10,  'Panther  'Panther  account(key(exp, [ 1 , 1 , 3, 0 ] , person, p a n t h e r ) , [48], 0.10, design personnel'). %panther design p a r t s control  'Pather  account(key(exp, [ 1 , 1, planning and c o n t r o l ' ) .  'Panther  4, 0 ] , person, panther), [11], 0.10, %panther p l a n n i n g and c o n t r o l  %SUBTOTAL OF T H E ABOVE PANTHER ACCOUNTS account(key(exp, [ 1 , 1 , 0, 0 ] , p e r s o n , p a n t h e r ) , total personnel'). %Panther t o t a l personnel  [78], 0.10,  'Panther  account(key(exp, [ 1 , 1 , 0, 0 ] , p e r s o n , m a n u f a c t u r i n g ) , [109], 0.10, 'Manufacturing total personnel'). %Manufacturing t o t a l personnel %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %MANUFACTURING T O T A L BUDGET I N DOLLAR AMOUNT account(key(exp, [ 1 , 1 , 0, 0 ] , d o l l a r , m a n u f a c t u r i n g ) , [2320000], 'Manufacturing personnel expense'). %manufacturing personnel  0.10,  account(key(exp, [ 1 , 2, 'Manufacturing material supplies  0, 0 ] , d o l l a r , m a n u f a c t u r i n g ) , [90000], 0.10, and s u p p l i e s ' ) . %manufacturing m a t e r i a l and  account(key(exp, [ 1 , 3, 'Manufacturing computer  0, 0 ] , d o l l a r , m a n u f a c t u r i n g ) , [490000], 0.10, services'). %manufacturing computer services  P.104  account(key(exp, [1, 4, 0, 0], d o l l a r , manufacturing), [16000], 0.10, 'Manufacturing miscellaneous expense'). %manufacturing miscellaneous %T0TAL OF THE ABOVE MANUFACTURING ACCOUNTS - Total D o l l a r Budget account(key(exp, [1, 0, 0, 0], d o l l a r , manufacturing), [2916000], 'Manufacturing t o t a l budget'). %manufacturing t o t a l budget  0.10,  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %MANUFACTURING TOTAL PERSONNEL IN DOLLAR AMOUNT account(key(exp, [1, 1, 1, 0], d o l l a r , manufacturing), 'One-time personnel c o s t ' ) . %one-time personnel cost  [144610],  0.10,  account(key(exp, [1, 1, 2, 0], d o l l a r , manufacturing), [1718712, 1535592], 0.10, 'Salary based on avarage salary 1983'). %salary based on avarage account(key(exp, [1, 1, 3, 0], d o l l a r , manufacturing), 'Other expenses'). %other account(key(exp, [1, 1, 3, 1], d o l l a r , manufacturing), 'Misc. expenses'). %other account(key(exp, [1, 1, 3, 2], d o l l a r , manufacturing), 'Workload i n c r e a s e ' ) . %other  [456678],  0.10,  [204408],  0.10,  [252270],  0.10,  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %FORMULA TO CALCULATE AVERAGE SALARY equation(key(exp, [1, 1, 2, 0], d o l l a r , manufacturing), man_personnel*ave_salary). %alias(man_personnel, key(exp, [1, 1, 0, 0], person, manufacturing)), alias(man_personnel, key(exp, [1, 9, 8, 8], person, manufacturing)), a l i a s ( a v e _ s a l a r y , key(exp, [1, 9, 9, 9], d o l l a r , manufacturing)). account(key(exp, [1, 9, 9, 9], d o l l a r , manufacturing), 0.10, '1983 Average s a l a r y ' ) . %average s a l a r y  [15768, 14088],  account(key(exp, [1, 9, 8, 8], person, manufacturing), [109], 'Number of p e r s o n n e l ' ) . %Number of personnel for s e n s i t i v i t y  0.10, analysis  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %MANUFACTURING COMPUTER SERVICES IN DOLLAR AMOUNT account(key(exp, [1, 3, 1, 0], d o l l a r , manufacturing), [410000], 0.10, 'Regular s e r v i c e s ' ) . %regular services account(key(exp, [1, 3, 2, 0], d o l l a r , manufacturing), [80000], 0.10, 'One time computer c o s t ' ) . %0NE-TIME CHARGE %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %MANUFACTURING PARTS COUNT account(key(exp, [2, 0, 0, 0], p a r t s , panther), [11600, 10200], 0.10, 'Panther parts c o u n t ' ) . %panther parts count account(key(exp, [2, 0, 0, 0], p a r t s , s t a r l i n g ) , [4800], 0.10, ' S t a r l i n g parts c o u n t ' ) . %starling parts count % TOTAL OF THE ABOVE ITEMS IS USED TO CALCULATE TOTAL PARTS account(key(exp, [2, 0, 0, 0], parts,manufacturing), [16400, 10200], 0.10, 'Manufacturing parts c o u n t ' ) . %manufacturing parts count  P.105  %%%%%%%%%%%Department Subtotal%%%%%%%%%%%% %%%%sum o f s a m e a c c o u n t a t a h i g h e r l e v e l o f t h e a c c o u n t ( k e y ( T , A , M, 0 ) , T o t a l , _ , _ ) : b a g o f ( V a l , f i n d _ V a l ( k e y ( T , A , M, 0 ) , V a l ) , sum_list(Total, L).  organizational L),  hierarchy  p.m  APPENDIX D  1 Test Result Controller:  ***  C o n t r o l l e r : Checking the f o l l o w i n g item: account(key(exp, [1,0,0,0], d o l l a r , manufacturing), [2916000], 0.100000, Manufacturing t o t a l budget) C o n t r o l l e r : The r e q u e s t e d item Manufacturing t o t a l budget (key(exp, [1,0,0,0], d o l l a r , manufacturing)) exceeds l i m i t . C o n t r o l l e r : Ask the o r i g i n a t o r t o supply i n f o r m a t i o n on subsidiary divisions. C o n t r o l l e r : W r i t i n g command f i l e t o r e q u e s t d e t a i l o f (key(exp, [1,0,0,0], d o l l a r , m a n u f a c t u r i n g ) ) . C o n t r o l l e r : P l e a s e s t a r t another i n s t a n c e o f p r o l o g t o generate response. C o n t r o l l e r : When response the c u r r e n t p r o c e s s .  i s r e c e i v e d , type 1 t o c o n t i n u e  Manufacturing: The r e q u e s t e d data i s n o t a v a i l a b l e . No data w i l l be p r o v i d e d .  C o n t r o l l e r : The requested data i s not a v a i l a b l e , to perform the next t e s t .  Continue  C o n t r o l l e r : The requested item Manufacturing t o t a l budget (key(exp, [1,0,0,0], d o l l a r , manufacturing)) exceeds l i m i t . C o n t r o l l e r : Ask the o r i g i n a t o r t o supply i n f o r m a t i o n on any c a t e g o r i c a l sub-accounts.  P.107  C o n t r o l l e r : W r i t i n g command f i l e t o r e q u e s t d e t a i l o f (key(exp, [1,0,0,0], d o l l a r , m a n u f a c t u r i n g ) ) . C o n t r o l l e r : P l e a s e s t a r t another i n s t a n c e o f p r o l o g t o generate response. C o n t r o l l e r : When response the c u r r e n t p r o c e s s .  i s r e c e i v e d , type 1 t o c o n t i n u e  Manufacturing:  Collecting categorical  Manufacturing:  W r i t i n g c o l l e c t e d accounts t o f i l e  Controller:  sub-accounts  ***  C o n t r o l l e r : Checking the f o l l o w i n g item: account(key(exp, [1,1,0,0], d o l l a r , manufacturing), [2320000], 0.100000, Manufacturing p e r s o n n e l expense) C o n t r o l l e r : The requested item Manufacturing p e r s o n n e l expense (key(exp, [1,1,0,0], d o l l a r , manufacturing)) exceeds limit. C o n t r o l l e r : Ask the o r i g i n a t o r t o supply i n f o r m a t i o n on any c a t e g o r i c a l sub-accounts. C o n t r o l l e r : W r i t i n g command f i l e t o r e q u e s t d e t a i l o f (key(exp, [1,1,0,0], d o l l a r , m a n u f a c t u r i n g ) ) . C o n t r o l l e r : P l e a s e s t a r t another i n s t a n c e o f p r o l o g t o generate response. C o n t r o l l e r : When response i s r e c e i v e d , type 1 t o c o n t i n u e the c u r r e n t p r o c e s s .  Manufacturing:  Collecting categorical  sub-accounts  Manufacturing:  W r i t i n g c o l l e c t e d accounts t o f i l e  p.m  Controller:  ***  C o n t r o l l e r : Checking the f o l l o w i n g item: account(key(exp, [1,1,1,0], d o l l a r , manufacturing), [144610], 0.100000, Onetime p e r s o n n e l c o s t ) C o n t r o l l e r : One-time p e r s o n n e l c o s t = 144610 (key(exp, [1,1,1,0], d o l l a r , manufacturing)) exceeds l i m i t > NOT APPROVED  Controller:  ***  C o n t r o l l e r : Checking the f o l l o w i n g item: account(key(exp, [1,1,2,0], d o l l a r , manufacturing), [1718712], 0.100000, S a l a r y based on avarage s a l a r y 1983) C o n t r o l l e r : The r e q u e s t e d item S a l a r y based on avarage s a l a r y 1983 (key(exp, [1,1,2,0], d o l l a r , manufacturing)) exceeds l i m i t . Controller:  Ask the o r i g i n a t o r t o supply e q u a t i o n .  C o n t r o l l e r : W r i t i n g command f i l e t o r e q u e s t d e t a i l o f (key(exp, [1,1,2,0], d o l l a r , m a n u f a c t u r i n g ) ) . C o n t r o l l e r : P l e a s e s t a r t another i n s t a n c e o f p r o l o g t o generate response. C o n t r o l l e r : When response i s r e c e i v e d , type 1 t o c o n t i n u e the c u r r e n t p r o c e s s .  Manufacturing: Manufacturing: text f i l e .  Controller:  The r e q u e s t e d e q u a t i o n i s found. W r i t i n g the.requested equation to  ***  C o n t r o l l e r : E q u a t i o n checked, i n d i v i d u a l component.  proceed t o check the v a l u e o f  C o n t r o l l e r : W r i t i n g command f i l e t o r e q u e s t d e t a i l o f (key(exp, [1,9,9,9], d o l l a r , m a n u f a c t u r i n g ) ) . C o n t r o l l e r : P l e a s e s t a r t another i n s t a n c e o f p r o l o g t o generate response. . r:  P.109  C o n t r o l l e r : When response i s r e c e i v e d , type 1 t o c o n t i n u e the c u r r e n t p r o c e s s .  Manufacturing: W r i t i n g the components o f t h e requested eqation to f i l e .  Controller:  ***  C o n t r o l l e r : Checking the f o l l o w i n g item: account(key(exp, [1,9,9,9], d o l l a r , manufacturing), [15768,14088], 0.100000, 1983 Average s a l a r y ) C o n t r o l l e r : 1983 Average s a l a r y = 15768 (key(exp, [1,9,9,9], d o l l a r , manufacturing)) exceeds l i m i t > NOT APPROVED C o n t r o l l e r : W r i t i n g command f i l e t o r e q u e s t d e t a i l o f (key(exp, [1,9,8,8], person, m a n u f a c t u r i n g ) ) . C o n t r o l l e r : P l e a s e s t a r t another i n s t a n c e o f p r o l o g t o generate response. C o n t r o l l e r : When response i s r e c e i v e d , type 1 t o c o n t i n u e the c u r r e n t p r o c e s s .  Manufacturing: W r i t i n g the components o f the requested eqation to f i l e .  Controller:  ***  C o n t r o l l e r : Checking the f o l l o w i n g item: account(key(exp, [1,9,8,8], person, manufacturing), [109], 0.100000, Number o f personnel) C o n t r o l l e r : Number o f p e r s o n n e l (key(exp, person, manufacturing)) = 109 > APPROVED  [1,9,8,8],  p.no  Controller:  ***  C o n t r o l l e r : Checking the f o l l o w i n g item: account(key(exp, [1,1,3,0], d o l l a r , manufacturing), [456678], 0.100000, Other expenses) C o n t r o l l e r : The r e q u e s t e d item Other expenses (key(exp, [1,1,3,0], d o l l a r , manufacturing)) exceeds l i m i t . C o n t r o l l e r : Ask the o r i g i n a t o r t o s u p p l y i n f o r m a t i o n on any c a t e g o r i c a l sub-accounts. C o n t r o l l e r : W r i t i n g command f i l e t o r e q u e s t d e t a i l o f (key(exp, [1,1,3,0], d o l l a r , m a n u f a c t u r i n g ) ) . C o n t r o l l e r : P l e a s e s t a r t another i n s t a n c e o f p r o l o g t o generate response. C o n t r o l l e r : When response i s r e c e i v e d , type 1 t o c o n t i n u e the c u r r e n t p r o c e s s .  Manufacturing:  Collecting categorical  Manufacturing:  W r i t i n g c o l l e c t e d accounts t o f i l e  Controller:  sub-accounts  ***  C o n t r o l l e r : Checking the f o l l o w i n g item: account(key(exp, [1,1,3,1], d o l l a r , manufacturing), [204408], 0.100000, M i s c . expenses) C o n t r o l l e r : Misc. expenses (key(exp, manufacturing)) = 204408 > APPROVED Controller:  [1,1,3,1], d o l l a r ,  ***  C o n t r o l l e r : Checking the f o l l o w i n g item: account(key(exp, [1,1,3,2], d o l l a r , manufacturing), [252270], 0.100000, Workload i n c r e a s e ) C o n t r o l l e r : Workload i n c r e a s e = 252270 (key(exp, [1,1,3,2], d o l l a r , manufacturing)) exceeds l i m i t > NOT APPROVED Controller:  ***  p.m C o n t r o l l e r : Checking the f o l l o w i n g item: account(key(exp, [1,2,0,0], d o l l a r , manufacturing)-, [90000], 0.100000, Manufacturing m a t e r i a l and s u p p l i e s ) C o n t r o l l e r : Manufacturing m a t e r i a l and s u p p l i e s (key(exp, [1,2,0,0], d o l l a r , manufacturing)) = 90000 > APPROVED  Controller:  ***  C o n t r o l l e r : Checking the f o l l o w i n g item: account(key(exp, [1,3,0,0], d o l l a r , manufacturing), [490000], 0.100000, Manufacturing computer s e r v i c e s ) C o n t r o l l e r : The r e q u e s t e d item Manufacturing computer s e r v i c e s (key(exp, [1,3,0,0], d o l l a r , manufacturing)) exceeds limit. C o n t r o l l e r : Ask the o r i g i n a t o r t o s u p p l y i n f o r m a t i o n on any c a t e g o r i c a l sub-accounts. C o n t r o l l e r : W r i t i n g command f i l e t o request d e t a i l o f (key(exp, [1,3,0,0], d o l l a r , m a n u f a c t u r i n g ) ) . C o n t r o l l e r : P l e a s e s t a r t another i n s t a n c e o f p r o l o g t o generate response. C o n t r o l l e r : When response i s r e c e i v e d , type 1 t o c o n t i n u e the c u r r e n t p r o c e s s .  Manufacturing:  Collecting categorical  Manufacturing:  W r i t i n g c o l l e c t e d accounts t o f i l e  Controller:  sub-accounts  ***  C o n t r o l l e r : Checking the f o l l o w i n g item: account(key(exp, [1,3,1,0], d o l l a r , manufacturing), [410000], 0.100000, Regular services) C o n t r o l l e r : Regular s e r v i c e s (key(exp, manufacturing)) = 410000 > APPROVED  [1,3,1,0], d o l l a r ,  P.112  Controller:  ***  C o n t r o l l e r : Checking the f o l l o w i n g item: account(key(exp, [1,3,2,0], d o l l a r , manufacturing), [80000], 0.100000, One time computer c o s t ) C o n t r o l l e r : One time computer c o s t = 80000 (key(exp, [1,3,2,0], d o l l a r , manufacturing)) exceeds l i m i t > NOT APPROVED Controller:  ***  C o n t r o l l e r : Checking the f o l l o w i n g item: account(key(exp, [1,4,0,0], d o l l a r , manufacturing), [16000], 0.100000, Manufacturing m i s c e l l a n e o u s expense) C o n t r o l l e r : Manufacturing m i s c e l l a n e o u s expense (key(exp, [1,4,0,0], d o l l a r , manufacturing)) = 16000 > APPROVED Controller:  no more items i n t h i s  list  

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.831.1-0087622/manifest

Comment

Related Items