Enterprise resource planning system and method for managing route transactions

A computer-implemented method of managing route transactions in an enterprise resource planning (ERP) system is provided. The method includes calling a route form from an ERP server. The route form graphically illustrates at least one of a plurality of related tables corresponding to route processes, as well as an approval control input element to approve of a route transaction corresponding to the route processes. Upon receiving a user input at the approval control input element of the route form, the route transaction can be approved. Then, the method includes automatically implementing route transaction executing steps to each of the plurality of related route tables.

CROSS-REFERENCE TO RELATED APPLICATIONS

Reference is hereby made to the following co-pending and commonly assigned patent applications: U.S. application Ser. No. 11/127,464, filed May 12, 2005, entitled “ENTERPRISE RESOURCE PLANNING SYSTEM AND METHOD FOR MANAGING BILL OF MATERIAL TRANSACTIONS”; U.S. application Ser. No. 11/127,595, filed May 12, 2005, entitled “METHOD AND SYSTEM FOR ENABLING AN ELECTRONIC SIGNATURE APPROVAL PROCESS” and U.S. application Ser. No. 11/127,518, filed May 12, 2005, entitled METHOD AND SYSTEM FOR PERFORMING AN ELECTRONIC SIGNATURE APPROVAL PROCESS”.

BACKGROUND OF THE INVENTION

The present invention generally relates to computerized Enterprise Resource Planning (ERP) systems. More particularly, the present invention relates to a route approval process in an ERP system.

Enterprise resource planning (or ERP) is a phrase used to describe a broad set of activities supported by multi-module application software that helps a manufacturer or other business manage the important parts of its business. Computerized ERP systems typically integrate and automate various activity modules internal to a business or organization, such as planning, manufacturing, production, distribution, inventory, sales, shipping, order tracking, invoicing, accounting, customer service, marketing and human resource management. Not all ERP systems integrate all of these activities, but the trend is to integrate more and more business activities. Often, an ERP system uses or is integrated with a relational database system. An example of an ERP system is Microsoft® Business Solutions-Axapta®.

Each activity module managed by an ERP system includes transactions or documents. Transactions or documents include information or data that describes processes that occur internal to a business or organization. Many businesses, such as those in the pharmaceutical or biomedical industries, have certain processes that are critical processes and need to be approved before they can be implemented as an activity of the business. Such critical processes are highly regulated by the Food and Drug Administration (FDA) or other agencies. These agencies require that implementation of new processes, as well as modifications to processes as well as deletions of processes, are signed off by a representative or multiple authorized representatives of the pharmaceutical, biomedical or other life science business. Examples of such critical processes in the pharmaceutical or biomedical industries include bill of materials (BOM) and routes.

A “BOM” is a list of materials utilized in the manufacture of a specific product, essentially a recipe for production of an item. A “route” is a description of the process, or order in which things must be done, when producing an item using a BOM. When handling a BOM or a route in these heavily regulated industries, there are numerous aspects to manage. For example, when developing a new BOM or route, unintentional use must be prevented. Then, when the development of the BOM or route is finished, it must be released for general use. However, even when released for general use, the BOM or route should be locked to prevent unintentional changes. Further, a verification process can be required in some instances to ensure that the person approving the BOM or route has authority to do so. Also, records of attempted changes to the BOM or route may need to be kept.

Generally, information related to a critical process, such as a BOM or route, is stored in the ERP system in the form of a transaction or document. To approve such a process or a modification to a process, the document is printed out and manually signed and dated by an individual or multiple individuals who are allowed to make such approvals. The document is then stored in a safe place that is readily available such that copies can be made of the approved document. For example, a working copy of the originally signed document can be made for those needing to complete a specific job shown or discussed in the document. After the job is complete, the working copy is destroyed such that only one original exists.

This manual approval process ensures a history or audit trail that describes the lifecycle of data by storing old versions of an approved document as well as storing modified versions of a document. However, such a paper trail is difficult to manage. Original documents can easily become misplaced. Thus, to ensure that the history of critical data is fully documented, keeping and storing additional copies of the original documents is practiced.

