WO2011008186A1

WO2011008186A1 - Software-based system and method for business management

Info

Publication number: WO2011008186A1
Application number: PCT/US2009/004042
Authority: WO
Inventors: Bander Abdullah Mohammed Al-Saud; Tahir Rashid; Nader Jaber Saleh
Original assignee: Soroof International; 30550.03 Patent Trust
Priority date: 2009-07-13
Filing date: 2009-07-13
Publication date: 2011-01-20

Abstract

The software-based business management system (10) is an integrated business management system for managing financial transactions and interactions of small and mid-size businesses. The system (10) includes at least one central server (12) having computer-readable memory (14) and a computer display (16) associated therewith. Multiple users of the business access the at least one server (12) through remote network terminals (18). The system (10) allows integration of a wide variety of business-related tasks and functions, and may be integrated into an existing network, using existing software and hardware. A plurality of software modules, each representing a different aspect of a business to be managed, are integrated into the system (10). System (10) incorporates a financial module (22), a fixed asset module (24), a sales module (26), a security module (48), a purchasing module (28), an inventory module (30), a human resources module (32) and a report module (34).

Description

SOFTWARE-BASED SYSTEM AND METHOD FOR BUSINESS MANAGEMENT

TECHNICAL FIELD

The present invention relates to computer systems and computerized methods for managing businesses. BACKGROUND ART

Computer database management systems are widely used in both standalone computer systems, as well as web-enabled distributed computer systems. Database application programs operate by retrieving data from the database management system, performing modifications on the data and returning the data to the database management system. Database management systems are accessed through interface functions that control the manner in which data is accessed. In a small or mid-size business, the business may service a large number of accounts. In an effort to deal with these large customer databases, businesses typically maintain these records on multiple-user databases. Therefore, each department has a program that maintains these records. However, in such a system, information must be extensively duplicated and thus, over time, maintaining database system performance becomes a challenge.

In a rapidly changing high technology business environment, where information management of the business organization is often a critical factor in maintaining competitiveness, it has become increasingly necessary for businesses to adopt software business platforms in an effort to enable the efficient sharing of information within a corporation. Typically, such platforms have a database that stores corporate information, business application software for its business functions (typically finance, sales, marketing, etc.), a security or user access system that controls access to the information by a number of users that are assigned roles that permit or deny access to the information, based on the assigned role of the individual, and a system bus that provides an interface permitting the various components of the system to communicate with each other according to certain protocols. However, in many instances, these business platforms may have developed separately over time so that the various modules relating to business functions, such as marketing and sales, may have different configurations, and may be coded in different software languages, thereby complicating communication between the modules and adding complexity to information sharing between corporate divisions and the generation of reports for management. Further, as business organizations grow in size, complexity and need for more information sharing, the business platforms and modules often lack sufficient scalability to keep pace.

The issues that pertain to intra-business software platforms is further complicated when the business platform is one that serves a variety of separate business entities, that may be independent corporations, partnerships or other business entities, and that may be hosted by a third party. For a variety of reasons, it may be desirable for these separate and independent business entities to share information. For example, in a franchise operation, it may be desirable for franchisees (that are independent corporations) to share information with a franchiser, and it may also be necessary for and desirable for franchisees in a regional area to share information between themselves, with regard to certain functions, such as marketing, but perhaps not with regard to other functions, such as finance. This would be further complicated if several franchise operations were to share the same platform, hosted by a third party. Clearly, information sharing between franchises would not be desired or allowed but some franchisees might hold multiple franchises. Accordingly, the sharing of information is not only complicated due to the separate business entities involved, but also the degree and extent of information sharing that is required.

Further, in an inter-business software platform, that may be hosted by a third party, it might be expected that the separate business entities may each have before hand developed their own business modules, for example each might already have developed their own marketing, sales, accounting and web management modules, before the advent of the hosted platform. There may be a considerable difference between the nature, configuration, language, etc. of the modules between the businesses that must now share certain information. This presents highly complex integration and information sharing issues to be resolved.

Business entities participating in an inter-business platform (or simply multiple users on multiple terminals in an intra-business platform) may share common data access on their networked computers. Maintaining uniform and consist data access is an important aspect of sales, customer relationships, and overall business strategy. Non-integrated and non- accessible data, flowing from one computer to another, may result in loss of sales and profits, due to lack of communication and inefficiency of data flow.

Thus, an integrated software-based business management system solving the aforementioned problems is desired. DISCLOSURE OF INVENTION

The software-based business management system is an integrated business management system for managing financial transactions and interactions of small and midsize businesses. The system includes at least one central server having computer-readable memory and a computer display associated therewith. Multiple users of the business access the at least one server through remote network terminals. The system allows integration of a wide variety of business-related tasks and functions, and may be integrated into an existing network, using existing software and hardware. A plurality of software modules, each representing a different aspect of a business to be managed, are integrated into the system. The system incorporates a financial module, a fixed asset module, a sales module, a security module, a purchasing module, an inventory module, a human resources module and a report module.

In use, one or more users input financial-based data to establish a financial data set; sales-based data to establish a sales data set; purchasing-based data to establish a purchasing data set; inventory data to establish an inventory data set; and human resources-based data to establish a human resources data set. These data sets are stored in a database associated with the computer-readable memory. At least one journal voucher is generated, including calculated net financial data based upon the financial data set, the sales data set, the purchasing data set, the inventory data set and the human resources data set. The net financial data is then recorded in a general ledger stored in the computer-readable memory, and at least one report is generated based upon the net financial data recorded in the general ledger. The report is then displayed on a computer display.

These and other features of the present invention will become readily apparent upon further review of the following specification and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 is a block diagram illustrating the software-based system for business management according to the present invention.

Fig. 2 is a block diagram illustrating the overall software architecture for the software- based system for business management according to the present invention.

Fig. 3 is a block diagram illustrating the sub-modules and the financial module of the software-based system for business management according to the present invention. Fig. 4 is a flowchart illustrating data flow in the payroll sub-module of the software- based system for business management according to the present invention.

Fig. 5 is a flowchart illustrating data flow in the accounts payable sub-module of the software-based system for business management according to the present invention.

Fig. 6 is a flowchart illustrating data flow in the accounts receivable sub-module of the software-based system for business management according to the present invention.

Fig. 7 is a flowchart illustrating data flow in the budget sub-module of the software- based system for business management according to the present invention.

Fig. 8 is a flowchart illustrating data flow in the general ledger sub-module of the software-based system for business management according to the present invention.

Fig. 9 is a flowchart illustrating data flow in the fixed asset module of the software- based system for business management according to the present invention.

Fig. 10 is a flowchart illustrating data flow in the inventory module of the software- based system for business management according to the present invention.

Fig. 11 is a flowchart illustrating data flow in the human resources module of the software-based system for business management according to the present invention.

Fig. 12 is a flowchart illustrating data flow in the sales module of the software-based system for business management according to the present invention.

Fig. 13 is a flowchart illustrating data flow in the security module of the software- based system for business management according to the present invention.

Fig. 14 is a flowchart illustrating data flow in a career development module of the software-based system for business management according to the present invention.

Fig. 15 is a flowchart illustrating data flow in a cash flow module of the software- based system for business management according to the present invention.

Fig. 16 is a flowchart illustrating data flow in a training module of the software-based system for business management according to the present invention.

Fig. 17 is a block diagram illustrating the overall software architecture for the software-based system for business management according to the present invention, specifically adapted for an intellectual property implementation.

Fig. 18 is a flowchart illustrating data flow in a purchasing module of the software- based system for business management according to the present invention.

Similar reference characters denote corresponding features consistently throughout the attached drawings. BEST MODES FOR CARRYING OUT THE INVENTION

The software-based business management system 10, illustrated schematically in Figs. 1 and 2, is an integrated business management system for managing financial transactions and interactions of small and mid-size businesses. As shown in Fig. 1, the system 10 includes at least one central server 12 having a processor 20 (e.g., a microprocessor), computer-readable memory 14 (which may be volatile or non- volatile computer memory, and includes both an area of main memory connected to the processor 20 by a bus and a data storage device including read only memory [ROM], random access memory [RAM], or both) and a computer display 16 associated therewith. The server 12 is connected to a network through a data communications device, which may be a modem, a network interface card, a router, etc. Multiple users 18 of the business access the at least one server 12 through the network, which may be in the form of a local area network (LAN), a wide area network (WAN), an intranet, an extranet, the Internet, or any other network through either an Ethernet, a telecommunications network, or a wireless network. The client's user interface may be through any Web browser.

The system 10 allows integration of a wide variety of business-related tasks and functions, and may be integrated into an existing network, using existing software and hardware. As best shown in Fig. 2, a plurality of software modules, each representing a different aspect of a business to be managed, are integrated into system 10. Each module communicates via interconnection with processor 20 of server 12. Processor 20 may be any suitable type of processor associated with a computer server, such as a programmable logic controller or the like. Memory 14 associated with server 12 incorporates at least one database 15, and users may write to the database, change entries in the database, and read information from the database, either directly at server 12 or through the remote terminals illustrated in Fig. 1. As will be discussed in greater detail below, system 10 includes a security module 48, which may provide selective access to database 15, dependent upon a user's particular security level. For example, some users may be able to only read data, rather than write new data or change existing data entries.

System 10 incorporates a financial module 22, a fixed asset module 24, a sales module 26, a security module 48, a purchasing module 28, an inventory module 30, a human resources module 32 and a report module 34. Each module may incorporate sub-modules. For example, human resources module 32 includes a payroll sub-module 46. As best shown in Fig. 3, the financial module 22 includes a general ledger sub-module 36, a budget sub- module 38, an accounts payable sub-module 40 and an accounts receivable sub-module 42.

The financial module 22 incorporates basic accounting functionality, providing the user with accounting templates, which may be displayed to the user, and which may be filled by the user with general accounting and financial information. The templates may be modified to provide a wide variety of fillable options, which may be specific to a country, a type of business or the like. As will be described in greater detail below, the modules of system 10 allow for the creation of journal entries and journal vouchers, which may incorporate user notes, pre-defined fillable templates, or may include automatically generated reports. Creation of journal entries and vouchers may be accomplished using any desired software, and may be incorporated into existing software, such as Microsoft Outlook®, for example.

Multiple manual journal entries can be saved to a batch, located in memory 14, and may be processed simultaneously by processor 20, thus allowing verification and correction of postings before they are entered in the general ledger. The general ledger sub-module 36 creates, stores and controls editing of a general financial ledger which is stored in database 15 and may be used to generate printable or displayable reports, as will be discussed in greater detail below. Users may define general ledger account assignment models, which may save the user time and aids in preventing mistakes during the manual posting of journal entries. Additionally, users may reverse journal entries and ventures, allowing users to reverse month-end accruals postings automatically. By default, reversal of specified postings will occur on the first day of the following calendar month in the preferred embodiment, but if necessary, users can specify a different reversing date for each posting.

