sql-ledger-users

[SL] Payroll

[Jigme D. <jig...@gm...>]

I'm looking at my setup for SL and right now I'm not seeing any
payroll module.  That is while I see the HR module, and the Projects
module, I don't see a way to print up cheques/cheque stubs for the
hours that my employees have put in.  Am I missing something obvious?
I think I've gone through a few times to figure this out, and put the
payroll through, but the only way that I can see this right now, is to
manually enter the cheques, and stubs through the general ledger.

Jigme Datse

Re: [SL] Payroll

[David B. <dav...@sb...>]

On Mon, 2007-03-26 at 18:31 -0700, Jigme Datse wrote:
> I'm looking at my setup for SL and right now I'm not seeing any
> payroll module.  That is while I see the HR module, and the Projects
> module, I don't see a way to print up cheques/cheque stubs for the
> hours that my employees have put in.  Am I missing something obvious?
> I think I've gone through a few times to figure this out, and put the
> payroll through, but the only way that I can see this right now, is to
> manually enter the cheques, and stubs through the general ledger.

I have my associates/employees set up as vendors and pay out using Add
AP Transaction.  Entering the transaction this way allows me to enter
Gross Pay under whatever expense account I am paying them through and
entering deductions in the same transaction for withheld payroll taxes,
garnishments and other items.  Works for us, but your mileage may vary.

HTH,
David Boyle
NAPCO


> 
> Jigme Datse
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> sql-ledger-users mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users

Re: [SL] Payroll

[Jeff R. <je...@jr...>]

Hi Jigme

I do the same as David, if you set up your 'deduction' liability 
accounts (tax owing, employment insurance owing, pension owing etc) they 
will appear in the drop down menus of the AP module. You can put in the 
gross pay and assign it to an expense and then use negative numbers to 
'deduct' from the gross and assign the 'deductions' to liability 
accounts. When I'm all done printing the cheques I do a GL entry to 
account for the matching expenses, I, for example, expense the amount I 
have to match on their pension contributions (Pension expense) and add 
it to a liability account called 'pension owing' (same account I used 
when cutting their cheque). This way both my contribution and their 
contribution end up in the same liability account. At the end of the 
month when it's time for remittance I pay from a bank account and 
decrease the liability account back to zero.

None of this does anything for the calculations that have to be made to 
determine how much each employee has to pay each of the various 
deductions. I have a spreadsheet with the Canadian formulas in it to do 
that and it's printout is what I use to cut the cheques and do the GL entry.

Jeff Roberts

David Boyle wrote:
> On Mon, 2007-03-26 at 18:31 -0700, Jigme Datse wrote:
>   
>> I'm looking at my setup for SL and right now I'm not seeing any
>> payroll module.  That is while I see the HR module, and the Projects
>> module, I don't see a way to print up cheques/cheque stubs for the
>> hours that my employees have put in.  Am I missing something obvious?
>> I think I've gone through a few times to figure this out, and put the
>> payroll through, but the only way that I can see this right now, is to
>> manually enter the cheques, and stubs through the general ledger.
>>     
>
> I have my associates/employees set up as vendors and pay out using Add
> AP Transaction.  Entering the transaction this way allows me to enter
> Gross Pay under whatever expense account I am paying them through and
> entering deductions in the same transaction for withheld payroll taxes,
> garnishments and other items.  Works for us, but your mileage may vary.
>
> HTH,
> David Boyle
> NAPCO
>
>
>   
>> Jigme Datse
>>
>> -------------------------------------------------------------------------
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to share your
>> opinions on IT & business topics through brief surveys-and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> sql-ledger-users mailing list
>> sql...@li...
>> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users
>>     
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> sql-ledger-users mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users
>
>
>   

Re: [SL] Payroll

[William H. <wi...@th...>]

There has been regular discussion on this subject for some time. (my 
list collection only goes as far back as 2002 - there may be more before 
that time.)
Subject questions about payroll
Date: 12/12/2002 4:57 a.m.

There was more in 2003.
Subject [SL] Perl Payroll API
Date: 9/09/2003 7:10 a.m.

Subject [SL] payroll
Date: 8/12/2003 3:14 p.m.

And earlier this year
Subject [SL] US Payroll
Date: 16/01/2004 2:30 a.m.

And now the recent couple of postings.
(NOTE: This is only postings I have with payroll in subject line, other 
may cover it inside body)

It does seem to be a common request/requirement.  As I see it, Payroll 
is so varied and complex when dealing wityh multiple countries and their 
respective laws and taxes.  It would most likely take a lot of effort to 
get to the level of internationalisation that SL has to date.  This is 
not to say that it is an impossible task.

I suggest, if people want payroll, raise your hand and offer 
time/expertise/resources/funds and see if we can make it happen.  I 
would be happy to help out, if it were a realistic project.

Could an alternative solution be the integration of a more specialised 
application?

my 2c worth

W


Assured Computing wrote:
> Hi,
> 
> This is a 2 layer question.
> 
> Dear Mr. Simader, how is payroll coming?
> 
> Our payroll is being handled in Peachtree at the moment.  What accounts do I
> need to show taxes and whatnot in SL.  Specifically, how should they be
> defined so they will fit into Dieter's scheme without making a mess when he
> finally is ready to release it?
> 
> I'm trying to plan ahead a little bit here.
> 
> Thanks for a great program and all the help here.
> Bob
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_idP47&alloc_id808&op=click
> _______________________________________________
> sql-ledger-users mailing list
> sql...@sq...
> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users
> 


-- 
William Hamilton

TheVirtual Ltd                  Voice:  +64 4 801 5830
Wellington, New Zealand         Mobile: +64 21 650 936
wi...@th...        www.thevirtual.co.nz
Making Virtual Business Reality

Re: [SL] Payroll

[Vicki R. <vi...@be...>]

I'm thinking that an international payroll might be possible if it 
included lots of ways to adjust withholdings.

For example, choices for each withholding might include:
* will this formula operate against gross (stage 1) or against 'almost 
net' which would be the total after all stage 1 adjustments are completed?

* will this withholding be a percentage, a set amount or a user defined 
formula? User defined formulas could allow for things like ((gross - 
241) * 0.125)

* is this withholding applied every payperiod or event triggered? 
Perhaps this could be used to allow for once a month withholdings when 
the payroll is prepared weekly, etc.

* what will be the title of this withholding?

* to what vendor and account will this withholding relate?

Since the withholdings are very flexable and you would be able to setup 
as many as necessary, this should take care of the tax type requirements 
of wherever and allow for things like garnishments, insurance, etc.

Something similar could be used to allow for additions such as payments 
of child care allowances, commissions, etc.

