Just-in-time requisition and inventory management system5712989Abstract In accordance with the present invention, a requisition and inventory management system is provided which employs both a host computer and a local computer which can be linked to permit two-way data communications in a real time environment. Each computer has an associated database which can be accessed by that computer. By accessing its respective database, each computer can build and transmit to the other computer communications blocks of data relating to a particular requisition of an item in Just-in-Time (JIT) inventory or to the management of the JIT inventory. The other computer can then use the received data to continue processing of the requisition or to update its JIT inventory records. Thus requisition records are created from a real-time interaction between the host and local computers, with each computer using data from its respective database in conjunction with information entered by a Customer Service Representative (CSR) operating the local computer. The system of the present invention also utilizes means for automatically determining which items in the JIT inventory are likely to require replenishment. The system then proposes a purchase or transfer order for an optimum quantity of the item, which the CSR may accept or modify. Claims We claim: Description BACKGROUND OF THE INVENTION
TABLE 1
______________________________________
PRODUCT
TYPE DESCRIPTION
______________________________________
01 Distributor owned item in JIT
warehouse located at or near the
Customer's site
02 This price type is not currently
used, but has been reserved for
Distributor-owned items in Distributor's
warehouse 30 which have been segregated
in some fashion for a particular
Customer.
03 Distributor catalog item; stored in
Distributor's warehouse
04 3rd party item that Distributor orders
05 3rd party item which CSR or Customer
orders
06 Customer owned item located in Customer
warehouse at or near Customer site
______________________________________
Requisitioning Requisitioning on the system of the present invention is described in FIGS. 2A and 2B. In FIGS. 2A and 2B, the diamonds represent decisions. The rectangles represent data screens as well as programs associated with those data screens. The rounded rectangles represent programs not associated with data screens such that, while these programs are running, the prior data screen may remain visible without, necessarily, being operational for the input of data. The programs associated with the data screens enable the CSR to display and modify the contents of various tables associated with particular data screens. These tables make up local database 50, which can be any relational database. As the data (e.g., Account Number, Requisition Number and Stock Numbers) associated with a single requisition are entered through the various data screens on local computer 40, that computer creates a set of Requisition Tables (a Requisition Header Table and a Requisition Item Table) for that particular requisition. The Requisition Tables are stored in local database 50, and can be accessed by local computer 40 using the Requisition Number to find the desired table. The CSR will ordinarily receive a written or oral request from an employee of the Customer to requisition one or more items. For example, a laboratory technician may approach the CSR with a list of supplies to withdraw from an on-site JIT stockroom. In some forms of the invention, such a requisition request can be received by local computer 40 in electronic form through the customer's host computer (not shown on FIG. 1), through a telephone line or in electronic media such as a floppy disc. The first step in creating a requisition involves entry by the CSR of information in the Order Header data screen 60 in FIG. 2A. A sample of an actual Order Header data screen is set forth Table I. Generally, the CSR need only enter the Account Number and a Requisition Number. Hitting the ENTER key after entering the Account Number (which is the Distributor's designation for the customer department for which the requisition is placed) will automatically cause the correct Name and Address associated with that Account Number to be entered into the appropriate fields of data screen 60. Local computer 40 accomplishes this by comparing the entered Account Number to a table of account number records in local database 50 which contains certain basic information associated with each Account Number record stored therein. This database table has been previously created by the CSR using the associated Customer Account Maintenance data screen, a sample of which is shown in Table XIII. A Requisition Number is also required for each requisition. The CSR must also enter this information in the appropriate field of the Order Header data screen. The requisition number can be the customer's own internal requisition number, or can be any unique number assigned to the requisition by the CSR. Various additional information may also be inputted, such as the name of the person needing the items ordered in the requisition, the name of the person who called the CSR to place the requisition, etc. The ORDER TYPE field on Order Header data screen 60 can have one of three values: "R" for an ordinary Requisition; "T" if the requisition was generated to replenish Customer-owned JIT inventory 54, as will be discussed below; and "G" if the order is for returning JIT inventory to JIT facility 51, as will be discussed below. The ordinary Requisition order type ("R") is the default. At the bottom of the screen are several fields which describe the function of various function keys (e.g., F1, F2 etc.). In this data screen, the CSR can preferably obtain help online by hitting the F1 key. The online help facility functions in a conventional manner that will readily be understood by those of ordinary skill in the art. Hitting the F3 key would permit the CSR to quit the program; hitting F4 would erase the contents of any of the fields into which data had been previously entered to permit a new requisition to be entered. Hitting F11 would permit the CSR to change the requisition number to enter a new requisition. Hitting F12 permits the CSR to cancel an open requisition. Function keys F2, F5 and F6 all cause the system to jump to a new program or data screen. F2 causes the program to jump to Requisition Management data screen 68 as shown in FIG. 2A. Hitting F6 will cause the system to enter the sourcing program 88 shown in FIG. 2A, provided that the CSR has already entered the necessary information on the Order Header data screen 60 and one or more items on the Requisition Management data screen 68, as will be discussed below. If the CSR has just begun the requisition (and has not yet entered at least an Account Number, a Requisition Number and at least one item), then hitting F6 will have no effect. Because the CSR will not ordinarily initiate sourcing program 88 from Order Header data screen 60, no arrow is shown in FIG. 2A linking these programs. It should be noted that function keys (F1, F2 etc.) are not the only means for directing the flow of the program shown in FIG. 2A. Each data screen and program also has a unique four character identification code. To go directly to a particular data screen or begin a subroutine, the CSR can enter the associated code into the RESPONSE field shown on any data screen along with any necessary parameters, which are entered in the KEY(S) field. For example, to Fast Path to Cross Reference Maintenance data screen 76, the CSR can enter the code CRNL into the RESPONSE field. If the CSR hits the F5 key from Order Header data screen 60, the system jumps to the Customer Variable Header data screen 64 and associated program as shown in FIG. 2A. An example of a Customer Variable Header data screen 64 is set forth at Table II. This data screen allows the CSR to enter and edit information that the particular customer desires to be associated with the requisition due to requirements of the customer's internal accounting system or other systems. Examples of such customer variable information might be the names (or identification codes) of various customer divisions or customer projects. The CSR can define any desired fields for the Customer Variable Header data screen in the manner set forth below. Thus the Customer Variable Header data screen may contain one or more data fields into which the CSR may enter and edit data, such as a division name or identification code, of interest to the Customer but not, necessarily, to Distributor. This variable information is useful in preparing data sets such as Requisition summary reports, status reports, financial reports and the like which can be loaded periodically on request into the Customer's own host computer, either as a flat file or in a customized form. If the CSR hits the F2 key from the Order Header data screen (or the F4 key from the Customer Variable Header data screen) the program jumps to Requisition Management data screen 68 in FIG. 2A. A sample Requisition Management data screen is set forth at Table III. The CSR uses this data screen to enter the catalog or stock numbers and quantities of the various items being ordered. The Account Number and Requisition Number are automatically passed to Requisition Management data screen 68 and displayed at the top of the Requisition Management data screen 68 in the relevant fields. The CSR can now enter the items and quantities for the requisition. The item is identified by entering the Distributor catalog number of the desired item in the field below the STOCK NBR label on the appropriate line number in Requisition Management data screen 68. In the sample screen shown in Table III, the stock number A181 has been entered in the STOCK NBR field of line 001. The CSR may also enter an item by using a catalog or reference number from a third-party supplier other than the Distributor where the same item has both Distributor and third-party catalog numbers (which are necessarily different). In the preferred embodiment, most records in local database 50 identify products by a stock number or part number compatible with the Customer's record-keeping system. Part Master records (see Table VI) also contain a manufacturer or supplier's catalog or part number, which will be the number used on purchase orders and, for product types 01 and 03, will be the Distributor's catalog or part number. The local database 50 contains a cross-reference file between such stock numbers and a particular supplier's catalog or part number. The creation of this cross-reference file by the CSR is described below. When the CSR enters an item code in the STOCK NBR field and hits the ENTER key, local computer 40 begins a program described in the flowchart is shown in FIG. 3. The entered stock number appears on the data screen as it is being entered. In step 201, the entered stock number is added to the appropriate field of the Requisition Item Table in local database 50 along with the associated line number. In step 202, local computer 40 searches the Part Master Table in local database 50 for the STOCK NBR that has just been entered (which can be either the Customer's stock number or a valid cross-reference number such as a Distributor catalog number). (A description of how the Part Master Table in local database 50 is created by the CSR is set forth in detail below.) If the stock number is not found the Part Master Table in local database 50, as indicated in steps 204 and 206, the product type field defaults to product type 03. The display on the Requisition Management data screen 68 is then updated to reflect this information (the PT field displays "03") as shown in step 212. As described below, such designation of product type 03 will be verified during the Sourcing steps using the product records and cross-reference files contained in host database 20. If, on the other hand, the entered stock number is found in the Part Master Table in local database 50, as indicated in steps 204 and 208, the Requisition Item Table in local database 50 is updated with the following information from the entry in the Part Master Table associated with the relevant stock number: the default unit of measure; the product type; the cross-reference number, if any; and a text description of the item. In step 209, Requisition Item Table is updated with the following information from the entry in the Plant Location Table in local database 50 associated with the relevant stock number: the quantity of the item available in the Customer-owned inventory 54 in the JIT facility 51 (for product type 06) or in the Distributor-owned inventory 52 in the JIT facility 51 (for product type 01); a description of the location of the item in the relevant stockroom or warehouse (e.g., by aisle and shelf); and a code identifying the relevant stockroom or warehouse. In steps 210 and 211, the Unit Price is added to the Requisition Item Table if the product type is 06. (The Plant Location Table is created and updated using the Plant Location data screen, a sample of which is set forth in Table VII.) In the system of the present invention, a particular stock number will preferably be either Customer-owned (product type 06) or Distributor-owned (product type 01) in the local JIT, but not both. Thus a given stock number may or may not have a corresponding entry in the Part Master (or Plant Location) Table in local database 50; but, if a record exists there, there will be at one time only one record associated with the stock number. Thus, stock stored in the JIT facility 51 of one product (whether in a single bin or in multiple bins), will either be all customer-owned or all Distributor-owned. Customer and Distributor may, however, decide at any time to redesignate particular products from Customer-owned to Distributor-owned (with corresponding change of ownership and debit or credit to the applicable accounts). Such a change can be reflected in local database 50 using the Part Master, Plant Location and Inventory Adjustment data screens (samples of which are set forth in Tables VI, VII and VIII, respectively), without necessarily moving the inventory physically within the JIT facility 51. In the instance where the stock number is found in the local database 50, the display of data screen 68 is then updated in step 212 by displaying: the default unit of measure (in the UM field); the product type (in the PT field); the cross-reference number, if any (in the XREF field); the list price of the item, if the product type is 06 (in the UNIT PRICE field); a text description of the item (in the DESC field); the quantity of the item available in the JIT facility 51 as Customer-owned inventory 54, product type 06, or as Distributor-owned inventory 52, product type 01 (in the QTY AVAIL field); a description of the location of the item in the relevant stockroom or warehouse (in the LOC field); and a code identifying the relevant warehouse (in the WHSE field). At this time, if the product type is shown to be type 03, the CSR may edit this field to change the product type to 04 or 05, as shown in steps 213 and 214 of FIG. 3 if the CSR knows that the item is not regularly available from Distributor as a routine item. This editing will change both the displayed product type and the value of the product type field in the applicable field of the Requisition Item Table. Local database 50 includes as product type 01 items only a subset of the entire set of Distributor catalog items. Thus, in step 206, local computer 40 assigns a product type 03 by default to any item number which is not determined to be a product type 01 or 06--i.e., for which a Part Master record is not found in local database 50. As described below, host computer 10 will verify the 03 status for such products during sourcing and communicate information to local computer 40 to establish an error code for such 03 status if not found in host database 20. If the CSR fails to change the product type for an item which host computer 10 is unable to identify as a Distributor catalog item, an error will result during sourcing when host computer 10 attempts to source the item. This error will be handled as discussed below. The CSR can then enter the quantity of the item being requisitioned in the field below the QTY label in Requisition Management data screen 68. The entered quantity will be displayed on data screen 68 and this data will be entered into the appropriate field of the Requisition Item Table in local database 50. The unit of measure associated with this quantity is defined by the value in the UM field. In the example shown in Table III, this field is occupied by "EA," meaning that the unit of measure is a single unit for A181 (a single one liter bottle of acetone). This is the default unit of measure for this item and is the unit in which all records and computations are performed. An alternate unit of measure is preferably also provided (as is the case for many of the products in host database 20), which is a multiple of the standard unit (e.g., a "CS" or case of six such bottles of acetone). Within the Part Master Table, a unit price is maintained, but only for product type 06 will a unit price be displayed at this stage as indicated in steps 210 and 211 (during requisition management and before sourcing). The CSR may use as many lines of the Requisition Management data screen 68 as are necessary to complete the requisition (up to a preset or default limit set by the system, e.g., 200 lines; or to a lower limit set by the CSR, e.g., 100 lines). Keys F7 and F8 allow the CSR to page forward and backward on Requisition Management data screen 68; the F9 key provides the next available line number at the top of the list of items (giving the CSR a new screen to work with). Hitting the F4 key creates a new requisition (to which the CSR must assign a new requisition number) with the same Customer Account Number and the associated address information. The F5 key causes a customer variable item data screen to be displayed, which enables the CSR to enter information that the customer desires to have associated with a given item. With the exception of the F10 key, the functions of the remaining function keys will be clear from the previous discussion. Hitting the F10 key calls the Non-Catalog Information data screen 80 onto the screen of monitor 41. An example of a Non-Catalog Information data screen 80 is shown in Table V. This data screen is used to enter additional information about items not regularly sold by Distributor (for which host database 20 contains a Distributor catalog number and list price), but which are available as third-party purchases by Distributor (product type 04) or as administrative purchases by Customer (product type 05): e.g., the identification of the third party vendor (by number and name), the vendor's part number, the vendor's offered price and other information shown in Table V. If the CSR has previously created a cross-reference entry in the Cross Reference Table (using Cross Reference Maintenance data screen 76) for the item, some or all of the information on Non-Catalog Information data screen 80 will be automatically filled in using the data associated with that stock number (of the vendor) in the Cross-Reference Table in local database 50. Information associated with products of type 04 will, to at least some extent, be shared with the host computer 10. Information associated with type 05 products will, for the most part, not be shared with the host computer 10. Nevertheless, records about both types of products are maintained in local database 50 and are available for flat file and other information transfers to the Customer's host computer. For items of product type 04, the Distributor will order the item for the customer and have it sent to the customer. Consequently, the following information must be entered on the Non-Catalog Information data screen 80 for items of product type 04: vendor stock number and the vendor number (which corresponds to a particular vendor). These data are forwarded to the host computer 10 to be checked against or added to host database 20 (for products of price type 04, but not for products of price type 05). An error will result in "sourcing" this order if this information is not provided by the CSR or does not correspond to information in host database 20 for a non-catalog item. For items of product type 05, the CSR will create an order record or document ordering the item on behalf of the customer or confirming an order placed on behalf of the customer (e.g., by telephone to the designated vendor). For items of product type 05, the CSR may order the item for the Customer. These orders are not placed or filled using the system of the present invention, although data regarding these transactions may be entered on Non-Catalog Information data screen 80 to record these transactions. Instead, either the proposed purchase order record is uploaded into the customer's computer for processing or a document is printed at local printer 43 for signature and action by the customer's purchasing agent or the CSR confirms that the order has been placed with the designated vendor by some other means. Sourcing After all of the items for a requisition have been entered, the next step is that of sourcing the requisition. Sourcing the requisition is the process of determining what inventory will be used to fill the requisition. Pricing is also performed in this step when it is called for (e.g., for all product types except for 05 and 06). Sourcing, which is represented by step 88 in FIG. 2, is initiated by hitting the F6 key from the Requisition Management data screen 68 (or from Order Header data screen 60 or Non-Catalog Information data screen 80.) Sourcing is performed on both local computer 40 and host computer 10. Sourcing in the preferred embodiment of the system of the present invention can involve up to four different product types: 01--local Distributor-owned JIT items; 03--Distributor catalog items; 04--third-party items which are ordered by the Distributor; Type 06--Customer-owned JIT items. (Product type 05 comprises third-party items which are not sourced by the system of the present invention.) Any particular requisition may involve all of these product types, only a single product type, or any combination of product types. The product type which was determined when the STOCK NBR was entered on the Requisition Management data screen is now used to source the item. Items of product type 06 are sourced from the Customer-owned Inventory 54; items of product type 01 are sourced from Distributor-owned inventory 52. Sourcing for each item in the Requisition Item Table will be described in connection with FIGS. 4A through 4D. In step 220, the CSR hits the F6 (Source) key from Requisition Management data screen 68. In steps 221 and 224, the system checks the product type (in the PT field) of the item and routes control of the program according to that product type. If the item is of product type 03 or 04, control passes through point A 222 to the diagram shown in FIG. 4C. If the item is of product type 01 or 06, control passes to block 228. If the item is of product type 05, control passes to point B 226. The processing of transactions of product type 05 by the preferred embodiment of the system of the present invention is of a record keeping nature. In the steps represented by point B 226, the CSR enters the relevant data regarding the transaction and the data are stored in local database 50 in the same manner as data relating to the other product types described herein. The data may then be uploaded periodically to the Customer's host computer. In the case where the item has product type 01 (an item owned by Distributor in JIT facility 51), local computer 40 will prepare and send to host computer 10 a block of data including the stock number (STOCK NBR), product type (PT), warehouse location code (LOC), the requisitioned quantity (QTY), the quantity available at the JIT facility 51 and header data, as shown in step 230. The header data includes at least the account number and requisition number. Local computer 40 then waits for host computer 10 to transmit a block of data in response to the transmission of local computer 40, as shown in step 232. Local computer sends the block of data via the communication linkage described in connection with FIG. 1. At host computer 10, the data sent by local computer 40 is received as shown in step 250 of FIG. 4B. Most computer 10 first uses the warehouse location code (LOC) and the stock number (STOCK NBR) to access host database 20 to determine what the host's records show for the quantity available at the relevant location for the item being requisitioned, as shown in step 252. The host's quantity available is compared to the received quantity available (QTY AVAIL) to determine if they match, as shown in step 256. If the quantities are not the same, host computer 10 creates a data block including an inventory match error code, as shown in step 258. This data block will then be transmitted back to local computer 40 via the communication link, as shown in step 272. This insures that the host and local databases are in agreement as to the quantity of an item in JIT facility 51 which is owned by the Distributor. If, however, the host computer's 10 quantity available does match that in the received QTY AVAIL field, in step 256, host computer 10 then determines if the quantity available (QTY AVAIL) is equal to or exceeds the requisitioned quantity (QTY), as shown in step 260. If the quantity available is equal to or exceeds the quantity requisitioned, host computer 10 then prices the item, as shown in step 268 (using the program represented by block 96 of FIG. 2B). Any conventional algorithm or data structure may be employed by host computer 10 for determining the net price per unit of a particular Distributor product sold to a particular Customer as shown in step 268. Such pricing may be based, for example, on Distributor's list price and a percentage discount off that list price negotiated between Distributor and Customer and recorded in host database 20 for that product type. As is described below, the net price per unit is sent from host database 20 through the communications link to the local computer 40 for entry into a previously blank field in the Requisition Item Table. If the quantity available is determined to be less than the quantity requisitioned in step 260, host computer 10 then creates a warning message indicating a proposed backorder for a quantity equal to the difference between the quantity requisitioned (QTY) and the quantity available (QTY AVAIL). As will be discussed below, the CSR need not accept this backorder. Host computer then proceeds with pricing step 268. After pricing is complete, host computer 10 creates a data block including the information regarding any backordered quantities of the item and the net price per unit of the item, as shown in step 270. This data block is then transmitted to local computer 40, as shown in step 272. In block 234 of FIG. 4A, local computer 40 receives the data block transmitted from host computer 10. Local computer 40 will preferably remain in wait state 232 for only a fraction of a second, so that the display on monitor 41 will appear to be updated almost instantaneously to the CSR. The data (relating to pricing and backorder quantity) received from host computer 10 is then used to update the relevant line entries in the Requisition Item Table as shown in step 234. If an error code is found in the received data, local computer 40 displays Requisition Management data screen 68 with the relevant error code. A list of the various error codes and warning codes which local computer 40 can cause to be displayed is attached at Table XXIV. Only some of the three digit codes are applicable to the Requisition Management data screen 68. The CSR may now take steps to reconcile the values of stock on hand in JIT facility 51 for the requested item of product type 01 before sourcing of the line can proceed further. (For example, the CSR may attempt to adjust the inventory for this product, as will be described in detail below.) If no error codes are found in the transmitted data, local computer 40 will display Requisition Maintenance data screen 108 on monitor 41 as shown in step 237. (A sample Requisition Maintenance data screen is set forth in Table IV.) Requisition Maintenance data screen 108 will display the price transmitted by host computer 10 (UNIT PRICE) and any quantity which host computer 10 has proposed to place on backorder (QTY BCKORD). In addition to displaying the relevant quantities in the Requisition Item Table, local computer 40 also assigns a status code to each line of a requisition and displays it in the STATUS field in Requisition Maintenance data screen 108. The possible status codes and the algorithm for assigning them to a line of a requisition will be discussed in detail below. If the entire requisition has been sourced, control then passes to block 245, where the system will cause a picking list to be printed out (as shown in step 246) on printer 43 if the CSR hits the F2 (Accept) key. This completes sourcing for an item of product type 01. For items of product type 06 (an item owned by the Customer in JIT facility 51), sourcing does not require communication with host computer 10. Thus control in FIG. 4A passes from block 228 to block 240, where local computer 40 determines whether the quantity of the item requisitioned (QTY) is equal to or exceeds the quantity available (QTY AVAIL). If the quantity available is determined to be less than the quantity requisitioned in step 240, local computer 40 then creates a proposed backorder in step 242 for a quantity equal to the difference between the quantity requisitioned (QTY) and the quantity available (QTY AVAIL). As will be discussed below, the CSR need not accept this backorder. Local computer 40 then proceeds with step 244 (as it would if the quantity available is equal to or greater than the quantity requisitioned.) In step 244, local computer 40 display Requisition Maintenance data screen 108 on monitor 41, which will display any quantity which local computer 10 has proposed to place on backorder in addition to the relevant data in the Requisition Item Table. Local computer 40 also assigns a status code to each line of a requisition and displays it in the STATUS field in Requisition Maintenance data screen 108. Control then passes to block 245, where the system will cause a picking document to be printed out (as shown in step 246) on printer 43 if the CSR hits the F2 (Accept) key. This completes sourcing for an item of product type 06. The picking list can be used by suitable personnel to pick the required items of product type 01 or 06 from JIT facility 51. The quantities picked are then entered onto the picking document and compared by the CSR to the quantities shown. If the quantities agree, the CSR can accept the order by hitting the F2 key again, as will be discussed below. Thus sourcing for product types 01 and 06 is similar except that, for product type 06, there is no verification with the host computer 10 as there is with product type 01. The steps performed in the sourcing of product types 03 and 04 are described in FIGS. 4C and 4D. If local computer 40 determines that the items in a requisition line being sourced have product type 03 or 04, control passes from block 221 in FIG. 4A through point A 222 to decision block 280 shown in FIG. 4C. If the product type is 03, control then passes through decision block 280 to block 282. In block 282, local computer 40 creates and sends to host computer 10 a data block containing the stock number, product type (which is 03 in this case), quantity requisitioned and header information as discussed in connection with the sourcing of product type 01. Local computer 40 then waits for data to be received from host computer 10 as shown in step 284. If, on the other hand, the product type is 04, control then passes through decision block 280 to block 286. In block 286, local computer 40 creates and sends to host computer 10 a data block containing the stock number, product type (which is 04 in this case), quantity requisitioned, non-catalog item data (the vendor number and the vendor catalog number of the item) and header information as discussed in connection with the sourcing of product type 01. Local computer 40 then waits for data to be received from host computer 10 as shown in step 288. The sourcing of product types 03 and 04 at host computer 10 is described in connection with FIG. 4D. In step 300, host computer 10 receives a data block from local computer 40. By accessing the product type (PT) field for a given line in a received block of requisition data, host computer 10 can readily determine the product type of that line. Assuming that the line is of product type 03, control passes through block 301 to decision block 302. In block 302, host computer 10 determines if the received stock number (STOCK NBR) for the line of requisition data block being processed is a valid Distributor catalog number. Host computer 10 performs this action by comparing the stock number (STOCK NBR) to series of databases described below in connection with cross referencing containing all valid catalog numbers which are stored in host database 20. If the stock number is not recognized, host computer creates a data block with an unrecognized product error code in step 304. This data block is transmitted to local computer 40 in step 312. If, however, the stock number is recognized as corresponding to a valid Distributor catalog number, host computer 10 sources (using the transmitted QTY) and prices the line of the requisition in steps 306 and 308. Sourcing may be performed in a conventional manner. Host computer 10 has access to host database 20 which includes information regarding the price and quantity available in the Distributor Warehouse 30 and each other Distributor Warehouse of each particular item stocked by the Distributor. Host database 20 also includes coding for items to be direct-shipped from a regular vendor 37. For pricing, the Distributor may employ a separate discount table for each customer account, to automatically provide net prices of items that have been negotiated with each particular customer. Thus any suitable conventional algorithms may be employed by the host computer 10 for sourcing and pricing items of product type 03. The pricing algorithm employed for those items of product type 03 can also be the same algorithm employed for items of product type 01 which are regular Distributor products. In step 310, host computer 10 creates a data block containing at least the net price per item, a code identifying the location of the inventory used in sourcing, and the quantity of the item available at that location. This data block is transmitted to local computer 40 in step 312. As noted above, items of product type 04 are also sourced by the preferred embodiment of the system of the present invention. As to these items, the Distributor is providing the service of ordering the item(s) for the customer to simplify requisitioning and other administrative flow such as accounts payable management for the customer. The Distributor may not provide this service as to all third-party vendors, however, as will be discussed below. If the product type of the line of the requisition being processed is 04, control passes through decision block 301 to decision block 316. In block 316, host computer 10 determines if the received vender number (VENDOR NBR) for the line of requisition data block being processed is a valid vendor from which Distributor will order items for shipment to the Customer. Host computer 10 performs this action by comparing the vendor number to a database containing all valid vendor numbers which is stored in host database 20. If the vendor number is not valid, host computer 10 creates a data block with an unauthorized vendor error code in step 318. This data block is transmitted to local computer 40 in step 312. If the vendor number is determined to be valid in step 316, control passes to decision block 320. In block 320, host computer 10 determines if the received vendor catalog number (VENDOR CAT NBR) for the line of requisition data block being processed is a valid vendor catalog number which Distributor will order (from the relevant vendor) for shipment to the Customer. Host computer 10 performs this action by comparing the vendor catalog number to a database containing all valid vendor catalog numbers which is stored in host database 20. If the vendor catalog number is not valid, host computer creates a data block with an invalid product warning code (see code 500 in Table XXIV) in step 322. This data block is transmitted to local computer 40 in step 312. The host computer 10 then prices the item in step 324 using any conventional algorithm or method. A data block is then created containing the price information in step 328, and this data block is transmitted to local computer 40 in step 312. When local computer 40 receives a data block from host computer 10 in response to its previous transmission of a data block to the host, local computer 40 updates the Requisition Item Table for the relevant line (or lines) as shown in block 290 of FIG. 4C. As in the sourcing of items of product type 01, if an error code is received, local computer 40 displays Requisition Management data screen 68 with the relevant error code on monitor 41, as shown in step 294. At this point the CSR can evaluate the error for possible mistaken entry of the stock number, vendor code or vendor catalog number depending on the error code received; the CSR can then manually correct the error and resource the item. In the case of an invalid vendor error code, the CSR can contact the Distributor's central purchasing department for evaluation of adding a new vendor. If the CSR determines that the Distributor will not purchase from this vendor, he can change the product type to 05. In the case where the vendor code is found in host database 20, but the vendor catalog number is not (i.e., where warning code 500 is received), the CSR may attempt to contact the Distributor so as to establish the product as a non-catalog special in host database 20 which can then be obtained as a type 04 product. If, however, no error codes are received, local computer 40 displays Requisition Maintenance data screen 108 with the pricing data (and inventory data, for products of type 03) transmitted by host computer 10. As noted above, items of product type 05 are not sourced using the preferred embodiment of the system of the present invention. It will be noted that the above discussion of sourcing in FIGS. 4A through 4D has been in the context of requisition for a quantity of a single product (stock number). In the preferred embodiment of the present invention, requisitions having several lines, each of which is for a different item (having a different stock number) can be sourced at one time (i.e., by hitting the F6 key once). As will be clear to those of ordinary skill in the art, where more than one item is requisitioned in a single requisition, data block transmission and the printing of picking documents will preferably occur only after all items in the requisition have been processed. Thus, for example, if a requisition contains several items of product type 01, only one data block need be transmitted from local computer 40 to host computer 10, host computer 10 need transmit only one data block in reply to local computer 40, and only one picking document need be printed out. The data blocks will preferably contain the requisition line number of each requisitioned stock number, in addition to the data discussed above for each stock number. The status codes which appear in the STATUS field of each line on Requisition Maintenance data screen 108 will now be discussed. The status of a line begins as "R" (Requisitioned) when the line item is first created on Requisition Management data screen 68. After sourcing, the status of a line becomes "S" (Sourced). After acceptance of a sourced requisition, the status can change to "F" (Filled), "B" (Backordered), "P" (In Process) or "C" (Canceled). If there is sufficient inventory at the relevant location (which depends on the product type of the requisitioned item) to supply the requisitioned line item, the line will have the status of Filled. If there is not sufficient inventory at the relevant location to supply the requisitioned line item, the line will have the status of Backordered. If the CSR determines that such a backorder is unacceptable to the requisitioner, he can source the item elsewhere: e.g., an item carried at the JIT as type 01 can be changed for this order to an 03 and ordered from warehouse 30 for direct shipment to the requisitioner. Similarly, the CSR can look for the inventory at other Distributor warehouses if it is not currently available at the JIT facility 51 or at warehouse 30. A line having the status of In Process is one that has been sourced, but communications between the host computer 10 and local computer 40 were somehow interrupted while local computer 40 was awaiting a response from the host computer 10 during the acceptance process described below. Generally this will occur, when it does happen, for all of the line items in a single requisition. Lines having a status of In Process will eventually become either Filled or Backordered, as described below. A line will have the status of Canceled if the CSR cancels the line item prior to acceptance, by hitting the F12 key from Requisition Maintenance data screen 108. Thus only a line having a status of Requisitioned or Sourced may be canceled. Line items having the status of Filled or Backordered will have the status of Delivered ("D") when the items have been received and the receival is entered (as described below). Local computer 40 updates the status of each line in Requisition Item table consistent with the manner described herein. Orders having the header status (shown in the ORDER STATUS field of Order Header data screen 60) of Requisitioned or Sourced may be cancelled by hitting the F12 key from Order Header data screen 60. (An order has a header status of Requisitioned or Sourced if all of the line items in that order have the status of Requisitioned or Sourced.) A canceled order will have a "C" code in the ORDER STATUS field. Prior to acceptance, the CSR can also decrease the quantity requisitioned QTY of any line on Requisition Maintenance data screen 108. Acceptance The CSR can accept all lines of the requisition if all lines have a status of Sourced by hitting the F2 key to ACCEPT. However, as discussed above, if the requisition includes items sourced from JIT facility 51 (i.e., items of product types 01 or 06), hitting the F2 key the first time causes local computer to print a picking document out as described in step 246 of FIG. 4A. This permits suitable personnel to pick the required items of product type 01 and 06 from the JIT facility 51. The quantities picked are then entered onto the picking document and compared by the CSR to the quantities shown. If the quantities agree, the CSR can hit the F2 key again to accept the requisition. If the quantities do not agree (e.g., due to breakage of one or more of the items in JIT facility 51), the CSR can go to the Inventory Adjustment data screen and adjust the inventory as described in detail below. If, on the other hand, there are no type 01 or type 06 lines on the particular requisition, then hitting the F2 key for the first time will accept the requisition. In either event, accepting the requisition (by hitting the F2 key once or twice) causes control to be passed to the Purchase Order Build program 112 (shown in FIG. 2A). As described in the diagram FIGS. 5A and 5B, for items of product types 01, 03 and 04, local computer 40 uses Purchase Order Build Program 112 to create a purchase order between the Customer and the Distributor from the data in the Requisition Header and Item Tables. For items of product type 06, a Purchase Order record internal to the Customer may be created at this stage, recording a sale from the Customer's purchasing department to the requisitioning department or account, for later use by the Customer's host computer in making accounting adjustments. In the case of items sourced from JIT facility 51 (items of product type 01 or 06), the inventory records will be adjusted accordingly as described below. As shown in FIG. 5A, after the CSR accepts the requisition in step 330, local computer 40 updates the STATUS field of the Requisition Item Table for the relevant lines with the status code of "P" or In Process in step 331. This code will preferably remain visible on Requisition Maintenance data screen 108 for only a fraction of a second, before it is replaced with another status code as discussed below. In step 332, local computer 40 then checks the product type of the requisition line item by accessing the product type (PT) field of the Requisition Item Table for that line. (As with the discussion of sourcing, FIGS. 5A and 5B describe the acceptance of a single line item for the sake of clarity.) In the preferred embodiment of the present invention, a typical requisition will often have several line items. In that event, the entire requisition is processed line by line by the respective computers before transmitting data to the other computer. Similarly, only one purchase order is generated for the requisition. If the line item has a product type of 06, control is passed to block 334. As shown in steps 334 and 336, a Purchase Order record internal to the Customer may (at the option of the Customer) be created and printed out on printer 43 at this stage, recording a sale from the Customer's purchasing department to the requisitioning department or account. This internal purchase order can be used by the Customer's host computer in making accounting adjustments. Since the implementation of such an internal sale will vary depending on the Customer's own accounting software in a manner easily understood by one skilled in the art, these steps will not be further described here. Regardless of whether or not such an internal purchase order is created for the Customer, control then passes through decision block 352 (as the product type is 06 in this case) to block 354. In block 354, the quantity on hand (QTY ON HAND) field of the Plant Location Table for the relevant part number (PART NUMBER) in local database 50 is reduced by the requisitioned quantity (QTY) for the relevant line in the Requisition Item Table (which is also in local database 50). At this point, control passes to block 356, where the local computer updates the status (STATUS) field of the relevant line of the Requisition Item Table to "F" for Filled. The display on Purchase Order Maintenance data screen 108 is also updated at this time. If, on the other hand, the line item has a product type of 01, 03 or 04, control is passed from block 332 in FIG. 5A to block 338. In step 338, local computer 40 creates and transmits to host computer 10 a purchase order data block containing at least the customer account number (ACCT-NBR) and Requisition Number (REQ NBR) from the Requisition Header Table and 10 the line number (LINE), item stock number (STOCK NBR), quantity to be purchased (QTY), unit of measure (UM), product type (PT), net unit price (UNIT PRICE) and net total price (EXT PRICE) from the Requisition Item Table. If the product type is 01, the purchase order data block will also include an identification code for the JIT facility 51 (WHSE) and the quantity of the item available at that facility (QTY AVAIL). If the product type is 04, the purchase order data block will also include the vendor number (VENDOR NBR) and vendor catalog number (VENDOR CAT NBR) entered into the Requisition Item Table from Non-Catalog Information data screen 80. As noted above, the purchase order data block created in step 338 may have multiple lines with the associated data described above for each such line. After the purchase order data block described in step 338 is transmitted to host computer 10 over the data link described above, local computer 40 waits for a response from the host, as shown in block 340. The acceptance of a purchase order on host computer 10 is described in connection with FIG. 5B. In block 360, host computer 10 receives the purchase order data block transmitted from local computer 40. Receipt of a purchase order data block by host computer 10 causes the host to initiate host Purchase Order program 120 shown in FIG. 2B. In step 362 shown in FIG. 5B, host Purchase Order program 120 validates the data received in the purchase order data block. In the validation step, host computer 10 checks the customer account number, item stock number (using the product type information to determine what database in host databases 20 to search) and the price against the relevant information in host database 20 to validate the data in the received purchase order data block. If the item is of product type 01, host computer 10 also validates the identification code for the JIT facility 51 and the quantity of the item available at that facility (by comparing this data to the relevant entry in the table in host database 20 which indicates the quantity of each Distributor-owned item in JIT facility 51) in step 362. If any of the validation checks performed in step 362 failed, control passes to block 364 where host computer 10 creates a data block with the appropriate error code or codes (e.g., invalid stock number or vendor). This data block is then transmitted to local computer 40 in step 374. If none of the validation checks performed in step 362 fail, host computer 10 executes the purchase order as shown in step 366 of FIG. 5B using the Order Creation program 126 shown in FIG. 2B. Note that control passes through decision block 124 in FIG. 2B to the Order Creation program 126 because this is a new purchase order. Host computer 10 recognizes that local computer 40 is requesting that a purchase order be created because the purchase order data block received by the host computer 10 includes a code instructing the host computer 10 to process the data block as a purchase order, as opposed to as a confirmation inquiry. As to items of product type 03 or 04, the execution of the purchase order by the host computer 10 in step 366 may be performed by any conventional means for arranging shipment of the item(s) from the Distributor Warehouse 30 or from the facility of a vendor (37 or 38), depending upon whether the type 03 or 04 product is routinely stocked by the Distributor. For type 03 and type 04 products, the host computer 10 will also cause an invoice to be created in step 366, billing the customer by EDI, in paper form or otherwise, but not necessarily involving the local computer 40 or the communications link provided to it. When the Customer's host computer receives that invoice (directly via EDI or indirectly otherwise), it can compare the invoice with the purchase order data that has, by then been uploaded from the local computer 40 (e.g., as a flat file). If the product type is 04, host computer 10 verifies the vendor part number. If the part number is found, host computer 10 executes the order in step 366 by generating a proposed purchase order to the vendor and creates a data block including a status code of "B" (Backordered) for transmission to local computer 40. The Distributor's purchasing department will then verify that order (e.g., verifies that the pricing is correct) and generate a purchase order to that vendor. If, during verification, host computer 10 does not find the vendor part number, host computer 10 also creates a part record in the host database 20 when it creates the proposed purchase order to the vendor. The Distributor's purchasing department then verifies the information in the part record and issues the purchase order to the vendor as described above. For items of product type 01 (local JIT inventory), the customer is billed for the items in step 366 as with any item ordered from the Distributor. Host computer 10 next checks to determine whether the purchased item is of product type 01 in step 368. If the item is of product type 01, control passes to block 370, where host computer 10 updates the relevant entry (which is determined by the stock number of the purchased item) in the relevant table (which is determined by the location code for the JIT facility 51) in host database 20. Host computer 10 updates the relevant entry with a new quantity on hand, which is obtained by subtracting the quantity purchased from the old quantity on hand found which host computer 10 finds at that table entry. Control then passes (either directly from block 368 or from block 370) to block 372, where host computer 10 creates a confirmation data block to transmit to local computer 40. As shown in FIG. 2B, confirmation is performed by the host Purchase Order Confirmation program 128 (control having passed from Order Creation program 126 through decision block 124). Host computer 10 adds information including the Distributor order number, line item status codes and any error or warning codes (see Table XXIV) to the confirmation data block. In step 374, the confirmation data block is transmitted to local computer 40. In step 344, local computer 40 receives the confirmation data block from host computer 10. If any error codes are found in the received data block, control then passes through block 348 to block 356. In step 356, local computer 40 updates the Requisition Item Table and the display shown on Requisition Maintenance data screen 108 with (in this case) the information, including error codes, found in the received data block. Any line items generating error codes will have the status of canceled. The CSR will have to create a new requisition with corrected entries corresponding to the canceled lines to requisition these items. If no error codes are found in the data block received from host computer 10, control passes through block 348 to block 350, in which local computer 40 directs printer 43 to print out a purchase order acknowledgment (unless no acknowledgment of the requisition was requested on Order Header data screen 60). The printed purchase order acknowledgement may employ any conventional form using data found in the Requisition Header and Item Tables. In steps 352 and 354, local computer 40 updates the relevant data in local database 50 to reflect the removal of purchased products of product type 01 from JIT facility 51. This step is performed in the same manner as discussed above in connection with items of product type 06. The on hand quantity in the relevant Plant Location Table entry is reduced by the amount of the item purchased, as discussed above. For items of product type 01, step 354 insures that host database 20 and local database 50 will indicate the same on hand quantity of this item. Control then passes to step 356, where (in this case) local computer 40 will update the STATUS field in the Requisition Item Table and the display shown on Requisition Maintenance data screen 108 to reflect receipt of the confirmation data block. The Distributor order number is also added to the Requisition Item Table and is displayed on Requisition Maintenance data screen 108 in the ORDER NBR field. If a line item (of product type 01 or 06) has any quantity on backorder, the status of that line will be a "B" for Backorder until the stock at JIT facility 51 is replenished. For line items of product type 01 or 06 where there is no backordered quantity, the status will now be "F" for Filled. For line items of product type 03 or 04, the status will now be "F" for Filled, "B" for Backordered or "C" for Canceled (e.g., if the product was discontinued) depending on the status code received in the data block. If the communication link between local computer 40 and host computer 10 is interrupted shortly after the CSR accepts an order, the status of a line item may remain at "P" for In Process. If this is the case, the CSR may (after the communication link is reestablished), hit the F10 key while at Requisition Maintenance data screen 108. This causes a confirmation inquiry data block (containing the Purchase order number, Account number, line numbers, the date and time) to be created by local computer 40 using the Purchase Order Confirmation program 116 (shown in FIG. 2A) and transmitted to host computer 10. When host computer 10 receives this confirmation inquiry data block, it is passed by host Purchase Order program 120 (shown in FIG. 2B), through decision block 124 to Purchase Order Confirmation program 128. Most computer 10 recognizes this data block as a request for confirmation of a previously submitted requisition because of a code in the data block which instructs host computer 10 to process the data block using Purchase Order Confirmation program 128. Purchase Order Confirmation program 128 directs host computer 10 to send a confirmation data block to local computer 40 just as described above. The receipt of this confirmation block is as described above, and will alter the status code of the Requisition Item Table. The function of the F11 key from Requisition Maintenance data screen 108 is very similar to that of the F10 key, except that the F11 key relates to purchase orders for items of product type 01 or 06 that have been filled through backorder allocation. By hitting the F11 key (where the status of the line is Backorderd), host computer 10 transmits a backorder inquiry data block including the Customer Account Number, Requisition Number, line numbers, date and time to host computer 10. As described above in connection with a confirmation inquiry, when host computer 10 receives the backorder inquiry data block, it checks host database 20 to determine whether or not the backordered order has been filled and sends a backorder confirmation data block to local computer 40 similar to that described above. The receipt of this confirmation block will update the status code of the Requisition Item Table from "B" to "F" if the status has changed. As discussed above, Requisition Maintenance data screen 108 indicates, for each line, the quantity of an item that has been delivered or received (QTY REC) as well as the quantity of the item on Backorder (QTY BCKORD). When items are received from either the Distributor or a third-party supplier into the JIT facility 51, the CSR can use Requisition Maintenance data screen 108 to enter the receivals. By hitting the F5 key while the cursor in on the appropriate line, the CSR can change the value of the quantity received (QTY REC) to reflect shipments that have been received. Once all of the items in that line have been received, the status code will change to "D" for Delivered. Similarly, a backordered quantity (QTY BCKORD) will be reduced by the amount received once the various purchase or transfer orders for the items that were on backordered status are filled. If all Backordered items for a line of a requisition of ORDER TYPE "T" (which is generated to restock Customer-owned JIT inventory 54, as discussed below) are received, the status of that line will automatically be changed to Delivered by local computer 40. Hitting the F9 key from Requisition Maintenance data screen 108 allows the CSR to go to Print Driver data screen 118, a sample of which is shown in Table XV. Print Driver Screen 118 enables the CSR to print extra copies of order acknowledgments (F2), Bills Of Lading (F4), Picking Lists (F5) and Packing Lists (F6), to the extent that these documents are relevant to the requisition at issue. As discussed above, the Requisition Header and Item Tables for a given requisition are stored in local database 50, where they remain after until they are deleted by the CSR. The data relating to a particular requisition can thus be subsequently retrieved for further review or updating. The data in the Requisition Header Table, Requisition Item Table and customer variable tables (associated with the customer variable data screens) may also be periodically uploaded to the Customer's host computer, e.g., as a flat file. Inventory Maintenance Inventory records for items in JIT facility 51 are created using the Part Master data screen, an exemplary screen being set forth in Table VI. To add an item to local inventory, the CSR enters an "A" (for Adding a record) in the ACTION CODE field, a Part Number, Product Type and Product Used indication. Fields are also provided for a Description, standard and alternate units of measure, list price, standard cost and current cost and information relevant to shipping the product (e.g., Hazardous Material code, Safety Data code, Bill Of Lading code, etc.). Distributor's current cost is what it would cost Distributor to purchase the item today. Distributor's standard cost is the cost upon which Distributor's gross margin is calculated and may differ (e.g., because of inventory on-hand that was purchased previously at a lower cost). This cost information, which is periodically downloaded from the host database 20, is for use by the CSR. Other Action Codes the CSR may enter include "D" (Deleting a part record), "M" (Modifying a part record) and "I" (Inquiring, to permit the CSR to view information on the host database 20 without adding or changing the information in local database 50.) If the item being entered is of product type 06 (Customer-owned JIT inventory), the CSR will also enter a code in the CUST OWNED PROD TYPE field to indicate how the item will be restocked. There will preferably be a different code for each of the possible manners of restocking the product, i.e., as a requisition of an item of product type 03, 04 or 05. The manufacturer part number can then be added in the adjacent field, if appropriate (i.e., if the underlying item is not purchased from the Distributor). If the item has product type 03 for restocking purposes, the CSR can enter a code to identify the Distributor warehouse that will normally used to replenish the JIT inventory in the T/O SOURCE WHSE field. If the Distributor normally has the an item of product type 04 direct shipped to its Customers from a vendor 37, that can be so indicated in the STOCK POLICY FIELD. Other possible entries in that field include codes to indicate, if the item is of product type 03, which of the Distributor warehouses should be searched in sourcing the item. One such code might indicate that the item should be shipped from only a particular warehouse, and backordered if it is not found at that location. Another such code might indicate that the item should be shipped from only one of two particular warehouses, and backordered if it is not found at either of those locations. If no code is entered, the general sourcing rules of the Distributor (which may employ searching several warehouses in a predetermined order) will be used. The specific algorithms employed in connection with these STOCK POLICY codes are well known to those of ordinary skill in the art and thus are not described in detail here. The ABC CLASS field, on the other hand, which includes information downloaded from host database 20 when the Part Master record is added to local database 50, indicates the Distributor's stocking policy for the item. Thus different codes in this field may indicate that the item is stocked in all Distributor warehouses, some Distributor warehouses, or few or no Distributor warehouses. This information is intended to aid the CSR in assessing alternatives for obtaining backordered items. To enter any changes into the Part Master Table on local database 50, the CSR must first hit the Enter key, so that local computer can validate the entered information by determining if sufficient information has been entered. (That is, if the CSR has entered at least a valid ACTION CODE, a PART NBR, a PROD TYPE and a USED IND.) If the CSR has entered the required information, local computer 40 displays a message prompting the CSR to confirm the update by hitting the F11 key. The action that follows the CSR's hitting the F11 key (Confirm Update) depend on the information the CSR has entered. If the product type of the item is 01, it may be restocked from Distributor's regular catalog items. Thus when the CSR hits the F11 key local computer creates a data block including the Account Number, location code, action code, part number and product type indication for transmission to host computer 10. The host computer 10 compares the received part number to its master database of Distributor catalog items, and if it finds a match, creates a data block using the data in the master database (which is in host database 20) to send back to local computer 40. The data block transmitted by host computer 10 to local computer 40 includes data to fill in many of the fields shown on the Part Master data screen which the CSR has not himself filled in, such as the DESCRIPTION, price data, STD UNIT, ABC CLASS etc. Local computer 40 then uses the information in the received data block to add a new entry in the Part Master Table stored on local database 50 for the item. If the item being updated on the Part Master data screen is of product type 06, the confirmation of the update depends on how the product is to be restocked (which corresponds to the indicator in the CUST OWNED PROD TYPE field). If the item is to be restocked as an item of product type 03, the confirmation of the update proceeds essentially as described above for items of product type 01, except that host computer 10 does not create a new entry in a part master table for the relevant JIT facility 51 in host database 20 (as host computer 10 will only be tracking Distributor-owned inventory 52 in JIT facility 51.) If the item being updated on the Part Master data screen is of product type 06, and the item is to be restocked as an item of product type 04 or 05, there is no data block transmitted to host computer 10. Rather, local computer 40 simply adds an entry to the Part Master Table in local database 50 for the item. The CSR must, however, have added a manufacturer part number, else an error message will be generated. After entering the information in the Part Master Data screen, the CSR can hit the F5 (PLANT) key to go to the Plant Location data screen, a sample of which is set forth in Table VII. This data screen provides access to the Plant Location Table in local database 50. In creating a new entry in the Plant Location Table, the CSR enters the MAX ORDER QTY, MIN ORDER QTY and the REORDER POINT, which are described in Table 2:
TABLE 2
______________________________________
FIELD NAME DESCRIPTION
______________________________________
MAX ORDER QTY Maximum quantity to be ordered in
replenishment
MIN ORDER QTY Minimum quantity to be ordered in
replenishment
BACK ORDER QTY Quantity of item presently on
backorder
REORDER POINT When the quantity on hand less any
allocated quantity falls below the
reorder point, the system will
recommend a restocking order during
replenishment.
QTY ON HAND Quantity in local warehouse
QTY ON ORDER Quantity on order
ALLOCATED QTY The allocated quantity is the
quantity reserved in the local
database for a particular
requisitioner. The quantity on
hand less any allocated quantity is
the quantity available to other
requisitioners.
______________________________________
The remaining data in Table 2 (BACK ORDER QTY, QTY ON HAND, QTY ON ORDER and ALLOCATED QTY) will be tracked and updated by local computer 40 as described herein. If the product type is 01, after initial validation by local computer 40 when the CSR hits the Enter key, hitting the F11 key from the Plant Location data screen causes local computer 40 to create a data block using the part number, location identification code and information entered on the Plant Location data screen. This data block is then transmitted to host computer 10, which confirms the data and creates a new entry in its plant location table for the relevant JIT facility location with the transmitted data. Host computer 10 then transmits a confirmation data block to local computer 40 (if there were no errors), which adds an entry to the Plant Location Table in local database 50 using the information displayed on the Plant Location data screen. If the product type is 06, no data block is created and transmitted to host computer 10. Rather, local computer 40 just adds an entry to the Plant Location Table in local database 50 using the information displayed on the Plant Location data screen. Using the Part Master and Plant Location data screens, the CSR builds item records for all items in local inventory, whether of product type 01 or 06. The Customer Account Maintenance data screen (set forth in Table XIII) is also used by the CSR to provide local database 50 with customer account data which is utilized in the order header of a requisition. For items of product type 01, the data on local database 50 are also sent to host computer 10, where a data file reflecting the contents of JIT inventory (product type 01) is created. From time to time, the CSR may need to adjust the value of the quantity on hand of a particular item in JIT facility 51. This can done using the Inventory Adjustment data screen, a sample of which is set forth in Table VIII. Using the Inventory Adjustment data screen, the CSR may adjust the quantity of an item of product type 01 or 06 up or down by entering PART NUMBER, PLANT CODE (which identifies the JIT facility), TOTAL BIN QTY (the quantity in the relevant bin in JIT facility 51) and the amount of the adjustment in the PLUS or MINUS fields under the ADJUSTMENT QTY heading. The CSR must also enter a REASON CODE indicating the reason for the adjustment in the appropriate field. Exemplary reason codes are set forth in Table 3:
TABLE 3
______________________________________
Reason
Code Description
______________________________________
01 Product Writedown
-- New Part To Used Part
02 Product Writedown
-- Soon To Expire Product
10 Expired Material
20 Warehouse Breakage
-- Customer Shipment
21 Warehouse Breakage
-- Claims
22 Warehouse Breakage
-- Vendor Refurbishing
23 Warehouse Breakage
-- ISD Refurbishing
24 Warehouse Breakage
-- Sundry
25 Loss And Damage
-- Warehouse Breakage
52 RIMS Stock Return To Host Warehouse
90 Physical Inventory Adjustment
91 Transfer Order Misshipments
92 Scrap Of Dead Or Excess Inventory
______________________________________
Once the CSR has entered the required information and hit the Enter (Return) key, local computer 40 validates the entered PART NUMBER and TOTAL BIN QTY by using the PLANT CODE to reference the relevant entries in the Part Master and Plant Location Tables in local database 50. Local computer 40 also checks to see if a negative ADJUSTMENT QTY exceeds the quantity on hand (which should be the same as the TOTAL BIN QTY). If validation fails, local computer 40 prompts the CSR with an appropriate error message, and the CSR may again try to make the adjustment. For example, in the screen shown in Table VIII, the error message "Part Master Record Not Found" is displayed one line from the bottom of the data screen. If there are no errors in validation, local computer 40 prompts the CSR to update the JIT inventory records (which will be done by altering the QTY ON HAND for the relevant entry in Plant Location Table local database 50) by hitting Enter. When the CSR hits enter, local computer 40 executes the program shown in FIG. 6A. After the CSR hits Enter (which is shown in step 380) local computer 40 checks the product type of the item (which is in the Part Master Table) to determine whether it is 01 or 06, as shown in step 381. If the product type of the item is 06, local computer proceeds to step 392 where the QTY ON HAND in the Plant Location Table for the adjusted item is modified to add or subtract the Adjustment Quantity as appropriate (depending upon whether the CSR entered the Adjustment Quantity in the PLUS or MINUS field. If, however, the product type of the item is 01, control passes to block 382, where the local computer creates a data block including the JIT location code (PLANT JIT SITE in the Plant Location Table), the PART NUMBER, the TOTAL BIN QTY, the Unit of Measure and the ADJUSTMENT QTY (all entered onto the Inventory Adjustment data screen). The REASON CODE may also be added to this data block if this information is desired by the Distributor. This data block is transmitted to host computer 10 in step 384. Local computer 40 then waits for a response, as shown in block 385. The processing of the JIT inventory adjustment by host computer 10 is shown in FIG. 6B. In step 400, host computer 10 receives the adjustment data block from local computer 40. In step 402, host computer validates the data received in step 400. In this step, host computer 10 checks host database 20 to determine if the PART NUMBER and PLANT CODE are valid (i.e., if host database 20 includes corresponding records.) Host computer 10 then changes its entry for the quantity on hand in the corresponding reflection records stored in host database 20 for the relevant JIT facility to match the received TOTAL BIN QTY. Host computer 10 also validates the REASON CODE, if this code was received in the transmitted data block. The validation of the REASON CODE may employ any conventional algorithm. If any of the validation checks fails, an error data block is created with an appropriate error message, as shown in step 404. This data block is then transmitted to local computer 40, as shown in step 410. If no error is detected in validation step 402, control passes to step 406. In step 406, host computer 10 adjusts the entry for the quantity on hand in the corresponding JIT inventory reflection records stored in host database 20 for the relevant JIT facility. An adjustment confirmation data block is then prepared in step 408. This data block includes an indication of the result of the adjustment, or an error code if the adjustment was not made. This data block is transmitted to local computer 40 in step 410. Local computer 40 receives the data block transmitted by host computer 10 in step 386, shown in FIG. 6A. In step 388, local computer 40 checks to see if there are any error codes in the received data block. If an error code is detected, control passes to block 390, where the appropriate error message is displayed on the Inventory Adjustment data screen. If, on the other hand, no errors are detected, control passes from block 388 to block 392, where local computer 40 adjusts the quantity on hand of the relevant entry of the Plant Location Table in local database 50. Periodically, requisitioned goods distributed from JIT facility 51 may have to be returned to JIT facility 51. The CSR can return goods to the JIT facility 51 by proceeding to Order Header data screen 60 and entering an Account Number and a Requisition Number. The CSR must then enter a "G" into the ORDER TYPE field on Order Header data screen 60 so that order type field of the Requisition Header Table for this transaction will be recognized by local computer 40 as a returned goods transaction. As with an ordinary requisition, the CSR may then enter customer variable data using Customer Variable Header data screen 64. By hitting the F2 key from Order Header data screen 60, local computer 40 will then display the Return Goods data screen, an example of which is set forth in Table XIV. This data screen is very similar to Requisition Management data screen 68, and the CSR enters data onto the Return Goods data screen this screen as described in connection with the use of Requisition Management data screen 68. The CSR must enter a valid STOCK NBR, a RET QTY (return quantity), a UM (unit of measure) and a PT (product type). Once the CSR has entered the required information, if the CSR hits the Enter key, local computer 40 will validate the entered data (much as local computer 40 validated the data entered onto the Inventory Adjustment data screen). If no errors are detected, local computer 40 runs a program which is essentially the same as that described in FIG. 6A in connection with adjustments to inventory. As in FIG. 6A, if the returned item (for the line being processed) is of product type 06, local computer 40 immediately adjusts the relevant quantity on hand entry in the Part Master Table in local database 50 (this time by adding the quantity in the RET QTY field to the prior quantity on hand). If the item or items being returned are of product type 01, local computer builds a data block to transmit the appropriate data to host computer 10, just as is shown in FIG. 6A. The host's processing of the return of goods is essentially the same as that shown in FIG. 6B in connection with adjustment of JIT inventory. The host validates the information received and creates an error block as described in connection with FIG. 6B if necessary. Otherwise, host computer 10 accesses the quantity on hand field for the relevant part number and JIT facility in host database 20 and adds the returned quantity to this amount to get a new quantity on hand. Host computer 10 then transmits a confirmation data block to local computer 40. Upon receiving this confirmation data block, local computer 40 then (assuming no error code is received) similarly updates the relevant quantity on hand entry in the Part Master Table in local database 50 (by adding the quantity in the RET QTY field to the prior quantity on hand), just as is shown in FIG. 6A. Inventory Replenishment Replenishment of local inventory is initiated when the CSR enters the code REPL into the RESPONSE field on any data screen. A replenishment algorithm (which may be one of many which are well known to those of ordinary skill in the art) is then executed using the data from the fields described in Table 2. An exemplary replenishment algorithm may employ two steps, as follows. First, a determination is made as to whether or not to restock the inventory for each item having a Plant Location Table entry. If the quantity available (the quantity on hand (QTY ON HAND)) is less than or equal to the REORDER POINT, then the inventory for the item will be restocked. Local computer 40 then creates a Replenishment Results Table in the random access memory of local computer 40. There will be one transfer order entry in the Replenishment Results Table for each part to be restocked. Each transfer order entry contains the following information: the relevant part number, product type, the plant location, the restocking source location, maximum order quantity, minimum order quantity, back order quantity, reorder point, quantity on hand and quantity on order from the relevant tables in local database 50. Next, local computer 40 runs the second step of the replenishment process to determine the quantity to be ordered to restock each item being restocked. For each transfer order entry in the Replenishment Results Table, local computer 40 performs an algorithm such as the following using data in the relevant fields of the Plant Location Table: Proposed Order Qnty.=((MAX ORDER QTY-QTY ON HAND)+(BACK ORDER QTY-QTY ON ORDER)) Local computer 40 then enters the calculated Proposed Order Quantity into a Quantity field in each transfer order entry in the Replenishment Results Table. When this has been done for all of the transfer order entries, local computer 40 then sorts the entries in the Replenishment Results Table by product type (01 or 06). Some of the entries having product type 01 are preferably further sorted by a SOURCE LOCATION code in the Plant Location Table (see the exemplary Plant Location data screen, which is used to create the Plant Location Table). The SOURCE LOCATION code identifies the particular Distributor warehouse that item is sourced from; by grouping such items together in the Replenishment Results Table, individual transfer orders generated from replenishment will thus be more likely to be sourced by a single warehouse, which will simplify tracking of the trans | ||||||