From Fedora Project Wiki
No edit summary
(double entry system basic setup.)
Line 1: Line 1:
== Database ==
== Database ==
=== Data Models ===
* Region
* Account
*


== Access Control ==
== Access Control ==
Line 10: Line 15:


== Double Entry System ==  
== Double Entry System ==  
In a ‘double entry’ system each value is stored twice, once as a credit (a positive value), once as a debit (a negative value).
'''Rules to consider when making a double entry:'''
* Every entry into the system must balance – i.e. the sum of any transaction must be zero.
* The sum of all the values in the system at any one time must be zero (the ‘trial balance’).
* No values can ever be amended or deleted. They must be negated with an opposing entry (a ‘contra’) and re-entered (‘re-booked’).
'''Technical Representation:'''
*


=== Transaction Types ===  
=== Transaction Types ===  
There will be two types of transactions in our system.
* Deposit: Will be used when the Budget Owner allocates budget.
* Withdrawal: Will be used when the FAm attach the receipt to an approved Fund Request, to create the needed journal entries.


=== Accounts ===
=== Accounts ===
Basic Accounts to be used in any journal entry, Account will increase as the system expand, as a start we will track the following accounts:
* Cash Books: To track the cash in/out flow to the system
* Allocated Budget: To track the decreases and increases for each region allocated budget.
* Region Expense: To track the expenses for each region.
=== Journal ===
Journal is a representation to for both debit and credit side of any transaction (Check Posting Below), Here we will save a unique sequential id for the journal, Transaction Type, User and Region, When creating a new journal the system will auto create to entries in the Posting table one for the debit and the other for the credit each with the amount and accounting period.
The system should verify that every journal entry created have two corresponding posting entries, to ensure that the accounting rule is applied.
=== Posting ===
Posting is where the actual amount are saved whether to the debit side or the credit side, we will generate a unique id for each entry then save:
* journal id: The corresponding journal id from the above
* account: The corresponding account e.g (cash books, allocated budget, region expense).
* value: Debit will be represented by a negative value and Credit will be represented by a positive value.


=== Journal Data ===
Note:
* The balance of the Posting Amount column always being zero after every complete Journal transaction.
* System must not allow an incomplete one (debit without credit or vise versa).


=== Posting Data ===


== Report Generation ==  
== Report Generation ==  


=== Region Ledgers ===
=== Accounts per Region Ledgers ===

Revision as of 11:16, 1 May 2013

Database

Data Models

  • Region
  • Account

Access Control

FAS authentication

Roles

Permissions

Double Entry System

In a ‘double entry’ system each value is stored twice, once as a credit (a positive value), once as a debit (a negative value).

Rules to consider when making a double entry:

  • Every entry into the system must balance – i.e. the sum of any transaction must be zero.
  • The sum of all the values in the system at any one time must be zero (the ‘trial balance’).
  • No values can ever be amended or deleted. They must be negated with an opposing entry (a ‘contra’) and re-entered (‘re-booked’).

Technical Representation:

Transaction Types

There will be two types of transactions in our system.

  • Deposit: Will be used when the Budget Owner allocates budget.
  • Withdrawal: Will be used when the FAm attach the receipt to an approved Fund Request, to create the needed journal entries.

Accounts

Basic Accounts to be used in any journal entry, Account will increase as the system expand, as a start we will track the following accounts:

  • Cash Books: To track the cash in/out flow to the system
  • Allocated Budget: To track the decreases and increases for each region allocated budget.
  • Region Expense: To track the expenses for each region.

Journal

Journal is a representation to for both debit and credit side of any transaction (Check Posting Below), Here we will save a unique sequential id for the journal, Transaction Type, User and Region, When creating a new journal the system will auto create to entries in the Posting table one for the debit and the other for the credit each with the amount and accounting period.

The system should verify that every journal entry created have two corresponding posting entries, to ensure that the accounting rule is applied.

Posting

Posting is where the actual amount are saved whether to the debit side or the credit side, we will generate a unique id for each entry then save:

  • journal id: The corresponding journal id from the above
  • account: The corresponding account e.g (cash books, allocated budget, region expense).
  • value: Debit will be represented by a negative value and Credit will be represented by a positive value.

Note:

  • The balance of the Posting Amount column always being zero after every complete Journal transaction.
  • System must not allow an incomplete one (debit without credit or vise versa).


Report Generation

Accounts per Region Ledgers