-- 
========================================================================
This is me:
Vicki Reeves          vi...@be...        http://www.beau.org/~vickir

This is where I work:
Beauregard Parish Library                        http://library.beau.org
205 South Washington Ave, DeRidder, LA 70634           (337)463-6217 x19
  The Library does not necessarily agree with everything I write :-D

Geek code 3.1:GIT d? s-:++ a? C++ L++$ W++ w-- Y+ b+ G e r+++

                              <><

Re: [SL] Payroll (Draft DB Schema for US)

[Chris T. <ch...@me...>]

I have designed something that amost fits what you are talking about.  
See the attachment for more info.

Vicki Reeves wrote:

> I'm thinking that an international payroll might be possible if it 
> included lots of ways to adjust withholdings.
>
> For example, choices for each withholding might include:
> * will this formula operate against gross (stage 1) or against 'almost 
> net' which would be the total after all stage 1 adjustments are 
> completed?

Yes-- the before_tax flag can be used for this purpose.  This is 
primarily a US centric thing though (my implimentatation, that is).

>
> * will this withholding be a percentage, a set amount or a user 
> defined formula? User defined formulas could allow for things like 
> ((gross - 241) * 0.125)
>
Formulas are not really supported.  For custom formulas, I suggest using 
stored procedures as I am doing in this example for federal income taxes 
(US).

> * is this withholding applied every payperiod or event triggered? 
> Perhaps this could be used to allow for once a month withholdings when 
> the payroll is prepared weekly, etc.
>
Not supported at all in this draft.  Not sure what the applications are, 
but would be really easy to add if necessary.

> * what will be the title of this withholding?
>
Supported.  Also, is this globally appropriate (i.e. affects everyone) 
or per employee.
Eventually may need to make this country specific and add something into 
the employee table to handle it.

> * to what vendor and account will this withholding relate?
>
Good point, had forgotten about vendor.  Will add this.

> Since the withholdings are very flexable and you would be able to 
> setup as many as necessary, this should take care of the tax type 
> requirements of wherever and allow for things like garnishments, 
> insurance, etc.

supported globally and per employee.

>
> Something similar could be used to allow for additions such as 
> payments of child care allowances, commissions, etc.

Allowances might have to be handled differetly.  Anyway, this rough 
draft only handles payroll witholding and not the calculation of the 
gross ammt.  I would suggest offering separate checks for tax-free 
benefits, though if these are kept as a per-employee balance, it is not 
a problem.

This system uses wage bracket percentage-method for calculating the 
federal income tax witholdings and does not include the tax tables.   It 
is just a set of ideas at this point...

Best Wishes,
Chris Travers

Re: [SL] Payroll (Draft DB Schema for US)

[Vicki R. <vi...@be...>]

Chris Travers wrote:
> I have designed something that amost fits what you are talking about.  
> See the attachment for more info.

Thanks Chris! I will definitely play with this soon.  We are in a 
homebrew payroll/bookkeeping system based on a database product which 
has gotten way too expensive for what we use it for.  I want to move to 
SQL-Ledger and payroll is a must.

-- 
========================================================================
This is me:
Vicki Reeves          vi...@be...        http://www.beau.org/~vickir

This is where I work:
Beauregard Parish Library                        http://library.beau.org
205 South Washington Ave, DeRidder, LA 70634           (337)463-6217 x19
  The Library does not necessarily agree with everything I write :-D

Geek code 3.1:GIT d? s-:++ a? C++ L++$ W++ w-- Y+ b+ G e r+++

                              <><

Re: [SL] Payroll

[Santoken <san...@br...>]

List,

After the last few weeks' discussions regarding payroll, and what 
appeared to be an opinion of work-arounds, lack of need, etc. I started 
planning my own.

My theory was a plugin to SL.  Working with SL, but not within.  My fear 
would be to create a module, then the next update that I wanted came 
out, I'd have to recode the payroll.

I'm not a coder, but I do dabble.  I'm sure that I will be using 
improper jargon, but here's what I've came up with at this point:

My module would be perl/sql based.  It would work hand in hand with SL, 
posting approiatly directly to the SL db.  First, the deductions would 
be defined in a Deductions Definition screen.  Each deduction would be 
entered in a formula format and assigned a deduction varible or tag 
name.  Example being for the FICA deduction, you could name it FICA. 
For Barney Fife's child support, you could name it BFCS, etc.  You could 
assign each deduction an order of preference, if you so need.  Some 
deductions would be pre-tax, some post-tax.

We then move on to the employee definition screem, where you assign the 
deduction tags to the employee.

Then, a payroll generation screen, to select/deselect the employees for 
that generation.  Once the generation is complete, you print checks, and 
post.

While I'm sure that I have missed some things, that is the general jist 
of what I had in mind.  Funny this came up just today, because I 
actually started work last night  :)  I spent the last few days with the 
concept, and figured that with winter coming, I would have something by 
spring.  Anyone have an thoughts?

Kent



Vicki Reeves wrote:

> I'm thinking that an international payroll might be possible if it 
> included lots of ways to adjust withholdings.
> 
> For example, choices for each withholding might include:
> * will this formula operate against gross (stage 1) or against 'almost 
> net' which would be the total after all stage 1 adjustments are completed?
> 
> * will this withholding be a percentage, a set amount or a user defined 
> formula? User defined formulas could allow for things like ((gross - 
> 241) * 0.125)
> 
> * is this withholding applied every payperiod or event triggered? 
> Perhaps this could be used to allow for once a month withholdings when 
> the payroll is prepared weekly, etc.
> 
> * what will be the title of this withholding?
> 
> * to what vendor and account will this withholding relate?
> 
> Since the withholdings are very flexable and you would be able to setup 
> as many as necessary, this should take care of the tax type requirements 
> of wherever and allow for things like garnishments, insurance, etc.
> 
> Something similar could be used to allow for additions such as payments 
> of child care allowances, commissions, etc.
> 

Re: [SL] Payroll

[Mark W. <wa...@ea...>]

Santoken,

I think you should take a close look a some free demos from the pay for 
companies.  There are reports that must be filed electronically for the 
payroll to work for evenly small companies.  I would be happy to point 
you to some of the demos if you would like.  Write me off list and I 
will send you some.

Mark


Santoken wrote:

