[ic] Shipping to different zip code

[Mike Heins]

Quoting Russell Mann (tech@khouse.org):
> > > 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.
> >
> 
> Ok, show me one major ecommerce site that works the way Interchange does.
> Buy.com, Amazon.com, etc.  There's a reason for this.  With the Interchange
> system, if I put in my friends name for the Ship To address, then next time
> I login, the system will say "Welcome to Buy.com Fred Cougar" instead of
> "Welcome to Buy.com Russell Mann."  This is a bit unprofessional, and
> confuses people.

Those are all consumer-oriented sites. If the greeting is all it is
it couldn't be simpler to handle.

    Welcome, [either][value b_fname][or][value fname][/either]!

Or you could write a small usertag that gave the entire name including
a salutation. Or any number of other options.

Aren't you making rather sweeping generalizations? How do you even know
what they have under the hood?

There simply is no one right way to do it. We selected the way that
seems to work out best to make catalogs easy to administer and
develop. This was not done in a vacuum -- actually MiniVend started
out the other way and changed to this way because it made so much
more sense from a complexity standpoint.

> 
> > > In any case, I fixed the problem by eliminating the
> > > shipping address from the userdb, and selecting a shipping
> > address for the
> > > entire order based on entries in the "ship_addresses" data table.
> > >
> > > The problem comes in calculating shipping costs.  If the shipping and
> > > billing addresses are the same, no problem.  If the shipping address is
> > > different, I need to be able to calculate shipping based on a different
> > > address.  How can this be done?
> > You will have to figure that out, since you chose to use a different
> > paradigm. You should probably change your shipping calculation code to
> > account for this.
> 
> Do you mean in the shipping.asc file, or somewhere else?
> 
> >
> > Not having to deal with this is just one of the advantages of having a
> > the main address be the shipping address.
> >
> 
> Are there other advantages?

Yes.

If you are not a consumer-oriented site, the billing address is much
less likely to be the actual person patronizing the catalog.

You don't have to worry about tax application on alternative addresses,
either. It is very important to have precise geo information for taxing,
and shipping address is almost always the basis for tax.

> 
> Can you point me in the direction of the code section that handles this?
> One would assume that by including the "ship_addresses" database in the demo
> there would be support for actually shipping to those addresses, or at least
> a plan to get there.  Has anyone else done this?

That is the whole point. There is no "code section". Shipping is custom
in almost all cases, there are many taxing paradigms, and there are many
places where taxing is involved. It is all over the map, and having to
allow for multiple geo-code parameters in all these places is extremely
hard to do.

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

There's nothing sweeter than life nor more precious than time.
-- Barney