Re: Is Shipping Address ResidentialAddress attribute on Shipping Estimate requests.

[Tim Ruppert]

Agreed. While we could do this totally thru the UPS interface - many companies don't want the overhead of the AVS - and it's not like it's bundled in the same request as the Rate inquiry. We should definitely change the default to residential since it's higher.

Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595


On May 18, 2007, at 1:00 PM, David E Jones wrote:

Now, if you supply these values to UPS - they ALWAYS give you back different answers. They do not change the values based upon your address - only on what you specify - at least at this time.

-David


Tim Ruppert wrote:

Between the options of adding a field to PostalAddress and passing it to the service, I definitely like the added field better (once we ask the customer we might as well remember it and not ask again, or not have the info later). Chris is right that UPS will do what they will anyway, but many companies probably still want to ask the customer to hopefully get it right. BTW, if our current default is commercial we should definitely change that to default to residential as that is the "safer" choice to avoid charges when it really is a residential instead of a commercial address.

What does everyone else think?  Any issues with this?
Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com
o:801.649.6594
f:801.649.6595
On May 18, 2007, at 11:17 AM, Anil Patel wrote:

The two methods are refactored to the point where upsRateInquire calls

upsRateEstimateByPostalCode. The parameter set of upsRateInquire  is
controlled by calcShipmentEstimateInterface which does not have
isResidentialAddress flag.


somebody was pricing is different. In order to consistently get good

web session.

+1

this.

Regards
Anil

As you have mentioned, even if we add this attribute to service interface. Order create / invoice and for future reference we'll need to remember why shipping estimate we will have to remember value of this flag beyond user for adding some kind of attribute to Postal Address to be able to remember On 5/18/07, Tim Ruppert <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:

Anil, I remember when this feature was added to the

methods were refactored to clean up the code redundancy, so the
isResidential flag would have been still used right?

this information along in the cart process that you're working on.



Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595


On May 18, 2007, at 11:04 AM, Anil Patel wrote:

Hi,

of

for

to
commercial.


there
is some other better option to handle this.

Regards
Anil Patel

upsRateInquireByPostalCode method. Last I remember I thought that these two Now, your question appears to be a bit different in that you are looking for a way to store the isResidential flag on the Postal Address in some manner. My vote would be to either extend the PostalAddress or to just pass Is this a flag everyone would like to see supported by default in OFBiz? There is noticeable difference in shipping estimate (definitely in case UPS) if Postal Shipping address is ResidentialAddress or Not. Shipping estimate services (other then upsRateInquireByPostalCode) don't account this attribute when request is sent. In case of UPS this always defaults What is best to do in this case? Should we add an attribute to Postal address, a flag that tells me if the address is ResidentialAddress. Or

smime.p7s
Description: S/MIME cryptographic signature