455,403 Members | 1,534 Online
Need help? Post your question and get tips & solutions from a community of 455,403 IT Pros & Developers. It's quick & easy.

# Shipping Matrix Calculations

 P: n/a Hi, I was just wondering if anyone has had any experience in developing a shipping matrix. We are based in the UK, and we need to ship both locally and internationally. Local shipping is priced by weight and doesn't matter about the number of packages, international shipping is by weight and package size, so we need to know the number of packages. Whilst we can decide how many of product x fits in a box, and what each product weighs, what happens if someone orders: -2 of product x, -3 of product y and -4 of product z the problem here is how can we tell if it will all fit in one box etc...? Should we need to calculate the volumes of each item? Maybe we should treat each order of each product type as a separate shipping item, e.g. the example above shipped internationally should be treated as three shipping orders and priced accordingly (even though they may all fit in one box). Has anyone solved this problem in the past? Thanks for any advice! Chris. May 4 '06 #1
6 Replies

 P: n/a Hi Chris, This forum is more for the use of C# language nuts... You will probably be better off in one of the SQL or database forums. -- Bob Powell [MVP] Visual C#, System.Drawing Ramuseco Limited .NET consulting http://www.ramuseco.com Find great Windows Forms articles in Windows Forms Tips and Tricks http://www.bobpowell.net/tipstricks.htm Answer those GDI+ questions with the GDI+ FAQ http://www.bobpowell.net/faqmain.htm All new articles provide code in C# and VB.NET. Subscribe to the RSS feeds provided and never miss a new article. "Chris Buckett" wrote in message news:11**********************@y43g2000cwc.googlegr oups.com... Hi, I was just wondering if anyone has had any experience in developing a shipping matrix. We are based in the UK, and we need to ship both locally and internationally. Local shipping is priced by weight and doesn't matter about the number of packages, international shipping is by weight and package size, so we need to know the number of packages. Whilst we can decide how many of product x fits in a box, and what each product weighs, what happens if someone orders: -2 of product x, -3 of product y and -4 of product z the problem here is how can we tell if it will all fit in one box etc...? Should we need to calculate the volumes of each item? Maybe we should treat each order of each product type as a separate shipping item, e.g. the example above shipped internationally should be treated as three shipping orders and priced accordingly (even though they may all fit in one box). Has anyone solved this problem in the past? Thanks for any advice! Chris. May 4 '06 #2

 P: n/a Bob Powell [MVP] wrote: Hi Chris, This forum is more for the use of C# language nuts... You will probably be better off in one of the SQL or database forums. Ok, I know now that there are probably better groups to post this to. I just happen to work in C#. Chris. May 4 '06 #3

 P: n/a > Should we need to calculate the volumes of each item? Maybe we should treat each order of each product type as a separate shipping item, e.g. the example above shipped internationally should be treated as three shipping orders and priced accordingly (even though they may all fit in one box). Has anyone solved this problem in the past? This makes for a really interesting algorithm; one that I've spent some time on in the past. If you calculate based on volume alone then you might be able to decide if you can fit in another area of a larger volume but you won't be able to determine whether you can snug in the box. For example, a shipping container might have a volume of 27 sq. meters but the dimensions might be something like 3 x 3 x 3 meters. The shipping items you are shipping might be 10 x 1 x 1 meters and won't fix in the shipping container. Ideally, you'll be using the dimensions of the shipping items and then fit them together like in the game of tetris. There's many ways to do this and the way I chose was to create a 3 dimensional matrix and fill the hypothetical unit with a value to indicate that a shipping item takes up that space. The size of the matrix will depend on your smallest calculatable unit (3.8 meters is really 38 centimeters, etc.) so one of your matrix indices represents 1 centimeter. On another dimension of the shipping item, perhaps the smallest unit is 1 meter so your other matrix index represents 1 meter. Of course, the matrix can be huge but like I said, there might be better ways to do this. In the end, you can't use volume or dimensions alone to run an abstract calculation because the math will always work out. You have to somehow be able to fit them together to see if they will fit in the shipping container because even though the volume works out and the dimensions seem to, once you "stack" them together you might not have enough space to fit the remaining items. Thus, think of it in terms of 3D tetris and you'll do fine, conceptionally. Another thing is to weed out the largest of the shipping items, to see if the large of its dimensions exceeds the larger of the shipping container and then the to the second largest then to the 3rd largest. If any of them are too large then you automatically know it won't fit. The other thing is, we keep track of which dimension represents the "top" of each the shipping item and the shipping container (if there must be a top such as a television set or something) and that helps to narrow down the game of tetris, so-to-speak. Thanks, Shawn May 4 '06 #4

 P: n/a In addition to all I said in the previous post I forgot the mention an "optimzation" I eventually gravitated towards, but the optimzation will only work in certain conditions: if you ship the same products most of the time then you can pre-compute shipping arrangements and re-use them. For example, you know that 1x Product A will fit nicely into Package A-1. For all orders of 1x Product A, you use Package A-1. You know that 1x Product A + 3x Product B + 4x Product C will fit nicely into Package ABC-134. Whatever Package ABC-134 is, you define it. I can be a 1 x 3 x 3 meter box. In any case, you've already figured out how to "snap" the shipping items into the Package and you just record it. On all future shipments of the same order (or any other order that match the dimensions of Product A/B/C) you use the same Package ABC-134. You can either manually enter this data into the system for future use or you just record it somehow from a previous computation that automatically computes whether the items will fit in the package and in what optimal stacking scheme. Thereafter, you just do a lookup and there is no computation necessary. There are more factors to consider, like whether Product B is fragile (glass) and Product C is an ironball, you obviously won't ship them together. Again, you can create attributes for each package and have some business rules that dictates what items go together and what items cannot and then you basically store your information accordingly. Sometimes glass and iron can ship together. Maybe you have a flat iron plage of some kind you can just pack the glass on top and indicate to the shipper "this side up". Hope I got you thinking. Thanks, Shawn May 4 '06 #5

 P: n/a Thanks for that Shawn, It's good to get another head involved - I was kind of thinking of a 3D tetris scenario, but I hadn't considered fragile and non-fragile items, and the concept of products having a "side up." We had thought about a sort of "self learning" system for calculating shipping - that is, when someone orders a product mix, we enter the actual shipping cost to their destination (after having guestimated shipping first), and next time someone orders the same product mix to a similar destination, we use the orginal actual shipping cost as a lookup. I'm just concerned that we may take more time "teaching" the system about product mixes, and not get enough hits (I guess I'm going to have to analyse previous orders). I'll look into doing a lookup for product packing as you suggest and have a chat with the warehouse guys. At present, we're using a simple percentage of product cost with a minimum fee, which works out for quite a lot of orders, but we're starting to sell more high value (but small) items, which makes for cheap shipping costs for us, but expensive shipping costs for the customer. Working out shipping for multiples of individual products seems relatively simple - it's combinations of products that adds the hard work! I expect that unless I come up with a better solution, we'll probably go with a lookup matrix for individual product orders and common product mixes, and a sort of guestimate (erring in our favour) for unknown product mixes - possibly with the "learning" facility to convert an unknown to a known mix. I've had a quick look at the UPS and FEDEX api's, but they all need to know the size & weight of the package before giving a price (I guess that should've been obvious). Cheers, Chris. http://blog.cecatech.co.uk/chrisb May 5 '06 #6

 P: n/a If you don't want to spend the effort to dynamically compute packing strategies (which can be time-consuming and expensive) for what you view as a marginal benefit, you're better off to go through the pain of figuring out a strategy when you need to and then "caching" that stretegy for future lookups as I stated earlier and as you implied you might do. Even for a place like Amazon, having such a dynamically computing program may not be so much of a benefit as what they sell are usually of predictable characteristics and will likely fit into any of various package sizes they have (I know, I purchased over 500 books for amazon (computer programming books) of various quantities) and usually its the same box for a certain quanity. Some place like Wal-Mart or a freight company, on the other hand, might get much more utility from such a program and they ship larger objects into more shipping space and usually a wide-degree of contents that can't easily be predicted. It really depends on what you perceive your overall gains to be. Thanks and Good Luck, Shawn May 5 '06 #7

### This discussion thread is closed

Replies have been disabled for this discussion.