Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

USPS Rate V4, Intl Rate V2 (official support thread)


Guest

Recommended Posts

1 minute ago, ArtcoInc said:

@TomB01

1) Which version of Phoenix are you using?

2) I also see an issue with icon_arrow_right.gif not being defined properly.

M

1) 1.0.4.0

2) just sloppy copy/paste - it's not present on the actual site's page

Link to comment
Share on other sites

11 minutes ago, ArtcoInc said:

Are you a member of the Phoenix club?

Yes.

I checked my copies of 1.0.3.0.  and 1.0.4.0.  Both only have 4 files under includes/modules/shipping:

flat.php

item.php

table.php

zones.php

These seem to match up exactly with the options I have under Modules->Shipping.  None of those have anything about entering a zip code, postcode or whatever.  The store address under the Admin Configuration has it, but there is no formatting discipline with that entry and probably has nothing to do with an actual store originating postcode.

Edited by TomB01
Link to comment
Share on other sites

1 minute ago, ArtcoInc said:

@TomB01

I've just downloaded 1.0.4.0 , and I can confirm that Country of Origin and Postal Code are not being defined in the database.

M

Interesting ... I think I was getting mixed up in the former post.  The older version of OsCommerce that runs my live store has it stored under Configuration->Shipping/Packaging, not Modules->Shipping.

I'll continue to search for differences, re: 1.0.3.0 and 1.0.4.0.

Link to comment
Share on other sites

@TomB01

INSERT INTO configuration (configuration_title, configuration_key, configuration_value, configuration_description, configuration_group_id, sort_order, use_function, set_function, date_added) VALUES ('Country of Origin', 'SHIPPING_ORIGIN_COUNTRY', '223', 'Select the country of origin to be used in shipping quotes.', '7', '1', 'tep_get_country_name', 'tep_cfg_pull_down_country_list(', now());


INSERT INTO configuration (configuration_title, configuration_key, configuration_value, configuration_description, configuration_group_id, sort_order, date_added) VALUES ('Postal Code', 'SHIPPING_ORIGIN_ZIP', 'NONE', 'Enter the Postal Code (ZIP) of the Store to be used in shipping quotes.', '7', '2', now());

M

Link to comment
Share on other sites

OK - haven't used SQL for awhile, but the top "INSERT INTO" doesn't need anything, right?  Country of origin is already "United States" when the id = 223.  Correct?

On the 2nd INSERT INTO, I replace 'Enter the Postal Code (ZIP) of the Store to be used in shipping quotes." with my store's zip code numbers, as in 'xxxxx' - correct?

Edited by TomB01
Link to comment
Share on other sites

1) You can use something like phpMyAdmin. Log into the correct database. Copy and paste the two lines above into the SQL box, and run. This will add the two entries into the correct table.

Once the entries have been made, you should be able to use Admin -> Configuration -> Shipping/Packaging to adjust/edit these settings.

2) I have confirmed that these two entries have been dropped from Phoenix 1.0.4.0. Since this USPS module uses the entries, the module now needs to be updated to include the instruction of how to do so! Unfortunately, it seems that the module has not been updated since 2012, nor has the original developer been here since.

M

Link to comment
Share on other sites

2 minutes ago, ArtcoInc said:

1) You can use something like phpMyAdmin. Log into the correct database. Copy and paste the two lines above into the SQL box, and run. This will add the two entries into the correct table.

Once the entries have been made, you should be able to use Admin -> Configuration -> Shipping/Packaging to adjust/edit these settings.

2) I have confirmed that these two entries have been dropped from Phoenix 1.0.4.0. Since this USPS module uses the entries, the module now needs to be updated to include the instruction of how to do so! Unfortunately, it seems that the module has not been updated since 2012, nor has the original developer been here since.

M

1) A bit of miscommunication; I'm familiar with phpMyAdmin, and am prepared to copy and poke.  I was just trying to figure out where to place the actual values in those SQL statements.  I think the country is already defined in your first SQL statement with ID = 223, but was trying to figure out the best place to put the real value of my zip code (5 digits) in the second SQL statement.

2) Kymation has taken it upon himself to support the USPS Rate V4 module for the last several years, thank goodness!  I will be dead as an e-commerce store if I don't have USPS shipping.

