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

Re: [GNC] Accounting Modules

[Christopher Lam]

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

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  wrote:

> Geert Janssens  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
>warl...@mit.eduPGP key available
> ___
> 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.

Re: [GNC] Accounting Modules

[Derek Atkins]

Geert Janssens  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
   warl...@mit.eduPGP key available
___
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.

Re: [GNC] Accounting Modules

[Adrien Monteleone]

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  wrote:
> 
>> 
> Ounch


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

Re: [GNC] Accounting Modules

[John Ralls]

> On Nov 28, 2018, at 8:36 AM, John Ralls  wrote:
> 
> 
> 
>> On Nov 28, 2018, at 12: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).

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

Regards,
John Ralls

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

Re: [GNC] Accounting Modules

[Robert Heller]

At Tue, 27 Nov 2018 15:49:17 -0800 "Stephen M. Butler"  wrote:

> 
> On 11/27/18 4:46 AM, Robert Heller wrote:
> > At Tue, 27 Nov 2018 10:13:37 +0100 Geert Janssens 
> >  wrote:
> >
> >> Op dinsdag 27 november 2018 00:17:06 CET schreef John Ralls:
>  On Nov 27, 2018, at 6:35 AM, Stephen M. Butler  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
> >> 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.
> >>
> >> 
> 
> 

-- 
Robert Heller -- 978-544-6933
Deepwoods Software-- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
hel...@deepsoft.com   -- Webhosting Services
 
___
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.

Re: [GNC] Accounting Modules

[David Cousens]

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

Re: [GNC] Accounting Modules

[Stephen M. Butler]

On 11/27/18 6:47 AM, 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  
wrote:


Op dinsdag 27 november 2018 00:17:06 CET schreef John Ralls:

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

With a payroll system, the number of employess 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. 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.
dealing with the different conditions for casual, part -time and full time 
staff is a hassle.
You also have to track employee benefits like annual leave, sick leave, 
parental 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 for
each individual and whether casual/part-time/fulltime. Most of my staff were 
casual or part time.
Our tax office provided online calculators based on the total weekly wage for
tax eduction. There were also additions to the tax based on an income threshold 
for basic medicare
coverage which had an additional levy which cut in for higher income earners or 
those who did not
have private hospital insurance.

Also, sometimes union fees, health insurance and compulsory superannuation 
which was a fixed percentage
of the gross wage also had to be deducted and paid to specifc payees. A lot of 
these calculations were based on a table
of thresholds and % rates which applied between each threshold. On top of that 
employees could specify
deductions for compulsory workplace insurance and private life, income 
insurance etc payable to a specified accounts. To
calculate  the payroll, you entered the hours worked and the rest was 
calculated.

A payroll system also has to deal with overtime rates and in our case penalty 
rates which applied for work on Saturdays,
Sundays and public holidays. A further complication is that these penalty rates 
were part of industrial awards for
specific occupations and sometimes varied between specific occupations so all 
this was all employee specific and had to
be tied to each employee's record. They also had Time off in lieu provisions 
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.

I am sure most other jurisdictions have similar but differnet complications 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.

David Cousens



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.


--
Stephen M Butler, PMP, PSM
stephen.m.butle...@gmail.com
kg...@arrl.net
253-350-0166
---
GnuPG Fingerprint:  8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8

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

Re: [GNC] Accounting Modules

[Stephen M. Butler]

On 11/27/18 4:46 AM, Robert Heller wrote:

At Tue, 27 Nov 2018 10:13:37 +0100 Geert Janssens  
wrote:


Op dinsdag 27 november 2018 00:17:06 CET schreef John Ralls:

On Nov 27, 2018, at 6:35 AM, Stephen M. Butler  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.

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





--
Stephen M Butler, PMP, PSM
stephen.m.butle...@gmail.com
kg...@arrl.net
253-350-0166
---
GnuPG Fingerprint:  8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8

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

Re: [GNC] Accounting Modules

[David Cousens]

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 
>  wrote:
> 
> > 
> > Op dinsdag 27 november 2018 00:17:06 CET schreef John Ralls:
> > > > On Nov 27, 2018, at 6:35 AM, Stephen M. Butler  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 

Re: [GNC] Accounting Modules

[Michael or Penny Novack]

On 11/27/2018 1:04 AM, Jeff Abrahamson wrote:

