Source and destination determination system and method

In a first general aspect, a computer program product tangibly embodied in an information carrier is described. The computer program product includes instructions that, when executed, perform operations for identifying a source or destination for stock. The operations include receiving an electronic request to determine a source or destination for stock, identifying, using a primary rule, a logistic area database object that represents a storage location at one of multiple levels of a hierarchy of storage locations. The logistic area database object is associated with a value that indicates an amount of stock that is associated with the storage location. The operations also include transmitting an identifier specifying the logistic area database object if the value indicates that associated storage location is available as a source or destination. The identifier is used to assign the storage location as the source or destination for the stock.

TECHNICAL FIELD

This application relates to a source and destination determination system and method.

BACKGROUND

As logistic environments, such as warehouses, become larger, management of these environments has become increasingly complex. Current systems can model the logistic environments with software to enable human managers to control execution and planning of the environments. For example, some software models may provide warehouse workers with instructions regarding where to move incoming stock based on the model's knowledge of what locations can store the stock.

Managing stock allocation for storage locations can be a function incorporated into some current software systems. Some systems allocate stock at the most basic unit of the logistic environment. For example, the system can allocate stock to be stored or removed from bins, if the bin is the most basic unit of storage for the warehouse.

Additionally, some current software systems are designed only for allocating stock in warehouse logistic environments. In these systems, the locations that are allocated can be limited to physical storage space within the warehouse, such as bins. Also, the bins can be assigned to a particular product. When that bin runs out of the product, it can remain empty for a period of time until another shipment of that product arrives.

SUMMARY

The present application relates to a system and method for determining a source or destination for stock in a logistic environment.

In a first general aspect, a computer program product tangibly embodied in an information carrier is described. The computer program product includes instructions that, when executed, perform operations for identifying a source or destination for stock. The operations include receiving an electronic request to determine a source or destination for stock, identifying, using a primary rule, a logistic area database object that represents a storage location at one of multiple levels of a hierarchy of storage locations. The logistic area database object is associated with a value that indicates an amount of stock that is associated with the storage location. The operations also include transmitting an identifier specifying the logistic area database object if the value indicates that associated storage location is available as a source or destination. The identifier is used to assign the storage location as the source or destination for the stock.

In selected embodiments, the request to determine the source or destination for the stock may include a request to allocate the stock to or from the location. The primary rule may include sequences that specify an order of categories to be searched. The categories may include logistic area database objects, processing methods that are associated with and define storage characteristics for the logistic area database objects, or electronic documents that include information about deliveries or orders for the stock. The operations may further include matching a delivery of incoming stock with an order for outgoing stock.

Additionally, the operations can further include identifying a second logistic area database object that is at a level in the hierarchy logically below the first identified logistic area database object. The operations can further include determining if a storage location associated with the second logistic area database object is available for allocation and if so transmitting a second identifier specifying the second logistic area database object.

The operations can further include dynamically assigning an association between a material of the stock for which the source or destination has been requested and the identified logistic area database object wherein the identified logistic area database object is not assigned to any material. Furthermore, the operations can further include selecting one logistic area database object over another logistic area database object based on local rules associated with the identified logistic area database object. The local rules can specify characteristics for the storage location.

In other embodiments, the operations can further include applying at least one refinement rule to identify a single logistic area database object if the primary rule identifies more than one logistic area database object. The operations can further include using the identified logistic area database object in a planning module. The amount of stock associated with the storage location can be based on expected stock deliveries or orders. The operations can further include using the identified logistic area database object in an execution module. The amount of stock associated with the storage location can be based on current stock deliveries or orders. The storage location may include physical areas that store stock, resources that transport stock, or production machinery that modifies stock.

In still other embodiments, the storage location can be available as the destination if the storage location includes space for storing the stock or the location is available as the source if the stock available for retrieval. The space for storing the stock or the stock available for retrieval can be available in the future. The operations can further include determining from a set of primary rules which primary rule is to be used to identify the logistic area database object. Determining which primary rule to be used can be based on a material category associated with the stock or a logistic unit associated with the stock, wherein the logistic unit includes a set of attributes that define the stock.

