System and Method for Partial Order Filling

1. Field of the Invention

The present invention relates generally to a system and method for automatically filling multiple orders of different quantities and types of items. More specifically, a system is provided wherein the quantities of any Stock Keeping Unit (SKU) for an order may be less than the standard package quantity for that particular SKU such that redistribution of SKU's into multiple transport units is required, A planning method is implemented for arranging orders into a plurality of transport units containing mixed SKU types, and sequencing the processing of SKU packages and transport units so that the orders are placed by a robotic workcell with a fixed quantity of transport unit fill positions.

2. Description of Related Art

Problems associated with automatically placing a plurality of different SKUs, i.e., brands of items, in a single storage unit are well known in the art. The problem becomes more difficult to solve when the types and quantities of SKUs to be placed in the storage units vary between orders. That is, a first order may require different quantities of several different SKUs and a subsequent order may call for different quantities of the same SKUs, or different quantities of completely different SKUs. Additionally, it can be seen that a problem exists when an order calls for a specific quantity of SKU that is less than the quantity in which the SKU is normally supplied. For example, an order may call for two units of a particular SKU (brand A) and four units of a second SKU (brand B), but brand A is supplied in cases of twelve units. Thus, ten additional units of brand A need to be placed before continuing on to brand B. In order to maximize use of a placing robot, the robot should complete placement of brand A prior to placing any units of brand B.

U.S. Pat. No. 4,588,349 discusses a method of automatically filling a kit with required parts. The parts are held in a container and stored in trays which are placed at a transfer location. A robot removes the selected container and empties it into a kit box. U.S. Pat. No. 5,029,095 describes a system that assembles multiple components wherein the components are placed in one of a plurality of bins and a display indicates a complete kit of parts to be subsequently assembled. U.S. Pat. No. 4,988,256 discusses an apparatus and method of compiling parts into individual kits. An apparatus wherein parts are singulated onto multiple feeders through a gate such that the required parts are transported to a workstation. IBM TDB "Dynamic Database" discusses a database used to manage the data flow through an automatic packaging and palletizing system. A packaging line is divided into zones with an associated computer for each zone. A kitting database is transferred from each computer to the subsequent computer as the items being packaged moves between zones. IBM TDB "Database Structure" describes an automatic parts inventory system. Inventory is stored on pallets that are located in aisles. Information is stored for the pallets based on data indexes in fields in the database. These fields include information such as the types of parts on the pallet, vendor that supplied the parts, date the parts were received, location of the pallet, oldest and newest location of a particular part, and the like.

It can be seen that conventional techniques do not provide any near optimal techniques for placing partial orders by ensuring that the most difficultly placed SKU (brand) is put in the oldest transport units before continuing to place subsequently desired brands.

In contrast to the prior art, the present invention provides a method and apparatus for planning and controlling the placement of particular SKUs (brands of an item) such that orders for less than the SKU package quantity can be placed without the need to impose ordering requirements, i.e. require that orders for the SKU be in the quantity in which it is provided. A computer implemented planning method is used that allows orders for the most difficultly placed SKU to be put in transport units before filling orders for other types of SKUs. In accordance with the present invention, requirements for less than the supplied quantity of a first type of SKU are combined such that all of the units of the first SKU are placed and orders for partial packages can be filled.

The SKU packages are sorted depending upon their relative difficulty in placing them in transport units. A material handling system, including a work area, robot, conveyors, supply means, transport units and the like, assigns a transport unit corresponding to an order requiring the most difficultly placed SKU to the work area.

Broadly, the planning and control method determines the aggregate number of SKU packages, e.g. product cases, needed for the orders, expressed as the number of full packages and the number of SKUs in a package for partial packages. The input sequence of SKU packages is determined wherein packages having the greatest number of different orders corresponding thereto (most difficult to place) are required to be the first ones used of that SKU in the input sequence. The number of transport units per order is computed and the sequence for filling the transport units is then determined. Different transport units corresponding to different orders to be filled are output from the system in a sequence that economizes the number of transport unit filling positions concurrently engaged in the work area.

