Accounting...
-
Ok, so in my 25+ years of programming i've never really had to do any real accounting. I managed to avoid Accounting classes in school, and I've always used Quickbooks or Quicken to balance my checkbooks ;) Now, i've been tasked with creating a relatively simple web-based double-entry accounting system for a client. I initially though "no problem, I should be able to figure this out", but after beating my head against a wall for weeks trying to get a grasp of what should be simple concepts... i'm ready to admit defeat. Would anyone care to try and beat some basic concepts into my thick skull? I'm not stupid. I undestand that D-E accounting means you must perform the opposite action on one side as what you did to the other, but some of it just doesn't make sense. For instance, when money is "deposited", it's actually subtracted from the Cash account? WHY? The task I have is to create a system similar to a bank. This isn't a corporate accounting system. There's no issues with inventory, accounts payable, payroll, etc... it's just moving figures back and forth from accounts and reporting on the transactions and balances. It should be easy, right? I hate accounting. Lol. Every book i've picked up on the subject goes off into great detail about taxes, and payroll, and accounts payable, and a hundred other topics that arent' really important to what I need, but gloss over the basics. As a side note, and this is straying far too close to asking a programming question, I'm also beating my head against the wall regarding the best way to design the database for this as well. It has to handle things like transactions that haven't "cleared" yet (pending transactions), but still must be represented in the transaction history. bah.. ideally i'd like to find something online that describes banking designs, but i've not found anything yet. Thanks.
-- Where are we going? And why am I in this handbasket?
Watch Office Space. It'll give you some ideas on accounting.:laugh:
"Neque porro quisquam est qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit..." "There is no one who loves pain itself, who seeks after it and wants to have it, simply because it is pain..."
-
Watch Office Space. It'll give you some ideas on accounting.:laugh:
"Neque porro quisquam est qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit..." "There is no one who loves pain itself, who seeks after it and wants to have it, simply because it is pain..."
-
Ok, so in my 25+ years of programming i've never really had to do any real accounting. I managed to avoid Accounting classes in school, and I've always used Quickbooks or Quicken to balance my checkbooks ;) Now, i've been tasked with creating a relatively simple web-based double-entry accounting system for a client. I initially though "no problem, I should be able to figure this out", but after beating my head against a wall for weeks trying to get a grasp of what should be simple concepts... i'm ready to admit defeat. Would anyone care to try and beat some basic concepts into my thick skull? I'm not stupid. I undestand that D-E accounting means you must perform the opposite action on one side as what you did to the other, but some of it just doesn't make sense. For instance, when money is "deposited", it's actually subtracted from the Cash account? WHY? The task I have is to create a system similar to a bank. This isn't a corporate accounting system. There's no issues with inventory, accounts payable, payroll, etc... it's just moving figures back and forth from accounts and reporting on the transactions and balances. It should be easy, right? I hate accounting. Lol. Every book i've picked up on the subject goes off into great detail about taxes, and payroll, and accounts payable, and a hundred other topics that arent' really important to what I need, but gloss over the basics. As a side note, and this is straying far too close to asking a programming question, I'm also beating my head against the wall regarding the best way to design the database for this as well. It has to handle things like transactions that haven't "cleared" yet (pending transactions), but still must be represented in the transaction history. bah.. ideally i'd like to find something online that describes banking designs, but i've not found anything yet. Thanks.
-- Where are we going? And why am I in this handbasket?
I have a meeting in 5 minutes, but I spent 6 years doing accounting programming, ledgers, payrolls, everything. If no one answers your questions, drop me a note as a reminder and I will walk you through it. It is simple, once you grasp the concept, and the concept seems to be at issue here. Into the valley of shadow I go.... :doh: If I don't answer replies... the meeting got to me... and I didn't survive.... ;)
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Ok, so in my 25+ years of programming i've never really had to do any real accounting. I managed to avoid Accounting classes in school, and I've always used Quickbooks or Quicken to balance my checkbooks ;) Now, i've been tasked with creating a relatively simple web-based double-entry accounting system for a client. I initially though "no problem, I should be able to figure this out", but after beating my head against a wall for weeks trying to get a grasp of what should be simple concepts... i'm ready to admit defeat. Would anyone care to try and beat some basic concepts into my thick skull? I'm not stupid. I undestand that D-E accounting means you must perform the opposite action on one side as what you did to the other, but some of it just doesn't make sense. For instance, when money is "deposited", it's actually subtracted from the Cash account? WHY? The task I have is to create a system similar to a bank. This isn't a corporate accounting system. There's no issues with inventory, accounts payable, payroll, etc... it's just moving figures back and forth from accounts and reporting on the transactions and balances. It should be easy, right? I hate accounting. Lol. Every book i've picked up on the subject goes off into great detail about taxes, and payroll, and accounts payable, and a hundred other topics that arent' really important to what I need, but gloss over the basics. As a side note, and this is straying far too close to asking a programming question, I'm also beating my head against the wall regarding the best way to design the database for this as well. It has to handle things like transactions that haven't "cleared" yet (pending transactions), but still must be represented in the transaction history. bah.. ideally i'd like to find something online that describes banking designs, but i've not found anything yet. Thanks.
-- Where are we going? And why am I in this handbasket?
Erik Funkenbusch wrote:
For instance, when money is "deposited", it's actually subtracted from the Cash account? WHY?
My meeting is delayed a few minutes.... first off remember you have different sets of accounts, and ironically the balance each other. Take a look here: http://www.gnucash.org/docs/v1.8/C/gnucash-guide/basics_accounting1.html[^] the goal of double entry accounting is to create a trail, a history of account changes. Okay, you want to deposit some cash, so it must go in a bank account, but it comes from your cash in your pocket. But it didn't start there. How did the cash get in your pocket? If you received a gift, you add to your cash, and balance with a gift account. Did it come from income? you got paid for work? then you balance the cash account change with an income entry. Your cash and your bank are both asset accounts, so they are on the same "side" of the accounting equation. http://www.rtoonline.com/Content/Contributor/John_Day/DoubleEntryAccounting.asp[^] everything must balance. http://www.gnucash.org/docs/v1.6/C/x2527.html[^] and here is a longer explanation: http://en.wikipedia.org/wiki/Double-entry_bookkeeping_system[^] But all in all, the goal is to give you a paper trail of all entries. Your cash you deposit "came" from somewhere, then it was deposited in the bank. Those are two separate transactions unless a check is deposited directly to a bank, but was that accounts receivable (something someone owes you), a gift, or income? the double entry tells the accountant where the money originated, whether it was taxable, etc.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the
-
Ok, so in my 25+ years of programming i've never really had to do any real accounting. I managed to avoid Accounting classes in school, and I've always used Quickbooks or Quicken to balance my checkbooks ;) Now, i've been tasked with creating a relatively simple web-based double-entry accounting system for a client. I initially though "no problem, I should be able to figure this out", but after beating my head against a wall for weeks trying to get a grasp of what should be simple concepts... i'm ready to admit defeat. Would anyone care to try and beat some basic concepts into my thick skull? I'm not stupid. I undestand that D-E accounting means you must perform the opposite action on one side as what you did to the other, but some of it just doesn't make sense. For instance, when money is "deposited", it's actually subtracted from the Cash account? WHY? The task I have is to create a system similar to a bank. This isn't a corporate accounting system. There's no issues with inventory, accounts payable, payroll, etc... it's just moving figures back and forth from accounts and reporting on the transactions and balances. It should be easy, right? I hate accounting. Lol. Every book i've picked up on the subject goes off into great detail about taxes, and payroll, and accounts payable, and a hundred other topics that arent' really important to what I need, but gloss over the basics. As a side note, and this is straying far too close to asking a programming question, I'm also beating my head against the wall regarding the best way to design the database for this as well. It has to handle things like transactions that haven't "cleared" yet (pending transactions), but still must be represented in the transaction history. bah.. ideally i'd like to find something online that describes banking designs, but i've not found anything yet. Thanks.
-- Where are we going? And why am I in this handbasket?
Erik Funkenbusch wrote:
ideally i'd like to find something online that describes banking designs, but i've not found anything yet.
http://www.bookkeeping-course.com/[^] maybe this will help? I just found it through wiki links. well, I am off to my meeting. late, but because my boss wants to attend.... oh joy.... I think I prefer accounting! Good luck! hope all that helps. If it is confusing, let me know and I will walk through it in more detail. I will be writing my own accounting system for doing business at home. probably a modification of an existing one, or linking to with plugins, etc. but I have to extend because of differences in special actions with the type of work I do, plus I have to throw away the default accounts and put in exactly the account names required for this type of accounting. All stuff I can do pretty easily. It'll be wierd paying myself payroll... strange....
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
If you are a proper programmer then you will never understand accounting. (Do you expect accountants to understand how to program?) I think your only reasonable course if you want to retain your sanity is to go back to your client and say, "Sorry, but you will have to find someone else." If anyone says, "It's easy, I don't see your problem" then they are infected - stay away from them!
Phil
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
Lol. Well, i'm stuck with the job. So if I can't figure it out, i have to outsource the accounting parts to someone that does.
-- Where are we going? And why am I in this handbasket?
-
Erik Funkenbusch wrote:
ideally i'd like to find something online that describes banking designs, but i've not found anything yet.
http://www.bookkeeping-course.com/[^] maybe this will help? I just found it through wiki links. well, I am off to my meeting. late, but because my boss wants to attend.... oh joy.... I think I prefer accounting! Good luck! hope all that helps. If it is confusing, let me know and I will walk through it in more detail. I will be writing my own accounting system for doing business at home. probably a modification of an existing one, or linking to with plugins, etc. but I have to extend because of differences in special actions with the type of work I do, plus I have to throw away the default accounts and put in exactly the account names required for this type of accounting. All stuff I can do pretty easily. It'll be wierd paying myself payroll... strange....
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
Hey, thanks. Lots of good stuff there. Maybe i'm wrong here, but I would think that there has to be some kind of standard design for accounting software. A sort of "best practices" or "Patterns" for it. I found that Martin Fowler created some double-entry patterns[^], and I like them. However, I'm thinking more about how the data model is structured. I know that varies depending on requirements, but there has to be some kind of basic structure that's common to most kinds of systems.
-- Where are we going? And why am I in this handbasket?
-
Hey, thanks. Lots of good stuff there. Maybe i'm wrong here, but I would think that there has to be some kind of standard design for accounting software. A sort of "best practices" or "Patterns" for it. I found that Martin Fowler created some double-entry patterns[^], and I like them. However, I'm thinking more about how the data model is structured. I know that varies depending on requirements, but there has to be some kind of basic structure that's common to most kinds of systems.
-- Where are we going? And why am I in this handbasket?
Erik Funkenbusch wrote:
Maybe i'm wrong here, but I would think that there has to be some kind of standard design for accounting software. A sort of "best practices" or "Patterns" for it. I found that Martin Fowler created some double-entry patterns[^], and I like them. However, I'm thinking more about how the data model is structured. I know that varies depending on requirements, but there has to be some kind of basic structure that's common to most kinds of systems.
well, to be honest the pattern is really just as defined there. The actual usage comes into the accounts themselves. What accounts balance the other. This is where you get in the 3,5,7 or other account models. As you saw in the wikipedia reference there are multiple accounting models. These are the same double entry design, it is just defined what accounts are debit accounts and what are credit accounts. That is where the nitty gritty is. there is the traditional, extended traditional, modern, and US government model, and a few others. After you define the major categories, all other accounts are sub-accounts under them, and then sub accounts under them. So you have income->work&overtime&moonlighting&etc as sub accounts. The actual accounts and subaccounts defines the resulting accounting model, but it is still just a double entry system it doesn't matter what you actually call it except to the accountant. In this aspect it is very much like programming, the name of the variable matters, but ultimately to the compiled system the computer doesn't care what you call the variable, it matters only to the programmer. So too with accounting, the methodology is all the same, but the naming convention defines the structure of the process from there. If you are doing government accounting the names are one way, modern another, and the traditionals another. It depends on how generic you want to make this system, you might want to have each of those accounting system default account models available. They simply define which account is on which side of the equals sign. After that everything is debit this, credit something else, until you fall asleep. Accounting is pretty boring, per se. It can get complex when you get into methods to display and reports, but that is just shaping the existing accounts into an output form and then their sub accounts (maybe, depending on the report). You can get fancy, as I have, and do predictions on what directions accounts are going, are you earning more than las
-
Erik Funkenbusch wrote:
Maybe i'm wrong here, but I would think that there has to be some kind of standard design for accounting software. A sort of "best practices" or "Patterns" for it. I found that Martin Fowler created some double-entry patterns[^], and I like them. However, I'm thinking more about how the data model is structured. I know that varies depending on requirements, but there has to be some kind of basic structure that's common to most kinds of systems.
well, to be honest the pattern is really just as defined there. The actual usage comes into the accounts themselves. What accounts balance the other. This is where you get in the 3,5,7 or other account models. As you saw in the wikipedia reference there are multiple accounting models. These are the same double entry design, it is just defined what accounts are debit accounts and what are credit accounts. That is where the nitty gritty is. there is the traditional, extended traditional, modern, and US government model, and a few others. After you define the major categories, all other accounts are sub-accounts under them, and then sub accounts under them. So you have income->work&overtime&moonlighting&etc as sub accounts. The actual accounts and subaccounts defines the resulting accounting model, but it is still just a double entry system it doesn't matter what you actually call it except to the accountant. In this aspect it is very much like programming, the name of the variable matters, but ultimately to the compiled system the computer doesn't care what you call the variable, it matters only to the programmer. So too with accounting, the methodology is all the same, but the naming convention defines the structure of the process from there. If you are doing government accounting the names are one way, modern another, and the traditionals another. It depends on how generic you want to make this system, you might want to have each of those accounting system default account models available. They simply define which account is on which side of the equals sign. After that everything is debit this, credit something else, until you fall asleep. Accounting is pretty boring, per se. It can get complex when you get into methods to display and reports, but that is just shaping the existing accounts into an output form and then their sub accounts (maybe, depending on the report). You can get fancy, as I have, and do predictions on what directions accounts are going, are you earning more than las
Thanks. Yes, I see what you mean. As far as the accounts go. In my opinion, I really don't care what the accounts are called, or what they're for. I just move money between them. The only thing I have to know is whether it's a Assett or Liability account, correct? The logic of the rest is all up to the reporting engine, not the account engine. Some questions I have are regarding the data model. For instance, in a transaction table, should you have two columns, one for debits, one for credits. Or should you have a single "amount" column, and have debits be negative and credits positive? Or should you not have signed numbers, and just use a type field to indicate whether it's a debit or credit? I think you see where I'm going here. Furthermore, should you have two physical transaction records for each logical one (ie, subtract $100 from account A, and a second as the Add to Acct B)? Or should each record be a complete transaction (ie. $100 was subtracted from Acct A and added to Acct B)? Did I mention I hate Accounting? Lol.
-- Where are we going? And why am I in this handbasket?
-
Thanks. Yes, I see what you mean. As far as the accounts go. In my opinion, I really don't care what the accounts are called, or what they're for. I just move money between them. The only thing I have to know is whether it's a Assett or Liability account, correct? The logic of the rest is all up to the reporting engine, not the account engine. Some questions I have are regarding the data model. For instance, in a transaction table, should you have two columns, one for debits, one for credits. Or should you have a single "amount" column, and have debits be negative and credits positive? Or should you not have signed numbers, and just use a type field to indicate whether it's a debit or credit? I think you see where I'm going here. Furthermore, should you have two physical transaction records for each logical one (ie, subtract $100 from account A, and a second as the Add to Acct B)? Or should each record be a complete transaction (ie. $100 was subtracted from Acct A and added to Acct B)? Did I mention I hate Accounting? Lol.
-- Where are we going? And why am I in this handbasket?
Erik Funkenbusch wrote:
Furthermore, should you have two physical transaction records for each logical one (ie, subtract $100 from account A, and a second as the Add to Acct B)? Or should each record be a complete transaction (ie. $100 was subtracted from Acct A and added to Acct B)?
You've just touched on the reference in wiki to "multiple entry accounting", but double is the general term. So lets assume you have a sale, a very common transaction. The sale was for $110.00, $10 being taxes, $60 inventory, and $40 gross profit from sales so the register entry looks something like this:
Account credit debit
Cash 110.00
Tax 10.00
Inventory 60.00
Gross Profit 40.00_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)