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