Economy

Introduction

Evidence of contributions is a typical problem for the double-entry bookkeeping. Why? Because [http://en.wikipedia.org/wiki/Double-entry_bookkeeping_system#Timeline at 12.-13. century, when the double-entry first appeared in written mentions,  yet nobody could think of no better and simpler system of internal financial records for any entity (sole trader, NGO, company or a university ...).

The principle of double-entry bookkeeping is really trivial: for every financial transaction you are getting is of the form

  ______________________ Amount ____________________
 | source binary Account | ----------> | target binary Account |
 | __________________ |                | _________________ |

Eg. when Franta Siska send being matched by amount of CZK 1,000, it can be dually accounted as follows:

______________________    1000 Kč   ____________________
|  Franta Siska                    | ---------->| our bank account  |
|_____________________|               |________________|

or like this:

______________________ 1000 CZK ____________________

| Member contributions | ----------> | Credit Franta Siska | | _________________ | | _______________ |

Note: what is the second way of account "membership fees"?

Money in the double-entry account can not come from "nowhere", on both sides of the arrow must be some bills.

The advantage of this is that if we all membership fees transferred to one account "Мembership fees" the current state of this account say how many of contributions we chose. Account balance is obtained with a single query in style:

SELECT balance FROM accounts WHERE accounts.name="Мembership fees".

DB Schema

With double-entry accounts we can open up the required accounts

Example: You want to know how much we spend for UTP cables. Therefore create account "UTP cables" and it will convert the amount of each purchase of UTP cable.

In FreenetIS double bills stored in a table accounts.

After installing FreenetISu accounts table contains only about 5 bills, but over time their numbers are growing, because every paying member is automatically created "his" double account, on which stores his funds.

In FreenetISu member can assigned other double-entry accounts - these are accounts of projects, but about that next time.

Transfers between accounts are double-entry table transfers. Its columns are :

• Origin_id , destination_id : id accounts from the table Accounts
• Previous_transfer_id : used in complex transactions that consist of multiple transfers. Eg . posting invoices are normally makes two transactions. To make it clear that these two transactions "belong together" previous_transfer_id in the second point to the first transaction.
• Member_id : ID user from which account originates deal. It may seem that this column is not necessary, because in each user's account is also listed member_id.. But keep member_id and transfers in the table is useful in multi- step transfers . Eg . accounting for payment of the membership fee in our association we do in 5 transfers , only one of which targets a credit account member. We want to simply see that the other transfers "caused" this particular member - we could deduce although complicated over previous_transfer_id , but the question , it would be crazy.
• User_id : user id , which created a binary transfer . In FreenetISu the right of access to economic assign more people so it is important to know which one of them committed the transfer .
• Type: 1 = regular monthly contribution , 2 = initial contribution , 4 = recharge VOIP credit ...
• Datetime : date and time of the transaction. Eg . in online banking statement will indicate these date and time. The invoice date there will be a taxable transaction.
• Creation_datetime : date and time when the transfer was entered into FreenetISu
• Text , Amount - description of payment and amount

Note for experts of double-entry bookkeeping: table transfers is actually common accounting journal - the same as my grandfather 50 years ago led on the paper ...

Table account_attributes

Speaking thus dually account is a good idea to have our double bills "compatible" with the legislation of our country.

Then the binary states of accounts in FreenetIS instantly start using the pan (s) accounts our organization, because his (her) it saves a lot of work.

To achieve the compatibility of the legislation for each double counting account is necessary to find an appropriate accounting standard account in accordance with the law.

Standard accounts legislation defines as the chart of accounts (Britons have a better term: chart of accounts).

The chart of accounts is a list of possible accounts for the type of organization. For each account in the chart of accounts is defined its standard name, standard number and other attributes.

The chart looks like for nonprofits, a little different for businesses, a little different for government.

In FreenetIS chart of accounts is stored in a table account_attributes as a chart of accounts for non-profits.  Other types of charts of accounts (eg business) to deal with installer FreenetIS, but so far nobody wanted.

We probably most interested in which standart accounts will be mapped credit members' accounts?

The dual credit account can be a member by the chart of accounts for non-profit organizations to implement either

1. Sub-standard account "membership fees" (standard number in the chart of accounts = 684,000)
2. Sub-standard account "Bank Accounts" (No. 221000)

In FreenetISu use the second option because it is the same for nonprofits as well as for other entities whose financial chart of any membership fees (684,000) do not know.

More detailed explanation can be found in this presentation:

• ~ dulik/unart/hospodareni_v1_5.pdf PDF format
• ~ dulik/unart/hospodareni_v1_5.odp ODP format

On slide 13 is shown how the membership fees will be charged in UnArtu (Imported from EBANKA).

Types double-entry accounts used when importing from the bank

• Account_attribute_Model :: MEMBER_FEES - type "membership dues"
• Account_attribute_Model :: SUPPLIERS - type "contractors"
• Account_attribute_Model :: OPERATING - operating account into which all fall uncategorized revenues and expenses Association
• Account_attribute_Model :: CASH - account for cash payments (cash)

Evidence bank accounts

Unlike conventional accounting systems (Pohoda, Money S3) FreenetIS has a better record of bank accounts of members - FreenetIS allows you to keep track of each member to its bank accounts. It often helps us to identify payments with poor variability - although many members (= families) pay the wife's bank account, which bears her maiden name (different from the surname of the family), we are able to register through bank accounts instantly know which member is the originator such payments.

Bank accounts recorded in the table 'bank_accounts'.

After installation FreenetIS there will be only bank account of the association.

Other members of the bank accounts automatically creates by import from ebank. For payments that are proper of variable, also importer newly generated by banks. account automatically assigns the owner.

If you want to import bank statements that does not contain bank accounts, then you will have to create account in the table "bank_accounts" as "unidentified"

Why? See the next chapter:

Evidence of bank statements

Bank statements recorded in the table bank_statement.

Each bank statement consists of many banking transactions. Banking transactions are transfers between bank accounts. Therefore, we record similar to the double-entry transfers between accounts - using the table bank_transfers, which contains the following columns:

• Origin_id, destination_id: id bank accounts of the table bank_accounts
• Transfer_id: id double-entry transfer of table transfers. Each bank transfer should be dually recognized ie refer to a double-entry transfer. If you did not recognize some bank transfers, there will be accounting error - status of double-entry account "bank account" will not sit with the actual state bank account
• Bank_statement_id link to a table of banks
• Number: Line number or number of the item bank listing
• Variable_symbol, constant_symbol, specific_symbol - it is probably clear
• Comment - any comment on the accounting for a payment

Date, time and text payments, we decided not to record in this table, but in the table transfers - because every bank_transfer has always assigned a transfer, they would have the same name, the columns in the table bank_transfers redundant.

Terminology

• The code uses a mixture of English "simply stated" and the official accounting terminology.
• Official English and the corresponding Czech accounting terminology is described

In this ** 20Dictionary.doc glossary PhD work in ** Radek Vogel MUNI Brno].

Import bank statements

FreenetIS currently can import HTML listings of ebanka / Raiffeisen banks and any listings in CSV format. The largest part of the work in this area represent parsers - especially HTML parser ebanka. Therefore parsers are written so that they have no dependency on the framework Kohana nor FreenetISu - they are completely separate library.

Description of the implementation of the following articles:

• Preparation for the data import
• Raiffeisenbank
• Fio banka
• Saving data to the database