Open Source Bookkeeping and Accounting Software in PHP - Demo - Wiki - Download - Forum - Development
I just updated the PBooks LiveDemo with the latest code from SVN. The interface is much improved thanks to some inspiration from m0n0wall. Hope you like what you see! You can access the livedemo here:
The username and password should be filled in, but if not, use “demo”, “demo”.
With a little bit of coding there have been some major improvements to the bookkeeping process, i.e. the process of taking transactions and assigning them to specific accounts. The process has been improved so much that it is almost entirely automatic! When a series of transactions are imported into PBooks, they are assigned an account, but that’s only one half of the accounting equation.
When that transaction is matched up with another, the memo is used to “guess” which other account it should be joined with. This hasn’t been tested thoroughly, and it has only been setup to work with simple, non-split journal entries. However, the amount of time saved by this addition is so significant that I’ll be spending more time to polish it up.
I’ll elaborate more on the additional improvements as well as post the SVN commit log later, right now I’m off to the mall for some shopping.
Getting there, slowly but surely. There’s really nothing like the real world to test a software application! 
Its been a while since I used PBooks on a day-to-day basis, and its great to start up with it again. I’ve learned a lot since my last foray into managing my books on my own, and I can see where PBooks needs some help.
I ran into a few small bugs today, and resolving them and the data corruption they caused wasn’t as bad as it could have been. The problem was rooted in the use case where transaction data is imported from CSV text (which reminds me there is still a small bug that causes a problem if the CSV text has a comma in the transaction memo!). Once transaction data is imported, it must be matched to another account to balance out the accounting equation. This process is made easier by the journal entry form getting pre-populated with data from the transaction. If its a simple transaction involving only two accounts, all the user has to do is select the other account and click submit. If there is more than two accounts involved, that’s still pretty easy, but the user will have to click a few more times. Anyway the problem was that the original transaction had to be deleted when the journal entry was made, and then reposted back to the account ledger. That was not only inefficient, but it also caused the transactions to get out of order with respect to the original bank statement, while not causing real issues, just making it very difficult to trace running balances.
The fix was to retain the original transaction, and simply link it up with the new journal entry that was created from it. If this doesn’t make sense, check out the pbooks data model for reference.
This experience with live data has reinforced my confidence in the core model, and working it as thoroughly as possible before opening up the source code and letting others monkey around with it. Maybe this is a stretch to the “what color should we paint the bike shed?” question that plagues open source project from time to time, but I hope to have the core bookkeeping model and supporting functions working so well that when people twist and turn and fold and manipulate it beyond belief - it still works really well.
So even though I’m the guinea pig here using PBooks to manage our books, I’m still planning to build some serious test cases to cover as many bases as I can dream up. This will ensure in an efficient manner that the working functionality is preserved as new features and changes are made to the code base. In the meantime, take a moment to check out some of the basic tests I’ve put together on the PBooks live demo. (I know one of the tests fails!)
I just posted this “letter” to the OSI in response to a blog entry about the Affero GPL on their website:
Hi Michael,
I’m working on an open source accounting and bookkeeping software project called “PBooks”, and plan to release the software under the AGPLv3.
I’ve been holding off publishing the code until the AGPL v3 is final and published, because I’m not sure if I release it now under the AGPL version 1, whether or not I can change the license later on. I’m under the impression that if licensed under the AGPL v1, it will always be licensed that way, but future versions (of the new code anyway) could be licensed differently. On the other hand, would the new code be considered a modification and thus be required to be available under the AGPLv1? This legal stuff makes my head spin.
The licensing delay has given me the time to compare what I’ve created with the many other open source accounting software projects that either stalled in development, or ended up with some wacky functionality or licensing scheme that didn’t fit my needs. At the same time, I’m working to simplify and streamline everything having to do with PBooks, so that others who find it will be able to easily modify it to fit their vision.
I foresee the following scenarios:
* Small-to-large businesses that are tech savvy can take the code, modify it, integrate it into their operations, not make the service publicly available (or distribute it), and thus not have to worry about their changes.
* Hosting companies that offer small business services like email, blogs, and web services in general could use the code but would be required to publish their modifications to PBooks under the same open source license.
* Financial companies, like banks, that offer online banking and related services could offer the software as a service to their customers. I would also like to require these businesses to publish their modifications under the same open source license. Alternatively, they could purchase a commercial license for a fee, and not be required to publish their modifications. Many of these potential customers would also involve value-added “resellers”, who I would like to require to publish their modifications, or pay for commercial licenses.
It is ironic that in all likelihood, it will be the first category that ends up contributing the most to the project. After that, it would most likely be the hosting companies who would then “spread the word” about such a project, and it is questionable whether banks would consider using a product with any open source limitations at all. I imagine that banking customers would prefer the fee-based alternative for a license with a more commercial and private focus. It is because of the potential for a dual-license that I’ll either require contributors to assign their copyrights to my company, or not accept contributions at all. That is not to say that the modifications would not be required to be published under the open source license, it just means that my company wouldn’t be selling licenses to them!
Furthermore, I’m planning the integration of plug-ins, which could work with PBooks and to a limited degree modify its behavior. Those plug-ins would of course have no licensing restrictions at all.
I believe that the AGPLv3 is the right license for PBooks, and eagerly await the finalized version. Feel free to contact me about the project and the our use of the license at any time in the future. I’ve been working on it for almost three years, and will continue to do so in the foreseeable future.
From,
Albert
http://www.pbooks.org/
UPDATE: Nice, they approved my comment.
There’s been a bunch of chatter on the gnucash mailing list about a SQL backend lately. Its been dabbled with many a time in the past, but never fully implemented. Someone pointed out that there are some column definitions coded in the source. That was cool to find. I responded to that with a comment about the XBRL specs and how I’ve been trying to implement them into the PBooks data model.
Wouldn’t it be cool if you could have a desktop application like GnuCash access the same database as a web-based bookkeeping system like PBooks? I think so!
UPDATE: Derek on the mailing list clarified that the code referenced above was used with GDA (Gnome Data Access), and the current GnuCash application uses the QOF (and ^).
UPDATE Feb 7, 2008: I took another crack at this with mixed results:
pbooks.org/blog/gnucash-with-mysql-sqlite
I just ran a bunch of tests on the PBooks demo using Selenium. While testing using the IDE everything seemed to check out without any errors or missteps. While using the Selenium core, one out of the two tests the program ran failed. The error occurs while attemting the click and wait command on the Test Account link. It says Element link=Test Account not found.
Error::init in /usr/share/php/nexista/kernel/datasources/metabasesqldatasource.php in line 446
Latest Comments
RSS