*** REPLY moved from one of the other threads ***
I thoroughly looked through your code and indeed I see all the references to adding handling fees.. however I am still not seeing it.. My client is running osCmax v2.5 (I stated wrong in a few places it as osC v2.5)
I just un-installed the USPS Methods v5.2 and uploaded/installed your USPS Methods v5.3.
All quotes seem to be proper, including handling fees, domestic & International
EXCEPT First Class is still not adding any handling fees on the domestic. It did add it on international:
First-Class Mail International Large Envelope**
First-Class Package International Service**
Yep - worse than before. I'll take some time today and see if I can install 5.2.2 from scratch and go from there. Hopefully, it will resolve the database, too - because now I've got semi-duplicate fields for many of the same services/options under USPS.
The current USPS shipping modules (USPS Methods, USPS Rate V4, Intl Rate V2, stock osCommerce 2.3x) all have a major problem -- they depend on the Service names that USPS supplies. Since USPS seems determined to change these names every six months or so, these modules break and must be patched twice a year. This should not happen, and it doesn't need to.
The quotes that USPS returns are keyed to a Service ID (called CLASSID.) These are (mostly*) unique numbers that never change, or only change when a service is deleted or added. These numbers are a much better way to select the service(s) desired, as the module will not break when USPS changes the service names.
If this system had been in use before the July changes, the only difference that anyone would have noticed would have been different service names showing up on the checkout page. No broken checkout, no thrashing to get a fix implemented, no lost sales.
I've done some preliminary testing, and I have a plan to fix this. I intend to use some of the code from the USPS Rate V4, Intl Rate V2 module since I like the way it is set up in the Admin. The rest of the code will be rewritten.
I have in mind an adaptive model that will require an extra step in the install process. The first edit of the module upon install will require a valid USPS Web Tools username. That will be used to send a dummy quote request to the USPS server for all available services, domestic and international. The response to that will be stored and presented in the second step as a list of services that may be selected. The selected values will then be stored in that step.
The installer will allow the selection of services by their current names. The names in the Admin will not change if USPS changes their API since those values are stored in the database. However, we are only comparing against the CLASSID, so the store side will continue to work and show the updated names.
Updating the names on the Admin side can be done by uninstalling/reinstalling the module, but that will normally not be necessary. You will only need to do that if USPS has added a new service that you want to offer to your customers or they have removed a service that you were offering. Doing an uninstall and reinstall is a lot simpler than modifying the code to make it work again.
*Yes, there's one problem with this approach -- the CLASSID for all First Class services is 0. That will have to be treated as a special case. That makes First Class more fragile, but USPS doesn't seem to change those services very often, so it's not likely to be a huge problem.
Any and all help with this is very welcome. I can use help with the code, of course, but feature suggestions and testing help are appreciated as well. Let's see what we can do with this.
The main problem that everyone is having with this is that both addons are trying to key on the service name that USPS returns. Since USPS seems determined to change those names every six months, this is a really bad idea. I think we should be using the CLASSID for each service as those numbers never (or rarely) change. I'm working on a proof-of-concept of an adaptive module that would never need these twice-yearly changes. I suppose I should start a development thread, as this is looking really good.