System for managing customer orders and method of implementation

Description Submit all comments and votes

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a system for providing efficient management and fulfillment of customer orders in a food processing and distribution environment. More specifically, the invention relates to a system having an order management function, integrated with financial services to process orders promptly and create current and efficient financial records. Likewise the system includes a logistics function for processing orders and consolidating them into appropriate loads for delivery over transportation systems. Integrated in the system is an inventory management system that cooperates with the order management function, financial services function and logistics function to properly manage the raw material and finished product through a warehouse for delivery to a customer. Also included in the system is a purchasing system based upon an electronic catalog that streamlines the purchasing function by using blanket vendor orders to approve the purchase of the necessary materials to support the system.

2. Related Art

A software package named Flashpoint provided by Knowledge Ware, Inc. is utilized to create screens for customer service representatives. PRISM software provided by Marcam is used to operate IBM AS/400 mini computers to support terminals using Flashpoint software. SMS software, supplied by ITLS of Canada, resides on the AS/400 platform to support the logistics function and TRACS software supplied by Westeley Development Corp., supports PCs driven by the TRACS software. Rhumba/400 Software is supplied by Wall Data, as well as PC Support by IBM to enable communications between an AS/400 platform and PC terminals. Furthermore, Software 2K provided by Software 2000 of Boston, Mass. supports financial functions. Marcam has issued U.S. Pat. No. 4,864,507 pertaining to a method and apparatus for process manufacture control. The aforementioned vendor software and patent are hereby incorporated by reference.

None of the foregoing software is integrated to provide an efficient order management system. In the past, these software packages operated vertically. This prior architecture does not provide the necessary system integration for efficient real time data management.

SUMMARY OF THE INVENTION

The present invention has the ability to efficiently receive customer orders, process them, create appropriate financial records and coordinate this information with the inventory and manufacturing functions to prepare and load consolidated shipments for transportation to a customer. This is accomplished by touching each sub-system's data base on a real time basis by horizontal integration of each system to create a harmonious flow of data between systems. This unique concept allows for continual updating of the system over time.

Most importantly, a deal with a customer is settled before the order is taken by using the horizontal data flow between systems to verify availability to meet the order, integrate customer data and price the deal while speaking to the customer.

It is an object of this invention to efficiently receive and process customer orders.

It is another objective of this invention to minimize costs of a food processing and supply business.

It is yet another object of this invention to create a system tailored to customer profiles for the delivery of products.

It is still another object of the invention to efficiently manage inventory.

It is yet another object of the invention to efficiently assemble and deliver loads of products to customers.

It is further an object of this invention to efficiently purchase and account for materials.

It is still another object of this invention to create a financial system to support each of the above objectives.

It is an object of this invention to create and integrate a system incorporating the above features at minimal cost.

It is still another object of this invention to provide business control features to manage such a system.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is better understood by reading the following Detailed Description of the Preferred Embodiments with reference to the accompanying drawing figures, in which like reference numerals refer to like elements throughout, and in which:

FIG. 1 illustrates an overview of the order management system.

FIG. 1a illustrates the application software architecture.

FIG. 1b illustrates the order management update and controls.

FIG. 2 illustrates the order fulfillment and architecture.

FIG. 3 illustrates an order fulfillment customer representative screen.

FIG. 4 illustrates an order fulfillment customer/master file maintenance selection screen for use by a customer service representative.

FIG. 5 illustrates an order fulfillment screen for use by a customer service representative to maintain customer master controls.

FIG. 6 illustrates a screen for order entry by a customer service representative.

FIG. 7 illustrates the order acceptance system.

FIG. 8 illustrates the system management software/TRACS architecture.

FIG. 9 illustrates, in diagrammatic form, the delivery process for managing and executing the activities associated with inbound and outbound movement of goods.

FIG. 10 illustrates diagrammatically the traffic management network of all incoming and outgoing deliveries.

FIG. 11 illustrates the logistics system interfaces.

FIG. 12 illustrates the delivery subprocess for order delivery planning.

FIG. 13 illustrates the delivery process flow charts for order consolidation.

FIG. 14 illustrates the delivery subprocess for carrier selection.

FIG. 15 illustrates a delivery subprocess for load release.

FIG. 16 illustrates a delivery subprocess for freight claim management.

FIG. 17 illustrates a delivery subprocess for freight claim management.

FIG. 18 illustrates a delivery subprocess for freight claim management.

