Anonymous

My feedback

  1. 487 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    49 comments  ·  Feature Request  ·  Flag idea as inappropriate…  ·  Admin →
    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.

  2. 74 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    4 comments  ·  Feature Request  ·  Flag idea as inappropriate…  ·  Admin →
    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.

  3. 188 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  7 comments  ·  Feature Request  ·  Flag idea as inappropriate…  ·  Admin →
    Anonymous supported this idea  · 
  4. 255 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    21 comments  ·  Feature Request  ·  Flag idea as inappropriate…  ·  Admin →
    Anonymous supported this idea  · 
    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!

  5. 4 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Feature Request  ·  Flag idea as inappropriate…  ·  Admin →
    Anonymous shared this idea  · 
  6. 197 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    12 comments  ·  Feature Request  ·  Flag idea as inappropriate…  ·  Admin →
    Anonymous supported this idea  · 
    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)

Feedback and Knowledge Base