UPS XML: Support Thread

mrsawyer:

I will try your suggestion about using debug. However, UPS's response mentions package size as a determining factor in the rate estimate received online. How does the UPS_XML plugin supply UPS with package dimensions, or does it? I did not see anywhere where package size could be entered. In the ZC admin area I saw small box and large box, but did not a place to specify the dimensions of either.

Please advise,
mrsawyer

I would like to add that I just took a quick look at the debug log which I had already enabled, but had not look at. From what I'm seeing, the plugin is passing length, width, and height of all zero inches to the UPS interface. Is there a way to pass an actual box size?

mrsawyer:

I will try your suggestion about using debug. However, UPS's response mentions package size as a determining factor in the rate estimate received online. How does the UPS_XML plugin supply UPS with package dimensions, or does it? I did not see anywhere where package size could be entered. In the ZC admin area I saw small box and large box, but did not a place to specify the dimensions of either.

Please advise,
mrsawyer

mrsawyer:

I would like to add that I just took a quick look at the debug log which I had already enabled, but had not look at. From what I'm seeing, the plugin is passing length, width, and height of all zero inches to the UPS interface. Is there a way to pass an actual box size?
The shipping method, as inherited, *claims *to support product dimensions but I have neither updated nor tested that processing. While there's a DIMENSIONS_SUPPORTED constant that can be changed (as you apparently have) in the shipping-module itself, that's not a processing-path that I'm prepared to support at the current time.

lat9:

The shipping method, as inherited, *claims *to support product dimensions but I have neither updated nor tested that processing. While there's a DIMENSIONS_SUPPORTED constant that can be changed (as you apparently have) in the shipping-module itself, that's not a processing-path that I'm prepared to support at the current time.

I had not discovered the DIMENSIONS_SUPPORTED constant. However, after you mentioned it, I found it in the UPSXML.php file in the Modules folder (as opposed the UPSXML.php in the language folder). I changed the constant to 1, but saw no affect on the rate options. I see that you are not prepared to support it, but do you know what it is "supposed" to do? You got my curiosity up by mentioning it. :blink:

Our Dimensions_Supported constant is set at 0.

Here is part of the debug log that shows UPS is automatically receiving 10lbs as the package weight and $100 as the package value (unless I have misinterpreted). Our test shipment was 3.1lbs, so is this weight and value hard-coded somewhere?
<TransitFrom>
<AddressArtifactFormat>
<PoliticalDivision2>Bronx</PoliticalDivision2>
<PoliticalDivision1>NY</PoliticalDivision1>
<CountryCode>US</CountryCode>
<PostcodePrimaryLow>10472</PostcodePrimaryLow>
</AddressArtifactFormat>
</TransitFrom>
<TransitTo>
<AddressArtifactFormat>
<PoliticalDivision2>Beverly Hills</PoliticalDivision2>
<PoliticalDivision1>CA</PoliticalDivision1>
<CountryCode>US</CountryCode>
<PostcodePrimaryLow>90210</PostcodePrimaryLow>
<PostcodePrimaryHigh>90210</PostcodePrimaryHigh>
</AddressArtifactFormat>
</TransitTo>
<PickupDate>20200715</PickupDate>
<ShipmentWeight>
<UnitOfMeasurement>
<Code>LBS</Code>
</UnitOfMeasurement>
** <Weight>10</Weight>
</ShipmentWeight>
<InvoiceLineTotal>
<CurrencyCode>USD</CurrencyCode>
<MonetaryValue>100</MonetaryValue>**
</InvoiceLineTotal>
</TimeInTransitRequest>