In a second general aspect, a source and destination determination system for identifying a storage location as a source or destination for stock is described. It includes an interface that receives an electronic request for a storage location for stock to be placed or retrieved and a filter that searches categories related to storage locations and returns at least one identifier for a storage location. The storage location is one of multiple levels of a hierarchy of storage locations. The system also includes an availability checker that transmits a request to determine if the storage location is available for stock to be placed or retrieved and transmits the identifier for the storage location if it is available.

In some embodiments, the categories can be selected from a group consisting of logistic area database objects that represent the storage locations for stock, storage behavior methods that are associated with and define storage characteristics for the logistic area database objects, and electronic documents that include information about deliveries or orders for the stock.

Advantages of the systems and techniques described herein may include any or all of the following: improving the flexibility of allocation for different purposes, which represent the different stages of the process (e.g. planning, execution), by facilitating allocation on multiple levels of a hierarchy of storage locations; enabling different types of allocations (e.g. immediate, expected); increasing the power and flexibility of searching for locations for source or destination with or without allocation using sequences not only of locations but also of storage behavior methods and documents; enabling a refining approach to determine the preferred source or destination where multiple valid options exist; increasing simplicity of design and maintenance with use of a single allocation structure for warehouse and production logistic environments; and increasing efficiency by dynamically assigning storage locations to products.

DETAILED DESCRIPTION

A system100ofFIG. 1may receive a request to determine a location for stock placement or for stock retrieval. The system100can then determine, based on a set of rules, whether source or destination determination is required. If determination is required, the system may use a sequence of locations to identify at which hierarchy level (e.g. site, area, bin) the system should search. The location returned may be a general location instead of a specific one. For example, the system100may determine that an Aisle A is an appropriate place to store incoming stock, and any bin on Aisle A may be selected to hold the stock. In this case, an identifier associated with the location Aisle A is returned instead of returning an identifier for a particular bin. Similarly, the system100may receive a request to allocate stock to or from a location. In this case, the source or destination may be determined and then stock may be allocated to or from the determined location.

More specifically,FIG. 1is block diagram of the system100for identifying a location to place or retrieve stock according to one implementation. The system100can include a requesting object102, a Source and Destination Determination (SDD) engine104, and a data repository106. The requesting, or calling, object102transmits a request108for storage location determination to the SDD engine104, as indicated by an arrow110. The SDD engine104uses a primary rule112to search a hierarchy in the repository106for a location to store or retrieve stock, as indicated by an arrow114. The hierarchy here represents a location hierarchy, where each node can represent a different location level, such as an entire warehouse site, an aisle, or a bin in a warehouse. Other hierarchies, such as an inventory hierarchy can reside in the repository as well. The inventory hierarchy can be made up of nodes in a structure that mirrors the location hierarchy and can include an amount of stock for each corresponding node in the location hierarchy.

The SDD engine104can receive an identifier116associated with the location (shown by an arrow118), and determine whether the location is available to store or retrieve stock.

The repository106can hold logistic area database objects (LADOs) that represent physical storage locations in a logistic environment, such as a warehouse or production environments. The LADOs can be logically organized in a tree structure as represented by the location hierarchy. Nodes near the root of the tree, or at a higher level of the tree, may represent greater logical groupings of storage locations. For example, the root node of the tree may represent an entire warehouse, the root's children nodes can represent the aisles in the warehouse, and the lowest leaves in the tree can be individual bins in each of the respective aisles.

A LADO level can be specified in the query for a location transmitted by the SDD engine, and the search for a location can include only LADOs at the specified level. Alternatively, the level can be determined by the SDD engine based on factors, such as the request purpose (e.g., the request is for planning purposes or execution purposes) included in the request. After at least one LADO is identified as a match, the SDD engine receives the associated LADO identifier116as described above in association with the arrow118.