While ERP systems are widely used in business to manage the various functions of a company, there has been a need in some environments to employ separate software systems for BOM and route management. Some available BOM and route software systems provide electronic signature controlled management of BOMs and routes. However, using BOM or route software systems, separate from an ERP system which manages a broader scope of business activities, can be problematic and undesirable. It is desirable that BOM and route data be available for use in other modules of the ERP system, but integrating the separate BOM and route systems with the ERP system can require extensive programming.

SUMMARY OF THE INVENTION

A computer-implemented method of managing route transactions in an enterprise resource planning (ERP) system is provided. The method includes calling a Route form from an ERP server. The Route form graphically illustrates at least one of a plurality of related tables corresponding to route processes, as well as an approval control input element to approve of a route transaction corresponding to the route processes. Upon receiving a user input at the approval control input element of the Route form, an approval form can be called from the ERP server. The approval form verifies a user identification to confirm authority of the user to approve of the route transaction. An approved route can be locked for editing, and it can be possible to prevent unapproval of an approved route. The method also includes automatically implementing route transaction executing steps to each of the plurality of related route tables.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

The present invention is described in the context of an Enterprise Resource Planning (ERP) system. The ERP system of the present invention is configured to implement a bill of material (BOM) or route approval process upon a person attempting to create, modify or release the BOM or route managed by the ERP. Before describing aspects of the present invention, however, it is useful to describe suitable computing environments that can incorporate and benefit from these aspects.

The invention may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communication network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices. Tasks performed by the programs and modules are described below and with the aid of figures. Those skilled in the art can implement the description and figures provided herein as processor executable instructions, which can be written on any form of a computer readable medium.

Computer110typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer110and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computer110. Communication media typically embodies computer readable instructions, data structures, or program modules. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.

FIG. 2illustrates a block diagram of an ERP system200in accordance with a first embodiment of the present invention. As will be described, ERP system200and its corresponding methods implement electronic signature approval in a manner which prevents unintentional use of a new BOM or route during development, allows a new BOM or route to be released for general use when development has been completed, and locks the BOM or route to prevent unintentional changes. The ERP system200and corresponding methods also provide verification of the authority of a person approving a BOM or route, while logging for later viewing the identity of the person approving the BOM or route. The system200also tracks unauthorized BOM or route approval attempts.

FIG. 10illustrates a block diagram of an ERP system700in accordance with a second embodiment of the present invention. ERP system700does not require electronic signature or logging to prevent unintentional use of a new BOM or route during development, to allow a new BOM or route to be released for general use when development has been completed, and to lock the BOM or route to prevent unintentional changes. ERP system700shown inFIG. 10is described below following the discussion of ERP system200.

The ERP systems200and700of the present invention integrate a large number of business functions, and include BOM and route manufacturing control. The ERP systems are configured to implement both BOM and route approval processes using one or more of the techniques as will be described. These processes are described primarily with reference to BOM approval for illustrative purposes. However, these processes apply equally to route approval. Illustrated forms, and disclosed processes, are described for discussion purposes in the context of either BOMs or routes. However, these forms and processes are generally applicable in concept to both BOMs and routes. Therefore, any depiction or description specific to a BOM or to a route is considered fully supportive of both BOM and route approval processes. One of skill in the art will recognize that BOM forms and tables, and route forms and tables, can be modified accordingly from those disclosed to support the other type of process.

Referring again toFIG. 2, ERP system200includes ERP system server205having software modules or components configured to implement methods of BOM and/or route management which may be useful in the pharmaceutical, biomedical, or other heavily regulated life sciences industries for satisfying regulatory requirements regarding BOMs and/or routes. As such, ERP system200and its corresponding methods implement electronic signature approval in a manner which prevent unintentional use of a new BOM or route during development, allow a new BOM or route to be released for general use when development has been completed, and lock the BOM or route to prevent unintentional changes. A discussion of ERP system200follows the descriptions ofFIGS. 3-9.

Referring now toFIGS. 3 and 4, inFIG. 3a screenshot depicting a BOM form300and a BOM line form325is provided. InFIG. 4, a screenshot depicting an item number form350and another embodiment of a BOM line form375is provided. These forms reside on ERP server200and are accessible by an authorized user of ERP system200when developing, releasing, changing, etc. a BOM (or equivalently a route). A form in the context of the present invention is a window, a dialog, a page, or other graphical user interface (GUI) for managing a transaction such as a BOM or a route. In addition to a GUI, forms include form logic which implement the functions associated with the form.

