Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.I had a chance to install and look at the codes of ledger yesterday. After checking the module, I acknowledged that I did not understand what this module does :(
This module is a bookkeeping module to store personal accounting or transaction. I thought that this module create an account for each user.
At the other hand, What I need is:
1- I must be able to enter transaction for both users and non users,
2- Users must be able to transfer money from one to another.
3- Users must be able to see the transactions that are recorded.
I think, drupal based accounting software must store: Who entered the transaction, money is given to which user.
To do this job, there is mutual credit module. Unfortunately, it is too complicated and give lots of errors. There is balance tracker module. But it is very simple, not entity based and drupal 7 version is just dev.
I would like to request two more fields in account entry table; Payee, Paid By, Status, Statement. With these fields; I can filter a view to show the account entries that belong to a user. Additionally, users can see who added this debit or credit. Moreover, I can make an account entry as void or cancelled. With statement I can keep the account statement info (given not given) Finally, there wont be any need for another module to transact money between users (like mutual credit did.)
By the way; Since this is a bookkeeping module, There might be a category field field to enter account entry category. To do this; you may use taxonomy together with http://drupal.org/project/hierarchical_select module. One may enter The category fields to view records by category.
All in all, Making account entry entity fieldable with a user interface (You made it fieldable but no UI) one can add necessary fields to the accounts in the future. But I guess these 5 fields must be added in core schema.
I do not know how to patch but, If you accept, I can add these fields (except taxnomoy) and send you the ledger_account_entry module :)
Comments
Comment #0.0
zulfierken commentedupdate
Comment #0.1
zulfierken commentedlast update
Comment #1
zulfierken commentedOption 2 to create user accounts.
After checking all codes, I figured out that you use account entry functions only in ledger_transaction. I think it is possible to create submodules for additional account entries.
I mean;
1- Each account entry submodule will declare an account entry type.
2- Transaction module will ask user to add what type of account entry
3- There will be an account entry type filter in transaction views.
4- Each submodule will write their own views to show transactions and account entries to the end users.
In my case;
1- I can create a fork of your ledger_account_entry module and name it as ledger_user_account_entry.
2- Add the fields that I want to this submodule.
3- Create views to show account entries to the users (payroll, cash account, liabilities etc,.
4- Hack your ledger_transaction module line 116 to delete from ledger_user_account_entry if transaction us user account entry (I can add a field to the transaction to do this)
5- Create a new ledger_user_transaction_ui module to create forms that I need.
6- Define my own views to get transaction details.
This might give more flexibility to the end users to use ledger to store transactions per user.
Comment #2
m.stentaThanks for the feature request and suggestions. This is something I have been thinking about already: enabling multi-user support. What you are requesting specifically (allowing users to transfer funds to/from other users), however, may be outside the scope of this module, or at least outside the scope of the core entities (Account, Transaction, and Account Entry).
This module is meant to be a double-entry bookkeeping system used for keeping track of one's own income and expenditures (as well as assets, liabilities, and equity). An "Account Entry" is meant to simply be an increase or decrease to a given account. The Transaction entity, on the other hand, is meant to "collect" 2 or more account entries, to represent value being taken from one account and added to another account (all within the same user's accounts, not between two different users). That's what is meant by "double-entry bookkeeping" (see this wiki article for more info: http://en.wikipedia.org/wiki/Double-entry_bookkeeping_system). So for example, if I gave you $20 in cash for a pretzel, I would add two account entries to MY accounts: 1) decrease my "Cash" account by $20, and 2) increase my "Pretzel Expenses" account by $20. It doesn't keep track of YOUR end of the deal at all, though.
Currently, the Ledger module really only supports accounts for one user, but I do plan to add support for multiple users within the same site. There wasn't a feature request for that already, so I made one: #1511430: Access control and account ownership per user
Allowing users to transfer funds between one another is an interesting idea, though, and I think it would be a great feature to have. Perhaps we could achieve it with another module, that extends Ledger's basic functionality to allow transactions between users (which would involve at least 4 account entries - 2 for each user). I'll have to give this some more thought. Let's focus discussion in this ticket on that idea.
I'm changing the name of this issue to better reflect its purpose. And since this isn't a bug report, I'm changing the priority to "normal".
Comment #3
zulfierken commentedThanks for detailed reply. Transaction between user is also double entry. Transaction will just transfer the amount from one user's account to another user.
Example: User 10 transfer 50 dollars from his cash (or income or whatever) account to user 15 (librarians) collected fee account (or cash or income or whatever)
As a result 2 account entry done at the same time one labeled as user 10 and another labeled as user librarian.
With using multi users (user id in account entry) this can be done without any change in core modules. Of course each transaction form must be written as submodule, and an API to validate and submit transactions would be great :)
Comment #4
m.stentaYour description makes sense, but that's not really how double-entry bookkeeping works. The two entries are always between two of your own accounts.
Think about it this way (using Quickbooks as an example): if you and I both use Quickbooks to manage our books, Quickbooks does not maintain any kind of connection between our two instances of Quickbooks. We each have our own computers, with our own copy of Quickbooks, each set up with a list of accounts. When we enter transactions, we're just entering information about the transaction from our point of view, but there is no real link between the two (the two QB instances don't talk to each other or exchange information) - it's just conceptual.
So let's use the example you gave, in which I want to transfer $50 to you to pay a fee. And just to make it more specific, let's say I'm giving it to you by writing a check from my checking account.
In my books, I would "credit" (decrease) my "Checking Account" $50, and "debit" (increase) my "Expenses: Fees" account by the same amount, to indicate that I "transferred" $50 from my checking account to my fees account (which means I paid you, from my point of view). I could call that fees account something more specific, like "Expenses: Fees: zulfierken" if I wanted to, but it would still mean the same thing, and it would still be an account owned by me, because it's used to represent and keep track of how much money I have paid in fees over time.
Then, in YOUR books, you would also add entries to two of your accounts, but they would be different because it means something different from your point of view. You would "credit" (increase) your "Income: Fees" account, and also "credit" (increase) your "Assets: Checking Account" (when you deposit the check in your checking account). This allows you to track how much you've earned in fees, and at the same time also keep track of how much you have in the bank.
All that being said, it certainly would be possible to do it the way you suggest: where you actually just have the transactions going from one person's account to another person's account. That may work for your purposes, but it is not the "right" way to do it, and would therefore cause some issues down the line if you wanted to use any of Ledger's reporting or graphing features (which are coming soon). Those features will be working on the traditional double-entry bookkeeping assumptions. It also may end up being harder to implement, in the long run, precisely for the reasons you described earlier (the changes that would need to be made to the current data structures).
So I think the right way to represent a transaction between two people would be to create some new kind of relationship (maybe another entity type) called "User Transfer" or something like that. This relationship would simply link two "Transaction" entities (one in your accounts and one in mine). The Transactions would each have (at least) two Account Entries, so a total of (at least) 4 Account Entries would be created in the process.
I hope I'm explaining this in a way that makes sense. I want to be clear about the purpose of this module. It's important to understand that it does not have the same purpose as the Mutual Credit module, which seems to specifically focus on transferring money between two users. Ledger is all about keeping track of *your own* money.
But I think there is potential that both worlds can be combined. I think Ledger can provide the basis with it's traditional double-entry bookkeeping, and another module can be plugged in that extends it to make it easier to represent transfers between different users. This would be the ideal approach, I think.
Comment #5
m.stentaClosing this issue for now... I don't think it's something that we'll provide in the core Ledger modules. But it might be a good contrib module.
Comment #5.0
m.stentaAnother thing