Additional functionality for Employee salary

[Derek Atkins]

Hi,

Valdis Vītoliņš <valdis.vitolins at odo.lv> writes:

> Thanks Derek for detailed answer!
> You confirmed my suspicions about 3rd option as most useful.
>
> To make work with salaries more convenient,
> Transaction report (or ~ similar) should allow to search/filter by transaction
> description (i.e. employee).

Well, I would suggest writing a new report (sort of how I wrote the
owner and aging reports for customers/vendors).  Yes, you could probably
use the transaction report to get what you want, but I would think a
specific "salary report" would be an appropriate addition.  Also, if you
use ancillary data then you might need to write something new to read
that data out.

> Wouldn't it easy and useful addition?

Useful?  Absolutely.  EASY?  ....  

> Valdis

-derek

>     Hi,
>     
>     Valdis Vītoliņš <valdis.vitolins at odo.lv> writes:
>     
>     > Investigating employee expense vouchers for salaries seems not
>     > sufficient.
>     
>     That's because employee expense vouchers are NOT for salaries, they are
>     for employee expense reimbursements.  They are not and never were
>     designed for salaries.
>     
>     Payroll computation is a HARD THING to get right.  It's not just as
>     simple as adding a payroll tax table.  You have to deal with different
>     kinds of withholdings, limits, pre-tax and post-tax, tax-on-tax, etc.
>     And it varies from locale to locale.
>     
>     TRUST me, you do NOT want to try to squeeze that into the employee
>     expense vouchers.
>     
>     > To use them for Latvian legislation each entry should be with tax
>     > similarly to Invoice,
>     > and vouchers should be easily duplicated or scheduled.
>     
>     Maybe in Latvia.  That definitely wouldn't fly in the USA.
>     
>     > As vouchers are similar to invoices it seems to be easily
>     > implemented/fixed.
>     > Duplication/scheduling could be harder work.
>     
>     Actually, duplication/scheduling is MUCH MUCH easier than fixing the tax
>     withholding problem!
>     
>     > Workaround for current implementation would be:
>     > 1. separate entries for taxes (not optimal as requires more manual
>     > calculations and typing work),
>     > 2. treating employees as  "Customers" (can use tax table, but still
>     > can't duplicate/schedule),
>     > 3. not use invoices/vouchers at all and use split transactions (can be
>     > easily duplicated and scheduled, but is hard to print as Salary list).
>     >
>     > Any thoughts?
>     > Valdis
>     
>     You've only touched the tip of the iceburg in adding Salary to GnuCash.
>     You need a complete framework in order to plug in all the various taxes,
>     limits, and withholdings for various locales.
>     
>     Also, you need to keep in mind that some places have payroll taxes on
>     top of the salaries.  For example, in the USA there is a 6.9% Social
>     Security Tax that is withheld from the pay (up to an annual total of
>     something like 100,000/year -- once you reach the salary cap this tax no
>     longer applies).  But on top of that the employer owes another 6.9%
>     which does NOT come out of the salary, but instead is owed by the
>     employer!
>     
>     Then of course there are pre-tax deductions for things like healthcare
>     insurance.  So you have to substract those premiums before you compute
>     the taxes.  But of course there are also post-tax deductions, where you
>     compute the tax and THEN make the deduction (for example, life insurance
>     premiums).  However this is not necessarily true for ALL taxes; some
>     withholdings can apply differently as pre-tax or post-tax to different
>     taxes.
>     
>     Honestly, I can't even imagine how you'd fit these rules into the
>     expense vouchers!
>     
>     Personally I think you should do something like #3, but you can still
>     create a Salary List as part of the ancillary information in the invoice
>     itself.  Of course, printing out per-user annual to-date totals might be
>     challenging, but again you could do it with ancillary data similar to
>     how customers and vendors can share a single A/R or A/P account.
>     
>     But I think overloading the employee expense vouchers is definitely NOT
>     the right thing.
>     
>     > gnucash-devel mailing list
>     > gnucash-devel at gnucash.org
>     > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>     
>     -derek
>

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available