Off Topic - but since brig brought it up. We have accounts with all of the major shippers, and UPS is by far the most expensive and least "user friendly" for a small business. Fedex is good, but DHL was easily the best and it's unfortunate they had to terminate their domestic shipping service in the US. DHL ground packages shipped coast to coast one day faster than the others, packages were accepted 2 hours later in the day, and even small nobody companies like ours got our own account rep who would deal personally with any problems or requests. All this and they were also the lowest cost shipper.

Back On Topic - I had requested and received a copy the DHL shipping API documentation with the intention of writing a module, but due to cirmstances mentioned above it never got off the ground. While toying with the idea, it occurred to me that perhaps something along the lines of the DBI/DBD modules would make sense here.

Rather than various people writing complete shipping systems from scratch, perhaps we need a standard Perl API for shipping, and a universal interface to a set backend modules that can be written for each shipper. If anyone wants to work on this idea I'll be happy to participate.

ShipAPI
ShipAPI::DHL
ShipAPI::Fedex
ShipAPI::UPS
ShipAPI::USPS
...etc
[download]

I like your idea of ShipAPI::*.

This is the kind of hard work that should only really be done (well) once.

I agree wholeheartedly. Who wants to organize it? I'd love to help.




I'm a Linux user. You wouldn't know it since I mostly ask Windows questions. Whee.

If you want to do evil, science provides the most powerful weapons to do evil; but equally, if you want to do good, science puts into your hands the most powerful tools to do so.

- Richard Dawkins

My gosh, that's a great idea!!! I have tried to implement those many unfinished UPS shipping PERL Mods on CPAN into my shipping system. I ran into the same issues as the previous poster's and some of the Mods have too many dependencies. It's time to build a ShipAPI. It's not a crazy idea. How can I contribute?

My 2 cents...

I dont know if the modules work better but I can assure you that FedEx is far superior to UPS.

I get lots of crushed boxes at my job, all of them come through UPS. I don't think they actually care about anything they do -> that is why the documentation is so awful. I have never had to return anything because FedEx or USPS destroyed it, but I have had to return 2 items that UPS smashed flat(and delivered with no comment).

From my experience in the past, CPAN has a lot of modules that started off strong but never followed through on a correct and polished library of code -> plus everything in the entire world seems to change on a monthly basis rendering the development of stable code a near impossibility in any case.

For my money I would say: Jump in with WebService:UPS and help implement the functionality you need.

The UPS webservice is a lot easier to deal with than FedEx is. Or at least that was the case when I wrote the fancy webstore and order fulfillment system for Taylor Shellfish half a decade ago. With UPS, you can get all varieties of rates and availability for a set of boxes in one request. FedEx required one separate request for each different service, from what I kinda remember. I hope they fixed it since then. (BTW: Taylor Shellfish changed to a different web design company that replaced their fancy webstore that we made with some cookie cutter junk. What they have online now wasn't my doing.)

I have some very nice code that does all kinds of UPS stuff that I should have made into a proper module (tests, etc) long ago. I don't even know if I can find that code anymore. If I do, I'll see about releasing something on the CPAN. I'm not sure releasing a separate module would be better than enhancing the modules already on the CPAN though.




I'm a Linux user. You wouldn't know it since I mostly ask Windows questions. Whee.

If you want to do evil, science provides the most powerful weapons to do evil; but equally, if you want to do good, science puts into your hands the most powerful tools to do so.

- Richard Dawkins

FedEx may offer better service, but the last time I checked they want blood samples and your first-born before they will give you any webservice access.

From the look of things, it would appear that I will go ahead and create Yet Another UPS Module for CPAN. Since the UPS API appears to be relatively stable - albeit lame - it should function just fine for the foreseeable future.

Sorry about the slow response, but I got curious and googled my name on the Internet, to find this.

I would be Justin Wheeler, the author of Business::UPS (only sort of, I only hacked on it and re-released it, it was originally someone else's code).

I wrote it many many moons ago (I think I was 16 or 17 years old) and it was very ugly, screen scraping code. Someone came out with something better, and my module fell by the wayside. I had plans for updating it, but since I've been screwed far too many times by UPS, I don't feel the need to help anyone else give them their money. UPS is a horrible, horrible company, and I have no intentions of doing anything else with it. If anyone else wants to take over maintainership of it and/or steal the namespace, you have my blessing.

(And my e-mails to cpan@ only bounced for a short while when that particular e-mail address started getting spammed at a rate of ~500 a day. The bounce was removed months ago.)

When I was developing for UPS, it was so very easy. They have full PDF docs that are really helpful. If you need tech support on it, you might want to re-read the docs. The one time I needed help, it was easy to get. This was about or at least 5 years ago, so it may have changed since then. I hope not, though. My UPS experience was much more easy-going than FedEx and Airborne Express (before the DHL takeover).




I'm a Linux user. You wouldn't know it since I mostly ask Windows questions. Whee.

If you want to do evil, science provides the most powerful weapons to do evil; but equally, if you want to do good, science puts into your hands the most powerful tools to do so.

- Richard Dawkins