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

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

An interesting story, thanks for sharing it.

Well, before you roll up your sleeves, pause a coupe of minutes.

First off, we want to isolate Scheme to the reports module and use C++ 
everywhere else. Our current development focus is replacing the GObject-based 
core with modern C++.


I presume that Scheme will continue to be used in the reports arena -- as opposed to moving to some other language base. Understand from prior comments that Guile is no longer on the desired list.

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


The other big issue is that your description of the various modules in a 
business accounting system is for *big* business.
You can design scaled back versions for smaller business.  I will admit that having some built in depreciation schedules would have been helpful while I owned a small apartment building.  Now that it is sold, that is no longer a "need".
  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.

That was the main impetus for me to write those high level descriptions.  That, and to point out, a good G/L system is needed to support all those other modules -- but having support for does not mean it becomes or implements those modules.  Hence I cringed when the email came out regarding support for Fixed Assets.  But I'm sure you understand that thrust and I'll not climb on that tree stump.



As an aside I’ll also observe that most of the modules you described aren’t 
strictly speaking accounting, though they all have an accounting component. 
That’s why the vendors in that space (both FOSS and commercial) call their 
products “enterprise software” instead of “accounting software”.


Guess I'm showing my age from when those were "accounting software" (sans the POS which wasn't even in dreamland).


Regards,
John Ralls




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

Reply via email to