[GNC] Accounting Modules
David Cousens
davidcousens at bigpond.com
Tue Nov 27 18:11:00 EST 2018
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.gnucash at 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 <kg7je at 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 at 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 at 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.
More information about the gnucash-user
mailing list