I think it's only you seeing this because a cookie is set, or you are logged in to an account that has an address established.
Try using a browser you never use, and do not log into any account.

Thanks,
David

Still haven't had much luck so far with fixing our rates, tried the XML line query on our PHP end but did not have any luck. I've reached out to UPS to see what they can do, otherwise I did peak into our XML Logging and did see that it is actively requesting Negotiated Rates based on this line:

ShipmentRatingOptions":{"NegotiatedRatesIndicator":"Y"}}}}

But somehow returns published it seems.

Hi Mafluet
How about adding the parameter …
$dumpshippingxml=TRUE;
…to your includes.php file then try getting rates and then send that JSON that should appear to UPS. It really seems like the request is ok as if you don’t have the default ship state and request negotiated rates, UPS will error. So for some reason they are not completing the request and the answer will probably be in that JSON.

quote:

---

Thinking about it, there is a better way to get the JSON request and response and that's to go to your ECT Admin -> Main Settings page and under Store Settings check the box for "Enable XML / JSON request Logging:"
Then get rates and you should find the request by going to the ECT Admin -> Dashboard and clicking on the "Activity Log".

---

Vince

Click Here for Shopping Cart Software
Click Here to sign up for our newsletter
Click Here for the latest updater

dbdave, I wasnt logged to begin with. I had a new private tab open when I made the addition of defaultshipstate= and then after I added the parameter then upon refresh my state became the default. Furthermore, I opened new private tabs on Chrome, Firefox, and Edge and without logging in I saw the same behavior from my pc. To just make sure even further, I opened up a new Safari tab on my phone and saw the same as well as a new private Chrome tab on an Android and saw the same result.

3 devices, using 5 different private tabs, none of which are logged in, all showing the same result, which has a clear correlation, and can be reverted back by removing the defaultshipstate= parameter.

I’m fairly certain that I am seeing this correctly that defaultshipstate= is doing it’s job correctly. It’s intended to make the shipping estimator’s default state to what you want it be.

The issue is that I dont want there to be a default state. Removing the parameter breaks the new UPS setup.

Imo, the addition of a new parameter such as UPSdefaultshipstate= could give UPS what it needs while not disrupting the defaultshipstate= which I want to remove so I can have no default state pre-selected in the estimator / checkout

quote:

---

Based on that the fact I never needed it before, and that the help file specifically says it's not needed, I'm not sure why it's needed now but it works.

---

It's just that when requesting UPS Negotiated Rates as well as the Ship-From Zip they require a Ship-From State and it was like that with the old and the new API's. It was kind of a feature though to default the shipping estimator to the ship state if it was provided as this is generally going to be your lowest rate. I'll check when I get time about having a parameter specifically for UPS though if it's an issue.

Vince

Click Here for Shopping Cart Software
Click Here to sign up for our newsletter
Click Here for the latest updater

Vince, thank you. I would greatly appreciate it if I can use the negotiated UPS rates and also have no default state in the estimator / checkout.

I printed out dbdaves post worked like a charm V 7.8.8

An API developer did get back to me finally, quoting something similar to what had been said to Graham in the past:

"For the Rate API only: If the Shipper address is US-based, please include the CustomerClassification object container and Code object with a value of 00 - Rates Associated with Shipper Number
 
> Nesting Path: Rate_RateRequest_CustomerClassification_Code "

It sounds like the same thing, with the CustomerClassification code needing to be mentioned in the code.

I honestly can't figure out how to input the code correctly, I tried previously based off of Graham's old thread but have a hard time writing it correctly for PHP instead of ASP.

-Zach C.

It should be fairly straight forward to add that, but I imagine this is a Vince thing. If we BOTH needed to make these changes in order to receive back the correct negotiated rates, then other users probably need that as well.

Hi guys
Thanks for that and I've added it to the code in the v7.9 updater. Are you able to try it with that version? I've tested with negotiated and non-negotiated rates and don't get an error but as I only have a sandbox account I don't get different rates. But I'd prefer for you to try it with the Advanced Release before adding it to v7.8 if possible.

Vince

Click Here for Shopping Cart Software
Click Here to sign up for our newsletter
Click Here for the latest updater

Vince you are amazing, I'll see what I can do to try it with the 7.9 release Monday. Thank you and I'll report back here with results.

-Zach C.

