[GNC] Accounting Modules

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [GNC] Accounting Modules

Stephen M. Butler
On 11/27/18 7:59 AM, Michael or Penny Novack wrote:

> On 11/26/2018 11:27 PM, David Cousens wrote:
>> Steve,
>>
>> I'd reinforce John and Adrien's comments about diving right in. I
>> originally learned C somewhere in the late 1980's from Kernigan and
>> Ritchie's book and used the language for a couple of years.
> Not a bad way to learn  I used that book too. The exercises along the
> way are essentially creating your own versions of the "standard
> library" utilities.
>
> C++ is essentially a "pre-compiler" language. Object oriented at the
> source level, not object oriented at run time. Whether a good idea to
> start with C++ might depend on how far you need to go. Just some
> basic/routine programming or all the way to being able to define your
> own special purpose objects that are from scratch (as opposed to
> composed of existing ones in the C++ objects library).
>
> Michael D Novack
>

I C plus plus.


--
Stephen M Butler, PMP, PSM
[hidden email]
[hidden email]
253-350-0166
-------------------------------------------
GnuPG Fingerprint:  8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8

_______________________________________________
gnucash-user mailing list
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: [GNC] Accounting Modules

Stephen M. Butler
In reply to this post by David Cousens
On 11/27/18 3:11 PM, David Cousens wrote:

>
> 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 <[hidden email]> wrote:
>>
>>> Op dinsdag 27 november 2018 00:17:06 CET schreef John Ralls:
>>>>> On Nov 27, 2018, at 6:35 AM, Stephen M. Butler <[hidden email]> 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
Ounch
_______________________________________________
gnucash-user mailing list
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: [GNC] Accounting Modules

David Cousens
In reply to this post by Stephen M. Butler
Steve,

> You might be able to built an abstract engine upon which other (local)
> configurators could build specific rules for their areas. Trying to do
> something to handle all cases out of the box is a recipe for early death
> by a thousand cuts.

To some extent that was the point I was trying to make. Having a sufficiently flexible engine to allow sufficient local
customization and rule specification is definitely a non-trivial programming exercise, perhaps  at the same level of
complexity as GnuCash itself. I suspect you would need to have access to something like Python as a scripting language
to produce callable locale specific code to implement the necessary degree of flexibility.

To design such an engine requires a lot of scoping out the variations you would have to deal with and the industrial
relations regimes are likely to be far more variable than basic accountancy which has a fairly solid common core which
is increasingly covered by the IFRS international standards. E.g. even though the US has not officially adopted the the
IFRS standards, the FASB standards are generally very similar and there is a considerable effort in the US by the FASB
to bring them into closer agreement, with a view to becoming compliant in the future. Most counties who have adopted the
IFRS usually do so by adopting them with ammendment where necessary to fit in with other local legal frameworks and
business/corporation legislation and regulation where there is a conflict.