> List,
>
> After the last few weeks' discussions regarding payroll, and what 
> appeared to be an opinion of work-arounds, lack of need, etc. I 
> started planning my own.
>
> My theory was a plugin to SL.  Working with SL, but not within.  My 
> fear would be to create a module, then the next update that I wanted 
> came out, I'd have to recode the payroll.
>
> I'm not a coder, but I do dabble.  I'm sure that I will be using 
> improper jargon, but here's what I've came up with at this point:
>
> My module would be perl/sql based.  It would work hand in hand with 
> SL, posting approiatly directly to the SL db.  First, the deductions 
> would be defined in a Deductions Definition screen.  Each deduction 
> would be entered in a formula format and assigned a deduction varible 
> or tag name.  Example being for the FICA deduction, you could name it 
> FICA. For Barney Fife's child support, you could name it BFCS, etc.  
> You could assign each deduction an order of preference, if you so 
> need.  Some deductions would be pre-tax, some post-tax.
>
> We then move on to the employee definition screem, where you assign 
> the deduction tags to the employee.
>
> Then, a payroll generation screen, to select/deselect the employees 
> for that generation.  Once the generation is complete, you print 
> checks, and post.
>
> While I'm sure that I have missed some things, that is the general 
> jist of what I had in mind.  Funny this came up just today, because I 
> actually started work last night  :)  I spent the last few days with 
> the concept, and figured that with winter coming, I would have 
> something by spring.  Anyone have an thoughts?
>
> Kent
>
>
>
> Vicki Reeves wrote:
>
>> I'm thinking that an international payroll might be possible if it 
>> included lots of ways to adjust withholdings.
>>
>> For example, choices for each withholding might include:
>> * will this formula operate against gross (stage 1) or against 
>> 'almost net' which would be the total after all stage 1 adjustments 
>> are completed?
>>
>> * will this withholding be a percentage, a set amount or a user 
>> defined formula? User defined formulas could allow for things like 
>> ((gross - 241) * 0.125)
>>
>> * is this withholding applied every payperiod or event triggered? 
>> Perhaps this could be used to allow for once a month withholdings 
>> when the payroll is prepared weekly, etc.
>>
>> * what will be the title of this withholding?
>>
>> * to what vendor and account will this withholding relate?
>>
>> Since the withholdings are very flexable and you would be able to 
>> setup as many as necessary, this should take care of the tax type 
>> requirements of wherever and allow for things like garnishments, 
>> insurance, etc.
>>
>> Something similar could be used to allow for additions such as 
>> payments of child care allowances, commissions, etc.
>>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out 
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> sql-ledger-users mailing list
> sql...@sq...
> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users
>

RE: [SL] Payroll

[<In...@wi...>]

Hello Kent,

>Sent: Monday, October 11, 2004 5:59 PM
>To: sql...@sq...
>
>My theory was a plugin to SL.  Working with SL, but not within.  My fear
>would be to create a module, then the next update that I wanted came
>out, I'd have to recode the payroll.
I think a good upgrade friendly way is to use your own frontend and backend
code (maybe including all helper modules like io.pl, Form.pm..., too)
Then it will be usefull to create an own tableset and not change the
sql-ledger tables.

>I'm not a coder, but I do dabble.  I'm sure that I will be using
>improper jargon, but here's what I've came up with at this point:
>
>My module would be perl/sql based.  It would work hand in hand with SL,
>posting approiatly directly to the SL db.
I wouldn't post data directly into the SL db, because of future changes and
dependencies to other tables. Posting data directly into the sql-ledger
tables is in my eyes to chancy, just one systematic error in your data
entrys which will appear after thousands of bookings...
A better way may the use of the gl.pl of sql-ledger. Just simulate a booking
in gl and analyze the posted data. This way you create easily your own link
and post it to the gl.pl. If the gl-api will change its a small job to
adjust your link.

For the rest I cant say anything more, I don't need payroll.
I found this in an old (2002-12) users posting , maybe it helps:
http://cbbrowne.com/downloads/sql-payroll.tgz
(Complete posting
http://www.freelists.org/archives/sql-ledger-users/12-2002/msg00126.html)

Good luck

Udo Spallek

Re: [SL] Payroll

[Chris T. <ch...@me...>]

Since I am neither an accountant nor a tax lawyer, and I live in a state 
without state income tax, I have an interesting question for folks---

Are there any states in the US (or regions elsewhere) where certain 
payroll deductions may be exempt from state or regional taxes but not 
from federal taxes or vice versa?  This is something which could greatly 
complicate payroll.

My idea is as follows:
1)  Simple percentage deductions will be defined in a table.
2)  Complex deductions (such as US Federal Income Tax) would be handled 
by stored procedures, allowing these to be swapped out for other 
countries.  These may need to be specifically coded for specific regions.
3)  The actual paycheck deduction definition would be handled in a 
stored procedure and returned as a set of records.

Best Wishes,
Chris travers
Metatron Technology Consulting

Santoken wrote:

> List,
>
> After the last few weeks' discussions regarding payroll, and what 
> appeared to be an opinion of work-arounds, lack of need, etc. I 
> started planning my own.
>
> My theory was a plugin to SL.  Working with SL, but not within.  My 
> fear would be to create a module, then the next update that I wanted 
> came out, I'd have to recode the payroll.
>
> I'm not a coder, but I do dabble.  I'm sure that I will be using 
> improper jargon, but here's what I've came up with at this point:
>
> My module would be perl/sql based.  It would work hand in hand with 
> SL, posting approiatly directly to the SL db.  First, the deductions 
> would be defined in a Deductions Definition screen.  Each deduction 
> would be entered in a formula format and assigned a deduction varible 
> or tag name.  Example being for the FICA deduction, you could name it 
> FICA. For Barney Fife's child support, you could name it BFCS, etc.  
> You could assign each deduction an order of preference, if you so 
> need.  Some deductions would be pre-tax, some post-tax.
>
> We then move on to the employee definition screem, where you assign 
> the deduction tags to the employee.
>
> Then, a payroll generation screen, to select/deselect the employees 
> for that generation.  Once the generation is complete, you print 
> checks, and post.
>
> While I'm sure that I have missed some things, that is the general 
> jist of what I had in mind.  Funny this came up just today, because I 
> actually started work last night  :)  I spent the last few days with 
> the concept, and figured that with winter coming, I would have 
> something by spring.  Anyone have an thoughts?
>
> Kent
>
>
>
> Vicki Reeves wrote:
>
>> I'm thinking that an international payroll might be possible if it 
>> included lots of ways to adjust withholdings.
>>
>> For example, choices for each withholding might include:
>> * will this formula operate against gross (stage 1) or against 
>> 'almost net' which would be the total after all stage 1 adjustments 
>> are completed?
>>
>> * will this withholding be a percentage, a set amount or a user 
>> defined formula? User defined formulas could allow for things like 
>> ((gross - 241) * 0.125)
>>
>> * is this withholding applied every payperiod or event triggered? 
>> Perhaps this could be used to allow for once a month withholdings 
>> when the payroll is prepared weekly, etc.
>>
>> * what will be the title of this withholding?
>>
>> * to what vendor and account will this withholding relate?
>>
>> Since the withholdings are very flexable and you would be able to 
>> setup as many as necessary, this should take care of the tax type 
>> requirements of wherever and allow for things like garnishments, 
>> insurance, etc.
>>
>> Something similar could be used to allow for additions such as 
>> payments of child care allowances, commissions, etc.
>>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out 
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> sql-ledger-users mailing list
> sql...@sq...
> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users
>
>

