Request: Enhancement in Use of Account Codes

Mike or Penny Novack stepbystepfarm at mtdata.com
Thu Dec 25 11:44:36 EST 2008


Rolf Leggewie wrote:

>Mike or Penny Novack wrote:
>  
>
>>IMHO you do not want "a person" who meets all those criteria.
>>    
>>
>
>Mike, thank you for your reply.
>
>While your theoretical description may be correct, I think I have 
>accurately summed up why in reality gnucash is not moving forward for 
>European business users.  That is, there is no person who can actually 
>code with time on their hands, an interest and an understanding of where 
>gnucash currently falls short.
>
>A number of bugs were recently closed as wontfix with the idea of 
>"support for European/German business users is out of scope for 
>gnucash".  That is because all people concerned are well aware that it 
>won't happen anytime soon inside gnucash and thus it may be better to 
>pursue solutions outside of gnucash bolted on to the gnucash data.
>
>  
>
Well first of all, "bolted on" MIGHT be the appropriate solution. That 
is precisely the reason for my "theoretical description" of the 
development process.

A "bug" is a program not doing what it is SUPPOSED to do (doing 
something wrongly). Failure to do something that was never part of the 
specifications is not a bug, it's a user request for development work. 
But to have jumped ahead from the "this is what I need" to "THIS 
application should be changed to provide that functionality" is an 
error. First the end users and the "business analysts" decide what is 
needed. Then decisions are made how to best fill that need.

I faced this directly as I am both an end user and somebody quite 
capable of designing/coding --- all aspects of a project from inital 
user requirements analysis through final acceptance testing* -- though 
as I have already said, not great if wearing too many of the hats. In my 
case it was getting from the reports produced by GnuCash (income-expense 
statements, balance sheets, etc.) to the final form of the 
organizational financial statements as would be presented to the board 
of directors and filed with governmental agencies. I was advised NOT to 
try to add "finished form", that no accountant would want that, that 
they would simply take the reports as generated to be the data they then 
used to fill in a proper GAAP format report. And that they normally do 
this "by hand".

BUT -- let's say that I was going to do that. Would it end up as "part 
of GnuCash"? (part of the same executable). Probably not. It would 
probably be a stand alone application which accepted as input the 
reports as produced by GnuCash plus some fixed test files but functioned 
more or less as and "editor" allowing the accountant to insert the 
necessary "notes" and texts. That, by the way, was why I was told "don't 
bother". Any accountant already has preferences as to which editor 
application he or she prefers to use and all of them allow the pasting 
in of the GnuCash reports and the fixed descriptive texts as a starting 
point.

Point is, I don't have to live in Europe to design/code what you need. 
You assemble the European end users and agree on a specification of what 
you need done, what your "business requirements" are. Then we see 
whether what you need is for GnuCash to do this for you, some stand 
alone system that takes feeds from GnuCash (that can still be part of 
the GnuCash PROJECT), or something completely independent. Understand? 
Simply saying "GnuCash doesn't do what we need done" is not enough to 
get my attention. If I'm helping you with the "requirements phase" then 
I would probably rule myself out as a resource for later phases because 
wearing too many of those hats clouds judgement -- you need more 
distance from some of the decisions.

The "business requirements" phase is NOT a trival part of the process.

Michael D. Novack, FLMI

* I'm a retired very senior sort of analyst who used to do this stuff 
for one of the world's largest financials


More information about the gnucash-devel mailing list