Client--Server Implementation Model.
Mike or Penny Novack
stepbystepfarm at mtdata.com
Thu Nov 26 20:19:24 EST 2009
I'm going to jump in here.
Need to first take a closer look at the "business need" before jumping
to "simultaneous access". The latter would "solve" the perceived need
but in a way that may not be really appropriate. Let me explain.
As businesses grow larger, transaction handling tends to become
specialized. Might have an "accounts receivable" clerk who handles those
transactions, sales clerks who enter that kind of transactions, etc.
Normally you DON'T want people to be able to enter transactions of a
sort not their area of responsibility, though of course a single person
might be wearing more than one of these "hats". Using "simultaneous
multiple access" would allow everybody to enter their assigned sorts of
transactions to the main books BUT it would also permit them to enter
unauthorized sorts of transactions.
In really large systems this is handled by "feeds" to "general ledger".
That might be the model we should consider. Not multiple simultaneous
access to the main books but some way by which data might be moved from
subsidiary (specialized) books to the main books and THAT doesn't
require simultaneous access as can be a "batch" process. And yes, right
now Gnucash would support "subsidiary books" (books that represent only
a portion of the business). What we don't have is any way to automate
"feeds" and transfers between these books. All well and good to have
that a manual process when you are talking about once a month
transactions between "petty cash" and "general ledger" with likely only
a few accounts affected. Another thing were that A/R to general ledger
on a daily basis with scads of customer accounts involved.
Understand what I am saying? Were I the owner of a medium size business
I probably wouldn't want the employees entering A/R or sales
transactions to be able to even SEE the main books. Just their part of them.
Michael D. Novack
More information about the gnucash-user