Re: [SL] Payroll

[Chris T. <ch...@me...>]

William Hamilton wrote:
<snip>

>
> It does seem to be a common request/requirement.  As I see it, Payroll 
> is so varied and complex when dealing wityh multiple countries and 
> their respective laws and taxes.  It would most likely take a lot of 
> effort to get to the level of internationalisation that SL has to 
> date.  This is not to say that it is an impossible task.
>
I will need payroll by January 1...  currently I am considering rolling 
my own solution.  I live in Washington State, so we have no state income 
tax and that simplifes things a bit.

I am neither an accountant nor an attourney, but I am willing to 
contribute what expertise I can to this project.

I agree that it is unlikely that a single person could make a generic 
payroll module which will be all things to all people due to the varying 
regulations...

> I suggest, if people want payroll, raise your hand and offer 
> time/expertise/resources/funds and see if we can make it happen.  I 
> would be happy to help out, if it were a realistic project.

>
> Could an alternative solution be the integration of a more specialised 
> application?
>
I would vote for this if there was a reasonably functional American 
payroll app that might integrate with SQL-Ledger.  Unfortunately there 
is not.  The apps I have been able to find are either proprietary or too 
immature to be used for production.  The closest application I have 
found is pcxpayroll but I have not had time to look at it in depth.

I actually don't think that it will be too hard to write something which 
can handle US federal payroll taxes...

The harder part is again to make something general enough to work.

I will attach my database schemas/functions when they are written for 
review on this list.

Best Wishes,
Chris Travers
Metatron Technology Consulting

> my 2c worth
>
> W
>

Re: [SL] Payroll

[Jeff V. <jv...@ch...>]

On Sun, 2004-10-10 at 23:06, Chris Travers wrote:
> William Hamilton wrote:
> <snip>
> 
> >
> > It does seem to be a common request/requirement.  As I see it, Payroll 
> > is so varied and complex when dealing wityh multiple countries and 
> > their respective laws and taxes.  It would most likely take a lot of 
> > effort to get to the level of internationalisation that SL has to 
> > date.  This is not to say that it is an impossible task.
> >
> I will need payroll by January 1...  currently I am considering rolling 
> my own solution.  I live in Washington State, so we have no state income 
> tax and that simplifes things a bit.
> 
> I am neither an accountant nor an attourney, but I am willing to 
> contribute what expertise I can to this project.
> 
> I agree that it is unlikely that a single person could make a generic 
> payroll module which will be all things to all people due to the varying 
> regulations...
> 
> > I suggest, if people want payroll, raise your hand and offer 
> > time/expertise/resources/funds and see if we can make it happen.  I 
> > would be happy to help out, if it were a realistic project.
> 

Just from my limited experience in doing payroll for one company, in the
US there are things like medicare, ssa, FUTA, SUTA, state income,
federal income, local taxes, and probably others I have missed. 
There are also withholdings for IRAs, stock purchase plans,
garnishments, medical savings plans, insurance plans, etc.

This will be a very complex issue even if only addressed for one
country, and making it multinational will be even more.

My approach would be to do this for one country at a time and then add
additional countries as the need arises and time permits.  A separate
payroll module for each country, with the processing output being
plugged into the GL is likely required in order to make it flexible
enough for all environments.

A complete knowledge of the requirements for each country/state will be
needed and the ability to do updates to the calculations (percentages,
etc.) as changes occur will be mandatory. 

> >
> > Could an alternative solution be the integration of a more specialised 
> > application?
> >
> I would vote for this if there was a reasonably functional American 
> payroll app that might integrate with SQL-Ledger.  Unfortunately there 
> is not.  The apps I have been able to find are either proprietary or too 
> immature to be used for production.  The closest application I have 
> found is pcxpayroll but I have not had time to look at it in depth.
> 
> I actually don't think that it will be too hard to write something which 
> can handle US federal payroll taxes...
> 
> The harder part is again to make something general enough to work.
> 
> I will attach my database schemas/functions when they are written for 
> review on this list.
> 
> Best Wishes,
> Chris Travers
> Metatron Technology Consulting
> 
> > my 2c worth
> >
> > W
> >

Re: [SL] Payroll

[Chris T. <ch...@me...>]

Jeff Vian wrote:

>
>Just from my limited experience in doing payroll for one company, in the
>US there are things like medicare, ssa, FUTA, SUTA, state income,
>federal income, local taxes, and probably others I have missed. 
>There are also withholdings for IRAs, stock purchase plans,
>garnishments, medical savings plans, insurance plans, etc.
>
>  
>
My draft should be about 50% there for the basic US payroll taxes.  But 
the basic the idea is there and could be expanded.

>This will be a very complex issue even if only addressed for one
>country, and making it multinational will be even more.
>
>My approach would be to do this for one country at a time and then add
>additional countries as the need arises and time permits.  A separate
>payroll module for each country, with the processing output being
>plugged into the GL is likely required in order to make it flexible
>enough for all environments.
>
>  
>
I think that the paycheck database schema I have written should be 
flexible enough to work in a wide variety of circumstances and 
environments.  this would also be useful if you need to print the check 
with the paycheck stub.

However, aside from that, I think that your approach is fairly similar 
to the one I am advocating.  I think one of the questions is how to make 
a flexible framework which can deductions for multiple countries 
simultaneously even (if necessary).  Perhaps if we all get started and 
exchange ideas, this will happen.

Best wishes,
Chris Travers
Metatron Technology Consulting

