There already is a module system which is how the business features were brought in, but my understanding is that the plan is to remove this in favor of a full and proper SQL backend which would make pulling or inserting GnuCash data trivial for interoperability with other packages so GnuCash can focus on accounting instead of the kitchen sink.
On Sunday, February 4, 2018, Matt Graham <matt_graham2...@hotmail.com> wrote: > So there really is more than one way to skin a cat... or make a budget. > Whatever. > > Since we are talking about something very personal to the needs of > individuals, perhaps Gnucash needs a ‘add module’ system, where we can > write modules that perform data access and manipulation? So we could write > an “envelope budgeting” module that can overlay in the Gnucash environment. > > Seems a waste to have to export to another tool to do a small part of > budgeting. > > Thanks and regards, > > Matt > > From: Mike or Penny Novack<mailto:stepbystepf...@dialup4less.com> > Sent: Monday, 5 February 2018 3:12 AM > To: email@example.com<mailto:firstname.lastname@example.org> > Subject: Re: Future allocated money vs Budgets > > On 2/4/2018 1:21 AM, Christopher Lam wrote: > > Looks nice. My main concern with these "shadow accounts" is that they > will, > > by default, be counted in the Net worth reports, income reports, etc, and > > must be manually deselected every time. > > > > In my view budget allocations are technically "outside the books" and > must > > therefore ideally be recorded in ways that don't affect the everyday data > > and reports. > > > The problems people have been discussing are really "work flow" and "how > done" issues. > > a) As noted in the second paragraph, technically "outside the books". So > ONE solution is to do just that, a separate set of "books" (gnucash can > handle many). That obviously would mean no effect on reports run against > the regular books. And of course that could be using the built in budget > facility. > > b) But it seems most would prefer not having to switch books to record > the effect on budget items resulting from the real transactions. I can > think of MANY ways to put the "budget" accounts so that they would have > no net effect on reports, total of the parent standing accounts (asset, > liability, equity). What I can't see is any easy way to "automate" > because IN GENERAL users, especially non-organizational users, will be > ADJUSTING budget allocations on the fly as needed << don't need a vote > of some board to authorize that >> > > c) Some people seem to be confused about "liabilities" thinking that > they NECESSARILY represent an actual debt (the most common use) instead > of possibly representing a CONDITIONAL debt. I will note that some of > the things I have mentioned in this context (especially for non-profit > orgs) may be changing << I have heard that new accounting practice will > allow some restricted funds not to be considered liabilities > until/unless something prevents their use for the intended purpose > instead of as now from the get go as a conditional debt* >> > > d) IF I wanted to put the "envelopes" in my main books, I could put them > under assets, liabilities, or equity WITHOUT affecting the totals of any > of those. Thus: > Budget (the parent) > Total allocated funds (debit side?) > Allocations (credit side?) > Each individual envelope > << all that matters is that Total Allocated Funds and > Allocations be on opposite sides --- which means the total for the > parent "Budget" will be ZERO >> > > Michael D Novack > > * In my practical experience, donors of conditional gifts or grants > often will agree to a change of use, extension of time to use, etc. But > I have never had to deal with governmental grants, etc. which I suspect > would be less forgiving. But I also have practical experience where ALL > there is is budget accounting << the organization or committee has no > funds in hand --- the budget represents what will be reimbursed if the > committee votes to authorize an expenditure and some committee member > goes out and spends the money --- and then submits the receipts to the > town treasurer for reimbursement. The committee must track "how much do > we have left to spend" or somebody will be out of pocket >> > > > _______________________________________________ > gnucash-user mailing list > email@example.com > To update your subscription preferences or to unsubscribe: > https://nam02.safelinks.protection.outlook.com/?url= > https%3A%2F%2Flists.gnucash.org%2Fmailman%2Flistinfo% > 2Fgnucash-user&data=02%7C01%7C%7C83bd3ce9f801415c935008d56bea0556% > 7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636533575212166479&sdata= > 3MNjRS39Z12eOjBWLUx6JajL0rRyHYThwC7E%2F7Sln%2FM%3D&reserved=0 > If you are using Nabble or Gmane, please see https://nam02.safelinks. > protection.outlook.com/?url=https%3A%2F%2Fwiki.gnucash. > org%2Fwiki%2FMailing_Lists&data=02%7C01%7C%7C83bd3ce9f801415c935008d56bea > 0556%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0% > 7C636533575212166479&sdata=zTHJC9ALUjbF1jbL56Aixwk2i4PMBi > YUYxLlsG6JMvI%3D&reserved=0 for more information. > ----- > Please remember to CC this list on all your replies. > You can do this by using Reply-To-List or Reply-All. > > _______________________________________________ > gnucash-user mailing list > firstname.lastname@example.org > To update your subscription preferences or to unsubscribe: > https://lists.gnucash.org/mailman/listinfo/gnucash-user > If you are using Nabble or Gmane, please see > https://wiki.gnucash.org/wiki/Mailing_Lists for more information. > ----- > Please remember to CC this list on all your replies. > You can do this by using Reply-To-List or Reply-All. > _______________________________________________ gnucash-user mailing list email@example.com To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.