GSOC 2013/Student Application Jonathanhindi/Fin IS(466)

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: Responsible on each region (NA,EMEA,LATAM,APAC).
• FundRequests: Handles the fund request by FAm details.
• Receipts: Represents each receipt and related it to it’s FundRequest.
• User Role
• Account
• Journal
• PostingEntry
• TransactionType (Optional, Can be Hard Coded)
• FinancialYear (Optional, We don't needed but it's availability may ease some report generation and keep the data models organized)
• BudgetProposals: Represents Budget Proposal by FAm at the start of each year.
• ProposalItems: Represent each item in the BudgetProposal. (Need more clarifications on type of items and needed information)

An old detailed database structure can be found here.

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).

Report Generation

The below are just basic ideas of reports generation, I want to give the system administrators with some pre-set, simple and flexible ready reports which depends on their use case. Any other reports can be implemented later unless the data are well structured which what I am giving a higher priority, I am not going to provide a financial reports generation tool, Instead I will provide the most needed reports and make it easy for end-users to get the required data with just a few clicks.

Kindly, Suggest any other needed reports.

Fund Requests

Query Fund requests by Region, Status, Value and Financial Year.

Regions Ledger Report

• Query by Region and Financial Year.
• Shows Allocated Budget
• Shows Remaining Budget
• Shows Total of claimed Fund Requests

Budget Proposals

Query all budget proposals by some attributes:

• Type
• Items
• Region
• Total Value
• Other Attributes if Available.

FAms by Fund Requests

Query all FAms with Fund Requests