Link to comment
Share on other sites

3 minutes ago, ArtcoInc said:

To enter your ZIP code into the SQL statement, replace the 'NONE' with your ZIP code (include the single quotes). Or, like I said, just update it in Admin.

M

SUCCESS!

I didn't realize Inserting into the database would add those lines to the Admin pages.  I copied and entered the SQL, the lines appeared as you said they would, then entered my store's zip code.

Checked my running Phoenix and USPS works!  (Yeah, I have to grab the USPS logo gif, but I can handle that based on the earlier posts.)

Many, many thanks!!  Do we need to tell Gary/Burt to include those database items in later Phoenix fixes?

Link to comment
Share on other sites

17 minutes ago, ArtcoInc said:

@TomB01

No. He was the one that removed them. They are not needed in 'the core'. Add-on's now need to be self-contained.

M

I see.  Well, maybe Kymation will update this USPS add-on when he gets a chance.  Thanks again!

Link to comment
Share on other sites

  • 2 weeks later...

Back to this, now, to resolve bugs that may remain.  I thought this was working well on Phoenix 1.0.4.0, but the Phoenix sample products all weigh too much to test for 1st Class Package service, which is something my customers select all the time on my 2.3.4 store.

So, I created a listing for a single Lemon product in Phoenix with weight of 0.05 lbs (0.8 oz.).  I have a Package Tare weight of 0.125 set up in my Shipping/Packaging Configuration.  So, total weight should be 0.175 lbs, or 2.8 oz.  I'm pretty sure that falls well under the 1st Class Package max threshold.  Unfortunately, I cannot get a 1st Class Package option to appear:

ShoppingCartShippingOptions-12062019.jpg.98f599ce5c0b44ecf21315745138ca03.jpg

The USPS weights are calculated correctly (UPS is not, but that will be an issue in the UPS XML thread), but no 1st Class Package option, even though I have it selected in the Phoenix Admin.  I know in previous times in this thread, there was always an issue with how the US Post Office defined the string for the actual service.  They went back and forth from "Parcel" to "Package" and included new additions to the title such as "Retail" or "TM."  As best I can tell, however, the latest usps.php is using the correct terminology to get the USPS response.  I have a response I can post from the USPS server, if anyone thinks that would help.  In the response, it looks like the USPS server responded to the 1st Class Package Service with a rate of $3.74.  Any ideas why this isn't showing up in the checkout?

Thanks for your support!

Just to be certain, here are the settings in Admin:

Shipping Methods (Domestic and International)
0, 70, 0.00, 0, 70, 0.00, First-Class MailRM Parcel, 0, 70, 0.75, First-ClassTM Package Service, 0, 70, 0.75, 0, 70, 0.00, 0, 70, 0.00, 0, 70, 0.00, Priority MailTM, 0, 70, 1.00, 0, 70, 0.00, 0, 70, 0.00, 0, 70, 0.00, 0, 70, 0.00, 0, 70, 0.00, 0, 70, 0.00, 0, 70, 0.00, 0, 70, 0.00, Priority Mail ExpressTM, 0, 70, 1.5, 0, 70, 0.00, 0, 70, 0.00, 0, 70, 0.00, 0, 70, 0.00, First-Class Package International ServiceTM, 0, 70, 1.00, Priority Mail InternationalRM, 0, 70, 2.00, 0, 70, 0.00, 0, 70, 0.00, 0, 70, 0.00, 0, 70, 0.00, Priority Mail Express InternationalTM, 0, 70, 2.00, 0, 70, 0.00, 0, 70, 0.00, 0, 70, 0.00

Edited by TomB01
Link to comment
Share on other sites

@ArtcoInc

Thanks for the suggestion.  However, the latest download (V2_r1.8) has that line, including the comma.

It does remind me that there's something about unloading and re-loading the usps module before you will see a change.  So, I'll continue work on it and see if that will help.

It appears that the usps server is replying to the usps.php request, it's just not picking up in the checkout process in Phoenix, at least as much as I can decipher from the debug e-mail I got containing the below:

<Package ID="1"><ZipOrigination>XXXXX</ZipOrigination><ZipDestination>38053</ZipDestination><Pounds>0</Pounds><Ounces>2.8</Ounces><FirstClassMailType>PACKAGE SERVICE RETAIL</FirstClassMailType><Machinable>FALSE</Machinable><Zone>4</Zone><Postage CLASSID="0"><MailService>First-Class Package Service - Retail&amp;lt;sup&amp;gt;&amp;#8482;&amp;lt;/sup&amp;gt;</MailService><Rate>3.74</Rate><SpecialServices><SpecialService><ServiceID>119</ServiceID>  ... lots more after this ...

I made a call to 1st Class Parcel, as well.  That reply was Package ID="0".  The Priority Mail and Priority Mail Express are ID="2" and ID="3" in my debug e-mail.

Edited by TomB01
Link to comment
Share on other sites

Fixed it!

For those interested, refer to the USPS doc for Price Calculator APIs: https://www.usps.com/business/web-tools-apis/rate-calculator-api.pdf .  Apparently, the USPS has stopped using the word "Parcel" anywhere in their APIs.

In includes/modules/shipping/usps.php, find near line 300:

$first_class_type = '<FirstClassMailType>PARCEL</FirstClassMailType>';

Change that to:

$first_class_type = '<FirstClassMailType>PACKAGE SERVICE RETAIL</FirstClassMailType>';

Near line 429, fine this sequence of code and comment it out (or I guess you could delete it):

          // First Class service hack, because USPS isn't returning what they say they do.
          // Remove this block if they ever get their act together.
          if( $service == 'First-Class Mail' ) {
            $first_class_type = $response_array['Package'][$index]['FirstClassMailType'];
            switch( $first_class_type ) {
              case 'LETTER' :
                $service .= 'RM Stamped Letter';
                break;

              case 'FLAT' :
                $service .= 'RM Large Envelope';
                break;
                
              case 'PARCEL' :
                $service .= 'Parcel';
                break;
                
              default :
                break;
            }
          }
          // End hack

Starting near line 462, replace every reference of "TABLE_CONFIGURATION" with "configuration" (minus my quotes).  Note that outside of the big group of references starting about line 462, there are two additional instances near line 499 and 504.

Near line 523, find the list of USPS service types and replace line 530:

\'First-ClassTM Package Service\',

with this:

\'First-Class Package Service - RetailTM\',

Unfortunately, their are other references in that list to "Parcel," but I didn't need those services, so confess that I didn't mess with them.  Your mileage may vary.  Those service types get poked into the database, so unless you manually edit the values in the database, you'll need to un-install the USPS module and re-install it to make this work.  Also, just to be clear - this is the "USPS Rate V4 Intl Rate V2_r1.8" usps.php file.

 

P.S. This can be found elsewhere, but it works for me with USPS, FedEx Web Services, and UPS XML: find the gif you need to show up for your shipper and save it in catalog/images/icons.  In this USPS module's usps.php file, find line 32 and change this:

$this->icon = DIR_WS_ICONS . 'shipping_usps.gif';

to this:

$this->icon = '/catalog/images/icons/' . 'shipping_usps.gif';

Thanks!

 

Link to comment
Share on other sites

6 hours ago, TomB01 said:

Starting near line 462, replace every reference of "TABLE_CONFIGURATION" with "configuration" (minus my quotes).  Note that outside of the big group of references starting about line 462, there are two additional instances near line 499 and 504.

I wouldn't say it that way.  What should be replaced is

" . TABLE_CONFIGURATION . "

and it gets replaced with

configuration

So that the string looks like