The SDD engine104can determine whether the location associated with the LADO ID116is available by accessing an amount of stock value122that is associated with the LADO ID. For example, if the request for stock determination includes a request to allocate space for incoming stock, the SDD engine can use the stock value122to determine if there is enough room at the location for the incoming stock. Similarly, if the request includes a request to allocate stock from that location for an out-going shipment order, the SDD engine can use the stock value122to determine if there is enough of the specified stock to fulfill the shipment order.

If the location has either enough space or stock to satisfy the request for the storage location determination108, the SDD engine104can transmit the LADO identifier associated with the location to the requesting object102that called the SDD engine, as indicated by an arrow124.

In another implementation, the SDD engine does not transmit the LADO identifier of an available location if other constraints associated with the location indicated that stock should not be removed from or placed at the location. For example, the available LADO can be associated with a constraint, such as an inventory block. The location can have space available for placing the stock, but the inventory block informs the system that no incoming stock may be placed at the location until a physical count of inventory is performed on the stock at the location. In this implementation, the system will not place the stock at the location despite its availability. Instead, the SDD determines and transmits a LADO ID for a location that is both available and not constrained.

FIG. 1shows the arrows110,114,118, and124labeled with letters A-D, respectively. The lettering indicates an order of action for the system100according to one implementation. For example, the first action shown is the transmission of the request108for storage location determination and the last action is the transmission of the LADO identifier116, which corresponds to the location where the stock may be allocated.

FIG. 2is a more detailed block diagram of the system100ofFIG. 1according to one implementation. The system100shown inFIG. 2includes the requesting object102, the SDD engine104, the repository106, an availability service204, and a storage behavior method (SBM) object206. The requesting object102, which can be an order object that includes information that goods need to be stored, transmits the request108for storage location determination to the SDD engine104. The SDD engine can receive the request108through an interface207and use rules to query the repository106, which returns the LADO ID116, which is associated with a location for storing the stock, in response. The SDD engine104, then can transmit a request including the LADO ID116(as shown by an arrow208) to the availability service204, which determines if the location associated with the LADO ID is available for allocation.

In other implementations, the SDD engine104uses a primary rule that defines a search sequence to follow when searching locations. After the search scope is defined, the SDD can access an inventory object to determine what stock is placed in the locations and uses this information along with the SDD rules to determine a source or destination.

After this determination, the availability service returns an availability indicator210, as shown by an arrow212. If the location is available, the SDD engine104can request to allocate this location for the order object102and then transmit the associated LADO ID or IDs116to the order object102that requested the stock allocation.

The step of checking for availability of a location, however, may be optional. The SDD is not limited to making the determination based on the availability of the location, but can consider the constraints stored in the repository for the location. For example, a LADO for a fixed bin may specify that all cell phones must retrieved from that bin regardless of whether there are available cell phones in the bin or not (e.g., the bin may be over-allocated). Also, the SDD can use both the constraints and the availability of the location to determine a source or destination.

Although not shown, the order object102may be used to generate instructions to place the stock at the location associated with the LADO ID. For example, other components included in the execution module202may generate instructions and transmit them to a human worker's computer. The worker may read the instructions and transport the stock specified in the order to the location associated with the LADO ID116.

The requesting object102may be used in a planning stage instead of an execution stage. Used in this stage, the SDD engine can provide a high-level check of a stock or space availability using the location hierarchy120. For example, the requesting object102may transmit information that stock allocation is required tomorrow for a particular stock. The SDD engine can provide a high-level check indicating that there is stock available somewhere in the warehouse (e.g., at a site level). The SDD engine does not have to determine whether lower levels, such as aisle and bin levels, are available as sources.

When the request108for storage location determination is received, the SDD engine104may access information contained in the request, such as a material214(e.g., Motorola V66 cell phone) of the stock, a logistic unit designation216associated with stock, and a source/destination indicator218. The material214may identify the particular type of stock (e.g., cell phones, tires, bottled drinks, etc.). The logistic unit designation216can identify a logistic unit associated with the stock. The logistic unit can be a generic, or abstracted, representation of the stock, and may include all of the stock's attributes necessary for handling the stock; however, attributes not necessary for handling the stock, such as the stock's color, can be excluded from the properties of the logistic unit. The source/destination indicator218can indicate whether the stock allocation is for a source (i.e., an allocation of stock is requested from a location) or for a destination (i.e., allocation of space at a location is requested for storing stock).