On Overview tab301of BOM form300, a table302referred to here as “BOMTable” is shown. BOMTable302contains BOM information such as the BOM number in field306, the BOM name in field308, the identity of the person approving the listed BOM(s) in field310, and the approval status in field312. As shown on Overview tab326of BOM line form325, a second table327is illustrated. This table is referred to as the “BOM”. BOM327contains all BOM-lines for a particular BOM (e.g., Bodywork, Door, etc in the illustrated example). The BOM line dictates quantities and other information for each item number/name.

InFIG. 4, Overview tab351of item number form350is shown to include a table referred to here as Item table352. Item table352lists various items (individual items, BOMs containing a plurality of items, etc) which are tracked by ERP system200. In both of the different BOM line forms325and375shown inFIGS. 3 and 4, yet another type of table is illustrated. This table, referred to here as BOMVersion315, links Item table352and BOMTable302. It contains information about BOM number306, item number320, “from date”317, “to date”319, etc. From date317and to date319dictate the valid dates for a particular BOM. The exact information depicted in BOMVersion315can vary as desired, as can be seen by comparing the BOMVersion315table instances shown inFIGS. 3 and 4, which differ for the particular uses. Also illustrated in BOM line form375is a repeat of the table referred to as BOM327.

The grid in BOMTable302of BOM form300illustrates a list of BOMs. A BOM, for example BOM3shown in BOMTable302, contains some items used to produce the finished product or item (e.g., Bodywork, Door, Engine, and Wheels listed in the example table BOM327). The BOM (e.g., BOM3) in itself cannot be used, it must be linked to an item that can use it. The grid in BOMVersion315illustrates the list of items that can use the selected BOM in BOMTable307. In the illustrated example, there are two items using the same BOM (New Car and Custom Car shown in BOMVersion315each use BOM3). A more common scenario is one Item with many BOMs attached. This scenario is common when keeping track of older versions of the same item. In this case BOM3AND BOM4are both linked to the Item “New Car”. Given these different scenarios where multiple BOMs are used with an item, or where multiple items use a single BOM, a method of tracking approvals of BOMs or BOMVersions for these scenarios is provided.

In the ERP system200, BOM form300shown inFIG. 3also includes an approval button340. When clicking on or otherwise selecting this user interface element, an approval prompt form400is pulled up from ERP server205. A screenshot of approval prompt form400is provided inFIG. 5in accordance with an example embodiment.

Approval prompt form400includes electronic signature form404used for requesting an electronic signature in accordance with an embodiment of the present invention. Electronic signature form404solicits an approver's username and password to approve modifications to a transaction. InFIG. 5, the transaction, which is to be approved, is indicated in process name block406. In the example illustrated inFIG. 5, an electronic signature is requested for a BOM version approval transaction. However, as will be described further below, a similar approval form can be used for a route version approval transaction in other embodiments. Such an embodiment of approval prompt form400is shown inFIG. 8.

Referring back toFIG. 5, at username field408, an approver is asked to enter a valid username or identification number, for example an employee code or a clearance code. The approver's username or ID can be selectable from a plurality of usernames using a drop down menu, or the approver's username or ID can also be keyed into username field408. At password field410, the approver is asked to enter a valid password. Electronic signature form404also includes an information block412. Information block412provides an alert indicating that by electronically signing the document, the approver understands that the electronic signature is as legally binding as the approver's handwritten signature. After the approver has entered their username and password, the approver selects the okay UI control item414such that ERP system200will begin processing the approver's information.

In accordance with embodiments of the present invention, when applying a valid username and password, the multiple above-described tables are simultaneously affected, without repeating the approval process for each of these tables. For example, the tables can be locked from further modification, released for general use, etc. Thus, signing a BOM not only affects the BOMTable307where approval is initiated, but it also affects the BOM lines in BOM327, as well as the table referred to as BOMVersion315. At the same time, a record is generated in a signature log450, identifying that a BOM has been approved, by whom, date and time. Shown inFIG. 6is a screenshot of one example embodiment of signature log450. Signature log450include multiple fields which allow approval information to be tracked, including successful and failed BOM approval attempts. For example, machine name field452can be included to record the particular computer from which an approval attempt was made. Field454indicates the identification number or code of the person who was logged into the particular computer when the approval attempt was made. Fields456and458are included to record the identification number or code of the person who made the approval attempt, and the name of the person who made the approval attempt, which may be different from the person logged into the particular computer. Fields460and462record the date and time of the attempted approval, while field464records a description of the transaction which was being approved (e.g., BOM approval, BOM version approval, route approval, route version approval, etc). Finally, field466records unique identification numbers for the signatures used to authorize the approval. In the illustrated example, cells in field466which lack a signature ID represent failed approval attempts.

