hostricity

I'm having two problems on a OSC 2.2 website which has OSC_Affiliate installed. It appears to be working from a user / admin standpoint, I'm having three issues 1. I ran a couple of test sales using an affiliate link. I can see the click-throughs in the affiliate admin area, but the sales are not reqistering. as affiliate sales. The system is set to not pay for a 30 day refund period, but I've looked in the database and I can find nowhere that the sales are stored so that when the 30 day refund waitning period is over, they'll be eligible for affiliate payment.. Does anyone know how that waiting period for refunds works and where I would see the sales that have been made, but aren't eligible for payout because they haven't yet passed the 30 day refund period? 2. Does anyone know how I can tell which version of the OSC Affiliate addon I have installed. There aren't any headers that state which version that I can identify. 3. Is anyone actually supporting this addon? Thanks.

I updated to the current version and that fixed the problem. Thank you. Now, I have a question for you: We are signed up with the Post Office to receive email notifications when they make changes to their API, etc. - BUT we NEVER get those emails, so we're left scrambling when something breaks. Worse yet, this only affected small overseas orders, so we didn't even know there was a problem until a customer complained about the shipping (UPS to Greece is very expensive.) Does anyone else have problems getting the updates from the Post Office? What do you do to keep up with it? Is there a webpage at USPS.com we can monitor? I only have one customer left on OSCommerce and this i\really is driving us nuts. (The other shopping carts we use have automated module updates, so when we see a shipping module update, we make sure that gets applied immediately.)

I found the problem, but not the solution... It has nothing to do with Greece. We ship everything priority mail. When a larger box is required for the shipment, it returns the correct pricing. When a small flat rate box is required, it returns the correct pricing from the USPS server, BUT!!! Then, OSCommerce is not recognizing it and displaying it. It works correctly for domestic, but not for international. So, it appears that there's been a service name change or something for international priority mail flat rate small boxes. I'm not sure exactly how the mechanism works. It appears that the USPS returns all options and then OSCommerce filters what to display based on the settings for the module in the OSCommerce control panel. Has there been an update recently to service names or something that would break this? It was working and now it's not.

We can ship anywhere in the world by USPS, except for Greece. Here's what's in the countries table: 84 Greece GR GRC 1 A couple of questions: 1. Is there an official list somewhere that I can use to validate this entry? 2. Is there a way to validate the entire country table or is there an updated table to replace the one I have? 3. Absent the above, do you see anything wrong with the entry for Greece listed above? Thanks for all your help.

I just tested Express mail small box domestic and international. The test server did not reflect the 10 cent increase in the small flat rate express mail box.

We use this module. I'm looking at the USPS update which is coming on January 25th, 2014. The details can be found here: https://www.usps.com/business/web-tools-apis/welcome.htm (Look in the middle of the page for the release notes link) In reviewing this, I think the following pertains, and I would like a confirmation from others that I am correct: 1, It appears that this update does not affect this module unless you want to take advantage of the new services, which will likely require some coding to support. The module uses the V4 and International API's, both of which are being updated, so that is what I evaluated. 2. The price updates should be completely transparent and simply passed through as appropriate. 3. I do have a concern about this statement in Section 2.2.2 of the document pertaining to the V4 API: " Standard Post availability to zones 1-4 eliminated with exception given to mailings with hazardous materials, live animals or other ground only items" I'm not sure whether elimination of these zones will have an impact on what is sent to the V4 api, or how the response is handled. This sounds like an area where there could be a problem. 4. We need to test this very carefully both on the test server and the day it goes live because the post office has a habit of breaking things and inserting new garbage into api responses that break shipping modules. I will be testing and I will post any problems I find. I hope that others will do the same. IF WE'RE VERY LUCKY, we may be able to handle this update without any major downtime.

VERY IMPORTANT. I found the problem I described above. The module comes hard coded with dimensions that exceed the dimensions of a small priority mail box. Before the most recent USPS update (which required the December 14th update to this module), the API ignored the dimensions and returned the small priority mail box for box domestic and international pricing. After the USPS update, the API ignores the dimensions and returns the small priority mail box for domestic pricing, but on international pricing, the API uses the dimensions and will not return the small priority mail box. SO, for the module to work correctly, with the dimensions in the API call in usps.php must be small enough to fit in a small box, or you will not get pricing for a small international box.

Is anyone else having a problem with this module not returning the Small Priority International Flat Rate Box? I also noticed, that even with the "International Regulations" set to NO, the regs are still retrieved via the API call. The regs are not displayed, so the only problem is the additional bandwidth used on each query. We installed USPS Methods Rates V4 Intl Rates V2 - R3.1 (December 14th release) because the older version went down, I assume due to changes made by the Postal Service. This fixed the problems for Domestic (US) and appeared to fix the problem for International (Shipping internationally from the US.) What we subsequently discovered is that for international orders, the international small priority mail box is not offered to our customers when it should be. Shipping domestically, to destinations within the US offers the small priority mail box correctly. We found this workaround: we are using the Priority Mail unpadded International envelope instead of the small box. It appears that the price is the same for both the box and the envelope, so it does price the shipping correctly. (This only works because we have "rigged" the weights and measurements of products in our catalog so that when the shipment will not fit in a small flat rate box, it switches to priority mail with our own packaging.) I'm looking for some clues as to why the Small Priority International Flat Rate Box is not being displayed when it should be. Thanks.