The financial module 22, in conjunction with updated information stored in database 15, allows the user to calculate exchange rate differences, which may be automatically applied to the general ledger. Thus, users may periodically evaluate their open items in foreign currencies, and then identify differences and choose the appropriate correction transaction.

Financial module 22 allows the user to access, generate and alter financial report templates. Users may generate any number of financial report templates. Users may create templates for any purpose, such as additional profit-and-loss statements, for example. The budget sub-module 38 aids the user to define and manage budgets. Users can configure budget allocation methods and display a summarized budget report on display 16 that compares actual and planned figures. In addition, users can define an online alert that notifies them whenever a transaction exceeds a monthly or annual budget limit, which may be entered by the user or determined automatically through calculations to be described in greater detail below.

Users may also define different profit centers or departments. Users can allocate the corresponding revenue and cost accounts to a predefined profit center in the chart of accounts. In conjunction with the profit center allocation within financial module 22, profit center reports may be generated, to be displayed or saved in memory. The profit-and-loss statement is based on revenues and costs (both direct and indirect) as defined in the allocation rules (which may be entered by the user and stored in memory 14), and the report may be run for any profit center. Users may select between annual and monthly display formats and compare the results with figures for the previous period.

The fixed asset module 24 allows the streamlining of different fixed asset management functions, such as depreciation calculation, sale, disposal and exchange of assets and any asset-related expenditure. The fixed asset module 24 provides users with forecasted information on depreciation costs of all fixed assets or a specific asset record in the system. Users may monitor any expenditure that will be incurred for given fixed assets. A budget may be set for these expenditures.

The sales module 26 allows users to record each sales opportunity, from a first phone call to the successful close of a transaction. Sales information is stored, as journal entries, vouchers or ledger entries, in database 15 of memory 14, and may be accessed by the users through the network. Users can enter various details concerning the sales opportunity, including the source, potential, closing date, competitors, and activities. As soon as the first relevant quotation is created, users can link it with the opportunity to simplify later tracking and analysis. The sales quotation capability of system 10 offers flexibility when creating the contents of quotations or any marketing document.

Different line types are supported, allowing users to create subtotals of previous lines. The gross profit can then be calculated for each quotation. The last sales prices offered to a customer can be viewed via accessing the information, stored in database 15, and displayed on display 16. Once a quotation is created, users can export it to existing display and editing software, such as Microsoft Word®, for example.

Sales module 26 includes templates for sales orders. These templates simplify sales order entry by giving the order taker full view of an item's stock position in multiple warehouse locations when a shortage arises. The order taker can choose to order from a list of alternative items to back order the item or allow the item to be partially delivered. Orders can be created that support different delivery dates and ship-to addresses for each line item. A delivery function is further provided, allowing a shipping department to generate the necessary packing documentation for all goods shipped to a customer. Such information is inserted into delivery templates, stored in database 15.

Automatic receipts and invoices are generated and are saved as journal entries.

Similarly, credit memos may be generated automatically from templates, with the financial information either being manually entered, or filled automatically from information stored in database 15. Sales information, such as receipts, invoices and the like, may be displayed to the user on display 16 or printed.

The purchasing module 28 allows users to generate, save and edit purchase orders, and provides an integrated sub-system for ordering materials or services from vendors. These orders update the available quantity of the ordered items and inform the warehouse manager or the like of the expected delivery date. Users can split a single purchase order into multiple parts when, for example, items need to be shipped to multiple warehouses. The split or revisions are required so that different packing slips and delivery notes can be created for each shipment. Each line item within a purchase order or an account payable voucher can be shipped to, or specified as, a different warehouse location.

Users may also generate goods receipt purchase orders. This function allows users to receive a delivery at the warehouse or allocate deliveries to multiple warehouses. Goods receipts may be linked to a purchase order, and users can change the purchase order quantity versus the actual received quantity. Similarly, goods return documents may be generated, stored, displayed and/or printed. Such return documents are used when a vendor returns an item or items for repair or without credit.

When processing vendor invoices, the purchasing module 28 creates a journal entry, to be stored in database 15. Users can use this information to process subsequent payments to the vendor. Credit memos may also be generated and issued to vendors for returned merchandise. The required data can be imported from the original invoice, stored in database 15, as it is with any other sales and purchasing document. All sales and purchasing documents, which are stored in database 15, may be displayed on display 16 or printed. Users accessing database 15 may search by period, document number, or document type.

Software tools relating to business partners are incorporated into the purchasing module 28 and the sales module 26. All critical information on customers and vendors, such as address, preferences, sales employees, and credit terms, for example, is entered in the business partner sub-modules. Users can define an unlimited number of contact persons for each business partner, along with their phone numbers, e-mail addresses, and other important data. Users may also enter a customer contact or vendor name and send e-mail or internal network messages. All relevant associated data, such as customer sales reports and detailed balances, can be displayed on display 16. Interactions with customers, such as phone calls, meetings, and follow-up tasks, may be tracked and saved automatically in database 15 as journal entries. Users may also modify these entries to include special notes and attachments to activities, and further schedule next action items. System 10 further allows users to maintain a calendar, which graphically displays the activities for one or more users. The calendar also provides functionality for scheduling activities as well as modifying scheduled activities. The calendar can be configured to show only specified activities and users.