>A complete knowledge of the requirements for each country/state will be
>needed and the ability to do updates to the calculations (percentages,
>etc.) as changes occur will be mandatory. 
>
>  
>
>>>Could an alternative solution be the integration of a more specialised 
>>>application?
>>>
>>>      
>>>
>>I would vote for this if there was a reasonably functional American 
>>payroll app that might integrate with SQL-Ledger.  Unfortunately there 
>>is not.  The apps I have been able to find are either proprietary or too 
>>immature to be used for production.  The closest application I have 
>>found is pcxpayroll but I have not had time to look at it in depth.
>>
>>I actually don't think that it will be too hard to write something which 
>>can handle US federal payroll taxes...
>>
>>The harder part is again to make something general enough to work.
>>
>>I will attach my database schemas/functions when they are written for 
>>review on this list.
>>
>>Best Wishes,
>>Chris Travers
>>Metatron Technology Consulting
>>
>>    
>>
>>>my 2c worth
>>>
>>>W
>>>
>>>      
>>>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
>Use IT products in your business? Tell us what you think of them. Give us
>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
>http://productguide.itmanagersjournal.com/guidepromo.tmpl
>_______________________________________________
>sql-ledger-users mailing list
>sql...@sq...
>https://lists.sourceforge.net/lists/listinfo/sql-ledger-users
>
>
>  
>

Re: [SL] Payroll

[Santoken <san...@br...>]

Jeff Vian wrote:

> Just from my limited experience in doing payroll for one company, in the
> US there are things like medicare, ssa, FUTA, SUTA, state income,
> federal income, local taxes, and probably others I have missed. 
> There are also withholdings for IRAs, stock purchase plans,
> garnishments, medical savings plans, insurance plans, etc.

Yes...so, what you are saying is we start with a big number (gross 
income) and do some deductions (some will be percentages, others static 
numbers, etc.) and then we are left with a smaller number...that's the 
total of the paycheck, right?

> This will be a very complex issue even if only addressed for one
> country, and making it multinational will be even more.

Complex?  Hardly.  Look, doing payroll (as I and my company have been 
doing for 8+ years now) is nothing more than simple math.  You start 
with a big number, subtract some numbers or percentages from it, and the 
total left is the check amount.  Granted, there are other things 
happening in the background, but it's hardly more complicated than this.

> My approach would be to do this for one country at a time and then add
> additional countries as the need arises and time permits.  A separate
> payroll module for each country, with the processing output being
> plugged into the GL is likely required in order to make it flexible
> enough for all environments.

That type of approach only makes this module look more difficult than it 
really is.

> A complete knowledge of the requirements for each country/state will be
> needed and the ability to do updates to the calculations (percentages,
> etc.) as changes occur will be mandatory. 

Nope.  Currently, I use Peachtree for my payroll.  I haven't paid for 
their tax tables since I bought the software.  I have manually entered 
my deduction tables since then.

Look, payroll is not rocket science.  If you think it is, your 
accountant (or your payroll contractor) has kept you in the dark for far 
too long. Payroll is quite simple, as some have indicated by still using 
ledgers, pens, and adding machines.

There is NOTHING (as least here in Ohio) that has to be filed 
electronically.  I mean NOTHING. Not on any Federal, State or local.

Kent

Re: [SL] Payroll

[Michael R. <mc...@sa...>]

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Santoken" == Santoken  <san...@br...> writes:
    Santoken> Yes...so, what you are saying is we start with a big
    Santoken> number (gross income) and do some deductions (some will be
    Santoken> percentages, others static numbers, etc.) and then we are
    Santoken> left with a smaller number...that's the total of the
    Santoken> paycheck, right?

  Yes.
  There are additional transactions that often have to be made.

    >> This will be a very complex issue even if only addressed for one
    >> country, and making it multinational will be even more.

    Santoken> Complex?  Hardly.  Look, doing payroll (as I and my
    Santoken> company have been doing for 8+ years now) is nothing more
    Santoken> than simple math.  You start with a big number, subtract
    Santoken> some numbers or percentages from it, and the total left is
    Santoken> the check amount.  Granted, there are other things
    Santoken> happening in the background, but it's hardly more
    Santoken> complicated than this.

  Do it for one country/province first.
  Then let's do it for a second one.
  After which, we can make it table driven.

    Santoken> Look, payroll is not rocket science.  If you think it is,
    Santoken> your accountant (or your payroll contractor) has kept you
    Santoken> in the dark for far too long. Payroll is quite simple, as
    Santoken> some have indicated by still using ledgers, pens, and
    Santoken> adding machines.

    Santoken> There is NOTHING (as least here in Ohio) that has to be
    Santoken> filed electronically.  I mean NOTHING. Not on any Federal,
    Santoken> State or local.

  On a montly basis, not really in Ontario, either.
  At year end, if you have more than 75 employees then you have to
submit on disk. 

  Btw: speaking of submitting on disk, I have the Federal Canadian T2
corporate filing documentation. Alas, it is incomplete without a full
understanding of ANSI X.12. Anyone have that expertise and/or
documentation?

- --
]     "Elmo went to the wrong fundraiser" - The Simpson         |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mc...@xe...      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQWsOa4qHRg3pndX9AQH31wP+KWauLJCneT3MwgRv0+hDe/8UzuWk4dQa
TdnJunRxEiZSXW05XaHEN8yS5u8MNIb8f4P85VvISuylB1EnB41EruNhkLcsjGKu
uxSun4MAxTcZzs+HOHYzyQO/sXMVoljKn1B++h+jOWJCXWKIJyxFk/qYDhKK3E6/
98i+GUH00R0=
=aXz5
-----END PGP SIGNATURE-----

Re: [SL] Payroll

[Jeff V. <jv...@ch...>]

On Mon, 2004-10-11 at 17:06, Santoken wrote:
> Jeff Vian wrote:
> 
> > Just from my limited experience in doing payroll for one company, in the
> > US there are things like medicare, ssa, FUTA, SUTA, state income,
> > federal income, local taxes, and probably others I have missed. 
> > There are also withholdings for IRAs, stock purchase plans,
> > garnishments, medical savings plans, insurance plans, etc.
> 
> Yes...so, what you are saying is we start with a big number (gross 
> income) and do some deductions (some will be percentages, others static 
> numbers, etc.) and then we are left with a smaller number...that's the 
> total of the paycheck, right?
> 
> > This will be a very complex issue even if only addressed for one
> > country, and making it multinational will be even more.
> 
> Complex?  Hardly.  Look, doing payroll (as I and my company have been 
> doing for 8+ years now) is nothing more than simple math.  You start 
> with a big number, subtract some numbers or percentages from it, and the 
> total left is the check amount.  Granted, there are other things 
> happening in the background, but it's hardly more complicated than this.
> 

The complexity is not in doing the math, but in making the interface
easy to use and easy to update values.  Even worse is the need to make
it intuitive on "how to get there from here."  Many (probably most)
users don't care about the backend, as long as the interface is friendly
and easy to use and the results are accurate.  

As I see it, the hardest programming part will be in defining what
deductions apply to which employees and when. Then making the interface
and automation handle that correctly with suitable reports and data
entry screens.