FIG. 19 illustrates a delivery subprocess for freight payment/reconciliation.

FIG. 20 illustrates a delivery subprocess for proof of delivery.

FIG. 21 illustrates a product flow from receipt to the staging area for storage and ultimately shipment.

FIG. 22 illustrates a flow chart of a transaction (TR).

FIG. 23 illustrates a system for hand-held warehouse reading devices interconnected to a dedicated network through a radio base for inputting and receiving warehouse data.

FIG. 24 illustrates an inventory management normal cycle overview.

FIG. 25 illustrates a production receiving schematic.

FIG. 26 illustrates a vendor receiving schematic.

FIG. 27 illustrates a put-away schematic for identifying and placing goods received.

FIG. 28 illustrates a schematic for workload planning for receiving orders and placing shipments.

FIG. 29 illustrates an order-pick schematic for selecting orders and delivering to destinations.

FIG. 30 illustrates a batch-pick schematic for selecting orders and delivering pallets of such orders to warehouse for put away.

FIG. 31 illustrates an order load and closeout schematic showing the process for documenting orders and their ultimate filing into the system of this invention.

FIG. 32 illustrates a cycle count diagram for determining product scheduled for processing and movement to inventory as well as updating inventory.

FIG. 33 illustrates year-end physical schematic to provide a year-end inventory count.

FIG. 34 illustrates a consolidation schematic showing the process of moving goods to new locations for efficient storage and processing.

FIG. 35 illustrates a return schematic demonstrating the receipt of goods that are returned to either inventory or to quarantine.

FIG. 36 illustrates an outside storage schematic showing the movement of goods from inventory to storage and ultimately receiving.

FIG. 37 illustrates the standardized process and end solution for creating an electronic catalog and system to support it.

FIG. 38 illustrates the relationship of an electronic catalog to the various components using it.

FIG. 39 illustrates the information stored in an electronic catalog.

FIG. 40 illustrates how the electronic catalog accesses information in various data bases.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

In describing preferred embodiments of the present invention illustrated in the drawings, specific terminology is employed for the sake of clarity. However, the invention is not intended to be limited to the specific terminology so selected, and it is to be understood that each specific element includes all technical equivalents which operate in a similar manner to accomplish a similar purpose.

I. ORDER MANAGEMENT

Referring to FIG. 1, it shows an overall schematic of the order processing data flow, based on an IBM AS/400 platform. The figure is self-explanatory and will be amplified in the following description of this invention by reference to the specific figures that go into the necessary detail.

Referring to FIG. 1a, there is shown the software functions resident in the networked AS/400s and interconnected PCs. The PRISM software resides on AS/400 1.a., Software 2000 resides on AS/400 1.b., and Shipment Management System (SMS) software resides on AS/400 1.c. AS/400's 1.a., 1.b., and 1.c. are networked and support PCs 1.d. each of which has resident enabler software Flashpoint shown as 1.e. Also, residing in these PCs are solution software 1.f. for creating DEALS, purchasing interface, pricing and profitability (hereinafter described). The SMS software in AS/400 1.c. supports PCs 1.g. having Flashpoint software 1.e. and TRACS load builder software 1.h., hereinafter described. The implementation of both solution softwares (1.f. and 1.h.) are unique to this invention.

Generally, the GUI (graphic user interface) consolidates the various fields by pulling data from numerous screens into one screen used by a customer service representative. When a specific field is entered, the interface updates the supporting multiple screens thereby saving time while interacting with a customer. The resulting screen is user friendly and responds to queries in real time.

PRISM software on the AS/400 platform interfaces with Flashpoint software on the PC platforms to allow the creation of the above described user friendly screens, and to interact with other modules of this invention. The enabler software between the PRISM customer order management software and the Flashpoint software is the Rhumba 400 and IBM PC support. This interface also talks to Software 2000 that maintains accounts receivable (A/R) files. It also allows for keeping separate data stored in synchronization without having the data keyed in.