The inventory module 30 enables users to manage item master information (to be described in greater detail below) and maintain, edit and store serial and batch numbers, as well as price lists. Users also may define alternative items, perform inventory increase or decrease adjustments, revalue inventory costs based on current market values, and perform cycle counts. Control of item master data allows users to define production items, purchase items, or purchase non-inventory items, such as labor, travel, or fixed assets. Default information, such as purchasing vendor names, purchasing and selling units of measure and the like are stored in database 15, to be accessed for inventory purposes. Stocked items can be maintained and tracked in multiple warehouses and system 10 further supports different inventory valuation methods on a per item basis. Such methods include standard cost, moving average, and "first in, first out". Planning data is also maintained within item master data.

Serial numbers may be automatically generated based on predefined masks or methodologies. Serial numbers may also be manually created and assigned upon release of an item from inventory, or optionally on every transaction. A cross-reference table of vendor part numbers to inventory part numbers is further preferably maintained and stored in database 15. Vendor part numbers can be used on purchasing documents in lieu of inventory part numbers.

Different situations or market conditions may require changes of the valuation method for inventory. System 10 allows for the production of updated stock valuation method reports, where users can select items from a list and change the current valuation method to an alternative method. Further, inventory module 30 allows to record goods receipts and issues that are not directly related to a sales or purchasing document. Inventory module 30 may further be used to track stock transfers, where inventory is moved between warehouse locations, and to issue orders across the network for such a transfer. Through inventory module 30, users may enter opening balances for inventory items and also update warehouse data recorded in database 15. A cycle counting sub-system is further provided. In large warehouses, counting stock is often a continual process. This sub-system streamlines the process by identifying when each item in stock is due to be counted. Alerts and reports are produced to help ensure that items of different levels of importance are counted as frequently as required.

Further, users may make changes in existing inventory prices. This may be necessary when the current price of the material does not match the actual market price. In that case, the price is adjusted and a manual posting on the change is posted. Users may further define any number of price lists and link them with customers or vendors within database 15. In addition, they may create dynamic links between price lists, quickly and easily, updating the links automatically whenever the primary price list changes.

The human resources module 32 provides staff management capabilities, including employee details and contact information. Entry, display and modification of employee master data, stored in database 15, allows users to track important information about each employee, such as name, job title, skills, department, reporting manager, attendance information, salary, team membership, and address information.

The report module 34 enables users to create reports and initiate corrective actions immediately afterwards. Module 34 includes generation of accounting reports, enterprise reports, inventory reports, financial reports, and reports to aid decision-making. Users can export any report to existing, integrated software, such as Microsoft Excel®, for example. All modules may be accessed through a separate security module 48, which is selectively controlled to determine and control levels of access for information.

Fig. 4 illustrates the production of payroll reports using payroll sub-module 46, which is part of human resources module 32. Initial input occurs at 100, with the input including data related to monthly leave 102, employee payroll exceptions 104, allowances and deductions 106, loans 108, lateness and absences 110 and overtime 112. Termination or end of an employee's service is also incorporated at 114. Payroll calculation occurs at step 1 16.

If there is no change to an employee's allowances or deductions, then the flow moves from 136 to the calculation of allowances and deductions at 140, which is then fed to the payroll calculation at 1 16. If there is a change in allowances or deductions, then these changes must first be changed in memory 14 at step 138, before passing on to the payroll calculation at 116.

If a loan has been made to an employee, then the loan or advance payment is recorded at 146, and the employee's loan is either adjusted at 150 (with the adjustment decision being made at 148), or if there is no adjustment needed, the flow passes directly back to the payroll calculation at 116. Employee latenesses are entered at 110, and lateness deduction is taken at 152, with a further attendance deduction being made at 154. These deductions are calculated into a grand total at 156, which is fed into an overall posting at 166. The posting is then fed directly back to the payroll calculation at 116. Similarly, overtime hours are entered at 112, with the total number of normal work hours being recorded at 158 and the total number of overtime hours being recorded at 162. These are used to produce an overtime summary 160 and a calculation of monthly overtime at 164. These figures are posted at the general posting 166, which then flows to the overall payroll calculation at 116.

The payroll calculation 116 is used to generate a payroll voucher at 118. Any necessary indemnity calculations are performed at 120, and the payroll voucher data and the indemnity calculations are used to produce a journal voucher 142, which is then written into the general ledger at 144, which may be stored in memory 14 and/or displayed on display 16. The general ledger sub-module 36, which is part of financial module 22, will be described in detail below, with particular reference to Fig. 8.

The payroll calculation is posted at 122 and an employee pay slip is produced at 124.

The overall pay may be refused by the employer at 126, put on hold at 128, or approved at 130, which leads to the end of the process (step 132) and the generation of a final report 134, for storage in memory 14, and/or display on display 16.

Fig. 5 illustrates the accounts payable sub-module 40, which is part of financial module 22. Initial input occurs at step 200, where either invoices are registered at 202, or accounts payable advance payments are entered at 204. When invoices are registered at 202, they are then posted at 206, and a journal voucher is generated at 210 for recordation in the general ledger 208 (which may be stored in memory 14 and/or displayed on display 16). If an invoice needs settlement (the decision is made at step 212), then a debit/credit memo is generated at 214 and posted at 220, where another journal voucher is produced at 218 for recordation in the general ledger at 216. If another settlement is necessary, flow returns to the decision step at 212. If invoice settlement is not needed, then flow proceeds directly to the decision to cancel the invoice at step 228. The decision to cancel the invoice is made at step 228. The invoice is canceled at 222, which is then recorded on a journal voucher 224 for recordation in the general ledger at 226. If the invoice is not canceled, then the invoice is paid at 230, which is then recorded in another journal voucher at 224, and results in the end of the process (at step 238) and the production of the final report at 240.

