Couple of webGUI bugs to sort out:
In IE, the page title sinks below the background… = fixed!
Archive for the 'PBooks To-Do Lists' Category
I really like the idea of using a development framework for my own internal purposes, as it makes things a lot easier for managing a big project. However, for smaller, more focused projects, it might not make as much sense.
The problem with a framework is that it takes a lot to set it up. Once its setup, no problem, but for most people who only want one area of functionality, like a blog, a wiki, or an accounting system, they may not want to have to setup the framework just to get access to the specific application.
I’ve had pretty good luck with Wordpress, because it does what it is supposed to extremely well. That experience has led me to believe that not all parts of a program need to be easily and fully customizable. In addition, any open source project is ultimately fully customizable, but they may not be architected to be easily changed in every manner of speaking.
For a bookkeeping (or any web-based system) program, the interface needs to be customizable. What else? The database table names.
I think what I will ultimately end up doing is using the framework to build an independent web application which can be installed on its own, without the need for the framework. It will bloat the code, but also make it more portable. The use of XSL makes the installation of PBooks a little tough, but it might be doable. For now, I might want to simply include Nexista along with the PBooks distribution - aka a “monolithic” distribution. That is obviously not the best way to architect PBooks, but it will hopefully facilitate the introduction of new developers to the project.
This is how I currently have my development environment setup (will be copied to wiki):
/usr/share/php/nexista/
/usr/share/php/metabase/
/usr/share/pbooks/
/usr/share/pbooks/apps/pbooks/
I will expand upon this more in the wiki page “Pbooks Development“.
A couple of ideas to implement:
- Add column to entries table for balanced, processed, or posted entries (entry_state_id?)
- Only show accounts that have activity - or ability to hide accounts.
- Accounting periods - monthly, quarterly, or yearly - tasks including bank reconciliation, and closing accounts.
Sub-accounts and / or grouping of accounts- Reverse a journal entry!
Accounting periods are a very important part of bookkeeping and accounting, and very much something I want to setup in PBooks. While I’ve been reading about XBRL, I’ve noticed that they have some information on accounting periods, and I’ll also check out some of the notes I saw on the Gnucash wiki. I’ve also happened upon a bunch more open source accounting programs at sourceforge so I’m going to dig through those ones before I craft my own. So I found a decent reference to “accounting periods”. Its simple enough for me to understand at this point, and I’d like to build on the basic concept. Rick Bradley’s Accountomatic is the program I found this simple but effective accounting period concept. It basically is a start and end date that you can use as a bookmark to certain snapshots of financial records. While the rest of Accountomatic is nice and simple, its written in ruby, and while I hear good things about that language, I prefer PHP for now.
CREATE TABLE periods (
id serial NOT NULL,
fromdate timestamp with time zone DEFAULT now() NOT NULL,
todate timestamp with time zone DEFAULT now() NOT NULL
);
I did some more research and found this helpful page:
Computerized Accounting Training > Year End & Month End Bookkeeping Tasks
—–
Oh but I did create a test data generator. It simply creates a recently dated set of transactions in CSV format. Should be very helpful for testing! I got the idea from the ESU Team - thanks!
The initial release will use the base authentication system already released for use with Nexista. I’ve modeled the directory layout off of the one used by the symfony development framework due to its great documentation and explanation, but that’s all I used from symfony.
Data Model
Accounts
- You cannot delete an account if there are transactions in it the account (enforced by InnoDB FK constraint).
- Account deletion cannot be undone.
- Account numbers correspond to the account type
- Accounts are cached to an xml file for faster processing.
Journal and Ledger: Transactions, Entries, and Entry Amounts
- 1 Entry per transaction in the general ledger
- 2 or more entry amounts per journal entry, must balance to zero
(only two are currently supported in the application, but the database can support as many as needed) - Entry Amounts related to a journal entry are all deleted when the journal entry itself is deleted (as well as the related general ledger transaction).
Transactions
Transactions are what go in the ledger, they are single sided and they adjust the running balance for each account. A transaction can be created by importing account transactions, as well as posting the transactions from an existing journal entry. If you import a transaction, it is not yet related to any journal entries. You can create a journal entry from that transaction, and the two will then be related. After that, you will not be able to only delete the transaction, you’d have to delete the journal, which will then also delete the transaction which is related to it. When you create a journal entry from a single transaction, the journal entry form will be pre-populated with the transaction data (even so far as to limit your options based upon the criteria supplied by the transaction).
Posting a journal entry to the general ledger is easy. Each journal entry that has not yet been posted to the ledger will have a “+” sign next to it. Click that, and the entry will post.
To-Do
- Be able to recalculate balances all at once.
- Test balance recalculations
- i18n
Test in Internet Explorer- works- A check to see if related entries and transactions are in sync.
- On journal entry page - need to match credit and debit rows by more than the amount and account id, but what else is there? Need a unique id for the entry amounts table to fully support multiple credits or debits in a single journal entry.
- Reports:
- Cash flow - functional
- Profit and loss - needs work
- Balance sheet - functional
- Test test test test test, you get the idea. Especially test the posting of credit-side transactions to the ledger, it appears that some have an incorrect affect on the account balance. Make a similar balance to make sure the transactions have a balancing act themselves, depending on the normal balance of each account.
Support more than one account per debit or credit in one journal entry. For example: withdrawal from bank account for $967.23 for payroll. Need to credit bank account and debit staff wages AS WELL AS taxes. Really a must have for the initial release.DONE!!! Now need to document the limits of how this works.Fix paginationGood enough for now.- Get balance recalculation working.
Create journal entries from ledger transactions, populating form with transaction data for one side of the equation- DONEAutomatically create transactions in the general ledger whenever a journal entry is made.- CANCELLED
The code is almost ready for release. I reworked the data model a little bit and changed to InnoDB as a storage engine for MySQL (using another DB won’t be difficult because of the simplicity of the model. Most of the generalization is complete: I’ve set the db table references as configurable variables, started to localize with i18n, and have done a lot of testing.
Latest Comments
RSS