I second that you can just start with C++.  C++11 and beyond permits and
encourages programming styles that are very different from C's.

I'd stress that encourages rather than permits, but very strong 
encouragement as being permitted to do something not useful if you don't 
know how or even if that "it" exists.


Thus while learning C (after I formally retired in 2000 -- I then 
consulted) after a discussion about whether a procedural or functional 
language I was challenged to write pure function C (rewrite one of my 
exercises). Now obviously I had to know what a "functional language" was 
like.


If you seriously want to do so, you can write in C just as object 
oriented as if you were using C++. My (self chosen) "case problem" for 
learning C was a direct finite implementation of the 2nd Lempel-Zev 
compression algorithm. I certainly defined/created an "object" that were 
the dictionary nodes.


Michael D Novack
___
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.

Re: [GNC] Accounting Modules

[Michael or Penny Novack]

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

Re: [GNC] Accounting Modules

[David Cousens]

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 
>  wrote:
> 
> > 
> > Op dinsdag 27 november 2018 00:17:06 CET schreef John Ralls:
> > > > On Nov 27, 2018, at 6:35 AM, Stephen M. Butler  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 basi
s 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).

With a payroll system, the number of employess 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. 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.
dealing with the different conditions for casual, part -time and full time 
staff is a hassle. 
You also have to track employee benefits like annual leave, sick leave, 
parental 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 for
each individual and whether casual/part-time/fulltime. Most of my staff were 
casual or part time.
Our tax office provided online calculators based on the total weekly wage for 
tax eduction. There were also additions to the tax based on an income threshold 
for basic medicare 
coverage which had an additional levy which cut in for higher income earners or 
those who did not 
have private hospital insurance.

Also, sometimes union fees, health insurance and compulsory superannuation 
which was a fixed percentage 
of the gross wage also had to be deducted and paid to specifc payees. A lot of 
these calculations were based on a table 
of thresholds and % rates which applied between each threshold. On top of that 
employees could specify 
deductions for compulsory workplace insurance and private life, income 
insurance etc payable to a specified accounts. To
calculate  the payroll, you entered the hours worked and the rest was 
calculated. 

A payroll system also has to deal with overtime rates and in our case penalty 
rates which applied for work on Saturdays,
Sundays and public holidays. A further complication is that these penalty rates 
were part of industrial awards for
specific occupations and sometimes varied between specific occupations so all 
this was all employee specific and had to
be tied to each employee's record. They also had Time off in lieu provisions 
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 

Re: [GNC] Accounting Modules

[Robert Heller]

At Tue, 27 Nov 2018 10:13:37 +0100 Geert Janssens  
wrote:

> 
> Op dinsdag 27 november 2018 00:17:06 CET schreef John Ralls:
> > > On Nov 27, 2018, at 6:35 AM, Stephen M. Butler  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.

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

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

-- 
Robert Heller -- 978-544-6933
Deepwoods Software-- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
hel...@deepsoft.com   -- Webhosting Services
   
___
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.

Re: [GNC] Accounting Modules

[Geert Janssens]

Op dinsdag 27 november 2018 00:17:06 CET schreef John Ralls:
> > On Nov 27, 2018, at 6:35 AM, Stephen M. Butler  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.

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

More generally, we can certainly use more hands to carry gnucash forward. So 
Stephen your offer to lend us a hand is highly appreciated :)

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.

Re: [GNC] Accounting Modules

[Jeff Abrahamson]

I second that you can just start with C++.  C++11 and beyond permits and
encourages programming styles that are very different from C's.

A while back (having already worked with C and C++ for many years) I
read Koenig & Moo's Accelerated C++.  For specificity, here's a link at
one online vendor:


https://www.amazon.com/Accelerated-C-Practical-Programming-Example/dp/020170353X/

One of its strong points is that it doesn't talk about memory allocation
until near the end and encourages a nearly python-with-types style of
programming.  That produces much more readable and maintainable code.

Jeff Abrahamson
https://www.p27.eu/jeff/
https://www.transport-nantes.com/



On 27/11/18 04:00, Adrien Monteleone wrote:
> Stephen,
>
> You can learn it directly. My university didn’t even offer C except as part 
> of their Operating Systems Design course. They start everyone off with C++.
>
> Regards,
> Adrien
>
>> On Nov 26, 2018, at 8:18 PM, Stephen M. Butler  wrote:
>>
>>
>>
>> And I think the route to C++ is learning C -- or can one skip directly.  
>> Although that might not be helpful during the migration.
>>
>
> ___
> 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.

