Anonymous
My feedback
6 results found
-
232 votes
An error occurred while saving the comment Anonymous
supported this idea
·
An error occurred while saving the comment Anonymous
commented
I would suggest just specifying the red line with a hard date, rather than by a number of days. If I close out a year in January, I want all transactions after Dec 31 in the prior year to become read-only. It doesn't really matter how many days ago. It matters when my last hard-close was (typically at the end of a year, a quarter, or a month)
-
576 votes
An error occurred while saving the comment Anonymous
commented
Hajo and Vincent are on the right track. I implemented this in a custom accounting program written for my company a few years ago. We settled on these three orthogonal dimensions:
Accounts:
Traditional accounting of assets, liabilities, equity, income, expenses, and appropriate sub-accounts of each. This is useful for getting to a tax return, or knowing things like net income.Categories:
In traditional accounting, we usually only do detail categories on expense accounts. This is probably just tradition. But also because it is difficult to do on things like assets and liabilities. But sometimes, it is very useful to know how much fuel, or electricity, labor, or materials went into a capital asset. By having separate categories for these, you can see how an asset breaks down, just as easily as we now determine how our expenses break down.Projects:
These have more to do with accountability, job costing, etc. At the highest level, a project can be a separate business unit. At lower levels, it can be used as an alternative to traditional accounts (like having a separate project number for different bank accounts, all under Current_Assets::Cash). A project can track the assets in a property, or department. It can also contain expenses, all applicable to that property or department. It is really fun when you can build a separate budget for each project, and then track performance against a budget goal.Projects can benefit greatly from a hierarchical structure, like accounts. Categories can be hierarchical, but they work fine in a flat format too.
-
89 votes
An error occurred while saving the comment Anonymous
commented
If, instead the development team focuses on a true, concurrent, multi-user SQL backend, writing custom reports would be a breeze, using a variety of already existing database tools, or even cooking your own. Writing reports in Gnucash is possible now, its just very difficult. If the data were available in sql tables, people could even write their own views (using existing SQL skills) and expand the universe of reporting very quickly.
-
194 votesAnonymous
supported this idea
·
-
308 votes
Concurrent multi-user support has been part of our long-term goals for a while now:
http://wiki.gnucash.org/wiki/Roadmap#Database_and_QOFTime to update the status of this feature request…
Note it still says “long-term”, which currently means several years ahead of us.Anonymous
supported this idea
·
An error occurred while saving the comment Anonymous
commented
As I read the FAQ about SQL support, it sounds like the code base might be moving slowly toward this goal of multi-user support. I hope that is the case. I would benefit greatly from being able to make a change in the sql tables and have that propagate back into any instance of gnucash that might be accessing the database (i.e. model-view-controller). This would open the door to web-based view's being developed that can access a gnucash model running on a server somewhere. That would be awesome!
-
4 votesAnonymous
shared this idea
·
I would really like this feature!