If an accounts payable advanced payment is made at step 204, then the payment is posted at 232 and a journal voucher is produced at step 234 for recordation in the general ledger at 236. This ends the process at step 238 and the final report is produced at 240, for recordation in memory 14 and/or display on computer display 16.

Fig. 6 illustrates the accounts receivable sub-module 42, which is part of financial module 22. Initial input occurs at step 300, where either invoices are registered at 302, or accounts receivable advance payments are entered at 304. When invoices are registered at 302, they are then posted at 306, and a journal voucher is generated at 310 for recordation in the general ledger 308 (which may be stored in memory 14 and/or displayed on display 16). If an invoice needs settlement (the decision is made at step 312), then a debit or credit memo is generated at 314 and posted at 320. If another settlement is necessary, flow returns to the decision step at 312. If invoice settlement is not needed, then flow proceeds directly to posting at 320, where another journal voucher is produced at 318 for recordation in the general ledger at 308.

The decision to cancel the invoice is then made at step 328. The accounts receivable invoice is canceled at 322, which is then recorded in a journal voucher 324 for recordation in the general ledger at 326. If the invoice is not canceled, then the payment is received at 330, which is then recorded in another journal voucher at 324 for recordation in the general ledger at 326, and results in the end of the process (at step 338) and the production of the final report at 340.

If an accounts receivable advanced payment is made at step 304, then the payment is posted at 332 and a journal voucher is produced at step 334 for recordation in the general ledger at 336. This ends the process at step 338 and the final report is produced at 340, for recordation in memory 14 and/or display on computer display 16.

Fig. 7 illustrates budget entry and calculation in budget sub-module 38, which is part of financial module 22. Initial input occurs at step 400 and a budget template is provided for the user at 402. The budget template allows the user to enter data into selected fields. The budget is assigned at 404 and a first report is produced at 406 for recordation in memory 14 and/or display on computer display 16. The user may then selectively approve the budget at 410. If the user does not approve the budget, then the flow passes back to step 404 for alteration of the budget parameters. If the user does approve the budget at 410, a second report is generated at 408, and the user has the option of further enhancing the budget parameters at step 412. The budget may be enhanced at 414, with the user selectively increasing the budget by a selected amount at step 416. If the budget requires no enhancement or no further enhancement, then the user may choose whether a transfer of the budget is required. If no transfer is required, then the process ends at step 418. If a transfer is selected at step 413, then the budget transfer occurs at step 415, and the budget amount is selectively increased or decreased at step 417.

As discussed above, the production of journal entries results in recordation in the general ledger. The general ledger sub-module 36 is part of financial module 22. As shown in Fig. 8, journal voucher bonds are initially provided at step 500 and input at step 502. The vouchers may be input as journal vouchers at 504, receipt vouchers at 506 or payment vouchers at 508. The user may revise input voucher entries at 510 and if an error is detected at step 512, flow returns to the input of the vouchers. If there is no error, the voucher entries are posted at step 514, then an account balance is calculated at step 516, and this balance is transmitted to the budget sub-module 38 at step 518.

If one or more vouchers needs to be reversed then, at step 520, the flow passes to step 522 for reversal. If no reverse is necessary, then a decision is made at step 528 to close if the date falls in the last month of the year. If it is not the last month of the year, then closing occurs at step 524, and a new month is opened at step 526. If it is the last month of the year, then the account closes at step 530, and a new month is opened at step 532, followed by the opening of a new year at 534. The process then ends at step 536 and a report is produced at step 538. The yearly closing at step 530 results in the generation of a yearly closing journal voucher at 531, which is then recorded in the general ledger.

Fig. 9 illustrates data flow within the fixed asset module 24. Data is initially input at step 600, where it is recorded and processed in an item master 602, which may be part of database 15, or a separate, dedicated database stored within memory 14. Inventory software or a separate inventory cataloging system 604 may be part of item master 602, or may be separately accessed by item master 602.

At step 610, the user may perform depreciation calculations on any stored assets. Depreciation is posted at 614 for the production of a report at 612. A journal voucher 616 is also produced, for recordation in the general ledger at step 618. At step 620, the user determines whether any assets require sale or disposal. The assets may be sold at 622, resulting in the production of a journal voucher at 626 for recordation in the general ledger at 618. If the assets are being disposed of, disposal occurs at step 624, and up-to-date depreciation is calculated at step 628. If no assets require selling or disposal, the process ends at step 632.

The user may also choose to upgrade or update the assets at step 608. A journal voucher is then produced at step 630 and the process ends at step 632. The user may further choose to transfer assets at step 606, and then the process ends at step 632. It should be noted that the user may sell or dispose of the asset at any time without needing to post the depreciation prior to selling or disposal of the asset.

Fig. 10 illustrates the flow within inventory module 30. Initial input occurs at step 700. The user may store a new inventory entry at step 702 or adjust a unit of measurement at step 704. If the user stores an entry at 702, a journal voucher is generated at step 710 and recorded in the general ledger at step 712. The user enters whether a supplier brought an invoice at step 708. If an invoice exists, then the process ends at step 738 and a report is generated at step 740. If no invoice exists, then an invoice showing receipt of new inventory is generated at step 722, resulting in the generation of a journal voucher at 724 and recordation in the general ledger at step 726.

