Suggestion required for Accounting Software core infrastructure VS2010 C# MySql
-
Dear All, I am on the beginning stage on C# development. Currently I am developing an Voucher based Accounting Software with following: 1- Visual Studio 2010 2- Programming Language: C# 3- Database: MySql 5 At present, Database structure is as follows: 1.accAccounts (For holding information about Chart of Accounts like Account Code, Name, Subsidiary or Detail, Opening Balance etc) 2.vMaster (For Vouhcer Master information, Like Voucher Number, Date, Voucher Type (i.e Payment/Receipt/Journal), Payee Name, Remarks, Debit Account, Credit Account, Amount) 3. vDetails (For Voucher Detail information, used for further allocation of Expenses/Assets uses AccCode, Debit Amount, Credit Amount) 4. TranPost (All transactions from vMaster and vDetails will be posted in this table) The General idea is this: User create new Voucher, enter transactions for Payment/receipt/journal etc. Then save the voucher. After approval of supervisor, Voucher will post and all transactions were copied to TransPost, once posted vMaster and vDetails were restricted to further editing. Ofcourse when data is available in TransPost table, generation of Trial Balance, Balance Sheet & Income Statement will be based upon it. Now my Question is: Is this the correct approach for development of Accounting Software? I am mainly concern about Year end closing process. Should I use same vMaster/vDetails/TransPost tables for every Accounting period or should I create new tables for each period? Assuming 50-80k transactions per year. What is the recommended way? For accMaster I think it should be the global table for All accounting periods, if yes, then it needs also in Master/Detail structure for holding different Opening balances for each year. As mentioned, I am a beginner and what I've learned so far is by 'learn-by-doing' approach and guidance of all experience programmers in the forums like this. So I am in need of guidance again. Looking forward for suggestions from all Masters specially those who are in development of Accounting Softwares. Thanks in advance Ahmed
-
Dear All, I am on the beginning stage on C# development. Currently I am developing an Voucher based Accounting Software with following: 1- Visual Studio 2010 2- Programming Language: C# 3- Database: MySql 5 At present, Database structure is as follows: 1.accAccounts (For holding information about Chart of Accounts like Account Code, Name, Subsidiary or Detail, Opening Balance etc) 2.vMaster (For Vouhcer Master information, Like Voucher Number, Date, Voucher Type (i.e Payment/Receipt/Journal), Payee Name, Remarks, Debit Account, Credit Account, Amount) 3. vDetails (For Voucher Detail information, used for further allocation of Expenses/Assets uses AccCode, Debit Amount, Credit Amount) 4. TranPost (All transactions from vMaster and vDetails will be posted in this table) The General idea is this: User create new Voucher, enter transactions for Payment/receipt/journal etc. Then save the voucher. After approval of supervisor, Voucher will post and all transactions were copied to TransPost, once posted vMaster and vDetails were restricted to further editing. Ofcourse when data is available in TransPost table, generation of Trial Balance, Balance Sheet & Income Statement will be based upon it. Now my Question is: Is this the correct approach for development of Accounting Software? I am mainly concern about Year end closing process. Should I use same vMaster/vDetails/TransPost tables for every Accounting period or should I create new tables for each period? Assuming 50-80k transactions per year. What is the recommended way? For accMaster I think it should be the global table for All accounting periods, if yes, then it needs also in Master/Detail structure for holding different Opening balances for each year. As mentioned, I am a beginner and what I've learned so far is by 'learn-by-doing' approach and guidance of all experience programmers in the forums like this. So I am in need of guidance again. Looking forward for suggestions from all Masters specially those who are in development of Accounting Softwares. Thanks in advance Ahmed
As a beginner taking on a project of this scope I think you are nuts. I'd look for a smaller more defined project (probably business based but not the underlying accounting system). If you are serious then you need to talk to an accountant conversant with various accounting systems, then nail down the scope of what you want to attempt and start getting some specs together working with the accountant. On the other hand if you are attempting to create a simplistic invoicing system then talk to an accountant AND the business user - your client. If this is for a business you should consider buying an existing system and bolting on your customised front end.
Never underestimate the power of human stupidity RAH
-
As a beginner taking on a project of this scope I think you are nuts. I'd look for a smaller more defined project (probably business based but not the underlying accounting system). If you are serious then you need to talk to an accountant conversant with various accounting systems, then nail down the scope of what you want to attempt and start getting some specs together working with the accountant. On the other hand if you are attempting to create a simplistic invoicing system then talk to an accountant AND the business user - your client. If this is for a business you should consider buying an existing system and bolting on your customised front end.
Never underestimate the power of human stupidity RAH
Thanks for your reply, I haven't take this project for business purpose. It's a practice project for my self. Once mastering the important areas, I will move on to more advance topics. Your suggestion to consult with accountant is already followed, as I am an Accountant :-D, and learning programming as an hobby. As an accountant I can assure you we can only provide information about Accounting policies not how a programmer map it to business logic in application, hence I am here. So back to my original question: What is the recommended way to design Tables to record accounting transactions? Is it same transactions table to records multiple financial year data or multiple Tables for multiple year. Regards Ahmed
-
Thanks for your reply, I haven't take this project for business purpose. It's a practice project for my self. Once mastering the important areas, I will move on to more advance topics. Your suggestion to consult with accountant is already followed, as I am an Accountant :-D, and learning programming as an hobby. As an accountant I can assure you we can only provide information about Accounting policies not how a programmer map it to business logic in application, hence I am here. So back to my original question: What is the recommended way to design Tables to record accounting transactions? Is it same transactions table to records multiple financial year data or multiple Tables for multiple year. Regards Ahmed
I am not an accountant nor have I ever worked on any accounting software, but I have dealt with database applications a lot. Your suggested records per year of 50-80K will definitely not be an issue for a database table on platforms like MySQL or MSSQL or Oracle or the likes, unless you are running wide open queries such as (select * from table) without any filter or limitation on rows returned. Database design can become complicated if you want a very efficient means of storing your data. You may look over your required data several times and see if there are relations to break out into separate tables as much as possible and use primary keys, foreign keys and joins to bring your data together. Such as your "year" you could create a table that contains a primary key, year identifier and other year associated data and then that primary key would be a foreign key in your transaction table to match those transactions to that year etc. Hopefully that kind of makes some sense and helps in some way.
-
I am not an accountant nor have I ever worked on any accounting software, but I have dealt with database applications a lot. Your suggested records per year of 50-80K will definitely not be an issue for a database table on platforms like MySQL or MSSQL or Oracle or the likes, unless you are running wide open queries such as (select * from table) without any filter or limitation on rows returned. Database design can become complicated if you want a very efficient means of storing your data. You may look over your required data several times and see if there are relations to break out into separate tables as much as possible and use primary keys, foreign keys and joins to bring your data together. Such as your "year" you could create a table that contains a primary key, year identifier and other year associated data and then that primary key would be a foreign key in your transaction table to match those transactions to that year etc. Hopefully that kind of makes some sense and helps in some way.
Trak4Net wrote:
I am not an accountant nor have I ever worked on any accounting software, but I have dealt with database applications a lot. Your suggested records per year of 50-80K will definitely not be an issue for a database table on platforms like MySQL or MSSQL or Oracle or the likes, unless you are running wide open queries such as (select * from table) without any filter or limitation on rows returned.
Database design can become complicated if you want a very efficient means of storing your data. You may look over your required data several times and see if there are relations to break out into separate tables as much as possible and use primary keys, foreign keys and joins to bring your data together. Such as your "year" you could create a table that contains a primary key, year identifier and other year associated data and then that primary key would be a foreign key in your transaction table to match those transactions to that year etc.
Hopefully that kind of makes some sense and helps in some way.Very nice guidelines, I will definitely follow them, thanks a lot.