On the weight limits: We use them to limit the options the customer has from which to select. For example, we set a minimum and maximum weights so that the customer will not see more than one flat rate packaging choice. (With this customer's products, the weight serves as a good substitute for physical size of the products.) We use max weight on small flat rate box of 1.5lbs. Minimum weight on larger flat rate box is 1.6lbs. So, even though the flat-rate boxes are supposed to ship anything that will fit in them, we force a larger flat-rate box when the customer has ordered enough items that they won't fit in a small flat rate box. If it's over 1.5 pounds, it goes in the larger box. (If the total shipment is over 1.5 pounds, we know that they ordered enough items that they won't fit in the small box!)

Since you've done a comprehensive review of the various USPS modules, would you please render your opinion on my post #766 above? I'd really like to get this cleaned up before the USPS makes another change in the hope that further USPS changes won't break the module.

I had a similar problem last year and had to add some code to filter out the html garbage. Sorry, I don't have it to give it to you, but I think there are some posts here with samples of that filtering code.

Thank you, @@kymation and @@wkdwich. Since we don't use first class postage, everything is now great and working. Jim, I think you are correct that the USPS has multiple servers that have not all been updated the same way. NOW: My client is going to be on OSC 2.2 RC2 for at least another year. So, I want to do something to prevent this from happening again. I think the problem with this module breaking is that it is using the service name text strings (which change) instead of a permanent key. I think this because our Prestshop stores don't crash when the USPS makes there changes. (I haven't looked at the API). BEFORE I DIG INTO THIS FURTHER, I AM SOLICITING INFO FROM THOSE WHO MAY HAVE GONE HERE BEFORE!! 1. Am I correct that this module is breaking because it is using a text field instead of the proper database row key field? 2. Is this the module to focus on, or is there another USPS module which doesn't have these problems, or would be a better starting point for a fix? I will say that when I set this module up in early 2012, I replaced whatever we had before and switched to this one because I couldn't get the updated version of what we had to work (or maybe there wasn't one available yet). My impression is that this module is relatively simple, provides the features we need and would be easier to upgrade than to switch to another module --- but that is just a guess.

First, kymation, thank you for your leadership role in this thread. Thanks to everyone else here, as well. A summary of the actual changes required to upgrade this contribution would be greatly appreciated. Maybe summarizing my status will help clarify for some others... Here's where I think I am: OSC 2.2 RC 2. I have this USPS Module installed: USPS Rates ServerV4 (for osc2.2) / http://addons.oscommerce.com/info/8403 Now, it appears that there's an update I hadn't applied: USPS Methods Rates V4 Intl Rates V2 - 01-27-13 Update / http://addons.oscommerce.com/info/8702 So, I applied this update. At this point, I should now be ready to make the updates contained in this thread to fix the July 28th USPS changes. IS THAT CORRECT? So, now, here's my problem: I've been reading through this thread and there changes on top of changes to update for USPS and then a few more changes to correct side issues, but I'm having a terrible time trying to figure out exactly which changes I should apply. WOULD YOU OR SOMEONE ELSE HERE BE SO KIND AS TO SUMMARIZE THE STATUS AND PROVIDE THE LATEST SET OF FILES AND HACKS REQUIRED TO GET THIS CONTRIBUTION GOING? I am a programmer and am happy to help with furthering this effort to a clean update, but I need to see the actual status, install the changes, and do some testing before I can provide any useful assistance. OK, I SEE THE FILE KYMATION POSTED AT #748. Is this the best version of usps.php, if I don't care about restricting by products? AM I CORRECT THAT NO VERSION WORKS FOR FIRST CLASS MAIL? ARE THERE ANY OTHER FILES IN ADDITION TO usps.php which I need to update?

OOPs - I typed the domain name incorrectly in my post about Priority Mail International Small Flat Rate Box: https://www.xeonixinc.com/ (I know, there's a configuration error that makes it not work without www. I'm taking care of it!

Your module installed beautifully with no problems. Thank You! Now, I do have a couple of questions: 1. Priority Mail International Flat Rate SMALL BOX does not display. It works fine with Domestic Priority Mail Flat Rate small box. I also tested to verify it is not dependent on country to make sure it wasn't a problem with a particular country. It may have displayed and stopped working when I switched between Retail and Online. Are there any configuration fields in the database that may have gotten screwed up or corrupted by changing between Retail and Online and back? I also played with product dimensions and weights, but that has no effect. I did uninstall usps.php and redid the configuration, but that did not help. - Which is why I am wondering about configuration fields in the database. NOTE: The module installed WITHOUT any changes, so it isn't a typo in the module itself unless it's in the distribution. 2. Is there any provision in this module for handling product / shipping dimensions? If not, any clever ways to handle them? 3. It appears that the estimated delivery time is returned and I just need to modify my site to display the time estimate. Is that correct? 4. If you want to place a test order to see what I am talking about, feel free to do so. You will see the problem before you are asked to pay. https://xeonixinc.com Thanks in advance for any guidance you might offer.