Yep, its been awhile.
I’ve since become a full-time Rails developer and as it turns out, one of the applications I’m working on has a comprehensive accounting package included in it.
So now my plans are to work on a Rails-powered bookkeeping system! There are some interesting, existing projects, too. The one I liked the best is aptly named “Bookkeeper” (though I think the name is too generic). I forked it awhile back, and since then the project has evolved a little, but not much. I do like it, but it is BSD licensed, and I prefer the Affero GPL for web-based applications.
I plan to make it a standard Rails 3.1 application, using stock components, using Regdel as the headquarters. I started work on Regdel to learn Sinatra and DataMapper, but since then, I’ve grown to prefer Rails and ActiveRecord.
]]>First off, some bad news - I converted the PBooks wiki from MediaWiki to Ikiwiki, and something went haywire. I've cleaned up a bunch, but there is still a bunch to do. Thanks for your patience.
The good news is that I've moved both the PBooks source code and the Nexista source code to Github - that should make access much easier as well as (hopefully) collaboration.
]]>Its actually a really sweet software application and I'm totally fired up about Git. I'm actually planning to switch the PBooks code base from Subversion to Git, too.
Thoughts, concerns, questions?
]]>The balances of all the accounts are separated based upon whether the account is a debit or a credit. A tally is then made at the bottom of the list which shows the totals for all credit accounts and all debit accounts.
While this is a pretty simple feature, it comes in quite handy!
]]>SD is a distributed issue tracker, but that's not why I'm planning to switch (though it may help out in the future). It uses Git and Prophet, a peer-to-peer database.
SD is a new open source project, and I really like the direction its going and want to help out by using it and sharing my notes.
Also, SD has the ability to render static HTML reports of the issues it is tracking. I've increasingly come to rely upon static files as a simple and reliable way to publish information to the web. Truth be told, that's my major motivation for the switch.
It won't happen overnight. Although I've experimented with SD, I still have a lot to learn on how best to use it.
]]>Here's some more thoughts on the matter:
I'm quite confident that given the time, I'll be able to implement all this into PBooks.
]]>My hesitation for implementing this feature involved cases where there were unmatched transactions, and entries which had not yet been posted.
True, when all transactions are matched, and all entries have been posted, theoretically, the journal and the general ledger should be in sync. I'd like to be able to rebuild the ledger, just to make sure!
This makes an important point - in PBooks, the ledger is the "canonical" record, meaning that everything else is based upon its entries.
]]>All these business objects are, at their core, journal entries with additional metadata, check numbers and invoice numbers, for example.
After about two years in development, structuring business objects has worked out very well. There are still a few minor outstanding issues with them, but other than that, they are good to go.
I bring business objects up for discussion because I did some work on deposits and invoices tonight. First I found a bug where the entryid key used to select a deposit was also used as a key to select an invoice - if there is no key, all invoices are selected. This was due to the fact that the keys used to be business object specific - invoiceentryid, depositentry_id, and so on. The keys were consolidated awhile back, and there may be additional bugs hiding due to that change, but this one is definitely squashed!
With invoices, I was able to clean out an old SQL file which was used prior to the setup of business objects in this way. This type of "cleaning house" always feels good! I've still got some cleaning to do!
]]>My business operates on a standard calendar, annual fiscal period basis. Some business operate differently, so the flexibility is there. Most of the time, PBooks will be used in the current operating period, but it would be nice to be able to go back to previous fiscal periods and review the books.
I had previously viewed this operating such that the user could only choose one fiscal period at a time. I started to implement this, but held off for some reason, and I think I now know why.
I think it was because I felt that it could be frustrating to only be able to view one period at a time. Furthermore, I wasn't clear on the best way to implement functional restrictions. For instance, if the user selects a previous fiscal period and then decides to create an entry into their current fiscal period, how should the system alert them to this discrepancy? How should access be controlled on this basis?
So there are some unanswered questions on this topic. I'm now going to take a moment and do a little research on foreign key constraints bound by dates.
Ah, I'm remembering a little bit more on the subject - I had two fiscal periods in mind, the current fiscal period, and the selected fiscal period. I like that because for now while PBooks remains in development, it will be reasonably possible to override whether the selected period is closed or not, but otherwise it will be possible to limit changes only to the current period, and automatically place new entries into the current period.
]]>He informed me that it might have just been the version of Quickbooks I was using, as he said there are several different versions, and he's using a version that has some terrific reporting capabilities.
I've quite interested to see the reports he's referring to, but unfortunately I'm so busy over the next few weeks I won't get to meet with him until December. Until then, I'm going to review the basic reports available in PBooks:
The logging functionality is based upon the Nexista log action as well as PEAR's Log class and is currently limited to logging to a file.
I plan to add support for logging to the PBooks database as well.
]]>However, the time I have available to work on it is still limited, and is likely to remain so for the foreseeable future.
I don't have any specific goals set for the immediate future, but the software is getting more and more usable as I use it for my own business and refine it along the way.
]]>Checks are a little challenging as I get concerned that if I create the check in PBooks and then the transaction it represents gets imported again from the statement, then there would be duplicate entries. Yes, I realize this is what bank reconciliation is all about! PBooks needs a process to identify and match checks with entries.
Eventually I'd like to use PBooks to print checks, but from a procedural standpoint, my business just isn't there yet.
Right now, I'm just focused on keeping track of my checks and check numbers in a manageable way.
]]>I'm still using it for my business, and as things have settled down a little, I'm planning to call the current code base stable. It may not be bug-free, but at least its not rapidly changing.
When I take my next crack at moving PBooks forward, it will be nice to have a stable version to steer new users to.
A primary goal for PBooks is still easy installation. While I will still use XML and XSL for my own production purposes and development, I may render (one of the nice things about XML!) a script-only version for easier installation. Thoughts?
]]>