UPS RESPONSE: <?xml version="1.0"?><TimeInTransitResponse><Response><TransactionReference><CustomerContext>Time in Transit</CustomerContext><XpciVersion>1.0002</XpciVersion></TransactionReference><ResponseStatusCode>1</ResponseStatusCode><ResponseStatusDescription>Success</ResponseStatusDescription></Response><TransitResponse><PickupDate>2020-07-15</PickupDate><TransitFrom><AddressArtifactFormat><PoliticalDivision2>BRONX</PoliticalDivision2><PoliticalDivision1>NY</PoliticalDivision1><Country>UNITED STATES</Country><CountryCode>US</CountryCode><PostcodePrimaryLow>10472</PostcodePrimaryLow></AddressArtifactFormat></TransitFrom><TransitTo><AddressArtifactFormat><PoliticalDivision2>BEVERLY HILLS</PoliticalDivision2><PoliticalDivision1>CA</PoliticalDivision1><Country>UNITED STATES</Country><CountryCode>US</CountryCode><PostcodePrimaryLow>90210</PostcodePrimaryLow></AddressArtifactFormat></TransitTo><ShipmentWeight><UnitOfMeasurement><Code>LBS</Code></UnitOfMeasurement><Weight>10.0</Weight></ShipmentWeight><InvoiceLineTotal><CurrencyCode>USD</CurrencyCode><MonetaryValue>100.00</MonetaryValue></InvoiceLineTotal><Disclaimer>Services listed as guaranteed are backed by a money-back guarantee for transportation charges only. UPS guarantees the day of delivery for every ground package you ship to any address within all 50 states and Puerto Rico. See Terms and Conditions in the Service Guide for details.</Disclaimer><ServiceSummary><Service><Code>1DM</Code><Description>UPS Next Day Air Early</Description></Service><Guaranteed><Code>N</Code></Guaranteed><EstimatedArrival><BusinessTransitDays>1</BusinessTransitDays><Time>08:30:00</Time><PickupDate>2020-07-15</PickupDate><PickupTime>19:30:00</PickupTime><Date>2020-07-16</Date><DayOfWeek>THU</DayOfWeek><CustomerCenterCutoff>18:30:00</CustomerCenterCutoff></EstimatedArrival><SaturdayDelivery>0</SaturdayDelivery><SundayDelivery>0</SundayDelivery></ServiceSummary><ServiceSummary><Service><Code>1DA</Code><Description>UPS Next Day Air</Description></Service><Guaranteed><Code>N</Code></Guaranteed><EstimatedArrival><BusinessTransitDays>1</BusinessTransitDays><Time>10:30:00</Time><PickupDate>2020-07-15</PickupDate><PickupTime>19:30:00</PickupTime><Date>2020-07-16</Date><DayOfWeek>THU</DayOfWeek><CustomerCenterCutoff>18:30:00</CustomerCenterCutoff></EstimatedArrival><SaturdayDelivery>0</SaturdayDelivery><SundayDelivery>0</SundayDelivery></ServiceSummary><ServiceSummary><Service><Code>1DP</Code><Description>UPS Next Day Air Saver</Description></Service><Guaranteed><Code>N</Code></Guaranteed><EstimatedArrival><BusinessTransitDays>1</BusinessTransitDays><Time>23:00:00</Time><PickupDate>2020-07-15</PickupDate><PickupTime>19:30:00</PickupTime><Date>2020-07-16</Date><DayOfWeek>THU</DayOfWeek><CustomerCenterCutoff>18:30:00</CustomerCenterCutoff></EstimatedArrival><SaturdayDelivery>0</SaturdayDelivery><SundayDelivery>0</SundayDelivery></ServiceSummary><ServiceSummary><Service><Code>2DM</Code><Description>UPS 2nd Day Air A.M.</Description></Service><Guaranteed><Code>N</Code></Guaranteed><EstimatedArrival><BusinessTransitDays>2</BusinessTransitDays><Time>23:00:00</Time><PickupDate>2020-07-15</PickupDate><PickupTime>19:30:00</PickupTime><Date>2020-07-17</Date><DayOfWeek>FRI</DayOfWeek><CustomerCenterCutoff>18:30:00</CustomerCenterCutoff></EstimatedArrival><SaturdayDelivery>0</SaturdayDelivery><SundayDelivery>0</SundayDelivery></ServiceSummary><ServiceSummary><Service><Code>2DA</Code><Description>UPS 2nd Day Air</Description></Service><Guaranteed><Code>N</Code></Guaranteed><EstimatedArrival><BusinessTransitDays>2</BusinessTransitDays><Time>23:00:00</Time><PickupDate>2020-07-15</PickupDate><PickupTime>19:30:00</PickupTime><Date>2020-07-17</Date><DayOfWeek>FRI</DayOfWeek><CustomerCenterCutoff>18:30:00</CustomerCenterCutoff></EstimatedArrival><SaturdayDelivery>0</SaturdayDelivery><SundayDelivery>0</SundayDelivery></ServiceSummary><ServiceSummary><Service><Code>3DS</Code><Description>UPS 3 Day Select</Description></Service><Guaranteed><Code>N</Code></Guaranteed><EstimatedArrival><BusinessTransitDays>3</BusinessTransitDays><Time>23:00:00</Time><PickupDate>2020-07-15</PickupDate><PickupTime>19:30:00</PickupTime><Date>2020-07-20</Date><DayOfWeek>MON</DayOfWeek><CustomerCenterCutoff>18:30:00</CustomerCenterCutoff></EstimatedArrival><SaturdayDelivery>0</SaturdayDelivery><SundayDelivery>0</SundayDelivery></ServiceSummary><ServiceSummary><Service><Code>GND</Code><Description>UPS Ground</Description></Service><Guaranteed><Code>N</Code></Guaranteed><EstimatedArrival><BusinessTransitDays>4</BusinessTransitDays><Time>23:00:00</Time><PickupDate>2020-07-15</PickupDate><PickupTime>19:30:00</PickupTime><Date>2020-07-21</Date><DayOfWeek>TUE</DayOfWeek><CustomerCenterCutoff>18:30:00</CustomerCenterCutoff></EstimatedArrival><SaturdayDelivery>0</SaturdayDelivery><SundayDelivery>0</SundayDelivery></ServiceSummary><MaximumListSize>35</MaximumListSize></TransitResponse></TimeInTransitResponse>
------------------------------------------ ???

mrsawyer:

Greetings,

I have set up our API Key and run some cross-country shipping tests (in test mode) using UPS-XML Version 1.7.8. I set the Customer Classification Code to 00 so that rates displayed would reflect our contracted agreement with UPS. I then tried using the exact same shipping information with the Customer Classification Code set to 53 to display the regular rates for comparison. To my surprise, the regular rates were about 4% to 7% lower than our contracted "discounted" UPS rates.

I have contacted UPS to make sure they have given us the correct code and have also activated the contract. While I am awaiting a reply, I thought I'd check with the forum folk here to see if using test mode could account for this, or if there is some other possible reason I have overlooked, or if there is the remote possibility that the plugin has an error.

I am hoping that some readers of this post will be so kind as to run a similar test and share their findings.

Thanks,
mrsawyer

mrsawyer:

I would like to add that I just took a quick look at the debug log which I had already enabled, but had not look at. From what I'm seeing, the plugin is passing length, width, and height of all zero inches to the UPS interface. Is there a way to pass an actual box size?

lat9:

The shipping method, as inherited, *claims *to support product dimensions but I have neither updated nor tested that processing. While there's a DIMENSIONS_SUPPORTED constant that can be changed (as you apparently have) in the shipping-module itself, that's not a processing-path that I'm prepared to support at the current time.

at the risk of getting myself into more trouble than i already in, allow me to weigh in here.

i think it best to solve 1 problem prior to moving to a new problem. i thought the original problem was that your contracted rates are showing up as being expensive than your list rates. did you solve that problem?

my understanding is that this plugin is for getting shipping quotes. if i am wrong in that, i apologize. if i am correct, and we are getting shipping quotes, i see no need to not being going to a live UPS server. last time i checked, UPS does not charge for getting a shipping quote. so why not check against the live server? i see little downside unless i am missing something here.

with regards to the bane of my existence, i mean dimensional weight, seems that lat9 is not ready to support that element on this plugin. which personally i would respect. lot of work associated with quoting dimensional weight.

what are you selling? when you look at your UPS bill, do you see a lot of dimensional weight surcharges? if you do not see them on your bill, it makes little sense to me to start building infrastructure to quote them to your customer.

lot of stores use this module. i think the 0 dimensions have 0 effect on the rate that gets quoted. the only time dimensional weight gets hit, is when you send a big box that weighs nothing. sending a box that takes up 0 space and weighs 5 lbs; well you will get the 5 lb rate.

just my 2 cents.

carlwhat:

at the risk of getting myself into more trouble than i already in, allow me to weigh in here.

i think it best to solve 1 problem prior to moving to a new problem. i thought the original problem was that your contracted rates are showing up as being expensive than your list rates. did you solve that problem?

my understanding is that this plugin is for getting shipping quotes. if i am wrong in that, i apologize. if i am correct, and we are getting shipping quotes, i see no need to not being going to a live UPS server. last time i checked, UPS does not charge for getting a shipping quote. so why not check against the live server? i see little downside unless i am missing something here.

with regards to the bane of my existence, i mean dimensional weight, seems that lat9 is not ready to support that element on this plugin. which personally i would respect. lot of work associated with quoting dimensional weight.

what are you selling? when you look at your UPS bill, do you see a lot of dimensional weight surcharges? if you do not see them on your bill, it makes little sense to me to start building infrastructure to quote them to your customer.

lot of stores use this module. i think the 0 dimensions have 0 effect on the rate that gets quoted. the only time dimensional weight gets hit, is when you send a big box that weighs nothing. sending a box that takes up 0 space and weighs 5 lbs; well you will get the 5 lb rate.

just my 2 cents.

Thanks, 98 more and I'll have a dollar! :smile: I am not interested in dimensional weight. I just asked what the Dimensions_Supported was "supposed" to do, since lat9 mentioned it, and it seemed to do nothing when changing the constant. It is all in an effort to find out more about the plugin so we can find out why we are getting lower rates when using the standard rates rather than our negotiated discounts. From your "2 cents", are you saying that changing that constant is supposed to implement a dimensional weight feature somewhere? If so, it was not apparent, not desired. We are shipping nothing at this point, just trying to make sure everything is working as it should before opening the shipping option to future customers. We have tried using test mode and live mode with the same result. We tried choosing Commercial versus Residential with the same result. So, the reason for the rate issue is not apparent yet. Hopefully, when UPS examines our site tomorrow, something meaningful will be revealed. If you have another couple of pennies, your idea of what might be amiss would be appreciated.

mrsawyer:

Our Dimensions_Supported constant is set at 0.

Here is part of the debug log that shows UPS is automatically receiving 10lbs as the package weight and $100 as the package value (unless I have misinterpreted). Our test shipment was 3.1lbs, so is this weight and value hard-coded somewhere?
...
It sounds like you're running into the Tare weight settings. Head to your admin's Configuration :: Shipping/Packaging and check those two Tare weight settings. The default for a small package is a 3x multiplier.

I just had a Zoom meeting with UPS, who confirmed all my settings in the Shipping Module are correct and that we are getting our negotiated rates displayed, YAY! :D The one question they could not answer was, why when I choose Customer Classification Code 53 (for standard rates), why the rates displayed are lower? The UPS technical person did not know what Customer Classification Code 53 was. I was under the impression that code 53 was dictated by the UPS system to signal the API to display "standard rates". She says that ZC created the customer classification codes, which made NO sense to me!

So, I'm left with two questions: 1) Is UPS the one that dictates what the Customer Classification Codes are? and 2) Why would the "standard rates" be lower than our negotiated rate?

Can someone test changing their Customer Classification Code to 53 to see if they get the same lowering of rates?

mrsawyer:

I just had a Zoom meeting with UPS, who confirmed all my settings in the Shipping Module are correct and that we are getting our negotiated rates displayed, YAY! :D The one question they could not answer was, why when I choose Customer Classification Code 53 (for standard rates), why the rates displayed are lower? The UPS technical person did not know what Customer Classification Code 53 was. I was under the impression that code 53 was dictated by the UPS system to signal the API to display "standard rates". She says that ZC created the customer classification codes, which made NO sense to me!

So, I'm left with two questions: 1) Is UPS the one that dictates what the Customer Classification Codes are? and 2) Why would the "standard rates" be lower than our negotiated rate?

Can someone test changing their Customer Classification Code to 53 to see if they get the same lowering of rates?

I just found the UPS Rating Package XML Developer Guide, where on page 21, it lists all the Customer Classification Codes. So, I have my answer to the 1st question. I am at a loss as to question #2. Why are the displayed standard rates lower than our negotiated rates? Perhaps something is wrong over at UPS??? :shocking:

In addition to my question as to why Code 53 is not yielding the correct standard rates (they are too low according to UPS), I also have the misfortune of attempting to hide the number of boxes and the weight from the customer at check out. I changed the "Display Number of Boxes and Weight Status" setting to 0 in the Admin area, but the number of boxes and weight still remain visible on our website. I am still using UPSXML v.1.7.8.

Any help with these two issues would be greatly appreciated.

mrsawyer:

In addition to my question as to why Code 53 is not yielding the correct standard rates (they are too low according to UPS), I also have the misfortune of attempting to hide the number of boxes and the weight from the customer at check out. I changed the "Display Number of Boxes and Weight Status" setting to 0 in the Admin area, but the number of boxes and weight still remain visible on our website. I am still using UPSXML v.1.7.8.

Any help with these two issues would be greatly appreciated.
I can't help with the Code 53 question, but there are checkboxes within the UPS-XML shipping-method's configuration to enable the display of the weight and transit-time. Just un-tick the "Display Weight?" checkbox.

OK, I see now, that the "Display Number of Boxes and Weight Status" setting in the Admin Configuration area are moot for this module. So, all is well with the plugin. Now to get UPS to fix their standard rates will be tough. Good thing I don't want to use the standard rates. I was just using them for testing! :smile:

Thanks,
lat9

mrsawyer:

Now to get UPS to fix their standard rates will be tough. Good thing I don't want to use the standard rates. I was just using them for testing! :smile:

i think the odds are low that the problem is with UPS.

if you post the 2 contents from your debug log for the 2 separate requests, i'm sure we can figure out where you have gone adrift. try and post them within a code block. see:

https://www.zen-cart.com/misc.php?do=bbcode#code

please ensure to post the request and the response for the 2 transactions; and do not include any sensitive data, ie your account number and any keys.

Thanks Carlwhat, however, since I am not using the Standard Rates, I'll have to deal with that later.

A problem with using the multi-lingual capability has just been revealed. We had planned to display the transit time (ETA info) so that customers would be able to choose a shipping method based on when they wanted their purchases to arrive. However, when we change the text to Spanish, the ETA info goes away. Is there a way to use the multi-language feature AND still show the ETA info?

Please Advise,
mrsawyer

mrsawyer:

A problem with using the multi-lingual capability has just been revealed. We had planned to display the transit time (ETA info) so that customers would be able to choose a shipping method based on when they wanted their purchases to arrive. However, when we change the text to Spanish, the ETA info goes away. Is there a way to use the multi-language feature AND still show the ETA info?

Please Advise,
mrsawyer
If you'd post, using those 'CODE' tags, a copy of a request/response for which the ETA info doesn't show, I'll be happy to take a look.

Lat9,

I have found that changing the text by even one character causes the ETA info not to show. See #1 and #2 on the screenshot. I have included the log, and the text we changed.

define('MODULE_SHIPPING_UPSXML_SERVICE_CODE_US_ORIGIN_01', 'UPS al día siguiente aire');
define('MODULE_SHIPPING_UPSXML_SERVICE_CODE_US_ORIGIN_02', 'UPSo 2nd Day Air');

I think the log was too long to include. What is the best way to send the log (assuming you need it)?

mrsawyer:

I think the log was too long to include. What is the best way to send the log (assuming you need it)?
Not needed; I've replicated the issue locally. The problem is that the Service Code values returned by UPS's time-in-transit service are, unfortunately, not the same as those returned for the associated Rate service.

Does that mean that the Time-in-transit routine in the plugin has to be rewritten?