[ic] Shipping to different zip code

[Mike Heins]

Quoting gurs@sbcglobal.net (gurs@sbcglobal.net):
> > Quoting Russell Mann (tech@khouse.org):
> > > Hello,
> > > 
> > > I'm using IC 4.8.3 and the default user database setup is klunky in regards
> > > to the shipping and billing address.  The billing address should be the
> > > primary information entered, and shipping information should only be entered
> > > if it is separate.
> > 
> > You make this statement without showing any evidence as to why anyone
> > should agree with you.
> 
> The billing address should be the primary address and shipping address
> should be changeable per order. For one this is how every
> order/invoice/shipping management software is setup (Or that I have
> come across and one less thing to worry about when connecting
> backoffice with online). And even more important when you consider the
> following common scenerios,
> 
> 	For B2B sites:
> 		With Billing as primary,
> 			Dealer has multiple locations
> - Dealer could setup one account with the Billing info as the Primary Address
> - Dealer simply uses his "address book" to select what locations he
>   wishes to ship to and place orders without logging into multiple
>   accounts

Interchange has multiple shipping and billing addresses. There is no
real difference in IC between the two. The only difference is what
happens when the billing is different from the shipping.

> 
>               With Shipping as primary,
>       Dealer has multiple locations
> - Dealer would need to setup a different account for all locations
> - Dealer would need to login to multiple accounts to place orders

What about multiple purchase orders, multiple B2B credit cards, and
multiple divisions? There are many customers who pay based on a contract,
and the billing address will always change.

So what I am saying is that no one model works for everyone in every
situation. This is a given. The question is can you do what you need
to do? In Interchange you absolutely can.

>       For B2C sites:
>               With Billing as primary,
>                       Consumer wishes to send a gift to friend
> - Consumer could setup one account with Billing info as the Primary Address
> - Vendor simply uses his "address book" to select what locations he
>   wishes to ship to and place orders without logging into multiple
>   accounts or changing his ship to information

This is the way it is now. They are just fields in a database, doesn't
anyone see this! The key thing is that you have control over both.

>               With Shipping as primary,
>                       Consumer wishes to send a gift to friend
> - Consumer would need to setup a different account every time he
>   wishes to buy a gift or to change his shipping info every time
>   (defeating one of the benefits of an account)

Absolutely not. They just bring in a different shipping address
from the address book.

> - Dealer would need to login to multiple accounts to place orders

Again, no. They just bring in a new shipping address from the address
book.

> Most people/companies use one payment type and don't need to change
> the billing address all the time, when ever their billing address
> changes they can just update the account info.

This is not true in my experience. In today's world, it is common for
small businesses and consumers to use multiple credit cards for payment.
Oftimes they have a company credit card and a personal credit card with
different billing addresses. If the billing address does not match then
you don't pass AVS.

> 
> I am not demanding that this be done right now or that it should be
> done for free or that it should be done at all. If someone does it
> great, if someone doesn't do it no problem I will eventually do this,
> but since I don't need this right away I am not worried about it. I
> have to first setup a multimedia management system, then gift
> certificates, and then affiliate reporting before I can worry about
> changing this.
> 

That is the whole point. It does not need to be done -- these are all
logical distinctions that make no real difference in practice. If you
turn it around and look at it from another direction, you will see
this. 

The reason IC does it this way is to keep the shipping field name the
same no matter what. If you did not do this, every time you took an
order or formulated a transaction you would have to copy the information
from the billing address in the most common case where they are the
same. Unless you have a totally invarying number of fields to copy,
as is the case for software packages that are not as flexible as
IC, this is very difficult to manage.

For payment this is much easier because payment information is only
ever needed for the transaction. In almost all cases you don't tax
based on billing address and you never calculate shipping based on
billing address. So you can do a temporary mapping in one place and
you are done.

The only reasonable way that anyone could do better would be to have
a c_lname and c_fname field for the actual name of the person in the
account. In Interchange, this is as simple as adding the fields to
the database and copying the information over when you collect the
initial address.

If you were limited to one shipping address -- that would be a
big problem. 

Most of the software that you think of is limited in that way. You
have one billing address and that is it. 

Interchange has the ability to have both multiple shipping and
multiple billing addresses. So why worry?

The thing that I would *most* like to do would be to set up a new
"addresses" database that allows you to store these addresses in a table
fashion, routing them to either billing or shipping address as you wish.
It is actually a pretty simple concept, but no one has funded the work
yet for me to do it. I believe some others have done implementations,
but have not taken the time to generalize and polish it enough for
public consumption.

-- 
Mike Heins
Perusion -- Expert Interchange Consulting    http://www.perusion.com/
phone +1.513.523.7621      <mike@perusion.com>

Experience is what allows you to recognize a mistake the second
time you make it. -- unknown