The interface and making it flexible enough to encompass many different
locales  will require some basic knowledge of what is needed in each
locale.  Once the requirements are known the actual implementation
should be fairly straight forward and similar to what Chris is already
working on.

> > My approach would be to do this for one country at a time and then add
> > additional countries as the need arises and time permits.  A separate
> > payroll module for each country, with the processing output being
> > plugged into the GL is likely required in order to make it flexible
> > enough for all environments.
> 
> That type of approach only makes this module look more difficult than it 
> really is.
> 

Not really - divide and conquer.  Once it is done for one locale, the
modifications to fit additional areas become simple and in many cases
obvious.

> > A complete knowledge of the requirements for each country/state will be
> > needed and the ability to do updates to the calculations (percentages,
> > etc.) as changes occur will be mandatory. 
> 
> Nope.  Currently, I use Peachtree for my payroll.  I haven't paid for 
> their tax tables since I bought the software.  I have manually entered 
> my deduction tables since then.
> 

You may the updates to the taxes tables manually, but do you have all
the knowledge of what is required in all situations?  And do you know
how to make the software do what peachtree does in the background?  If
so, please collaborate and help produce the modules to make this happen.

> Look, payroll is not rocket science.  If you think it is, your 
> accountant (or your payroll contractor) has kept you in the dark for far 
> too long. Payroll is quite simple, as some have indicated by still using 
> ledgers, pens, and adding machines.
> 
> There is NOTHING (as least here in Ohio) that has to be filed 
> electronically.  I mean NOTHING. Not on any Federal, State or local.
> 
> Kent
> 

Exactly, but reports will have to be designed to provide the values
needed for you to fill in the periodic reports that do need to be filed
- monthly, quarterly, or whenever.

Re: [SL] Payroll

[James N. <Jne...@we...>]

Hi all,

Not having much experience with payroll systems, I'm not able to add 
much to the discussions, but from an interface perspective I agree that 
the interface will be vital to the system.

One thing that would definitely make it easy to use is the ability to be 
able to copy a previous payroll transaction for an employee. For 
salaried employees whose Gross and Net pay don't change, it would be a 
simple task to process these transactions.

For contract/waged staff where the capturing of time sheets needs to be 
handled, I suggest that it is a manual process where someone will have 
to tally the hours, and manually create the deductions, etc.

I'm not an accountant, but here in South Africa the requirements seem to 
be simpler than in the US.
We have Tax that is deducted by the employer according to a sliding 
scale (PAYE),
an unemployment fund payment that is paid by both the employer and the 
employee, also based on a scale
and then other deductions such as retirement funds, medical aids, etc

We don't have State taxes or Federal taxes.

Other items that I've experienced on the payroll system is the ability 
to pay off money lent to you by the organisation. This is probably 
outside the scope of a payroll system, but may be nice for those 
instances where it is required.



Our small organisation would be able to function much more easily with 
the ability to capture the Gross Pay, manually insert the deductions 
(PAYE, UIF, etc) and then print out a payslip to present to the employee 
- Currently we do with with a spreadsheet template and we just change 
the date :)

Once one transaction has been saved, we can always copy that payroll 
slip for the next month and save a ton of time in calculating out TAX debt.



I have no experience with a larger organisation (25+), maybe the 
requirements are very different.

Kind Regards,
James



Jeff Vian wrote:

>On Mon, 2004-10-11 at 17:06, Santoken wrote:
>  
>
>>Jeff Vian wrote:
>>
>>    
>>
>>>Just from my limited experience in doing payroll for one company, in the
>>>US there are things like medicare, ssa, FUTA, SUTA, state income,
>>>federal income, local taxes, and probably others I have missed. 
>>>There are also withholdings for IRAs, stock purchase plans,
>>>garnishments, medical savings plans, insurance plans, etc.
>>>      
>>>
>>Yes...so, what you are saying is we start with a big number (gross 
>>income) and do some deductions (some will be percentages, others static 
>>numbers, etc.) and then we are left with a smaller number...that's the 
>>total of the paycheck, right?
>>
>>    
>>
>>>This will be a very complex issue even if only addressed for one
>>>country, and making it multinational will be even more.
>>>      
>>>
>>Complex?  Hardly.  Look, doing payroll (as I and my company have been 
>>doing for 8+ years now) is nothing more than simple math.  You start 
>>with a big number, subtract some numbers or percentages from it, and the 
>>total left is the check amount.  Granted, there are other things 
>>happening in the background, but it's hardly more complicated than this.
>>
>>    
>>
>
>The complexity is not in doing the math, but in making the interface
>easy to use and easy to update values.  Even worse is the need to make
>it intuitive on "how to get there from here."  Many (probably most)
>users don't care about the backend, as long as the interface is friendly
>and easy to use and the results are accurate.  
>
>As I see it, the hardest programming part will be in defining what
>deductions apply to which employees and when. Then making the interface
>and automation handle that correctly with suitable reports and data
>entry screens.
>
>The interface and making it flexible enough to encompass many different
>locales  will require some basic knowledge of what is needed in each
>locale.  Once the requirements are known the actual implementation
>should be fairly straight forward and similar to what Chris is already
>working on.
>
>  
>
>>>My approach would be to do this for one country at a time and then add
>>>additional countries as the need arises and time permits.  A separate
>>>payroll module for each country, with the processing output being
>>>plugged into the GL is likely required in order to make it flexible
>>>enough for all environments.
>>>      
>>>
>>That type of approach only makes this module look more difficult than it 
>>really is.
>>
>>    
>>
>
>Not really - divide and conquer.  Once it is done for one locale, the
>modifications to fit additional areas become simple and in many cases
>obvious.
>
>  
>
>>>A complete knowledge of the requirements for each country/state will be
>>>needed and the ability to do updates to the calculations (percentages,
>>>etc.) as changes occur will be mandatory. 
>>>      
>>>
>>Nope.  Currently, I use Peachtree for my payroll.  I haven't paid for 
>>their tax tables since I bought the software.  I have manually entered 
>>my deduction tables since then.
>>
>>    
>>
>
>You may the updates to the taxes tables manually, but do you have all
>the knowledge of what is required in all situations?  And do you know
>how to make the software do what peachtree does in the background?  If
>so, please collaborate and help produce the modules to make this happen.
>
>  
>
>>Look, payroll is not rocket science.  If you think it is, your 
>>accountant (or your payroll contractor) has kept you in the dark for far 
>>too long. Payroll is quite simple, as some have indicated by still using 
>>ledgers, pens, and adding machines.
>>
>>There is NOTHING (as least here in Ohio) that has to be filed 
>>electronically.  I mean NOTHING. Not on any Federal, State or local.
>>
>>Kent
>>
>>    
>>
>
>Exactly, but reports will have to be designed to provide the values
>needed for you to fill in the periodic reports that do need to be filed
>- monthly, quarterly, or whenever.
>
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
>Use IT products in your business? Tell us what you think of them. Give us
>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
>http://productguide.itmanagersjournal.com/guidepromo.tmpl
>_______________________________________________
>sql-ledger-users mailing list
>sql...@sq...
>https://lists.sourceforge.net/lists/listinfo/sql-ledger-users
>
>  
>