The planning method of the present invention determines the sequence for filling transport units by initially assigning transport units to the work area and giving it a sequence number. The sequence number is increased for each additional new unit assigned to the work area, such that lower numbers indicate older transport units. Only one transport unit per order is assigned to the work area at a single time, thus providing more possibilities for each work area position that can be used by the planning method. The SKUs are then ranked depending on their difficulty in placement. If a partial SKU package is required, it is placed before any other full packages of that SKU. The planning method considers a partial package as a normal package until the partial package is placed, then a full package is considered normal. The transport units may contained unfilled positions, i.e. holes, since the order and transport unit capacity do not always match. Finally, a transport unit is completed when it is full, it is the last unit of an order, or when the planning method assigns holes to the unit.

The planning method completes the oldest transport unit in the work area and attempts to place the most difficult SKUs first. The difficulty in placing a SKU is determined by dividing the number of orders for an SKU by the number of packages of that SKU ordered. The higher the quotient, the more transport units are concurrently needed to redistribute an SKU package. When a SKU is examined for placement, the planning method determines whether the next package for that SKU can be placed: (1) entirely in the oldest transport unit; (2) in the oldest unit in combination with other transport units currently in the work area; or (3) be placed in the oldest unit in combination with existing transport units in the work area and new units assigned to the work area in order to complete this order. When the SKU is placed, the transport units are tested and, if complete, removed from the work area. In this manner, all orders for a particular SKU are combined and this combined requirement is compared with the items in the SKU package such that placement of the entire contents of the package is achieved.

In accordance with the previous summary, objects features and advantages of the present invention will become apparent to one skilled in the art from the subsequent description and the appended claims taken in conjunction with the accompanying drawings.

FIG. 1 is a plan view of a material handling system in accordance with the present invention;

FIG. 2 is a block diagram of the hardware control for the material handling system of FIG. 1;

FIG. 3 is a block diagram of the process control of the present invention;

FIG. 4 illustrates the software architecture to control the placement of different type of items in accordance with the present invention;

FIG. 5 is a display of the operator interface used in a particular embodiment of the present invention;

FIG. 6 is a diagram showing transport units and their flow through the work area of the material handling system;

FIG. 7 shows the flow of control between a process control computer and a host computer; and

FIGS. 8A-8F are flowcharts that represent the planning method of the present invention.

Referring to FIG. 1, the hardware robotic conveyor and picking system 1 of the present invention is shown and will now be described. It should be noted that the planning and control method of the present invention was developed for use in a bottle ordering and filling application wherein a plurality of different brands of beverages are placed, according to specific orders, in transport units and provided to customers. Warehouse stock consisting of different supply means, i.e. packages, or product cases of different stock keeping units (brands) are placed on an input conveyor 26 and then transported via a series of warehouse stock accumulating conveyor buffers 28, 30 and 32. Dual input conveyors 33 are then used such that two cases can be constantly going into and out of work area 15. That is, one case can be entering work area 15 while another is exiting and being replaced by a subsequent case. Cases 16 are shown at unloading point 17 of the workcell 15 and are in position to be unloaded by a robot and placed in totes 12 within filling positions 14 of workcell 15. It should be noted that totes 12 are used to exemplify a type of transport unit used in the preferred embodiment of the present invention. Of course other types of transport units are contemplated by the present invention, such as partitioned areas on a conveyor, or the like. It will be understood by those skilled in the art, that a robot, such as is commercially available by Automaker, can be utilized by the present invention. Robot 2 will have the ability to access each of the filling positions 14 of workcell 15 and to move specific items of warehouse stock from cases 16 to totes 12 in fill positions 14 by means of a gripper 4, such as an end of arm tool, or the like. The robot 2 may be suspended by a gantry 6 above the work area 15 and movable therealong between unloading points 17 and fill positions 14. The robot 2 and gripper 4 positions may be controllable by a plurality of electric servo motors and appropriate control hardware and software (not shown). It will further be noted that the gripper 4 can be made to be interchangeable such that warehouse stock units other than bottles can be picked and placed. That is, the present invention is not limited to the placement of bottles in totes, but is applicable and encompasses any situation wherein a plurality of different types of warehouse stock units are to be repackaged in varying quantities to fill customers orders.