Hi all
It seems there was another piece to the Negotiated Rates puzzle and if you get the v7.9 updater and update the files...
vsadmin/inc/inccart.asp/php
vsadmin/inc/uspsshipping.asp/php
...then you should get the negotiated rates.

Vince

Click Here for Shopping Cart Software
Click Here to sign up for our newsletter
Click Here for the latest updater

Just to be clear, are we OK to overwrite the vsadmin/inc/inccart.php and vsadmin/inc/uspsshipping.php files in our current v7.8.8 cart with the files from v7.9?

Hi Pauld
Yes, I've checked and you could replace those files without problem.

Vince

Click Here for Shopping Cart Software
Click Here to sign up for our newsletter
Click Here for the latest updater

Just like with my request for FedEx here: https://www.ecommercetemplates.com/support/topic.asp?TOPIC_ID=116436 , is there a way to have UPS calculate the taxes and duties for Canadians or all Countries so we can pre-collect and prepay them to the couriers? I'm getting a ton of bills this year from Canadians who are refusing to pay them and losing all profits on those sales.

I have a script on my website for Canadians that is bright yellow & red and is right above the Submit Order button which reads "Orders shipped via FedEx, UPS, or DHL will have additional duties and/or taxes billed by the courier later. The bill will come from FedEx, UPS, or DHL and must be paid by the customer (YOU!)" They are most definitely aware there are going to be taxes/duties, they just simply don't pay them

This hasn't happened to me in the last 20+ years of selling online; only has been happening since earlier this year and likely politically motivated over the tariff situation. I would like to continue to sell to Canadians but I can't keep doing that if I'm getting bills from the couriers for the taxes/duties that Canadians are refusing to pay. There needs to be a system in place to pre-collect and prepay them in so buyers can't defer them back on me.

Still looking for a solution to the default state issue since the UPS change.

We're running into a new issue where people don't change the default state, and are now paying sales tax on orders when they should not. Example: We'll see orders with New York, Michigan or Los Angeles, Michigan. People are simply not changing the default state and as a result paying the wrong sales tax.

I ended up using this script so that UPS still works on the back end and customers are not checking out with my state and paying my state sales tax:

<script>
document.addEventListener("DOMContentLoaded", function() {
var st = document.getElementById("state");
if (st) {
st.value = ""; // force default to "Please select US State"
}
});
</script>

but the issue with this approach is that the state selection doesn't persist through page load. It's currently the lesser issue to deal with and would prefer an official solution that allows UPS to work with their new setup AND allows me to have "Please select US State" as the default option.

quote:

---

We're running into a new issue where people don't change the default state, and are now paying sales tax on orders when they should not. Example: We'll see orders with New York, Michigan or Los Angeles, Michigan. People are simply not changing the default state and as a result paying the wrong sales tax.

---

The exact same issue came up for us yesterday and I was just looking into this myself. Customers are definitely struggling with it.

I think I found the easy fix for now.

In incart.asp I have this line:



I believe you can safely comment out this line:
shipstate=defaultshipstate

So my code there now looks like:



The issue is that the ESTIMATOR defaults to the default ship state. If the customer then moves to the second cart page (without changing it), that default value is then copied into the second cart page. That shouldn't happen. That's cool it copies that data to the next page, but you only want that to happen if it's data the customer entered into the estimator themselves.

@Graham Slaughter , I will give yours a try this weekend. That looks like a better approach than my script.

--------------

A slight variation on my previous post, that works through updates and persists the state for me is this at the end of my cart page:

<script>
document.addEventListener("DOMContentLoaded", function () {
const st = document.getElementById("state");
if (!st) return;

// Load saved state from last visit / refresh
const saved = localStorage.getItem("checkout_state");

if (saved) {
st.value = saved; // Restore user's previous choice
} else {
st.value = ""; // Default to "Please select US State"
}

// Save user's clicked choice
st.addEventListener("change", function () {
localStorage.setItem("checkout_state", st.value);
});
});
</script>

I've made some changes to the v7.9 updater so that now you can set the parameter shiporiginstate / $shiporiginstate in the same way as the defaultshipstate but with this new parameter it will only be used for shipping rates and won't be used for checkout. If the new parameter isn't set but the defaultshipstate is and negotiated rates are used then the defaultshipstate will still be used and so it shouldn't break anything.

Vince

Click Here for Shopping Cart Software
Click Here to sign up for our newsletter
Click Here for the latest updater