Matt, I again applaud your promise (threat?! ;) ) to update the slim information about the Budget section. As you do, be sure to look through the list archives and the wiki for any information you might draw in to the Tutorial; there have been numerous discussions over the years about how to use them. Personally, I would love an explanation of how the Budget reports can be used; I have never been able to figure them out (beyond a few rudiments).
Cheers, David > On Feb 14, 2018, at 2:53 AM, Matt Graham <matt_graham2...@hotmail.com> wrote: > > 😊 I think I would love to sit down in a pub with the three of you (Wm, > Adrien, and Mike). I think we could have such awesome semi-drunken > discussions about the nature of life, the universe and everything! > > I think you have basically answered my question, and I think we all basically > agree on the rough direction things *should* go in (separate interacting > packages). I’m just not sure how to help make it happen (I’m an enthusiastic > amateur when it comes to programming). I think I’ll start by updating the > budget part of the tuts and concept guide like I have promised elsewhere, and > then start looking into how the C++ modules have been structured (to see what > connection will be possible within the 3.0 releases). > > Thanks and regards, > > Matt > > From: Adrien Monteleone<mailto:adrien.montele...@gmail.com> > Sent: Wednesday, 14 February 2018 2:31 AM > To: gnucash-devel<mailto:gnucash-devel@gnucash.org> > Subject: Re: Scope of GNUCash > > Michael, > > I agree completely on the separation point, especially with regard to > controls. > > I’ve seen first hand when sales clerks have the ability to void and edit > their own transactions from a point of sales system. I can’t imagine the > damage that WOULD be done if they also had the ability to access the > inventory system AND the general accounting software. (even just the ability > to partially close a ticket is dangerous) > > As for interoperability, the devil is always in the details but I see three > main hangups. First, any software should be able to import it’s own exports. > Second, any software with imports should be able to allow the user an easy > way to map fields and save that mapping for future use. Third, importing and > exporting should be possible to schedule or trigger without manual user > intervention. (so apps can talk to each other reliably without lag) > > I think 3.0 is going to partially address the first and second case. I don’t > think the third is contemplated yet. The third is also dangerous for > accounting so it should be very carefully implemented and certainly not a > default condition. > > Regards, > Adrien > >> On Feb 13, 2018, at 8:10 AM, Mike or Penny Novack >> <stepbystepf...@dialup4less.com> wrote: >> >> On 2/13/2018 2:55 AM, Wm via gnucash-devel wrote: >> >>> >>>> A couple of times I have noticed that people have said "That's not what >>>> GNUCash is for". It begs the question - where is it defined what GNUCash >>>> is and isn't for? The charter for GNUCash doesn't seem to ever been >>>> formalised. >>> There is a long term plan, we never write it down because people ask us >>> about it :) Is it intended that people should establish a complementary but >>> separate project for functionality they want, but is not included in >>> GNUCash scope? >>> >>> I don't see why not if that is what they want to do. >> >> Since I have been one of the people arguing for "separation" (I think this >> is being misunderstood) I want to clarify the reasons and what I mean when I >> use the term. >> >> a) I do NOT mean that needs to be a separate project. Could be part of a >> PACKAGE (even installed together) but not a single program. >> >> b) The reason for separate "packages" that interact with each other rather >> than a single program (that a user is or is not allowed to use) is so that >> ONE "system" (interacting parts) can be used for all. Those people who are >> running "one man band" businesses do not see the problem, do not see why >> things like (proposed extensions) like "inventory", "point of sales", >> "payroll", etc. cannot be PART of the "general ledger" program. Call these >> "one man band" users businesses of class A. >> >> But there is another sort of business user, call these class B. They have >> employees, they have division of responsibility and authority. They may have >> need of safeguards. I am not meaning JUST businesses since even a larger >> non-profit (call these class C, they might have other needs too) might need >> safeguards making embezzlement more difficult. >> >> These need separation. They need to be able to have people "log in and use" >> things like an inventory system or "point of sales" system WITHOUT being >> able to access "general ledger. Does not have to be a very large small >> business before it has people waiting on customers, stocking inventory, etc. >> These people need to be able to do their jobs without being able to access >> "general ledger". >> >> c) A solution with separated subsystems that feed each other would satisfy >> the needs of these entities (class B and C) while at the same time satisfy >> the needs of entities of class A. The reverse is not true AND not practical >> to "first build what would just work for class A and then modify that to >> work for classes B and C". That would be pretty much a complete rewrite. >> >> d) However, the IS a common element for all the proposed additions (if >> separate). They need a way to FEED (send transactions to) general ledger. So >> general ledger (gnucash as it is) would need a way to accept feeds. And that >> includes a component to "input edit" feeds (make sure all the transactions >> coming in are valid, in balance, accounts they refer to exists, etc.) so >> that "general ledger" can reject (hopefully with meaningful explanations of >> the problems) a feed. >> >> e) Not discussing at the present time feeds that might be required between >> these proposed extensions. For example, we would want a point of sales >> system to feed an inventory system. But things like that would not be "in >> common". Likewise not yet discussing safeguards (if a feed was not accepted, >> how is the system producing this feed temporarily blocked from adding to it. >> However I will say that to start, these systems should be designed to work >> "asynchronous batch" and only later consider expanding to supporting "real >> time update". Again this is a matter of "would work for all" while small >> entities could not safely make the assumption that all parts are up << and >> even some VERY LARGE entities do batch feed to general ledger --- I worked >> for the 43rd? largest "financial >> >> >> Michael D Novack >> >> >> >> >> >> _______________________________________________ >> gnucash-devel mailing list >> gnucash-devel@gnucash.org >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.gnucash.org%2Fmailman%2Flistinfo%2Fgnucash-devel&data=02%7C01%7C%7C4a12e32a892c49373cb808d572f6dd24%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636541326963734686&sdata=uRhoUkj5Wgq%2BKV9DwRsPujzdXLgbGE8BmoKVI9ryR2g%3D&reserved=0 > > _______________________________________________ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.gnucash.org%2Fmailman%2Flistinfo%2Fgnucash-devel&data=02%7C01%7C%7C4a12e32a892c49373cb808d572f6dd24%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636541326963734686&sdata=uRhoUkj5Wgq%2BKV9DwRsPujzdXLgbGE8BmoKVI9ryR2g%3D&reserved=0 > > _______________________________________________ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