Empty totes 12 enter workcell 15 from conveyor 10 and are placed in fill positions 14 by a series of gates or the like which direct totes 12 to the proper filling position 14. In a preferred embodiment, 28 tote filling positions 14 were provided in work area 15. Of course, the number of fill positions 14 will vary depending on the type of material handling application being implemented. Once in fill position 14, the robot places the warehouse stock units, e.g. bottles into the awaiting totes 12 and empty warehouse stock containers 11, such as cases are then transported away from workcell 15 and diverted onto conveyor 34 which directs the empty cases 11 away for reuse, recycling, or the like. Once the bottles have been placed in totes 12, in accordance with the planning method of the present invention, the completed totes 20 exit workcell 15 along conveyor 18 and are transported to accumulating conveyor 22 and subsequently to customer output conveyor 24 wherein the completed totes are distributed to the customer, according to each customer order. It should be noted that after placement of the bottles in totes 12, a packing list is placed in each tote to identify the tote with a specific customer order. Thus, it can be seen that the robot 2 and conveyors work in concert to assemble the bottles into the transport units 12.

Referring to FIG. 2, the hardware control system of the robotic system of FIG. 1, generally referred to by reference numeral 1 is shown. A host computer system 100, such as an AS/400 midrange computer, manufactured and sold by the IBM Corporation, or the like is interconnected to a picking system controller 102, which is a typical personal computer, such as the IBM PS/2 computer. PSC 102 is then interconnected with several peripheral input/output devices such as keyboard 106, printer 112, as well as a packing list printer 114 which is used to provide the packing slip for each completed tote as it leaves workcell 15. Additionally, a display 110 and hand held bar code scanner 108 are interconnected with controller 102. Robot controller 104 is also interconnected with PSC controller 102. It can be seen that keyboard 106, printer 112, and display 110 will allow an operator to interface with the PSC controller 102. The hand held bar code scanner 108 also provides input from the operator to the PSC controller 102. The operator reads the bar code on each warehouse stock case that enters the stock accumulating conveyor 26 such that the control system can keep track of particular brands being input.

Conveyor controller 116 is also in communication with controller 102 and further controls the conveying system shown in FIG. 1. Additional bar code scanners 118 input data to conveyor controller 116. The bar code scanners 118 are placed along the conveyors shown in FIG. 1. More particularly, one scanner is placed along the input conveyors 28, 30, or 32, with the remaining two bar code scanners 118 placed on each end of workcell 15 such that an empty tote 12 can be associated with a filling position 14, and the order in which completed totes leave the workcell 15 can be determined, i.e. the totes are tracked in the work cell 15 with the first totes entering the work area 15 being considered to be the oldest. A robot axis controller 120 is also provided and communicates with the robot controller 104. Robot axis controller 120 controls the robot, schematically represented by block 122 in FIG. 2 as it moves between case unload stations 17 and filling positions 14. The robot gripper 124 is controlled directly by the robot controller 104 such that bottles, or other items, can be removed from warehouse stock cases 16 and placed into awaiting empty totes 12 within workcell 15. Indicating lights 126 are used by the operator for robot error handling. For example, a blue flashing light indicates that the line is down and in need of immediate attention, whereas a low parts intervention, such as an empty stock input conveyor or lack of empty totes, is signal by flashing yellow lights. Red and green lights may indicate the status of the robot i.e. whether it is off or on.

FIG. 3 shows the software architecture that allows the hardware controllers and I/O devices shown in FIG. 2 to operate in conjunction with one another. It should be noted that these processes are also described by the pseudo code attached hereto as appendices A-I.

