Scope of GNUCash

[Mike or Penny Novack]

On 2/13/2018 2:55 AM, Wm via gnucash-devel wrote:

>
>> A couple of times I have noticed that people have said "That's not 
>> what GNUCash is for". It begs the question - where is it defined what 
>> GNUCash is and isn't for? The charter for GNUCash doesn't seem to 
>> ever been formalised.
> There is a long term plan, we never write it down because people ask 
> us about it :) Is it intended that people should establish a 
> complementary but separate project for functionality they want, but is 
> not included in GNUCash scope?
>
> I don't see why not if that is what they want to do.

Since I have been one of the people arguing for "separation" (I think 
this is being misunderstood) I want to clarify the reasons and what I 
mean when I use the term.

a) I do NOT mean that needs to be a separate project. Could be part of a 
PACKAGE (even installed together) but not a single program.

b) The reason for separate "packages" that interact with each other 
rather than a single program (that a user is or is not allowed to use) 
is so that ONE "system" (interacting parts) can be used for all. Those 
people who are running "one man band" businesses do not see the problem, 
do not see why things like (proposed extensions) like "inventory", 
"point of sales", "payroll",  etc. cannot be PART of the "general 
ledger" program. Call these "one man band" users businesses of class A.

But there is another sort of business user, call these class B. They 
have employees, they have division of responsibility and authority. They 
may have need of safeguards. I am not meaning JUST businesses since even 
a larger non-profit (call these class C, they might have other needs 
too) might need safeguards making embezzlement more difficult.

These need separation. They need to be able to have people "log in and 
use" things like an inventory system or "point of sales" system WITHOUT 
being able to access "general ledger. Does not have to be a very large 
small business before it has people waiting on customers, stocking 
inventory, etc. These people need to be able to do their jobs without 
being able to access "general ledger".

c) A solution with separated subsystems that feed each other would 
satisfy the needs of these entities (class B and C) while at the same 
time satisfy the needs of entities of class A. The reverse is not true 
AND not practical to "first build what would just work for class A and 
then modify that to work for classes B and C". That would be pretty much 
a complete rewrite.

d) However, the IS a common element for all the proposed additions (if 
separate). They need a way to FEED (send transactions to) general 
ledger. So general ledger (gnucash as it is) would need a way to accept 
feeds. And that includes a component to "input edit" feeds (make sure 
all the transactions coming in are valid, in balance, accounts they 
refer to exists, etc.) so that "general ledger" can reject (hopefully 
with meaningful explanations of the problems) a feed.

e) Not discussing at the present time feeds that might be required 
between these proposed extensions. For example, we would want a point of 
sales system to feed an inventory system. But things like that would not 
be "in common". Likewise not yet discussing safeguards (if a feed was 
not accepted, how is the system producing this feed temporarily blocked 
from adding to it. However I will say that to start, these systems 
should be designed to work "asynchronous batch" and only later consider 
expanding to supporting "real time update". Again this is a matter of 
"would work for all" while small entities could not safely make the 
assumption that all parts are up << and even some VERY LARGE entities do 
batch feed to general ledger --- I worked for the 43rd? largest 
"financial >>

Michael D Novack