The SDD engine104can include a primary rule set212, which contains primary rules that are used to retrieve a location for stock allocation. The SDD engine104may select a particular primary rule, such as the rule112, using the material214and the logistic unit designator216included in the request108. For example, cell phones (e.g., the material) may be associated with one primary rule, while cases of beer (e.g., the logistic unit “CASE”) can be associated with another primary rule. The request for storage location determination108can also include a source/destination indicator218. The SDD engine104can use the indicator218to select a primary rule from the primary rule set212.

The selected primary rule112can access several pieces of information for use in filtering appropriate locations for storing or retrieving stock. In one implementation, this information includes a request purpose220, a reservation level222, and one or more sequences224. The primary rule112can use request purpose220to specify whether the stock allocation is made for planning purposes or execution purposes. This can affect whether current or future availability of the location is queried by the availability service, which is described in greater detail below. The primary rule112can use the reservation level222to specify a level in the hierarchy from which to retrieve the location. For example, the reservation level222can be “aisle.” The primary rule can use the “aisle” designation to query the repository only for “aisle” locations.

The sequences224can describe a search sequence the primary rule112follows if a location returned from the repository106is not available. The primary rule112can be associated with a logistic areas search sequence that searches the repository106for logistic areas that meet the criteria specified by the rule. For example, the search sequence can be L1>>L2>>L3, where “L” stands for logistic area and the “>>” symbol indicates that if L1 is not available, L2 is checked for availability, and if L2 is not available, L3 is checked.

The sequences can also designate an order that the primary rule searches locations by specifying storage behavior methods, which are associated with the locations, to search. A storage behavior method (SBM) can be associated with a LADO and can define storage behavior for the location that is represented by the LADO. For example, the SBM can specify that products must be retrieved from the location using a first in first out (FIFO) method. An SBM may represent several locations that share similar characteristics, such as the same material and bin size. For example, one SBM may represent one hundred 10×10 feet bins that can contain 2-liter soda bottles.

Additionally, the primary rule112can search locations by specifying a sequence of documents, which are associated with locations. A document can be an electronic representation of a “paper,” such as a delivery notice that certain goods will be delivered or that certain goods will be ordered by a customer. The document sequence can specify an order for the primary rule to search the locations associated with the documents. For example, the primary rule can specify that all locations associated with order documents from FavoriteCustomer A will be searched first to determine if stock is available to meet its order. Additionally, the primary rule112may use sequences of mixed types, such as L>>SBM2>>Doc3.

In some implementations, the primary rule may perform “cross-docking” using the documents. Cross-docking occurs when deliveries specified by a first document are matched with orders for the same goods specified by a second document. In other words, the documents are used to match the goods which will be received in the future (supply) with the orders for those goods (demand). This can have the advantage that goods do not have to be stored in the logistic environment, such as a warehouse, but can simply be transferred from an arriving truck to a departing truck.

If the primary rules produce more than one LODA match from the repository106, one or more rules, such as a refinement rule226, from a refinement rule set228may be used to narrow the list of possible locations for storage location determination. The refinement rules can be associated with the primary rules, so that results produced from a particular primary rule may then be refined with a refinement rule that corresponds with the primary rule. In one implementation, if two LODA IDs116a,116bare returned as a result of the primary rule's filtering, the refinement rule226can select one of the LODA IDs based on the location which is preferred in a sequence defined in the refinement rule. For example, if the request is for a stock allocation for a customer order and the SDD receives IDs associated with two bins that contain the same product, then the refinement rule228may select the ID associated with the bin that is closer to the truck loading dock so that the time required to move the stock from the bin to the loading dock is minimized.