The control system shown in FIG. 3, consists of high-level processes that execute on picking system controller 102 and the robot controller 104. These processes are compiled separately and independently loaded and executed. They communicate with one another through a common database and through the exchange of asynchronous messages passed by using local area network (LAN) based protocols, or the like. With the exception of the planner and database update process, the remaining processes are continuously executing when the system is operational. The planner and database update process are loaded and executed on command and terminate when their work is completed. Database 200 is used to store information relating to each days production. This data is input to the host computer 100 and downloaded to database 200 and is then accessible by controller 102. A host PC support process 202 is utilized to allow host computer 100 and controller 102 to interface with database 200. Once the next days order file is downloaded to the database 200 from computer 100, the planner process 210 is invoked by host computer 100 to plan the picking and placing of bottles and cases for the next days orders. The planning method is described in detail below in conjunction with FIGS. 8a-8f. In general, the planning method generates a sequence of totes for the robot to fill in a sequence based upon an ordered introduction of individual cases into the work area. Upon completion of the planning method process, the production schedule is then uploaded to the host computer 100 from controller 102, where the planning method is implemented. Controller 102 then waits for the host computer to download the final data file that will include more detail regarding shipping docks, truck assignments and the like for the orders, i.e. data that is not accessed by the planning method. The database updates the process 204 then installs the additional data into the data base 200 such that it is accessible by controller 102, for use during packing slip printing. Next, the robot application 212 is implemented and manages the coordinated operation of the robot 122 and gripper 124 based on the planning method 210. Additionally, the robot application 212 controls the status lights 126 that are used to signal the operator in the event of a robot error. Finally, the robot application also coordinates movement with the conveyor controller 116 via conveyor interface process 218 which communicates directly with the conveyor controller 116. The conveyor interface controls details of the conveyor and its status in comparison with the rest of the system. That is, whether the conveyor is moving totes through the work cell, directing totes into filling positions 14, or the like. The conveyor interface also receives data from the bar code readers 118.

The operator interface process 220 which is responsible for user interfaces with the system including status screens on display 110, selection menus, dialogue menus and the like. Operator input is expressed through the menu selection by keystrokes and hand held bar code scanner 108 which causes changes to be made in the database 200 and messages to be passed onto other related processes. The handheld bar code scanner 108 is interfaced to a keyboard port and appears to the operator interface process 220 as additional keystrokes. Of course, a touch screen, stylus, or the like could be used to provide input to the operator interface process and is contemplated by those skilled in the art. One of the primary functions of the operator interface process 220 is to indicate to the operator the sequence of product cases to be loaded on the input conveyor. Menu selections are also provided to start, pause, restart or shut down the system and the operator is able to request reports such as a list of product cases needed for all of the days orders. FIG. 5 is a typical screen generated by operator interface process 220. It can be seen that a field is present for the SKU number which may entered through the keyboard 106 or hand held bar code scanner 108. Information regarding the status of the system is also shown and currently indicates the system is active, the conveyor is on-line, the robot is off-line and the planner process is idle. Information indicating the next case quantity is shown along with the next case configuration from the warehouse where an X indicates bottles or other items that are present and an 0 indicate empty positions. The next brand and quantity field shows a code and a representative brand of items along with the quantity required. In this manner, the operator knows the sequence in which to load input conveyor 26 with warehouse stock. Function keys also allow the process to be exited, help text to be displayed, changes to be made to the case quantity, and the like. Additionally, files can be generated and reports printed regarding the status of the data accessed by the operator interface process. It should be noted that replacement of the operator by an automated flow rack conveyor system is possible and is similarly contemplated by those skilled in the art.

Error handler process 206 controls the handling of error conditions that are detected by other processes and sent as messages to the error handler process. Depending on the configuration and type of error condition, the error handler process 206 may ignore the error, record it in a log file or force the system to stop until the condition is acknowledged by the operator. The case wherein the system stops until the operator acknowledges the condition is referred to as intervention which is passed as a message to the operator intervention process 208 which supervises the presentation of these error condition to the operator via the operator interface process 220, and supervises solicitation of the operator response. The system query (SQL) logic function process 216 is a collection of functions used to store data in SQL tables, manipulate and update the data in the tables and retrieve data from the SQL tables. This data is utilized by the processes shown in FIG. 3 during normal operations. The data stored in the SQL tables is associated with processing the days picking and placement run. Data structures are used by the individual processes to retrieve data from the SQL tables, store data therein and pass data between the processes. The SQL tables include information relating orders, status, brands, cases, totes, customers and the like. Query manager process 222 receives information from an operator interface process 220 and is used to print reports regarding the status of operations such that error conditions, quantities and other data are printed. Finally, the process manager 214 is responsible for retrieving and updating the SQL status tables regarding the robotic application process, update tote records which include assigning a bar code to a tote and entering the actual quantities of brands placed in the tote by the robot. The process manager 214 also prints the tote packing slips which are placed in the tote as they exit workcell 15. In particular, when the robot application process starts, it requests a copy of the system status record from the process manager 214. This copy of the status record is obtained from the SQL status table and sent to the robot application process 212. If the robot application updates the status, the message is sent to the process manager 214 which in turns updates the status record in the SQL status table. As totes are completed by the robot and leave the workcell a message is sent to the process manager 214 indicating the bar code for the tote, from bar code reader 118 and actual quantities of each brand loaded in the tote. The process manager 214 then updates the SQL totes table with this information. When a tote is scanned by a bar code reader when exiting the workcell 15 a message is sent to the process manager 214 requesting a packing list be printed for the identified tote bar code. The process manager then collects the required data and prints the tote packing list.

