Robert, Geert,
On Tue, 2018-11-27 at 07:46 -0500, Robert Heller wrote:
> At Tue, 27 Nov 2018 10:13:37 +0100 Geert Janssens
> <geert.gnuc...@kobaltwit.be> wrote:
>
> >
> > Op dinsdag 27 november 2018 00:17:06 CET schreef John Ralls:
> > > > On Nov 27, 2018, at 6:35 AM, Stephen M. Butler <kg...@arrl.net> wrote:
> > >
> > > The other big issue is that your description of the various modules in a
> > > business accounting system is for *big* business. That’s not what GnuCash
> > > is designed for and not what the current development team is interested
> > > in,
> > > never mind (as you point out) capable of supporting. There are a several
> > > open-source projects in that space, search the web for “foss erp” to find
> > > them. GnuCash is focussed on very small businesses (as in sole
> > > proprietorships) and individuals.
> >
> > I mostly agree, yet I think many small businesses would benefit from a
> > simple
> > inventory management system. My own business would have for that matter.
> >
> > And while inventory is not strictly accounting it would make gnucash a
> > viable
> > option to quite a few extra small businesses. So I'm in two minds with
> > respect
> > to inventory support and have been for quite a while. In the past I
> > envisioned
> > implementing it myself (reusing certain parts of the existing code and
> > adding
> > the missing bits) but for various reasons shifted to other priorities. If
> > someone would step in to write it, I would still support the effort though.
>
> "Inventory Management" is so close to managing stocks, that it should be
> possible to implement with bit of recycling/repurposing the existing code for
> stocks... One can *almost* fake it now by considering physical inventory as
> if it were a stock and using a "stock" type account.
I too have looked at the use of lots in the stock management as a possible basis
of a basic inventory system. A full cost management system as used in a
manufacturing business would likely be out of scope for GnuCash but a system
for
managing inventory that is bought and sold would look very similar. The main
addition
would probably be a product table possibly using KVPs for product attributes.
>
> >
> > Payroll on the other hand is not my cup of tea and likely more targeted at
> > larger businesses.
>
> Yes, a full fledged Payroll module would likely to be major bit of coding, but
> maybe a simplified small scale Payroll module *might* be of use to smaller
> businesses (say < 5 employees).
This a brief illustrative description of what a payroll system has to cover in
Australia. I am sure to have left
something out and some things may have changed since I last employed anyone
(2004) or was employed (2013). Perhaps
gathering similar descriptions for at least some of the major jurisdictions
e.g. US, EU, UK GnuCash has to deal with may
provide a better outline of the scope of such an undertaking and how much is
common across various jurisdictions and
what it might be possible to address within Gnucash.
I had originally envisaged a separate payroll program which exported the
appropriate accounting information to GnuCash
(OFX etc) but maintained its own internal database and records which were
payroll specific.
With a payroll system, the number of employees is not really a factor in the
coding effort as you have to have the same
basic facilities in place to deal with a single employee or 100. The only thing
that differs is the size of the employee
database/file not the complexity of its content. I don't think that there is
such a thing as a simple payroll system in
most juridictions.
The most difficult part is setting up a system for deductions of income tax,
superannuation etc. and dealing with the
different conditions for casual, part -time and full time staff. You also have
to track employee benefits like annual
leave, sick leave, parental leave, long term service leave etc, where these
often accumulate on the basis of total hours
worked.
When I used MYOB for calculating my staff salaries I entered the appropriate
hourly rates (set by industrial agreements
and industrial court decisions most of which are now available on-line) and
whether casual/part-time/fulltime for each
individual in an employees record. Most of my staff were casual or part time at
the time.
Our tax office provided online calculators based on the total weekly wage for
tax deductions. A lot of these
calculations were based on a table of thresholds and % rates which applied
between each threshold and these and the
calculation methodology were available on the ATO website so they can be
included in software. There were also additions
to the tax based on an income threshold for basic medicare coverage which also
had an additional levies for those who
did not have private hospital insurance.
There were also compulsory superannuation deductions (over a very low
threshold) for all employees at a fixed % of gross
pay. (All employees also had to be covered by compulsory insurance cover for
workplace injury and death. This was
generally in the employers overheads however and not charged to employees.)
A payroll system also has to deal with overtime rates and in Australia at
least, penalty rates normally expressed as a
multiplier of normal pay rates, which applied for work on Saturdays, Sundays
and public holidays. They also included
Time off in Lieu provisions for overtime and penalty rates. A further
complication is that these penalty rates were part
of industrial awards and agreements for specific occupations and sometimes
varied considerably between specific
occupations so all this was all employee specific if you employed people in
severl occupational categories and had to be
tied to each employee's record.
Other common deductions sometimes handled by an employer included:
union fees for union members,
private health insurance premiums,
private superannuation.
other life income protection etc insurance premiums.
These have probably been simplified since most employers now pay net pay
directly to an employees bank account and it is
now much easier for an employee to organize deductions themselves.
To calculate the payroll, you entered the hours worked by the employee in each
category of employment (normal
hours/overtime hours, various penalty rate categories and the gross pay, tax to
be withheld and the deductions to a
variety of payees were calculated. My bank business account had portal
provisions where I could upload a file detailing
the payments to the employees and various bodies which was then processed
electronically by the bank - for which I paid
a fee naturally. MYOB could create that file (which had to be massaged in Excel
for import to the bank) and /or access
that portal directly if you paid them an extra amount for their electronic
banking module.
This will not be not to implement in a way that can deal with differences in
the rules and types of calculations used in
different jurisdictions. Some payments were to our federal government and
others wer to state governments depending on
which administered a particular aspect.
Some calculations depended totally on gross income but some were based on
taxable income. The latter is difficult if the
employee has more than one employer. Often one was specified as the main
employer and all other employers were required
to extract income tax at the maximum marginal rate.
The other bugbear is maintenance. Much of this information changes over time,
usually minor adjustments to pay rates,
but sometimes modifications to thresholds and occasionally the complete method
of calculation. As an employer you have
to stay on top of those changes. I was union friendly and most of my employees
were members of a union I had been a
member of and they provided updates on changes, self interest but it reduced my
workload. MYOB had annual updates which
incorporated such changes for which they charged appropriately
I am sure most other jurisdictions have similar but also different complex
systems to deal with.
Underpaying the tax office their share where it was collectable by the employer
is of course a punishable civil offence
should you be caught doing it in an audit. This is an increasing problem with
the gig industry in Australia as many such
businesses think they are somehow exempt from industrial laws or are
deliberately ignorant.
David Cousens
>
> >
> > More generally, we can certainly use more hands to carry gnucash forward.
> > So
> > Stephen your offer to lend us a hand is highly appreciated :)
>
> +1
>
> >
> > Regards,
> >
> > Geert
> >
> >
> > _______________________________________________
> > gnucash-user mailing list
> > gnucash-user@gnucash.org
> > To update your subscription preferences or to unsubscribe:
> > https://lists.gnucash.org/mailman/listinfo/gnucash-user
> > If you are using Nabble or Gmane, please see
> > https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> > -----
> > Please remember to CC this list on all your replies.
> > You can do this by using Reply-To-List or Reply-All.
> >
> >
>
> _______________________________________________
> gnucash-user mailing list
> gnucash-user@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> If you are using Nabble or Gmane, please see
> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
_______________________________________________
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
