STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT
BACKGROUND OF THE INVENTION
 The invention described herein may be manufactured and used by or for the government of the United States of America for governmental purposes without the payment of any royalties thereon or therefor.
1. Field of the Invention
The present invention relates to a computer-based networked purchasing management system. More specifically, the Material Ordering and Reporting Expediter (MORE) is a procurement device that uses the FILEMAKER PRO 5® database to partially automate preparing and obtaining approvals on the numerous types of purchasing documents used by an organization or sub unit of an organization.
2. Description of the Related Art
Electronic transaction and purchasing systems are well known. An electronic transaction or purchasing system typically permits a user to conduct designated transactions or purchases electronically, which substantially improves efficiency and convenience to the user. Examples of electronic transactions or purchases include transactions conducted via computer networks, automated teller machines (ATM's), automated point-of-sale systems, automated library systems, and the like. Transactions and purchases conducted via computer networks may encompass a wide range of transactions, including exchanging information and data via a computer network popularly known as the Internet, e.g., to make a purchase from a vendor on the network. ATMs typically permit users to conduct financial transactions (such as withdrawals, transfers, deposits, and the like) vis-a-vis a financial institution in an electronic manner. Automated point-of-sale systems may be employed by merchants to permit users to purchase products or services using the users' electronic account, and automated library systems may be employed to permit library users to check out and return library materials. Other examples of electronic transaction or purchasing systems are readily available in popular literature and are not enumerated herein for brevity sake.
To enhance security to the user's account, electronic transaction or purchasing systems typically request the user to provide identification data to authenticate himself as the user authorized to approve the proposed transaction or transactions. If the user fails to provide the requested identification data, the proposed transaction or purchase is not authorized and will not be processed. The identification data may be required with each transaction.
- SUMMARY OF THE INVENTION
In the prior art, users are typically required to manually enter the identification data into the electronic transaction system for authentication. Typically, the entry of identification data involves typing in a password on a numeric keypad or on a keyboard. The identification data is then compared with data previously stored within the electronic transaction or purchasing system, and authentication is satisfied when there is a match. As mentioned previously, the transaction or transactions proposed will not be allowed to proceed if there is no match. More recently, electronic signatures have been used to verify the approval of a transaction or purchase and to act as a security device. Typical examples of the use of electronic signatures can be found in U.S. Pat. No. 5,917,913 issued to Wang on Jun. 19, 1999 and U.S. Pat. No. 6,058,483 issued to Vennel on May 2, 2000.
The Material Ordering and Reporting Expediter (MORE) partially automates preparing various purchasing documents and obtaining approvals thereon. MORE may select subsets of the data and sort those subsets in a variety of ways for generating reports. Because the typical (signature) approval chain goes to the Division level (a specific sub unit of the organization), MORE is implemented on a Division-by-Division basis. MORE is written in FILEMAKER PRO 5® and is renewed (that is, recycles to 0 records) at the start of each fiscal year.
Automation occurs at various steps in the process. The program automatically fills in part and vendor information based on a prior order (if any) of the same part number. When a Job Order Number (JON) is entered, the program looks it up in a Master Job Order (MJO) file to validate its existence and suitability for this purchase. The program determines the approval chain based on rules specific to each Division. Once the signature cycle is started, the program automatically e-mails the next Signatory in the chain. When a Signatory approves the order, an electronic signature is affixed to the purchase document. When the last Signatory approves the order, the program automatically e-mails the within-Division buyer, called a Processor in the MORE program, that the order is approved for purchase. Only then does the Processor print out a hard copy of the purchase document.
MORE has 3 classes of users:
1) Requesters: people who need something—a tool, a part, a contract—to complete a task.
2) Processors (i.e. within-Division buyers)
3) Signatories: supervisors and financial personnel with approving authority.
A preferred embodiment of the present invention is a computer-based system for coordinating a purchase document and approving the purchase by one or more Signatories of an approval chain. First, the program of the current invention provides a means for creating the purchase document by a Requester. Next, the program provides a means for notifying a Processor of the purchase document. The Processor reviews the purchase document for completeness and accuracy and upon finding the purchase document to be complete and accurate, the processor forwards the purchase document to the approval chain. Next, the program provides a means for determining an approval chain for the purchase document. Next, the program provides a means for sequentially notifying each of the Signatories in the approval chain and then each of the Signatories approve the purchase by clicking a button that affixes an electronic signature to the purchase document prior to automatically sending the purchase document to the next Signatory in the approval chain. Next, the program provides a means for notifying the Processor of approval of the purchase document, after the final Signatory in the approval chain approves the purchase document. Next, the program provides a means for printing a purchase document. The purchase document form contains information relevant to the purchase and the electronic signature of each of the Signatories in the approval chain.
The general flow of the program is described below with the likely user class listed in parenthesis.
Creating a New Order (Requester):
Requesters submit a request for a Material purchase by Creating a New Order that describes the item or items needed and then pressing a pale, yellow on-screen button that e-mails a “processor”, i.e. a within-Division buyer, to examine the order for completeness and route it for electronic signatures. (Each requester “in the system” has a default processor, but alternate processors are selectable.)
Responding to Orders Pending Approval (Processor):
The Processor is, in essence, the first approver. Only after the Processor has reviewed an Order and found it acceptable, is it routed to the Signatories for (electronic) signatures.
Responding to Orders Pending Approval (Signatory):
The Program determines the approval chain (based on rules specific to each Division) and e-mails the first signatory in response to the processor clicking a large, green, on-screen button that the order is complete. Each signature category has an “In Box” button that finds all the order requests awaiting that person's review.
Each Signatory has a unique password and an approval button with the Signatory's name on it that only that password operates. As each Signatory approves an order (thereby affixing an electronic signature), the program automatically e-mails the next Signatory in the chain, such as a supervisor or a financial overseer. When the last person in the chain approves the order, the Processor receives automatic e-mail that the order is approved for purchase. Each signature category has a single reject button that all passwords in that category operate. When rejecting an order, the Signatory may explain why in the “Order Status Dialog Box”. Clicking the Reject button puts the rejecter's name next to the Reject button and automatically generates an e-mail to the Processor, with a cc: to the Requester, that the order is being rejected.
Checking the Status of Open Orders (Requester and Processor):
Requesters (and Processors) may follow the progress of an order through the (within-Division) approval chain by checking the status of open orders. Received and canceled orders are not listed. The Order Status screen shows the complete approval chain, in order, date stamps when a Signatory responded, and uses color-coding to indicate who approved the order last.
Making the Purchase (Processor):
When the Processor receives the “approved for purchase” e-mail, the Processor clicks a single button that prints out the form appropriate for this purchase. Electronic signatures of those who approved will be affixed. At this point, the purchase follows established rules for an organization or division.
Generating a Report (Requester, Processor, Signatory):
MORE can generate a number of canned reports that provide subtotals and totals by Requester, by Processor, by project, by JON, or by division. These reports can be for the entire fiscal year or for a specified time span within the year. The reports can be for a single Requester, Processor, Project, JON or Code, or for all in the category, or for a subset in the category. When a report has more than one individual/item per category, there are subtotals on an individual/item basis with a rollup for all in the selected set/subset.
One object of a preferred embodiment of the present invention is to provide automatic e-mails that expedite the approval process and “In Box” buttons that prevent orders from being forgotten.
Another object of a preferred embodiment of the present invention is to provide the Requester with a common interface regardless of the type of purchase that will be pursued. Details of the procurement system not pertinent to the Requester are handled by the Processor. For purchases from the same vendor with the same JON, the program allows easy entry of up to 20 items on a single buy.
Another object of a preferred embodiment of the present invention is to provide a common interface that works for the Processor as well the Requester. Both have a consistency/uniformity of data entry that may have been lacking before. If all Requesters access the system to place their orders, undecipherable, hand-written requests become a thing of the past.
Another object of a preferred embodiment of the present invention is to provide a computer-based system where if internet sites were used in the previous purchase of the same item, they are cited for easy referral to the current purchase. Easy referral means the user clicks a button that opens the browser and goes to that site.
BRIEF DESCRIPTION OF THE DRAWINGS
Another object of a preferred embodiment of the present invention is to provide a computer-based system with a link to the FedLog program. FedLog tells the user which supply centers in the Federal Supply System carry which items and how many they have in stock. MORE even presents how to create a custom screen in FedLog to display the information the user wants and only that information. A custom screen makes it easy to cut and paste between the two programs.
The objects, features and advantages of the method and apparatus for preferred embodiments of the present invention will be apparent from the following descriptions in which:
FIG. 1A is a pictorial representation of the top half portion of the Item 1 screen of a preferred embodiment of the present invention, which includes help features and explanatory text of a preferred embodiment of the present invention.
FIG. 1B is a pictorial representation of the bottom half portion of the Item 1 screen of a preferred embodiment of the present invention, which includes help features and explanatory text of a preferred embodiment of the present invention.
FIG. 2 is a pictorial representation of the of the Order Status Screen of a preferred embodiment of the present invention, which includes help features and explanatory text of a preferred embodiment of the present invention.
FIG. 3A is a pictorial representation of the top half portion of the Signature Buttons screen of a preferred embodiment of the present invention, which includes help features and explanatory text of a preferred embodiment of the present invention.
FIG. 3B is a pictorial representation of the bottom half portion of the Signature Buttons screen of a preferred embodiment of the present invention, which includes help features and explanatory text of a preferred embodiment of the present invention.
FIG. 4 is a pictorial representation of the left side portion of the Processor Page screen of a preferred embodiment of the present invention, which includes help features and explanatory text of a preferred embodiment of the present invention.
FIG. 5 is a flowchart illustrating the processing steps of creating an order using the Material Ordering and Reporting Expediter in accordance with a preferred embodiment of the present invention.
FIG. 6 illustrates computer systems in a network that are configured in accordance with a preferred embodiment of the present invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
FIG. 7 illustrates a simplified block diagram of the Material Ordering and Reporting Expediter, configured in accordance with a preferred embodiment of the present invention.
The Material Ordering and Reporting Expediter (hereinafter “MORE”) program partially automates the preparation of purchase order documents. MORE may select subsets of the data and sort those subsets in a variety of ways for generating reports. Purchasing is expedited by automatic data fill-in based on a prior order, if any, of the same part number, automatic validation of the Job Order Number, and program determination of the approval chain with automatic e-mailing to the next Signatory when approval is granted. Electronic Signatures are affixed when a Signatory clicks the applicable password-controlled button.
Most organizations have an approval chain specific to the organization or a division thereof. For each order, MORE determines the approval chain based on rules specific to the organization. In addition, MORE can determine the approval chain of a division within an organization. This feature enables the program to automatically e-mail the next Signatory in the approval chain of a division once the signature cycle has been started, and to e-mail the Processor when approval to purchase is granted.
To better describe the operation of the property management system of the present invention, the utility will be described as it pertains to purchasing documents used at the Naval Air Warfare Center Weapons Division at China Lake, CA and Point Mugu, Calif. These documents are the 6-part short stub, 6-part long stub, a worksheet for a government Bankcard purchase, the Pt. Mugu site Hazardous Materials (hereinafter “HazMat”) Bankcard purchase, and the China Lake site Long Stub. In addition, the Bankcard worksheet is generally suitable for China Lake Small Procurement Electronic Data Interchange (hereinafter “SPEDI”) purchases. The Material Ordering and Reporting Expediter is a FILEMAKER PRO 5.0® database that partially automates preparing purchase order documents, such as:
1) the DD Form 1348 (6 PT) Requisition Document (hereinafter “the Short Stub”)
2) the DD Form 1348-6 Requisition Document (hereinafter “the Long Stub”)
3) the HazMat Bankcard purchase
4) a Work Sheet for a government Bankcard purchase,
5) the China Lake 4491/1 (9 PT) Requisition Document
In addition, the program accommodates entry of the SPEDI catalog number in lieu of a part number. Thus, SPEDI costs may be included in reports generated by MORE. Further, the Bankcard Work Sheet may be used for a hard-copy document of the SPEDI purchase. Data may be organized, that is filtered and sorted, by Processor (the person who processes the order, either a Credit Card Holder or someone who handles stubs), Requester, Job Order Number, Project, Organization Code, time span, etc. Combinations of the preceding are also possible. The ability to organize data and to total and subtotal the data on that basis allows for a number of useful reports to be generated. In a preferred embodiment of the present invention, various colors are used to assist the user in identifying the various choices available on a screen and information required by the program.
The active database, “OnOrder”, contains all orders submitted in a current fiscal year (FY). This database is used to enter new orders and to review existing orders. As a new fiscal year approaches, a new, empty database is created for the new fiscal year. For example, when used in government organizations, on about October 1, the active “OnOrder” database is renamed “OnOrderFY,” where FY represents the last two digits of its fiscal year. At the same time, the new, empty database is made available under the name “OnOrder.”
Another database, “Stock”, contains information on items previously ordered. The records in “Stock” are from the current fiscal year and all prior years that the MORE program existed. When a Requester enters a part number block 20 in a new order, it is searched in the Stock database, and if a match is found, the information in “Stock” is automatically entered in the new order. Referring to FIGS. 1A and 1B, when a Requester has completed all entries, the Requester clicks an on-screen button 21 that e-mails the Processor that the Requester has an order pending. The Processor is the person who checks the order for completeness, starts the e-mail signature chain, prints the order, and submits the paperwork to supply or makes the credit card purchase. The Requester's name, a brief description of the order, and the order number are included in the e-mail message. After the Processor has reviewed an order, the Processor chooses one of two on-screen buttons to respond. A button 90 e-mails the Requester that the Processor found no unresolvable problems and the order is being electronically routed for signatures. A button 92 e-mails the Requester that a problem with the order exists. The Processor is expected to describe the problem in the “Order Status Dialog Box” 94 prior to clicking the “problem” button 92. If there is a problem, after the Requester fixes it and/or provides clarifying information in the Order Status Dialog Box 94, the Requester again presses the on-screen button 21 to notify the Processor to process the order. If the Order Status Dialog Box 94 is used to keep a running dialog, the Requester may start each entry with that day's date.
When the Processor e-mails the Requester that the order is acceptable, the program simultaneously e-mails the first signatory, for example a Section Head or Branch Head. That e-mail includes a brief description of the order and the order number, and requests that the Signatory review and respond to the order by approval or rejection. If the signatory chooses to reject the order, the signatory may give the reason why in the Order Status Dialog Box 94. Clicking a red Reject button 60,61,62,63,64,65 and 66 initiates e-mail to both the Processor and the Requester. If approval is given, a check mark is placed next to the signatory's name on the approval button; the signatory's electronic signature is affixed to the form. An e-mail to the next signatory, such as the Division's Budget Analyst, is automatically generated. Similar e-mails are generated as the order goes from the Budget Analyst block 69 to the Division Head, and from the Division Head to a funds overseer, if any. The software is programmed to know the last stop in the approval chain, and when the last signatory approves, the program automatically generates an e-mail to the Processor that approval to purchase has been granted.
Initial Set Up.
To efficiently use the MORE program, a user must first identify himself to FILEMAKER PRO®. Recognized MORE Users have their name added to a list on the opening screen; the user then scrolls this list to select his/her name. However, if the user enters his/her name into FILEMAKER PRO®'s “User Name” exactly as the MORE program has it, no scrolling will be needed. In general, MORE uses the user's name as it appears in Microsoft Outlook's Address Book. The format is: Last Name, First Name Initial. There is only one (1) comma, and there is no period after the Initial. For example, “Smith, John L” might be an entry.
After the user has the precise name (no comma between First Name and Initial), the user opens the user's copy of FILEMAKER PRO® on the user's computer. From the pull-down menu bar near the top of the screen, the user selects the Edit pull-down menu. At the bottom of the list, Preferences is selected, then Application. In the User Name box, the user enters the user's name.
Starting the Program
Double clicking the Desktop starter file icon launches FILEMAKER PRO® and opens the Material Ordering and Reporting Expediter (MORE) “MainMenu.fp5” file. This initial screen asks the user to verify identifying information, for example Name block 22, Code block 23, Phone Number block 24, etc. If the user name is not highlighted when the file opens, the user scrolls the list to the user name.
Next, the user selects from creating a new order, checking order status, responding to an order, generating a report, or quitting the program. Quitting the program closes all MORE databases, but leaves FILEMAKER PRO® open. These choices are available at almost all stages of the MORE program. The user uses a mouse to make the selection. Unless the user elects to quit, the program opens “OnOrder” database and a database containing Job Order Number (JON) information.
Referring to FIGS. 1A and 1B, which illustrate the MORE Item 1 screen, once the “OnOrder” database is open, three other options are available under “Select the Next Step” 25: “New Order for this Project” 54, “. . .Next Step” choice, “Duplicate this Order” 55, also added to the “. . . Next Step” choices, and “Cancel this Order” 56.
There are five (5) main screens of interest to the general MORE user. They are Item 1, Items 2-20, Order Status, Reports and Signature Buttons.
FIGS. 1A and 1B display the “Item 1” screen. That screen and the other four (4) screens mentioned so far are choices on the “GO TO” navigation button 26 toward the upper right of the Item 1 screen. This pattern is repeated on all five (5) of these screens. As noted earlier, various colors may be incorporated into each screen to assist the user. For example, in a preferred embodiment of the present invention, the “GO TO” navigation button is green. The function of each of the main screens of interest may be summarized as follows:
Item 1—Requesters perform data entry for the 1st item to be purchased, including JON block 27, justification block 28, and Vendor block 29. Processors validate entries on this screen;
Items 2-20—Requesters enter items 2-20, if any, to be purchased on Credit Card 97, SPEDI 98, or Long Stub 99 buys. Processors review the entries on the Items 2-20 screen;
Signature Buttons—Referring to FIGS. 3A and 3B, Signatories review a summary of the order and respond (approve or reject) by clicking a button with their name. These button clicks generate automatic e-mails, and if approval is given, affix electronic signatures. Signature buttons include buttons 68-78 and Reject buttons include buttons 60-66;
Order Status—Anyone may view a color-coded representation of where in the approval chain orders are. If approved for purchase, date ordered and date delivered may be shown; and
Reports—Anyone may generate any of a variety of reports by clicking a button and following instructions given in pop-up information boxes.
There are two primary reasons to look at a prior order: 1) to check the status of the order, or 2) to obtain pertinent information for a new order. When a user clicks “Check Status of Open Orders” on the Main Menu, the user is directed to the Order Status screen of the “OnOrder” database. A dialog box asks if the user wants to see the “Slow Purchase Report”. This report shows all the user's orders that are more than 7 days old and for which the Processor has not entered an “Ordered On” date.
After declining or viewing that report, an information box pops up. It instructs a user to “Click the orange Requester button and follow its instructions”. When a user follows those instructions, the program will find all orders the user has submitted this fiscal year that have not been marked as received or canceled, i.e. that are still active. Each order number has a background color indicating its status: yellow indicates active, red indicates canceled, gray indicates received. The record currently selected will have a vertical, black bar on the left side of the screen, just to the right of the gray Status Area. The user clicks the upper or lower page in the spiral-bound flip book in the upper left to move to the record/order of interest. If the order vehicle is a long stub and the words “Click me for Supply status” appear on the far right of the line, simply single click anywhere on that text and follow the instructions in the information box that pops up to see the status of the order within the Supply Department.
If the purpose of reviewing the order was to check its status because the Processor notified the Requester of a problem, via click-of-a-button automatic e-mail, the Requester needs to correct the problem or provide clarifying information. In either case, the Requester clicks the “GO TO” button 26 and then selects “GO TO Item 1” to access that layout. The Requester should use the on-screen Order Status Dialog Box 94, illustrated in FIG. 1B, to describe the action/response and then click the pale-yellow, on-screen button 21, illustrated in FIG. 1A, to e-mail the Processor to process the order.
Data entry for a new order is greatly reduced if the Requester knows the part number of the item. If a part number is not known, the Requester may search the OnOrder database based nomenclature, manufacturer, description, etc., to find a prior order. In this case, The Requester does not click the orange “Requester” button. Instead, the Requester immediately clicks the green “GO TO” button 26 and then selects “GO TO Item 1”, as illustrated in FIGS. 1A and 1B. When on that layout, the Requester selects “View” from the pull-down menus, followed by “Find Mode” and then enters the known information in the appropriate fields. After clicking “Find” on the left in the gray Status Area, the Requester may scroll through the records found. If the item is found, its part number may be highlighted and copied to the clipboard.
The Requester should then select the “New Order for this Requester” option in the “Select the Next Step” radio buttons. The software creates a new record and places the cursor in the Part Number field block 20. Then, the Requester may paste in the part number and let the software automatically fill-in many of the fields. If the item is not found in the OnOrder database, the Requester may search the Stock database by pressing the green “Search Stock” button 32. Then, the Requester follows the same procedure as searching the OnOrder database, but when finished searching, clicks the “Return to OnOrder” button. If the search succeeded and the Requester copied the part number to the clipboard, after “New Order for this Requester” is selected, the part number is pasted. If the search did not succeed, the Requester must perform all the data entry.
In a preferred embodiment of the present invention, when creating a new order, the first entry on the “Item 1” screen, illustrated in FIGS. 1A and 1B, is the Manufacturer's Part Number block 20. This entry triggers a lookup in the Stock database to see if that item has been ordered before. If so, the program will fill in those fields expected to be the same, namely the Nomenclature block 33, Unit of Issue block 34, Unit Cost block 35, National Stock Number block 36, and Distribution Code block 37. The program will also fill in the Color, Size, Manufacturer, and Vendor information. The fill in should occur very quickly. The Requester reviews the “Item 1” screen to fill in and/or change any fields that need it, including those that were filled in by the program.
In a preferred embodiment of the present invention, when the user enters the 12-character Job Order Number (JON) block 27, the program will look it up in a Master Job Order (MJO) file to validate it. The program checks that the JON is in the MJO file, that the JON is open on this date, that the JON has a positive funds balance, and that the JON is open for purchasing material and for labor. This information is indicated to the right of the JON. The “Expires” field 40 will contain either the expiration date of the funds (which confirms that the JON is in the file and will tell the user if it is open or not) or the words JON NOF, where NOF means Not On File. A blank in the balance field indicates a positive balance. A red “$-” 41 in the balance field means the JON is “in the red”. The Material field (Mat'l) 42 is either Y or N, for Yes or No on being open for material. The Labor field follows the same convention. If the JON fails any of these checks, the user will be allowed to continue making entries, but the Processor will not process the submittal until the deficiency is corrected or a satisfactory JON is provided.
The item(s) is(are) added to the “Stock” database the first time the Requester e-mails the processor this order.
All fields on the “Item 1” screen and a brief description of the function are listed as follows, as illustrated in FIGS. 1A and 1B:
Part Number block 20—Manufacturer's Part Number. This field should be the 1st entry—triggers a lookup in the Stock.fp5 database to automatically fill in several other fields;
National Stock Number (NSN) block 36—The 13-digit number issued to national/federal stock items. The format is: nnnn-nn-nnn-nnnn. This field is often left blank;
Distribution Code block 37—This 2 or 3-character code designates the source of supply for NSN items. The correct code is found when using one of the computer databases for federal stock items, e.g. FedLog.
Nomenclature block 33—A brief description of the item. The first word should be very general/high level and the words that follow more descriptive. This entry is limited to about 44 characters.
Quantity block 38—The quantity of this item the Requester wishes to order;
Unit of Issue block 34—The Requester selects the correct 2-character abbreviation from the list that appears when tabbing or clicking into the field;
Unit Cost block 35—The cost per unit of issue. The program will multiple the Unit Cost by the Quantity to determine the extended cost;
Job Order Number block 27—The organizational JON;
Funds Expire—The software will automatically fill this in when it looks up the JON in the Master Job Order file. If the JON doesn't exist, JON NOF appears;
Required Delivery Date block 44—a date (mm/dd/yy) is entered when the Requester needs the item; the item may be especially important for end-of-year purchases. If a date is not entered, the software creates this date when the order is printed. It is the date of printing+30 days;
Justification block 25—A brief explanation of why this purchase is necessary;
Manufacturer block 45—The name of the manufacturer of the part to be ordered.
(Extended) Description/Notes block 46—List special features here, e.g. technical, electrical, and physical characteristics. The user should try not to repeat the same words listed in the part number field. This field is large to allow for the listing of all the special features. If the purchase is via a long stub or if the type exceeds the space on the appropriate form, the program will print the entire description on a separate sheet (or sheets)—up to 3 pages;
Vendor Name block 29, Vendor Addr block 49, Vendor Phone block 50, Vendor POC block 51—The user should list the suggested sources of supply here. Sometimes a vendor has a different part number than the manufacturer. If so, the user may list the vendor's part number next to the name to eliminate confusion. If the total cost is more than $2500, the user may furnish two or more sources. Make entries in the name, address, phone number, and point of contact fields if known. A separate page may help eliminate confusion on a crowded stub. Therefore, the vendors are automatically printed on the separate, extended description sheet;
Order Status Dialog Box block 94—A place for the Requester and Processor to conduct a dialog concerning the status of the order; and
Internet Addresses block 52—Universal Resource Locators (URLs) give Internet addresses for potential suppliers. Typically, these correspond to entries in the Vendor Name. They are treated as hyperlinks, and clicking the “GO TO” buttons 26 to their left will launch a browser (if necessary) and go to the designated web site.
The “Items 2-20” screen is used for those credit card and Long Stub orders that are for multiple items from the same vendor (and same JON). This screen is accessed by clicking the green, on-screen “GO TO” button 26
and then selecting “GO TO Items 2-20”. As the following Table 1 shows, the seven fields on “Items 2-20” have the same definition as those seven fields on the “Item 1” screen.
|TABLE 1 |
|“Items 2-20”Fields |
|Field ||Description |
|Part Number ||Same definition as the Item 1 Field “MFG |
| ||Part #”. |
|Nomenclature/Name ||Same definition as the Item 1 Field |
| ||“Nomenclature”. |
|(Extended) Description ||Same definition as the Item 1 Field “(Extended) |
| ||Description/Notes”. |
|Manufacturer ||Same definition as the Item 1 Field |
| ||“Manufacturer”. |
|Unit of Issue ||Same definition as the Item 1 Field “Unit of |
| ||Issue”. |
|Qty ||Same definition as the Item 1 Field “Quantity”. |
|Unit Cost ||Same definition as the Item 1 Field “Unit Cost”. |
When all entries are completed, including “Items 2-20” as needed, the Requester clicks the pale-yellow on-screen button 21 to e-mail the Processor that an order is pending. If the usual Processor is not available, the Requester may use the drop-down list above the e-mail button to select a different processor for an order. If the order is urgent, the Requester clicks the red check box 57 to the right of the required delivery date to have an “URGENT” statement included at the beginning of the e-mail message. If the Requester does not enter a part number or a National Stock Number (NSN), and does not attempt to describe the item, the program will not issue the e-mail, but will request either a part number or further description of the item.
When a Requester creates a new order from the MainMenu or from the “New Order for this Requester” button 53 in the “xxx OnOrder” database, MORE automatically fills in the information pertaining to the selected Requester, but nothing else. In the “xxx OnOrder” database there is a second option under “Select the Next Step” 25, which is “New Order for this Project” 54. In a preferred embodiment of the present invention, when the Requester clicks this button 54, in addition to the requester information, the Project Name, Urgency Indicator 48, JON 27, Required Delivery Date 44, and Justification 28 are automatically duplicated in the new request. The button 54 will be useful when ordering many parts for a specific project, especially if the parts are federal supply, which requires a separate short stub for each part. When creating a new order, there is a third option: the “Duplicate this Order” button 55. A new record is created with all the Requester entries from this record duplicated. This method will be useful if the changes required are less than making all the non-automatic entries from scratch. Referring to FIGS. 1A and 1B, the “Cancel this Order” button 56 is utilized by the Requester to abort an order.
To exit the program, a user may click the “Exit MORE” radio button in the “Select the Next Step” set of options 25. All MORE databases will be closed, but the FILEMAKER PROS application will remain open.
Referring to FIGS. 3A and 3B, the Signature Buttons screen contains several sets of password-controlled buttons 68 through 78 that signatories click to affix their electronic signature to the appropriate form. Only the individual signer will have the password for his or her button 68 through 78. The password given to “Stand-ins” will operate the button 68 through 78, but the signature on forms will be preceded by the Stand-in's initials and the word “for”. On the Signature Buttons screen, the Stand-in's full name will appear as the Approver rather than the permanent signatory's name. Right above the block of buttons is a condensed version of the order information. That is intended to be sufficient for the signers to decide whether to approve or reject the order. When someone “signs off”, the next higher level signatory is notified automatically and a check mark is placed to the right of the individual's name on his/her approval button. When the final approver in the chain clicks “yes”, the Processor is e-mailed that the order is approved for purchase. Thus, the Processor will know when it is time to print the appropriate hardcopy and proceed with the purchase.
When the Processor places the order, the Processor may go to the Signature Buttons screen to enter data into fields indicating who placed the order, when it was placed, and when delivery is expected. Clicking an on-screen button automatically e-mails this information to the Requester. The date ordered is displayed on the Order Status screen.
When the order is delivered, the Processor may go to the Signature Buttons screen to enter the quantity received, actual cost, received date, and the recipient. Clicking an on-screen button automatically e-mails this information to the Requester. When this button is clicked the program changes the order status from “active” (yellow background color on the order number e.g. order 59) to “received” (gray background color on the order number e.g. order 58). The date delivered is displayed on the Order Status screen under “Date Rec'd”.
The Processor clicks the green “GO TO” button and then selects “GO TO Processor Page” to go to the “Processor Page” layout, as illustrated in FIG. 4. This layout has the same “GO TO” button 26 to easily navigate to the “Item 1” screen, to “Items 2-20”, to the “Signature Buttons”, to the “Order Status”, and to the “Reports” screen. The Requester's name and order are repeated on the Processor Page for the processor to know what order is being processed. Any problems the Processor sees should be described in the Order Status Dialog Box 94.
There is a line for Shipping and Handling (S & H) charges if it is a credit card order. If it is a stub order, there is an entry for the Contractual/Other Code. After the Processor has decided whether or not there are problems with the order, the Processor presses the appropriate button (Success or Problem) to e-mail the Requester. The Processor then selects the form to print, for example credit card 97, short stub 104, long stub 99, HazMat 106, or 4491/1 108. This selection assures that when the time is right to print a hardcopy, the right form will be printed.
The Reports screen is used for generating a variety of reports. A three-line format is used for each order that is reported. A row of buttons along the top left of the screen allows the user to select and sort data by Processor, by Requester, by Job Order Number, by Code, and by project.
The Processor is responsible for verifying and/or filling in many fields. Many of these fields, which are related to stub purchases are selectable from drop-down lists. For example, the Unit of Issue 34
contained in columns 23-24 of both the Long Stub and the Short Stub is an abbreviation of the types of units under which material is issued. Table 2 presents typical examples of 2-character abbreviations from the list that appears when tabbing or clicking into the field.
| ||TABLE 2 |
| || |
| || |
| ||Code ||Description |
| || |
| ||AM ||Ampoule |
| ||AT ||Assortment |
| ||AY ||Assembly |
| ||BA ||Ball |
| ||BD ||Bundle |
| ||BE ||Bale |
| ||BF ||Board Foot |
| ||BG ||Bag |
| ||BK ||Book |
| ||BL ||Barrel |
| ||BO ||Bolt |
| ||BR ||Bar |
| ||BT ||Bottle |
| ||BX ||Box |
| ||CA ||Cartridge |
| ||CB ||Carboy |
| ||CD ||Cubic Yard |
| ||CE ||Cone |
| ||CF ||Cubic Foot |
| ||CK ||Cake |
| ||CL ||Coil |
| ||CN ||Can |
| ||CO ||Container |
| ||CY ||Cylinder |
| ||CZ ||Cubic Meter |
| ||DR ||Drum |
| ||DZ ||Dozen |
| ||EA ||Each |
| ||FT ||Foot |
| ||FV ||Five |
| ||FY ||Fifty |
| ||GL ||Gallon |
| ||GP ||Group |
| ||GR ||Gross |
| ||HD ||Hundred |
| ||HK ||Hank |
| ||IN ||Inch |
| ||JR ||Jar |
| ||KT ||Kit |
| ||LB ||Pound |
| ||LG ||Length |
| ||LI ||Liter |
| ||MC ||Thousand Cubic Feet |
| ||ME ||Meal |
| ||MR ||Meter |
| ||MX ||Thousand |
| ||OT ||Outfit |
| ||OZ ||Ounce |
| ||PD ||Pad |
| ||PG ||Package |
| ||PM ||Plate |
| ||PR ||Pair |
| ||PT ||Pint |
| ||PZ ||Packet |
| ||QT ||Quart |
| ||RA ||Ration |
| ||RL ||Reel |
| ||RM ||Ream |
| ||RO ||Roll |
| ||SD ||Skid |
| ||SE ||Set |
| ||SF ||Square Foot |
| ||SH ||Sheet |
| ||SK ||Skein |
| ||SL ||Spool |
| ||SO ||Shot |
| ||SP ||Strip |
| ||SX ||Stick |
| ||SY ||Square Yard |
| ||TD ||Twenty-four |
| ||TE ||Ten |
| ||TF ||Twenty-five |
| ||TN ||Ton |
| ||TO ||Troy Ounce |
| ||TS ||Thirty-six |
| ||TU ||Tube |
| ||VI ||Vial |
| ||YD ||Yard |
| || |
The 2 or 3-character Distribution Code 37
designates the source of supply for NSN items. In the Defense Logistics Agency Customer Assistance Handbook it is called the Routing Identifier Code (RIC). NAWCWPNS chooses from the “NAVY COG” column. Several popular choices are:
|9N ||Def. Sup. Cntr, Columbus (electronics) ||9Q ||GSA, DC |
|9G ||Def. Sup. Cntr, Richmond VA ||9Z ||Def. Industrial Sup. |
| || || ||Cntr |
The correct code is found when using one of the computer databases for federal stock items, e.g. FedLog.
Priority is a 2-digit code related to MILSTRIP Force/Activity Designators (F/AD). RDT&E in general, and Code 522 in particular tend to use F/AD IV, encompassing priorities 07/09/14. The lower the Priority Number the quicker the response. Specific projects may be authorized a lower-numbered F/AD.
07 indicates a work stoppage has occurred on mission-essential tasks or equipment,
09 indicates a work stoppage will occur to a mission-essential task or equipment,
14 indicates routine requirements, replacement of stock, or scheduled maintenance.
If the user has a customer with authority to use a higher priority, attach a memo authorizing use of that priority signed by an official from the code or division. Table 3
presents examples of Priority designators used in a preferred embodiment of the present invention.
|TABLE 3 |
| ||Urgency ||Urgency ||Urgency |
|F/AD ||Designator A ||Designator B ||Designator C |
|I ||01 ||04 ||11 |
|II ||02 ||05 ||12 |
|III ||03 ||06 ||13 |
|IV ||07 ||09 ||14 |
| ||Conus: 12 days ||Conus: 31 days ||Conus: 31 days |
| ||Overseas: 16-17 days ||Overseas: 69-84 days ||Overseas: |
| || || ||69-84 days |
|V ||08 ||10 ||15 |
The designators are defined as follows. Designator A is requirements for material without which the activity concerned is unable to perform an assigned mission, or to eliminate an existing work stoppage of the repair of mission-essential equipment; Designator B is requirement for material, the lack of which is impairing the operational capability of the activity concerned, or is anticipated to cause work stoppage in performing maintenance of mission-essential equipment; and Designator C is routine requirements, replacement of stock, scheduled maintenance.
Table 4 presents typical Project Codes used in a preferred embodiment of the present invention. Each position of this 3-character code is sub-coded.
|TABLE 4 |
|1st Position ||2nd Position ||3rd Position |
|A ||Aircraft & ground ||A ||Allowance-Self Support (COSAL, ||0 ||CASREP/ |
| ||support equip || ||etc.) Increase Range || ||NMCS |
|F ||Fleet Ballistic ||K ||Repair-Unscheduled ||1 ||Work Stoppage |
| ||Missile Program || ||(Required for repair of “in-use” |
| ||(FBM) (SSBNs and || ||equipment.) |
| ||Ass) (FBM) |
|L ||Other Fleet Units ||L ||Repair-Scheduled ||2 ||Restricts |
| ||(includes || ||(Required for use in formal repair || ||operation |
| ||Oceanographic Units/ || ||program.) |
| ||Detachments) |
|P ||CNO Special ||M ||Overhaul-Unscheduled ||3 ||Shortage (not |
| ||Projects/Elements || ||(Required for overhaul of“down” || ||fully equipped) |
| || || ||equipment.) |
|S ||Repair and ||N ||Overhaul-Scheduled ||4 ||Management |
| ||Overhaul Shops (other || ||(Required for use in formal || ||Program |
| ||than AMD) || ||overhaul programs.) |
|T ||Experimental, Test ||O ||Maintenance-Technical ||5 ||Customer |
| ||and Research || ||(Required under normal preventative || ||Program |
| ||Programs/ || ||maintenance programs-lube, oils, || ||(forecasted |
| ||Organizations || ||paints, parts that have worn out but || ||requirement by |
| || || ||not failed, etc.) || ||customer) |
| || ||S ||Production/Manufacture ||7 ||Capability |
| || || || || ||impaired for |
| || || || || ||lack of parts |
|Y ||Miscellaneous- ||Y ||Miscellaneous-Not otherwise ||8 ||Government |
| ||Not otherwise || ||defined || ||furnished |
| ||categorized || || || ||material |
|Z ||Special Programs ||Z ||Disposal Programs ||9 ||Miscellaneous- |
| || || || || ||not otherwise |
| || || || || ||categorized |
Table 5 presents examples of frequently used codes for Federal Stock.
|TABLE 5 |
|Advice Codes for Federal Stock |
|Code ||Explanation |
|2B ||Only requested item will suffice. Do not substitute/interchange. |
| ||Also applies to “Obsolete”/“Inactivated” item previously rejected |
| ||with Status Code CJ. |
|2C ||Do not backorder. Reject any unfilled quantity not available to |
| ||meet SDD/RDD. Suitable substitute acceptable. |
|2J ||Do not substitute or backorder any unfilled quantities. |
|2L ||Entry in quantity field exceeds normal demands; however, this is a |
| ||confirmed valid requirement. |
|2N ||Item required in one continuous length as expressed in rp 25-29 |
| ||and unit of issue in rp 23-24. No other configuration is acceptable |
| ||and/or multiples of the unit pack are not acceptable. |
|2P ||Initial requirement certification. Requested item is a mandatory |
| ||turn-in repairable required for initial outfitting/installation or |
| ||increased allowance/stockage objective; therefore, no unserviceable |
| ||unit is available for turn-in. Requires memo explaining why we |
| ||have no turn-in. |
|J1 ||Requester authorizes buyer to pay up to 10% higher price without |
| ||calling for approval. |
In a preferred embodiment of the present invention, an order's status is updated after a credit card order has been placed or a long or short stub has been sent to Supply. The Processor may access the necessary fields to update the order's status by opening the MORE Program, navigating to the “Signature Buttons” screen illustrated in FIGS. 3A and 3B, and selecting the appropriate order number. If the purchase is a credit card buy, the user enters the name of the individual who bought the item, the date the order was placed, and the estimated date of delivery. If there was a change in price or a different vendor chosen, the user may enter this new information also. If it is a long or short stub, the user enters the date the stub was sent to Supply and the estimated date of delivery. If any new information comes to the attention of the user, such as the Purchase Order Number or Bankcard Purchase Log Number, that information may be added to the Signature Buttons page as well. After updating the Signature Buttons screen, the user clicks the yellow “E-mail Order Placed” button so that the new information will be forwarded to the requester.
In a preferred embodiment of the present invention, when an order is received, this information is entered on the Signature Buttons screen. The user enters the quantity received, the total price, and the date received. The requester will be notified of this change in status when the “E-mail Order Rec'd” button is clicked. Clicking the “E-mail Order Rec'd” button changes the background color of the MORE Order Number from yellow (active) to gray (received). If the user clicked the “Cancel This Order” button 56 on the Item 1 screen, the background color will be red to indicate cancellation. If the order has been cancelled for any other reason, the buyer can change the More Order Number to red by selecting the “Red” circle button on the Signature Buttons page.
Processors have three reports available immediately after logging on to the MORE program. Those reports are 1) Slow Review, which displays a list of orders not yet reviewed; 2) Slow Order, which displays a list of orders reviewed but not yet ordered; and 3) Late Delivery, which displays a list of orders placed but past the delivery due date. If more detailed information is required on a particular order, the user clicks the MORE Order Number and then the desired display screen is accessed by clicking on the green “GO TO” navigation button.
In a preferred embodiment of the present invention, each display screen needed in processing MORE orders has a drop down entry on the green “GO TO” navigation button. These choices make it easy to move around in the program. Item 1 displays the first screen, illustrated in FIGS. 1A and 1B, of the order. This screen is used by the Requester to enter ordering data for the first line item. If more than one line item is ordered from the same vendor, the Requester goes to Items 2-20. Items 2-20 screen (not shown) displays the screen where items 2 through 20 can be entered or reviewed. This includes the part number, description, manufacturer, unit of issue, quantity and u nit cost fields. Line item 1 is copied to this second screen and the program adds the shipping charges to the extended costs to calculate the total cost and enter it on the Item 1 screen. Signature Buttons screen, illustrated in FIGS. 3A and 3B, displays the Signatory buttons 68 through 78 and is used by the signatories to review and then to approve or reject an order. This screen is also used by the processors for updates such as ordering and receiving dates and price changes. Order Status screen, illustrated in FIG. 2, provides a Buyer/Processor or Requester the most current approval status of each active order. The user selects the Processor name button 110 or Requester name button 112, types the name for which the user wishes to view orders and then clicks “Continue”. If more details are needed, the user clicks the Order Number box 58 or 59 and then uses the green “GO TO” button to navigate to the desired screen. The Reports screen (not shown) generates reports based on the Processor/Buyer, Requester, Job Order Number, (Organization) Code, and project fields selected. The report can be a combination of fields and for a specific time frame. The Processor Page screen, illustrated in FIG. 4 allows the user to select the type of purchase, fill in items such as the Fund Type, e-mail the Requester, and print the appropriate form(s).
Help Buttons are available on most pages and can be identified by the green question mark (?) inside the green square buttons. These buttons offer additional information the user may need to determine the correct response for the corresponding block. If there is a list, the user clicks on the item needed and it will appear in the block.
Referring to FIG. 5, there is shown a flowchart illustrating the processing steps 120-154 which create an order using the Material Ordering and Reporting Expediter in accordance with a preferred embodiment of the present invention. Processing steps 120-124 require the requester to enter a password, verify his/her name, select “create a new order” on the Main Menu, and then enter a part number. If the part has previously been ordered, MORE inserts the required information from a previous order (processing step 128), otherwise the requester must enter this information (processing step 130, which includes, for example JON block 27, justification block 28, and Vendor block 29.
If more than one item is being ordered from a vendor, the Requester clicks “GO TO” button 26 and then selects “GO TO Items 2-20” prior to inputting the information for items 2-20 (processing steps 134 and 136). If special instructions are required for the order, the Requester enters these instructions and/or remarks into the “Order Status Dialog Box” 94 (processing step 140). The Requester e-mails the Processor to process the order by clicking on-screen button 21 (processing step 142), the processor receives and reviews the order (processing step 144), approves the order and sends the order to the first signatory in the approval chain (processing step 154). When the order is incomplete or there is an error in the order, the Processor notifies the Requester of the need for additional information to complete the order or to correct the order (processing step 148). The Requester makes the necessary additions and/or corrections to the order (processing step 152) and returns the order to the Processor for review.
FIG. 6 illustrates computer files 160, 162, 164, 166 and 168 in a network configured in accordance with a preferred embodiment of the present invention. Computer file 160 represents the aggregate of orders for the current fiscal year, file 162 represents the database file with user information, file 164 represents the main menu for the material ordering and reporting expedite, file 166 represents the database with job order number information, and file 168 represents the stock database which contains information on all items ordered in the MORE program.
FIG. 7 illustrates a simplified block diagram flow chart of the Material Ordering and Reporting Expediter, configured in accordance with a preferred embodiment of the present invention. To create an order, the requester enters the main menu then proceeds to the item one menu of FIGS. 1A and 1B and provides the required information (processing step 126). When there are multiple items to be ordered from the same vendor, the Requester provides the required information using the items 2-20 screen (processing step 172). The Requester may provide an extended description of the item to be ordered by utilizing block 46 (processing step 174).
The Requester may provide a sole source statement for the item to be ordered by utilizing block 47 (processing step 176) A sole source statement justifies ordering the item from a single source without price competition from multiple vendors. It is generally used when a vendor has an item which is uniquely configured for a particular application.
The Requester may also provide an urgency statement for the item to be purchased utilizing block 48 (processing step 178).
By utilizing block 52, the Requester may visit a single vendor Web Site or multiple vender Web Sites (processing step 182). The Requester may view the status of his/her order from the screen illustrated in FIG. 2 (processing step 180). There is also an option to view the different forms to purchase an item such as the credit card work sheet, the long stub and/or the short stub (processing step 188). The Processor page, used by the processor to purchase the item, is illustrated in FIG. 4 (processing step 190). Similarly, the signature screen which sets forth the signature chain required for approval to purchase the item is illustrated in FIGS. 3A and 3B (processing step 194). The Material Order and Reporting Expediter also allows for the generation of reports for items being purchased (processing step 192) and includes a screen for viewing purchases within a division (processing step 180).
Although the description above contains many specificities such as colors, indicators and purchasing forms, these should not be construed as limiting the scope of the invention but as merely providing an illustration of the presently preferred embodiment of the invention. Thus the scope of this invention should be determined by the appended claims and their legal equivalents.