Kryptronic Software Support Forum

You are viewing this forum as a guest. Login to an existing account, or create a new account, to reply to topics and to create new topics.

#1 02-05-2016 18:25:59

ThomasGiannou
Member
Registered: 02-10-2007
Posts: 184

USPS problem with real time services window.

I'm finding the USPS medium sized flat rate box is not appearing in the shipping options under certain circumstances.   The reason  is (I think), only
"USPS-US-Priority Mail 2-Day Medium Flat Rate Box" is in the realtime services table.   1-day and 3-day are not in that table.   The post office returns a 1-Day or a 3-Day Medium Flat Rate Box as a description, but there is nothing in the Realtime Services table to match it so the option doesn't get displayed in the checkout.   Then, to add insult to injury, the realtime services table only has an UPDATE function, there's no way to ADD new table entries.   The priority mail option doesn't have this problem because it has 1, 2, and 3 day entries in the realtime services table.  How are we supposed to update the realtime services table so those 1 and 2 day options are present for Priority Mail Medium Flat Rate Boxes???   

Also, could we just make entries in the realtime services table to pick up the Priority Mail Regional Box A and the Priority Mail Regional Box B shipping options that are available through the domestic USPS??

Offline

 

#2 02-05-2016 19:51:31

webmaster
Administrator
From: York, PA
Registered: 04-20-2001
Posts: 19798
Website

Re: USPS problem with real time services window.

The software is designed so that USPS pulls services from that table.  You can add entries in admin under System > Database > Raw DB Admin.  Choose to browse the ecom_shiprealtimep table and add entries as needed.  Please share here what you add and I'll make sure those options make it into the base software.  Thank you.


Nick Hendler

Offline

 

#3 02-06-2016 01:55:56

ThomasGiannou
Member
Registered: 02-10-2007
Posts: 184

Re: USPS problem with real time services window.

I tried putting in a table entry to show the 1 and 3 day options, but it didn't make any difference.  So, I changed the size of the h-l-w on the product from 10-7-4 to 4-4-4 and the medium and large flat rate boxes showed up on the shopping cart shipper selection list.   I also had to add the 1 and 3-day shipping times to the ECOM-SHIPREALTIMEP table.   The only domestic priority mail flat rate shipping options that were in the ECOM-SHIPREALTIMEP table were the 2-day versions.   When USPS api returns 1-day or 3-day, no medium or large flat rate boxes were being displayed.   The inside dimensions of a medium flat rate box are
11 x 8.5 x 5.5  yet it would not take my 10 x 7 x 4 product.   When I changed the dimensions of the product to 4 x 4 x 4 and put the two table entries for the 3-day medium and large flat rate boxes into the table, the shopping cart picked up the medium and large flat rate boxes.   There appears to be a mismatch between the l-w-h in the product table and the USPS system, otherwise the 10-7-4 product definition should have worked.   The l-w-h defined on the product has to match the l-w-h on the USPS flat rate box or the api won't return that box.   By going to 4-4-4, I got away from the mismatch problem.   If the three dimensions l-w-h on the product are not matching up with the three dimensions of the USPS, then those flat rate boxes won't be returned by the api.   For example, if the API is expecting w-h-l and the cart is sending l-w-h from the product table dimensions 10 x 7 x 4 won't match up with the USPS dimension definitions.   That's why 4 x 4 x 4 worked, all three of those dimensions are under the USPS dimensions no matter what order the USPS dimensions are in the api programming.   

So, there are two problems going on in this situation.  The 1-day and 3-day entries are missing from the ECOM_SHIPREALTIMEP table and the hand shake regarding product dimensions in the cart and product dimensions in the USPS api program is not matched up properly.  So, to get this to work, I have to hokey up the product dimensions so there's no handshake mismatch and I have to make two entries for the medium flat rate boxes and the large flat rate boxes (1-day and 3-day) into the ECOM_SHIPREALTIMEP table.   I will also have to do the same for the 1-day and 3-day flat rate envelopes and legal sized envelopes.

If I can figure out what the USPS name keys are for the Priority Regional Box A and Regional Box B, I should be able to enter the 1-day, 2-day, and 3-day entries for those USPS boxes into the ECOM_SHIPREALTIMEP table and have them show up in the shipping selection list on the shopping cart checkout display. 

I can move the 10 x 7 x 4 product dimensions around and probably figure out how the shopping cart program is not doing the dimension match up with what the API is expecting.   I changed the dimensions to 7 x 10 x 4 and that matches up with the API expectations and the medium and large flat rate boxes appeared.   This is going to require a code change in the shopping cart program so Length and Width and Height in the product table actually matches with the USPS API Length and Width and Height expectations.   

If that all works, this multi-year nagging USPS failure just might get straightened out and I can stop swearing at this blanket-blank shopping cart for not working with USPS domestic mail.

Offline

 

#4 02-10-2016 21:52:39

ThomasGiannou
Member
Registered: 02-10-2007
Posts: 184

Re: USPS problem with real time services window.

What is the name of the cart program that submits data to the USPS api?   I need to change the code so the product dimensions match up correctly with the USPS dimensions.

Offline

 

#5 02-11-2016 06:49:04

webmaster
Administrator
From: York, PA
Registered: 04-20-2001
Posts: 19798
Website

Re: USPS problem with real time services window.

All logic is in {private}/apps/ecom/ECOM_Ship/ext/usps.php.  The $packages, or boxes, are built already and used to rate boxes individually.

For example, if the API is expecting w-h-l and the cart is sending l-w-h from the product table dimensions

Please confirm this is the case.  If this is the case, simply flipping the dimensions around before being sent to USPS will work.

Know that the Kryptronic software builds each $package with the length being the longest dimension, the width being the next longest dimension, and the height being the shortest dimension.  It does not matter how you enter them on the backend, it will build the package in this format as it stacks and packs items into bigger and bigger boxes.

Exception: In the case where you have items set to ship in their own box, and you enter the dimensions in the same format the software uses (length being the longest dimension, the width being the next longest dimension, and the height being the shortest dimension) then the $package rated will match your entry for the product.

I recommend highly against hardcoding box sizes.  Try flipping the dimensions in the API call to the order USPS is looking for, if that means sending length as width, width as height and height as length.  Or, perhaps you've entered the longest side as the width on the data side and that's caused your issue?


Nick Hendler

Offline

 

#6 02-11-2016 09:26:19

ThomasGiannou
Member
Registered: 02-10-2007
Posts: 184

Re: USPS problem with real time services window.

Nick I had a dimension set up as 10 x 7 x 4 in the three dimension fields in the product table as Length x Width x Height and none of the flat rate boxes of USPS showed up in the selection list.   When I changed the sequence to 7 x 10 x 4 in the product definition, the flat rate boxes showed up in the selection list on the cart checkout display.   The sequence of the product display is L x W x H.   This means what is being presented to the USPS API is out of sequence with those definitions in the product table.   The product table is in the sequence L x W x H but I had to enter the physical dimensions as W x L x H in the product table in order for the USPS API to return the flat rate boxes.   The code in the program is not correct for passing the product dimensions to the USPS API.   This problem has been verified by my having to switch the actual product dimensions around in the Product Dimensions section of the cart Product table.   There is a bug in the program code that needs to be fixed.

Offline

 

Board footer