[ http://issues.apache.org/jira/browse/OFBIZ-282?page=comments#action_12434754 ] Jacques Le Roux commented on OFBIZ-282: ---------------------------------------
I think it's interesting not to loose this part : Something like this has been proposed in the past, and it would be a great thing to have. Getting stuff in place to enter and administer the different boxes shouldn't be too bad. The entity should probably be named something to clarify the purpose, like ShipmentBox. The HARD part it doing something to automatically decide on a box. That is a heuristic optimization problem and not simple. A nice first step is to write something that would check to see if a certain set of products that are assigned to a ShipmentPackage will fit in the box associated with the ShipmentBox associated with that ShipmentPackage. That can be used as part of the heuristic for auto assignment later on, and in the mean time provides some validation. If you have the dimensions (in MFG packagin dimensions) of a product you can somewhat estimate how much packing material will be needed and from that volume the appoximate weight according to whatever you use. BIG BIG BIG WARNING HERE: This is all real nice and stuff, but keep in mind that while for VERY high volume places it is nice to automatically split up a shipment and assign the items to packages and boxes, the estimated weight it NOT always permissible to use. You'll have to find out from your shipping company (UPS, FedEx, USPS, Airborne, whoever) if they allow estimation and what their tolerance is. If you claim certain weights and they aren't based on actual weighing of the packed boxes you are on thin ice if they have strict guidelines for reporting inaccurate weights and therefore getting cheaper fees, messing up the carrier weight calculations and what not... Commentaire de la part de Jacques Le Roux [13/janv./06 02:01 AM] [ Lien permanent ] Hi, I will soon need something like that too. A prospective customer wants to sheep T-Shirts from Egypt to France, great cotton in Egypt. He wants to have them packed in boxes following somes criterias. He wants to pack variants in same boxes (I hope to generalize the heuristic) and with packing optimization (at least 2 types of constraints so). I have no time yet to think more about it, but for sure I will do it or work on it if someone begins before me. I hope to be back on OFBiz at spring. Jacques Commentaire de la part de Jacopo Cappellato [16/janv./06 12:35 PM] [ Lien permanent ] This is intresting. I've too developed a very simple auto package creator in OFBiz; it is not in svn because its logic is rather simple and is not generally applicable and so it is not good enough for OFBiz(we've developed it to generate some packages useful in the kitchen manufacturing industry). By the way, here are some of the details of it (something good, something not): a) we have used the ShipmentBoxType entity to store information about all the available boxes (dimensions etc...) b) we have added a new field to the Product entity (shipmentBoxTypeId) to store the box type that should be used to ship the product c) based on the product's dimensions and on the box's dimensions a very simple algorithm is used to calculate the number of boxes (the products are divided accordingly to their box type, then, for each group, the number of packages is calculated) A final note: sometime one single product is shipped in more than one package (e.g. a table could be delivered into two packages, one with the legs)... we should take this into account. I think we did something about this for the kitchen industry... but I don't remember well Commentaire de la part de Jacques Le Roux [16/janv./06 04:34 PM] [ Lien permanent ] Thanks for these details Jacopo Jacques Commentaire de la part de Daniel Kunkel [17/mars/06 08:25 AM] [ Lien permanent ] At the same time that this feature is implemented, it might be a good to organize and simplify the calculations for orders that need to be split into multiple boxes. As it is currently, if an order is too big for one box, each shipping estimate module must handle the breaking up and calculating of multiple boxes, sizes, weights and costs which complicates the methods significantly... It makes more sense to me to refactor this so this module will take care of breaking up the order appropiately have a call to each carrier/method to calculate each box's shipping costs individually. This method probably won't be accurate in the case where multiple boxes to the same address is discounted by a carrier, however that is a situation that can easily be corrected manually if it needs to be handled at all. Commentaire de la part de BJ Freeman [17/mars/06 09:09 AM] [ Lien permanent ] from a practical point of view it would be better to provide an estimate that is single box, then have then order complete email, specify a credit if the multiple box shipment turns out less than the orginal shipment estimate. The con to this is the overall order maybe higher than other stores for the same items. the pro is a well worded explanation about not being charged till shipped, and shipping may be less if more than one item will fit into the shipping container, will make customers appreciate the thoughtfullness. from a technical view-- This should be rule based instead of hardcoded. this brings about it own can of worms, to have the rules checking for consitency. The reason is each company, or shipper has there own rules about packing. also there is the type of packing material that an shipper will use. There should be a rules checking to note when a shipment does not fit the estimate, for evaluation of the rules. a real pie in sky would be to have the decrepency create exception rules, automatically. atleast that is the direction i have been working on. Commentaire de la part de Jacques Le Roux [17/mars/06 11:51 AM] [ Lien permanent ] My 2 cents about inner size Usable inner size isn't difficult to know ? For example for hardware you have to stuff the box with polystyrene, paper or such, but for shirt you don't need it. Perhaps a parameter may be used here (% of inner size for example)... Jacques Commentaire de la part de Jacques Le Roux [17/mars/06 11:54 AM] [ Lien permanent ] Inner size sequel, For the parameter, perhaps we may create a stuff parameter with choice for user (polystyrene, paper, etc.) with according associate % of inner size consumed by the stuffing. Jacques Commentaire de la part de Bradley Plies [21/mars/06 05:58 PM] [ Lien permanent ] Really the problem is broken down into two main processes: 1. Planning - Identifying feasible sets of packaging configurations that would satisfy the shipping problem. 2. Searching - Selecting the most attractive/optimal configuration based on heurestics such as total cost (courier + packing materials), and wasted space. Both of which could be certainly done in an automated way. Planning itself is covered under the AI subject of "Planning" for automated problem solving. Here is a link to useful resources: http://www.csc.ncsu.edu/faculty/stamant/planning-resources.html There may well be some planning tools in Java under some liberal academic license. Basically you feed a Planning engine an initial state, rules, and conditions for success and it outputs solutions (if any). Data we would feed into a planning engine are: item volumes, item packing requirements (enclosed in bubble bags, etc.), item lists, packing materials lists, courier restrictions, options (such as splitting into sub-packages), packing rules (cannot be packed with oxidizers, etc), or whatever else might be useful. The planner would then provide a set of solutions that met all conditions for success and without violating rules. The solutions could then optionally be filtered based upon some criteria such as "No configurations with 10% wasted volume" or something. Finally the remaining solutions are ranked by a cost quote from the respective couriers. Best fit wins... and is recorded and used. This has applications not only in price quoting, but perhaps also in automatically discovering optimal packing configurations for your goods (and future goods & materials) without having the unskilled laborers in the shipping department to "discover" them on their own or having to rethink your favored configurations when new materials are introduced. Commentaire de la part de Bradley Plies [21/mars/06 06:11 PM] [ Lien permanent ] A simpler solution I suppose would be to just use a simple non-optimal price quote. Then refund the difference (if you overcharged) as a gift certificate or store credit. This is much more a marketing solution than a technical one, but does have that special "glue" to keep your customers coming back while suggesting you are trying to give them the best deal. > Shipping Box Size and Weight estimator > -------------------------------------- > > Key: OFBIZ-282 > URL: http://issues.apache.org/jira/browse/OFBIZ-282 > Project: OFBiz (The Open for Business Project) > Issue Type: New Feature > Components: ecommerce > Environment: new feature > Reporter: Daniel Kunkel > Priority: Trivial > > Moved from old jira - 669. Placeholder for the feature. > -- > Having gotten the USPS rate estimator working... I'm realizing that in order > for it to be useful we need to get an accurate estimate of which box will be > needed, and how much it weighs with packing materials. > Proposed Scheme > Add a new table for shipping boxes... > box id > height > width > depth > height uom > width uom > depth uom > --- > usable height > usable width > usable depth > usable height uom > usable width uom > usable depth uom > weight > weight uom > etc > --- > Algorithm... > 1.) Requires all products height >= width >= depth... or have the > dimensions ordered that way for algorithm > 2.) Find Maximum Height Width and Depth of any product > 3.) Calculate total shipping volume for all products > 4.) For all boxes in the above table, sort by usable volume that is greater > than total shipping volume. > 5.) Searching box by box, accept the first box that is large enough in every > dimension (max length, max width, max height). > 6.) Add the weight of this box to the product weight... and use this for > shipping. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