Referring to FIG. 4, the processes of FIG. 3 and hardware of FIG. 2 are shown in relation to one another. Remote host 100 implements PC support 202 in order to download information to shared database 200. Picking system controller 102 implements the operator interface process to allow for an operator to start the system, print reports, print packing slips, update and add records to the database, view the system error log file, or the like. Error handler 206 determines error conditions and generates messages for the operator intervention handler 208 when operator action is required. The process manager application is implemented on picking system controller 102 and controls packing list printer 114. The conveyor interface process is also run on PSC 102 and supervises conveyor controller 116 which in turn controls the conveyor hardware system. Planner 210 is loaded and run on system controller 102 based on data input from remote host 100 via PC support 202. The database update process 204 is used to add information to the customer order data initially downloaded from remote host 100. The robot controller 104 implements robot application process 212 which takes the order information as set forth by the planner process, and input to DB 200, in the form of a set of tote sequence numbers and the number of bottles required by each tote. A placement schedule is then generated for the robot to follow that will assemble the proper quantity and types of bottles in the corresponding totes. In this manner, the planner method controls the picking of bottles from the input supply units (cases), and their placement in an appropriate transport unit, in accordance with the customer orders. The supply units are sequenced such that the cases that are the most difficult to place, i.e. the cases that have the most customer orders associated therewith, enter the work area 15 first. The planner then causes, via the data input to database 200, the placement of bottles in the appropriate transport unit 20. The robot application 212 is in communication with conveyor controller 116 in order to coordinate the operations therebetween. Additionally, robot application 212 controls the physical movement of the robot by controlling the robot access 122 and robot gripper 124. Additionally robot application 212 supervises the status indication lights 126 to provide data to the operator relating to the current state of the robot.

Referring to FIG. 6, a flow diagram illustrates the inputs and outputs to workcell 15. Warehouse stock units 16, e.g. cases of bottles, are input via conveyor 26 to two case pick positions 17 (FIG. 1). Simultaneously, empty shipping totes 12 are input to the work cell 15 along conveyor 10 and directed to designated tote filling positions 14 within work cell 15. The robot then places different brands from the cases 16 into totes 12 based upon the planning method of the present invention. It should be noted in FIG. 6 that letters indicate different brands of items and dots indicate empty positions. Thus, it can be seen that product cases 16 each include one brand which may then be distributed among the totes 12 based on the planning method. Further, it should be noted that not only will the planning method of the present invention distribute partial case quantities among various orders, i.e. one case of product can be distributed in partial case quantities among more than one order, the planning method also anticipates product cases 16 wherein less than a full quantity of products is provided for distribution among the totes 12. Once a case of product 16 is completely distributed among one or more customer orders, the empty cases 11 exit along conveyor 34 for reuse or recycling. The completed totes 20 are then provided with a packing slip and exit workcell 15 along conveyor 18 to a customer pickup area, shipping docks, or the like. It can be seen that the planning method of the present invention allows product cases to be partially distributed among various orders and cases having less than a full quantity of product therein to be placed among orders in partial case quantities.

