SQL - simultaneous GC access ? << the need for an "analyst" >>

Mike or Penny Novack mpnovack at mtdata.com
Mon Jan 4 11:12:54 EST 2016


On 1/2/2016 10:06 PM, __ wrote:

> 4.) is there any plan to regulate access to certain parts of the accounting
> to certain users? (for example a merchandiser being able to make supplier's
> bills but not being able to access/see salaries)

I am going to use this apparently reasonable request to explain what a 
"business analyst" does and that "end users" need one in order to 
properly frame their requests.

A business end user knows his or her business and may have a very good 
idea of the business needs at the business level. But a the same time 
might have a poor understanding of how that might best be implemented 
(at the business level). In other words, ask for specific changes at the 
application level not realizing that these changes would NOT provide 
what is actually being asked for. This request is a perfect example, so 
I will analyze it to show you what I am talking about.

Let us assume for just a moment that the gnucash application COULD do 
this (restrict users to specific accounts). WOULD that prevent a 
"merchandizer" with just access to the accounts necessary for his or her 
job from being able to obtain salary information? << does NOT have 
access to any of the payroll accounts >>

The answer is NO. Not if the same checking account is used for checks 
paying for merchandize purchases and checks paying employees. Do you see 
why? And BTW, that's how the analyst gently points out to the business 
client the problem, by looking at the situation, seeing the hole, and 
asking the right questions.

OK then, need separate checking accounts, no big deal << or maybe 
"merchandizing" only produces vouchers, doesn't actually cut checks.>>

But then, is that change to the application really necessary? Well maybe 
not. The usual method in the larger business world is "subsidiary 
books". And this makes sense, because the CEO or Directors aren't going 
to be interested in seeing each low level transaction but the totals. In 
other words, the Treasurer (and his or her staff in a large operation) 
can access all the books and maintain the "general ledger" which mirrors 
the nets of the subsidiary books. But in each area of specialization, 
the employees doing that work can only access the subsidiary books of 
their area. That needs just security at the file level, and gnucash in 
effect has that right now << well it's at the operating system level >>

Look, before retiring, this is what I did (at one of the world's largest 
"financials"). Besides analyzing at the system level (estimating the 
effort to fill a client request, designing the software, etc.)  user's 
planning their requests could ask one of us analysts to sit in an help 
them frame their requests so if they got what they asked for it would 
actually do what they wanted and not be useless.

So what I am saying is that if you have a "business need" (that can of 
course be for personal accounting too) ask at THAT level instead of 
making requests for specific changes at the application level which 
might or might not have the desired end result. To go back to the 
specific example, might have been "can we have something so that workers 
in some sub section of the business ("receivables", "purchases", 
"payroll", etc. ) can only see that part of the overall business system 
that they need to into order to do their job". But not making that 
request at the specific change to the application level (security at the 
account level).

Michael D Novack


More information about the gnucash-user mailing list