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

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

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