Thread: [SQL-Ledger-users] Q. on the TO-DO list.

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hello,
I see on the TO-DO list that  Steve has started
a payroll system and Roderick has started  aging
reports. Are these avaiable to view?
Thanks.
Wayne.

On Wed, 9 May 2001, Wayne wrote:

> Hello,
> I see on the TO-DO list that  Steve has started
> a payroll system and Roderick has started  aging
> reports. Are these avaiable to view?

Funny you should mention this I just (re)found the notes I had buried
under some other stuff.  I'll be working on it this week and next.

Rod
-- 
                 Remove the word 'try' from your vocabulary ... 
                     Don't try.  Do it or don't do it ...
                                Steers try!

                                                            Don Aslett

Hi Wayne/everybody.

Wayne wrote:

> Hello,
> I see on the TO-DO list that  Steve has started
> a payroll system and Roderick has started  aging
> reports. Are these avaiable to view?
> Thanks.
> Wayne.

I started a payroll system and there isn't anything that can be loaded
or used yet.  If anyone wants to help or has any input on it, please let
me know and I'll send you what I have.  I've got an employee package and
a few of the sql tables started.

Here's what I have planned - it's a three part system and it just
follows existing forms and modules.

1.  An entry form and perl module to set up an employee's information
(i.e. name, address, pay rate, withholdings/deductions).  This is going
to write each employee's info to the database, which will be called and
applied to their pay period data when you enter and run payroll.  I've
got a separate table for deductions/withholdings that will have a two
part id, one associates them with an employee id and one numbers them.
It should be able to hold an infinite number and types of deductions for
employees in any country (that's the goal).

2.  An entry form and perl module to enter each employee's data for the
pay period (hours worked, vacation taken, sick time taken, etc.).
You'll also be able to run and post the pay period data here.

3. Reports.

That's a brief overview of payroll.
Steve

Hi  Steve,
I was going to hold off on offering some suggestion
until I understand what is going on in the code, but
if anyone is going to develope the payroll I would
suggest that we look at the data model a little further.
The suggertion I'm going to make is not my own. If
folks like to purchase the book "The Data Model
Resource Book"  ISBN 0-471-15364-8
you can see where I'm coming from.
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
relationship would be "employee" and  "vendor".
I know I'm leaving alot of description out, but
I think if people purchase the book it would give
the group a good model to follow.
Later.
Wayne
P.S. I should also point out that I'm learning Perl
to convert the system to Python. I hope that
doesn't offend anyone.

Steve Doerr wrote:

> Hi Wayne/everybody.
>
> Wayne wrote:
>
> > Hello,
> > I see on the TO-DO list that  Steve has started
> > a payroll system and Roderick has started  aging
> > reports. Are these avaiable to view?
> > Thanks.
> > Wayne.
>
> I started a payroll system and there isn't anything that can be loaded
> or used yet.  If anyone wants to help or has any input on it, please let
> me know and I'll send you what I have.  I've got an employee package and
> a few of the sql tables started.
>
> Here's what I have planned - it's a three part system and it just
> follows existing forms and modules.
>
> 1.  An entry form and perl module to set up an employee's information
> (i.e. name, address, pay rate, withholdings/deductions).  This is going
> to write each employee's info to the database, which will be called and
> applied to their pay period data when you enter and run payroll.  I've
> got a separate table for deductions/withholdings that will have a two
> part id, one associates them with an employee id and one numbers them.
> It should be able to hold an infinite number and types of deductions for
> employees in any country (that's the goal).
>
> 2.  An entry form and perl module to enter each employee's data for the
> pay period (hours worked, vacation taken, sick time taken, etc.).
> You'll also be able to run and post the pay period data here.
>
> 3. Reports.
>
> That's a brief overview of payroll.
> Steve

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/

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/

OK, this sounds innocuous enough, because there is some=20
distance, and the job functions/authorites are unrelated.

For example: Mr. X, has a job as the bolt buyer for DrillHole=20
Inc..  He always specifies bolts from Threadless Cos.  This=20
might be because Threadless Cos. makes better bolts, or because
Threadless is 25% owned by Mr. X.  (Did we mention that
Threadless's biggest customer is DrillHole, and that it would go
under if it weren't for DrillHole's juicy contracts?)

--linas

On Thu, May 10, 2001 at 06:49:36PM -0400, Wayne was heard to remark:
> 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
>=20
> Linas Vepstas wrote:
>=20
> > 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/
>=20

--=20
Linas Vepstas -- li...@gn... -- http://www.gnumatic.com/

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.

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/
>
>

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/
> >
> >

On Thu, 10 May 2001, Linas Vepstas wrote:

> On Thu, May 10, 2001 at 03:23:21PM -0400, Wayne was heard to remark:

> > 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.

Bad idea, too.

The typical example would be a combined vendor &
customer.  The administration and logic involved doesn't 
seem to warrant the normalization.  Think about it.
Whose "owns" the data, the A/R or the A/P people.

When you normalize this junk you end up with a useless 
entity{ id, name, canonical_address }
which may be duplicated anyway, if there are variations
in name or address.

If A/P and A/R data are purged sometime, what happens
to the empty-nested entity.  If the canonical address
is not the same as the childrens, no one may be sure
who this is.  Yes this may be eased by sharing
the "id", but this has its own problems.

> employee is paying you kickbacks, I think that may 

More usual is putting someone on a payroll
as a kickback.

rob                     Live the dream.

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

On Thu, 10 May 2001, Wayne wrote:

> Hi  Steve,
> I was going to hold off on offering some suggestion
> until I understand what is going on in the code, but
> if anyone is going to develope the payroll I would
> suggest that we look at the data model a little further.
> The suggertion I'm going to make is not my own. If
> folks like to purchase the book "The Data Model
> Resource Book"  ISBN 0-471-15364-8

There are several others that address the same issues including "Data
Model Patterns : Conventions of Thought", and the whole Case Method
series.  Data design can be a very touchy issue so I tend to avoid it.
It is very tough being a Programmer and a Database Designer at the same
time.  And the people we design for sometimes either can't get over the
hurdle of data normalization or just like their 3x5 cards, file folders,
and napkin notes.

> you can see where I'm coming from.
> 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
> relationship would be "employee" and  "vendor".
> I know I'm leaving alot of description out, but
> I think if people purchase the book it would give
> the group a good model to follow.

I'll have to look into this one.  I have theoretical books but having a
nuts and bolts will be nice.

> Later.
> Wayne
> P.S. I should also point out that I'm learning Perl
> to convert the system to Python. I hope that
> doesn't offend anyone.

Doesn't offend but I'd suggest you learn Perl then decide if you'd be
gaining anything by going to Python.

Rod
-- 

At 01:23 PM 10/05/01, you wrote:
>Hi  Steve,
>I was going to hold off on offering some suggestion
>until I understand what is going on in the code, but
>if anyone is going to develope the payroll I would
>suggest that we look at the data model a little further.
>The suggertion I'm going to make is not my own. If
>folks like to purchase the book "The Data Model
>Resource Book"  ISBN 0-471-15364-8
>you can see where I'm coming from.
>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
>relationship would be "employee" and  "vendor".
>I know I'm leaving alot of description out, but
>I think if people purchase the book it would give
>the group a good model to follow.

I was thinking along the same lines.  Thanks for the suggestion of the 
book.  I'll see if I can find it.  My thoughts on it were that it doesn't 
make sense to have multiple address databases.  An employee can be a 
customer as well as a vender and so on.  It's also worth noting that 
contact info isn't always unique.  Multiple people can live or work at the 
same location and have the same phone numbers.  Of course there's always a 
performance trade off between keeping redundant/duplicate information or 
doing multiple table lookups.

IMHO, SQL-Ledger should be flexible enough to take advantage of whichever 
contact manager, inventory control system, invoice system, payroll system, 
etc, that makes the most sense for a given customer and a given 
location.  I don't believe that it makes sense to tightly integrate a whole 
bunch of features and functions into SQL-Ledger.  A more modular approach 
that lets the developer for a given customer decide what  modules to use is 
what I'm after.  SQL-Ledger should concentrate on the accounting side of 
things and that's it.  Everything else belongs in a different project that 
can be linked in with the appropriate glue logic.

Every industry is different and has different unique needs.  For instance, 
a moving company needs to keep track of at least two addresses for every 
person; their old address and their new address. It doesn't make sense to 
integrate a contact manager into SQL-Ledger that can only handle one 
address.  Nor does it make sense to integrate a contact manager that can 
handle two addresses.  The ideal solution would be to develop SQL-Ledger 
with the idea that contact management is the responsibility of a different 
program and only store a reference to a given contact in the SQL-Ledger 
tables.  A well defined interface could then be created to allow the front 
end to extract the required data from which ever contact manager makes the 
most sense for a given customer. Creating, modifying, or deleting contacts 
should be passed of to the contact manager's interface.

I'm not saying that we don't want to create a feature rich accounting 
package here.  On the contrary, I think that the more features we can give 
it, the more likely business will consider it a viable option.  I just 
think that thought and planning should go into building each module in such 
a way that it can be replaced with an industry/country specific version as 
needed.  In that way we aren't needlessly bloating SQL-Ledger in an effort 
to make it meet the needs of everyone.  Creating basic, general purpose 
modules that are replaceable is the only way to go, IMHO.

 From the point of view of the payroll system, I think that the SQL-Ledger 
tables should be limited to tracking an employee ref#, pay cheque amount, 
and deductions.  If it isn't AP/AR/GL related, it doesn't need to be in the 
SQL-Ledger tables.  A Perl package should be created that will give a 
developer the necessary functions to interface with these tables as 
needed.  i.e. add new entires to the payroll table as cheques are being 
printed.  There's no need for SQL-Ledger to get involved in tracking 
vacation days, sick days, start date, and termination dates of 
employees.  This is clearly not accounting related but would be a part of 
any good employee tracking system.  Even the functions of printing cheques, 
tracking hours, over time tracking, pay rates, etc aren't really accounting 
related.  Just the amount paid and deducted are.

If we all think in this way when we develop new , or overhauling old 
features for SQL-Ledger, then we'll have a much richer accounting package 
in the end that can meet the needs of everyone without becoming excessively 
bloated in the process.

...Izzy

>Later.
>Wayne
>P.S. I should also point out that I'm learning Perl
>to convert the system to Python. I hope that
>doesn't offend anyone.

No offence here.  I'd actually planned and started to learn Python before 
taking up Perl.  Because of my intention to participate in developing 
SQL-Ledger, I decided to take up Perl first.  I've since learned the 
basics.  I wont insult anyone by suggesting I've become an expert in the 
short time I've been playing with it, but I know enough to be able to read 
the code and understand what is going on now.  I'd be very interested in 
looking at a Python port though.  If nothing else, it may aid my learning 
of Python! :)

>Steve Doerr wrote:
>
> > Hi Wayne/everybody.
> >
> > Wayne wrote:
> >
> > > Hello,
> > > I see on the TO-DO list that  Steve has started
> > > a payroll system and Roderick has started  aging
> > > reports. Are these avaiable to view?
> > > Thanks.
> > > Wayne.
> >
> > I started a payroll system and there isn't anything that can be loaded
> > or used yet.  If anyone wants to help or has any input on it, please let
> > me know and I'll send you what I have.  I've got an employee package and
> > a few of the sql tables started.
> >
> > Here's what I have planned - it's a three part system and it just
> > follows existing forms and modules.
> >
> > 1.  An entry form and perl module to set up an employee's information
> > (i.e. name, address, pay rate, withholdings/deductions).  This is going
> > to write each employee's info to the database, which will be called and
> > applied to their pay period data when you enter and run payroll.  I've
> > got a separate table for deductions/withholdings that will have a two
> > part id, one associates them with an employee id and one numbers them.
> > It should be able to hold an infinite number and types of deductions for
> > employees in any country (that's the goal).
> >
> > 2.  An entry form and perl module to enter each employee's data for the
> > pay period (hours worked, vacation taken, sick time taken, etc.).
> > You'll also be able to run and post the pay period data here.
> >
> > 3. Reports.
> >
> > That's a brief overview of payroll.
> > Steve

Thread: [SQL-Ledger-users] Q. on the TO-DO list.

sql-ledger-users