Bookkeeping module for Drupal commerce users

About Me
Hello everyone I am Paras Kuhad, B Tech Final year student from India. I have been working with drupal since last one year. I see drupal more as a framework. I would like to contribute some serious piece of code this summer.

Overview
My idea is to develop a bookkeeping module. As an accounting application bookkeeping provides you the basic means to manage your financial information and to generate useful reports. This module will enable drupal to be deployed as a Financial Information Management tool.

Description

Why an Accounting Application based on CMS
Around me a lots of user are there using some accounting tools without any modular structure. If they provide some customizability then it is limited to either report generation or some field manipulation. Using a modular CMS like drupal this customizability can be exposed to its extreme where from the ledger manipulation to report generation anything will be customizable. It would be useful to write such 'Financial Management' application for drupal that can also be used in intranet environment.

Features
This application would be based on double entry based bookkeeping method. My task would be to design bookkeeping API and incorporate basic functionality of bookkeeping : -
[A] Bookkeeping API :

[1] If a bookkeeping system is being developed in drupal then definitely it should be an integration module that provides integration hooks to other commerce modules.
[2] Bookkeeping API should be generalized in such a way so that code is usable for Commerce projects and they also can maintain their transactions.
[3] These API function set would be separated from UI and validation logic in such a way so that they can provide open hooks to other potential colleague modules.

[B] Implementing data entities and transaction entry :
[1] Introduction of accounting masters over which whole bookkeeping lies : Groups and ledgers. Ledgers are supposed to behave like native entity types as it would be much easy to attach extra fields like address of account holder using field UI . I would be introducing primary groups and secondary groups under assets, liabilities, income and expenditure but this project will support infinite level of grouping. User will be able to create customize groups and subgroups in any nature.
[2] Introduction of transactions/ vouchers types : Payment, Receipt, Sales, Purchase, Journals, Bank paid/received. These things would be content types. Since in bookkeeping transaction is the thing that attaches debit side ledgers and credit side ledgers with amount. Dynamic user interface, proper validation and database operation would be handled using prepared library function set along saving the node. Since it is a node it is pretty much easy to attach meta information in fields like consignee name, transportation detail.

[C] Statements and report generation :
[1] Display interface of trial balances and voucher statements: Although voucher statements would be easy to handle after views integration but task of displaying trial balances remains in core implementation of this project using native library function set as queries in trial balance display cannot be handled with views. I will have to write some recursive functions in API as grouping of ledgers is totally customized, so a group can have child groups as well as child ledgers.
[2] Preparation of Balance Sheet and final accounts : Profit & Loss A/c, Trading accounts
Preparation of balance sheet is an on going process that keeps changing over transactions but on closing of a financial period behavior of financial account is need to be defined that affects balance sheet and other reports as well.

Earlier work
These posts are under my concern :
http://drupal.org/node/163443
http://drupal.org/node/554924

Why Drupal
I recently deployed quiz module in an educational environment and realised that this is the Learning Management face of drupal. This same can happen with this bookkeeping module in terms of financial data processing and will be useful to users who want to deploy an accounting service in their local province.
Amazing user permission layer and node structure provides the ease of doing this. Apart from this if every transaction type is a node then it is an open door for administrator to manages these content types without writing any code.

For example :
[ 1 ] Using field UI it will be possible to customize fields which is very basic need for such kind of financial application
[ 2 ] Accounting rules can be exposed to customize the calculation.
[ 3 ] Integration with views can be used to generate dynamic reports.

What's the real part
Main part of this project would be to introduce bookkeeping entities and to generalize their behavior as per standard bookkeeping methods. This also includes designing general function set of bookkeeping and integrate whole core bookkeeping to existing views and rules module.

Considering Drupal 7 entities ledgers and groups can be concerned as a fieldable entities. It will be a clean code while keeping the core function separate interacting with entities from API and using those functions in controller classes. Transaction types are supposed to behave like a node. In double entry based bookkeeping system a transaction entry bind ledgers those are debited to those which are credited having both side amount equal. So in a transaction type node, I will be implementing their behavior as per their nature using general node hooks and separating generic functions to API. Keeping transaction types as a node, it would enable us to add fields and also help us in generating sales invoices or similar transaction types.

This is about the basic entities. Along with this integral structure and distributed organization general function would be needed in code like :

_bookkeeping_is_negative_cash_allowed($ledger_id)

_bookkeeping_trial_balance_of_group($group_id)

_bookkeeping_sales_transaction_add($debit_ids, $credit_ids, $amount, $date)

So designing core set of functions would be the part of project.

So using basic entities and transaction types holding those entities data is stored in a consistent format then there comes the report generation part. Bookkeeping API will be holding all helper functions regarding it. Integration with views becomes the necessity when I want users to generate their own reports but since financial reports like balance sheets are not just the select and filter view of primary tables of bookkeeping, these are dependent on nature of ledgers and their balances and in what transaction types they are involved , so report generation tools have to be defined in the code. Meanwhile in these calculations if I am able to expose rules of accounting method then it would be great to observe this kind of implementation.

Time Line :
Community binding period : My best efforts will go to study existing commerce projects. How should I design my code so that it will result into integration with commerce projects like e commerce and ubercart.

24 May to 31 may :

[1] Researching and reading on various bookkeeping methods.
[2] Setting up development environment and following D7 development track along with reading core code and api.
[3] Understanding code development strategies with drupal API effectively possibly with some test code related with this project.
[4] I will also be testing with multiple approaches in schema design during this period.

1 June to 15 June :

[1] Start working with bookkeeping API
[2] Initializing with accounting masters : groups and ledgers
[3] Designing database schema, code and interface to maintain these basic entities

15 June to 12 July :

[1] Working with transaction types
[2] Handling user interface for these content types
[3] Extending bookkeeping API to separate the logic of transaction entry from interface
for the re usability of code
[4] Getting suggestion for integration and modular structure of project and implementing
them

13 July to 9 August :

[1] Integrating transaction types with views
and rules
[2] Working with report generation helper functions in bookkeeping API
[3] Writing code for voucher display
interface
[4] Tweaking earlier code if needed on the base of execution of final accounts
[5] Implementing balance sheets, Profit and Loss a/c and trading accounts

9 August to 16 August :

Documentation will be a needful task. I will be writing how this codebase and module can be used effectively in combination with other modules. I will be reviewing, testing my code and handling issue queues.

Mentors :
mentor: (anybody that is also in bookeeping along with drupal please mentor me )

co-mentor : rszrama
( unofficially for integration with commerce project )

Contact Details
paras.kuhad@gmail.com
http://pacificparas.org

Difficulty: Medium to hard
I will be developing the code for drupal 7.x implementing core bookkeeping. I will write the code in the way in which standard practices of double entry based bookkeeping is followed. A complete accounting package fulfilling all requirements of variety of users and their methods of accounting is a subject of giant code in itself. After this project I would like to enhance its feature set by contributing extension modules. I see the future of this module in integrating with e-commerce aspect of drupal.