Is Shipping Address ResidentialAddress attribute on Shipping Estimate requests.

[Anil Patel-2]

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

[Tim Ruppert]

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

[Anil Patel-2]

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 <[hidden email]> 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
>
>
>
>

[Tim Ruppert]

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 <[hidden email]> 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

[cjhowe]

I've looked at a few UPS bills since this was discussed in Jira.  It
seems that UPS is going to make the adjustment to the bill based on
their information regardless of what we put.  That said, would it be
better to get the information on whether it is a commercial or
residential address from UPS's address validation  service prior to
getting the rate and storing that information in the cart?

The only downside I see in this approach is the amount of time it may
take to get a response from UPS.  

--- Tim Ruppert <[hidden email]> 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 <[hidden email]> 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
> >>
> >>
> >>
> >>
>
>

[David E Jones]

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 <[hidden email]
>> <mailto:[hidden email]>> 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
>>>
>>>
>>>
>>>
>

[cjhowe]

How about this alternative.  

Don't ask the customer.  The first time we have an address ask UPS what
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 <[hidden email]> 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.
>
> -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 <[hidden email]
> >> <mailto:[hidden email]>> 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
> >>>
> >>>
> >>>
> >>>
> >
>

[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.

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.

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:

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 <[hidden email] <[hidden email]>> 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

[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.

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.

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:

How about this alternative.  

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

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 <[hidden email]> 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.

-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 <[hidden email] 

<[hidden email]>> 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

[BJ Freeman]

in https://issues.apache.org/jira/browse/OFBIZ-100
I proposed a different way to handle this


Tim Ruppert sent the following on 5/18/2007 12:25 PM:

> 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.
>
> 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.
>
> 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:
>
>> How about this alternative.
>>
>> Don't ask the customer.  The first time we have an address ask UPS what
>> 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 <[hidden email]> 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.
>>>
>>> -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 <[hidden email]
>>>>> <mailto:[hidden email]>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>
>

[Tim Ruppert]

BJ thanks for the refresher - I now remember this.  This is similar to what Chris proposed, but with explicit code to take care of it - thanks.

I still think that this doesn't address the need to allow a user in a system WITHOUT an AVS service running to designate themselves as a business or residence and get more accurate information from the returning service.

How would we handle that other than:

1. Keeping track of it in the cart for sending along to UPS 

2. Adding a field on the PostalAddress

3. Storing this information in another associated table

Lemme know.

Cheers,

Tim

--

Tim Ruppert

HotWax Media

http://www.hotwaxmedia.com

o:801.649.6594

f:801.649.6595

On May 18, 2007, at 1:58 PM, BJ Freeman wrote:

in https://issues.apache.org/jira/browse/OFBIZ-100

I proposed a different way to handle this

Tim Ruppert sent the following on 5/18/2007 12:25 PM:

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.

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.

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:

How about this alternative.

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

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 <[hidden email]> 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.

-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 <[hidden email]

<[hidden email]>> 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

[BJ Freeman]

Using the USPS walk route database it does tell if a home, apartment,
high rise, business address.
This eliminates the need for AVS service search.

Tim Ruppert sent the following on 5/18/2007 1:22 PM:

> BJ thanks for the refresher - I now remember this.  This is similar to
> what Chris proposed, but with explicit code to take care of it - thanks.
>
> I still think that this doesn't address the need to allow a user in a
> system WITHOUT an AVS service running to designate themselves as a
> business or residence and get more accurate information from the
> returning service.
>
> How would we handle that other than:
>
> 1. Keeping track of it in the cart for sending along to UPS
> 2. Adding a field on the PostalAddress
> 3. Storing this information in another associated table
>
> Lemme know.
>
> Cheers,
> Tim
> --
> Tim Ruppert
> HotWax Media
> http://www.hotwaxmedia.com
>
> o:801.649.6594
> f:801.649.6595
>
>
> On May 18, 2007, at 1:58 PM, BJ Freeman wrote:
>
>> in https://issues.apache.org/jira/browse/OFBIZ-100
>> I proposed a different way to handle this
>>
>>
>> Tim Ruppert sent the following on 5/18/2007 12:25 PM:
>>> 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.
>>>
>>> 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.
>>>
>>> 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:
>>>
>>>> How about this alternative.
>>>>
>>>> Don't ask the customer.  The first time we have an address ask UPS what
>>>> 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 <[hidden email]> 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.
>>>>>
>>>>> -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 <[hidden email]
>>>>>>> <mailto:[hidden email]>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>
>