With the current dev version of this module + dev versions of commerce and commerce_shipping I'm always getting back Account rates, never list rates.

Reproducing is pretty easy, simply get a quote, then switch the setting in the fedex config from List to Account, or Account to List, whichever you didn't try the first time, and the result of another rate request will be exactly the same.

It looked pretty simple to me, when I looked at line 809 of FedEx.php, it appears that it's setting the RateRequestType, then overwriting it with a blank array.

809: ->addToRateRequestTypes($this->configuration['options']['rate_request_type'])
810: ->setRateRequestTypes();

But, even when I comment out line 810 and do a dump of the RateRequest object I see that the RateRequestTypes array is ["NONE"], which, according to the FedEx docs, means they will return Account rates

So, one more test, I manually insert "LIST" into the RateRequestTypes array on the RateRequest object:

->addToRateRequestTypes('LIST');

I confirm by a dump of the RateRequest object that the RequestedShipment->RateRequestTypes is ["LIST"], but my response still doesn't change, and when I dump the RateReply object, I see that the ActualRateType is "PAYOR_ACCOUNT_PACKAGE". I believe based upon a fair amount of searching that I want "PAYOR_LIST_PACKAGE" there.

My two attached screenshots below show a dump of the request and response, showing the RateRequestTypes and ActualRateType as outlined above. I'm not sure what else I can share to make this easier.

At this point I'm out of ideas. It appears to me that the RateRequest object should be returning LIST prices but it's just not. I'm not sure if there's any way to dump the raw XML to inspect it, or if I'm way off base already and someone believes I'm barking up the wrong tree.

Edit: Fixed malformed code examples

Comments

vood002 created an issue. See original summary.

vood002’s picture

Issue summary: View changes
mikelutz’s picture

Can you try the attached patch? It's definitely not working now. The options set 'preferred' for account, which is wrong. It should be 'NONE' for account and LIST for list, but if you request list, you still get back both account and list rates, so you have to filter.

I don't have a great dev environment for testing the remote calls right now, but this patch is based on my reading of the docs. I'll try to take some time to test on my end when I can as well.

vood002’s picture

Hi Mike, thanks for the response and sorry for my delayed response!

I installed the patch and did some testing. When setting to "LIST" rate types, I wasn't seeing any shipping methods I could select. I dumped some debugging information and while I can confirm the fedex_request->getRateRequestTypes is returning ["LIST"], the fedex response only contains responses of type "PAYOR_ACCOUNT_PACKAGE", thus it's never getting past this early exit as $rate_type is always "NONE":

if ($this->configuration['options']['rate_request_type'] !== $rate_type) {
    continue;
}

AFAIK this is not something specific to my client's FedEx account, they claim there are no options in their account that could affect this. I am planning to circle back at some point and spend some more time on a variety of shipping quote issues our site is having, I'll post back if I ever get to the bottom of this.

jonnyeom’s picture

Just writing some notes from my tests.

The patch does parse out any rates that are not LIST prices. However, there was a flaw in how we were parsing the returned rates.
I have updated the patch to goes through each of the RatedShipments within each RateReplyDetail (I know, its confusing) and adds them depending on the configured Rate Type.

Results
screenshot
(Top is List)
(Bottom is Account)

This is working as expected on our sites.

Jonathan

mikelutz’s picture

Status: Needs review » Reviewed & tested by the community

  • mikelutz committed 7bc005e on 8.x-1.x authored by jonnyeom
    Issue #3018615 by jonnyeom, mikelutz, vood002: API is ignoring option to...
mikelutz’s picture

Status: Reviewed & tested by the community » Fixed

Fixed, thanks!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.