System of Determining Container Load Units From Dispatch Load Units
20200019918 ยท 2020-01-16
Inventors
Cpc classification
G06Q10/0832
PHYSICS
G06Q10/087
PHYSICS
B65G65/30
PERFORMING OPERATIONS; TRANSPORTING
International classification
Abstract
A system of determining container load units from dispatch load units which allows for packing a container load unit by a homogeneous (identical) type of dispatch load unit and/or by heterogeneous (different types) of dispatch load units. The system allows for the incorporation of practical operational factors, packing preferences and also allows for various empirical overrides. The quantity of container load units and the packing arrangements for each container load unit are generated for various lots of items.
Claims
1. A system for determining container load units (CLUs) from dispatch load units (DLUs) comprising: (a) providing a list of items with a quantity and weight associated with each said item; (b) accessing a DLU database for multiple dispatch load units each comprising exterior height, exterior length, exterior width, gross weight, placement direction, maximum stacks and orientation data; (c) identifying from said DLU database one or more suitable DLUs for each said item to define a group of IDLUs; (d) calculating the quantity of IDLUs for each item; (e) accessing a CLU database for multiple container load units each comprising interior length, interior width, interior height and maximum load data; (f) calculating the quantity of CLUs from IDLUs based on the DLU and CLU databases; and (g) allocating the IDLUs to each selected container load unit CLU to construct a table comprising items and quantities of IDLUs and CLUs.
2. The system of claim 1 further comprising accessing a preference database of packing preferences and employing a packing preference in one or more of steps (d), (f) and (g).
3. The system of claim 1 wherein for a given item, the IDLUs are homogeneous.
4. The system of claim 2 further comprising calculating the allocable quantity Q of each IDLU having a theoretical maximum allocable quantity possible for a CLU based on properties of the CLUs and the packing preferences and applying a preference to reduce the theoretical allocable quantity of the Q.
5. The system of claim 4 further comprising overriding of the dispatch load Q by a preferred empirical value.
6. The system of claim 4 further comprising recalculating the Q and for each IDLU comprising assigning an item weight and recalculating the Q based on a CLU maximum load property.
7. The system of claim 1 further comprising constructing a packing model of two possible packing arrangements for a front facing direction and a side facing direction.
8. The system of claim 7 wherein each said IDLU is a carton and each CLU is a container and further comprising for each container determining the upright lot, an adjacent lot and an overhead lot and calculating the allocable cartons as the sum of the cartons for each of the upright lot, the adjacent lot and the overhead lot.
9. The system of claim 8 further comprising overriding the allocable carton quantity by an empirical value.
10. The system of claim 1 further comprising for each IDLU performing a first round homogeneous allocation by determining a full container quantity for each IDLU and determining an unallocated remaining IDLU quantity for each IDLU.
11. The system of claim 10 wherein for all remaining IDLUs grouping each IDLU with identical packing properties into a super lot, and for each super lot, sorting the IDLUs and determining full container load unit quantity based on allocable item dispatch load quantity, and determining an unallocated remaining IDLU and quantity for each super lot.
12. The system of claim 11 wherein each container has a volume and further comprising sorting the item dispatch load unit by grouping all item dispatch load units with identical packing properties into a super lot, sorting the super lots to define a sort segment where a lot volume is based on a unit allocable volume V and wherein carton allocations of V is based on the sort sequence, and proceeding until allocation of the cartons is such that the total unit allocable volume of cartons does not exceed the container interior volume until all cartons are allocated, and summing the containers for the homogeneous allocation and the heterogeneous allocation.
13. A system for determining container load units (CLUs) from dispatch load units (DLUs) comprising: (a) providing a list of items with a quantity associated with each said item; (b) providing an DLU database for multiple DLUs each comprising exterior dimensional data; (c) identifying from said DLU database a group of items specific DLUs (IDLUs) for each said item (d) calculating the quantity of IDLUs for each item; (e) providing a CLU database for multiple container load units each comprising interior dimensional data; (f) calculating the quantity of CLUs from IDLUs based on the DLU and CLU databases; and (g) allocating the IDLUs to selected CLUs to construct a table comprising items and corresponding IDLUs and CLUs
14. The system of claim 13 further comprising constructing a packing model for each of the selected CLUs.
15. The system of claim 13 further comprising providing a preference database and employing the preference database in one or more of steps (b), (d) and (f).
16. The system of claim 13 wherein said group of IDLUs comprises homogeneous and heterogeneous cartons and further comprising initially performing steps (d), (f) and (g) for homogeneous cartons and then performing the calculations of (d), (f) and (g) for heterogeneous cartons.
17. The system of claim 13 further comprising constructing a packing model of two possible packing arrangements for a front facing direction and a side facing direction, and then for each carton and a selected container, determining an upright lot, an adjacent lot and an overhead lot and calculating the allocable cartons as the sum of the cartons of each of the upright lot, the adjacent lot and the overhead lot.
18. The system of claim 13 wherein said DLU database comprises gross weight data and said CLU database comprises maximum load data and further comprising performing steps (d), (f) and (g) by employing said gross weight and maximum load data.
19. The system of claim 13 wherein said DLU database comprises placement direction, maximum stack and orientation data and further comprising employing the placement direction, maximum stack and orientation data to perform steps (d), (e) and (f).
20. The system of claim 1 further comprising constructing a lookup table comprising Allocable Quantity and unit Allocable Volume calculated for each IDLU and for each CLU for each item.
Description
BRIEF DESCRIPTION OF THE DRAWINGS
[0040]
[0041]
[0042]
[0043]
[0044]
[0045]
[0046]
[0047]
[0048]
[0049]
DETAILED DESCRIPTION
[0050] With reference to the drawings, a system of determining container load units from dispatch load units derived from a list of items is illustrated for various embodiments which embrace a wide range of applications depending on the nature of the items, the configurations of possible dispatch load units, such as cartons, pallet-load and the configurations of possible container load units such as intermodal containers, trucks, unit load device, etc. . . . In
Organization of Information
[0051] 1. Definitions
[0052] 1. Container Load Unit
[0053] 2. Dispatch Load Unit
[0054] 3. Dispatch Load Unit and Container Load Unit Relationship
[0055] 4. Item or Product
[0056] 5. Item and Dispatch Load Unit Relationship [0057] 2. Operational Factors & Preferences [0058] 3. Algorithm for Determining Container Load Unit Quantity
[0059] 1. The Constraints
[0060] 2. Packing Preferences
[0061] 3. Algorithm Strategy
[0062] 4. Homogeneous Allocation Algorithm Model [0063] 1. Allocation by Geometry [0064] 1. Properties of Load Units [0065] 2. Recursive Allocation Method & Two Blocks system [0066] 3. Spatial Unit Representing a Container Load Unit [0067] 4. Allocation of Dispatch Load Unit [0068] 5. Allocation of Upright Objects [0069] 6. Allocation of Non-Upright Objects [0070] 2. Allocation by Geometry Calculation Approach [0071] 3. An Illustrated Example of Calculating the Allocable Quantity [0072] 4. Homogeneous Allocation Algorithm Extension [0073] 1. Empirical Adjustment of Allocable Quantity from Allocation by Geometry [0074] 2. Allocation by Weight [0075] 3. Empirical Adjustment of Allocable Quantity from Allocation by Weight [0076] 5. Packing Arrangement Details in a Container Load Unit
[0077] 5. Heterogeneous Allocation Algorithm Model [0078] 1. An Illustrated Example of Calculating the Container Load Unit Quantity [0079] 1. Allocation by Allocable Quantity on Item [0080] 2. Allocation by Allocable Quantity of Identical Allocation Properties [0081] 3. Allocation by Allocable Volume and Weight [0082] 4. Totalling Required Container Load Units [0083] 2. A More Complex List of Dispatch Load Units for Calculation [0084] 3. Packing Arrangement Details in Container Load Units [0085] 4. Variation to the Heterogeneous Allocation Algorithm Model
Definitions
Container Load Unit
[0086] Any container load unit (CLU or Container) that may containerized cargo, such as intermodal freight containers, trucks or any unit load device is expected to have the following properties: [0087] 1. Interior lengthfrom the back of the container to the front/opening/doors [0088] 2. Interior widthbetween the sides of the container [0089] 3. Interior height, also representing the upright orientation of the container. [0090] 4. Maximum loadthe maximum gross weight of content the container can support/hold. [0091] 5. Container is of a solid and static cubical shape, which the shape is maintained and not reduced or expanded or deformed in any of the length, width or height dimensions. [0092] 6. Container may be moved around but its height orientation is always maintained in the upright orientation; thereby maintaining the contents' original placement orientation and preventing damage.
Dispatch Load Unit
[0093] Any unit cargo that is dispatched by one party as a dispatch unit, fulfilment unit or shipment unit, and received by another party is a dispatch load unit (DLU). It is considered as having a cubical shape occupying space, typically in a carton form, is expected to have the following properties: [0094] 1. A well determined top/bottom. Representing the upright orientation. Referencing a carton typically can be identified by the flaps to open/close the carton box. The unit's upright orientation is often essential to be maintained to preserve the integrity of the dispatch load unit and its content. [0095] 2. A well determined front/back. The upright faces that typically inform everyone what the content of the dispatch load unit is. Referencing a carton, typically are the faces with the content details and depictions are printed, and it is parallel to the line where the top/bottom closing flaps meet. Also identifies the front facing orientation referenced in packing operations. [0096] 3. A well determined sides/ends. The other upright faces adjacent to the front/back and top/bottom faces. [0097] 4. Exterior height is the distance between the top and bottom of the dispatch load unit. [0098] 5. Exterior lengthIt is referred to the front or back face of the dispatch load unit. It is the width of this face, or equivalent to the distance between the two sides/ends. [0099] 6. Exterior width/depthIt is referred to the side/end face of the dispatch load unit. It is the width of this face, or equivalent to the distance between the front and back face. [0100] 7. Gross weightis the weight of the dispatch load unit with content [0101] 8. Placement direction of the dispatch load unit when placed inside a container load unit, with its front/back face may be placed facing the container opening/door, the container side, or either. The placement direction does not change the dispatch load unit's upright orientation. [0102] 9. Stacking of dispatch load unit means one dispatch load unit is placed on top of another dispatch load unit, along the height of the container load unit. [0103] 10. Maximum stacks allowed for dispatch load unit at its upright orientationthe stacking could be ranged from one (1) and upwards based on the engineering design of the dispatch load unit. This property may be identified with a positive integer number as: [0104] 1. One (1) for allowing dispatch load unit to lie on its upright orientation but no other dispatch load units may stacked on top. [0105] 2. Two (2) for allowing dispatch load unit to be stacked with maximum two layers. [0106] 3. Three (3) for allowing dispatch load unit to be stacked with maximum three layers. [0107] 4. And identical logic for larger integer numbers. [0108] 11. Maximum stacks allowed for dispatch load unit placed on its front/back orientationmeaning the dispatch load unit's front/back face becomes the top/bottom with the original width becomes the height. This placement orientation is not preferred; hence it is subordinate to upright placement orientation. This property may be identified with a positive integer number as: [0109] 1. Zero (0) for disallowing dispatch load unit to lie on its front/back face. [0110] 2. One (1) for allowing dispatch load unit to lie on its front/back face but no other dispatch load units may stacked on top. [0111] 3. Two (2) for allowing dispatch load unit to be stacked with maximum two layers all layers lie on its front/back face. [0112] 4. Three (3) for allowing dispatch load unit to be stacked with maximum three layers all layers lie on its front/back face. [0113] 5. And identical logic for larger integer numbers. [0114] 12. Maximum stacks allowed for dispatch load unit placed on its side/end orientationmeaning the dispatch load unit's side/end face becomes the top/bottom with the original length becomes the height. This placement orientation is not preferred hence it is subordinate to upright placement orientation. This property may be identified with a positive integer number as: [0115] 1. Zero (0) for disallowing dispatch load unit to lie on its side/end face. [0116] 2. One (1) for allowing dispatch load unit to lie on its side/end face but no other dispatch load units may stack on top. [0117] 3. Two (2) for allowing dispatch load unit to be stacked with maximum two layers all layers lie on its side/end face. [0118] 4. Three (3) for allowing dispatch load unit to be stacked with maximum three layers all layers lie on its side/end face. [0119] 5. And identical logic for larger integer numbers. [0120] 13. Dispatch load unit is of a solid and static cubical shape, i.e. the shape is maintained and not reduced or expanded or deformed in any of the length, width or height dimensions. [0121] 14. Dispatch load units packing into a container load unit prefer to maintain their upright orientations. [0122] 15. Dispatch load units packing into a container load unit much less preferred to be placed in non-upright orientations, such as lie on its front/back or side/end faces. If, however, the non-upright orientation(s) is allowed, dispatch load units will only be placed at spaces not occupied by dispatch load units in the upright orientation.
Dispatch Load Unit and Container Load Unit Relationship
[0123] 1. Dispatch load unit is the unit being considered in packing a container load unit. It is the content of the container load unit. It is a cargo unit and it is the container load unit's cargo. [0124] 2. A dispatch load unit is small enough to move freely in and out of a container load unit in its upright orientation. A dispatch load unit is also small enough to move freely in and out of a container load unit in its non-upright orientations if it is allowed to be packed in the corresponding non-upright orientation. [0125] 3. A container load unit constrains how many dispatch load units can be packed/loaded by its interior dimensions length, width and height. [0126] 4. A container load unit also constrains how many dispatch load units can be packed by having a maximum load property. The gross weight of the dispatch load units packed/loaded normally cannot be allowed to exceed the container load unit's maximum load property. However, at times, users may ignore this maximum load constraint. The geometry of the container load unit constrains the maximum quantity of dispatch load units can be packed, but with the maximum load property may further reduce this maximum quantity by geometry. [0127] 5. Dispatch load unit at times has preference in placement direction in the container load unit often to facilitate unpacking or to avoid damage.
Item or Product
[0128] 1. Item is an object unit being referred to in the business process interactions between customers and vendors. [0129] 2. Item also has a quantity unit being referred to in the business process interaction.
Item and Dispatch Load Unit Relationship
[0130] 1. Item is the content of a dispatch load unit. The quantity of items to the dispatch load unit is well defined, and may not always be a one to one relationship; it could be a larger integer value. The quantity of items to a dispatch load unit is a conversion ratio between item and dispatch load unit. An instance of a dispatch load unit associated with an item can be referred to as an Item Dispatch load unit (IDLU). [0131] 2. With items packed into a dispatch load unit, it is assumed that there will be no alteration to the dispatch load unit except its gross weight will be increased. [0132] 3. An item can adopt many different dispatch load units; each item dispatch load unit implies a unit conversion and a set of physical and loading properties. [0133] 4. Business interactions refer to items; logistics refer to dispatch load units.
Operational Factors & Preferences
[0134] 1. Container load unit maximum load or gross weight may or may not be respected. It is a user option. [0135] 2. The packing/loading process of dispatch load units into a container load unit may not be perfect, where dispatch load units may be not placed abut each other, which may be referred to as loosely packed or loose packing. Loose packing may be intentional or unintentional in reality. In terms of determining the allocable quantity of dispatch load units to a container load unit, it may be assumed packing is perfect and make adjustments to account for possible loose packing. This adjustment is in the form of reserved length, width and height, where it is subtracted from the corresponding interior length, width and height of the container load unit to determine the available space for packing. [0136] 3. The algorithm is based on packing/unpacking preferences described in this paper and shows a packing arrangement but the actual packing arrangement done by the packing personnel may vary slightly. However, the allocable quantity determined of the dispatch load units in a container load unit is preserved and is consistent between the planning in the algorithm/calculation and the actual packed/loaded cargo or items.
Algorithm For Determining Container Load Unit Quantity
The Constraints
[0137] The result of a system algorithm must serve all parties: [0138] 1. Business interactions specify items and item quantity, while logistics process specify dispatch load units and container load units. [0139] 2. Dispatch load unit comes in all sizes and with loading properties, while packing container load units need to comply with packing preferences to account for reality packing constraints. [0140] 3. Essential to pack container load unit for ease of packing at dispatch location and unpacking at receiving location. [0141] 4. The algorithm not only needs to determine the minimum container load unit quantity required but also to show packing plan on how dispatch load units are allocated in the container load unit for container load unit based review and information.
Packing Preferences
[0142] 1. Most preferredis container load unit is packed with only one single (homogeneous) lot of dispatch load units of one type of item.
[0143] 1. Rationale: [0144] 1. For packing a container: It is most desirable to be filled with just one type of (homogeneous) dispatch load unit, which will have a proven allocable quantity and a standardized packing arrangement of the dispatch load units to a container load unit. [0145] 2. For unpacking a container: Easier to process unpacking the container load unit because it is easier to organize and route the unloaded dispatch load units of a single item type to storage.
[0146] 2. More detailed preference: [0147] 1. For each item user specified in a quotation/specification/scenario, the preference is to determine full container load units from the item quantity or the item-associated dispatch load unit quantity. Any dispatch load units of the item remaining unable to fully occupy a container load unit will be for deferred allocation in the algorithm. This demands the algorithm to have a prior determined allocable quantity for the item's dispatch load units to the specified container load unit. [0148] 2. For identical items user specified in the quotation in separate lines, if their dispatch load units are identical, they are also most preferred to be packed together. [0149] 2. Next preferredis container load unit is packed full of dispatch load units with identical physical and loading properties and allocable quantity, even though these dispatch load units are of different items.
[0150] 1. Rationale: [0151] 1. For packing a container: Despite the items being different, every aspect of the dispatch load units of those items is identical, so in terms of packing they are treated as a single dispatch load unit type. A container load unit packed full of these dispatch load units will be packed most optimal because the packing arrangement and allocable quantity is proven and standardized so as to have low packing complexity. [0152] 2. For unpacking a container: The preference is to have the fewest item types in a container load unit so it can be of lesser effort to organize and route items to their rightful storage locations. The preference is also to keep to fewest container load units with many different items so that fewer container load units need many routing to different storage locations. This preference is also preferred in the packing of a container load unit where the fewer the items are planned for a container load unit, the faster the container load unit can finish packing, be sealed and be released to the freighting party.
[0153] 2. More detailed preference: [0154] 1. The preference would be container load units full of dispatch load units of identical properties. The remainder dispatch load units unable to fully occupy a container load unit will be for deferred allocation in the algorithm. [0155] 2. Dispatch load units of an item are organized into a lot. When having different lots and all need to be packed into container load units, they are sorted typically based on their lot volume, to pack into container load units; so those earlier packed container load units will have fewest different items and later container load units have more different items. This also ensures an item would not be too scattered over many container load units making targeted unloading of a specific item less troublesome in operations. [0156] 3. Least preferred but inevitableis container load unit is packed full of dispatch load units of different items, sizes and loading properties.
[0157] 1. Rationale: [0158] 1. For packing a container: Not only are these container load units may not be packed with most optimized utilization of space and packing can be inconsistent based on skills, but also most difficult to have consistency in determining container load unit quantity. This is where the algorithm would provide a consistency in packing arrangement and allocation quantity. However, the primary target in the algorithm is to not underestimate container load units required because the nature of packing operations is time critical and often cannot wait for delivery of further container load units, but needs to be able to achieve very good utilization of container load unit to both reduce logistics cost yet maximize packing density. [0159] 2. For unpacking a container: Again, the preference is to have the fewest item types in a container load unit, and fewest container load units with many different item types. It is for the same reasons of ease of operations at both ends of the dispatch and receiving locations.
[0160] 2. More detailed preference: [0161] 1. Unlike packing a container load unit with dispatch load units of uniform size and loading properties, each container load unit allocable quantity must be individually determined and with bespoke packing arrangement. An approach to determining this bespoke allocable quantity is based on the dispatch load unit Allocable Volume (V) to the container load unit, where it has a proven allocable quantity value used in the most preferred packing arrangement (above). It is simply the interior available volume of the container load unit divided by the dispatch load unit Allocable Quantity (Q). It implies the volume the dispatch load unit would occupy by its physical form plus an equal share of the unused space of the container load unit. [0162] 2. Similar to the approach above, for all the items not assigned to a container load unit, item dispatch load unit lots are sorted based on their lot volume, to pack into container load units until all item dispatch load units are assigned a container load unit. Again, earlier packed container load units will have fewest different items and later container load units have more different items. The objective is to ensure an item would not be too scattered over many container load units making targeted unloading of a specific item less troublesome in operations. Besides packing these dispatch load units by allocable volume, the packing must comply with container load unit properties and can or cannot exceed its maximum load. [0163] 4. Packing a container load unit always starts from the furthest corner and side from the container load unit door opening.
[0164] 1. Rationale: [0165] 1. It is the most intuitive, efficient and common packing approach adopted by warehouse operations. [0166] 5. Dispatch load units preferred to be packed and stacked to result in a plane and flat surface for the next stack above, unless there will be no more dispatch load units to be stacked on top.
[0167] 1. Rationale: [0168] 1. Gives the maximum utilization of space [0169] 2. Easier packing and unpacking operation with the least damage to content during handling [0170] 3. Uneven surface creates pressure points on bottom of dispatch load units due to weight and may lead to damage to its content, so to be avoided. [0171] 6. Dispatch load units preferred to be organized into as large a lot as possible with the same placement orientation, such as all are placed upright (or lie on back face or on side face); and all facing in the same direction.
[0172] 1. Rationale: [0173] 1. For efficient loading and unloading of units [0174] 2. For the least handling complexity of loading and unloading of units [0175] 3. For minimal instructions and communication of packing arrangements along the work flow [0176] 7. Intrinsic preferences and properties of dispatch load unitwhether it is by design specification of the dispatch load unit or for the preservation of the content it is holding. [0177] 1. Dispatch load unit always want to be handled and placed in its upright orientation. Only by design or special circumstances would a dispatch load unit be allowed to be packed/placed in its non-upright orientation. Dispatch load units only placed in non-upright orientation in the container load unit when no more in the upright orientation can be loaded. [0178] 2. Dispatch load unit may have a stacking limitation to avoid damage to the structural integrity of the dispatch load unit or to its content. [0179] 3. In relation to a container load unit, the dispatch load unit may require reservation space inside the container load unit for packing and unpacking. These reservation spaces are typically empirically determined. These spaces would account for non-ideal packing factors such as dispatch load units: [0180] 1. May expand in dimension due to over packing or the weight from stacking [0181] 2. Maybe too loosely packed where gaps between dispatch load units are greater than normal [0182] 3. Require extra space for the process of loading/unloading and maneuvering inside the container load unit [0183] 4. Dispatch load unit support stacking lie on back face or lie on side face does not support further stacking on top. [0184] 5. The algorithmically determined allocable quantity, the quantity may support override to support an empirically derived allocable quantity. [0185] 8. Intrinsic preferences and properties of container load unitfor the integrity of the container load unit and protection of its content. [0186] 1. Maximum load, which may or may not be complied with by users of the container load unit.
Algorithm Strategy
[0187] The relationship among item, dispatch load unit and container load unit is a unit conversion system of item to dispatch load unit to container load unit.
[0188] How many dispatch load units can fit into a container load unit is constrained by geometry. With loading properties, adjustment for loose packing and compliance to packing preferences, the resultant Allocable Quantity (Q) is the maximum quantity of dispatch load units that can be packed into a container load unit. The calculation is by an algorithm on allocating homogeneous dispatch load units into a container load unit. This allocable quantity can be thought of as maximum quantity of empty boxes based on geometry.
[0189] When a dispatch load unit is associated with an item (IDLU), as its content, and with the number of items that maybe packed into it, it has an additional weight property as gross weight. Similarly, container load unit has a maximum load limit, which may or may not be respected. If respected, the Allocable Quantity (Q) maybe reduced so the gross weight of all allocable dispatch load units may not exceed the container maximum load. This allocable quantity can be thought of as maximum quantity of cargo boxes. This allocable quantity is also associated with an Allocable Volume (V) to represent the volume required to pack the item-associated dispatch load unit into the container load unit.
[0190] For a given list of item-associated dispatch load units (IDLU) and a supported list of container load unit (CLU), to determine the number of container load units required in the scenario, the algorithm strategy is a Setup and Operate model as set forth in
Homogeneous Allocation Algorithm Model
[0193] The aim of the homogeneous allocation algorithm model is to determine how many dispatch load units, all being identical (homogeneous), can be allocated into a given container load unit. The allocation will be based on the properties of the dispatch load unit (DLU) and container load unit (CLU) and comply with the packing preferences as indicated at
[0194] The homogeneous allocation algorithm model is depicted in
[0195] The homogeneous allocation algorithm model is a four steps model as explained below, ref.
Allocation by Geometry
[0201] The allocation of a dispatch load unit to a container load unit is based on a list of properties and packing preferences, ref.
Properties of Load Units
[0202] The algorithm for the allocation by geometry is based on two sets of properties; one from the dispatch load unit, another from the container load unit. For convenience of reading, we will refer to dispatch load unit as DLU or Carton (ctn), and container load unit as CLU or Container (ctr). [0203] 1. The container load unit (ctr) properties are listed at Table I:
TABLE-US-00001 TABLE I Property Type Description L.sub.ctr Decimal Interior length of container; from door/front to back of container W.sub.ctr Decimal Interior width of container, between the left & right sides of container. H.sub.ctr Decimal Interior height of container & defines the upright orientation of the container M.sub.ctr Decimal Maximum load/mass the container may hold L.sub.reserve Decimal Interior length reserved not for packing, so container interior length usable for packing is reduced by the amount. Value must be less than the container interior length. W.sub.reserve Decimal Interior width reserved not for packing, so container interior width usable for packing is reduced by the amount. Value must be less than the container interior width. H.sub.reserve Decimal Interior height reserved not for packing, so container interior height usable for packing is reduced by the amount. Value must be less than the container interior height. [0204] 2. The dispatch load unit (ctn) has these dimensional and loading properties are listed at Table II:
TABLE-US-00002 TABLE II Parameter Type Description L.sub.ctn Decimal Exterior length of carton front face. W.sub.ctn Decimal Exterior width of carton side face H.sub.ctn Decimal Exterior height of carton & defines the upright orientation of the carton, with carton top & bottom D.sub.facing List For cartons packed in upright orientation, the preference on facing direction: 1. Face Container Opening - Carton packing primarily on carton front face at direction of container opening 2. Face Container Side - Carton packing primarily on carton front face at direction of container side 3. Higher Of - Carton packing arrangement of the two choices (1 & 2) above with higher carton quanity S.sub.upright Integer Number of stacks allowed for carton placed in its upright orientation; also includes any placed on top at other orientations. Value is one (1) or greater; one being nothing can stack on top, two being itself plus one or more carton stacked on top, three being itself plus two more cartons stacked on top, and logic follows . . . S.sub.back Integer Number of stacks allowed for carton laid on its front/back, meaing W.sub.ctn becomes the upright orientation. Zero (0) for not allowed stacking, while 1 or greater is the maximum stacked allowed for cartons to be stacked all laid on front/back. S.sub.side Integer Number of stacks allowed for carton laid on its side/end, meaning L.sub.ctn becomes the upright orientation. Zero (0) for not allowed stacking, while 1 or greater is the maximum stacks allowed for cartons to be stacked all laid on side/end.
Recursive Allocation Method & Two Blocks System
[0205] For the allocation by geometry, a way to determine the maximum quantity of homogeneous dispatch load units that can be packed into a container load unit is by a Recursive Allocation Method. This method is desirable, as packing cubical objects into a cubical space often cannot achieve 100% utilization. After packing objects into a cubical space in a certain orientation, residual cubical spaces result and may be further packed by objects in different orientations or of different sizes. Based on common warehouse packing preferences, the packing is a recursive process first packing objects in upright orientations and then where allowed may further pack residual spaces by objects in non-upright orientations. Here, a cubical object represents a dispatch load unit or a carton, and a cubical space represents the interior space of a container load unit.
[0206] The recursive allocation method starts with a given cubical spatial unit, after it is fully allocated with homogeneous cubical objects in upright orientation, two residual spaces result that may further allocate the same homogeneous cubical objects in non-upright orientations. These residual spaces are the overhead and adjacent spaces around the body of upright objects. Each of these residual spaces, in the form of a cubical spatial unit, may apply the allocation method again; each will result in smaller overhead and adjacent residual cubical spacial units for further allocation,
[0207] For a spatial unit, the allocation method applies allocation by a two block system, in the form of a main object block and the other object block, both a cubical block, to fill the space, ref
[0211] For the commencing spatial unit is allocated, the residual overhead and adjacent spatial dimensions can be determined for follow-on allocation, ref
[0212] The commencing spatial unit is to be allocated by upright objects.
[0213] The adjacent spatial unit and overhead spatial unit are to be allocated by non-upright objects.
[0214] The quantity of upright objects allocated in the spatial unit, and the quantity of non-upright objects allocated in the overhead spatial unit and adjacent spatial unit are summed to give the total Allocable Quantity (Q) of the object to the spatial unit.
Spatial Unit Representing a Container Load Unit
[0215] For the application of the recursive allocation method, the properties of a spatial unit are listed at Table III.
TABLE-US-00003 TABLE III Property Type Description L.sub.S Decimal Length of the cubical spatial unit between the back and the front W.sub.S Decimal Width of the cubical spatial unit between the left and the right sides H.sub.S Decimal Height of the cubical spatial unit between the top and bottom
[0216] The commencing spatial unit, ref. Table IV, is simply the usable dimension of the container load unit. This is the interior container dimension less any reserved for lost space from loose packing, ref. Table I.
TABLE-US-00004 TABLE IV Business Parameter Rule Type Description L.sub.S L.sub.ctr L.sub.reserve Decimal Length of the commencing spatial unit W.sub.S W.sub.ctr W.sub.reserve Decimal Width of the commencing spatial unit H.sub.S H.sub.ctr H.sub.reserve Decimal Height of the commencing spatial unit
[0217] The spatial unit dimensions of subsequent residual overhead and adjacent spatial units around the upright object blocks can only be determined after the upright object blocks are calculated.
Allocation of Dispatch Load Unit
[0218] For the allocating object and its placement orientation, it is represented by dimensions so when a carton is intended to have a specific placement orientation, the length, width and height of the carton is assigned accordingly to the length, width and height of the main block object and that of the other block object.
[0219] The allocating objects for the main block and the other block can be modeled by a number of properties, ref. Table V, for allocating in spatial unit; also on properties for stacking objects on top of the object blocks below.
TABLE-US-00005 TABLE V Main Other Block Block Property Property Type Description L.sub.u1 L.sub.u2 Decimal Front width of the carton unit; between the left and right side of the carton. W.sub.u1 W.sub.u2 Decimal Side width of the carton unit; between the front and back of the carton. H.sub.u1 H.sub.u2 Decimal Height of the carton unit; between the top and the bottom of the carton. S.sub.current1 S.sub.current2 Integer Stacking limit of the current spatial unit S.sub.total1 S.sub.total2 Integer Overall stacking limit (current spatial unit and below spatial unit) S.sub.below1 S.sub.below2 Integer Stacks stacked below current spatial unit
[0220] Objects for the main block and other block are separately identified in the Two Blocks System so they maybe separately modeled and applied in the algorithm on the allocation calculation.
Allocation of Upright Objects
[0221] For allocating upright dispatch load unit into the commencing spatial unit, two allocation arrangements (FS and SF) are possible. One with main block objects facing front (F), another with main block objects facing side (S). The two blocks system correspondingly will have the objects at the other block turned to face the other direction; see Table VI. Each allocation arrangement will produce its recursive allocation result. The carton loading property (D.sub.facing) at Table II, will determine the Allocable Quantity (Q) is from which upright arrangement, ref
TABLE-US-00006 TABLE VI Main Block Other Block # Arrangement Orientation Facing Orientation Facing 1 FS Upright Front Upright Side SF Upright Side Upright Front
[0222] Upright objects in the commencing spatial unit, with the two allocation arrangements are modelled in Table VII. The objects at the main block and the other block are identical except for their facing direction. The algorithm will manipulate L.sub.u2 and W.sub.u2 accordingly to represent the object rotation about the y-axis in the Cartesian coordinate system for the change in facing direction. The carton length, width and height are mapped to the object length, width and height according to their placement orientation arrangement. The maximum stacking of the current spatial unit (S.sub.current) is that of the upright carton. Since there is no cartons stacked below (S.sub.below), the maximum total stacking (S.sub.total) remains to be that of upright carton.
TABLE-US-00007 TABLE VII Main Block Other Block # Orientation L.sub.u1 W.sub.u1 H.sub.u1 S.sub.current1 S.sub.total1 S.sub.below1 Orientation L.sub.u2 W.sub.u2 H.sub.u2 S.sub.current2 S.sub.total2 S.sub.below2 1 FS Upright L.sub.ctn W.sub.ctn H.sub.ctn S.sub.upright S.sub.upright 0 Upright L.sub.ctn W.sub.ctn H.sub.ctn S.sub.upright S.sub.upright 0 SF Upright W.sub.ctn L.sub.ctn H.sub.ctn S.sub.upright S.sub.upright 0 Upright W.sub.ctn L.sub.ctn H.sub.ctn S.sub.upright S.sub.upright 0
Allocation of Non-Upright Objects
[0223] Non-upright objects to be allocated to the residual overhead and adjacent cubical spatial units have a number of orientation combinations are modeled in Table VIII. Since the non-upright orientations are carton lying on its front/back face and lying on its side face, there are total of four combinations, each has two facing arrangements (FS and SF).
TABLE-US-00008 TABLE VIII Main Block Other Block # Arrangement Orientation Facing Orientation Facing 1 FS Lay on Back Front Lay on Back Side SF Lay on Back Side Lay on Back Front 2 FS Lay on Side Front Lay on Side Side SF Lay on Side Side Lay on Side Front 3 FS Lay on Back Front Lay on Side Side SF Lay on Back Side Lay on Side Front 4 FS Lay on Side Front Lay on Back Side SF Lay on Side Side Lay on Back Front
[0224] Based on the carton dimensions, the non-upright objects allocation combination model can be referenced at Table IX. Carton dimensions are assigned to the appropriate object dimension to represent the required carton placement orientation.
TABLE-US-00009 TABLE IX Main Block Other Block # Orientation L.sub.u1 W.sub.u1 H.sub.u1 Orientation L.sub.u2 W.sub.u2 H.sub.u2 1 FS on Back L.sub.ctn H.sub.ctn W.sub.ctn on Back L.sub.ctn H.sub.ctn W.sub.ctn SF on Back H.sub.ctn L.sub.ctn W.sub.ctn on Back H.sub.ctn L.sub.ctn W.sub.ctn 2 FS on Side H.sub.ctn W.sub.ctn L.sub.ctn on Side H.sub.ctn W.sub.ctn L.sub.ctn SF on Side W.sub.ctn H.sub.ctn L.sub.ctn on Side W.sub.ctn H.sub.ctn L.sub.ctn 3 FS on Back L.sub.ctn H.sub.ctn W.sub.ctn on Side H.sub.ctn W.sub.ctn L.sub.ctn SF on Back H.sub.ctn L.sub.ctn W.sub.ctn on Side W.sub.ctn H.sub.ctn L.sub.ctn 4 FS on Side H.sub.ctn W.sub.ctn L.sub.ctn on Back L.sub.ctn H.sub.ctn W.sub.ctn SF on Side W.sub.ctn H.sub.ctn L.sub.ctn on Back H.sub.ctn L.sub.ctn W.sub.ctn
[0225] The loading property of the carton may limit whether a carton can be placed lying on its front/back face (S.sub.back) and lying on its side face (S.sub.side), as can be referenced in Table II.
[0226] For non-upright cartons to allocate to the residual adjacent space, the object property is modelled in Table X. The maximum stacking at the current spatial unit (.sub.Scurrent) is that of the carton stacking property of its lying orientation. Since the cartons are to be allocated at the adjacent spatial unit, they are placed on the base of the spatial unit; so maximum total stacking (S.sub.total) is the same as the maximum stacking at the current spatial unit. There are no cartons stacked below (S.sub.below).
TABLE-US-00010 TABLE X Main Block Other Block # Orientation L.sub.u1 W.sub.u1 H.sub.u1 S.sub.current1 S.sub.total1 S.sub.below1 Orientation L.sub.u2 W.sub.u2 H.sub.u2 S.sub.current2 S.sub.total2 S.sub.below2 1 FS on Back L.sub.ctn H.sub.ctn W.sub.ctn S.sub.back S.sub.back 0 on Back L.sub.ctn H.sub.ctn W.sub.ctn S.sub.back S.sub.back 0 SF on Back H.sub.ctn L.sub.ctn W.sub.ctn S.sub.back S.sub.back 0 on Back H.sub.ctn L.sub.ctn W.sub.ctn S.sub.back S.sub.back 0 2 FS on Side H.sub.ctn W.sub.ctn L.sub.ctn S.sub.side S.sub.side 0 on Side H.sub.ctn W.sub.ctn L.sub.ctn S.sub.side S.sub.side 0 SF on Side W.sub.ctn H.sub.ctn L.sub.ctn S.sub.side S.sub.side 0 on Side W.sub.ctn H.sub.ctn L.sub.ctn S.sub.side S.sub.side 0 3 FS on Back L.sub.ctn H.sub.ctn W.sub.ctn S.sub.back S.sub.back 0 on Side H.sub.ctn W.sub.ctn L.sub.ctn S.sub.side S.sub.side 0 SF on Back H.sub.ctn L.sub.ctn W.sub.ctn S.sub.back S.sub.back 0 on Side W.sub.ctn H.sub.ctn L.sub.ctn S.sub.side S.sub.side 0 4 FS on Side H.sub.ctn W.sub.ctn L.sub.ctn S.sub.side S.sub.side 0 on Back L.sub.ctn H.sub.ctn W.sub.ctn S.sub.back S.sub.back 0 SF onSide W.sub.ctn H.sub.ctn L.sub.ctn S.sub.side S.sub.side 0 on Back H.sub.ctn L.sub.ctn W.sub.ctn S.sub.back S.sub.back 0
[0227] For non-upright cartons to allocate to the residual overhead space, the object property is modelled in Table XI. The maximum stacking at the current spatial unit (S.sub.current) is that of the carton stacking property of its lying orientation. Since the cartons are to be allocated on top of the upright cartons, so maximum total stacking (S.sub.total) is that of the upright cartons, which cannot be exceeded. The cartons stacked below (S.sub.below) is the calcuated stacked count (S.sub.m) of the upright carton block, arbitrarily referencing that of the main block.
TABLE-US-00011 TABLE XI Main Block Other Block # Orientation L.sub.u1 W.sub.u1 H.sub.u1 S.sub.current1 S.sub.total1 S.sub.below1 Orientation L.sub.u2 W.sub.u2 H.sub.u2 S.sub.current2 S.sub.total2 S.sub.below2 1 FS on Back L.sub.ctn H.sub.ctn W.sub.ctn S.sub.back S.sub.upright S.sub.m on Back L.sub.ctn H.sub.ctn W.sub.ctn S.sub.back S.sub.upright S.sub.m SF on Back H.sub.ctn L.sub.ctn W.sub.ctn S.sub.back S.sub.upright S.sub.m on Back H.sub.ctn L.sub.ctn W.sub.ctn S.sub.back S.sub.upright S.sub.m 2 FS on Side H.sub.ctn W.sub.ctn L.sub.ctn S.sub.side S.sub.upright S.sub.m on Side H.sub.ctn W.sub.ctn L.sub.ctn S.sub.side S.sub.upright S.sub.m SF on Side W.sub.ctn H.sub.ctn L.sub.ctn S.sub.side S.sub.upright S.sub.m on Side W.sub.ctn H.sub.ctn L.sub.ctn S.sub.side S.sub.upright S.sub.m 3 FS on Back L.sub.ctn H.sub.ctn W.sub.ctn S.sub.back S.sub.upright S.sub.m on Side H.sub.ctn W.sub.ctn L.sub.ctn S.sub.side S.sub.upright S.sub.m SF on Back H.sub.ctn L.sub.ctn W.sub.ctn S.sub.back S.sub.upright S.sub.m on Side W.sub.ctn H.sub.ctn L.sub.ctn S.sub.side S.sub.upright S.sub.m 4 FS on Side H.sub.ctn W.sub.ctn L.sub.ctn S.sub.side S.sub.upright S.sub.m on Back L.sub.ctn H.sub.ctn W.sub.ctn S.sub.back S.sub.upright S.sub.m SF on Side W.sub.ctn H.sub.ctn L.sub.ctn S.sub.side S.sub.upright S.sub.m on Back H.sub.ctn L.sub.ctn W.sub.ctn S.sub.back S.sub.upright S.sub.m
Allocation by Geometry Calculation Approach
[0228] The calculation logic of the Allocation by Geometry is structured as follow: [0229] 1. Determine the allocable quantity of upright objects at the commencing spatial unit. The steps are: [0230] a. Based on Table IV for the commencing spatial unit and Table VII for upright objects allocation arrangements, each arrangement calculates its allocable quantity, ref
[0240] For determining allocable quantity of an object into a spatial unit, with the given properties of the object for the main block and the other block, the allocation quantity calculation logic is as follows, ref.
An Illustrated Example of Calculating the Allocable Quantity
[0246] With a given set of spatial unit properties, ref. Table IV, Table XV, Table XVIII, Table XX, Table XXI and allocating objects properties organized in an allocation arrangement, ref. Table VII, Table X, Table XI, the main block allocable quantity (Q.sub.M) can be calculated as shown in Table XII. For the quotient in the calculations, only the integer value is preserved; the fraction is ignored.
TABLE-US-00012 TABLE XII Parameter Business Rule Type Description R.sub.M L.sub.s/W.sub.u1 Integer Rows at main block M C.sub.M W.sub.s/L.sub.u1 Integer Columns at main block M S.sub.M 1. H.sub.s/H.sub.u1 Integer Stacks at main block M. Cannot exceed stacking 2. If S.sub.M > S.sub.current1 then set S.sub.M = S.sub.current1 limit specified S.sub.current1. Also overall stacks cannot 3. If (S.sub.M + S.sub.below1) > S.sub.total1 then set exceed overall carton stacking limit S.sub.total1. S.sub.M = S.sub.total1 S.sub.below1 Note, if S.sub.current1 = 0, then S.sub.M = 0 and Q.sub.M = 0. Q.sub.M R.sub.M * C.sub.M * S.sub.M Integer Carton quantity of the base main block M
[0247] Since Q.sub.M is calculated from the product of rows (R), columns (C) and stacks (S), if any has a value of zero (0), then Q.sub.M is zero (0) and the block does not exist. Note for stacks, the object stacking property may be constrained so the calculated stack value can be constrained, can even be constrained to zero (0).
[0248] With the main block allocable quantity determined and non-zero, the other block (Q.sub.N) may exist at two locations, one at the side (Q.sub.S), another at the front (Q.sub.F) of the main block, ref
[0249] The other block adjacent to the side (S) of the main block can be determined only if the main block exists (Q.sub.M not equal zero). The spatial dimension at the side can be determined as shown in Table XIII. The allocable quantity (Q.sub.S) for the other block at the side can be calculated as shown in Table XIV. Again, for the quotient in the calculations, only the integer value is preserved; the fraction is ignored. The corresponding residual front adjacent spatial unit (S.sub.SF) can be determined at Table XV for subsequent recursive allocation.
TABLE-US-00013 TABLE XIII Parameter Business Rule Type Description L.sub.SS L.sub.s Decimal Full dimension W.sub.SS W.sub.s C.sub.M * L.sub.u1 Decimal Full width less width of main block H.sub.SS H.sub.s Decimal Full dimension
TABLE-US-00014 TABLE XIV Parameter Business Rule Type Description R.sub.S L.sub.SS/L.sub.u2 Integer Rows at side block S C.sub.S W.sub.SS/W.sub.u2 Integer Columns at side block S S.sub.S 1. H.sub.SS/H.sub.u2 Integer Stacks at main block S. Cannot exceed stacking 2. If S.sub.S > S.sub.current2 then set S.sub.S = S.sub.current2 limit specified S.sub.current2. Also overall stacks cannot 3. If (S.sub.S + S.sub.below2) > S.sub.total2 then set exceed overall carton stacking limit S.sub.total2. S.sub.S = S.sub.total2 S.sub.below2 Note, if S.sub.current2 = 0, then S.sub.S = 0 and Q.sub.S = 0. Q.sub.S R.sub.S * C.sub.S * S.sub.S Integer Carton quantity of the base main block S
TABLE-US-00015 TABLE XV Parameter Business Rule Type Description L.sub.SSF L.sub.s R.sub.M * W.sub.u1 Decimal Full length less length of main block W.sub.SSF If (R.sub.s L.sub.u2 > R.sub.M * W.sub.u1) Decimal Width is main block width when length of the then set W.sub.SSF = C.sub.M * L.sub.u1 other block is greater than length of the man else set W.sub.SSF = W.sub.s block, else width is full width of spatial unit. H.sub.SSF H.sub.S Decimal Full dimension
[0250] The other block adjacent to the front (F) of the main block can be determined only if the main block exists. The spatial dimension at the front can be determined as shown in Table XVI. The allocable quantity (Q.sub.F) for the other block at the front can be calculated as shown in Table XVII. Again, for the quotient of the calculations, only the integer value is preserved; the fraction is ignored. The corresponding residual side adjacent spatial unit (S.sub.FS) can be determined at Table XVIII for subsequent allocation is shown.
TABLE-US-00016 TABLE XVI Parameter Business Rule Type Description L.sub.SF L.sub.s R.sub.M * W.sub.u1 Decimal Full length less length of main block W.sub.SF W.sub.s Decimal Full dimension H.sub.SF H.sub.s Decimal Full dimension
TABLE-US-00017 TABLE XVII Parameter Business Rule Type Description R.sub.F L.sub.SF/L.sub.u2 Integer Rows at side block F C.sub.F W.sub.SF/W.sub.u2 Integer Columns at side block F S.sub.F 1. H.sub.SF/H.sub.u2 Integer Stacks at main block F. Cannot exceed stacking 2. If S.sub.F > S.sub.current2 then set S.sub.F = S.sub.current2 limit specified S.sub.current2. Also overall stacks cannot 3. If (S.sub.F + S.sub.below2) > S.sub.total2 then set exceed overall carton stacking limit S.sub.total2. S.sub.F = S.sub.total2 S.sub.below2 Note, if S.sub.current2 = 0, then S.sub.F = 0 and Q.sub.F = 0. Q.sub.F R.sub.F * C.sub.F * S.sub.F Integer Carton quantity of the base main block F
TABLE-US-00018 TABLE XVIII Parameter Business Rule Type Description L.sub.SFS If (C.sub.F * W.sub.u2 > C.sub.M * L.sub.u1) Decimal Length is main block then set L.sub.SFS = R.sub.M * W.sub.u1 length when width of else set L.sub.SFS = L.sub.s the other block is greater than width of the main block, else length is the full length of the spatial unit W.sub.SFS W.sub.S C.sub.M * L.sub.u1 Decimal Full width less width of main block H.sub.SFS H.sub.S Decimal Full dimension
[0251] Overhead spatial unit can be determined only if the main block exists. For the main block without the other block, the overhead spatial unit (S.sub.O) is shown in Table XIX. For the other block exists at the side of the main block, the overhead spatial unit (S.sub.SO) is shown in Table XX. For the other block exists at the front of the main block, the overhead spatial unit (S.sub.R)) is shown in Table XXI.
TABLE-US-00019 TABLE XIX Parameter Business Rule Type Description L.sub.SO R.sub.M * W.sub.u1 Decimal Length of the main block. W.sub.SO C.sub.M * L.sub.u1 Decimal Width of the main block. H.sub.SO H.sub.S S.sub.M * H.sub.u1 Decimal Full height less height of main block
TABLE-US-00020 TABLE XX Parameter Business Rule Type Description L.sub.SSO R.sub.M * W.sub.u1 Decimal Length of the main block W.sub.SSO If (R.sub.S * L.sub.u2 >= R.sub.M * W.sub.u1) Decimal Width of main block then set W.sub.SSO = plus width of the C.sub.M * L.sub.u1 + C.sub.S * W.sub.u2 other block when else set W.sub.SSO = C.sub.M * L.sub.u1 length of the other block is equal or greater than length of the man block, else width is width of the main block. H.sub.SSO H.sub.S S.sub.M * H.sub.u1 Decimal Full height less height of main block
TABLE-US-00021 TABLE XXI Parameter Business Rule Type Description L.sub.SFO If (C.sub.F * W.sub.u2 >= CM * L.sub.u1) Decimal Length of main then set L.sub.SFO = block plus length of R.sub.M * W.sub.u1 + R.sub.F * L.sub.u2 the other block when else set L.sub.SFO = R.sub.M * W.sub.u1 width of the other block is equal or greater than width of the man block, else length is length of the main block. W.sub.SFO C.sub.M * L.sub.u1 Decimal Width of the main block H.sub.SFO H.sub.S S.sub.M * H.sub.u1 Decimal Full height less height of main block
[0252] Table XXII summarises the calculation of the Recursive Allocation Method and the Two Blocks System from the commencing spatial unit through all the subsequent residual cubical spatial units to the determination of the final allocable quantity (Q.sub.G). Each table column shows the cubical spatial unit to calculate in the recursive calculation process. The table rows show the calculation inputs and outputs. The input being the properties of the spatial unit and allocation arrangements possible for the spatial unit. The calculation outputs are for each allocation arrangement; are the allocation quantity for the main block (Q.sub.M), the two allocation quantity possible of the other blocks (Q.sub.N), the two possible corresponding adjacent cubical spatial units and the two possible corresponding overhead cubical spatial units. Each calculation references the Table described in earlier sections that has the calculation details. The table also shows three column groups of spatial units. First is the commencing spatial unit (single column) that initiates the calculation process representing a container load unit and for upright objects. Second group (two columns) is based on the result of the first column is of the recursive residual spatial units when the other block (Q.sub.N) is at the side of the main block. The residual spatial units are the adjacent spatial unit at the front (S.sub.SF) and at the overhead (S.sub.SO) Third group (two columns) is based on the result of the first column is of the recursive residual spatial units when the other block (Q.sub.N) is at the front of the main block. The residual spatial units are the adjacent spatial unit at the side (S.sub.FS) and at the overhead (S.sub.FO). Second and third column groups are for non-upright allocating objects. Do note each spatial unit column has its allocation arrangements listed in each of their table, which means each arrangement will have its one set of output, and lead to its follow on recursive calculation in the second and third column groups. Per spatial unit column, only the largest total quantity of all the allocation arrangements is returned.
TABLE-US-00022 TABLE XXII For the Other Block Q.sub.N@Side For the Other Block Q.sub.N@Front Adjacent Overhead Adjacent Overhead Commencing Spatial Unit Spatial Unit Spatial Unit Spatial Unit Spatial Unit (S.sub.SF) (S.sub.SO) (S.sub.FS) (S.sub.FO) Spatial Unit Table IV Table XV Table XX Table XVIII Table XXI Allocation Table VII Table X Table XI Table X Table XI Arrangements Object Upright Non-Upright Non-Upright Non-Upright Non-Upright Orientation Main Block Q.sub.M = Table XII Q.sub.MS = Table XII Q.sub.MSO = Table XII Q.sub.MF = Table XII Q.sub.MFO = Table XII Quantity Q.sub.M Other Block Q.sub.S = Table XIV Q.sub.SS = Table XIV Q.sub.SSO = Table XIV Q.sub.SF = Table XIV Q.sub.SFO = Table XIV Quantity Q.sub.N @Side Other Block Q.sub.F = Table XVII Q.sub.FS = Table XVII Q.sub.FSO = Table XVII Q.sub.FF = Table XVII Q.sub.FFO = Table XVII Quantity Q.sub.N @Front Total Quantity Q.sub.B = larger Q.sub.SF = larger Q.sub.SO = larger Q.sub.FS = larger Q.sub.FO = larger per Allocation of (Q.sub.M + Q.sub.S) of (Q.sub.MS + Q.sub.SS) of (Q.sub.MSO + Q.sub.SSO) of (Q.sub.MF + Q.sub.SF) of (Q.sub.MFO + Q.sub.SFO) Arrangement or (Q.sub.M + Q.sub.F) or (Q.sub.MS + Q.sub.FS) or (Q.sub.MSO + Q.sub.FSO) or (Q.sub.MF + Q.sub.FF) or (Q.sub.MFO + Q.sub.FFO) Adjacent Space S.sub.SF = n/a n/a n/a n/a Q.sub.N@Side Table XV Adjacent Space S.sub.FS = n/a n/a n/a n/a Q.sub.N@Front Table XVIII Overhead Space S.sub.SO = n/a n/a n/a n/a Q.sub.N@Side Table XX Overhead Space S.sub.FO = n/a n/a n/a n/a Q.sub.N@Front Table XXI
[0253] Only the commencing spatial unit will determine the residual spatial units (S.sub.SF, S.sub.FS, S.sub.SO, or S.sub.FO). Based on the Packing Preference in practice at warehouses, after determining the Allocable Quantity of upright blocks at the commercing spatial unit, all residual spatial units for non-upright blocks (second and third column groups) will ignore their residual spatial units.
[0254] For each of the spatial unit column in Table XXII, when the main block (Q.sub.M) calculation result in zero quantity, the spatial unit as a whole will return zero quantity. This means the other block (Q.sub.N) will have zero quantity and no residual spatial units (S.sub.SF, S.sub.FS, S.sub.SO, .sup.or S.sub.FO).
[0255] For the commencing spatial unit with an allocation arrangement that lead to a main block (Q.sub.M) with the other block (Q.sub.N) at the side of the main block, the follow on adjacent spatial unit at the front (S.sub.SF) and overhead spatial unit (S.sub.SO) results, which will apply the second column group Adjacent Spatial Unit (S.sub.SF) and Overhead Special Unit (S.sub.So) for the non-upright cartons calculation. Each allocation arrangement of Table X will have a total quantity (Q.sub.SF) which the largest of all allocation arrangements will be returned. Similarly, each allocation arrangement of Table XI will have a total quantity (Q.sub.SO) which the largest of all allocation arrangements will be returned. The largest returned value of Q.sub.SF and Q.sub.SO will sum with Q.sub.B to return the Q.sub.G of the commencing spatial unit and the allocation arrangement.
[0256] For the commencing spatial unit with an allocation arrangement that lead to a main block (Q.sub.M) with the other block (Q.sub.N) at the front of the main block, the follow on adjacent spatial unit at the side (S.sub.FS) and overhead spatial unit (S.sub.FO) results, which will apply the third column group Adjacent Spatial Unit (S.sub.FS) and Overhead Special Unit (S.sub.FO) for the non-upright cartons calculation. Each allocation arrangement of Table X will have a total quantity (Q.sub.FS) which the largest of all allocation arrangements will be returned. Similarly, each allocation arrangement of Table XI will have a total quantity (Q.sub.FO) which the largest of all allocation arrangements will be returned. The largest returned value of Q.sub.FS and Q.sub.FO will sum with Q.sub.B to return the Q.sub.G of the commencing spatial unit and the allocation arrangement.
[0257] For the commencing spatial unit with an allocation arrangement that lead to a main block (Q.sub.M) and without the other block (Q.sub.N), the follow on adjacent spatial unit at the side (S.sub.SF), adjacent spatial unit at the front (S.sub.FS) and overhead spatial unit (S.sub.FO) results, which will apply the column Adjacent Spatial Unit (S.sub.SF), Adjacent Spatial Unit (S.sub.FS) and Overhead Spatial Unit (S.sub.FO) for the non-upright cartons calculation. Each allocation arrangement of Table X will have a total quantity (Q.sub.SF) which the largest of all allocation arrangements will be returned. Each allocation arrangement of Table X will have a total quantity (Q.sub.FS) which the largest of all allocation arrangements will be returned. Similarly, each allocation arrangement of Table XI will have a total quantity (Q.sub.FO) which the largest of all allocation arrangements will be returned. The largest returned value between Q.sub.SF and Q.sub.FS and the largest return value of Q.sub.FO will sum with Q.sub.B to return the Q.sub.G of the commencing spatial unit and the allocation arrangement. D.sub.O note that Q.sub.G may be determined based on Overhead Spatial Unit (S.sub.FO) or (S.sub.SO) as both are identical since the other block (Q.sub.N) does not exist. Here, Overhead Spatial Unit (S.sub.FO) is arbitrarily picked for illustration.
[0258] For the commencing spatial unit, two allocation arrangements exist, ref. Table VII, which will result in two allocable quantity Q.sub.G values. Which allocable value is returned for the commencing spatial unit is governed by D.sub.facing value of the allocating object, ref. Table II.
Homogeneous Allocation Algorithm Extension
[0259] Empirical Adjustment of Allocable Quantity from Allocation by Geometry
[0260] User may want to override the Allocable Quantity (Q.sub.G) with a preferred empirical value to result in a new Allocable Quantity (Q.sub.GE), as referenced in
[0261] When subsequently the dispatch load unit is to be adopted by a product item, the item adopts the adjusted unit conversion ratio (Q.sub.GE) of the dispatch load unit to the container load unit.
Allocation by Weight (Q.SUB.W.)
[0262] Item may adopt one or more dispatch load units as its fulfillment and freighting units. With each dispatch load unit adoption, it is adopting a unit conversion (Q.sub.W=Q.sub.GE). As part of the adoption, the number of items to the dispatch load unit, and weight to have the dispatch load unit defined with a gross weight, all need to be specified, ref.
[0263] For an item associated dispatch load unit, with its inherited Allocable Quantity (Q.sub.W=Q.sub.GE) and with a unit gross weight, the resultant allocated gross weight may exceed the container load unit maximum load limit. If user prefers not to respect this maximum load limit, then the inherited dispatch load unit Allocable Quantity requires no change; otherwise, it is lowered to the maximum quantity not exceeding the container's maximum load limit, as referenced in Table XXIII. Accordingly, Unit Allocable Volume (V.sub.W) is recalculated.
TABLE-US-00023 TABLE XXIII Property Business Rule Type Description Q.sub.ctn M.sub.ctr/M.sub.ctn Integer Allocable Quantity (Q.sub.W) for the item dispatch load unit based on gross weight of the item dispatch load unit M.sub.ctn. Only return the integer value of the quotient in the calculation, the fractional part (or remainder) is ignored. If container maximum load is to be respected and Q.sub.ctn is less than Q.sub.W, then adopts Q.sub.ctn as the item dispatch load unit's updated Allocable Quantity Q.sub.W as instead of the Allocable Quantity Q.sub.GE from Allocation by Geometry. V.sub.W L.sub.ctr * W.sub.ctr * H.sub.ctr)/ Decimal Unit allocation volume of an Q.sub.W item dispatch load unit based on the final item dispatch load unit Allocable Quantity.
Empirical Adjustment of Allocable Quantity from Allocation by Weight
[0264] User may want to override the Allocable Quantity (Q.sub.W) with a preferred empirical value to result in a new Allocable Quantity (Q.sub.WE), as referenced in
[0265] The Allocable Quantity (Q.sub.WE) for the item is the unit conversion between the item associated dispatch load unit and the container load unit. The Unit Allocable Volume (V.sub.WE) for the item dispatch load unit is for use in the heterogeneous allocation algorithm.
Packing Arrangement Details in a Container Load Unit
[0266] For a dispatch load unit to a container load unit, the details on rows, columns and stacks for each dispatch load unit block in each spatial unit can be presented for review and as a packing instruction for packing a container.
[0267] As the Allocable Quantity is reduced with an empirical value, the reduction may start from either the overhead (S.sub.SO, or S.sub.FO) or the adjacent (S.sub.SF, S.sub.FS) spatial unit as preferred. In either case, reduction starts at the other block (Q.sub.N) before proceeding to the main block (Q.sub.M). Only if all the quantity from the overhead and adjacent spatial unit are all reduced to zero can the upright blocks be reduced. At the upright block, again, reduction starts at the other block before proceed to the main block.
Heterogeneous Allocation Algorithm Model
[0268] The aim of the heterogeneous allocation algorithm is to determine the minimum container load units (CLU) required for a given scenario, typically in the form of a transaction with a list of items, each with a specified dispatch load unit (DLU) and quantity. As the algorithm is dynamically applied, the algorithm will recalculate as the scenario is updated.
[0269] The algorithm is depicted in
[0270] The algorithm preference is to use the Allocable Quantity (Q) to determine as much of the CLU quantity as possible. Only when the conditions to apply Allocable Quantity is exhausted will Allocable Volume (V), ref.
[0271] The preference to use Allocable Quantity is the allocation quantity between a dispatch load unit and a container load unit is known, and often it is empirically tested and refined over time. Thus the calculation based on Allocable Quantity at sales will have become highly trustworthy by backoffice logistics, with calculated quantity is executable by backoffice.
[0272] Allocable Quantity is only used when all the dispatch load units being considered for allocating to a container load unit have identical allocation properties, which is the condition that the homogeneous allocation algorithm is applicable. The allocation properties are the dimensional and loading properties as can be referenced in Table II.
[0273] If the dispatch load units being considered for allocating to a container load unit do not have uniform allocation properties, allocation calcuation is by unit dispatch load unit Allocable Volume (V). Unlike Allocation by Allocable Quanity, allocation by Allocable Volume is an estimation. For the best possible estimation, Allocable Volume is only applied at the final stage of the heterogeneous allocation algorithm, ref.
[0274] The heterogeneous allocation algorithm is a three steps model as referenced in
An Illustrated Example of Calculating the CLU Quantity
[0278] The heterogeneous allocating algorithm, ref
TABLE-US-00024 TABLE XXIV Item DLU DLU Qty Item A DLU1 3,350 Item B DLU1 430 Item A DLU1 1,100 Item C DLU2 5,600 Item D DLU3 750 Item E DLU2 15 Item C DLU2 25 Item C DLU2 350 Item C DLU2 450 Item C DLU2 400
Allocation by Allocable Quantity on Item
[0279] Per
[0280] Per
TABLE-US-00025 TABLE XXV Full Remainder DLU CLU DLU Item DLU Qty Q Qty Qty Item A DLU1 3,350 800 4 150 Item B DLU1 430 800 0 430 Item A DLU1 1,100 800 1 300 Item C DLU2 5,600 500 11 100 Item D DLU3 750 800 0 750 Item E DLU2 15 500 0 15 Item C DLU2 25 500 0 25 Item C DLU2 350 500 0 350 Item C DLU2 450 500 0 450 Item C DLU2 400 500 0 400 Sub-Total 16
[0281] Line 1 Item A has 3,350 DLU.sub.1; with an Allocable Quantity Q of 800 results in 4 full CLU Qty and 150 remaining DLU Qty, which can be referred to as an DLU-lot. The same is applied to each line item to result in a Full CLU Qty sub-total of 16, and each line item DLU-Lot is unable to fill a CLU on its own.
[0282] Per
TABLE-US-00026 TABLE XXVI Item DLU DLU-Lot Item A DLU1 300 Item A DLU1 150 Item C DLU2 450 Item C DLU2 400 Item C DLU2 350 Item C DLU2 100 Item C DLU2 25 Item B DLU1 430 Item D DLU3 750 Item E DLU2 15 Sub-Total
[0283] Per
TABLE-US-00027 TABLE XXVII Item DLU DLU-Lot CLU Item A DLU1 300 Item A DLU1 150 Item C DLU2 450 1 Item C DLU2 50 Item C DLU2 350 1 Item C DLU2 150 Item C DLU2 200 Item C DLU2 100 Item C DLU2 25 Item B DLU1 430 Item D DLU3 750 Item E DLU2 15 Sub-Total 2
Allocation by Allocable Quantity of Identical Allocation Properties
[0284] Per
TABLE-US-00028 TABLE XXVIII Queue 1 Queue 2 Item DLU DLU-Lot Item DLU DLU-Lot Item A DLU1 300 Item C DLU2 200 Item A DLU1 150 Item C DLU2 100 Item B DLU1 430 Item C DLU2 25 Item D DLU3 750 Item E DLU2 15
[0285] Item A, Item B and Item D of Item Queue 1 all have identical allocation properties despite having different dispatch load unit DLU.sub.1 and DLU.sub.3. Item C and Item E have identical allocation properties since they have identical DLU.sub.2. Item Queue 1 has an Allocable Quantity Q of 800 while Item Queue 2 has an Allocable Quantity Q of 500, both their Q value can be referenced from anyone of their line item Item Allocation Lookup Table.
[0286] Each Item Queue is to be sorted, ref.
TABLE-US-00029 TABLE XXIX Queue 1 Queue 2 Item DLU DLU-Lot Item DLU DLU-Lot Item D DLU3 750 Item C DLU2 200 Item A DLU1 300 Item C DLU2 100 Item A DLU1 150 Item C DLU2 25 Item B DLU1 430 Item E DLU2 15
[0287] For Item Queue 1, line items Item A are grouped together with a super-DLU-Lot of 450, which is less than that of Item D of 750 and more than that of Item B of 430. Similarly for Item Queue 2, line items Item C with a total of 325 is more than that of Item E of 15.
[0288] Per
TABLE-US-00030 TABLE XXX Queue 1 Queue 2 Item DLU DLU-Lot CLU Item DLU DLU-Lot CLU Item DLU3 750 1 Item DLU2 200 D C Item DLU1 50 Item DLU2 100 A C Item DLU1 250 1 Item DLU2 25 A C Item DLU1 150 Item DLU2 15 A E Item DLU1 400 Sub- 0 B Total; Item DLU1 30 B Sub- 2 Total
Allocation by Allocable Volume and Weight
[0289] Per
TABLE-US-00031 TABLE XXXI Item DLU DLU-Lot Item C DLU2 200 Item C DLU2 100 Item C DLU2 25 Item E DLU2 15 Item B DLU1 30
[0290] All Item C are sorted, per
[0291] Per
[0292] If CLU maximum load limit is to be respected and if all the allocated item release units have a gross weight exceeding the maximum load limit of the CLU, then item dispatch load units are unallocated from the CLU in reversed allocation order until the CLU is not overloaded.
[0293] Allocation of item dispatch load units continues until all are allocated. The last CLU may result in not being fully utilized.
[0294] With reference to Table XXXII, it is assumed all the item dispatch load units can be allocated into one CLU.
TABLE-US-00032 TABLE XXXII Item DLU DLU-Lot CLU Item C DLU2 200 Item C DLU2 100 Item C DLU2 25 Item E DLU2 15 Item B DLU1 30 Sub-Total; 1
Totaling Required Container Load Units
[0295] Per
[0298] Allocation Properties, as indicated in Table XXX. [0299] 3. 1 CLU from step #3 based on allocation by Allocable Volume and Weight, as indicated in Table XXXII. [0300] 4. For the given scenario, the heterogeneous allocation algorithm derives a total of 21 (from 18 +2 +1) CLUs required.
A More Complex List of Dispatch Load Units for Calculation
[0301] With the same logic but a more complex scenario, the list of items for containerization may be as set forth in the example of Table XXXIII.
TABLE-US-00033 TABLE XXXIII Dispatch Location Item DLU DLU Qty Location A Item A DLU1 3,350 Location A Item B DLU1 430 Location A Item A DLU1 1,100 Location A Item C DLU2 5,600 Location A Item D DLU3 750 Location A Item E DLU2 15 Location A Item C DLU2 25 Location A Item C DLU2 350 Location A Item C DLU2 450 Location A Item C DLU2 400 Location B Item P DLU1 350 Location C Item X DLU99 350 Location B Item Q DLU1 150 Location B Empty Box A DLU9 200
[0302] Here, items are from three locations. Some items are from location A, some are from location B and some are from location C. Since each location must have their containers arranged for all the DLUs of that location, and may be specified with different CLU, DLUs are grouped and separated by locations. Heterogeneous allocation algorithm is applied to the line items of each location to determine the CLU quantity for each location. The total CLU quantity for the scenario is the sum of CLU quantity of each location.
Packing Arrangement Details in Container Load Units
[0303] After a scenario has applied the Heterogeneous Allocation Algorithm and all the CLU allocations are determined, each container load unit can have their list of allocated item dispatch load units with quantity presented. However, for the details on each allocation block and the rows, columns and stacks in the block will depend on whether the container load unit is allocated by Allocable Quantity or by Allocable Volume.
[0304] All container load units that are allocated by Allocable Quantity in the heterogeneous allocation algorithm can have the dispatch load unit allocation arrangement details presented in blocks with rows, columns and stacks. This information can be referenced from anyone of the item dispatch load unit record allocated in the container load unit. This is applicable to any CLU determined from
[0305] Any container load units that are allocated by Allocable Volume in the heterogeneous allocation algorithm cannot have their dispatch load unit allocation arrangement details presented in blocks with rows, columns and stacks. How such a container load unit is packed is not being predetermined. This is applicable to any CLU determined from
Variations to the Heterogeneous Allocation Algorithm Model
[0306] Sorting DLU-Lot in
[0307] The algorithm may support packing preference to not have any DLU-Lot to be split over different CLUs in
[0308] The algorithm at
[0309] While embodiments of the foregoing system have been set forth for purposes of illustration, the foregoing description should not be deemed a limitation of the invention herein. Accordingly, various modifications, adaptations and alternatives may occur to one skilled in the art without departing from the spirit and the scope of the present invention.