Class accounting?

[Beth Leonard]

It's a nice summary, perhaps we don't understand your
needs sufficiently.  The way you have described your
needs other users of gnucash have suggested solutions
that work for the majority of gnucash users.

You may wish to look into the business features of
gnucash in particular "customer" and "job" features -- maybe
a "job" is what you think of as a "project".  It allows
you to assign venders and invoices, create reports by
vendor, etc.

I do not often use those features, my business is simple
and the overhead does not create sufficient value-add to
the reports to be worth it, but if your reporting needs are
more complex, going through the more complex interface to
enter the data may be what you're looking for.  If you do
decide to go with the business features, look back through
the archives, someone recently posted how to keep a report
open that makes it a lot easier and less clunky to access
invoices and reports.

In short, accounting is hard.

Once you start to want to look at your money with multiple
views you have to be careful with how you set it up.  Major
companies have scandals all the time because they thought
they had more money than they did due to accounting irregularities.

--Beth

On Tue, Jul 03, 2007 at 03:41:28AM -0700, Jeff Wiegley wrote:
> Well, I was composing a nice long response to Daniel's message
> but in the end found that his small quips to me added up to
> probably as much as he found my postings insulting. Sorry
> Daniel.
> 
> So I guess since I'm insulting everybody with my discussion
> I'll just deleted that response for fear of ticking everybody off
> even more. I'll just summarize for posterity in case some other
> poor Joe needs project accounting like I do and he can google my
> thoughts in the mailing list archives in the future and save
> himself the embarrassment of also being offending. Then I'll
> leave you all alone. Current members need neither read this
> nor reply; I guess it's just a record of my conclusions.
> 
> here's the summary: I need project accounting.
> 
> My original question was basically: "In gnucash, how do I account
> for transactions related to a project so that I can attribute costs
> and profit to a project."
> 
> Suggestions given:
> 
> Use split transactions. This is not an answer as it solves an
>    entirely different, and useful, problem. (That is it aggregates
>    the debit/credits from several other accounts under a single
>    credit/debit in a target account.) Extremely handy for many things
>    including ATM deposits containing multiple checks, Purchases
>    for multiple items on a single invoice. Salary deductions and
>    Loan payments. I have used split transactions for years in
>    Quicken. None of this satisfactorily accounts for project details.
>    Conclusion: off topic for project cost accounting.
> 
> Self suggestion: Use Quicken instead. It also doesn't do project
>    cost accounting. I'll grant it doesn't even do vendor accounting
>    properly since it sort of maxes out with "categories" and
>    categories which are really nothing more than glorified
>    description fields. Quicken small business does start to
>    provide proper vendor support but is hiding the fact that
>    vendors are accounts and that double-entry is taking place
>    behind the scenes. Ok, use Quickbooks. That's where I'm tending to
>    now. I'm a fan of open source. I've made a career based on it.
>    I would like to switch to gnucash to avoid feeding corporate greed
>    and having to deal with a Windows platform for the sole purpose of
>    tracking accounting information. I would rather be delighted if
>    gnucash could meet my needs. Even if that's done in an unorthodox,
>    yet complete and accurate manner.
> 
> Make every project an account. summarize all vendor expenses or
>    purchases under that catchall account. This is not acceptable
>    because it produces gnucash account registers which do not
>    correlate to financial statements. Your bank statement will say:
>    "Paid $X to V" Where X is a dollar amount and V is a vendor.
>    Gnucash will show "Paid $X to P" where P is a project. It is now
>    a manual, doable yet error prone, process to cross-reference
>    account and statement line items. Gnucash has also lost all vendor
>    information with this scheme. Conclusion: unsatisfactory due to A)
>    loss of information and B) discrepancy between account and
>    statement.
> 
> Augmentation: Do the previous suggestion but also record the
>    vendor's name in the transaction description. Conclusion: better.
>    solves loss of information. Same discrepancy problem; statement
>    says A->V while gnucash says A->P. Also error prone. Descriptions
>    are arbitrary and prone to error. Were the other entries Ralphs,
>    ralphs, Ralph's or Ralph's groceries? Vendors and/or projects
>    should be one time creation items and then picked from a discrete
>    list for each transaction to prevent errors such as typos.
> 
> Better augmentation: Make accounts for Vendors, place project names
>    in the descriptions. This is an improvement. Statements and
>    gnucash both indicate A->V. Only problem now is that projects
>    can also be mistyped in the description field yielding the same
>    report integrity problems when making queries about project costs.
>    Was it doomsday or Doomsday, I forget. similar problem to previous.
>    But this is the most accurate, complete method that I currently
>    understand gnucash being able to support.
> 
> Use subaccounts. make every project an account and then under each
>    project make subaccounts for each vendor. No loss of information
>    little possibility of typos since accounts are one time creation
>    items. Conclusion: problem exists with reporting integrity and
>    and accuracy. Also suffers lack of conceptual cohesion by having
>    single vendor account accounted for in multiple independent
>    locations. Reports can be inaccurate by failing to mark all
>    appropriate accounts for inclusion or by having the same types
>    of typos in names.
>      Expenses:Doomsday:McMaster
>      Expenses:Gardening:Mcmaster-Carr  (oops)
>    Possibly on par for accuracy and completeness as previous
>    solution. Better due to discrete nature of Projects preventing
>    some typos, poorer due to increased complexity of account levels
>    while not adding additional capability or integrity. I'm tied
>    for acceptability between this suggestion and the previous if
>    I move forward with gnucash.
> 
> reverse you subaccounts:
>    Expenses:McMaster:Doomsday
>    Expenses:Mcmaster:Gardening
>    Same problem, Doomsday might be entered "Doom's day" under a
>    different vendor. Single items should be implemented in a single
>    manner and should not rely upon tricks of nomenclature to suggest
>    meaning. Imagine if mathematics texts did this: Let X be the
>    square of the hypotenuse of a right triangle, let Y be the square
>    of one the legs and let a different X be the square of the remaining
>    leg.
>    Then:
>        X = Y + X
>    therefore, through algebraic manipulation, one might incorrectly
>    assume that:
>        0 = Y
>    (although in this the same name is representing independent
>     variables versus the account being specified in independent
>     locations. it no less presents an example of the type of problem
>     you can get in to with tricks of nomenclature.) Labels are
>     arbitrary, the underlying objects should accurately and closely
>     implement the concept instances they represent. Nomenclature
>     should not be relied upon to enforce behavior.
>    Also suffers from A->V versus A->P problem.
> 
> I also want to put forth this observation:
> Projects should not be accounts. Accounts have assets of measurable
> financial value. Projects do not; they are virtual. Project
> accounting is primarily intended to serve the internal analytical
> needs of a company. Accounts serve external account reporting
> needs as well as internal. (please don't nit pick my summary, I'm
> fully aware that many organizations need to report project
> activities and success to external agencies as well as for internal
> use. I'm just trying to lay the groundwork for my conclusions.)
> As I think about it, transactions happen between accounts while
> Projects are more the cause of the transaction, not the source or
> destination of the transaction. I'll spend a lot of time next
> week with a CPA of forty+ years of accounting and financial
> management experience and see if I can't get a better understanding
> of this. Maybe I'm wrong and hopefully I'll figure that out next
> week. But I'm willing to stack up the accuracy and completeness of
> my personal and business accounting records to those of anybody
> else. I'm pretty sure I've got an excellent grasp of accounting
> principles already.
> 
> I apologize if I missed anybody's suggestions; I think I covered
> all the methods suggested. I also want to point out that I know
> some of the negative analysis points are manageable given small
> numbers of projects or vendors. If you have three projects, it is
> relatively easy to manually verify the spelling of accounts or
> descriptions and to verify account inclusion in reports. But for
> larger numbers of projects or vendors and given that the system
> may need to be operated by a variety of employees who may not
> understand database concepts like normal forms and such these
> analysis points are valid. gnucash should address them if it is
> intended to compete with the likes of QuickBooks or Peachtree. If
> the gnucash goal does not include robust enterprise accounting
> features then, of course, I am out of line and this is all moot.
> 
> I close with an implementation suggestion.
>    GnuCash should support an editable list of "classes" or "causes",
>    to provide a name for projects ("projects" seems too specific
>    and there may be activities or reasons one wants to attribute
>    transactions to that would not fit the definition of a project.
>    For instance process management policies and practices might
>    cause/incur monetary transactions and would nearly be the
>    antithesis of a project.)
> 
>    Each transaction should have a field allowing it to be associated
>    to a single specific class and a direction (whether the direction
>    of value flow should be counted as a credit due to the project or
>    a debit. The association would not affect any information about
>    the accounts the transaction actually took place between.
> 
>    The class could then be viewed as a pseudo-account. whereby the
>    "view" would simply locate and present all transactions tagged by
>    the class and list the transaction as a debit or credit to this
>    pseudo-account based on the bias of the direction assigned to the
>    association.  No method should be provided for the editing of
>    the virtual transactions presented in the pseudo-account view of
>    a class. (You couldn't add, delete or modify line items in the
>    pseudo-class view.
> 
> Though I may have to give this some more thought as it is not
> entirely clear to me yet whether one to one associations between
> classes and transactions are sufficient to properly represent
> enterprise business accounting practices and I have a few tugs of
> doubt about the existence of other unrecognized insufficiencies.
> For instance: subclasses I quickly think might be useful. I
> have advanced project needs but I certainly wouldn't call them
> enterprise class so I could be missing something useful to those
> fish larger than myself. But I think any change to gnucash like
> this should be designed cleanly and well enough to ultimately
> support an enterprise environment.
> 
> Thanks for your help,
> 
> - Jeff
> 
> Daniel wrote:
> > Jeff Wiegley wrote:
> >>> No, you create accounts for each *project*.  You can create
> >>> sub-accounts for vendor.
> >>
> >> That does not work.
> >>
> >> A single vendor can support multiple projects. Which project
> >> should you stash that vendor under? Whatever you select is wrong.
> > 
> > 
> > Expenses:Projects:Doomsday Weapon:Ralphs
> > Expenses:Projects:Gardening Robot:Ralphs
> > 
> > 
> >> Each invoice or receipt (or even portion of a receipt) should
> >> be attributable to any project account
> > 
> > Split transactions.
> > 
> > 
> >>>> The problem is that this doesn't extend to projects.
> >>
> >> see?
> > 
> > Actually, I don't. I don't understand what you mean by extend.
> > 
> >>>> But I can't put the McMaster account under "doomsday weapon"
> >>>> because then all purchases for the gardening project also
> >>>> get accounted for under the doomsday project. I can't put
> >>>> McMaster under the gardening project for the symmetric
> >>>> argument.
> >>
> >> And there is my example of why you can't have projects as
> >> accounts and vendors as subaccounts. Unless I guess you are able
> >> tp create two different subaccounts under their respective projects
> >> accounts with the same name.
> > 
> > Yes.
> > 
> > Expenses:Doomsday Weapon:McMaster
> > Expenses:Gardening Robot:McMaster
> > 
> > 
> >> But that is also asking for trouble
> >> which I am not going to get into here unless you want me to. The
> >> problem with two different accounts with the same name should be
> >> obvious.
> > 
> > It is not obvious to me. What's the problem? Some times I have accounts 
> > with the same name under different parent accounts.
> > 
> > 
> >> Splits are simply the aggregation of multiple, individual transactions,
> >> to produce a single credit or debit amount that matches some statement,
> >> or invoice record.
> > 
> > No they are not. For example, consider the following split:
> > 
> > Assets:Banks      -> - $300
> > Expenses:Interest -> + $130
> > Liabilities:Loan  -> - $170
> 
> I'm sorry, I cannot resist challenging this one item. It is so much
> two separate transactions aggregated into one line that the two
> transactions are attributable to entirely different tax schedules
> (at least if we are talking about a home loan in the US). One
> transaction is the bank charging you for $130 which you agreed to pay
> them for the use of their money. The second is an amount of
> $170 to pay off a portion of the outstanding principle which you agreed
> to in order to maintain their trust in you. The bank was just nice
> enough to let you write a single check to cover both charges. Two
> different chunks of value moved between different account pairs.
> 
> I'm ok if you want to consider it a single "transaction". It is
> in a sense a thing that only requires you go through the motions of
> a single gnucash transaction entry. Kind of a Poh-tato vs Pah-tata
> argument I could admit. But it still doesn't solve any project cost
> accounting needs.
> 
> > 
> > This is a single transaction that affects three accounts, not two 
> > transactions. I did not make two loan payments, I made one. Part of it 
> > went toward the principal and part was interest. You _could_ whack it 
> > into two transactions, but that would be _wrong_ not just because it 
> > doesn't match the bank statement but simply because that is not what 
> > really happened. I did not make two payments, I made one payment that 
> > had an expense component and a liability component.
> > 
> > 
> >> For instance if I deposit three checks drawn from
> >> three accounts as debit into a savings account then really three
> >> transactions took place. But the bank statement for the savings
> >> account shows a single credit.
> > 
> > In this case I would make three transactions in GnuCash. What you 
> > described is not what split transactions are for. They are not for 
> > matching bank statements. They are for matching single transactions that 
> > touch 3 or more accounts.
> > 
> >> Anyways, in doing it as project accounts with vendor subaccounts
> >> (with or without splits) you can never track back who you paid an
> >> amount to. All you can see is that in the bank account there are 
> >> transactions, paid to "doomsday" or to "gardening".
> > 
> > No, you would see a transaction that says "Doomsday:McMaster".
> > 
> >> But if you wanted to purchase the same component again who would
> >> you buy it from?  If you had a problem with the charge, like say
> >> it was discovered to be the incorrect amount, who would you call?
> > 
> > If the transaction says "Expenses:Doomsday:McMaster" I suggest you talk 
> > to McMaster.
> > 
> > 
> >> Oh... visually and manually cross-reference the bank statement you
> >> say? Forget that.
> > 
> > What the heck are you talking about? Who in the world suggested that you 
> > check statements manually? We are showing you how to use GnuCash and 
> > answering your questions in our spare time. Show some appreciation.
> > 
> >> You also can't make intelligent use of your data because you have
> >> lost all vendor information.
> > 
> > Are you sure you understand the concept of sub-accounts?
> > 
> > Expenses:Doomsday:McMaster
> > 
> > How exactly did you lose all the vendor information?
> > 
> >> You can say "How much did I spend on the
> >> doomsday product" but you can't determine "How much did dealing with
> >> McMaster-Carr cost me last year?" which can be equally important
> >> to a business as there are other suppliers.
> > 
> > You'd have to add up the totals for each McMaster sub-account. Mildly 
> > annoying, but perfectly doable. Or you could make an income-expense 
> > report and under 'Options' select only the McMaster sub-accounts.
> > 
> >>>> So it doesn't fit the food model. (Even the Food model
> >>>> doesn't work because I might want to account for food I
> >>>> bought for myself versus food I bought for guests as gifts
> >>>> under projects and such. I.E. not everything I buy at
> >>>> Ralph's is consumed ultimately paid for by me but rather my
> >>>> roommate.)
> >>> This is again done with a split.
> >>
> >> No, it isn't. IANACPABMFI (I am not a CPA but my father is) I have
> >> discussed this at length with him and this is not done with splits
> >> or subaccounts.
> > 
> > Expenses:Doomsday:Gifts
> > 
> > Who says you have to put everything that is edible in the Food account? 
> > I have an account for groceries and another for leisure which includes 
> > restaurants.
> > 
> > Much of the rest of your email was bordering on insult and I'd rather 
> > not reply to it.
> > 
> > Best,
> > Daniel.
> 
> -- 
> Jeff Wiegley, PhD
> Cyte.Com, LLC
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.

-- 
Beth Leonard
http://www.LeonardFamilyVideos.com