active_shipping
active_shipping copied to clipboard
Locations quietly default to 'residential', causing FedEx to categorically disable certain shipping types in favor of others.
I'm creating this as a supplement to a ticket I just opened under spree_active_shipping.
FedEx's publicly documented business logic makes certain shipping options only available for commercial shipments, and others only available for residential shipments. The FedEx code in this project defaults all Location objects to 'Residential'
if they are not explicitly set as otherwise by the application. This leads to results that are confusing to shipping novices (i.e. me).
Possible solutions
1. Explicitly encode a default value for :address_type when building a Location object
Change the address_type initializer (in ActiveMerchant::Shipping::Location) to immediately and visible specify a default
# before
self.address_type = options[:address_type]
#after
DEFAULT_ADDRESS_TYPE = 'commercial'
self.address_type = options[:address_type] || DEFAULT_ADDRESS_TYPE
2. Extend the Fedex Carrier class to print som warnings to the console when a Location
is used without explicitly setting an :address_type
[Warning] FedEx shipments will default to Residential if you do not specify an :address_type for your origin and destination Locations. FedEx offers different shipping options based on this setting.
3. Add something to the README about the residential/commercial issue
Something like the text in the previous suggestion would work.
Thanks for the sweet library!
cc: @jdugan
Just noticed that the fedex
gem has the XML to check an address's residential vs. commercial status:
https://github.com/jazminschroeder/fedex/blob/a8d9ea47dc1e9a4bf18f22d0ce668e4dd8a63172/lib/fedex/request/address.rb#L62
I tried using the fedex
gem to validate my addresses' residential/commercial status but it didn't work out. FedEx has a second access tier for their 'Advanced' API which covers the address validation service. This requires a certification so there's probably not such a huge audience for the feature after all.
Hey @dpritchett,
So I'm not a huge fan of option #1 since that could also lead to some really weird and unexpected results. #3 is alright, but doesn't let the user know they are goofing while they are working.
#2 is the best option in my opinion since we could just log it somehow (worst-case just puts), though gluing into a logger would be cooler, but I don't think that's really the goal of this library.
Implementing #2 should be easy peasy.