Re: Re: [SL] Payroll

[William H. <wi...@th...>]

Santoken wrote:
> Jeff Vian wrote:
> 
>> Just from my limited experience in doing payroll for one company, in the
>> US there are things like medicare, ssa, FUTA, SUTA, state income,
>> federal income, local taxes, and probably others I have missed. There 
>> are also withholdings for IRAs, stock purchase plans,
>> garnishments, medical savings plans, insurance plans, etc.
> 
The New Zealand tax dept has published guidelines for software developers
http://www.ird.govt.nz/payrolldev/payrollspec2004.pdf
http://www.ird.govt.nz/payrolldev/faqs.html
http://www.ird.govt.nz/payrolldev/changestoholidayact.html
http://www.ird.govt.nz/payrolldev/newoptionforsscwt.html

It provides reasonable guidance as far as NZ is concerned.  I am not 
sure on how other countries work out taxes etc.  NZ does not have States 
only one taxing body realy.  Not sure how useful it is for anyone.

> 
> Yes...so, what you are saying is we start with a big number (gross 
> income) and do some deductions (some will be percentages, others static 
> numbers, etc.) and then we are left with a smaller number...that's the 
> total of the paycheck, right?
> 
>> This will be a very complex issue even if only addressed for one
>> country, and making it multinational will be even more.
> 
> 
> Complex?  Hardly.  Look, doing payroll (as I and my company have been 
> doing for 8+ years now) is nothing more than simple math.  You start 
> with a big number, subtract some numbers or percentages from it, and the 
> total left is the check amount.  Granted, there are other things 
> happening in the background, but it's hardly more complicated than this.
> 
>> My approach would be to do this for one country at a time and then add
>> additional countries as the need arises and time permits.  A separate
>> payroll module for each country, with the processing output being
>> plugged into the GL is likely required in order to make it flexible
>> enough for all environments.
> 
> 
> That type of approach only makes this module look more difficult than it 
> really is.
> 
>> A complete knowledge of the requirements for each country/state will be
>> needed and the ability to do updates to the calculations (percentages,
>> etc.) as changes occur will be mandatory. 
> 
> 
> Nope.  Currently, I use Peachtree for my payroll.  I haven't paid for 
> their tax tables since I bought the software.  I have manually entered 
> my deduction tables since then.
> 
> Look, payroll is not rocket science.  If you think it is, your 
> accountant (or your payroll contractor) has kept you in the dark for far 
> too long. Payroll is quite simple, as some have indicated by still using 
> ledgers, pens, and adding machines.
> 
> There is NOTHING (as least here in Ohio) that has to be filed 
> electronically.  I mean NOTHING. Not on any Federal, State or local.
> 
> Kent
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> sql-ledger-users mailing list
> sql...@sq...
> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users
> 


-- 
William Hamilton

TheVirtual Ltd                  Voice:  +64 4 801 5830
Wellington, New Zealand         Mobile: +64 21 650 936
wi...@th...        www.thevirtual.co.nz
Making Virtual Business Reality

Re: Re: [SL] Payroll

[<ri...@sy...>]

It seems that the most reasonable way to handle this is to keep it as
basic as possible and make NO assumptions.

As someone else said earlier (too lazy to go look up who) :) it is just
simple math.

So if you start with Gross Pay, you should be able to define your own
deductions as follows:

Payroll Account (where the G/L transfers to the various taxing
authorities are credited)
Deduction Name
Taxing Authority (where the money is going; it doesn't have to be a
"tax")
Liability Account (the "Payables" account the deduction goes into until
it is paid to the taxing authority)
Deduction formula (Percentage of Gross, Percentage of Net, Fixed amount,
Custom)
Order (Setting application order of each deduction might have
significance)

This type of elemental system (with lots of changes for stuff I haven't
thought of I'm sure) will allow for the greatest flexibility for all
countries.

Basically ANY type of deduction can be defined and applied--tax, IRA,
stock purchase/options, insurance, etc.

Just my 2c

Rich C.

Re: [SL] Payroll

[Santoken <san...@br...>]

richc@sysupport wrote:

> It seems that the most reasonable way to handle this is to keep it as
> basic as possible and make NO assumptions.

Yes, just start with sometime..anything.  Basically, what I originally 
had in mind was a glorified spread sheet.

> As someone else said earlier (too lazy to go look up who) :) it is just
> simple math.

Finally, someone on the same wave as me.

> So if you start with Gross Pay, you should be able to define your own
> deductions as follows:
> 
> Payroll Account (where the G/L transfers to the various taxing
> authorities are credited)
> Deduction Name
> Taxing Authority (where the money is going; it doesn't have to be a
> "tax")
> Liability Account (the "Payables" account the deduction goes into until
> it is paid to the taxing authority)
> Deduction formula (Percentage of Gross, Percentage of Net, Fixed amount,
> Custom)
> Order (Setting application order of each deduction might have
> significance)

Yes!!! Yes!!! Exactly!!!