When a new entry is stored at 702, the user also may report material damage at 714, a return of stock at 716, or a transfer of stock at 718. These are all recorded in the general ledger at step 726, and the process ends at step 738. There may also be a separate storage issue, entered at 720, which may constitute an internal issue (entered at 728), an external issue (entered at 730) or new or changed assets (entered at 734). All of these entries are recorded in the general ledger at step 726. Available assets maybe extracted at step 734, for transfer to the fixed assets module 24 at step 736, resulting in the end of the process at step 738. If a unit of measure is to be adjusted at step 704, then price and/or quantity of recorded items is adjusted at step 706. It should be noted that, for each transaction, each inventory function that generates a journal voucher affects item quantity and unit prices within the store.

Fig. 11 illustrates the methodology of the human resources module 32. Initial input occurs at step 800, where initial information is passed to the filling of a government template at step 802, where government forms, such as tax forms and the like, are automatically filled with basic employee information. The user can then choose to enter the recruiting subsystem at 804, the archive sub-system at 828, the letter template at 832 or the leave subsystem at 842.

Within the recruiting sub-system, the user can decided between "regular" recruiting at 806 and immediate recruiting at 808. Within regular recruiting, the user may enter information and requirements for the manning of available positions at 810, and then form a "short list" of job candidates at 814. Candidate evaluations are entered at 819, and the entry of a final candidate selection occurs at 820. Interview scheduling may be input at 822, and further immediate recruiting may occur at 824. Recruiting information is then recorded in the employee master file at 826.

If the user decides on immediate recruiting at step 808, a job application is automatically generated and filled at 812, and a job offer is made and recorded at 816. The application is electronically confirmed at 818, and the recruiting information is recorded in the employee master file at 826. Following recordation in the master file at 826, the process ends at 850, and the user may be returned to the main system menu.

The archive sub-system 828 is used for the filing and storage of official human resources-related documents at 830. The system then ends at 850, once the documents have been recorded. Within the letter template 832, the user may enter information into previously generated forms, such as a car purchasing form 834, a multiple exit re-entry form 836, a form for opening a new account 838, or a passport release form 840. It should be understood that any desired form may be generated in this sub-system.

In the leave sub-system 842, requests for general leave may be recorded at 844, and special requests may also be recorded, such as requests for family tickets and visas at 846. At 848, an employee's leave balance is adjusted, and the process ends at 850.

Fig. 12 illustrates the method of using the sales module 26. Initial input occurs at step

900, with sales opportunities being entered at 902. The user may either go immediately to production of a sales order at 908, or may request generation of a quotation at 904, which may include further material supply quotations (906). Following production of a sales order at 908, order deliveries are scheduled and recorded at 910, and an invoice is produced at 912. The invoice is passed to accounts receivable at step 914, and then recorded as a general ledger entry at 916.

The sales opportunity may also be a customer follow-up, which leads to step 918. At step 920, the user may enter a change of status regarding present or future sales opportunities with the clients, and data flow passes back to step 902. The process ends at 922.

Fig. 13 illustrates the methodology of security module 48. Initial input occurs at 950, and from the end user list (952), the user may change a password at 954, copy a user access menu at 956, back up the system at 958, or assign a role for a position at 960. If the user choose to change his or her password at 954, then the decision of password expiration is made at step 962. If the password is not set to expire, then the password may be changed at the first user entry (step 964). If the password is set to expire, then the remaining days to expiration are calculated at step 966, and recorded in a generated report at 974, with the process ending at 976.

Both the copying of an access menu (step956) and the backing up of the system (step 958) are single step processes, with the processes ending at 976 once complete, and a report generated on the activity at 974. If the user is assigning a role for a position at 960, the system records whether assignment is being made by employee (step 968) or by position level (step 970). Assignment is made and flow passes back to the user access menu at 972.

Additionally, the system can be used as a career management system, with a career management module being coupled with human resources module 32. As shown in Fig. 14, a prospective employee submits an employment application at step 1000, which is input and stored in the database. Following selective, company-specific employment procedures, the prospective employee is nominated to a specific job at step 1002. Each step, such as the nomination, is recorded as a journal entry in the database. The system then checks the applicant against a set of employment requirements, stored in the database, at step 1004. For each job created in the database (at step 1006), the users input a list of particular necessary skills, such as education, certifications, languages, etc. (step 1008).

If the user passes the requirements check at step 1010, then a specific job is assigned to the user at step 1014. If the user does not pass at step 1010, then the user's application is transmitted to human resources for approval at step 1012. If approved at step 1016, then data flow returns to step 1014. If the application is not approved, then the application is saved as an archived application in the database at step 1018.

Once an employee has been assigned a job at step 1014, the system offers an annual appraisal of job performance at step 1024. A promotion or raise is determined at step 1022, with a comparison of the yearly appraisal being made at step 1020 against the job requirements set at step 1004. Based upon the appraisal at step 1024, the employee may be assigned further job training at step 1026, including classes (step 1038), requiring both attendance and the passing of assigned coursework at step 1040. If the employee passes, the employee's profile is updated at step 1042 and the employee's status is recorded as a journal entry in the database. As part of the yearly appraisal (step 1024), the employee's performance is based upon meeting set goals (step 1032), on the evaluation of the employee's supervisors (step 1030) and on an evaluation by the human resources department (step 1028).