Some aspects of the GnuCash design might be useful though, but only a small core of people (not including me) who are
still active in the development seem to have a really good grasp on that. If such a FOSS system already existed
somewhere it might be better to simply work on generating output that could be easily imported into GnuCash (e.g.
Dolibarr ERP/CRM https://www.dolibarr.org/#features or Compiere ) but in most cases they already have their own
accounting module so there is not likely to be an interest in their development team for exporting to GnuCash.

David Cousens

_______________________________________________
gnucash-user mailing list
[hidden email]
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.
David Cousens
Reply | Threaded
Open this post in threaded view
|

Re: [GNC] Accounting Modules

Robert Heller
In reply to this post by Stephen M. Butler
At Tue, 27 Nov 2018 15:49:17 -0800 "Stephen M. Butler" <[hidden email]> wrote:

>
> On 11/27/18 4:46 AM, Robert Heller wrote:
> > At Tue, 27 Nov 2018 10:13:37 +0100 Geert Janssens <[hidden email]> wrote:
> >
> >> Op dinsdag 27 november 2018 00:17:06 CET schreef John Ralls:
> >>>> On Nov 27, 2018, at 6:35 AM, Stephen M. Butler <[hidden email]> 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.
> Hmm.  I'll have to read up on stocks.  My retirement accounts are
> managed by a firm so I haven't felt the need to track the details.
A stock (or commodity) account contains a number of units (shares) at a value
of so much each. It is a "small" leap to think of an "account" for say a
supply of widgets valued at so much each. You would have an "account" for each
sort of widget, all grouped under some master account for one's complete
inventory. And then you would need to store the widget characteristics (size,
color, and so on) in addition to how many you have and what they are worth and
you might want to store things like base value, retail and wholesale sale
price, etc.

> >> 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).
>
>
> The one I built was for a 700 employee hospital in S. California.  They
> had strange rules about on-call and overtime.
>
> Something for a Mom and Pop would be interesting.  Not this year!
>
> >
> >> More generally, we can certainly use more hands to carry gnucash forward. So
> >> Stephen your offer to lend us a hand is highly appreciated :)
> I'm curious as to how many developers contribute.
> > +1
> >
> >> Regards,
> >>
> >> Geert
> >>
> >>
> >> _______________________________________________
> >> gnucash-user mailing list
> >> [hidden email]
> >> 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.
> >>
> >>                                            
>
>
--
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
[hidden email]       -- Webhosting Services
                             

_______________________________________________
gnucash-user mailing list
[hidden email]
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.
Robert Heller                      -- 978-544-6933
Deepwoods Software        -- Download the Model Railroad System
http://www.deepsoft.com/  -- Binaries for Linux and MS-Windows
heller@deepsoft.com        -- http://www.deepsoft.com/ModelRailroadSystem/
Reply | Threaded
Open this post in threaded view
|

Re: [GNC] Accounting Modules

John Ralls
In reply to this post by Michael or Penny Novack


> On Nov 28, 2018, at 8:36 AM, John Ralls <[hidden email]> wrote:
>
>
>
>> On Nov 28, 2018, at 12:59 AM, Michael or Penny Novack <[hidden email]> wrote:
>>
>> On 11/26/2018 11:27 PM, David Cousens wrote:
>>> Steve,
>>>
>>> I'd reinforce John and Adrien's comments about diving right in.  I
>>> originally learned C somewhere in the late 1980's from Kernigan and
>>> Ritchie's book and used the language for a couple of years.
>> Not a bad way to learn  I used that book too. The exercises along the way are essentially creating your own versions of the "standard library" utilities.
>>
>> C++ is essentially a "pre-compiler" language. Object oriented at the source level, not object oriented at run time. Whether a good idea to start with C++ might depend on how far you need to go. Just some basic/routine programming or all the way to being able to define your own special purpose objects that are from scratch (as opposed to composed of existing ones in the C++ objects library).

You’re about 30 years out-of-date on C++ (and probably on C as well if your study stopped with K&R). You might find the suggested reading at https://wiki.gnucash.org/wiki/C%2B%2B#Developer_Preparation <https://wiki.gnucash.org/wiki/C++#Developer_Preparation> or Koenig & Moo’s “Accelerated C++”, recommended earlier in this thread, useful to catch up.

Regards,
John Ralls

_______________________________________________
gnucash-user mailing list
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: [GNC] Accounting Modules

Adrien Monteleone-2
In reply to this post by Stephen M. Butler
Yes,

Now, add on support for the U.S. where you have Federal rules, State rules, even some City rules, and then those rules vary by industry, filing status, income level, type of entity making the payment, and so on. The monster just keeps growing. Intuit must have a small army working round the clock on it just to keep up. It probably took years to even implement what they have now.

Regards,

Adrien

> On Nov 27, 2018, at 6:02 PM, Stephen M. Butler <[hidden email]> wrote:
>
>>
> Ounch


_______________________________________________
gnucash-user mailing list
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: [GNC] Accounting Modules

Derek Atkins
In reply to this post by Geert Janssens-4
Geert Janssens <[hidden email]> writes:

> Payroll on the other hand is not my cup of tea and likely more targeted at
> larger businesses.

When I was more active in my consulting business, a payroll feature
would have been very useful.