The SDD engine104can also include an availability checker230that makes a call to the availability service204. The call may pass the LADO ID116, which the availability service uses to determine if the location is available for stock allocation. To make this determination, the availability service204can query an inventory module236. The inventory module236can return information about stock allocations for the location associated with the LADO ID116. For example, the module can return information about whether the location is reserved for incoming stock or whether stock at the location is reserved for orders. It also can return information about the current on-hand inventory at the location associated with the LADO ID116. For example, the inventory module can return information about how much space is currently available at the location or how much stock at the location is currently allocated for orders.

The availability service204may also store information about expected incoming stock or expected stock reservation for future orders. Previous requests to the SDD engine may provide the availability service204with this information, which is stored and used to calculate an availability status, such as the current amount of stock summed with the expected amount of stock.

In one implementation, the availability service204can use the stored information and the information from the inventory module236to calculate an amount of stock value122, which the engine can use to determine availability for the stock allocation. For example, if the request for stock allocation specifies that a hundred units of stock require storage immediately, the availability service can compare this requirement with the amount of space available at the location, which can be calculated by subtracting the amount of stock value122from the capacity of the location. In another example, if the request for stock allocation specifies that 100 units of stock require immediate delivery to Customer A, the availability service204can compare the amounts required to the amount of stock value122to determine if enough stock is available at that location. As a result of the availability determination, the availability service204can generate and transmit an availability status210that indicates whether the location associate with the LADO ID116is available.

In some implementations where several locations are available for stock allocation, the SDD engine104may utilize local SDD rules238in the SBM object206that is associated with the locations to refine which locations are returned. The local SDD rules238can define a strategy, such as retrieval and placement strategies, used within the location. For example, local SDD rules238can instruct the system to select the location that holds the oldest stock. The local SDD rules may be used by the SDD engine104in combination with the refinement rules228.

The SDD engine may determine which SBM object206to access based on pointers associated with an object that is dependent on the LADO. For example, the LADO may have a dependent object that stores information about the location that the LADO represents. This information may include a pointer to the SBM object206associated with the LADO.

FIG. 3is a flow chart for an exemplary method300for identifying a location to place or retrieve stock. For example, a processor may execute instructions which perform the method300. The method may start by performing step310, in which a storage location determination request is received. For example, the requesting object102may transmit the request for storage location determination108to the SDD engine104.

In step320, a primary rule to ascertain a location for the storage location determination may be selected. For example, the SDD engine104may use the material214to select which primary rule to select from a primary rule set212.

In step330, the sequences, levels, request purposes, and source/destination status may be determined. For example, the SDD engine104may access the sequences224specified by the primary rule to determine what categories (e.g., locations, SBMs, docs) to search and in what order. Primary rules may use the request purpose220to specify a purpose, such as immediate execution, for which the stock will be used. Additionally, the rule may use of the reservation level222to specify a hierarchy level, such as “aisle,” that will be used for stock allocation. The rule may use the level as filtering criteria when searching the repository106.

Next, depending on the sequence specified, step340,350, or360can be performed. If the sequence specifies that the next locations to be searched are associated with a logistic area, step340is performed. For example, a LADO associated with a particular location, such as bin #2432, may be specified by the sequence as the first location to search. The ID associated with this LADO can be transmitted to the SDD engine and checked for availability.

If the sequence specifies that the primary rule should search by SBM, step350is performed. For example, the SBM object may contain storage behavior methods that apply to high racks in a warehouse. One SBM object can be linked to more than one location, such as high rack A, high rack B, and high rack C. In one implementation, the primary rule may search the SBM, which also can be stored in the repository106. For example, the primary rule may implement the sequence SBMHighRack>>SBMLowRack. The SDD can access the SBMHighRackto determine which LADOs are associated with that SMB. The LADO IDs may then be returned to the SDD engine104.

If the sequence specifies that the primary rule should search by document, step360is performed. For example, the search sequence can instruct the primary rule to request documents from the Order module232for television sets delivered by customer BigSeller. If there are no deliveries from BigSeller, the primary rule may request documents that specify deliveries from SmallSeller. The document can specify what product will be delivered, and the system can associate a location with the product that will be delivered. For example, the television sets delivered by customer BigSeller may be delivered to an unloading dock, which has a LADO associated with it. An ID for this LADO can be returned to the SDD engine as a source for the television sets.