insert into configuration (

It will sort of work if you replace TABLE_CONFIGURATION with configuration, but it will generate a notice that may appear in the logs.  And of course if anyone ever made a constant named configuration, it would break. 

Normally, I'd recommend replacing

 $this->icon = DIR_WS_ICONS . 'shipping_usps.gif';

with

$this->icon = DIR_WS_CATALOG . 'images/icons/shipping_usps.gif'; 

Because that will work regardless of where the catalog directory is located. 

If you use the <> tool to insert code in the forums, it will be easier to tell it from the surrounding text. 

Always back up before making changes.

Link to comment
Share on other sites

11 hours ago, ecartz said:

<snip>

Normally, I'd recommend replacing


 $this->icon = DIR_WS_ICONS . 'shipping_usps.gif';

with


$this->icon = DIR_WS_CATALOG . 'images/icons/shipping_usps.gif'; 

Because that will work regardless of where the catalog directory is located. 

If you use the <> tool to insert code in the forums, it will be easier to tell it from the surrounding text. 

</snip>

Thanks - corrections made!

I'm curious, though, what's the strategy behind keeping some of the "DIR_WS_" and "DIR_FS_" path variables, but not others?  I was told in another thread that Burt got rid of them all, but was surprised to find a few left in the configure.php file, anyway - including this one.  If some are still there now, might they be gone in future revisions?

Link to comment
Share on other sites

The ones that remain are the ones that change from store to store.  For example, your catalog directory might be in the root at / or at /catalog/ or at something like /shop/.  Each store can choose to do something different.  Meanwhile, images/icons/ is always images/icons/ -- there is very little reason to ever change it.  Even if you did want to change it in the URL, you could use something like mod_rewrite so that the directory structure would stay the same. 

In general, most of the constant ones have gone, leaving only the few variable choices.  I find it rather unlikely that we'd take out more of the DIR_WS values (except possibly DIR_WS_HTTPS_CATALOG).  More likely to go would be HTTPS values and USE_PCONNECT.  USE_PCONNECT because mysqli does that in the DB_SERVER.  The HTTPS values because very few stores used mixed HTTP and HTTPS today.  So why support something that no one uses? 

The two DIR_FS_DOWNLOAD values may go.  And STORE_SESSIONS. 

The following are pretty safe, although the HTTP ones might get renamed (or not): 

  define('HTTP_SERVER', ''); // eg, http://localhost - should not be empty for productive servers
  define('HTTP_COOKIE_DOMAIN', '');
  define('HTTP_COOKIE_PATH', '');

  define('DIR_FS_CATALOG', dirname($_SERVER['SCRIPT_FILENAME']) . '/');

// define our database connection
  define('DB_SERVER', ''); // eg, localhost - should not be empty for productive servers
  define('DB_SERVER_USERNAME', '');
  define('DB_SERVER_PASSWORD', '');
  define('DB_DATABASE', 'osCommerce');

DIR_WS_CATALOG is defined elsewhere, but also pretty safe. 

Edited by ecartz

Always back up before making changes.

Link to comment
Share on other sites

You may be better to use the actual path in this one (full physical path to your catalog directory)

 define('DIR_FS_CATALOG', dirname($_SERVER['SCRIPT_FILENAME']) . '/');

as this format only works in catalog pages and can break some callbacks (mostly payment or shipping modules) in the ext directory - or at least be aware of it as something to check when trying to work out why a callback isn't working. The whole point in having this setting is that it isn't necessarily the path to the running script.

Contact me for work on updating existing stores - whether to Phoenix or the new osC when it's released.

Looking for a payment or shipping module? Maybe I've already done it.

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Link to comment
Share on other sites

  • 4 weeks later...
Link to comment
Share on other sites

5 hours ago, dculley said:

Moving my plate form to Phoenix 1.0.4.1

I have this app running on my current OSC w/BS

Was wondering if it work with Phoenix?

Thanks

Dean

I have it working on Phoenix. 1.0.4.0.  You need to modify the usps.php file so that the SQL strings reference the tables directly, as in "delete from configuration where configuration_key …" etc. (around line 500 e.g.) and elsewhere (a bunch of lines around 462 through 478).  Here's a file that I ended up with:

usps.php

There is also a section of code needed that kymation and greasemonkey developed that needs to go into the admin/modules.php file, unfortunately (Phoenix core file).  That's attached here and the section is commented in the file:

 modules.php

Finally, the 1st Class Parcel service in the USPS webserver documentation is wrong.  The $services_list in the usps.php file should use the following for 1st Class Parcel:

'First-Class Package Service - RetailTM\' (around line 531 in the usps.php file).

I use Package service for domestic and international, 1st Class, Priority, and Priority Express.  Please note that I haven't tested things for anything else.

Edited by TomB01
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...