I still maintain that GnuCash could contain a payroll framework which
defines the types of entries and sets of rules for taxes, deductions,
etc that would cover all locales.  However, the rules vary so much by
locality and change so frequently that there's no way we could maintain
that part of the system.

> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.

-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
       [hidden email]                        PGP key available
_______________________________________________
gnucash-user mailing list
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: [GNC] Accounting Modules

Thomas Forrester
Hence the reason payroll is so often outsourced.

On Wed, Nov 28, 2018 at 4:20 PM Derek Atkins <[hidden email]> wrote:

> Geert Janssens <[hidden email]> writes:
>
> > Payroll on the other hand is not my cup of tea and likely more targeted
> at
> > larger businesses.
>
> When I was more active in my consulting business, a payroll feature
> would have been very useful.
>
> I still maintain that GnuCash could contain a payroll framework which
> defines the types of entries and sets of rules for taxes, deductions,
> etc that would cover all locales.  However, the rules vary so much by
> locality and change so frequently that there's no way we could maintain
> that part of the system.
>
> > Please remember to CC this list on all your replies.
> > You can do this by using Reply-To-List or Reply-All.
>
> -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
>        [hidden email]                        PGP key available
> _______________________________________________
> gnucash-user mailing list
> [hidden email]
> 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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: [GNC] Accounting Modules

Christopher Lam
In reply to this post by Stephen M. Butler
Dear Stephen

Most describe various transaction *types* -
(1) GL ones are regular everyday money movements
(2) AP/AR transactions are business amounts owed/payable and are already
implemented
(3) FA transactions are multiyear entities whereby a single asset/liability
is amortized over time, and are currently handled very much manually. This
could be refined as a separate transaction type.
(4) PAYROLL transactions are, IMHO, simple multisplit transactions whereby
the allocations must follow predefined (and customizable) formulas
(5) POS transactions are simply an input mechanism into the GL, right?
Unless you're talking about POS transactions also handle decreasing
inventory items and calculating their pricing... this seems out of scope
for gnucash which aims to be for personal/sole trader bookkeeping.

I wouldn't know how to handle INVENTORY/PURCHASING ones.

You've forgotten commodities/stock:
(6) STOCK transactions are simple regular money movements with variably
priced commodities, and, IMO, currently gnucash handles them similarly to
currencies and it works fairly well... except the FIFO/LIFO asset pricing
is rather hard to do.

I'd add another candidate to the list.

(7) BUDGET transactions are virtual transactions - they do NOT move money
around in the book, yet, the budget balances may be counted separately and
are used to compare GL transactions with the budget ones.

Would you care to add your high-level overview to the wiki?

On Tue, 27 Nov 2018 at 05:37, Stephen M. Butler <[hidden email]> wrote:

