Specifications General Ledger

multiple currencies

• There is a base currency for each ledger, the balances of the ledger are stored in the base currency
• There is an international currency
  • it is only used for reporting (previously it was stored with each balance, but that caused too much problems/overhead)
• There can be foreign currency accounts which have balances in their own currency
  • they can be revaluated with a new daily exchange rate
• exchange rate is stored in the database
  • corporate exchange rate (eg. issued once per month, an average exchange rate over the last 30 days)
    • the corporate exchange rate is used for calculating the reports in international currency
    • it is also used by ICH for clearing the debits/credits of the different offices between each other
  • daily exchange rate: this can be updated each day, or downloaded from Yahoo Finance etc.
    • the daily exchange rate is used for transactions with other currencies (different from base currency)

transactions

double entry bookkeeping

• see also http://en.wikipedia.org/wiki/Double-entry_bookkeeping_system

Transactions in GnuCash

• see [1]
  • "For every transaction, total debits must equal total credits."
• see GnuCash Manual: Multiple Split Transactions; also see a discussion here: [2];
  • there are simple transactions (one split), which just post to 2 accounts, with same (opposite) amount, same narrative etc
  • there are multiple split transactions, that have several transactions, and combined they balance
  • see the GUI of GnuCash for this:

You can switch between View: Basic Ledger, this shows only the summary:

The other View is: Transaction Journal, this shows all movements of money involved:

Transactions in Petra 2.x

• the definition of transaction in Petra 2.x is different from anyone else's definition: In Petra 2.x, a transaction only involves one account, therefore you need at least 2 transactions to get to "total debits equal total credits".
• in Petra 2.x: a lot of transactions are in one journal, only some of them really belong together ("total debits equal total credits").
• a journal was only used for different grouping transactions by currency
• it was hard to find all parts of a real transaction, because there were so many transactions in the journal unrelated to each other

Transactions in OpenPetra

• option 1: do the same as GnuCash:
  • keep the same database structure as in Petra 2.x, with a_batch/a_journal/a_transactions
  • different GUI: journals are not displayed anymore as such, but they become the transactions to the user;
    • you can expand a journal line and see/edit the simple or split transactions involved
    • when a journal row is selected, show the details for the journal in the edit section
    • if a transaction row is seleted, show either simple transaction edit (2 accounts), or one of the split transactions
    • buttons: add journal, add transaction, add split transaction
  • simple transaction involves 2 accounts
    • only one reference/narrative/amount
  • split transaction: allows to define each account/reference/narrative

• option 2: keep the Petra 2.x users happy
  • addition in the database: a_transaction.a_transaction_group_i: refers to one transaction in the group; all transactions with the same a_transaction_group_i make up a real bookkeeping transaction
    • it might actually work to use the a_reference_c field; but we should then disallow manual editing of that field
  • GUI: mark several transactions in the grid, and click button "Group", which will assign the first transaction_number_i to all transaction_group_i in the group.

• improved reports will show the opposite transaction(s), on Account Detail report etc.
• we should change the names for Transaction in the common language files to reflect the usual meaning of Transaction to avoid misunderstandings with trained bookkeepers
• import transactions from text file; group transactions as soon as the totals of credits balances the totals of debits.

Posting

• posting: should show a preview of how the account balances would be after posting???
  • see also http://sourceforge.net/apps/ideatorrent/openpetraorg/ideatorrent/idea/3/

reduce number of tables

• to test: should there be 3 different tables, for transactions from the current periods, the closed periods of the current year, and periods of previous years?
  • is Postgresql fast enough to cope with all transactions in one table?
  • this would make reporting much easier

Analysis Attributes

Description

Analysis Attributes are "tags" with values that you can assign to a part of a transaction.

When an account is linked to an Analysis Attribute, all transactions to that account are forced to have an Analysis Attribute Value assigned to the transaction.

Examples:

• for assigning tax codes to transactions to the income account for book sales. some transactions have lower tax values, eg. Books, and CDs have the normal VAT tax.
• for assigning car registration numbers to accounts for fuel or car repairs. This way you avoid needing a separate cost centre for each car. Although that might be a good idea too...

Database

• a_analysis_type defines the types of Analysis Attributes, eg. Tax, Car Registration Number
• a_freeform_analysis defines the values for those types, eg. VAT5%, VAT17.5%, SI-CA-007, etc.
• a_analysis_attribute links an analysis type to an account, ie all transactions to that account are required to have an analysis attribute value associated with the transaction
• a_trans_anal_attrib tags a transaction with the given analysis attribute value

User Stories

• I want to be able to create a new type of analysis attribute, and want to create predefined values for such a attribute.
• I want to connect analysis attributes with accounts.
• When I enter a GL transaction to an account that is associated with an analysis attribute, I want to be prompted for a value from a list of available values.