Skip to content

Anonymous

My feedback

6 results found

  1. 222 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    Anonymous commented  · 

    I would really like this feature!

    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)

  2. 572 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    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.

  3. 87 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    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.

  4. 194 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Anonymous supported this idea  · 
  5. 309 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    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!

  6. 4 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Anonymous shared this idea  · 

Feedback and Knowledge Base