-- 

Jeff Abrahamson
+33 6 24 40 01 57
+44 7920 594 255
https://www.p27.eu/jeff/
https://www.transport-nantes.com/

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

Re: [GNC] Accounting Modules

[Stephen M. Butler]

On 11/26/18 8: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. After that I
moved on to Matlab and Mathematica for most of my calculation needs
(employed by the government who paid insitutional licence fees) as they
became available. Have never formally learned C++ (and it shows) but I did
use a couple of other Object Oriented languages in between, so C++ generally
becomes intelligible fairly quickly. There are a lot of online reources for
C++ and quite a few programming forums where you can seek advice as well.

The greatest difficulty I have experienced is in tracking program flow and
locating definitions with complex include heirarchies, which was why I
mentioned Sourcetrail previously. I won't say I am ever going to be an
expert C++ coder, but I can now get by to the extent necessary to string a
few library calls together. When I come across C++ features I don't
understand, I just read around the topic. Spending some time learning C++
properly is on the priority list for me and probably a good idea before
writing new code. When I get desperate, I just call my son who is a
professional developer of business software and games platforms.

David
Thanks David.  That reminds me that a neighbor from a decade ago now 
works for Intel down in Phoenix.  He'll be a great resource to call -- 
and in the non-winter we are even on the same time!


--
Stephen M Butler, PMP, PSM
stephen.m.butle...@gmail.com
kg...@arrl.net
253-350-0166
---
GnuPG Fingerprint:  8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8

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

Re: [GNC] Accounting Modules

[David Cousens]

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. After that I
moved on to Matlab and Mathematica for most of my calculation needs
(employed by the government who paid insitutional licence fees) as they
became available. Have never formally learned C++ (and it shows) but I did
use a couple of other Object Oriented languages in between, so C++ generally
becomes intelligible fairly quickly. There are a lot of online reources for
C++ and quite a few programming forums where you can seek advice as well. 

The greatest difficulty I have experienced is in tracking program flow and
locating definitions with complex include heirarchies, which was why I
mentioned Sourcetrail previously. I won't say I am ever going to be an
expert C++ coder, but I can now get by to the extent necessary to string a
few library calls together. When I come across C++ features I don't
understand, I just read around the topic. Spending some time learning C++
properly is on the priority list for me and probably a good idea before
writing new code. When I get desperate, I just call my son who is a
professional developer of business software and games platforms.

David



-
David Cousens
--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-User-f1415819.html
___
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.

Re: [GNC] Accounting Modules

[John Ralls]

> On Nov 27, 2018, at 12:06 PM, Stephen M. Butler  wrote:
> 
> On 11/26/18 7:00 PM, Adrien Monteleone wrote:
>> Stephen,
>> 
>> You can learn it directly. My university didn’t even offer C except as part 
>> of their Operating Systems Design course. They start everyone off with C++.
>> 
>> Regards,
>> Adrien
> Good to know.
>>> On Nov 26, 2018, at 8:18 PM, Stephen M. Butler  wrote:
>>> 
>>> 
>>> 
>>> And I think the route to C++ is learning C -- or can one skip directly.  
>>> Although that might not be helpful during the migration.
>>> 

I’d say that it’s more like dive right in with C++ and C will come along for 
the ride.
https://wiki.gnucash.org/wiki/C%2B%2B#Developer_Preparation 
 has some suggested 
reading. 

Regards,
John Ralls
___
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.

Re: [GNC] Accounting Modules

[Stephen M. Butler]

On 11/26/18 7:00 PM, Adrien Monteleone wrote:

Stephen,

You can learn it directly. My university didn’t even offer C except as part of 
their Operating Systems Design course. They start everyone off with C++.

Regards,
Adrien

Good to know.

On Nov 26, 2018, at 8:18 PM, Stephen M. Butler  wrote:



And I think the route to C++ is learning C -- or can one skip directly.  
Although that might not be helpful during the migration.



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



--
Stephen M Butler, PMP, PSM
stephen.m.butle...@gmail.com
kg...@arrl.net
253-350-0166
---
GnuPG Fingerprint:  8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8

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

Re: [GNC] Accounting Modules

[Adrien Monteleone]