Suggestions for the employee may be made by any of the above at step 1034, along with the assignment of further tasks and job duties at step 1036. These may include further coursework at step 1026. The training in step 1026 may be part of a training module, coupled with the human resources module. Fig. 16 illustrates a training module, which may be used at step 1026, or may be used as a stand-alone module, to be implemented at any process step or time.

In Fig. 16, initial input is made at step 1100. This includes a specific request for training at 1102 and identification of the particular training needed at step 1 104. Planning of particular training or coursework occurs at step 1108, and the human resources module provides input at 1106 in the identification of needed training at step 1104. Once the program has been prepared, organization of the course or courses occurs at 11 10, and trainees are selected and assigned to courses at step 1112. The trainees, or job candidates, are sorted at 1114, and attendance of courses occurs, and is recorded, at step 1116. A course may be canceled (or an attendee removed from the course) at step 1118, which may result in creation of a wait list for attendees at 1120. Normal coursework resumes at 1122, including an evaluation at 1124, resulting in generation of evaluation reports 1126, which may be stored as journal entries in the general ledger database. The process closes at 1128.

Further, a cash flow module may be coupled with financial module 22. As shown in Fig. 15, debtors' receipts, employee receipts and company returns checks 1050 may be recorded as receipt vouchers at step 1052, with review and auditing of the receipt vouchers occurring at step 1056. Approval occurs at step 1058. If the vouchers are not approved, they are checked for errors at step 1054. The approval is recorded as a journal entry at 1060, and then recorded in the general ledger module at step 1062. Once approved, bank deposit transactions occur at step 1064, and the transaction, along with any bank deposit slips (which may be generated at step 1066), is recorded as a journal entry at 1060, and then recorded in the general ledger module at step 1062. The nature of the transaction is entered at step 1070, including bank debit notes, bank credit notes, bank transfer notes and bank advice notes 1068.

Payment voucher information is also entered at step 1072, including input of voucher transactions from other modules at step 1078, and the printing of associated checks at step 1074. Approval and posting of the payment vouchers occurs at step 1080, at which point the printed checks are submitted at step 1076. This process is also recorded as a journal entry at 1060, and then recorded in the general ledger module at step 1062.

Bank statement and account reports and received and generated at 1084 and entered at step 1082. Any bank reconciliations at 1086 result in generation of reconciliation reports at step 1088. Upon monthly closing at 1090, closing reports are generated at step 1092, and any balances are re-evaluated at 1094, resulting in generation of a balance re-evaluation report at 1096. The process then ends at step 1098.

The above methodology allows a client who owns or operates a group of companies to operate all of the companies by buying one license of the above system, and then using a single database. Each company has its own secure data and transactions, with the automatic production of special reports that accumulate data from all companies' data summarized it into a single report according to user requirements. Any type of currency or exchange rate may be used, and an administrator of the above system has the ability to control the end user messages text, because all end user messages are saved on the system database. The administrator can control whether the end user message is a warning message only, or if a system transaction should be stopped when this cause occurs. Further, the administrator can control whether this message should be displayed to the end user as an alert message or at the last line of the screen. Thus, all the above cases can be controlled through the administrator by parameter settings in an "End User Messages" function. Additionally, upon user request, a historical file can be built for any system transaction that shows all types of Data Manipulation Language (DML) for that transaction, including display of DML date, time, terminal, user, and the old and the new values.

Fig. 18 illustrates the methodology of purchasing module 28. Initial input begins at step 1300 and at step 1302, a purchase request is formatted. If the user has sufficient information, a purchase order may be automatically filled and sent directly to the supplier of the goods to be purchased at step 1304. A report of this is automatically generated at step 1306, and the process ends at step 1324. If more information is required, such as initial price quotations, a request for quotation is prepared at step 1308, and the request for quotation is either physically printed or electronically formatted and completed at 1310. The request for quotation is sent to the supplier at step 1312 and the supplier delivers the quotation at step 1314. A selection may then be made from the supplier's goods and services at step 1316, based upon the quotation(s), and a purchase order is prepared at step 1318. The purchase order is delivered to the supplier at step 1320, and a report of the transaction is automatically generated at step 1322. The process then ends at step 1324.

The above system and method may be applied to a wide variety of industries and businesses, allowing for individually tailored and customized management in each field. Fig. 17 illustrates an intellectual property management example. Fig. 2 shows a general system for a general business, including sales and purchases. In the intellectual property example of Fig. 17, the "fixed assets" are replaced by a patent portfolio 1208, which may be managed in the same manner as tangible goods. Rather than "selling", invention intake module 1206 takes the place of sales module 26. Invention intake includes receipt of invention disclosures. Rather than "selling" goods, the intellectual property services are offered to clients in module 1206, including initial disclosure retrieval, which is then recorded in the database, and the offering of further legal services, such as patent application drafting, patent application prosecution, litigation matters, and the like. Rather than "purchasing" goods, the purchasing module 28 is replaced by an intellectual property transfer module 1200, where intellectual property may be purchased, licensed, assigned, or otherwise transferred between parties. A client module 1202 replaces human resources module 32, with management of clients taking the place of managing employees. Similarly, payroll module 46 is replaced by a module for handling client financial matters, such as intellectual property royalties, fees on intellectual property (such as maintenance fees, for example), and the like. The remaining architecture may remain the same, including security, financial records and the like.

