I have a problem in that I use drop shippers scattered around the country, and thus ship from different origins. It appears we can only plug in one origin in magento. What this will cause is either me, or my customer taking a biit of a hit on shipping, as it cannot be accurately calculated by the plug in.
I had a very skilled programmer look it all over to see if he thought he could add this to it. He was overwhelmingly impressed with the software, and commented that there is no question tht “these guys really know what they are doing” (which I knew LOL) , and he said most liekly he could alter it==, but two detriments, it would take him many hours to go thru all the code, and even if he accomplished it, when new releases came out, it could possibly alter it enough that it woudln’t work any longer and hes back on the payroll.
It does get complex as a customer may buy two items from one drop shipper and 1 item from another, thus it cannot be grouped together as one shipment. The UPS Calculator takes all of this into account when it has the origin zip of each product. I know this as I use Cart Manager which is only a cart, on another of my ecomm sites, but it is always within 1 to 3 bux different from what I end up getting charged. In the add to cart link you pass cart manager the origin zip of that product and weight and then it plugs into ups and figures it out.
So anyway, its a feature request and its also an inviation to employ anybody who understands this code to make some money on the side doing it. I would hire somebody to do it, and even if the magento team then wanted to fold it in to the package, it would be fine with me. I would just like to have the feature so I can use what otherwise I think is almost a perfect product.
All the ecomm solutions I have researched have this feature, they just don’t come close to magento is in other areas.
I really really want to use Magento, Ithnk its superb, but its just for me, and I would think others, it would be good to have this feature. Many biz’s do not ship from just one location, whether they are big companies, or small potatoes like me, who uses various drop shippers.
If I am alone in this desire, so be it. But still willing to hire anyone who can do it and then give it as a donation to the overall package. One of the team members would of course be best as nobody knows the code better and he/she could assure its foldable into the full product then.
In essence I am glad to pay for the feature then donate it to the cause.
I would also love to have a feature like this. Right now in my osCommerce store we use table rate shipping, and either we or the customer eat the difference in shipping. Sometimes it’s only pennies, but a lot of times we are eating $5-10 or more on the shipping. We’ve set the shipping charges to error on the side of the customer getting undercharged, as I don’t think it’s fair to overcharge shipping for customers. The fact that we have dozens of drop ship suppliers around the county has prevented us from using calculated shipping rates.
This is a serious miss if what you say is true. I am waiting for 1.0 to evaluate, but it seems a bit inconceivable that you could only have one origin ship point per site.
I would say the majority of ecommerce websites drop ship in some form or another. The solution I currently use allows you to specify vendor/origin zip on the product page set up screen.
The one roadblock I am running into with my current solution is that sometimes I need to combine products from separate vendors/origin zip on one page and I can’t do this b/c origin zip is set per page and not per varient. I think Magentos bundling takes care of that.
I am sure this can be easily fixed by Varian. I have over 200 vendors/origin zip codes.
This is a serious miss if what you say is true. I am waiting for 1.0 to evaluate, but it seems a bit inconceivable that you could only have one origin ship point per site.
I------
I am sure this can be easily fixed by Varian. I have over 200 vendors/origin zip codes.
Yes I was pretty surprised by it myself. I did ask Roy if it was planned to be implemented and he said no.
I have even have offered here to pay for the modification and donate it to the package and not even had a response. I realize it would not be cheap, I suspect it would take some time to do and affect other sections of the program etc. So I can understand some reluctance as it may be a lot of modules that would need modifying etc.
I am in touch with a programmer who thinks he can implement it, he has worked a lot with ecomm software. We only hooked up yesterday so have not got into much detail yet.
One problem I see and I think you eluded to it, is a customer buys 2 things from zip code A, 1 thing from zip code B etc on same order. The Magento cart and I imagine all carts(?) will treat it as one shipment of course, even though we have to pay for the separate shipments. This is a problem that would seem pretty complex to solve though. All we could do is charge the customer for two diff shipments and I don’t think they would like that. But cutsom programming could probably evaluate the origin zips and sort of ball park the figure after figureing precisely what each shipment would be.
I have used a cart on another site of mine called Cart Manager where in the add to cart code is the origin zip. What it does with 2 or 3 diff originis in one order I don’t know, just how far it goes I can’t be sure. I should probably ask their support. Maybe they just use the zip that is there the most times. Hard to say really! It is a bit of a complex problem.
My idea was in the proudct set up of magento to add a field that would be “Origin Zip”, optional, but if there, then passed to the cart. If left blank the one zip in the admin config would prevail.
Its a sticky wicket no matter how its dealt with, and you may have more ideas than I, or more experience with it. Its just something that has come into my awareness as this is the first time I have sold stuff on one site with more than one ship origin.
I am actaully thinking of picking some place like Topeka, KS or Jeff Citty Mo which seem to be sort of the middle of the country and using that. LOL Not sure how tht would wrok out, am diong some testing on it right now in fact.
Huh...weird that no support will be coming. It really is not complicated for straightforward UPS/FedEx/DHL type of products. You were very close with your suggestion.
If you have a warehouse/inventory - set up the global origin zip on site set up. That is probably how it works now. However, many people have multiple warehouse locations. So again the ability to only have one zip excludes all of those people (along with people who have multiple vendors/drop-shippers)).
When you set up a product have a zip code field (for items you don’t inventory) that overrides any global zip.
Or you can have a vendor section where you set up all your vendor info (including YOUR warehouses) and you choose from this vendor list (drop-down) while setting up the product.
This is not hard for the integrated shipping calculators. The required shipping data is sent through the calculators for each product ordered, and results are added up and presented to the customer as a shipping total.
Where the breakdown comes in this is the processing of the order on the backend because each item from a different vendor needs separate tracking etc...and then the customer gets confused etc because their order is showing up in pieces etc…
So complicated on the frontend to the customer....yes...complicated on the backend in getting a real shipping $....it shouldn’t be?
I have a question that is somewhat related. As I mentioned above, we have a bunch of different drop ship suppliers. So it would seem that multiple shipping origins would be beneficial to me. However, our set up is very complicated. First, we have over a dozen different drop ship suppliers. Some of those suppliers have multiple warehouses across the country. So in order to get an accurate shipping quote, we would have to know which of their warehouses the product is coming from before doing the shipping calculations. However, that information is not available to us until after the order is placed. We have no way of knowing which warehouse each product will come from or if the product is in stock at all in any of them. We also don’t always get certain products from the same supplier. Often we will go back and forth between multiple suppliers depending on who has it in stock, who is closest to the customer, and who has the best price. We try to have a minimum of 2 different suppliers for each product just to make sure it’s always in stock, but sometimes that isn’t enough. We also ship some products out of our office because it’s cheaper for us that way, or we will stock items that are notoriously out of stock. As you can tell, it would be very difficult or nearly impossible for us to offer calculated shipping rates online, and that’s a big problem for us. Right now we do table rate shipping, which goes up as the price goes up. Then at a specific price point, the shipping is free. That works well in our case, but we only offer ground shipping online. We get a lot of complaints because we don’t offer overnight or 2-day shipping right on the website, and customers can’t select the carrier (UPS, FedEx, etc). Now, in most cases ground shipping will get the product there in less than 3 days, but the customer doesn’t know that. And also, the customer can call and get a quote for overnight if they really need it. In those cases we will call our suppliers and get stock info, then call the customer back and take the order. It’s a pain, and some customers just won’t do it. So given all of that, what would be the best way to handle this? I don’t expect Magento to solve this problem, but I would like to hear from anyone who’s been in a similar situation and has a good solution.
Seems to me that shipping origin becomes a custom product attribute that overrides the default origin. I wonder if Magento’s thinking on this is that it is not really a eCommerce solution problem to solve but one for an Inventory solution to solve. Just specutlating…
Seems to me that shipping origin becomes a custom product attribute that overrides the default origin. I wonder if Magento’s thinking on this is that it is not really a eCommerce solution problem to solve but one for an Inventory solution to solve. Just specutlating…
I think it’s both actually. The issue at hand (at least for me) is what to charge the customer. If you want to be fairly accurate, you have to know not only where the product is going to, but where it’s coming from. Having multiple shipping origins really complicates things, especially if you are sending two products from two different warehouses to the same customer on the same order. I don’t expect Varien to provide a solution to this, so I think the community should come together and hopefully work something out.
Seems to me that shipping origin becomes a custom product attribute that overrides the default origin. I wonder if Magento’s thinking on this is that it is not really a eCommerce solution problem to solve but one for an Inventory solution to solve. Just specutlating…
Hi , I have read this several times, and just not sure what you mean about ‘inventory solution’. Magento is what is figuring the shipping calculation, nothing else, and its doing it based on the zip code provided in admin as the origin. Are you suggesting that every product be shipped from the same location, move it all to one warehouse. Just not following you, though you may have a good idea that I’m not understanding.
Maybe you could elaborate as you may have a very good idea which I am just not understanding.
I always know what zip my proudct is coming from because each drop shipper has one location. Thats what I meant about having an optional proudct setup field “Origin Zip” which can either be left blank, in which case the default zip is passed to the calculator, or if filled in , that zip is passed to the calculator.
The problem with that as I also pointed out though, is when you have a cusomer who buys 2 products shipped from zip code A and 1 product shipped from zip code B. What can be done then? I suspect only custom programming is the solution to that.
But this simple additon of an origin zip in product setup, would make for x% more accurate shipping quotes for customers. Esp given that most people buy one or two products and they are often going to be coming from the same drop shipper. It doesn’t seem a hard addition and would make magento that much more flexible and valuable. Its still just one origin zip code, but is switchabel depending on the product purchased. As I say this would make it x amount more accurate, totally more accurate in fact, until they buy from different drop shippers on the same order.
Like the other person here with the car icon whose name I cannot see right now, I am mostly concerened about my customer being charged too much for shipping and cancelling an order.
I have done some testing on dummy orders and it seems the closest best solution is to pick a middle USA zip code. I found out, that I don’t think UPS is divided up into very many zones, as I found little difference often, when I changed the origin zip, in fact often the charge was the exact same, be it origin Iowa or origin Ohio etc. Its when I set origin to Florida or Wash state that a very signifciant differece was seen.
So that got me wondering if this is as big a problem as I thought it was LOL Sometimes I will just pay more for shipping than I collect from the customer, sometimes I will pay less. It isn’t totally fair, but I can see no other answer coming.
Some years ago we took part at development of a system for online shops to deliver goods from nearest point to customer’s location. Customer could also choose to where to get those goods from when articleA is available in location1, articleB in location2 and location3, articleA and articleB in location3 and so on.
It’s not only a question of costs of delivery. This also has a lot of influence in relation to transport time because this system works worldwide (12 major and synched dbs spread all over the world). Not to mention legal issues like tax, warranty and the like.
Yes I agree, it is complex in many ways. Simpler for me as I am only shipping to US, maybe Canada. I have a programmer writing a plugin now where I can speicify origin zip for each product. Quite reasonbly priced too. I will post here when its done how its working. Isuspect itwill be fine for my needs. He has loads of ecomm experience and has looked over the code and is beginning the project now..
I just made a post about this before finding this one. Roy had told me once before that they will not be developing this idea either.
I don’t quite understand why as I think this is a fairly common concern in the eCommerce world. Not everybody has a huge warehouse where they house everything.
I’d be interested in hearing directly from Varien how the best suggest to handle that sort of situation? Is choosing a zip code in middle america the best option?
DavePit.com – From our experience of building such modules for some of our clients (Pre Magento days) this module is not an easy one to build in a one-size-fits-all kind of method. I see in this thread that there are some attempts at solving this for some cases. We might work on a module like this after the stable release but I cannot guarantee this at this time. My best suggestion using the existing functionality, and one that worked for some our clients, is to setup some kind of table rate (by number of items vs. destination or total order amount vs. destination) that averages the different shipping rates the drop-shippers charge and adjust this to your needs. Setting a zip-code origin on a per-item level might have some performance issues when trying to get real time shipping rates.
DavePit.com – From our experience of building such modules for some of our clients (Pre Magento days) this module is not an easy one to build in a one-size-fits-all kind of method. I see in this thread that there are some attempts at solving this for some cases. We might work on a module like this after the stable release but I cannot guarantee this at this time. My best suggestion using the existing functionality, and one that worked for some our clients, is to setup some kind of table rate (by number of items vs. destination or total order amount vs. destination) that averages the different shipping rates the drop-shippers charge and adjust this to your needs. Setting a zip-code origin on a per-item level might have some performance issues when trying to get real time shipping rates.
Thanks
yoav
Yoav - thanks for the reply. I guess I really need to understand table rates. Based on your explanation, it would still be impossible. Some parts that I sell are 1lb, some are 20lbs and need a huge box. The number of parts or the order total are irrelevant to the shipping price. Some parts cost me $50 to ship while others cost me $5. This has always been the reason I’ve had to use exact quotes...or free shipping for specific products but build their shipping into the price (also had to do with the location they were shipping from).
With this in mind, is table rate shipping still an option?
Yoav - thanks for the reply. I guess I really need to understand table rates. Based on your explanation, it would still be impossible. Some parts that I sell are 1lb, some are 20lbs and need a huge box. The number of parts or the order total are irrelevant to the shipping price. Some parts cost me $50 to ship while others cost me $5. This has always been the reason I’ve had to use exact quotes...or free shipping for specific products but build their shipping into the price (also had to do with the location they were shipping from).
With this in mind, is table rate shipping still an option?
Dave, I agree that this is a complex issue, and as Yoav says, one size fits all can be a bit of challenge. if you are willing to pay a moderate price I have found a ecomm programmer who is modifying it to my needs. I do think customizing it is the only answer, there are too many variables and different situations for different people. PM me and I can hook you up with a fellow who can probably work with you. I think its the only way to get fully what you need. Magento offers so much other great stuff, so I feel its worth any effort needed to make it exactly what you need. Thats the idea of open source anyway I believe.
I think its also customary to donate to the cause and I am certainlyy happy to pay for this package witha donation but have never seen the usual info given, ie if you wish to donate this is how. I don’t expect anything for free and am wondering how does one donate to the cause? Or perhaps when version 1.0 comes out there will be a charge for it? Whichever way, it certainly is worth a good price. People should not work for free!