FIG. 1b further describes the relationship of input devices (2 and 4) to the system which captures sales representative and customer activities including financial data. Shown here is the use of Gelco checks (6) and input devices (2 and 4) to input and manage DEALS (8). Gelco (6) is an existing vendor that allows checks to be written to customers for a variety of reasons. The Gelco checks (6) and information from input devices (2 and 4) then are fed into the DEAL system (8), to properly reflect discretionary spending. The information from the DEAL system (8) is transmitted to the order management system and updates the control function (10) where it creates activity reporting (12) to give input for sales representative reports, customer profitability reports, pricing reports and deals and discretionary reports. The information also flows from order management update control to pricing function (14) where the details of pricing are worked out using product costs, freight increments, profit margin, market adjustment and other charges to create correct pricing. Likewise information flows from order management updates and controls to financial systems (16) where appropriate financial records are created. These include invoicing, credit memo, accounts payable checks, price lists and discount lists, among many others.

Referring to FIG. 2 the order fulfillment architecture has multiple inputs from computer integrated manufacturing systems at various locations as well as from warehousing data base (24). Information on the activities at these various sites are fed into the central customer order management (COM) (26) function and at the same time, information is fed to a software package supplied by a vendor known as Software 2000 (28). Accounts receivable and the general ledger functions are created using Software 2000 (28). The foregoing functions are performed on an AS/400 platform. Data from the customer order management system is transmitted to Flashpoint software (30), that resides on personal computers or like equipment such as work stations. This software is used as a basis to create business scripts (32, 34, 36 and 38) that are displayed on each personal computer to aid customer service representatives in taking and creating orders.

FIG. 3 demonstrates one of the screens created for the order fulfillment function used by a customer service representative. Shown in FIG. 3 are the various files that have been created based upon the Flashpoint software. Unique to this system is the windowing of such files in one location for a customer service representative so that he or she does not have to page back and forth through the software while engaged in a discussion with a customer to create an order. As a result, orders are taken and fulfilled promptly in a real time mode because the file folder serves as a main menu which can be navigated using the mouse to select a business event unlike in the past where there was much delay in the process.

FIG. 4 shows another order fulfillment screen used by customer service representatives. It is entitled Customer Master File Maintenance Selection and by use of a mouse the customer service representative can quickly navigate through the basic data on a customer and if necessary update it based upon the interview. This submenu has been customized to a series of radio (40, 42) and push (44) buttons in order that the majority of the navigation can be accomplished by single mouse clicks.

FIG. 5 shows a further screen entitled Maintain Customer Master Control Screen used by customer service representatives. This screen has the basic data for each customer and once again can be navigated promptly to update it if necessary. If the information is correct it is the basis for creating the customer records used throughout this system. This screen is populated by data entered on previous screens in order that the screen user does not have to re-key, thus eliminating a potential for unsynchronized master files. Also, the "Bill To" and "Ship To" screen sequence is customized for this presentation. "Ship To" navigates forward through related screens then automatically navigates in reverse, and activates Software 2000 customer maintenance files saving the operator the navigation.

FIG. 6 is entitled Order Form and it has the basic information blocks to be completed in creating an order by a customer service representative. This screen has the series of buttons added to easily allow access to additional screens. The "Resource Description" (50) and "Sm" (52) fields were pulled in from other screens.

Shown in FIG. 4, 5 and 6 are radio buttons as well as well as normal push buttons to indicate functions that may be selected by the operator to allow real time navigation through the files supporting these screens. The feature of updating files forward and backwards results in error free master files.

II. FINANCIAL

The Exception Resolution process design (103) involves putting in procedures and policies to ensure customer service levels. This begins with the order acceptance process all the way through the collection and application of cash. For any problems that arise, that process will have procedures and policies to handle and resolve them.

Referring to FIG. 7, Order Acceptance (100) is the beginning of the entire process. Data can enter the system via two ways, (1) manual entry from the customer service representative and the tool they use is a Knowledge Ware based application that interacts with the AS/400 PRISM system for manually taking orders or (2) by EDI transmissions. At order acceptance the system goes through a variety of validations shown on the left-hand side of this diagram as a process called Rule Validation (102). Validated order and customer attributes include, but are not limited to, the order lead time required from the customer, their delivery schedules, whether delivery schedules can be met, their credit, available inventories and production times for their products and like rules. This feedback is conveyed to the customer while on the telephone. With the EDI scenario exception reports will be created and conveyed to the customer.

Logistics (104) primary objective is to reduce the outbound and also the inbound freight costs of the organization. This is accomplished in a couple of ways (1) by using software to consolidate the less than truckload shipments to different plants to have better utilization of the trucking operation. It also houses a low cost core carrier list to be utilized to expedite shipping processes and to monitor the performances of carriers.

