[ic] Merge perge for user database

[rbragg at rickbragg.net]

Paul Jordan wrote:
> Ed LaFrance [edl at newmediaems.com] wrote:
> 
>>At 09:56 AM 11/8/2003 -0500, you wrote:
>>
>>>Is there a built in way to handle merging of customer accounts?
>>>
>>>i.e. if a customer orders and does not log in, they get new accounts
>>>each time. If they then call in an order later, and we find that
>>>they have many accounts, we would like to merge them into 1.
>>>
>>>Thanks
>>>Rick
>>
>>You would have to do this manually, though you could probably write a
>>script to handle it; there is no built in feature for this. In
>>practice, once you have decided which userdb account will be primary,
>>it is just a matter of inserting that customer ID in the username
>>field of all affected records in the transactions table, then
>>deleting the redundant
>>userdb records.
>>
>>- Ed L.
> 
> 
> Yes, and orderline has a username column as well.
> 
> So, decide the primary, then iterate through all transactions and orderlines
> and swap old username for primary username. Then, take the old userdb's
> 'order_numbers' and append them to the primary userdb's 'order_numbers' column.
> 
> That should be all there is, assuming you never implemented advanced tables
> like "order_returns" or "forum", etc.
> 
> The only hard part will be how to associate old and new usernames via ADMIN.
> Your best bet is probably to make the UPDATE/DELETE query, then just copy paste
> the old username with the primary username (into the query). You would have to
> retrieve them first by manually searching obviously. I probably would not write
> a script that compares addresses and automatically merges.
> 
> You could make two pages. One, that show results of similar
> addresses/names/whatever in a row. Each record would have a:
> 
>   radio    	() primary account
>   checkbox	[] merge account
> 
> and each row would have a checkbox:
> 
> 		[] merge these records
> 
> Your query could be built in from that.
> 
> I avoided this by requiring login. If you don't require log in, it makes life
> harder not only for you but for the customer. If a customer signs up for a
> newsletter everytime he makes a purchase, it will be a bear to
> unsubscribe/maintain subscriptions. If you want to offer advanced features like
> personalized tools, they need log in as well. Having an order history/status is
> a tool to mitigate customer service, which is really useless if they don't have
> a real account.
> 
> I would rather have one record a user can control, know what he is subscribed
> to, what he is not, and all his orders. I don't like one person having 20
> userdb records. It probably also depends on your product though.
> 
> I think subliminally to a consumer, requiring login is a bit of a turn off.
> However, they won't admit that it does instill confidence that it is not just
> some hack job that will send/save your CC number in the clear to some punk teen
> that drives around in a 71' primer grey camero with t-tops that steals your
> lunch money even after my mom called the principle...
> 
> Ugh... anyways, 90% of all my purchases are on the web, and 99% of the sites I
> use require login.
> 
> HTH
> Paul
> 
> _______________________________________________
> interchange-users mailing list
> interchange-users at icdevgroup.org
> http://www.icdevgroup.org/mailman/listinfo/interchange-users
> 



I would like to require login, but for complex mail order catalog 
management, I have to be able to take orders in many ways, internet, 
phone, mail, or fax. I would like to use Interchange as an open source 
replacement for something like "sigma". 
(http://www.sigma-micro.com/Products.htm)
That has the ability to really do lots of stuff, like giving sales reps 
the ability to override prices, track advertising "source codes", 
coupons,  gift certs, returns and credits, etc...

Rick