As described above, equivalent forms corresponding to route management are used in the above-described process when managing route approval. For example, a screen shot of one such Route form600is included inFIG. 7. Route form600includes RouteTable602, which is similar in purpose to BOMTable302shown inFIG. 3. RouteTable602in this example includes two routes, named respectively Route2and NewRoute. As was the case with BOM form300, Route form600includes an approve button640. Like approve button340, when clicking on or otherwise selecting this user interface element, an approval prompt form400is pulled up from ERP server205. As mentioned above, a screenshot of approval prompt form400for the Route version approval process is provided inFIG. 8in accordance with an example embodiment. As a further example of the similarities between the BOM and route approval processes,FIG. 9includes a screenshot of a Route Number form650similar to item number form350. Form650includes a table, Route627, which is similar in purpose to the table BOM327. A route equivalent to the table BOMVersion315is also included in ERP system200. This table is referred to as RouteVersion615. In the same manner as described above, signing a route affects not only the table where the route is initiated, but it affects all three of these tables (Route, RouteTable and RouteVersion) in the same fashion as described above with reference to the BOM equivalents. In both cases, the present invention applies also to related tables having functions similar to these three table examples, regardless of the particular name used to designate the related tables. In this description and in the claims, these table types should be understood to represent the table functions as well, and the invention is not limited to the particular table names.

Referring back toFIG. 2, the above forms, methods and components are shown as being implemented in software programs, modules or components on ERP system server205. InFIG. 2, the various BOMs or routes stored on server205are illustrated at block210. The BOM/route forms300/600described above are used to initiate the approval process by calling approval prompt form400. Approval prompt form400operates as described above, but can use an electronic signature module220to perform the actual verification logic. As described above, all BOM/route transaction approval requests are logged in signature log450. This functionality can be used to satisfy various regulatory requirements regarding tracking of changes to BOMs and routes.

Referring now toFIG. 10, shown is a second embodiment of an ERP system which does not require electronic signature, but can be used in conjunction with electronic signature if desired. Since electronic signature is not required in system700, electronic signature module220and signature log450are omitted in the illustration. Generally, ERP system700can use the same forms as described above with reference to ERP system200, but certain forms may not be necessary. For example, Approve version form400and the Electronic signature log form are not used in some embodiments. The other forms function substantially as described above, with the exception of the approval process.

In the ERP system700, BOM form300shown inFIG. 3still includes an approval button340. When clicking on or otherwise selecting this user interface element, the BOM will be approved, in many embodiments without electronic signature and password verification. To control BOM (or route) editing, and/or to control removal of approval of a BOM (or route), a module or form800is included in system700.

FIG. 11is a screenshot illustrating form800which provides control over editing and removal of approval of a BOM (or alternatively a route). In one example embodiment, this form is a tab801of an Inventory parameters form. This form illustrates three new parameters linked to a BOM. The first, “Mandatory quantity and dates”, is controlled by GUI input element805, which is in the illustrated embodiment a check box. When input element805is checked (or otherwise selected for other implementations), this causes ERP system700to force the user to not leave the “quantity”, “from-date” and “to-date” fields blank.

The second and third new parameters provided on form800are “Block removal of approval” and “Block editing”, controlled by GUI input elements810and815, respectively. When input element810is selected, ERP system700will prevent any user from intentional or unintentional removal of a BOM (or alternatively a route) approval. When input element815is selected, ERP system700will prevent all users from editing a any approved BOM. Thus, BOM or route control is achieved without the requirement of electronic signature. Even though electronic signature is not required with form800, in other embodiments, electronic signature is combined with the BOM or route control provided using form800.