This module has issues installing and uninstalling.

  • Installing: 32 character limit violated
  • Uninstalling: Error message

    Error: Class 'panels_display' not found in include() (line 59 of .../bookkeeping/page_manager/bookkeeping_export.page).

    The website encountered an unexpected error. Please try again later.

IMO, it also has fundamental conceptual flaws concerning accounts and transactions. There is a need for such a module. If you want to address these issues, I might be able to help and you can PM me.

Comments

geru created an issue. See original summary.

andrewbelcher’s picture

andrewbelcher commented
Title: Errors and fundamentals » Missing dependency on panels

I think the problem there is a missing dependency on panels.

What are the 'fundamental conceptual flaws' you mention? I have a number of clients using this to track millions of pounds a year with no problems. It is very geared towards programmatic usage, so has very little UI and also probably currently requires a developer to configure it to interact with other systems, but to me that's more features that could improve it for site builders rather than fundamental flaws.

geru’s picture

geru commented

This module defines a Transaction Entity and this is fundamental and good.

However, the concept of an Account is also fundamental and this module pushes that into a Taxonomy.

andrewbelcher’s picture

andrewbelcher commented

Why is taxonomy not suitable for accounts? They are fieldable so we can add our additional information to them, but come with the large benefit of supporting hierarchy out of the box. Taxonomy is about categorisation, which is exactly what accounts are for.

geru’s picture

geru commented

Your point is a good one, and I'm not saying you can't do it with taxonomy. Clearly you can, just as you could have the transactions be content types.

However, you did take the time and energy to make a transaction entity recognizing that it was not appropriate use of content type. A package like Quickbooks stores a dozen or so fields with their account information and if you take their word for it that this is useful information, then you might do the same eventually. Then, all that field information will get dragged around or made available in all the rest of your taxonomies.

Some of that information concerns itself with the fundamental type information of account, some with balances, some with categorization of different special accounts, some with tax, but at a minimum, a balance and the account type seem like a reasonable information to keep around with accounts. For these reasons, I believe the account is best maintained as an entity.

I'm looking at the Ledger module and liking the ledger_account entity. Also, the Party module looks quite useful relative to the who aspect of many transactions.

andrewbelcher’s picture

andrewbelcher commented

As fields exist on the bundle, they only exist on terms in the account vocabulary, so you can add any fields you want without affecting other taxonomy terms in any way.

In D8, they would definitely be their own (config) entity type, but in d7 I think using taxonomy makes sense.

Transactions (and entries) are their own type because they are wildly different from nodes (no title, body etc).