Re: [SQL-Ledger-users] Q. on the TO-DO list. (Payroll update)

[Izzy B. <iz...@ec...>]

At 01:57 PM 10/05/01, you 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/

This of course depends on the situation.  I for one work in co-operation 
with people who are in fact my competitors.  I trust them only as far as I 
need to, but they purchase my products and services as I do theirs.  In 
this regard they are both a vender and a customer.  A more common situation 
is for employees to purchase the products of their employer.  The concept 
expressed is still the same.  There are certain characteristics of venders, 
customers, and employees which are all the same.  Creating multiple tables 
to track the same things doesn't make a lot of sense in all situations.

Of course in your situation, there may be very good reasons to keep this 
data in separate tables.  Maybe you already have an existing vender 
database which tacks the venders address info.  In this case your need to 
keep the existing system will outweigh the need to reduce duplication.  My 
suggestion of building SQL-Ledger around the idea of being able to replace 
all none accounting specific modules with customer/country specific 
versions would allow SQL-Ledger to meet both needs. SQL-Ledger doesn't need 
to track Venders internally.  Just transactions with venders.

...Izzy