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

[Tim Ruppert]

I'm also ok with this being built into the flow. My only problem is OOTB, #1 UPS AVS is not implemented to my knowledge - only USPS & #2 we can't really count on it being there for this kinda stuff.

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

o:801.649.6594
f:801.649.6595


On May 18, 2007, at 1:13 PM, Chris Howe wrote:

I like what Chris proposes, but I think that by default we should ask - and maybe we have another service OOTB that does this type of process flow.

How about this alternative.


it is and store that value for next time.

or

Ask the customer
Ask UPS
Compare
If match store value
If !match && UPS says commercial store - store commercial
If !match && UPS says residential, inform customer - store residential

--- David E Jones <[EMAIL PROTECTED]> wrote:

Don't ask the customer. The first time we have an address ask UPS what

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.

-David


Tim Ruppert wrote:

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.

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

somebody was pricing is different. In order to consistently get

good

shipping estimate we will have to remember value of this flag

beyond user

web session.

+1
for adding some kind of attribute to Postal Address to be able to

remember

this.

Regards
Anil


On 5/18/07, Tim Ruppert <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:

Anil, I remember when this feature was added to the
upsRateInquireByPostalCode method.  Last I remember I thought

that

these two
methods were refactored to clean up the code redundancy, so the
isResidential flag would have been still used right?
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
this information along in the cart process that you're working

on.

Is this a flag everyone would like to see supported by default in

OFBiz?

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,
There is noticeable difference in shipping estimate (definitely

in case

of
UPS) if Postal Shipping address is ResidentialAddress or Not.

Shipping

estimate services (other then upsRateInquireByPostalCode)  don't

account

for
this attribute when request is sent. In case of UPS this always

defaults

to
commercial.

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

there
is some other better option to handle this.

Regards
Anil Patel

smime.p7s
Description: S/MIME cryptographic signature