[ic] Multiple ship to's...

Paul R Stearns pauls@compuace.com
Tue, 05 Dec 2000 15:50:01 -0500


Warren:

I don't have a problem with an address table, but if you have one, don't put
billing info in it.

It is my experience with the multiple ship to's that is less than half there.
You can enter multiple ship to's per order but it doesn't store the data
anywhere, a kinda pointless excercise if ya know what I mean.

I am currently hacking the shiping module to handle the problem. I will make it
available if & when I complete it.

Paul

Warren Odom wrote:

> <<I am a firm believer in database normalization, and I hope that you're not
> serious about moving the ship_addresses into the userdb table. In fact I
> would like to see the current shipping info moved out of the userdb table
> and into the ship_address table.>>
>
> It depends on how this is done.  We once had a prospect who needed to
> support a large number of shipping addresses per order (like maybe 20 or
> more).  Trying to put these in one user record would not be wise.  If,
> however, Mike means that a shipping address will appear as a separate record
> in the same table just like a billing address (which seems a more likely
> interpretation), then I wouldn't necessarily call it a bad thing.  You could
> consider the table as an "address" table and I don't know that it would
> really violate the spirit of normalization.
>
> But there are some things to consider.  You still need to include a field to
> tell which shipping addresses belong to each billing address.  All searches
> for billing info in the table need to have code to ignore the non-billing
> addresses (and vice versa).  Also there will be fields that are needed for
> billing addresses but which will always be empty for shipping addresses.
> Added together, these kinds of complications could make it messy enough to
> justify separate tables.
>
> But, you know, I thought the latest version of Interchange already supported
> multiple ship-tos....?  Did I misread the announcement?
>
>            -- Warren
>
> -----Original Message-----
> From:   interchange-users-admin@minivend.com
> [mailto:interchange-users-admin@minivend.com] On Behalf Of Paul Stearns
> Sent:   Monday, December 04, 2000 8:08 AM
> To:     interchange-users@minivend.com
> Subject:        Re: [ic] Multiple ship to's...
>
> Cameron:
>
> The answer of course is to sort by ship to's and handle the shipping the
> same
> way it currently does, assuming of course that it does some sort of
> consolidation currently.
>
> My design stated below doesn't show it but, I am a firm believer in database
> normalization, and I hope that you're not serious about moving the
> ship_addresses into the userdb table. In fact I would like to see the
> current
> shipping info moved out of the userdb table and into the ship_address table.
> I
> am aware of the tradeoff's sometimes associated with normalization vs
> performance, but in this case, I would think that a single keyed read to get
> a
> "ship to" would be inconsequential.
>
> Is the problem that flat file searches are (would be) too slow? I would
> think
> that sacrificing normalization for flat file search speed would not be in
> the
> product's best interest. This of course is only my opinion.
>
> What is the timing for this "almost complete rewrite" more or less? a week?
> a
> month? 6 months?
>
> Paul
>
> "Cameron B. Prince" wrote:
>
> > Paul,
> >
> > I think you are headed in the right direction here and you solution is
> > entirely feasible. I am not sure if you are using product weights to
> > calculate shipping, but one thing you may not have considered is
> dimentional
> > weight.
> >
> > It will be easy to calculate a shipping amount for each line item in the
> > basket and add this all together to determine the total shipping amount.
> But
> > what if two items are going to the same non-default address? These items
> > could be put into the same box, which would at times be less expensive
> than
> > shipping them separately.
> >
> > I have spoken with Mike regarding this function and he has informed me
> that
> > he plans to move the information in ship_addresses tables to the userdb
> > table to consolidate the data somewhat. There will also be other
> > improvements to this function and sounds like an almost complete rewrite.
> >
> > I am not sure when this will be done, so if your schedule is tight, it
> would
> > most likely be best for you to continue on your current path.
> >
> > Good luck,
> >
> > Cameron
> >
> > -----Original Message-----
> > From: interchange-users-admin@minivend.com
> > [mailto:interchange-users-admin@minivend.com]On Behalf Of Paul Stearns
> > Sent: Sunday, December 03, 2000 8:01 PM
> > To: interchange-users@minivend.com
> > Subject: [ic] Multiple ship to's...
> >
> > Has anyone handled multiple ship to's?
> >
> > My thoughts on how to do it are;
> >
> > Add the shipmode to the ship_addresses table, force valid country and
> state
> > on ship_addresses
> > table using pull downs.
> >
> > Add all fields from the ship_addresses table to the orderline table and
> > populate with the
> > appropriate data at checkout time.
> >
> > Modify the shipping routine to use the shipping info from the orderline
> > table instead of the
> > transaction table, use the shipping field in orderline to store the
> > individual line item
> > shipping charge, keep the total in the transaction table.
> >
> > Modify the receipt print and e-mail line item section to order by ship to
> > with applicable
> > subtotals.
> >
> > If feeling overly energetic, rip the ship to info out of the userdb, and
> > transaction table. The
> > main purpose of this is to remove redundant data. It might muck with other
> > stuff in the system,
> > so I probably will take the chickenhearted approach, and leave it in.
> >
> > If somone has done something similar please let me know any hints.
> >
> > If this functionality is already in progress by Akopia, please let me know
> > before I waste my
> > energy.
> >
> > Lastly, I would be glad to share this code when done, but I really could
> use
> > some help in
> > finding out where all the bodies are buried (boy would I like to have an
> > entity relationship
> > diagram, and some inline documentation in the code).
> >
> > Paul
> >
> > _______________________________________________
> > Interchange-users mailing list
> > Interchange-users@www.minivend.com
> > http://www.minivend.com/mailman/listinfo/interchange-users
> >
> > _______________________________________________
> > Interchange-users mailing list
> > Interchange-users@www.minivend.com
> > http://www.minivend.com/mailman/listinfo/interchange-users
>
> _______________________________________________
> Interchange-users mailing list
> Interchange-users@www.minivend.com
> http://www.minivend.com/mailman/listinfo/interchange-users
>
> _______________________________________________
> Interchange-users mailing list
> Interchange-users@www.minivend.com
> http://www.minivend.com/mailman/listinfo/interchange-users