FIG. 7 shows the flow of control between host computer 100 and the picking system controller 102 in order to put the appropriate information in database 200 that will allow the robot picking system to fill customer orders based upon the planning method. Initially host 100 downloads customer orders to the picking system controller 102 which is physically located on the plant floor proximate the workcell 15. Customer orders include information such as a customer number, shipping date, description, quantity, brand code, locator code (where operator can find the brands required), and the like. The host 100 then invokes the executable planner process on picking system controller 102 which in turn runs the planner process and schedules subsequent activities for the robot and conveyor based upon the order files previously provided by host 100. A tote information file is then generated and uploaded to the host system by the planner process. This file includes one record for each brand to be placed in each tote and includes information such as customer number, brand codes, quantity of items ordered, and the like. The host computer 100 then downloads a customer placement file to picking system controller 102 after the tote orders file is uploaded. The placement file specifies from which part of the warehouse a customer's order is shipped, thereby allowing totes to be placed in the most convenient portion of the plant for customer shipping. A customer placement file includes information such as customer number, location in the building from which the order is shipped, bill of lading number, and the like. The host computer then invokes the database update executable process 204 on the picking system controller 102 which runs the process and updates the tote information and the database 200 based upon the placement information previously downloaded from host 100. Subsequent to updating the database 200 with the placement information, the system is ready to run the order.

The planning method of the present invention will now be described with reference to the flow chart of FIGS. 8a-8f. This planning method is a computer executable process and shown in more detail with the accompanying pseudocode of Appendix E. At step 1 the process starts and step 2 determines if all orders to be filled have been planned. If so, the planner method is done and ends at step 3. If, however, all orders have not been planned, then step 4 determines if there are any totes 12 in workcell 15. This determination is made based on the planning of previous customer orders since the planning method executes prior to physical totes being in the workcell. If, at step 4 it is determined that no totes are in the workcell, then the planning method determines the most difficult stock keeping unit, e.g. brand or type of item, to place in the transport unit. Difficulty in placement is determined by the ratio of the highest number of customer requests, or orders, per warehouse stock case, i.e. supply means. That is, a case having 12 bottles therein with 6 customer orders for those 12 bottles (e.g. 2 bottles per order) will be more difficult to place then a case with 12 bottles therein corresponding to a single customer order for the entire 12 bottles. In particular, the difficulty is determined by a statistic which is generated by dividing the number of orders for a particular brand by a number of cases used. The higher the number, the more difficult it is to use the brand since more totes are required from particular orders to be in the workcell at a given time. Once the most difficult SKU is determined, the planning method assigns a tote to the workcell from any order using this particular SKU. At step 6, the planning method finds the oldest tote in the workcell and sorts the stock keeping units by ordering them in a sequence needed to complete the associated customer order (request) from most difficult to the most easiest, using the method of step 5, above. At step 7, the next most difficult stock keeping unit needed to complete the customer order associated with the oldest tote is chosen. The method of the present invention then determines the package quantity of stock keeping unit at step 8. That is, how many units, e.g. bottles are in the case being distributed by the robot to the totes in the workcell. Step 9 then determines the unit count of the SKU package that can be assigned to the oldest tote, i.e. how many bottles from the SKU package can be placed in the oldest tote in the workcell. The package quantity is a predetermined quantity that will usually be a case quantity of the item being placed (i.e. 12 or 24 bottles), but can be any number since the operator can tell the system how many items (bottles) make up the predetermined quantity through the hand held bar code scanner 108. Step 10 then determines if the unit count requirements of the oldest tote in the workcell are greater than or equal to the package quantity and if so, the planning method has placed the entire SKU package, e.g. the entire case of bottles, and the process returns to step 2 to determine if all orders have been planned. However, if the required unit count is not greater than or equal to the quantity in the SKU package, the process continues to step 11 where its determined if the required unit count is equal to zero. If so, the process returns to step 7 because none of the units in the SKU package being considered is required by the oldest tote in the workcell and the process, at step 7, continues to the next most difficult stock keeping unit. If, at step 11, the required unit count is not equal to zero, then it must be less than the package quantity in the stock keeping unit package being considered. At this point, the process at step 12 then chooses the next assigned tote from the sorted order of oldest to newest, i.e. the next oldest tote which has been in the workcell the longest. Step 13, then determines the required unit count for the particular stock keeping units in the package being considered that are assignable to the next oldest selected tote, and then adds this required unit count to the existing count. In this manner, the requirements for the oldest and next oldest tote are combined. The process then, at step 14, determines if the new unit count requirement are greater than or equal to the package quantity and if so the planning method considers the particular stock keeping unit package to be placed and continues to step 20 and assigns the SKUs in the package to totes where the counts are equal to zero. Step 21 then ejects completed totes from the workcell 15 and the process then returns to step 2 to consider another customer order. If at step 14, the count of required units is not greater than or equal to the package quantity then the process continues to step 15 which determines if all of the totes assigned to the workcell have been checked for the particular SKU being considered. That is, have all totes of the ordered list of totes from oldest newest been checked for the SKU being considered. If not, the process returns to step 12 to choose the next assigned tote in order from oldest to newest and determines if any SKUs in the package being considered are required. If all of the totes assigned to the workcell have been checked for the particular SKU, then the process at step 16 determines if the remaining quantity requirements needed to use all of the SKU for the order associated with the oldest tote fit in the oldest tote. That is, are there any empty spaces in the oldest tote that will accommodate the remaining quantity of the stock keeping units. If so, the process continues to step 17 where it is determined if there are any empty positions available in the workcell to assign a pending tote. If so, the process proceeds to step 22 where the planning method selects the next order to be filled from those orders not presently associated with any totes currently in the workcell. These orders are sorted in sequence from highest use of the SKU being considered for placement to the lowest use. At step 22, a new tote is added to the pending list for the selected order and the required unit count of the SKU to be received by the newly assigned tote is added to the existing unit count requirements. At step 24 it is then determined if the unit count requirements are now greater than or equal to the SKU package quantity and if so, the pending tote(s) are assigned to the workcell at step 25. Subsequent to step 25, process proceeds to step 20, as previously described. If at step 24 the required unit count is not greater than or equal to the SKU package quantity being placed, the process returns to step 17 where it is again determined if there are empty filling positions available to assign a pending tote. If so, the planning process of the present invention iterates through steps 17 and 22-25 as previously described. If there are no empty positions in the workcell available to assign a pending tote, the present invention continues to step 18 where it is determined if placement of all the brands has been attempted. In other words, step 18 determines if all of the other stock keeping units on the list, sorted by most difficult to least difficult units to place (determined in step 5) have been tried. If not, the process returns to step 7 and the next most difficult brand, or SKU is chosen for placement. If at step 18 it is determined that an attempt has been made to place all of the stock keeping units on the sorted list, then the oldest tote is ejected from the workcell at step 19. Subsequent to step 19, the method of the present invention returns to step 2 to determine if all orders have been planned and if so ends at step 3.