In step370, the SDD engine can access local SDD rules associated with the returned LADO IDs and use the rules to filter the possible locations. For example, a local SDD rule may specify that the oldest stock should be allocated first.

In step380, the location or locations identified by the local SDD rules are checked to see if the locations are available for stock allocation. For example, the SDD engine104may transmit the LADO ID116associated with the location to the availability service204. The availability service204can generate and return the availability status210based on whether the location has enough space or stock to satisfy the storage location determination request108. If the location is not available, the method300may return to step340, step350, or step360. The method can return to the step that is specified by the sequence. For example, if the first category is a Logistic Area, and the associated location is unavailable, the SDD engine may search the repository based on a second category, such as SBM.

If the location is available, step390may be performed. In step390a determination can be performed based on whether multiple locations appropriate for stock allocation were returned. For example, if the SBM specified by the search sequence224is associated with more than one location, the SDD engine104may receive multiple LADO IDs. If multiple LADO IDs are received, step399may be performed. If the SDD engine104returns one LADO ID, the process may end.

In step399, refinement rules in the SDD engine may be used to filter the multiple LADOs to a single LADO. For example, the SDD engine can use refinement rule226to filter the multiple locations to a single location. The refinement rule can be selected from a set of refinement rules228based on the primary rule that produced the multiple locations.

FIG. 4is a relational diagram400of objects used in the system100ofFIG. 2according to one implementation. The diagram400includes a SDD engine410, a SBM object, a LADO430, a storage control object440, and a resource object450.FIG. 4illustrates that the SDD engine may search the objects LADO430and SBM object430. For example, the SDD engine may use the sequences224to determine which objects should be searched.

When the SBM object420is searched, the associated LADO can be accessed by using the SBM to access the storage control object440, and then using a reference that associates the storage control object440with the LADO to access the LADO430. In some implementations, the storage control object440stores characteristics related to the location represented by the LADO. For example, the storage control object440may include material categories that specify what type of material can be stored at the location, such as only tooth brushes or only tooth brushes and tongue scrapers. As another example, the storage control object440may include the physical capacity of the associated location (e.g., the location can only contain 50 units of stock X).

The SBM object may include replenishment and clean-up rules that apply to the location. The replenishment rule can be triggered when a storage location is “starved for,” or needs more, stock. This may be determined by comparing a replenishment threshold with a quantity of stock associated with the location. The clean-up rule can be triggered when stock should be removed from a storage location, such as when the storage location has too much stock. Similarly, clean-up can be triggered by comparing a clean-up threshold with the quantity of stock.

In some implementations, the current and expected stock for the storage location may be compared to the threshold. If the threshold is crossed, the storage control object may initiate an action that requests the SDD engine to allocate stock for the location. For example, the storage control object430may access the SBM object, which contains methods for a type of locations, such as a high rack type. In the case of replenishment, the storage control object can access the replenishment method, which includes the replenishment threshold, to determine if the location associated with the storage object requires more stock.

More than one storage control object440can be associated with the same SBM, as indicated by an asterisk above the link connecting the storage control object440and the SBM object420. This may cause the SDD engine to receive multiple location matches when searching for a location by SBM. In that case, the SDD engine410may use the primary rules, the refinement rules, the sequences, and the request purpose to filter the results as described in association withFIGS. 2 and 3.

Resources may also be associated with the storage control object. The storage control object can include characteristics about the resource, such as the type of material it accepts. Resources can include machines and people that manipulate stock, such as trucks that move it to the logistic environment, workers that pick it from storage areas, forklifts that move it internally within the warehouse, and production machines that assemble, paint, or otherwise modify it.

A resource can be considered a storage location in a similar way that a physical storage area, such as a bin or aisle, is considered a storage location. The SDD engine410may access and return resource IDs that specify a resource from which to retrieve or add stock. For example, if the SDD engine searches using SBM sequences, it can then access the storage control object associated with the selected SBM. The resource450can be associated with the storage control object in a similar manner to the way that the LADO is associated with the storage control object, and thus, the SDD engine can retrieve a resource ID that the engine410can use for allocation of stock to or from the identified resource.

