-
Notifications
You must be signed in to change notification settings - Fork 308
Conversation
be20530
to
e9f4881
Compare
My thinking here is that we should approach this by building out a mini-application with a chart of accounts and a general ledger, where admins can filter, sort, search, browse, and CRUD accounts and ledger entries, and then once we have the tables and UI in place, start porting existing processes and data over to the ledger in follow-on PRs. |
Over on #3786 I want to make a dashboard.css that uses the same but separate SCSS wiring.
02c4ec0
to
45499f0
Compare
We actually shouldn't need to manually add accounts that often, mostly when we set up a new bank account or payments vendor. I don't believe we'll ever want to delete an account that has any transactions on it (a question for Peter). |
Alright, so let's get some accounts persisting, and then turn to transactions ... |
52920d0
to
15cb917
Compare
That looks like rocket science from finance world to me. Is it possible to call it somehow differently for people who is not an expert in accounting? I have a natural interest in this stuff, so tried to watch a few videos on khan academy, but I expect that majority of users are not that involved to learn what this How about?
And hey! It looks like we will be able to do this - https://sfconservancy.org/npoacct/ |
I think we should use standard accounting terminology, because eventually the goal is to have accountants on our Team, helping us manage our company. The point here is to build a system that accountants will be comfortable with. I'm meeting with an accountant next week to make sure we're achieving that. |
The next step on this PR is to implement the general ledger. I believe the accounts schema/API will need to change to support what we want for the ledger. One of the things we want is auditability. We want to be able to know who changed accounts when. |
We also need to keep track of the balance for each account. I'm thinking about implementing this using our |
Oooooooo ... multicurrency? I'm looking at http://www.ledger-cli.org/3.0/doc/ledger3.html#Keeping-a-Journal. |
"Commodities" are pretty low down in Ledger's design: http://www.ledger-cli.org/3.0/doc/ledger3.html#Internal-Design. |
I think currency/commodity attaches to an account, so for a Coinbase payout we'd have 50 against a Gratipay account denominated in USD, and 0.1 against Gratipay's Coinbase account, which would be denominated in BTC. |
"Journal entries made into the general ledger [...]" not less confusing. |
What's our accounting period? The week? |
That would seem the most natural fit given our history. |
Let's say it's the week. |
I like the typography on the ledger detail in the book used in https://www.youtube.com/watch?v=D96wao4iZn8: |
Alright, so let's show a ledger summary at:
And a ledger account detail at:
|
Let's not worry about a Trial Balance for this PR. |
Let's move the account creation/modification to the general ledger summary. For ~users and Teams, account creation and modification happens in the course of ~user registration and Team application. Do ~users and Teams subledgers make sense, though? |
What are the GL control accounts that we would have? I suppose we'd have a "~user balances" and "Team balances." |
The typical examples of subledgers are AR and AP, where the accounts in the former are customers, and the latter, vendors. |
How do income and expense factor in? Seems like that gets us into Gratipay's operational accounting. Braintree, etc.'s fees are expenses to Gratipay. We pass them through as fees to our ~users, which is income for us. |
|
|
What are our source documents? |
I think "source document" in our case is blurred because we're so automated. The database record is the source document, or the source document is notional. E.g., we're going to generate a receipt from the database record, not the other way around. |
Maybe we rename |
From the goofy one: |
Maybe we rename |
It would be a win and perhaps a more achievable one on this PR if we simply start with a general ledger that covers our top-level escrow accounts, without necessarily having the drill-down yet. |
But first I want to redo the |
We're not worrying about subledgers yet.
fe1935c
to
544429d
Compare
Alright, it is seeming foolish to me to reimplement an entire accounting system inside of Gratipay. Per the above comments #3786 (comment) and #3786 (comment), I'm now thinking about how the work on this PR relates to setting up accrual accounting for Gratipay as a whole. It seems that we want to use a proper accounting package (Xero!) for Gratipay-as-a-whole. In which case, gratipay.com effectively becomes a subledger for our escrow liability. |
I'm looking back over http://www.tdi.texas.gov/title/documents/BASICS.pdf ... |
Alright, thanks to @kaguillera we are off and running with gratipay/inside.gratipay.com#308. There's some great work on this PR towards a literate, integrated API. Perhaps one day we can scavenge it for parts. :-) |
Redo of #3653.
Questions for Peter: