Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
Does anybody know or have any links to websites describing details of how to design a database schema for a double entry accounting system ??.
I did find a bunch of articles but non were very explanatory enough.
Would appreciate it if someone could help me on this.
Create the following tables
account
transaction
line_item
contact (can be a customer a supplier, or an employee).
To keep things simple, we will leave out the account_type table, contact_type table, etc.
Identify the relationships between the tables and set them up
a contact can have many transactions, but each transaction can only have one contact (one-to-many relationship)
an account can have many transactions, and one transaction can affect many accounts; line_item is the join table between transaction table and account table (a many-to-many relationship)
a transaction can have many line items, but each line item must relate to one transaction.
We have the following schema (a one-to-many relationship):
CONTACT ———< TRANSACTION ———< LINE_ITEM >——— ACCOUNT
Add appropriate fields to each table
Contact
contactID
name
addr1
addr2
city
state
zip
phone
fax
email
Transaction
transactionID
date
memo1
contactID
ref
Line_item
line_itemID
transactionID
accountID
amount
memo2
Account
accountID
account_name
account_type
Create as many new transactions as needed
For example to add a new transaction in the database, add a new record in the transaction table and fill in the fields, select a contact name, enter a date, etc. Then add new child records to the parent transaction record for each account affected. Each transaction record must have at least two child records (in a double-entry bookkeeping system). If I purchased some cheese for $20 cash, add a child record to the transaction record in the child record, select the Cash account and record −20.00 (negative) in the amount field. Add a new child record, select the Groceries account and record 20.00 (positive) in the amount field. The sum of the child records should be zero (i.e., 20.00 − 20.00 = 0.00).
Create reports in the database based on the data stored in the above tables
The query to give me all records in the database organized so that transaction line item child records are grouped by account, sorted by date then by transaction ID. Create a calculation field that gives the running total of the amount field in the transaction line_items records and any other calculation fields you find necessary. If you prefer to show amounts in debit/credit format, create two calculation fields in the database query have one field called debit, and another called credit. In the debit calculation field, enter the formula "if the amount in the amount field from the line_item table is positive, show the amount, otherwise null". In the credit calculation field, enter the formula "if the amount in the amount field from the line-Item table is negative, show the amount, otherwise null".
Based on this rather simple database design, you can continuously add more fields, tables and reports to add more complexity to your database to track yours or your business finances.
I figured I might as well take a stab at it. Comments are appreciated – I'll refine the design based on feedback from anyone. I'm going to use SQL Server (2005) T-SQL syntax for now, but if anyone is interested in other languages, let me know and I'll add additional examples.
In a double-entry bookkeeping system, the basic elements are accounts and transactions. The basic 'theory' is the accounting equation: Equity = Assets - Liabilities.
Combining the items in the accounting equation and two types of nominal accounts, Income and Expenses, the basic organization of the accounts is simply a forest of nested accounts, the root of the (minimum) five trees being one of: Assets, Liabilities, Equity, Income, and Expenses.
[I'm researching good SQL designs for hierarchies generally ... I'll update this with specifics later.]
One interesting hierarchy design is documented in the SQL Team article More Trees & Hierarchies in SQL.
Every transaction consists of balanced debit and credit amounts. For every transaction, the total of the debit amounts and the total of the credit amounts must be exactly equal. Every debit and credit amount is tied to one account.
[More to follow ...]
Related
System has many users belongs to a company. Admin user of the company can entry customers and each customer may have invoices with payment amount. The customer invoice amount need to be paid and should be inserted in double entry system in transaction master table.
Data Models are followings:
User
Company
Customer
Invoice
Transaction Master
My initial approach will be:
Company will have a one to many relationship with users
in invoice table, the details will be saved.
My questions are:
Do I need to create any relationship between customers and invoices tables?
How the transaction master table will be created? (double entry system refers to have debit and credit accounts, that's all my knowledge)
Yes, you need to create a relationship between customers and invoices table. Every invoice will have one customer. Every customer will have none, one, or many invoices. You will need a unique identifier to be stored in each file.
Transaction file is a much deeper subject. I assume you mean Ledger Transactions. Generally you will group a transaction with one or more debit entries matched with one or more credit entries with an associated reference number which will point to the invoice transaction. You would group references in a batch, usually called a session, and assign a session number at batch posting time which would have the post date.
These are the basic minimum answers to a very vague question on a potentially complex subject, but hopefully it will help get you started in the right direction for further research.
I am building a new business application for my personal business which has close to ~100 transactions of sale and purchase per day. I am thinking of having Separate tables to record the sale and purchase with another linked table for Items that were sold and a seperate linked table with items that were purchased.
Example:
**SaleTable**
InvoiceNo
TotalAmt
**SaleTableDetail**
LinkedInvNo
ProductID
Quantity
Amount
etc.,
would this design be better or would it be more efficient to have one transactiontable with a column stating sale or purchase?
-From an App/Database/Query/Reporting Perspective
An invoice is not the same as a sales order. An invoice is a request for payment. A sales order is an agreement to sell products to a party at a price on a date.
A sales order is almost exactly the same as a purchase order, except you are the customer, and a sales order line item can reference a purchase order line item. You can put them in separate tables, but you should probably use Table Inheritance (CTI, extending from an abstract Order). Putting them in the same table with a "type" column is called Single Table Inheritance and is nice and simple.
Don't store totals in your operational db. You can put them in your analytic db though (warehouse).
You are starting small, thats a quick way to do. But, I am sure, very shortly you will run into differences between sale and purchase transactions, some fields will describe only a sale and some fields that will be applicable only for purchases.
In due course, you may want to keep track of modifications or a modification audit. Then you start having multiple rows for the same transaction with fields indicating obsoletion or you have to move history records to another table.
Also, consider the code-style-overhead in all your queries, you got to mention the Transaction Type as sale or purchase for simple queries.
It would be better to design your database with a model that maps business reality closest. At the highest level, everything may abstract to a "transaction", with date, amount and some kind of tag to indicate amount is paid or received against what context. That shouldn't mean we can have a table with Tag, Date, Amount, PayOrReceive to handle all the diverse transactions.
I'm trying to build a database for banking I created a table for every account loan, deposit , checking account and also for payment methods checks, debit cards and cash.
My question is that how should I handle transactions between the tables knowing that the transactions are possible between all the tables?
For example customer can withdraw money using debit card, transfer money from checking account to loan or deposit money to checking using a check.
My first solution is to create one transaction table for all the transactions and the Cardinality (0...1 n ) so that only one type of payment and one account, so should I go with it or just create a transaction table for every relationship between two tables?
If "I created a table for every account, loan, deposit , checking account" means that you have more than four tables then you are doing something very very wrong. You should have one table for customers and one table for transactions. A transaction is money moving from one account to another account, so a simple transaction table would have the fields id, transaction date, credit account, debit account, amount. In accountancy, there are frequently transactions which involve several credit and debit accounts so these can't be maintained in the simple transaction scheme outlined above.
If you want to represent loans, then you'll probably need two more tables: one table contains the atomic details of all the loans (date given, account of the loanee, total amount, nominal interest rate, etc) and the other table contains the projected repayments of each loan.
There is no need for further tables representing deposits or checking accounts: these can be represented as accounts, with a type field designating which kind they are.
Consider these two use cases.
Say a store gives out store credit for customers. Store credit come from refunds, discounts, overpaying amounts etc...
The customer decides how and when to
use this credit. E.g. Say customer A
have $50 dollars in store credit and
he decides to use $25 for invoice A
and $25 for invoice B... or decides
to have the store credit sitting
there against his account for future
purchases.
The customer and store must also
have a way to look up the total of
store credit.
What is the easiest and most straight forward way to cater for this in table structure?
I currently have tables:
Transaction (For journal and reporting purpose)
Customer
Credit
Used Credit
Invoice table will have other associations like invoice lines, receipt, receipt lines etc...
Is this the best way to do this? My concern is primarily regarding ease of reporting and transaction mechanics.
Alternatively I'm considering just saving all credit entry and used credit inside the transaction table.
Updated diagram for clarification and from inputs
Correct me if I'm wrong, but I believe you want something like this.
A Customer has CreditEntrys, and CreditEntrys have UsedCredites. There are also Transactions which include links to corresponding Invoice. And finally, a Transaction has links to many UsedCreditwhich were used during this transaction. If all CreditEntry was used at a time, then there will be one UsedCredit used with this Transaction, and this UsedCredit will correspond to the entire CreditEntry
The database schema would be quite straightforward here - relations through foreign keys. You would probably want to create an additional unique constraint to reflect ONE-TO-ONE relation between Transaction and Invoice
Oh, by the way, that service that you used for diagram creation is cool.
create 4 tables, 1 for customers then another for their credit and used credit and then another for transaction and invoice. You may join transaction and invoice since they may have similar data.
My application needs to implement a one to one relation between multiple tables. I have a table which store companies (which can be customers and suppliers, or both). There are twi Bit fields, Customer and Supplier.
Then I have different tables for various operations: Invoices, Bank operations, Cashdesk operations. An I need to pair payments with invoices. A payment is not exact amount of an invoice, but it can be split over each number of invoices. Also, an invoice can be split over multiple payments. Payments can be from both bank or cashdesk operations
My original approach was to have a table, PaymentRelations, with Foreign Keys InvoiceID, BankOpID, CashOpID and Amount, and for any payment between between them, I create a record with only two foreign ID's filled, and the corresponding amount. This way in any moment I can know for each operation (invoice or payment) how much was paid.
Also there are RI requirements, so if a document is involved in payment relation, it cannot be deleted (or there is cascade delete, so if a payment of invoice document is deleted, the related PaymentRelations records are deleted, so the counterpart operations are freed - they are no longer involved into payment relations so their amount can be fully used into other payment relations).
But appeared another situation. Since partners can be both customers and suppliers, it is possible to compensate between same type of operation on customer and supplier side of the same partner (e.g. a partner is both customer and supplier, he made an invoice as supplier for 100 and received an invoice as customer for 150, 50 was compensated between the received and the sent invoice and the rest of each is paid through one or multiple payment operations).
This can also happen for the other operations (e.g. he paid through a bank operation 100, he received through another bank operation 200, and 50 needs to be compensated between those two operations; same apply for caskdesk operations).
What approach would you use to model this kind of relations?
I would buy accounting software instead of writing it. Some wheels are worth reinventing; this isn't one of them.
But if you must . . .
Bitfields are the wrong way to identify customers and suppliers. This SO answer should get you over the issues with customers and suppliers.
If I had to design an accounting system, I think I'd start with a spreadsheet. I'd design a table of transactions in that spreadsheet, so I could get the feel of how certain transactions were alike, and how others were different. At this stage, I wouldn't worry about NULLs, about repeating groups, about transitive dependencies, or anything else like that.
Having developed a working(ish) model in the spreadsheet, I'd then try to normalize it to 5NF.