It is again emphasized that the present invention has been described in terms of stock keeping units which are different brands of bottles and packages that are cases of associated bottles, but it should be understood that the planning and control system of the present invention contemplates use in any kitting type application wherein different types of items are to be combined in specific ways based upon a predetermined allocation. Of course, the different items do not have to be physically configured identically as in the case of bottles since a robot end of arm tool, or gripper, can have different fittings thereon to accommodate differently shaped objects to be picked and then placed in transport units. Further, the present invention provides a system and method where customer orders for partial stock keeping packages (cases) can be accommodated without the need to require customers to order items in specific quantities. That is, customers may order one bottle or 19 bottles of a particular brand and the method of the present invention will place them in transport units associated with that particular customer. Thus, the present invention provides a more efficient distribution system than those currently in use which require customer orders to be in case quantities only.

Attached hereto are appendices A-I which are the pseudocode that corresponds to the processes illustrated in FIG. 3 and previously described with reference thereto. More particularly: Appendix A is the operator interface 220 pseudocode; Appendix B is the error handler 206 and operator intervention 208 pseudocode; Appendix C is the process manager 214 pseudocode; Appendix D is the conveyor interface controller (CIC) 218 pseudocode; Appendix E is the pseudocode for the planner 210 of the present invention; Appendix F is the database update 204 pseudocode; Appendix G is the robot application 212 pseudocode; Appendix H is the query manager 222 pseudocode; and Appendix I is the SQL function 216 pseudocode. It should be understood that this pseudocode is but one example of a method for controlling the picking and placement of items from stock units into transport units and does not limit the scope of the present invention to this example.

Although certain preferred embodiments have been shown and described, it should be noted that many changes and modifications can be made therein without departing from the scope of the appended claims.