What I don't understand is the journal table. It looks like a simple lookup table. Why is so much ephasis placed on it in the article you reference (first one.) It says:
I.e. all POSTING entries associated with the JOURNAL entry must be successfully completed or none must be completed. The numerical sum of all POSTING entries associated with a JOURNAL entry must also equal zero
What's that mean? If you look at the example table entries is just has a, b, c, d for the type.
Thanks for the article.
James Urquhart
· 1 year ago
John,
A Journal binds together several Posting's. Typically you'd have one per full account transaction - e.g. DEBIT Bank 100, CREDIT Revenue 100 could be linked to a single journal of the type "Deposit". In theory it makes it easy to track complex transactions which consist of transfers to/from multiple accounts.
The linked article does indeed make Journals a bit confusing by referring to them by letters (a,b,c,d). Instead you should just refer to them by key number (1,2,3,4) and the whole thing becomes much more clearer.
My above example could be recorded in the POSTINGS table as follows (assuming Bank == 100 and Revenue == 50):
When i writ that code, i hadn't quite figured out the difference between new and create. safe to say, now i know. :)
steveluscher
· 1 year ago
I'm rather looking forward to the post "Double Entry Accounting with Invoicing in Rails."
James Urquhart
· 1 year ago
Haha
Actually, that wouldn't be such a bad idea... :)
Artificial
· 1 year ago
the approach i liked the best was the one mentioned in the article. It made the most sense, and wasn’t needlessly complicated. So i decided to implement it
All Comments
I.e. all POSTING entries associated with the JOURNAL entry must be successfully completed or none must be completed. The numerical sum of all POSTING entries associated with a JOURNAL entry must also equal zero
What's that mean? If you look at the example table entries is just has a, b, c, d for the type.
Thanks for the article.
A Journal binds together several Posting's. Typically you'd have one per full account transaction - e.g. DEBIT Bank 100, CREDIT Revenue 100 could be linked to a single journal of the type "Deposit". In theory it makes it easy to track complex transactions which consist of transfers to/from multiple accounts.
The linked article does indeed make Journals a bit confusing by referring to them by letters (a,b,c,d). Instead you should just refer to them by key number (1,2,3,4) and the whole thing becomes much more clearer.
My above example could be recorded in the POSTINGS table as follows (assuming Bank == 100 and Revenue == 50):
Id,Account Id,Journal Id,Asset Type,Amount
1,100,1,£,100
2,50,1,£,-100
100 + -100 == 0, thus satisfying the requirements in the article.
Hope that helps. :)
type less. :)
#third_transaction = Journal.new(:transaction_type => :transfer, :start_date => Time.now)
#third_transaction.save!
third_transaction.create(:transaction_type => :transfer, :start_date => Time.now)
Kronidas
Hello,
type less. :)
#third_transaction = Journal.new(:transaction_type => :transfer, :start_date => Time.now)
#third_transaction.save!
third_transaction = third_transaction.create(:transaction_type => :transfer, :start_date => Time.now)
Kronidas
When i writ that code, i hadn't quite figured out the difference between new and create. safe to say, now i know. :)
Actually, that wouldn't be such a bad idea... :)