Re: Request: Enhancement in Use of Account Codes
Geert Janssens wrote: Maybe it would be good to get an overview of typical accounting issues/agreements in Europe to see if some more general improvements could be made towards European users ? Maybe you are looking for something like http://bugzilla.gnome.org/show_bug.cgi?id=473506 My understanding for the reason of the current situation is that there is nobody fitting all of the following description. 1) can code 2) has time to contribute code 3) business user 4) lives in Europe I fit 3 and 4. I currently think that trying to get gnucash into shape for business users is unlikely to happen even in the medium term. I use gnucash when it is the right tool and thank Phil for providing us with the SQL backend which then allows me to access the accounting data for reporting and manipulation from other SQL tools. AFAICS, it currently is the only sane way to handle this. - Rolf ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Request: Enhancement in Use of Account Codes
My understanding for the reason of the current situation is that there is nobody fitting all of the following description. 1) can code 2) has time to contribute code 3) business user 4) lives in Europe I fit 3 and 4. I currently think that trying to get gnucash into shape for business users is unlikely to happen even in the medium term. I use gnucash when it is the right tool and thank Phil for providing us with the SQL backend which then allows me to access the accounting data for reporting and manipulation from other SQL tools. AFAICS, it currently is the only sane way to handle this. IMHO you do not want a person who meets all those criteria. And the additional criteria can design (not the same as coding) and can test/has time to test. Those criteria define the TEAM you want to assemble. Some of the hats can be worn by the same person but it is actually a rather bad idea if one person is doing the whole thing. Unless a program hangs or loops, if what it is SUPPOSED to do has not been properly specified, then it must be doing the right thing (whatever behavior it exhibits is what it does, there is no outside criteria of rightness. The business USER in conjunction with a BUSINESS ANALYST constructs the requirements (definition of what is needed). Alone the USER is unlikely to consider all the rare situations since from an end user point of view, what a system usually does is what is in their mind. The SYSTEM ANALYST in conjunction with the BUSINESS ANALYST designs the system. The PROGRAMMER in conjunction with the SYSTEM S ANALYST implements the program. The TESTERS in conjunction with the PROGRAMMER test the system according to the test plans devised by the BUSINESS ANALYST and SYSTEMS ANALYST and the USER usually is involved too (but in MY work, I would have been embarrassed if the user ever got to see something not working correctly; that final sign off should be a formality of the other pros have done their jobs). I do not mean to imply it has to be formal titles or different people -- but these are hats, many of which I have worn, sometimes several on the same project but that's not easy or the safest thing to do. While wearing one hat must somehow keep from considering the problem too much from the other person's point of view (when designing, should NOT be thinking how am I going to code that?). Only to the extent necessary (when coding, always thinking what test data/process will be necessary to test every bit of logic -- perhaps building the test processes at the same time as the main program). Michael D Novack, FLMI ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Request: Enhancement in Use of Account Codes
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. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Request: Enhancement in Use of Account Codes
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 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Request: Enhancement in Use of Account Codes
Mike, thank you for your mail. I am sure you have great experience in developing software, I am not questioning that. I am not sure your experiences, the analytical approach, division of labor (hats as you described them) which I would consider best practice in any kind of business project can easily be transferred to gnucash or any other FOSS project. I've never seen you around before, but you seem to have valuable knowledge. What is it that you are suggesting and what role do you see for yourself in that? How long have you actually been following what is going on with gnucash development? Regards Rolf PS: My experience is that most FOSS projects are much more evolutionary, chaotic and nonlinear than what theory may prescribe. It is not as the project manager requires but scratching greatest itch that determines what gets done, usually. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Request: Enhancement in Use of Account Codes
I am not sure your experiences, the analytical approach, division of labor (hats as you described them) which I would consider best practice in any kind of business project can easily be transferred to gnucash or any other FOSS project. The only real difference is that it's voluntary. Nobody paying the bills and so nobody in a position to say do thus and so. I agree with you very much that I do not see standard software development process being used in FOSS. Could that the the reason for some of the problems? User expectations? My sense is that users do not seem to understand their role in the process. When I was PAID to do this sort of work, I might have had to tolerate a user who wasn't willing at first to do more than tell me it's broken, fix it. In other words, my job to help this user and so would devote as much time in as many meetings as necessary to tease out what the users ACTUALLY need till there was a clear understanding of what the darned thing was SUPPOSED to do. I certainly wouldn't bother to take a look at the code until that was out of the way. Unless there is a clear understanding of what the program is supposed to be doing DIFFERENTLY, it ain't broke. It's working perfectly well (doing whatever it does) right now. I'm an analyst, not a mind reader, can't guess what it is that the users really want/need (often NOT what they initially say that they want/need). I've never seen you around before, but you seem to have valuable knowledge. What is it that you are suggesting and what role do you see for yourself in that? How long have you actually been following what is going on with gnucash development? Almost two years. Had a house fire November 2006 which took out the hardware and software on which the organizational books were kept. At the same time as reconstructing the books the old fashioned way on paper, began a parallel with GnuCash, and recommended adoption of this software instead of replacing the commercial package. In terms of standard bookkeeping (auto posting ledger) I've never had the slightest problem with GnuCash except for the annoyance of not being able to set up properly under all legal Windows* user names. I've been watching both the user and developer lists since, and consider that my professional expertise should be available to the project. I've done a few hundred thousand lines of code in my day, all in financial applications. Never worked in any of the languages GnuCash is in but that's not really relevant (not when you are fluent writing in half a dozen and can read most anything -- pretty fast to add one more). Anyway, I don't see the real bar to getting things done to be lack of programmer availability as much as the lack of user commitment to do their part of the process. I've seen lots of complaints doesn't do this or that but not one presentation of a business spec of what a group of users would want differently. Complaints that the the programming developers aren't doing their job misunderstands the problem. They aren't being given a clearly defined proposal. Thus --- asking please have GnuCash create the xyz report such that it meets county C's reporting requirements is NOT how you properly frame a request to a programmer. It's not the programmer's job to look up the regs of country CD and find sample reports meeting these regs, etc. That's the user's job, assisted by the business analyst (who might not initially know the answers but knows how to tease those out of the users). Very important to have all the loose ends defined, because in reality, perhaps 80% of the coding of any real life software project is dealing with the exceptional conditions the end user doesn't even think of as potentially existing (unitl the business analyst begins asking questons). Michael D Novack, FLMI * That I might be perfectly happy running under a 'nix OS besides the point. Only one other board member of one organization and none on the boards of any of the others would, so software caapble of running under Windows a must. Might not always be treasurer. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Request: Enhancement in Use of Account Codes
Let's agree to disagree on the facts instead of wasting more time on trying to win an argument, OK? You have your perspective, I think it does not apply. I stated my perspective based on my experience over the last two years or so actually working on the kind of support that we are now theoretizing about. You did not mention which role you intend to take in this, I guess youI don't intend to take on a role. I see the value in doing, not in theoretical arguments how things should be done. Over and out. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Problems with dbi-connector and mysql
Hi Oliver, a few things: 1) Since this question involves software which has not been released yet, it should really be on gnucash-devel, not gnucash-user. 2) What are you running on? Linux? Windows? What distribution? 3) Assuming you are on Linux, do you have a file /usr/lib/dbd/libdbdmysql.so (maybe /lib/dbd/libdbdmysql.so). Phil On December 25, 2008 03:11:59 pm Oliver Brandt wrote: Hi! thank you very much for gnucash. I've been using it for quite some time to do my personal finances and it works great. Now I'm trying to help a friend of mine, who needs to do accounting where multiple people can work on the same data. So I thought of a combination of gnucash and mysql. After researching for quite a while, I found out that the dbi connector seems to be the way to do it. I spent about 4 hours to get gnucash to build properly with the dbi-connector. But now I'm stuck getting it to connect to the mysql database. I've installed a clean version of mysql and executed the following mysql-command to have full access to the database: GRANT ALL ON *.* TO oli...@localhost IDENTIFIED BY 'x' WITH GRANT OPTION Now I've tryed both the save and the load button in the database connection outions. I staid wit the default options: server: localhost database: gnucash user: oliver password: xxx I always get the message the following url could not be processed: mysql://localhost:gnucash:oliver:eis3Shia original german message: Die folgende URL konnte nicht verarbeitet werden. Same situation after I have created the database gnucash with CREATE DATABASE gnucash. I'm really stuck and I could not find any more information neither through google nore by reading the archives. I would really appreciate it if you could point me into the right direction or towards some howto or something similar. Thank you very much! Merry Christmas! Oliver ___ gnucash-user mailing list gnucash-u...@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-user - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