Pricing (105) is in software residing on a LAN file server. It is geared towards looking at customers, markets and products. In addition, it brings in other business data like product cost, profitability targets, where customer ship-to's are located, freight delivering cost to develop delivery pricing to customer and FOB pricing picking up shipper's dock. Included are market adjustments, overhead, et cetera, to be used to compile and work out a customer product pricing. (Also seen on FIG. 1a (14)).

Warehousing (106) is designed to ensure inventory accuracy, put to away and retrieve inventory in an expedient fashion, to validate the order to ensure what is loaded on the truck, and to ensure all documentation prepared for the shipment is accomplished.

DEALS (8) includes discretionary spending, negotiating deals with customers by writing them an AP check to rebate for performance, initiating a credit memo to them on account, Giving them a "Gelco check" for buying advertisements, or buying down their price for special promotional activities that customers may undertake. Also, the sales representatives will have the ability to put discount lists into the system via this DEAL system (8) to give them a special allowance. This information is fed into PRISM and shows an allowance off of their invoice when invoicing occurs. The sales representative can create a credit memo to issue invoice errors and apply the amount to a pre-set account.

This DEAL system (8) also houses the sales representatives' targets by product category and customer by which they will be measured. This also gathers the data to support customer profitability reporting.

Performance Reporting (112) is where all the data comes together. This is outside of the AS/400 environment, on a LAN file server, to gather data from the order acceptance, the invoicing, the pricing, the shipping and the DEALS (8) function, plus brokerage fees to brokerage companies that service accounts. From this data is generated all of the performance reportings such as sales representative activities, customer profitability, analysis of movement trends and the like. There will be a customer score card created to rate the customer for profitability, volume and the like. This data is used for management decisions related to this customer.

Order Fulfillment (114) is used after order acceptance and it gets the product picked and packed at the warehouse, closes the order, and generates all necessary documents.

Credit Memo (116), G/L (General Ledger) (118), AP (Accounts Payable) System (120), Accounts Receivable System (122), how customer credit is established, and procedures (how they interact at order entry time is important), and are all traditional accounting functions.

III. LOGISTICS

ORDER PLANNING

Referring to FIG. 8 entitled SMS/TRACS Architecture, (SMS, also known as shipment management system) which is a vendor supplied software. The diagram shown in this figure lays out the relationship of the hardware in this system as well as the supporting software. It is understandable by one skilled in the art upon examining this figure and will only be touched upon lightly. The main frame has resident software for providing order management. This software communicates with the AS/400 (150) which is networked with other AS/400s to create the basic information network. Residing on the AS/400 (150) platform is the SMS Software supplied by ITLS of Canada, and on the PCs the TRACS Software supplied by Westeley Development Corp. of Stamford, Conn. This combined software has the functions indicated on the drawing and also communicates with an accounting function supported by Software 2000 (28). The SMS/TRACS software residing in the AS/400 (150) further supports PCs (152) or work stations or the like with information generated by the AS/400 (150) resident software on rates, customer information and less than full truckload shipments. This software provides for consolidation of less than full loads, as well as creates shipment and load reports. It likewise creates information feeding back to the AS/400 (150) to create shipping instructions. The use of this hardware and software combination uniquely supports the logistics system for load building. The load builder function includes load tendering, load planning, load confirmation and load inquiry to build loads. This allows handling multiple orders to create a load.

FIG. 9 is a diagram of the delivery process for managing and executing activities associated with inbound and outbound movement of goods. Shown in the diagram is the function of taking incoming orders (154) from customers as well as distribution center replenishment, information on returns and purchase of raw materials generated through POs. This information flows to the order consolidation function (156) from which information goes to the function for carrier selection (158). The carrier selection function (158), as further described hereafter, goes through a series of decision making steps to select the correct carrier for the correct destination and load for that carrier and takes this information and sends it to the load release receipt function (160) where data is created to input to the carrier monitoring function (162) as the well as shipment tracking function (164). From the shipping tracking function (164) information flows to the freight claim management function (166) as well as the freight payment reconciliation function (168). There is feedback from the freight claim management function (166) to the carrier monitoring function (162) as the case may be. The carrier selection function (158), carrier monitoring function (162), shipment tracking function (164) and the freight payment function (166) all have EDI connections to customers to create data bases necessary to support these functions.

FIG. 10 is a diagram of the traffic management network showing how goods are received and distributed using the system. It is a system that allows for multiple tracing of carriers available to deliver goods to customers.

