UPS XML: Support Thread

mrsawyer:

Does that mean that the Time-in-transit routine in the plugin has to be rewritten?
In a word: Yes.

lat9:

In a word: Yes.
@mrsawyer, I've got this updated on GitHub (https://github.com/lat9/upsxml/issues/25). Both the shipping-module and its language file require updates for full support.

Could/would you grab that updated version to ensure that I've corrected the "Missing ETA" issue?

Thanks, I'll check it out. Tied up in meetings for a few hours, but will check it afterwards.

lat9,

I see no problem with your update. Everything seems perfect. Great job! Thanks so much!

mrsawyer:

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

As for the standard rates, I thought they were the same as retail rates, but they are not. I found a document on UPS's website that listed all the standard rates per zone. Some of those rates are better than out contracted rates.

So all is well with the UPS XML Shipping Module.

mrsawyer:

lat9,

I see no problem with your update. Everything seems perfect. Great job! Thanks so much!
No problems; I appreciate your quick update to let me know that the changes *do *correct the issue. I'll get UPSXML v1.7.9 released.

lat9:

No problems; I appreciate your quick update to let me know that the changes *do *correct the issue. I'll get UPSXML v1.7.9 released.
Just submitted; and available for download (https://www.zen-cart.com/downloads.php?do=file&id=126).

 This release contains changes associated with GitHub issue [#25](https://github.com/lat9/upsxml/issues/25) (Missing time-in-transit display when method is translated).

Note that two additional constants have been added to the shipping-module's language file.

lat9:

This release contains changes associated with GitHub issue #25 (Missing time-in-transit display when method is translated).

Note that two additional constants have been added to the shipping-module's language file.
Now available for download.

As for the UPS XML Plugin, I have set the Shipping Delay to 0.34 days so that if a customer orders after approximately 11:45AM eastern time, the system will calculate the ETAs based on the shipment going out the following day. All worked well, as orders placed before 11:45 had an ETA that was one day sooner. This was tested on a Tuesday and a Wednesday.

Then, I tested the plugin on Friday at 11AM eastern time and correctly received an ETA of Monday for Next Day Air delivery, since there was plenty of time to schedule a UPS pickup for the package. Expecting the shipping delay to have kicked in, I checked again on Friday after 8PM (which is too late to send a shipment}, but still got the ETA of Monday. I checked again on Saturday at 6AM, and still got the Monday ETA. So, it seems that the UPS API is set to assume that shipments go out on Saturday. I have emailed UPS to confirm this, but have not yet received a reply. (I did not see a problem with the ETAs of orders placed on a Sunday.)

My question is: is there a flag that can be set in the interface with the UPS API that turns off Saturday shipping? I have looked for UPS'es Time-In-Transit API technical documentation, but have not found it as yet.

Please Advise,
mrsawyer

I've not seen anything in the UPS API to indicate that Saturday shipping isn't supported.

Saturday Shipping is certainly supported automatically, based on the ETAs generated during weekend sales, however, I need to know if that is something that can be toggled off in the UPS Time-In-Transit API. I am waiting for UPS to send me a link to their tech specs for the API, but I thought someone here may have seen that piece of info (as to whether there is a flag for turning on/off Saturday deliveries).

On Monday through Thursday at 11:02 AM, the UPS ETAs all shifted from what they showed prior to that time, to one day later. This is right and proper since we state that orders made BEFORE 11AM will ship that day. However, on today, Friday at 11:02AM, no change in ETA occurred, presumably because somewhere in the system shipping on Saturday is set.
UPS got back to me about this, stating that there is a flag on our account whether to include Saturday shipping and/or delivery. Our rep says we do not have any Saturday services , so Next Day Air after 11:02 AM "should" show a Tuesday delivery.
So, my question is: Is something in the plugin causing the UPS API to trigger ETAs based on Saturday shipping, whether the shipper has that option on their account or not?

UPS-XML, when gathering the estimated arrival dates, uses the following condition to determine the ship-date submitted to UPS:

        if (defined('SHIPPING_DAYS_DELAY')) {
             $shipdate = date('Ymd', time() + (86400 * SHIPPING_DAYS_DELAY));
        } else {
            $shipdate = $this->today;
        }

... where 86400 represents a day's worth of seconds (60 * 60 * 24). If you enable the shipping-method's debug, you'll see the request/response to UPS' *TimeInTransit *API with the request's *PickupDate *field identifying the date the shipment's to be made.

Thanks Lat9,

After looking at the UPSXML logs, all seems to be working correctly on the plugin side, but our UPS account manager says that our account settings should override a Saturday shipping date. Obviously, either she is wrong, or the UPS API is not functioning correctly. I have a support call scheduled next week with UPS tech support to determine if there is an account-based override that is not functioning or whether there is a Saturday shipping override in the API. I have a feeling that they will say the API is working as designed, to include Saturday shipping and exclude Sunday shipping, but we will see. If there is no override, then we will modify the plugin to just skip Saturday ship dates which should be easy enough.

This brings me to a question about modifying the plugin, should we use the same type of overrides we use to modify ZenCart, or just change the UPSXML.php file directly?

Thanks Again,
mrsawyer

mrsawyer:

Thanks Lat9,

After looking at the UPSXML logs, all seems to be working correctly on the plugin side, but our UPS account manager says that our account settings should override a Saturday shipping date. Obviously, either she is wrong, or the UPS API is not functioning correctly. I have a support call scheduled next week with UPS tech support to determine if there is an account-based override that is not functioning or whether there is a Saturday shipping override in the API. I have a feeling that they will say the API is working as designed, to include Saturday shipping and exclude Sunday shipping, but we will see. If there is no override, then we will modify the plugin to just skip Saturday ship dates which should be easy enough.

This brings me to a question about modifying the plugin, should we use the same type of overrides we use to modify ZenCart, or just change the UPSXML.php file directly?

Thanks Again,
mrsawyer
My suggestion would be to add a notifier at the UPSXML processing point(s) that you need to change and handle those updates via an observer class. That's similar to what I've done on one of my sites for the USPS shipping-method.

That way (with heavy commenting before/after the change), you only need to add those notifications when/if the UPSXML shipping method's updated in the future. If you go down that path, just let me know what notification(s) you've added and I'll add them to the base shipping-method so that you don't need to 'follow the bouncing ball' in the future.

Is there a way to change this module from using UPS Negotiated Rates to using UPS Standard Rates?

swguy:

Is there a way to change this module from using UPS Negotiated Rates to using UPS Standard Rates?

@swguy, i do not use this module; but i know more about shipping than i care to admit...

if standard rates are available i would look here:

https://github.com/lat9/upsxml/blob/5a0dfad3f46039a222045bb73f8a2b52d83f0889/includes/modules/shipping/upsxml.php#L409-L411

the $quote_info element may have it, and you can then change line 411 to reflect the list price as opposed to the negotiated cost from UPS.

if the $quote_info array does not have it, we would then need to look at the method _upsGetQuote:

https://github.com/lat9/upsxml/blob/5a0dfad3f46039a222045bb73f8a2b52d83f0889/includes/modules/shipping/upsxml.php#L759

and specifically what is happening there that it is only returning negotiated rates. but i have a feeling that it is already returning the list price, and that it is in the aforementioned array.

hope that helps.

swguy:

Is there a way to change this module from using UPS Negotiated Rates to using UPS Standard Rates?
Sure, just wipe out the setting for your*** UPS Rates: Shipper Number*** value, that's what determines whether negotiated rates are requested.

lat9:

Sure, just wipe out the setting for your*** UPS Rates: Shipper Number*** value, that's what determines whether negotiated rates are requested.

Looking at the code I would have thought that would work too but comparing it against the regular ups.php module, I get different rates - $11.06 with upsxml and $14.63 with ups. There are a ton of parameters of course but I thought I checked the main ones - Packaging Type, Customer Code, Pickup Method.

swguy:

Looking at the code I would have thought that would work too but comparing it against the regular ups.php module, I get different rates - $11.06 with upsxml and $14.63 with ups. There are a ton of parameters of course but I thought I checked the main ones - Packaging Type, Customer Code, Pickup Method.
I've not used the 'regular' UPS shipping method, so I don't know what it's doing (perhaps some % adder to the charges?). Shoot me a debug-output via direct email and I'll see what I can see.