Stephen,

You can learn it directly. My university didn’t even offer C except as part of 
their Operating Systems Design course. They start everyone off with C++.

Regards,
Adrien

> On Nov 26, 2018, at 8:18 PM, Stephen M. Butler  wrote:
> 
> 
> 
> And I think the route to C++ is learning C -- or can one skip directly.  
> Although that might not be helpful during the migration.
> 


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

Re: [GNC] Accounting Modules

[Stephen M. Butler]

On 11/26/18 3:11 PM, David Cousens wrote:

Stephen,

Gnucash really only fully implements the first three modules you have
described. It is certainly capable of maintaining the records necessary for
the other areas but does not support any in built calculations and automatic
creation of the entries in the books. At present any use of GnuCash for
these functions must be totally manual and all calculation largely external
to GnuCash.



Exactly my point.



One  reason for that is the details of the calculations required in most of
the other areas you describe often have a larger degree of dependency upon
local legislation and business practices. Even then in many cases the core
functionality is largely common, details of calculation methods employed and
rules on applicationof specific methods, thresholds of applicability etc
will vary, and the devil is in the detail.



Plus a few other places.



The program does have basic support for the creation of other modules. When
I first started using GNuCash I was still working and was interested at that
stage in the possibility of both payroll and inventory capability to support
minor business ventures I was involved in which did not justify the
expenditure on using commercial accounting packages. I had used MYOB for
accounting for one business several years earlier. I have found however that
delving into the GnuCash code to be a not inconsiderble undertaking.



I would not want to burden the existing team with additional modules.  
If another team decided to tackle one or some of the other modules and 
utilize GNC as the back-end G/L that would be a different story.




I recently found a program, Sourcetrail, which makes finding my way around
the existing C, C++code base little easier. It searches the code and
constructs a searchable database of where in the code functions are called,
definitions  are located, which has allowed me to construct ER diagrams and
map the program flow at least within the specific area of code I am working
on. Mapping the whole code would obviously be a desirable undertaking but I
fear I won't live that long.



Interesting.  Hopefully I remember to ask you about that when I get to 
the "Learn C/C++" bucket item.



David Cousens



--Steve

PS  If the length of life for my parents/grandparents is any indication, 
I'll live long enough to master another couple of languages (software).  
So for I've avoided going Forth.


--
Stephen M Butler, PMP, PSM
stephen.m.butle...@gmail.com
kg...@arrl.net
253-350-0166
---
GnuPG Fingerprint:  8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8

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

Re: [GNC] Accounting Modules

[Stephen M. Butler]

On 11/26/18 3:17 PM, John Ralls wrote:



On Nov 27, 2018, at 6:35 AM, Stephen M. Butler  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 

Re: [GNC] Accounting Modules

[John Ralls]

> On Nov 27, 2018, at 6:35 AM, Stephen M. Butler  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 

Re: [GNC] Accounting Modules

[David Cousens]

Stephen,

Gnucash really only fully implements the first three modules you have
described. It is certainly capable of maintaining the records necessary for
the other areas but does not support any in built calculations and automatic
creation of the entries in the books. At present any use of GnuCash for
these functions must be totally manual and all calculation largely external
to GnuCash.

One  reason for that is the details of the calculations required in most of
the other areas you describe often have a larger degree of dependency upon
local legislation and business practices. Even then in many cases the core
functionality is largely common, details of calculation methods employed and
rules on applicationof specific methods, thresholds of applicability etc
will vary, and the devil is in the detail.

The program does have basic support for the creation of other modules. When
I first started using GNuCash I was still working and was interested at that
stage in the possibility of both payroll and inventory capability to support
minor business ventures I was involved in which did not justify the
expenditure on using commercial accounting packages. I had used MYOB for
accounting for one business several years earlier. I have found however that
delving into the GnuCash code to be a not inconsiderble undertaking.

I recently found a program, Sourcetrail, which makes finding my way around
the existing C, C++code base little easier. It searches the code and
constructs a searchable database of where in the code functions are called,
definitions  are located, which has allowed me to construct ER diagrams and
map the program flow at least within the specific area of code I am working
on. Mapping the whole code would obviously be a desirable undertaking but I
fear I won't live that long.

David Cousens



-
David Cousens
--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-User-f1415819.html
___
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.

[GNC] Accounting Modules

[Stephen M. Butler]

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