From: Steve D. <sd...@sw...> - 2001-05-11 01:04:20
|
Hi Wayne. Matt Benjamin wrote: > I have to say, I think the "employee also your customer" notion is > somewhat strained. I doubt it leads to much data redundancy. > > Offhand, possibly "your vendor is also your customer" is more common, and > maybe is more relevant. I agree here, but even in a customer/employee situation, those are two unique relationships and the data should probably be grouped together even if redundant. I still don't think the redundancy would be extensive. It would only be the name, contact, and residence info anyway. Billing terms, sales tax, wage rates, withholdings, and all of the other data is unique to the relationship as either customer or employee. I have gotten burned by this situation where a company only updated a CRM app (Siebel) for customer address changes without considering what was in the shipping data in their accounting app. Someone spent up to an hour a day trying to keep them in sync across the customer base. This was a big problem, because when customers ordered things, they sometimes went to the wrong address, and it made the company look like idiots. I think this will be okay. And since this is free software, if it presents a problem, you can "fix" it. Thanks for the input. Steve > > > matt > > Matt Benjamin President/CTO > > The Linux Box > 206 South Fifth Ave. Suite 150 > Ann Arbor, MI 48104 > > tel. 734-761-4689 > fax. 734-769-8938 > pgr. 734-431-0118 > > On Thu, 10 May 2001, Wayne wrote: > > > Hi Linas, > > I know of many companys that have employees > > that use there sevice for other work. For example > > I have one company that has an employee that > > has his own business doing lawn care. This > > employee is a welder during the day for said > > company. On weekend he does the out ground > > care for this company. > > Wayne > > > > Linas Vepstas wrote: > > > > > On Thu, May 10, 2001 at 03:23:21PM -0400, Wayne was heard to remark: > > > > Hi Steve, > > > > This book has good data model for a business. > > > > One enity that is present is a "Party", a party is > > > > a person or and organization. One then associates > > > > a relationship to a "Party". This will help to reduce > > > > data redundancy. For example, if I have an employee > > > > that happens to be a vendor, then the party is in > > > > my DB only once , as a person, and I only have to > > > > establish the relationship this enity has. That > > > > > > Bad example. > > > > > > If you have employees who also act as vendors to you, > > > you are putting yourself into a conflict of interest. > > > If you're the sole owner, hey, that's up to you, but > > > if you work for a larger company, that's grounds for > > > getting yourself and your employee fired. If the > > > employee is paying you kickbacks, I think that may > > > even be a felony under rico. > > > > > > --linas > > > > > > -- > > > Linas Vepstas -- li...@gn... -- http://www.gnumatic.com/ > > > > |