FIG. 11 is a diagram of the logistics system interface. Shown in this interface are the various software and communications that support the system. The Software 2000 (28) supports the accounts payable function as previously described. PRISM software (170) supports the order management function and Software 2000 (28) supports the accounts receivable function, all of which feed into logistics systems (104) where the various bits of data created are used for support. From the logistics system (104) outbound orders (172) are received as well as internal information on the production of goods. The logistics system (104) is connected through EDI (174) and fax (176) to carriers for tendering and accepting delivery.

Referring to FIG. 12, Order Delivery Planning (300) is where orders are received from the order management system. The first action with the orders is to download them into the system, then sort them based on ship date, and also by priority such as a quick delivery. For example, there are orders for a particular shipping date, those orders would be sorted into full truckloads including those that are LTL (less than a truckload) and customer pickup (the carrier or customer picks the order up with their private fleet i.e., an XYZ truck or customer arranges their own carrier which means that XYZ arranges ABC carrier to come and pick it up). Referring to the schedule load appointment function in Box 306, if it is a customer pickup, then an appointment is scheduled to actually come to the dock and load the product. The warehouse keeps a list of appointments and times, (i.e., eight trucks can load in one hour, and therefore there are eight time slots for one hour increments) and records the trucks schedules. The dotted line is for the carrier to actually call in and confirm or set the appointment with the warehouse. The arrow coming down indicates that the truck will be loaded when the carrier arrives.

If it is not a customer pickup, go to the Full Truckload decision in Box 308 which questions a full truckload or not. Full truckload means did the customer order an entire truckload with their product or is their order on two separate truckloads. For example, is there half an order of frozen and half an order of chilled orange juice? In the present system, these are two separate orders, and therefore do not create a full truckload even though in theory it would be a full truckload. If there is a full truckload you go to "carrier selection" which will be two or three processes down the decision tree. If you don't, the orders are passed onto order consolidation. Again, the process here is to determine which are full truckloads and which are LTL shipments. The LTL shipments would again go to the order consolidation function which is one of the keys to the entire process.

ORDER CONSOLIDATION

Referring to FIG. 13, Box 310 this is the same decision process that was made in the order delivery planning process of FIG. 12, but instead, if a full truckload the arrow goes to the left and goes down to carrier selection. There is no need to go through consolidation because it is a full truckload. If it is not a full truckload, go to the order consolidation function of Box 312. This results in putting LTL shipments into a full truckload. The system goes through certain decisions to determine what is the optimal truckload. The next few boxes are decisions which are made by the software. The AS/400 is able to load build correctly on its resident logic. It is a matter of a logistic planner's judgment to override the internal logic. For the majority of the loads, the load decision is made in the PC based software package to perform the optimal consolidation. The decisions that the actual software goes through are based on a transportation algorithm, in software on the AS/400 Platform shown in Box 314. It looks at a delivery window which means when does that product need to be delivered? Most orders are sorted by shipment date. If an order is shipped on Tuesday, the query is when does it need to be delivered? The query is, how long does it take for a product to get to a certain area, in other words, from Dade City to California it could take two days, but from Dade City to Las Vegas it also might take two days. This data is used to decide whether those two orders can go on the same truck, i.e., can it fit the delivery window based on the guaranteed delivery date for that customer? The system looks at a window delivery and asks if the loads can be consolidated based on transit time, et cetera.

Further, the function shown in Box 316 asks if they can be consolidated if the delivery window is compatible and if the customer shipped to is the same?

The next decision is shown in Box 318 and asks if it is a truckload? Of course, if a full truckload is determined there is no need to proceed. This would be the optimal consolidation if a half a truckload of frozen and a half a truckload of chilled orange juice go to the same customer. Then you have full a truckload going to the same customer and delivered on the same day, for optimal consolidation. If the arrow to the left says there is a full truckload, the decision tree goes down immediately into carrier selection.

If the decision shown in Box 320 says there is not a full truckload but two orders are going to the same customer, it then looks at other orders going in the same destination area. There is basically one more check within the destination area. If not, it goes back into the rest of the orders for the next consolidation which is the arrow to the right.

If it is in the same destination area, then it goes to Box 322 the origin area locations 1 and 2. The system would try to put all orders for location 1 before putting location 2. If not in the same origin area the arrow goes to the right and it goes back into potential consolidation with other orders. If yes, it is in the origin area, then the decision arrow going down indicates it might be consolidated.

In the decision sh