> I was both excited and dismayed to learn that GnuCash has "Fixed
> Assets".  Excited because that meant an expansion of capability and
> dismayed because reading between the lines implied only the setting up
> of an accounting structure.
>
> Adding a set of Fixed Asset accounts to the General Ledger system does
> not make the General Ledger into a Fixed Assets module any more than
> adding a set of Payroll accounts make the G/L into a payroll system.
>
> Accounting Modules (at a high level):
>
> 1.  General Ledger (G/L).  The module that allows a user to maintain a
> set of accounting books electronically using generally accepted
> accounting practices.  This module is also the recipient of JVs (Journal
> Vouchers) from other financial systems.  Primary purpose is to produce a
> Balance Sheet (under various names) and an Income Statement (also having
> aliases).  It maintains information at a summary level
>
> 2.  Accounts Payable (A/P).  This module tracks to whom, how much, and
> when payments are due.  It should sent a multi-line JV to the G/L.  This
> module must track names and addresses and other information that a G/L
> does not need (and shouldn't have to worry about).
>
> 3.  Accounts Receivable (A/R).  This module tracks from whom, how much,
> and when payments should be received.  It also should sent a multi-line
> JV to the G/L.  It also tracks names, addresses, and other information
> that a G/L should ignore.
>
> 4.  Fixed Assets (F/A).  This module tracks the assets of the company
> that have a relative long life. (Not inventory that has a short shelf
> life).  It also knows about depreciation schedules and the past,
> present, and potential future value of each asset including the
> depreciation amount, etc.  It also sends a multi-line JV to G/L.  And
> again, G/L should ignore a lot of the details involved in Fixed Assets.
>
> 5.  Payroll (P/R).  This tracks employees, how much they are paid, what
> deductions to take out of their pay, how often they are paid along with
> the accrual of certain benefits (sick leave, vacation bank, etc).  It
> also prepares certain tax related reports for various governing bodies.
> This is one of, if not the, most complicated financial module.  It also
> sends a multi-line JV to G/L.  Generally it prints its own set of checks
> but I've heard of cases where it sends that information over to A/P
> (overloads A/P in my opinion).
>
> Then there follow other financial modules that may be beneficial to some
> entities:
>
> 6.  Inventory.  This tracks certain transitory assets and has
> reorder-points, vendors (from whom to order), clients (who can buy and
> purchase levels).  It also talks to G/L and other systems (A/P, A/R).
>
> 7.  Purchasing.  May be part of inventory or some systems make inventory
> part of purchasing.  Ideally they talk to each other and this handles
> the issuing of the PO (purchase order) to ensure inventory levels are
> maintained.  It may interface with F/A when the company needs to
> purchase additional (or replacement) items for long-term retention.  It
> also needs to handle items that are directly expensed and not recorded
> in inventory nor F/A.
>
> 8.  Point-of-Sale (POS).  I've not done one of these -- it might be more
> complicated then payroll (which I have designed and built)!
>
> So, why was I excited?  Its always nice to see an application expand and
> tackle additional arenas.
>
> Why dismay then?  It takes a lot of resources to maintain each one of
> the above modules.  It is better to pick one module and make it the best
> one available ("hit a home run", "gold standard", etc) than to be
> mediocre in several ("never get on base" -- even on fouls).
>
>
> So, what are my credentials?  I've seen that one of the Davids on this
> forum was a physicist in a prior career and retired as an accountant.
> Here is my story:
>
> I was born (I do wonder about some folks if they have even begun to
> live) midway through the last century (makes me feel even older
> admitting that).  Graduated with a BS in Chemistry (though I have more
> credits in math) and minors in Physics and Religion.  I took every
> computer class the college offered -- including Numerical Analysis.  It
> wasn't much but enough to impress the recruiter from a hospital.  So, I
> began my post graduation career as a programmer in the now ancient
> language of COBOL on a 6-bit computer (Honeywell 115-Mod1) with 32K of
> core (real core) based on 556 bpi 7 track tape.  Oh, it did have a 10 MB
> disk drive.  That was the summer of 1975.
>
> Graduated to an HP-3000 in 1978 (still COBOL) with gobs of disk, 9-track
> tape, and a two-level network database system called Image.  My phone
> has more RAM than all those disk drives held! But now I was an analyst
> and data modeler.  Spent time at Weyerhaeuser ('81-'84) with their
> database group brushing up on database theory (CJ Date book).  Moved on
> to consulting work ('85-'90) (built property tax receipting system,
> utility billing, permits, etc).  Then spent time with newsprint
> distribution for The Seattle Times ('91-'96).  They sent me off to
> become an Oracle DBA ('93) but didn't have a full-time position as
> such.  So I moved on (July '96) and did DBA (database administration)
> for Washington State's largest PPO (Preferred Provider Organization).
> Learned a lot about processing/pricing/adjudicating medical claims and
> ended up designing the data model for their new systems.
>
> Became an I.T. Manager (2007) for that company and managed two
> development teams plus the DBA (and was the only Korn Shell writer in
> the company).  Picked up my PMP (Project Management Professional)
> certification in 2011 and promptly retired in February 2017.
>
> So, I have over 40 years working with computers.  Mostly with those
> ancient languages (BASIC, Fortran, COBOL, some Pascal) and some assembly
> language/machine language exposure (PDP 11/20, ASM, PAL, PSL) and
> database transaction languages (Transact, PL/SQL,, Oracle's flavor of
> SQL).  But woefully lacking in web and modern day (C, C++, C#, Scheme --
> I did read the book last week).
>
> Took time this past year to relax, work on the new property, enjoy the
> grandkids and how I had time to go to work all those years.
>
> Well, the greenhouse is built, summer is over, the rains have set in and
> I did promise to figure this language called Scheme out enough to get
> the basic reports formatted to my wife's demanding specifications.
>
> Her qualifications?  MEd secondary education for Business Education.
> Took some additional Accounting courses and spend the last 21 years
> doing accounting for an architect.  Mostly assisted living facilities
> but also churches around the world.
>
> So, when I get stuck on which side of the T account the credits/debits
> go (and when the default value is negative/positive -- and yes, I know
> that both debits and credits can hold both negative and positive values
> for the same account so looking at the sign doesn't tell you to which
> side it belongs -- it is a really strong hint though) I have an in-house
> reference that accepts voice input (not Alexei nor Echo!) and generally
> responds rather quickly.  Failing that, I contact my daughter who has
> her AA in accounting (she specializes in payroll).
>
> Now, it's time for me to roll up my sleeves and get my hands dirty in
> this thing called Scheme.  It looks to me that there are just a couple
> developers holding down the fort here.  And that is way too little to
> try to make GNC anything more than a good G/L system.  Hopefully by
> spring I'll have my thousand hours in and be able to contribute.
>
> Yes, I've noticed that the brain muscle has atrophied along with the
> knees and other items since retirement.  I think I can still whip out a
> data model (ER diagram) but the detailed syntax to create that in an
> Oracle database -- well, for the last 10 years I had a DBA to whom I
> could assign that task!
>
> Oh yes, C is on the bucket list,  I'll have to Scheme my way to it.
>
> --
> Stephen M Butler, PMP, PSM
> [hidden email]
> [hidden email]
> 253-350-0166
> -------------------------------------------
> GnuPG Fingerprint:  8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8
>
> _______________________________________________
> gnucash-user mailing list
> [hidden email]
> 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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: [GNC] Accounting Modules

Stephen M. Butler
On 12/1/18 6:20 PM, Christopher Lam wrote:
> Dear Stephen
>
> Most describe various transaction *types* -


They are also different modules in a business financial package.


> (1) GL ones are regular everyday money movements
> (2) AP/AR transactions are business amounts owed/payable and are
> already implemented
> (3) FA transactions are multiyear entities whereby a single
> asset/liability is amortized over time, and are currently handled very
> much manually. This could be refined as a separate transaction type.
> (4) PAYROLL transactions are, IMHO, simple multisplit transactions
> whereby the allocations must follow predefined (and customizable) formulas
> (5) POS transactions are simply an input mechanism into the GL, right?
> Unless you're talking about POS transactions also handle decreasing
> inventory items and calculating their pricing... this seems out of
> scope for gnucash which aims to be for personal/sole trader bookkeeping.
>
> I wouldn't know how to handle INVENTORY/PURCHASING ones.
>
> You've forgotten commodities/stock:
> (6) STOCK transactions are simple regular money movements with
> variably priced commodities, and, IMO, currently gnucash handles them
> similarly to currencies and it works fairly well... except the
> FIFO/LIFO asset pricing is rather hard to do.
>
> I'd add another candidate to the list.
>
> (7) BUDGET transactions are virtual transactions - they do NOT move
> money around in the book, yet, the budget balances may be counted
> separately and are used to compare GL transactions with the budget ones.
>
> Would you care to add your high-level overview to the wiki?
>
> On Tue, 27 Nov 2018 at 05:37, Stephen M. Butler <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     I was both excited and dismayed to learn that GnuCash has "Fixed
>     Assets".  Excited because that meant an expansion of capability and
>     dismayed because reading between the lines implied only the
>     setting up
>     of an accounting structure.
>
>     Adding a set of Fixed Asset accounts to the General Ledger system
>     does
>     not make the General Ledger into a Fixed Assets module any more than
>     adding a set of Payroll accounts make the G/L into a payroll system.
>
>     Accounting Modules (at a high level):
>
>     1.  General Ledger (G/L).  The module that allows a user to
>     maintain a
>     set of accounting books electronically using generally accepted
>     accounting practices.  This module is also the recipient of JVs
>     (Journal
>     Vouchers) from other financial systems.  Primary purpose is to
>     produce a
>     Balance Sheet (under various names) and an Income Statement (also
>     having
>     aliases).  It maintains information at a summary level
>
>     2.  Accounts Payable (A/P).  This module tracks to whom, how much,
>     and
>     when payments are due.  It should sent a multi-line JV to the
>     G/L.  This
>     module must track names and addresses and other information that a
>     G/L
>     does not need (and shouldn't have to worry about).
>
>     3.  Accounts Receivable (A/R).  This module tracks from whom, how
>     much,
>     and when payments should be received.  It also should sent a
>     multi-line
>     JV to the G/L.  It also tracks names, addresses, and other
>     information
>     that a G/L should ignore.
>
>     4.  Fixed Assets (F/A).  This module tracks the assets of the company
>     that have a relative long life. (Not inventory that has a short shelf
>     life).  It also knows about depreciation schedules and the past,
>     present, and potential future value of each asset including the
>     depreciation amount, etc.  It also sends a multi-line JV to G/L.  And
>     again, G/L should ignore a lot of the details involved in Fixed
>     Assets.
>
>     5.  Payroll (P/R).  This tracks employees, how much they are paid,
>     what
>     deductions to take out of their pay, how often they are paid along
>     with
>     the accrual of certain benefits (sick leave, vacation bank, etc).  It
>     also prepares certain tax related reports for various governing
>     bodies.
>     This is one of, if not the, most complicated financial module.  It
>     also
>     sends a multi-line JV to G/L.  Generally it prints its own set of
>     checks
>     but I've heard of cases where it sends that information over to A/P
>     (overloads A/P in my opinion).
>
>     Then there follow other financial modules that may be beneficial
>     to some
>     entities:
>
>     6.  Inventory.  This tracks certain transitory assets and has
>     reorder-points, vendors (from whom to order), clients (who can buy
>     and
>     purchase levels).  It also talks to G/L and other systems (A/P, A/R).
>
>     7.  Purchasing.  May be part of inventory or some systems make
>     inventory
>     part of purchasing.  Ideally they talk to each other and this handles
>     the issuing of the PO (purchase order) to ensure inventory levels are
>     maintained.  It may interface with F/A when the company needs to
>     purchase additional (or replacement) items for long-term
>     retention.  It
>     also needs to handle items that are directly expensed and not
>     recorded
>     in inventory nor F/A.
>
>     8.  Point-of-Sale (POS).  I've not done one of these -- it might
>     be more
>     complicated then payroll (which I have designed and built)!
>
>     So, why was I excited?  Its always nice to see an application
>     expand and
>     tackle additional arenas.
>
>     Why dismay then?  It takes a lot of resources to maintain each one of
>     the above modules.  It is better to pick one module and make it
>     the best
>     one available ("hit a home run", "gold standard", etc) than to be
>     mediocre in several ("never get on base" -- even on fouls).
>
>
>     So, what are my credentials?  I've seen that one of the Davids on
>     this
>     forum was a physicist in a prior career and retired as an accountant.
>     Here is my story:
>
>     I was born (I do wonder about some folks if they have even begun to
>     live) midway through the last century (makes me feel even older
>     admitting that).  Graduated with a BS in Chemistry (though I have
>     more
>     credits in math) and minors in Physics and Religion.  I took every
>     computer class the college offered -- including Numerical
>     Analysis.  It
>     wasn't much but enough to impress the recruiter from a hospital. 
>     So, I
>     began my post graduation career as a programmer in the now ancient
>     language of COBOL on a 6-bit computer (Honeywell 115-Mod1) with
>     32K of
>     core (real core) based on 556 bpi 7 track tape.  Oh, it did have a
>     10 MB
>     disk drive.  That was the summer of 1975.
>
>     Graduated to an HP-3000 in 1978 (still COBOL) with gobs of disk,
>     9-track
>     tape, and a two-level network database system called Image. My phone
>     has more RAM than all those disk drives held! But now I was an
>     analyst
>     and data modeler.  Spent time at Weyerhaeuser ('81-'84) with their
>     database group brushing up on database theory (CJ Date book).
>     Moved on
>     to consulting work ('85-'90) (built property tax receipting system,
>     utility billing, permits, etc).  Then spent time with newsprint
>     distribution for The Seattle Times ('91-'96).  They sent me off to
>     become an Oracle DBA ('93) but didn't have a full-time position as
>     such.  So I moved on (July '96) and did DBA (database administration)
>     for Washington State's largest PPO (Preferred Provider Organization).
>     Learned a lot about processing/pricing/adjudicating medical claims
>     and
>     ended up designing the data model for their new systems.
>
>     Became an I.T. Manager (2007) for that company and managed two
>     development teams plus the DBA (and was the only Korn Shell writer in
>     the company).  Picked up my PMP (Project Management Professional)
>     certification in 2011 and promptly retired in February 2017.
>
>     So, I have over 40 years working with computers.  Mostly with those
>     ancient languages (BASIC, Fortran, COBOL, some Pascal) and some
>     assembly
>     language/machine language exposure (PDP 11/20, ASM, PAL, PSL) and
>     database transaction languages (Transact, PL/SQL,, Oracle's flavor of
>     SQL).  But woefully lacking in web and modern day (C, C++, C#,
>     Scheme --
>     I did read the book last week).
>
>     Took time this past year to relax, work on the new property, enjoy
>     the
>     grandkids and how I had time to go to work all those years.
>
>     Well, the greenhouse is built, summer is over, the rains have set
>     in and
>     I did promise to figure this language called Scheme out enough to get
>     the basic reports formatted to my wife's demanding specifications.
>
>     Her qualifications?  MEd secondary education for Business Education.
>     Took some additional Accounting courses and spend the last 21 years
>     doing accounting for an architect.  Mostly assisted living facilities
>     but also churches around the world.
>
>     So, when I get stuck on which side of the T account the
>     credits/debits
>     go (and when the default value is negative/positive -- and yes, I
>     know
>     that both debits and credits can hold both negative and positive
>     values
>     for the same account so looking at the sign doesn't tell you to which
>     side it belongs -- it is a really strong hint though) I have an
>     in-house
>     reference that accepts voice input (not Alexei nor Echo!) and
>     generally
>     responds rather quickly.  Failing that, I contact my daughter who has
>     her AA in accounting (she specializes in payroll).
>
>     Now, it's time for me to roll up my sleeves and get my hands dirty in
>     this thing called Scheme.  It looks to me that there are just a
>     couple
>     developers holding down the fort here.  And that is way too little to
>     try to make GNC anything more than a good G/L system. Hopefully by
>     spring I'll have my thousand hours in and be able to contribute.
>
>     Yes, I've noticed that the brain muscle has atrophied along with the
>     knees and other items since retirement.  I think I can still whip
>     out a
>     data model (ER diagram) but the detailed syntax to create that in an
>     Oracle database -- well, for the last 10 years I had a DBA to whom I
>     could assign that task!
>
>     Oh yes, C is on the bucket list,  I'll have to Scheme my way to it.
>
>     --
>     Stephen M Butler, PMP, PSM
>     [hidden email] <mailto:[hidden email]>
>     [hidden email] <mailto:[hidden email]>
>     253-350-0166
>     -------------------------------------------
>     GnuPG Fingerprint:  8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8
>
>     _______________________________________________
>     gnucash-user mailing list
>     [hidden email] <mailto:[hidden email]>
>     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.
>

--
Stephen M Butler, PMP, PSM
[hidden email]
[hidden email]
253-350-0166
-------------------------------------------
GnuPG Fingerprint:  8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8

_______________________________________________
gnucash-user mailing list
[hidden email]
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.
12