PHP Framework
The project will be developed using php and Laravel 4 (In beta but can be used for production), Laravel 4 is a framework for web artisans, applies the Model View Control (MVC) architecture/design pattern. Laravel contains a very strong database Object Relationship Mapper (ORM) called Eloquent (ActiveRecord Implementation) which will help us with our complex relations.
Laravel 4 also implements restful controllers / Resource Controllers and restful routes pattern in core.
Database
Data Models
- Region
- FundRequests
- Receipts
- Account
- Role
- Journal
- PostingEntry
- TransactionType (Optional, Can be Hard Coded)
- BudgetProposals
- ProposalItems
Access Control
FAS authentication
The Fedora Account System keeps track of Fedora Project contributors and the projects they work on. It is used to grant authentication and authorization to various components. FAS will be implemented in our system to authenticate users.
Process:
- User ask the system to authenticate
- FAS will authenticate the user
- FAS will send the username or unique user id.
- Username or unique user id will be saved in a table with the corresponding role_id
- When the user perform an action the system will check the corresponding role id if that role is permitted with Permission to do the action.
Suggestion: I am not sure that FAS support groups, If it support groups and the api allows to query the authenticated user groups, I suggest creating two groups in FAS one for the Budget owners and one for the FAm (Maybe both are already created), and instead of doing the role assignment inside out system, It happens inside FAS.
Roles
We will create roles to be able to determine if that user have the right permission to perform a specific action.
Basic Roles:
- Adminstrator
- FAmSCo members
- Budget Owner
- FAm
Permissions
Permissions is a set of actions which maybe share by one or more Role(s). In the system we are going to check the user permission before making any action, If the logged in user role has the needed permission to perfore the action It will be performed otherwise he/she will be prompt by an error message e.g ("Access Denied") or we can throw an exception.
Example of permissions:
- view_budget
- allocate_budget
- view_fund_request
- create_fund_request
- approve_fund_request
Determining all the Permissions now is a hard job, I will maintain a list of permissions and explanation for each one in a wiki page while implementing the project.
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’).
Example Scenario 1:
- Budget Owner "Tom" allocate $500 for region "EMEA". Deposite transaction.
- In normal paper double entry accounting system the allocated budget account will be credited by $500, and the Cash Book account will be debited by $500 to match.
- The system create a new Journal entry which will save Deposit as transaction type, "Tom's" user id, region "EMEA" id.
- The system will aslo create two entries in the Posting table.
- 1st Entry: Journal Transaction Id, Account (Allocated Budget) id, Value = 500.
- 2nd Entry: Same Journal Transaction Id, Account (Cash Book) Id, Value = -500.
Example Scenario 2:
- FAm "John" submitted a receipt related to a previously approved fund request with a value of $100, He is in "EMEA" region and want to get paid. Withdrawal Transaction.
- In normal paper double entry accounting system we will create one journal entry.
- Region Expense account will be debited by $100 and the Cash Books will be credited by $100
- The system will create a new Journal entry which will save Withdraw as transaction type, "John's" user id, region "EMEA" id.
- The system will also create two entries in the Posting table.
- 1st Entry: Journal Transaction Id, (Region Expense account) id, Value = -100
- 2nd Entry: Journal Transaction Id, (Cash Books account) id, Value = 100
Transaction Types
There will be two types of transactions in our system.
- Deposit: Will be used when the Budget Owner allocates budget.
- Withdrawal/Payment: 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 two entries in the Posting table one for the debit and the other for the credit each with the amount and accounting period.
Note: 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).