sql-ledger-users

Re: [SL] SL Configuration Questions - multiple businesses

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

Thanks, James,

We will be strongly considering an LLC business structure so keeping
that business separate makes sense. 
 
I still have some questions regarding our personal configuration.   Has
anyone used the department or project
designation of SL?  When would you recommend using each.   What are
their strengths ans weaknesses?

Roland

On Mon, 2004-10-11 at 05:21, James P. Kinney III wrote:

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



> 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 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
> > 
> > !DSPAM:416a32f385671544364091!

Re: [SL] Payroll

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

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


>>>>> "Chris" == Chris Travers <ch...@ve...> writes:
    Chris> I think that the paycheck database schema I have written
    Chris> should be flexible enough to work in a wide variety of
    Chris> circumstances and environments.  this would also be useful if
    Chris> you need to print the check with the paycheck stub.

  It would be nice to have all the deductions on the stub :-)

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

  I am willing to test anything (I'm the only actual employee of
sandelman.ca, everyone else are contracted, and do their own thing).
  I'm also happy to hack things in minor ways, but I have no time to
lead.

- --
]     "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

iQCVAwUBQWsSNoqHRg3pndX9AQGkAgQA2QoOK9graDu9B3cSwbkjp4w/4eEETIXl
qU8MPmIzUZu/rqliu64c2AEYnwux9wgaZuioM1IKU56WHCPvZhRv4ZxG9nHsZZ0v
ABsytuoFllhwx3uKhMIUNCxBnaj9hbsOUXPWcRgbVuABrpOr4P01jWTOFM+CGhpE
sw9atPNEF2o=
=eoDx
-----END PGP SIGNATURE-----

Re: [SL] Payroll

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

On Mon, 2004-10-11 at 18:07, Michael Richardson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> 
> >>>>> "Chris" == Chris Travers <ch...@ve...> writes:
>     Chris> I think that the paycheck database schema I have written
>     Chris> should be flexible enough to work in a wide variety of
>     Chris> circumstances and environments.  this would also be useful if
>     Chris> you need to print the check with the paycheck stub.
> 
>   It would be nice to have all the deductions on the stub :-)
> 
>     Chris> However, aside from that, I think that your approach is
>     Chris> fairly similar to the one I am advocating.  I think one of
>     Chris> the questions is how to make a flexible framework which can
>     Chris> deductions for multiple countries simultaneously even (if
>     Chris> necessary).  Perhaps if we all get started and exchange
>     Chris> ideas, this will happen.
> 
>   I am willing to test anything (I'm the only actual employee of
> sandelman.ca, everyone else are contracted, and do their own thing).
>   I'm also happy to hack things in minor ways, but I have no time to
> lead.
> 


That leads to another issue.  Payroll for employees is one thing, but
for those who are contractors, filing of 1099s in the US is another
issue similar to the W2 and should be contained as well.

Re: [SL] Payroll

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

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.  

Making the interface easy to use?  What exactly do you mean there? 
Again, this is only payroll, there is no need to make it more 
complicated than it already is not.  Look, starting with only the basics 
and keeping it at that is all that is needed.  You offer an employee 
maint. screen, a deduction maint. screen, a payroll generation screen 
and a payroll report screen.  What more is needed?

Of course most users don't care about the backend...they want a software 
package that works...that's all.  Frankly, they just have a job to do 
and when that's done, they go on with their lives.  Most users of an 
office package could give a whit how it gets the job done, they just 
want the job done, done right, and done easily.

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

Again, applying the defined deductions (defined in the deduction screen) 
to the appropriate employees can be easily maintained in the employee 
maint. screen I proposed.

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

The only reason it would need to be flexible enough is if it becomes 
over-complicated.  If it is kept simple enough to allow the user to 
create, enter, and maintain the deduction tables, then specify which 
employees those deductions apply to or which deductions apply to which 
employees.  No point it making it so structured and complicated that the 
package I use a person in Oz or UK can't use it.  Essentially, the core 
of payroll is the same everywhere, you start with gross, deduct, end 
with net.  Again, payroll is simple math.

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

Again, why make it so difficult and complicated that what works here 
won't work there.  I guess that what I'm saying is that the procedure 
that (if I did payroll manually) not really any different than the way 
the do payroll in Canada, Europe, etc.  So, why not make the module work 
the same way?  To approach payroll in any other fashion is insane!  :)

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

Knowledge of what is required in all situations?  What do you mean by 
situations?  Again, you start with gross pay, make deductions, you are 
left with net pay...you write the check.  Regarding whether "I know how 
to make the software do what peachtree does in the background," I do 
not.  I am not a coder, as I said in an earlier email...I dabble with 
perl, sql, C, etc.  However, what little bit of dabble I do, I can tell 
you that what is needed for a payroll module is far from complex.

Regarding your last statement, about collaborating and making this 
happen, at first I took that as a personal slam and a 'put your money 
where your mouth is' type statement.  Then, I got to thinking about it. 
  If you'll notice, I started the heated debate about payroll and I've 
been the one keeping it going, continuing to debate my point.  I'm not a 
programmer, I'm a computer hack and a small business owner.  I don't 
have the time to devote learning perl enough to create a payroll module. 
  I don't have to, I pay money to people that do...you can ask Dieter. 
However, SL has everything that I need...save for payroll.  SL has 
matured to the point that it needs to offer a payroll module...that's 
just the way it is.  Anyone that says different, or offers a crude 
workaround, is blind to the potential of SL.  Besides, do you really 
want a hack to come along and make a module and show up all the 
programmers on this list?  :)

Kent

Re: [SL] Payroll

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

On Tue, 2004-10-12 at 21:11 -0400, Santoken wrote:
>   Besides, do you really=20
> want a hack to come along and make a module and show up all the=20
> programmers on this list?  :)

No. But I _would_ like to see the hack generate some screen shots of the
proposed UI with some basic docs on how the payroll system is supposed
to be used (click here, now enter..., etc).

The issue I keep runing up on with this is (and I do program in perl)
that the UI is the sticking point. Yes, the math for most business stuff
is mastered by the end of the 6th grade here in the US.=20

So my challenge is this:  Look at the customer and vedor data entry
screen that already exist in SL. Using that as a design model, generate
a layout for the entry and managment screens as you proposed that would
also include form labels that the user sees. Keep in mind that every
form box will ultimately have to be an entry in a database. So the "on
the fly" random deductions are not really an option (coding new database
column generation based on user input is a security no-no). Also keep in
mind that all deductions must be eventually printable individully on a
paycheck for each employee.

Hmm. We may need a new mailing list : sql-ledger-payroll-devel.