FIG. 5is a schematic diagram of a general computing system. The system500can be used in the method300and can be used to implement one or more components of the system100, described above, according to one implementation. For example, the system500may implement the repository106and a separate system, similar to system500, may implement the SDD engine104.

The system500includes a processor510, a memory520, a storage device530, and an input/output device540. Each of the components510,520,530, and540are interconnected using a system bus550. The processor510is capable of processing instructions for execution within the system500. In one implementation, the processor510is a single-threaded processor. In another implementation, the processor510is a multi-threaded processor. The processor510is capable of processing instructions stored in the memory520or on the storage device530to display graphical information for a user interface, such as an interface that displays planning or execution information to a manger, on the input/output device540.

The memory520stores information within the system500. In one implementation, the memory520is a computer-readable medium. In one implementation, the memory520is a volatile memory unit. In another implementation, the memory520is a non-volatile memory unit.

The storage device530is capable of providing mass storage for the system100. In one implementation, the storage device530is a computer-readable medium. In various different implementations, the storage device530may be a floppy disk device, a hard disk device, an optical disk device, or a tape device.

The input/output device540provides input/output operations for the system500. In one implementation, the input/output device540includes a keyboard and/or pointing device. In another implementation, the input/output device540includes a display unit for displaying graphical user interfaces.

A number of embodiments have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the embodiments. For example, the SDD engine may receive a LADO ID associated with a relatively higher location level, such as an aisle. Once this higher level LADO ID is determined, the SDD engine may determine a lower location level, such as a bin within the aisle. This determination of the lower level may be similar to the method400, where a sequence of bins is specified and the SDD uses a primary rule to determine which bins are available for the allocation. The SDD engine can receive A LADO ID associated with an available lower location level and transmit it to the requesting object102instead of or in addition to the LADO ID associated with the higher level. For example, the SDD may search at the aisle level and then at the bin level once an aisle is located. The SDD engine can then return The LADO ID associated with the bin to the requesting object instead of the LADO ID associated with the aisle.

In another implementation, only the LADO ID associated with the higher level location is transmitted to the requesting object. In this case, the stock may be taken from or put in any of the lower level locations that are logically included in the higher level location. For example, if Aisle A is returned, then the incoming stock can be stored in any bin in Aisle A.

In yet another implementation, other objects besides the location hierarchy120can be stored in the repository106. For example, the LADO, the SBM, the storage control object, and the primary rules can be static data stored in the repository. Other elements, such as the SDD engine and the availability service can be dynamic objects that are not stored in the repository, but access the objects in the repository to perform actions.

In other implementations, the system may dynamically assign an association between a bin and a type of stock. A bin can initially be a fixed bin that is associated with a specified type of material, such as desk lamps. When more desk lamps arrive, the SDD engine determines that the lamps should be stored in that fixed bin. When the lamps are removed from the bin, the SDD engine may dynamically reassign the fixed bin to store a different type of stock, such as flashlights.

Dynamic fixed bin assignment can work in concert with allocation at a higher level. For example, the SDD engine may assign stock to an abstracted level, such as an aisle. In this case, it may not be important what bin it is assigned to as long as the stock is located on that aisle. The SDD engine may assign any empty bin to the incoming stock material type, and in the future if more stock arrives of the same material type, it may be placed in the same bin because the SDD engine associated the bin with the material type. In one implementation, the SDD initiates a modification of data stored in the repository, such as a material category associated with a storage control object associated with the bin.

The determination of source and destination locations can also be bounded or influenced by requirements set by the requesting object. For example, a hierarchal level or a type of storage location (e.g., unloading dock) can be specified by the object requesting a source or destination determination. This may work in cooperation with or supersede the determination which would have been produced by the primary or refinement rules of the SDD.

In addition, the sequences224can be based on several types of information, such as the level of abstraction. For example, a sequence may specify that the SDD engine first search BIN1, and if that is not available, then search Aisle4. Accordingly, other embodiments are within the scope of the following claims.