Multiple Files

Mike or Penny Novack mpnovack at mtdata.com
Thu Mar 17 09:51:05 EDT 2016


On 3/17/2016 12:01 AM, E Rosenberg wrote:
>
> These are all independent private schools, each with their own boards
> and their needs.  I realize the complexity I am causing for myself,
> but my hands are tied.  The best I can think of is a general outline,
> of how to handle multiple inputs and outputs.  Any other advise you
> can render would be deeply appreciated.
>
> TIA
>
> Ethan
Then I can only tell you what I would do. Definitely separate sets of 
books for these separate entities. For two reasons.

a) There is no reason for any one of them to have access to the data to 
any one of them. Ideally you would be turning over to an officer of each 
school a copy of the backups* (not just give them the reports). That 
will be easier if all you have to do is copy the file.

b) The unified reports you might be asked to produce would almost 
certainly just be at the highest levels, not all the fine details. And 
you would presumably not be required to produce such a report very 
often. Perhaps quarterly, perhaps annually, yes? So you could just take 
the amounts from the corresponding reports of each school and enter that 
data into a spreadsheet << I'm not going to suggest you also use gnucash 
for this, would be more work, not necessary >>

c) If by some odd chance "b" isn't true, if the unified reports would 
need all the detail and/or they would be required very frequently, ask 
again, and I'll give it more thought. I have keep books for several  
entities, but they were really separate, no need for any unified reports.

d) If I have misunderstood your questions, if there would be no unified 
reports (how are these schools doing considered as a whole "system", the 
NO treason to even consider trying to keep in one set of books.

Michael

* That guarantees a set of backups off site (I had a house fire, not all 
backups survived the heat/smoke). A physical set, not dependent on the 
continuance of any "cloud" entity which might or might not continue to 
exist or provide free service (and could then hold data there to 
ransom). Also addresses the issue of "security" of data, that it hasn't 
been altered. A CD-ROM burnt as of some date has the data it had as of 
that time.


More information about the gnucash-user mailing list