Abstract:
In accordance with the present invention, a method, system, and program for controlling the replenishment process in the manufacturing process by maintaining a common database is disclosed. The present invention connects the acquiring entity, supplier, and the replenishment service center (“RSC”) to efficiently coordinate the replenishment process using the days of supply at the RSC as the key benchmark. By allowing access to the common database, the acquiring entity, supplier, and RSC can view and update changes in the replenishment process in real time increasing the communication and efficiency of delivering components to manufacture a product. In addition, the present invention facilitates the ability for the invoice process to be conducted electronically over the computer network.

Description:
BACKGROUND OF THE INVENTION 
   1. Field of the Invention 
   The present invention relates in general to a replenishment management system, method, and program and more particularly to a replenishment management system, method, and program which provides just in time delivery to an acquiring entity, which may comprise a distribution center, wholesaler or any other supply chain system of components or products. 
   2. Description of the Related Art 
   Availability of components necessary to manufacture a product is a major challenge to the manufacturer of that product. Typically, delivery of components to the manufacturer usually involves three separate parties: the supplier, the replenishment service center (“warehouse or RSC”) and the manufacturer. In the most basic sense, the availability of each component needs to be monitored to ensure an adequate supply is available to the manufacturer. The warehouse supplying the manufacturer and the supplier to the warehouse are further challenged to meet the demand for components without over stocking the components. However, maximizing the efficiency of delivering the components has been a constant problem in the prior art. For example, if the manufacturer finds either an increased or reduced demand in the product compared to its forecast, strain is placed throughout the supply chain where overstocking or depletion of components can occur quickly. In addition, if the supplier cannot deliver the components, manufacturers will often not be able to react quickly to meet demand, seek alternative sources, etc. Without keeping large stock of components on-hand in the warehouse, supply problems occur readily. However, keeping large stock has additional problems of its own, such as higher storage costs, an increased loss probability because components become outdated, etc. Moreover, electronic parts tend to reduce in value with time (i.e. a part that the manufacturer purchases in January will cost less in March and much less in June and so on). 
   Systems in the prior art have attempted to address this replenishment problem using various systems and methods. Internal MRP (“Material Requirement Planning”) or ERP (“Enterprise Resource Planning”) systems would manage components based on a forecast prepared by the manufacturer. However, forecasts are never precise, and often subject to changes. In recent years, to better match actual production with forecasts calculated by the MRP system, a Just-in-Time (“JIT”) concept was developed. In a JIT environment, a network of phones and faxes is used to monitor each point in an assembly line where someone would be responsible for counting each set of components as they are assembled into a product (i.e. a manual pull system). Thereby, the responsible party would order additional components by phone or fax as components are running short. However, such JIT systems require constant monitoring, and still are highly dependent on accurate forecasts. Although better forecasting tools have been developed over the years, replenishment issues have remained a problem for manufacturers. As the manufacturing world begins to move to build-to-order environment, greater demands are expected from the manufacturer to 1) lower total costs in the complete supply chain 2) shorten throughput times 3) reduce stock to a minimum and 4) provide more reliable delivery dates without constraining production due to supply issues. 
   Accordingly, there is a need in the art for an improved replenishment management system that addresses the concerns of the supplier, the manufacturer, and the RSC. 
   SUMMARY OF THE PREFERRED EMBODIMENTS 
   The present invention provides a system, method, and program for ordering or purchasing products between a manufacturer/distributor/etc (hereinafter “acquiring company”), a supplier, and a warehouse company (hereinafter Replenishment Service Center or RSC. To this end, an order to acquire a requested quantity of a specific product is generated by the acquiring entity. A product record is then generated in an inventory database which is updated to include information such as requested quantity, commitment quantity, and received quantity provided by the acquiring entity, supplier or RSC about the specific product. In addition, unlike prior art systems which depended purely on forecasts between the acquiring entity and supplier, the preferred embodiments calculate replenishment needs based on days of supply remaining at the RSC. Moreover, further embodiments are implemented in a network, such as the Internet, that allows the acquiring entity, supplier, or RSC to update and maintain current accurate information on a specific part in the database by means of a web tool, and which further facilitates communications among the acquiring entity, the replenishment service center, and the suppliers on a real time basis. In still further embodiments, invoices are automatically generated for the supplier as parts are pulled from the RSC to the acquiring entity reducing the amount of paperwork involved with the replenishment process. 
   The preferred embodiments allow the acquiring entity to operate on a true “pull” or “kanban” basis. Advantages of the preferred embodiments include improved inventory reduction, higher turnover, in-house warehouse space reduction, handling cost reduction, and early detection of out of specification shipments for a acquiring entity. Additional advantages of the preferred embodiments include better communication between the supplier, warehouse, and acquiring entity throughout the component delivery process including ordering, delivery, and invoicing. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
     Referring now to the drawings in which like reference numbers represent corresponding parts throughout: 
       FIG. 1  illustrates a network computing environment in which preferred embodiments are implemented; 
       FIG. 2  illustrates a computing environment of a manufacturer server in accordance with preferred embodiments of the present invention; 
       FIG. 3  illustrates files in a part record in accordance with preferred embodiments of the present invention; 
       FIG. 4  illustrates a program flow implemented in the manufacturer server to provide information on forecasted and ordered parts to the supplier and replenishment service center in accordance with preferred embodiments of the present invention; 
       FIG. 5  illustrates a program flow implemented in the manufacturer server to allow a supplier to commit to supplying requested parts and provide status information on the progress of delivering those parts to the replenishment service center in accordance with preferred embodiments of the present invention; 
       FIG. 6  illustrates a program flow implemented in the manufacturer server to update parts information in a database from information provided by the supplier and replenishment service center in accordance with preferred embodiments of the present invention; 
       FIG. 7  illustrates a program flow implemented in the manufacturer server to determine the days of supply for a part at the replenishment service center in accordance with preferred embodiments of the present invention; and 
       FIG. 8  illustrates a program flow implemented in the manufacturer server to generate an invoice and payment for the manufacturer in accordance with preferred embodiments of the present invention; 
   

   DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
   In the following description, reference is made to the accompanying drawings which form a part hereof and which illustrate the preferred embodiment of the present invention. It is understood that other embodiments may be utilized and structural and operational changes may be made without departing from the scope of the present invention. 
     FIG. 1  is a schematic overview diagram of the network computing environment in which the preferred embodiments are implemented. In preferred embodiments, a manufacturer server  10 , a supplier computer  20 , and replenishment service center (“RSC”) computer  30  are linked together using a network  40 , such as the Internet. The network  40  may be comprised of any network system known in the art including TCP/IP based networks (e.g., an Intranet, the Internet), LAN, Ethernet, WAN, Token Ring, etc. Alternatively, there may be separate and different networks between the components. Further, for a single part requested by the manufacturer, there can be numerous suppliers and RSCs, however a single supplier computer  20  and single RSC computer  30  is used for illustration purposes. 
     FIG. 2  illustrates software components in the manufacturer server  10  in which preferred embodiments are, including an Enterprise Resource Planning (“ERP”) program  50 , Hypertext Transfer Protocol (HTTP) server  52 , database  60 , database interface  70  and templates  65  and  67 . The HTTP server  52  responds to requests from the supplier  20  and RSC  30  computers using HTTP client programs, such as web browser programs known in the art. Upon accessing the server  52  through the network  40  using a unique network address, such as an IP address, the database interface  70  will give specific access to database  60  depending on the secured identification provided by the supplier  20  or RSC  30  computers. 
   The database  60  provides the manufacturer, supplier, and RSC with current, accurate information about the pipeline inventory necessary for the manufacturing process. The database  60  comprises a database program known in the art, such as a relational database program. The database  60  includes a database table  61  that includes records  62   a, b, . . . n . The records  62   a, b, . . . n  are used in the preferred embodiment as parts record  62   a, b, . . . n  to store information about the component parts requested by the manufacturer and supplied by the supplier to the RSC throughout the replenishment process. 
   The database interface  70  may comprise a Common Gateway Interface (CGI) program, a Java servlet, or other web page implementation known in the art to present the information in database  60  in a presentable format (e.g. HTML page, etc.). In preferred embodiments, the database interface  70  uses a secured login/password verification for identifying the individual supplier  20  or RSC  30  computer contacting the manufacturer&#39;s HTTP server  52 . The unique identification will allow the database interface  70  to identify which parts record  62   a, b, . . . n  belong to the requesting party and will appropriately give read/write capabilities to the parts record  62   a, b, . . . n.    
   The ERP program  50  is a common materials resource planning (MRP) tool used by most manufacturers today. The ERP program  50  determines the quantity of components required to manufacture of a determined number of a particular product over a specific period of time and prepares forecasts of the number of components required from each supplier. The ERP program  50  then places transfer orders for components from the RSC. In preferred embodiments, the ERP program  50  is capable of accessing the database  60  via a database interface system (not shown), such as the Open Database Connectivity (ODBC) standard database access method. The server  10  further stores a display template  65  and an input template  67 , which are preferably implemented in a document in which dynamic content may be generated (i.e. HTML, Extended Markup Language (XML) Document, etc.). Differing variations of the display template  65  and input template  67  exists for both suppliers and RSCs, depending on the information to be displayed or inputted, but a single display template  65  and a single input template  67  are used for illustration purposes in  FIG. 2 . The display template  65  is used to provide the supplier  20  and RSC  30  computers with forecasts and past history reports generated by the ERP  50 , as well as parts information from the database table  61 . The database interface  70  generates data into the display template  65  from one or more of the records  62   a, b, . . . n  in the database  60 . The input template  67  includes fields in which the supplier  20  and RSC  30  may enter information on the replenishment process which will be used to update one or more records  62   a, b, . . . n  in the database  60 . 
   The database  60 , display template  65 , and input template  67  are preferably stored in a non-volatile storage system, such as one or more hard disk drives, used by the server  10  for storage. The server  10  may load data from the storage system into volatile memory (not shown) when processing. 
   The manufacturer  10 , supplier  20  or RSC  30  computers may comprise any type of computer device known in the art, including server, personal computer, mainframe, workstation, hand held device, etc. Moreover, the manufacturer server  10  may comprise one or more separate computer systems to run the different program components  50 ,  52 ,  60 , and  70 . 
   As discussed, the part records  62   a, b, . . . n  may comprise fields containing information on parts used in the manufacturing of one or more products. The ERP  50  may determine the exact number of parts needed upon receiving a request for a product order and then generate the parts records  62   a, b, . . . n  including a purchase order for parts that will be needed to build the product. Thus, each part record  62   a, b , . . . n is generated in response to a forecast for parts the manufacturer plans to use to build products. 
     FIG. 3  provides an implementation of the fields in the parts records  62   a, b, n , including: —
         Record ID  110 : Provides a unique identifier generated by the ERP  50  for the component part ordered by the manufacturer.   P.O. Number  111 : Provides a unique identifier of the purchase order generated by the ERP  50  for parts needed to fulfill a manufacturer production goal.   Part Number  112 : Provides a unique identifier of the actual component part generated by the ERP  50 .   Supplier ID  114 : Provides a unique identifier of the supplier who is to provide the component parts to the manufacturer.   Forecasted Quantity  116 : Comprises one or more sub-fields indicating the projected quantity of parts required from the supplier by the manufacturer for a future designated time period.   Date Needed  118 : Comprises one or more sub-fields indicating the date the part is needed at the RSC according to the forecast prepared by the ERP  50 .   Committed Quantity  120 : One or more sub-fields set by the supplier computer  20  indicating the number of parts the supplier has committed to deliver to the RSC on specific dates.   Shipment Information  122 : One or more sub-fields set by supplier computer  20  providing tracking information on the delivery of components from the supplier to the RSC including method of shipment, carrier, port of entry, date of shipment and estimated time of arrival (“ETA”).   RSC Shipment Status  124 : Field set by RSC computer  30  indicating whether the components have been received or not from the supplier.   Requested Quantity  125 : Projected quantity of parts to be requested from the RSC on specific dates to satisfy the production needs of the manufacturer.   Pull Order Status  126 : One or more sub-fields set by the database interface  70  indicating the pull status (i.e. status of the components being pulled from the RSC to the manufacturer) including whether the components have been ordered to be pulled or not (Pull In Requested Status), whether the RSC can fulfill the requested amount of components (Pull In Committed Status), whether the products are received or not at the manufacturer&#39;s dock (Pull In Shipped Status or Pull in Cancelled Status), as well as historic pull information (Pull History).   Available Inventory  127 : Indicates the amount of parts currently available at the RSC.   Defective Notice  128 : Indicates the quantity of parts being returned as defective.   Price  130 : Indicates the price per unit of component.
 
Those skilled in the art will appreciate that  FIG. 3  is a preferred embodiment of the record  62   a, b, . . . n , but not as the only implementation. The record  62   a, b, . . . n  can be structured in many alternative formats to accomplish the present invention. For example, the separate Available Inventory field  127  may not be needed and instead the value for the available inventory may just be calculated as needed by comparing the RSC Shipment Status  124  and the Pull Order Status  126 . Another example is the Forecasted Quantity field  116  may be combined with the Requested Quantity field  125  into a single field used by both the supplier and RSC rather than two separate fields for the supplier and RSC.
       
   Typically the forecasting and shipping process starts when the manufacturer makes a decision on the number of products it plans to build over a set of future time periods designated by the manufacturer. A blanket purchase order may be issued by the manufacturer to order the necessary components for the product. The ERP program  50  determines the number of components needed from each individual supplier, compares the number of parts needed with the number of parts committed from existing supplier contracts, and prepares a delivery schedule for each part. The ERP  50  then creates a separate record  62   a, b, . . . n  for each part order in the database  60 . The data for the Record ID  110 , P.O. No.  111 , Part No.  112 , Supplier ID  114 , Forecasted Quantity  116  and Date Needed  118  is generated by the ERP program  50  and stored in the appropriate part record  62   a, b, . . . n.    
     FIGS. 4 ,  5 ,  6 ,  7 , and  8  illustrate the program logic embedded in the ERP program  50 , HTTP server  52 , and database interface  70  to implement the replenishment process of the preferred embodiments.  FIG. 4  illustrates the program logic to provide part record  62   a, b, . . . n  information to the supplier  20  and RSC  30  computers. At block  400 , the HTTP server  52  receives a request from the supplier  20  or RSC  30  computer (“requesting party”) for information on one or more part records  62   a, b, . . . n . The supplier  20  or RSC  30  computer may supply the record ID  110  or access a view of the part records in the database  60  and then select particular part records from the view. The HTTP server  52  may require a secured identification and password. At block  410 , the database interface  70  accesses the display template  65  and builds an HTML web page. The database interface program  70  queries (at block  420 ) the database table  61  for the requested one or more records and then inserts (at block  430 ) the returned information into the display template. For example, when the supplier wants to view the forecast order placed by the manufacturer, the database interface  70  will search the database  60  on the Record ID  110  or Part No.  112  which matches the supplier computer&#39;s  20  search request. The database interface  70  will then build a HTML web page based on a display template  65  which will list a menu of information available to the supplier such as new forecast orders, commitment history, existing commitment outstanding, existing parts stored at the RSC, etc. The generated display page may include information such as the P.O. No.  111 , Supplier ID  114 , Forecasted Quantity  116  and Date Needed  118 . 
     FIG. 5  illustrates the program logic implemented in the HTTP server  52  and database interface  70  to receive commitment and part status information from the supplier for a part record. At block  500 , the HTTP server  52  receives a request from the supplier computer  20  for the input page to provide commitment information with respect to a part record  62   a, b, . . . n . In response, the HTTP server  52  requests (at block  512 ) the database interface  70 , which accesses the input template  67  and builds an HTML input page for the specified part record  62   a, b, . . . n . The built HTML input page is then sent to the supplier computer  20 , where the supplier can enter commitment quantities for one or more part records. At block  514 , the HTTP server  52  receives the HTML input page with the commitment quantities the supplier entered. In response, the HTTP server  52  requests the database interface  70  to update (at block  516 ) the commitment quantity field  120  of the relevant record with the information supplied by the supplier. 
   At block  518 , the database interface  70  determines if the Committed Quantity  120  matches the Forecasted Quantity  116 . If the supplier did not commit to the entire forecasted quantity  116 , then the database interface  70  generates an exception view (at block  520 ) for all the uncommitted quantities. The manufacturer can then locate other suppliers to deliver the components or reduce product production to take into account that the supplier will not supply all the requested parts. The supplier may issue a shipment pre-alert document to the RSC personnel. This shipment pre-alert may specify when the supplier intends to make the shipment, the part number, quantity, etc. typically through an e-mail and/or fax. 
   At some point, the supplier is going to ship the committed quantity to the RSC. The supplier can then input various shipping information into the database  60  to confirm delivery to the RSC according to the terms of the supplier contract. The process initiates at block  550  where the HTTP server  52  receives a request for an input page from the supplier computer  20  to write in the shipment information  122  covering the method of shipment, carrier, port of entry, date of shipment and ETA (“shipment tracking information”) for one or more part records  62   a, b, . . . n . At block  552 , the HTTP server  52  requests the database interface  70 , which accesses an input template  67 . The database interface  70  builds an HTML input page in which the supplier can enter shipment tracking information for the specified part record(s)  62   a, b, . . . n . The HTTP server  52  then sends the input page back to the supplier computer  20 . At block  554 , the HTTP server  52  receives the input page from the supplier computer  20  in which shipment information was entered. The HTTP server  52  then requests (at block  556 ) the database interface  70  to update the shipment information field  122  in the part records  62   a, b, . . . n  for which shipment information is provided in the input page. Once shipment information is entered, the shipment or other information provided by the supplier is available to the manufacturer and RSC in the database  60 . 
   Once the components are ready, the supplier then ships the components to the RSC. The RSC will typically ensure that all necessary customs clearance and bonding documents are prepared in accordance with customs law regulations. An optional broker can be subcontracted by the RSC to facilitate the customs clearance process. Therefore, additional fields may exist in the Fulfillment Information  122  to indicate any potential broker used, customs requirement, etc. 
     FIG. 6  illustrates the program logic implemented in the HTTP server  52  and database interface  70  to receive inventory information from the RSC computer  30  for each part. The RSC updates information in the part records  62   a, b, . . . n  upon receiving parts from the supplier or receiving a pull request for the parts from the manufacturer, which may be transmitted by the manufacturer server  10 . The pull process is initiated when the manufacturer server  10  sends a Pull Order to the RSC computer  30 , i.e. ordering the delivery of component parts stored at the RSC to the manufacturing floor of the manufacturer  102 . The Pull Order is initiated by the ERP program  50  as parts are needed. The ERP program  50  then updates the Pull Order Status  126  as Pull Orders are issued. Typically, the RSC prepares the necessary documentation to provide a secure form of transportation from the RSC to the manufacturer&#39;s dock. 
   At block  600 , the HTTP server  52  receives a request from the RSC for an input page in which it can provide status information for part records  62   a, b, . . . n  as changes in the inventory occur at the RSC. The RSC computer  30  may request part record information as described in  FIG. 4 . The HTTP server  52  requests (at block  602 ) the database interface  70  to access the input template  67  and builds an HTML input page in which the RSC may enter input information on whether the parts have been received from the supplier or parts were shipped to the manufacturer. At block  604 , the HTTP server  52  receives an input page including inventory information for specified part record(s)  62   a, b, . . . n , indicating parts received from the supplier or parts shipped to the manufacturer. The RSC provides information for RSC Shipment Status  124  or Pull Order Status  126 . The database interface  70  (at block  606 ) updates the part record(s)  62   a, b, . . . n  with the RSC Shipment Status  124  or Pull Order Status  126  from the RSC. The updated information is then available to the supplier and manufacturer in the database  60 . 
   At block  608 , the database interface  70  will calculate the “Days of Supply” existing at the RSC, and determine whether the agreed “Days of Supply” exist at the RSC. Details of the calculation is given in  FIG. 7 . “Days of Supply” is the optimal amount of inventory to be held at the RSC by the supplier. The optimal amount is calculated by the manufacturer and negotiated with the supplier. Typically, the supplier will review the days of supply available at the RSC for its parts. If the available days of supply are less than the fixed days of supply agreed with the manufacturer, the supplier will ship parts to comply with the manufacturer&#39;s agreed Days of Supply. 
     FIG. 7  illustrates the program logic implemented in the database interface  70  to calculate the Days of Supply at the RSC according to the preferred embodiments. At block  700 , the database interface  70  accesses the record  62   a, b, . . . n  for the particular part stored at the RSC. At block  702 , the database interface  70  accesses the Available Inventory field  127  in the record  62   a, b, . . . n . At block  706 , the database interface  70  accesses the number of components to be pulled according to the Requested Quantity  125  in specific time period. At block  708 , the Days of Supply is calculated by dividing the inventory available at the RSC by a weighted pull rate. The actual equation for the weighted pull rate is to be set by the manufacturer depending on the manufacturer&#39;s needs. For example, for a basic supply chain, the simplest formula for the weighted pull rate can be calculated by dividing the forecasted number of parts needed for the next Y number of weeks by the number of production days in those Y weeks to derive the Daily Going Rate (“DGR”). The Days of Supply would then be calculated by dividing present inventory by the DGR. Alternatively, for a high volume manufacturer, the Days of Supply can be varied to assume that the next week forecast is already pulled and look further forward in time to calculate the Days of Supply. For example, the weighted pull rate can be calculated by dividing the forecasted number of parts needed in week number 2 (two weeks from current week) and week number 3 (three weeks from current week) by the number of production days in week number 2 and number 3. The Days of Supply is then calculated by first subtracting the forecasted number of parts needed in week number 1 (next week) from the present inventory at the RSC and then dividing by the weighted pull rate. Yet in other businesses where the manufacturer depends more on historic pull rates, another example exists where the weighted pull rate can be calculated by taking the average of the expected pull rate in the next X number of days or weeks and the actual pull rate in the past X number of days or weeks. Again, the Days of Supply is calculated by dividing the current inventory available at the RSC by the weighted pull rate. Therefore, without deviating from the scope of the present invention, there exists many variations in determining the Days of Supply depending on how the weighted pull rate is calculated, which ultimately depends on the needs of the manufacturer. 
   Once the components are delivered from the RSC to the manufacturer, a physical product inspection may be performed. At which time, any damaged or defective component parts are sent back to the RSC. The defective notice field  128  of database  60  is then updated to reflect any returned component parts. The returned component parts are kept in a separate part of the RSC to either be reworked, scraped or returned back to the supplier, according to the supplier&#39;s instructions. If the component parts are deemed acceptable by the manufacturer, then a receipt of acceptance is issued by ERP  50 . The ERP  50  then updates the database  60  to reflect the acceptance of the component parts. The database interface  70  updates the pull status  126  to reflect that the component parts or products were received by the manufacturer. Thereby notice is given to both the RSC and supplier on the delivery of the components if they access the record  62  for the relevant shipment. 
     FIG. 8  illustrates the program logic implemented in the HTTP server  52  and database interface  70  for the automatic invoicing and payment process according to the preferred embodiment. Once the receipt of the components are updated on part record  62   a, b  . . . n of the relevant shipment, the ERP  50  generates a goods receipt document and stores a price value in the price field  130  for part record  62   a, b, . . . n . The database interface  70  will query the part records  62   a, b  . . . n for any pulls in status shipped for that supplier (block  800 ) and query the supplier about a specific invoice number and price information (block  805 ) which the supplier needs to provide. At block  810 , the database interface  70  accesses an input template  67  and builds an HTML page which will have blanks next to the pre-invoice for the supplier  20  to confirm the invoice number and the unit price for the part. At block  820 , the supplier computer  20  will input values for Price  130 . At block  830 , the database interface  70  will then compare the values inputted by the supplier  20  with the values stored by the ERP program  50 . If they match (block  840 ), then in block  850 , an invoice document is automatically generated and payment to the supplier is processed according to the agreed upon payment term. The Pull Status  126  in database  60  will be updated from Shipped to Invoiced. If a discrepancy is found, at block  860 , the Pull Status  126  is changed from Shipped to Buyer Pending, and the manufacturer is given the opportunity to approve or reject the difference in the part&#39;s price (block  870 ). A supplier representative can also contact the manufacturer to reconcile the differences. Once an agreement is made (i.e. a match according to block  840 ), an invoice document can be produced according to block  850 . The ability to invoice through the database driven inventory system substantially simplifies the payment process and allows greater efficiency in the replenishment process. 
   Those skilled in the art will again appreciate that alternative embodiments exists from the description of the preferred embodiments without departing from the spirit and scope of the invention. The preferred embodiments may be implemented as a method, apparatus or article of manufacture using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof. The term “article of manufacture” (or alternatively, “computer program product”) as used herein is intended to encompass one or more computer programs and data files accessible from one or more computer-readable devices, carriers, or media, such as a magnetic storage media, “floppy disk,” CD-ROM, a file server providing access to the programs via a network transmission line, holographic unit, etc. Of course, those skilled in the art will recognize that many modifications may be made to this configuration without departing from the scope of the present invention. 
   Preferred embodiments were shown in the context of network system, where all of the communications were performed through computers located at the supplier, RSC, and the manufacturer. However, in alternative embodiments, many of the functions can be performed by other means of communication such as telephone, fax, e-mail, etc by operators located at the supplier, RSC, or manufacturer. For example, the supplier may directly call an operator at the manufacturer to give commitment values, shipment information, etc. rather than entering the values through the network by means of the supplier computer. The RSC or manufacturer may directly contact each other by phone, fax, e-mail, etc. for current inventory levels, pull order status, etc. rather than using the computer network. 
   In the described embodiments, a manufacturer was the entity that acquired parts from the RSC using the computerized database inventory management system of the preferred embodiments. In alternative embodiments, the computerized database inventory management system may be used by any acquiring entity and the parts being ordered may comprise products or supplies being acquired by the acquiring entity. For instance, the acquiring entity, in addition to being a manufacturer, can be a distributor or wholesaler or any other party having a supply chain. A hospital or a retail store may house its supplies/inventory at a warehouse and use the preferred embodiment database inventory system to order additional supplies as they are either used or sold off the shelves. Thus, the acquiring entity may encompass any entity that controls inventory process throughout the supply chain. Similarly, the RSC can be directly owned by either the supplier or manufacturer or third party, but the ownership does not effect its function or ability in the present invention. 
   Preferred embodiments were described with respect to the database interface  70  performing the computation regarding the Days of Supply, generating the Exception View, etc. However, in alternative embodiments, some of the functions of the database interface may be implemented in the ERP program, a separate software program or eliminated altogether. Alternatively, the functions shown may be combined or split in any manner amongst one or more systems. 
   In addition, preferred embodiments described the parts information describing the files as implemented as database records in a database table. However, the parts information may be implemented in any format for maintaining object information, including spreadsheet, non-database table, etc. Thus, as used herein, the terms database record, database table, and database refer to any data structure known in the art for maintaining information on data objects, such as relational databases, non-relational databases, spreadsheets, ASCII text files, etc. 
   Therefore, the foregoing description of the preferred embodiments of the invention has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. It is intended that the scope of the invention be limited not by this detailed description, but rather by the claims appended hereto. The above specification, examples and data provide a complete description of the manufacture and use of the composition of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended.