Printable View
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:
... 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.PHP Code:if (defined('SHIPPING_DAYS_DELAY')) {
$shipdate = date('Ymd', time() + (86400 * SHIPPING_DAYS_DELAY));
} else {
$shipdate = $this->today;
}
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.Quote:
Originally Posted by mrsawyer
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, i do not use this module; but i know more about shipping than i care to admit...Quote:
Originally Posted by swguy
if standard rates are available i would look here:
https://github.com/lat9/upsxml/blob/....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/...psxml.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.
Sure, just wipe out the setting for your UPS Rates: Shipper Number value, that's what determines whether negotiated rates are requested.Quote:
Originally Posted by 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.Quote:
Originally Posted by lat9
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.Quote:
Originally Posted by swguy