The software may be embodied in a computer program product that includes a computer readable medium. As used herein, the term "computer readable medium" includes a hard disk, a floppy disk, a compact disk (CD), a DVD, a laser disk, or any physical medium readable by magnetic, optical, or other transducer for reading instructions recorded on the medium and converting the instructions into electronic signals that can be read by a computer processor when loaded into main memory, and executed by the processor to carry out the computer program code.

It is to be understood that the present invention is not limited to the embodiments described above, but encompasses any and all embodiments within the scope of the following claims.

Claims

1. A computerized method of managing business, comprising the steps of:

inputting data into a plurality of data sets, including a financial data set, a sales data set, a purchasing data set, an inventory data set and a human resources data set;

storing the plurality of data sets in a computer-readable memory;

calculating net financial data based upon the data stored in the plurality of data sets; generating at least one journal voucher including the calculated net financial data; recording the net financial data in a general ledger stored in the computer-readable memory;

selectively generating at least one report based upon the net financial data recorded in the general ledger; and

displaying the at least one report on a computer display.

2. The computerized method of managing business as recited in claim 1, wherein the inputting of data into the human resources data set includes the step of inputting payroll data.

3. The computerized method of managing business as recited in claim 2, wherein the step of inputting payroll data includes inputting at least one item of data selected from the group consisting of monthly leave data, employee payroll exceptions data, allowances and deductions data, loans data, lateness data, absence data, and overtime data.

4. The computerized method of managing business as recited in claim 3, further comprising the step of calculating a payroll report based upon the input monthly leave data, employee payroll exceptions data, allowances and deductions data, loans data, lateness data, absence data, and overtime data.

5. The computerized method of managing business as recited in claim 1, wherein the step of inputting data into the financial data set includes the step of inputting accounts payable data.

6. The computerized method of managing business as recited in claim 5, wherein the step of inputting data into the financial data set includes the step of inputting accounts receivable data.

7. The computerized method of managing business as recited in claim 1, wherein the step of inputting data into the financial data set includes the step of inputting budget data.

8. The computerized method of managing business as recited in claim 7, further comprising the step of providing a budget template.

9. The computerized method of managing business as recited in claim 8, further comprising the step of selectively approving a calculated budget.

10. The computerized method of managing business as recited in claim 1, wherein the step of inputting data into the financial data set includes the step of inputting fixed asset data.

11. The computerized method of managing business as recited in claim 10, further comprising the step of calculating asset depreciation.

12. The computerized method of managing business as recited in claim 11, wherein the step of inputting data into the inventory data set includes the step of inputting damaged inventory data.

13. The computerized method of managing business as recited in claim 12, wherein the step of inputting data into the inventory data set includes the step of inputting returned inventory data.

14. The computerized method of managing business as recited in claim 13, wherein the step of inputting data into the inventory data set includes the step of inputting transferred inventory data.

15. The computerized method of managing business as recited in claim 14, wherein the step of inputting data into the inventory data set includes the step of inputting fixed asset inventory data.

16. The computerized method of managing business as recited in claim 1, further comprising the step of establishing a database, the database being stored in said computer- readable memory.

17. The computerized method of managing business as recited in claim 16, wherein said financial data set, said sales data set, said purchasing data set, said inventory data set, and said human resources data set are stored in the database.

18. The computerized method of managing business as recited in claim 16, further comprising the step of accessing the database remotely.

19. A computer program product, comprising a medium readable by a computer processor, the medium having stored thereon a set of instructions for managing business, the instructions including:

(a) a first sequence of instructions which, when executed by the processor, causes said processor to input financial-based data and establish a financial data set;

(b) a second sequence of instructions which, when executed by the processor, causes said processor to input sales-based data and establish a sales data set; (c) a third sequence of instructions which, when executed by the processor, causes said processor to input purchasing-based data and establish a purchasing data set;

(d) a fourth sequence of instructions which, when executed by the processor, causes said processor to input inventory data and establish an inventory data set;

(e) a fifth sequence of instructions which, when executed by the processor, causes said processor to input human resources-based data and establish a human resources data set;

(f) a sixth sequence of instructions which, when executed by the processor, causes said processor to store said financial data set, said sales data set, said purchasing data set, said inventory data set, and said human resources data set in a database;

(g) a seventh sequence of instructions which, when executed by the processor, causes said processor to generate at least one journal voucher including calculated net financial data based upon the financial data set, the sales data set, the purchasing data set, the inventory data set and the human resources data set;

(h) an eighth sequence of instructions which, when executed by the processor, causes said processor to record the net financial data in a general ledger stored in the database;

(i) a ninth sequence of instructions which, when executed by the processor, causes said processor to generate at least one report based upon the net financial data recorded in the general ledger; and

(j) a tenth sequence of instructions which, when executed by the processor, causes said processor to display the at least one report on a computer display.

20. A computer system for managing business, comprising:

a computer having a processor, an area of main memory for executing program code under the direction of the processor, and a disk storage device for storing data and program code;

data input means for entering data input cognizable by the processor;

a database stored on the disk storage device, the database having a plurality of data sets for organizing and storing data, the data sets including a financial data set, a sales data set, a purchasing data set, an inventory data set and a human resources data set;

a software program code stored in the disk storage device and executing in main memory under the direction of the processor, the software program including:

means for calculating net financial data based upon data stored in the financial data set, the sales data set, the purchasing data set, the inventory data set and the human resources data set; means for generating at least one journal voucher including the calculated net financial data;

means for recording the net financial data in a general ledger stored on the disk storage device; and

means for outputting at least one report based upon the net financial data recorded in the general ledger.