> This type of elemental system (with lots of changes for stuff I haven't
> thought of I'm sure) will allow for the greatest flexibility for all
> countries.

Acutally, since it is 'frilless' it will be non-country specific.  In 
theory, it will be general enough that each user could tailor it to 
his/her needs or their country's/state's needs.

> 
> Basically ANY type of deduction can be defined and applied--tax, IRA,
> stock purchase/options, insurance, etc.

Ah, yes, deduction actually means "an amount that is or may be deducted" 
or subtracted.  So, as I originally said, you start with a larger number 
(gross pay), subtract some stuff from it (deductions), and the remaining 
amount you write a check for (net pay).

Payroll, IMHO, is far simplier than many other portions of accounting. 
There really is no reason at all to make it anymore complicated than 
what it really is.

Kent

[SL] Re: Payroll

[Matthew P. <mp...@he...>]

On Tue, Oct 12, 2004 at 08:27:14PM -0400, Santoken wrote:
> Payroll, IMHO, is far simplier than many other portions of accounting.=20
> There really is no reason at all to make it anymore complicated than=20
> what it really is.

The problem is that what you think of as "payroll" and what users think of
as "payroll" don't have much to do with each other.  What users think of as
payroll includes the money side of it, as well as tracking the rest of the
weird bits of info you need to worry about when doing HR type stuff, like
tracking leave, historical payrates, and all of that sort of thing.

A general set of rules to do the calculations would be a good start,
however, and should be something you can define in a general (XML or SQL
statements) fashion for distribution within a tax jurisdiction.  Just don't
kid yourself that you'll be able to sell it to the businessman-on-the-street
as a payroll app -- they don't consider it as such.

- Matt

--=20
"[the average computer user] has been served so poorly that he expects his
system to crash all the time, and we witness a massive worldwide
distribution of bug-ridden software for which we should be deeply ashamed."
		-- Edsger Dijkstra

Re: [SL] Re: Payroll

[Chris T. <ch...@me...>]

Matthew Palmer wrote:

> The problem is that what you think of as "payroll" and what users think of
>
>as "payroll" don't have much to do with each other.  What users think of as
>payroll includes the money side of it, as well as tracking the rest of the
>weird bits of info you need to worry about when doing HR type stuff, like
>tracking leave, historical payrates, and all of that sort of thing.
>
>  
>
Getting *something* working for being able to do payroll with an 
SQL-ledger installation is more important than the rest of this...  I 
would argue, however, that vacation pay *should* be accreued as it is 
earned by the employee, though I am not a CPA, and if we can't get that 
part working at first, it is no big deal (I am very sure it will be 
added later).

Paid and unpaid leave tracking could also be added as a separate HR 
extension.  These are not, in my mind accrued but rather used under 
certain circumstances.  Eventually, one could even add a timecard app to 
integrate these things.

Regarding historical rates of pay, that could be generated in reports 
later if someone wants it as long as it is stored in the database.  IMO, 
one of the nice things about an SQL-based solution is that your 
reporting does not need to be limited to your application.

>A general set of rules to do the calculations would be a good start,
>however, and should be something you can define in a general (XML or SQL
>statements) fashion for distribution within a tax jurisdiction.  Just don't
>kid yourself that you'll be able to sell it to the businessman-on-the-street
>as a payroll app -- they don't consider it as such.
>  
>

Maybe not, but it will vastly increate my ability to sell SQL-Ledger to 
customers as an accounting solution.  And if these customers need 
additional extensions they can pay someone to develop them.  This is the 
wonderful thing about open source.  Customers can pay for the 
development of features they really need, and when you consider the base 
price they often still get a deal :-)

Best Wishes,
Chris Travers
Metatron technology consulting

[SL] SL Configuration Questions - multiple businesses

[Roland P. <Ro...@Qu...>]

I am attempting to set up SL to record my finances.  I have two small businesses which
because they are sole proprietorships are really just subsets of my personal finances 
and US tax return.  What is the best way to configure SL to support my needs?  

(I have purchased the SL support & manual but it has very little information in using 
SL Departments vs SL Projects)

-------------------
Structure 1:


        Dataset 1
          -Dept A - Personal, non business
          -Dept B - Business 1
          -Dept C - Business 2
         where everything is contained in either Departments A, B, or C

-------------------
Structure 2:


        Dataset 2
          -Dept A - Business 1
          -Dept B - Business 2
         where all personal accounts are not defined to be in a Department

-------------------
Structure 3:


          Dataset 3 - Personal
          Dataset 4 - Business 1
          Dataset 5 - Business 2
        where all datasets are independent



Questions:

1) Is anyone using SL Departments?

2) Is this a reasonable way to use SL Departments?

3) Should I be using Projects instead?

4) What are the advantages and disadvantages in the above structures?

5) Which structure should I use?

6) Is there a better structure which I have not considered?

7) Business 1 may be converted to a corporation in about 2-3 years.  Should this effect
what structure I choose now?


--Roland

Re: [SL] SL Configuration Questions - multiple businesses

[James P. K. I. <jk...@lo...>]

I would recommend that you completely seperate all three. As business A
and B are not really subsets of either, having them organized in
departments is not accurate.

While it is easy to lump all business assets in as personal ones for a
sole prop, as you mentioned, the plan is to convert one to a corp in the
future. Having the accounting already a standalone function makes the
initial setup much easier.

BTW: When you look at doing the corp transition, check out the process
of doing an LLC. It's the protection of a corporation with the structure
of a sole prop. Most states have it now. The federal IRS (in the US)
treats a single owner LLC as a sole prop for tax purposes so you fil it
just as before. It's easy to convert to a mutiple ownership LLC as it is
treated just like a partnership. Conversion to an S-corp is possible as
well by an assignment of shares relative to the % ownership of each LLC
member.

On Mon, 2004-10-11 at 02:33, Roland Porth wrote:
> I am attempting to set up SL to record my finances.  I have two small bus=
inesses which
> because they are sole proprietorships are really just subsets of my perso=
nal finances=20
> and US tax return.  What is the best way to configure SL to support my ne=
eds? =20
>=20
> (I have purchased the SL support & manual but it has very little informat=
ion in using=20
> SL Departments vs SL Projects)
>=20
> -------------------
> Structure 1:
>         Dataset 1
>           -Dept A - Personal, non business
>           -Dept B - Business 1
>           -Dept C - Business 2
>          where everything is contained in either Departments A, B, or C
> -------------------
> Structure 2:
>         Dataset 2
>           -Dept A - Business 1
>           -Dept B - Business 2
>          where all personal accounts are not defined to be in a Departmen=
t
> -------------------
> Structure 3:
>           Dataset 3 - Personal
>           Dataset 4 - Business 1
>           Dataset 5 - Business 2
>         where all datasets are independent
> Questions:
>=20
> 1) Is anyone using SL Departments?
>=20
> 2) Is this a reasonable way to use SL Departments?
>=20
> 3) Should I be using Projects instead?
>=20
> 4) What are the advantages and disadvantages in the above structures?
>=20
> 5) Which structure should I use?
>=20
> 6) Is there a better structure which I have not considered?
>=20
> 7) Business 1 may be converted to a corporation in about 2-3 years.  Shou=
ld this effect
> what structure I choose now?
>=20
>=20
> --Roland
>=20
> !DSPAM:416a32f385671544364091!
--=20
James P. Kinney III          \Changing the mobile computing world/
CEO & Director of Engineering \          one Linux user         /
Local Net Solutions,LLC        \           at a time.          /
770-493-8244                    \.___________________________./
http://www.localnetsolutions.com

GPG ID: 829C6CA7 James P. Kinney III (M.S. Physics)
<jk...@lo...>
Fingerprint =3D 3C9E 6366 54FC A3FE BA4D 0659 6190 ADC3 829C 6CA7