Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q10/00—Administration; Management
  • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
  • G06Q10/087—Inventory or stock management, e.g. order filling, procurement or balancing against orders

Definitions

• the present invention is a software system for procurement of operating resources and, more particularly, is a software system that automates the cycle of operating resource acquisition.
• ORM operations resource management
• Operating resource management replaces the traditional, fragmented methods of purchasing operating resources.
• new technology in one embodiment, namely intranets, extranets and Java TM — operating resource management supersedes decades of inefficiency with a consolidated corporate electronic commerce system, to fully capture economies of scale and leverage supplier relationships.
• the operating resource management system of the present invention provides at least three key benefits:
• Figure 1 shows the engineering architecture of an embodiment of the invention.
• Figure 2 shows the extensibility architecture of an embodiment of the invention.
• Figure 3 shows the procurement process flow of an embodiment of the invention.
• Figure 4 shows the product feature description of an embodiment of the invention.
• Figure 5 shows the user environment features of an embodiment of the invention.
• Figure 6 shows the system environment features of an embodiment of the invention.
• Figure 7 shows the business modules included in an embodiment of the invention.
• Figure 8 shows the system adapters of an embodiment of the invention.
• Figure 9 shows the installation and implementation comprehended in an
• the operating resource management system in accordance with the invention is a suite of software modules that automates the purchasing of goods and services within a corporation.
• some of the software modules that automates the purchasing of goods and services within a corporation.
• modules operate on a server computer of a network and others of the modules operate with the system of the present invention, a company can reduce the cost of transactions and increase overall productivity, with direct benefit to the bottom line.
• Walk-up User Interface on Any "Desktop” in the Company The user interface makes the product accessible to employees with little or no training, helping and guiding the employee through the requisitioning process. Use of the system need not be limited to a select purchasing group.
• ERPs enterprise data sources
• HRMSs Human Resource Management Systems
• Email systems and
• module is an Enterprise Commerce Server 102, which includes Intranet application server software, preferably written in Java.
• Intranet application server software preferably written in Java.
• a set of associated client- side software applications are also preferably written in Java.
• the Java client software 112 preferably runs in a Web browser (or, alternatively, is accessible via the web browser), on every desktop (shown in Fig. 1 as "Mac” , "Win95” ,
• the Java server software 102 preferably runs on a single
• Supplementing the Enterprise Commerce Server 102 are a number of
• Adapters 122 which integrate the system 100 into legacy enterprise data sources such as ERPs, HRMSs, E-mail systems and directory services.
• the system design is modular, allowing for any number of adapters to be plugged in without requiring revisions to the Enterprise Commerce Server software 102. In practice, the system in accordance with the invention is easy to use.
• the system is accessible both to infrequent users, people who buy something only once or twice a year, and frequent users, purchasing agents, administrators, and others who will use the system nearly daily.
• Figure 2 is a system diagram that shows generally how functionality (particularly functionality that can be extracted for a particular implementation) is apportioned in one embodiment of the system.
• Reference numeral 202 designates the requisition wizard module.
• Figure 3 is a flowchart that shows how a requisition is processed in a
• numeral 302 designates process steps associated with creating a requisition.
• Figure 4 is a top-level "product feature" description of an embodiment of the invention, while Figures 5 to 9 are diagrams that show the product features at a more detailed level. As can be seen from Figure 5, the wizard software is
• the wizard 202, 302 "walks" an employee through a number of questions to guide him through the process of making a purchase. For example: ⁇ What do you want to buy today?
• the wizard 202, 302 offers several ways to find the answer, always encouraging
• the system supports such on-line catalogs, but does not itself include
• the wizard prompt the employee to type in the name of a supplier and part explicitly (310). Entering such ad-hoc items, items that are not in the list of approved items, will typically trigger new
• approval rules For example, the approval rules of many companies will cause the Purchasing Department to be put into the approval loop at this point, to require a Purchasing Agent to decide whether to approve the new item. Because ad-hoc entry usually involves additional overhead, the wizard guides the employee through the process in such a way as to avoid ad-hoc entry whenever possible.
• the accounting structure typically varies from company to company, be it Division, Department, Account, or Project.
• wizard can be configured to display and ask for different accounting fields for each company, helping to ensure that the employee will always be presented with
• the wizard continues in this vein, asking questions and gathering other data about payment, billing, shipping, and the like. Throughout the process, the emphasis is on browsing and selecting, rather than typing, on channeling the
• the Organizer 504 ( Figure 5).
• the Organizer 504 software provides a folders-style view of existing requisitions
• approval software (approval engine 110 in
• FIG. 1 step 322 in Figure 3; approval flow software 602 of the system environment 404, in Figure 6) inspects the approval rules of the company, decides who needs to approve the request, and notifies the first required approvers, preferably by e-mail, that there is a requisition waiting for their
• the e-mail notification message includes a URL hyperlink that points the approver directly to the Organizer software 504 via his
• the browser to display the requisitions waiting for this person's approval.
• the app rover can approve or deny, and make comments, asking for more information
• notification software 120 sends an e-mail message notifying the requester and any other interested parties.
• the system uses notification e-mails throughout the approval process to keep users informed about the current state of a requisition.
• Requesters can also use the Organizer software 504 to check the status of a request at any time, to keep apprised who has or has not approved it, when it has been fully approved,
• supplier interface software 330 communicates with the suppliers to give them the order.
• the system may
• the pieces of the system used to transfer orders for fulfillment are known as the ordering modules 130 ( Figure 1) (see also, Fig. 7).
• the system may communicate orders to the supplier via
• the system includes a user interface for acknowledging receipt, which
• a Purchasing Agent will typically be involved when someone tries to buy an item from an unapproved supplier or when someone specifies an unusual ship-to address.
• the Purchasing Department via Administrative Tools software 506 (Fig. 5), defines which products and suppliers are "approved”.
• the Purchasing Department via Administrative Tools software 506 (Fig. 5), defines which products and suppliers are "approved”.
• the Administrative Tools software 506 provides Purchasing Agents with the ability to add or remove items from the Product Information Database, or remove items when a relationship with a supplier changes or an item is otherwise obsolete. Another piece of the user environment 500 of the system is Reports and
• Graphs software 508 (Fig. 5), which allows a company to summarize, group, and understand its purchasing history.
• the system preferably provides software to generate one collection of predefined reports that can be run at any time, giving purchasing agents and system administrators information they can use to refine their buying process and maximize the gain from automation. This information can be a valuable tool for gaining understanding and using that understanding to make improvements, such as modifying the approval processes or switching suppliers or updating the history of purchases to encourage different buying patterns by end-users in the future.
• the system environment 404 is the "back-end", the parts of the system
• one embodiment of the system is designed to allow companies to customize the set of data fields, recognizing that every company has a slightly different set of information that must be kept.
• Approval rules are the conditions that a company uses to decide which approvers are required for a particular requisition.
• the system preferably provides a mechanism for describing the approval rules that is flexible enough to model the existing process at any company. Every company will have its own set of rules, although there are often basic similarities, and many rules can be copied from simple examples. For example, an approval rule may be expressed
• conditional expressions such as "If the amount of this purchase is over $25,000 and it is for software, then the Information Systems department must approve the purchase. "
• approval rules can be based on any field in a requisition, including the fields that are added during the implementation process. So, in addition to standard approvals based on requisition or line item amounts, for example, the Facilities
• Manager might need to approve any furniture purchase, or the IS department might have to approve any computer system purchase.
• a particular role can be designated in an approval rule as an approver.
• An example role is the "CFO" role. At any given time, this role is played by a single individual in the company, but if there is a new CFO hired, then all the requisitions that are awaiting approval by the CFO can be approved by the new CFO when he comes on board, without any system maintenance.
• CFO CFO
• Roles can also describe a group of people. For example, there is the role of Purchasing Agent. There might be any number of Purchasing Agents in the company, but if the role Purchasing Agent is assigned to a requisition, then all individuals designated by the Purchasing Agent role see it for their approval. In one embodiment, if any one of them approves it, the requisition is approved for that role.
• Adapters 122 (Fig. 1) and 800 (Fig. 8) are software modules that link the system to the rest of the enterprise.
• the system obtains and stores all data through an adapter layer that integrates the system with existing services, using data that already exists in those legacy systems. This assists in avoiding duplication of information within the enterprise. If an adapter for particular data does not exist, then the system will store the information internally, but if the
• Significant adapters are adapters 804 to the ERP system in the company. These adapters may be customized to interface with each ERP (e.g. Oracle 10.4, 10.5, 10.6, SAP, Baan, D&B, PeopleSoft, etc.).
• the ERP adapters can obtain simple information from the ERP like units of measure, accounting information, etc. , as well as item templates, supplier information, approval matrices, and other relatively static information. They are also capable of storing the entire approved ERP (e.g. Oracle 10.4, 10.5, 10.6, SAP, Baan, D&B, PeopleSoft, etc.).
• the ERP adapters can obtain simple information from the ERP like units of measure, accounting information, etc. , as well as item templates,
• an HRMS adapter 806 (e.g. , to Peoplesoft, Version 5.0) is provided.
• An intrinsic field is a field that the system expects to find.
• An extrinsic field is an additional custom field, typically added during installation. There can be any number of extrinsic fields, depending on what a particular company desires. The system will store and display the information in these fields, but in a preferred embodiment, will not depend on having the information there. This document contains a number of examples of extrinsic fields, to illustrate how they can be used.
• the user interface for creating requisitions should be appropriate for both novice users — people who may use the system only once or twice a year — and expert users, who may use the system almost daily.
• the system allows users to create new requisitions in at least the following ways:
• a requisition can contain any number of individual line items that the employee would like to order. In one embodiment, there are some parts of a requisition that are shared among all line items, and others that are specific to individual line items. To initialize the information that applies to the entire requisition, the system will:
• the format of the numbers can include a prefix string, defined as part of the company configuration.
• d. Provide a way for one employee to prepare a requisition and submit it for someone else. That is, allow the creator and submitter to be different people. If the requester and the submitter are different, then the standard approval rules will put the requester as the first approver.
• holding is a company-wide feature, and can be turned off in the system profile for an entire company, if that company does not choose to allow the hold functionality.
• Table 1 summarizes the fields of a requisition record. Table 1 : Fields of Requisition
• the employee can add any number of products and services to it, as line items of the requisition
• the system guides employees toward choosing items from approved sources, rather than asking them to type in information manually: the interface emphasizes copying and selecting and deemphasizes typing.
• the system provides the following ways for an employee to create a line item in a requisition. a. By searching or browsing through a Product Information
• the Product Information Database for a company is the collection of all items that have been approved for purchase.
• the user may navigate the tree hierarchically, say by navigating through choices like Office Supplies, Computer Peripherals, Industrial Equipment, etc. and then from Computer Peripherals through Network Adapter, Disk Drive,
• the user is also able to search the Product Information Database with a "contains" search on the following fields: Item Description, Supplier Part Id,
• a Favorites list is a "flat" list of up to 25 items that the employee has chosen and marked as Favorites. c.
• a Favorites list is a "flat" list of up to 25 items that the employee has chosen and marked as Favorites.
• the employee is able to modify any of the information about that line item, as appropriate Quickpicks are provided for all fields to maximize accuracy
• the employee is able to: a Specify the quantity to be ordered b Specify the ship-to and deliver-to addresses c Modify the carrier or carrier method, if the defaults from the supplier are not appropriate. For example, the employee might want to ask for something to be shipped faster than the supplier's usual practice.
• d Specify a need-by date, to inform the supplier of the date by which the item needs to arrive in order to be useful.
• Any employee who handles a requisition can add commentary or attach documents to the requisition, helping everyone who sees it to better understand the requisition.
• the commenting mechanism a. Allows users to add textual comments to any requisition or line item, using "threading" to maintain context. b. Allows users to specify the audience for a comment, which can be any of Approvers, Requesters, Suppliers, Purchasing, or All. Comments are visible only to the specified audience. c. Allows users to attach electronic documents to comments. To ensure platform independence, this feature is preferably implemented using a browser's mailing facility. If employees can send attachments from their mailer, then they can attach documents to a requisition.
• a. Find all mandatory fields (as distinguished from optional ones), and ensure that they have values. If there are any missing values, then the requisition is returned to the user for more editing.
• b. For each field that has a value, verify the data in that field to ensure that values are valid for the field involved as well as validating that the account combinations (e.g. Account, department, etc.) are valid. If there are
• f. Determine the approval path for this requisition, using the approval rules defined in the business rules for the company, and allow the employee to preview the approval path. Allow the employee to either confirm the submission, or cancel it and return to editing the requisition.
• the user interface software for categorizing and classifying requisitions is known as the Organizer 504 ( Figure 5). Approvers use the Organizer software
• the system checks the approval rules of the company, decides which users need to approve the request, and in what order, and then notifies the first approver that there is a requisition waiting for attention. Each approver sees new requisitions in a folder of incoming requisitions, and will need to take action on the requisition to move it to a different folder.
• the system Whenever an approver acts on a requisition, the system timestamps the requisition with the name of the approver and the time of the action.
• the approver can take any of the following actions on the requisition:
• a Purchasing Agent can modify any field of a requisition; other approvers can modify only a limited set of fields in the requisition.
• the definition of which fields approvers can modify is part of the company's configuration of the data fields and is typically set up during installation.
• the system When an approver modifies any field of a requisition, the system recalculates the required approvals and invalidates any existing approvals for that line item (if it was a line item that changed) or for the entire requisition (if the requisition itself was changed). Modifying a field can thus trigger reapprovals from users who have already approved the requisition, or trigger the addition of new approvers into the chain, depending on the approval rules.
• this approver is a watcher
• Watchers are bystanders: they see the requisition but their
• Watchers can take any of the following actions on the requisition: ⁇ Add an additional approver to the approval chain, either before or after this approval.
• the system maintains the notion of chain of command derived from the "immediate supervisor" information in each employee's personal profile.
• the system allows certain authorized approvers to approve in the place of another approver: a.
• the system allows approvers to get a list of the requisitions that are waiting for approval from a lower-level approver (as defined by the business rules) and approve them directly.
• a high-level approver can explicitly approve in the place of any lower-level approver if the two approvers are in the same chain of command.
• the Organizer helps employees organize groups of requisitions. It allows employees to: a. Sort the requisitions by any of the fields that are displayed in the outline view. That is, if there is a column header for a field, then the employee can sort on that field. b. Filter the requisitions by any of the fields that are displayed in the outline view. That is, if there is a column header for a field, then the
• c View the details of any requisition, including all line items, approvals, and comments.
• d Put the results of a search into a folder. For example, a purchasing agent might wish to examine all outstanding requisitions for items from a particular supplier.
• An employee's personal profile is described in a configuration file that sets values for a user of the system. There are two kinds of information in a
• Human Resources data fields are preferably initialized from the HRMS adapter, if there is one at the site, and are also updated regularly from the HRMS adapter.
• the specific data fields are created and maintained entirely within the system.
• the system a Allows employees to view and edit the specified fields of their own personal profiles, in a form consistent with the rest of the UI. b Submits all changes to personal profiles for approvals, as described in the approval rules of the company. c. Allows employees to view the Human Resources data fields that are passed through from the HRMS adapter. d. Allows employees to add or remove items from their favorites list.
• Table 4 lists the specific data fields of a personal profile. Table 4: Fields of Personal Profile
• the system profile contains configuration values for an instance of the system.
• the system profile (an example of which is shown in Table 5) is created when the system is installed. It is intended primarily for setting default values that will be used when creating profiles for new employees.
• the system a. Allows the administrator to change the fields of the system profile, using a simple text editor or spreadsheet.
• Table 5 Fields of a System Profile
• the Product Information Database of a company is the collection of item templates for items that are approved for purchase inside the company.
• Item templates are maintained entirely on the system.
• An example item template is illustrated in Table 6
• the Purchasing Department of a company is typically responsible for maintaining the Product Information Database, helping to make it an accurate and valuable resource
• the system allows purchasing agents to create, edit, and remove item templates This functionality is available only to purchasing agents. It allows them to a. Create new item templates. The need to create new item templates arises most often when there is a requisition for an item that is not in the Product Information Database. If the Purchasing Agent decides to approve the item, he or she will create a new item template for it and decide whether to add it to the Product Information Database. b. Edit existing item templates. A purchasing agent can modify an existing item template, (e.g., update supplier information or price). c. Remove existing item templates. A purchasing agent can deactivate an item from the Product Information Database, if the purchasing agent decides that the item is invalid or no longer recommended.
• the system provides a reporting facility to help buying companies summarize, analyze, understand, and improve their buying process.
• the system comes with a number of pre-defined reports, ranging from buying patterns (e.g. , are we buying too much of something or too little?), to reports on the process itself (e.g. , who is not approving in a timely manner). This information can help the company refine its practices, say by modifying the approval processes or switching suppliers. 1. Defining Reports
• the system provides a variety of reports to categorize and group the information contained in the system.
• the reporting mechanism allows employees
• Each company generally has its own approval process for defining who has to approve each requisition.
• the system models this process with a set of approval rules, which each company can parameterize and extend.
• the approval rules are defined as part of the installation process, but can be modified by the customer's system administrator at any time.
• the approval rules are preferably stored in text files that can be edited with any text file editor.
• the simplest form of approval rules is a tabular file format, which describes values to be used in the rules. This file format allows the customer to: a. Parameterize the approval rules by editing the values in the
• tabular file For example, a company can change the dollar amounts to be associated with approval by various management levels, without changing the
• each rule has: a. A justification field, to be used as explanation for why the rule was invoked.
• a predicate which determines when the rule applies.
• the predicate can be based on any field in the requisition, such as commodity, currency, amount of purchase, ship-to address, or even the customized (i.e. , extensible) fields that this particular company has added.
• c. A consequent, for when the predicate applies. The consequent designates which role or roles need to approve the requisition. For example, a company might write a rule that requires employees with the role of purchasing agent to approve any requests that are for amounts over $200 and that have a ship-to address that is different from the default ship-to address. The particular amount, the $200, will be specified in the tabular file; the predicate-consequent will be in the rules file.
• d. A way to describe which approvals can be done serially, and which can be done in parallel. For example, an organization may want the
• Each line item in a requisition has an assigned Purchasing Agent.
• the system sets the assigned Purchasing Agent before submitting the request for approval.
• Each company can define its own rules for how buyers are assigned, using the same mechanism used for defining approval rules. For example, a
• the system provides the ability to escalate an approval, either manually or automatically, for occasions when an approver has not responded to a request
• Escalating an approval request moves it up the management chain, to the approver's immediate supervisor.
• the system provides the following features for escalation: a. A requester can escalate a request manually. b. If an approver has not responded to a request for approval within the escalation time period defined in the system profile, the system will escalate the approval request automatically. Escalation will continue up the chain as necessary, until someone takes action or there is an employee with no supervisor. c. If a requisition has not been approved within some time period,
• the requisition will time out. That is, any request that has been submitted but not yet fully approved within the specified time frame will be escalated to the administrator. d. Once an approval request has been escalated, the original designated approver can no longer take action on that request.
• Delegation of Authority is a substitution of one approver for
• the system supports delegation of authority in the following ways:
• DOA includes a start date, end date, and comment field explaining why the DOA is in effect.
• the DOA is stored in the employee's personal profile: like all changes to personal profiles, delegations of authority are subject to the approval rules of the company. An employee cannot delegate to more than one person at a time, or split the DOA among more than one designee.
• b If there is a delegation of autho ⁇ ty for an employee, and the date for the delegation has not expired, then the system will allow the delegate to approve in the place of the employee.
• c. Log all delegations of authority as part of the audit trail.
• the system provides a notification mechanism, designed to help keep all interested parties informed about what's going on with a particular requisition.
• the system defines a set of events, which are the triggers for notifying employees, and the recipients of the notifications. In one embodiment, there is no customization of the set of events.
• the system will: a. Provide e-mail notification for each of the defined events, which
• the notification message preferably includes a hypertext link to the Organizer.
• the notification frequency can be specified as Never, Immediate, or On Interval, where the interval is an integer number of Seconds, Minutes, Hours,
• the system uses a database to store all internal data, and record all transactions between clients and the Enterprise Server.
• this database resides on an Oracle Database Server. 4. Customer support and feedback
• the system a. Provides a simple feedback command, to allow customers to
• the system integrates with e-mail programs already in place (e.g. , SMTP), so the system can send employees notifications via e-mail.
• e-mail programs already in place (e.g. , SMTP)
• the Business modules are separable pieces of the system.
• An ordering module is the piece of the system that takes a fully approved requisition and submits it for fulfillment. When a requisition has been fully approved, the system will:
• the three ordering modules are a Purchasing Card Module, Direct Order Module, and a Purchase Order module.
• the Purchasing Card ordering module supports the use of purchasing cards as a payment mechanism.
• Purchasing cards p-cards
• Purchasing card transactions are reconciled on some regular basis with the bank that issued the purchasing card.
• the system maintains the following data associated with each purchasing card, as shown below in Table 11.
• Table 11 Data associated with a purchasing card
• the purchasing card module a. Allows administrators to assign cards to employees and modify the expiration date or authorization limits on purchasing cards. b. For each fully approved requisition, verifies whether a p-card can be used for this purchase:
• ⁇ Chooses a p-card number: If the supplier has a ghosted p-card number, then that is the preferred p-card number. Otherwise, if the employee has a p-card number, uses it. Otherwise, chooses another ordering module.
• ⁇ Checks the amount of the purchase. If it exceeds the per- transaction limit on the purchasing card, then chooses some other ordering module. c. For each transaction using a purchasing card, the system records data as shown in Table 12. The data is reconciled with banks on a monthly basis, using a printed report of the transactions. The reports used for reconciliation show an "allowed variance," because the values (i.e. , the p-card order total) do not include tax and shipping, but the bank values do.
• Table 12 Data in a p-card transaction
• the direct order module is an ordering module that supports communication of orders directly between the buyer and supplier, without storing the requisition in an ERP system. There are typically no constraints on orders under direct billing agreements.
• the direct order agreement includes terms and conditions, and specifies the frequency of billing.
• the system If there is a direct order agreement with a supplier, then the system: a. Checks that the transfer method has been designated for direct order in the item template. If neither the purchase order (PO) or DO order module has been designated in the item template then the supplier profile will be checked for the transfer method. If the supplier profile indicates direct order, then that is the method. Otherwise, it is treated as a PO. b. Transmits the requisition directly to the supplier via fax or e-mail, as specified in the supplier profile. All requisitions transmitted to the supplier are recorded in the audit trail database. Receiving acknowledgement
• the purchase order module is an ordering module whose case results in a purchase requisition in the ERP system.
• the system transmits the requisition to the ERP adapter, as an ERP requisition. Once the requisition is in the ERP, the
• Purchasing Agent can manipulate it with standard ERP operations to complete the process. For example, the agent typically autocreates a purchase order from the requisition, prints it out, an sends it to the supplier for fulfillment.
• the system includes a user interface for acknowledging receipt, which
• a system level toggle that can be set during implementation activates the receiving module.
• the system provides a simple form (the fields of which are shown below in Table 15) for the employee to indicate that he or she has physically received an item.
• This receiving interface a. Allows an employee to acknowledge receipt of an ordered item and to record the number of items received, showing the information in the table below. The employee is able to acknowledge either a single line item or an entire requisition. b. Allows an employee to reject either an entire requisition or an individual line item. When an employee chooses to reject something, the system will ask for a free-form comment, describing the nature of the rejection. There are no partial rejections on quantity, though the employee can convey that information in a comment.
• the reports shown in Tables 16 and 17 may be added to the core list of reports included with the core system.
• the system preferably uses adapters when possible, thus avoiding duplicating any information that is already available. But the system is not dependent on the presence of any of these adapters, and can run stand-alone when a company does not have a particular service or there is no adapter available for it.
• the system preferably uses username and password information from a directory service within the company, if there is such a service at the company and if the company has the appropriate adapter. If the company has no authentication service, the system itself stores the employee name and password information, allowing appropriately authorized system administrators to create new users.
• LDAP Lightweight Directory Access Protocol
• LDAP Lightweight Directory Access Protocol
• the LDAP adapter a. Uses the LDAP protocol for accessing corporate-wide passwords and use those passwords for authenticating employees. b. Provides real-time authentication of users, if the customer's LDAP server is fast enough to support it.
• HRMS systems are used for maintaining employee information such as names, mailstops, and organization structure. If there is no HRMS adapter available, the system supports basic employee management, storing employee
• the PeopleSoft Adapter The PeopleSoft Adapter:
• ERP adapters are the pieces that integrate the system with an enterprise ERP system
• the adapters are customized for each ERP (e.g., Oracle 10.4, 10.5, 10.6, SAP, Baan, D&B, etc.).
• One embodiment of the system provides adapters to Oracle ERP versions 10.4, 10.5, and 10.6.
• the requisition adapter is the basic piece mat integrates with the ERP. It pushes fully-approved requisitions into the ERP, where they are converted into Purchase Orders on the ERP system.
• the adapter can pull back the purchase order numbers for those requisitions, and store the PO numbers as extrinsic data fields associated with each line item.
• the adapter pushes the following data for each line item: Description
• Requester name if the requester exists in the ERP. If there is no such user name in the ERP, then there will be a standard catch-all user,
• the system pulls the set of Units of Measure from the ERP, and use
• the system pulls accounting information from the ERP, with whatever
• accounting details are defined for the company.
• the accounting fields might be:
• the system pulls commodity code information from the ERP.
• the exact structure of the commodity codes depends on the company. For example:
• the system pulls currency rate tables from the ERP, using the rate tables whenever currency conversion is required.
• the adapter pulls a table of currencies and conversion rates for each, pulling the following information:
• the system pulls supplier information from the ERP, on a periodic basis, and store that supplier information in supplier profiles.
• This adapter a. Pulls newly-created suppliers from the ERP. Purchasing Agents need to create new supplier profiles when someone requests a new item. That is, when a requisition includes an ad-hoc line item, the Purchasing Agent locates an appropriate supplier and adds a profile for that supplier in the ERP. The changes are then pulled back into the system.
• the supplier profile in the system has the fields shown below in Table 19.
• Java client that runs within a Web browser, with Java support. Tested on the following platforms and systems:
• Configuration a Provides a template for gathering basic information about the site before the installation: host DBMS, operating system, ERP and HRMS interface issues, e-mail interfaces, accounting and purchasing procedures, supplier data, client hardware and software, supported browsers, network configuration, and business rules.
• b Configure the extensible fields and approval rules, using a text file editor.
• the system provides the ability to seed the database with requisitions that were approved manually, outside the system. This functionality is intended as a convenience to help a company transition from paper requisitions to electronic.
• the system allows an administrator to enter a completed paper requisition into the system, without routing for signature. Requisitions entered in this way will appear in reports, but will not generate any approval requests or notifications, and will not be part of the Product Information Database without
• a Provides the ability to print out purchase orders and transmit them to the supplier.
• the printed purchase orders include standard notes (such as the supplier's terms and conditions) and a purchase order number. This is the only time the system generates a purchase order.

Landscapes

• Business, Economics & Management (AREA)
• Economics (AREA)
• Engineering & Computer Science (AREA)
• Marketing (AREA)
• Quality & Reliability (AREA)
• Finance (AREA)
• Entrepreneurship & Innovation (AREA)
• Human Resources & Organizations (AREA)
• Accounting & Taxation (AREA)
• Operations Research (AREA)
• Development Economics (AREA)
• Strategic Management (AREA)
• Tourism & Hospitality (AREA)
• Physics & Mathematics (AREA)
• General Business, Economics & Management (AREA)
• General Physics & Mathematics (AREA)
• Theoretical Computer Science (AREA)
• Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Applications Claiming Priority (3)

Publications (1)

Family

ID=21932031

Family Applications (1)

Country Status (6)

Families Citing this family (42)

Citations (1)

Family Cites Families (6)

• 1998
  • 1998-04-27 BR BR9809314-2A patent/BR9809314A/pt not_active IP Right Cessation
  • 1998-04-27 WO PCT/US1998/008407 patent/WO1998049644A1/en not_active Application Discontinuation
  • 1998-04-27 CA CA002287850A patent/CA2287850A1/en not_active Abandoned
  • 1998-04-27 EP EP98919907A patent/EP0979480A1/en not_active Ceased
  • 1998-04-27 JP JP54723498A patent/JP2002504245A/ja not_active Ceased
  • 1998-04-27 AU AU72591/98A patent/AU751847B2/en not_active Expired

Patent Citations (1)

Also Published As

Similar Documents

Legal Events