The PBooks Live Demo has been updated! Same domain, slightly different url:
A good way to see the system in action is to watch the Selenium tests run through. You can watch them here:
Archive for May, 2007
In testing PBooks in Internet Explorer, I found this display problem on the journal entry form:
Should be an easy CSS fix. Put it on the to-do list!
The site where we host the PBooks livedemo is undergoing maintenance so I’m going to take this opportunity to update the live demo to the most recent code base. That means that the live demo will be unavailable for a little while during this time. Sorry for the inconvenience, but that’s why we have the static demo!
You can view the PBooks Static Demo at any time. Sorry for the inconvenience and thanks for your interest.
“In the middle of difficulty lies opportunity.” - Albert Einstein
PBooks Installation on Debian
apt-get install apache2 php5 php5-xsl php-pear mysql-server subversion phpmyadmin php5-dev php5-curl php5-gd
One problem I ran into was the old loader setup from nexista. Nexista creates a loader for each app with a conditional testing for the environment, in this context something like development, testing, or production. Since I synchronized the new demo with the existing development environment, it didn’t work. I manually updated the loader files and so far so good.
UPDATE:
The livedemo update is coming along nicely, so it should be back online very soon. I found several bugs and made a bunch of changes in the process.
I’m starting the process of documenting the PBooks code so that when other developers review it, they won’t have to work so hard. 
There are a few comments I’ll post here in advance of releasing the code.
The user-interface of PBooks is generated from XSL. While XSL is an open standard, it still isn’t a cakewalk. It also allows developers to create spaghetti templates which manipulate and process data in a disorganized manner. I have to admit I’m guilty of this, so here’s a little explanation:
General Journal Interface
In this image, we see that there are plus signs (”+”) next to the PLACEHOLDER account. The placeholder account is just that, a placeholder, but lets just ignore that for now. The plus sign is more important. The plus sign will make an ajax (ie the page doesn’t have to reload) call to post the entry amount to the ledger. Here’s the comment explanation in the xsl template:
<!-- These table data contain the account name and amount for each transaction in each entry. If the entry has not yet been posted to the general ledger, and the entry is in balance, then a "+" link will be displayed. Clicking on the + will make an ajax request to post the transaction to the ledger. -->
Based upon this logic, if the general journal is in balance, but the accounting equation or balance sheet is not in balance, then not all transactions have been posted to the ledger. This explains the necessity to automatically post all journal entries to the ledger with the click of a button. For the time being, it must be done manually.
Journal Entry Form
The current journal entry form is a bit of a monster. It does a lot of things though. It supports the ability to have multiple credits or debits, can flip the entry (meaning that all the credit transactions become debits, and vice versa). Because of this, the xsl code is admittedly messy. Here’s the comments I’ve included in the template:
<!-- The following two templates do several things:
* create form for each entry amount
* select the account if it has already been specified
* select the account based upon account type criteria for a transaction-matching, meaning that a single sided transaction has been imported into the general ledger, and needs to be matched to another account, creating a journal entry. Based upon the account in which the transaction was committed and the sign of the amount (either + or -), the new journal entry will automatically select the account in appropriate entry type, either credit or debit.
As it stands, these templates need to be improved.
-->
When I took an accounting course a couple of years ago, I found it somewhat difficult to memorize the seemingly arbitrary correlation between debits and credits and account types, like assets, liabilities, etc. - i.e. their normal balance.
This might happen to other people, and so I think that’s why it makes a lot of sense to use “special forms”, in addition to the basic journal entry system. When I say “special forms”, I mean the check register, deposit slips, invoices, and purchase orders, to name a few. These forms will accomplish the same goal as using the journal entry form, but are clearer in their purpose and will automatically use the right credit and debit settings.
Some will probably say that the use of three tables to store entries, entry amounts, and transactions is unnecessary. I agree to a certain extent, and for archival purposes there is no need for storage. In fact, you really don’t need the general_ledger_table at all, because the information it contains could be dynamically built every time it is requested (in fact that’s how PBooks originally worked back a few years ago).
However, for many reasons, it is worthwhile to have the general_ledger table:
- Faster - the ledger can be thought of as a cache to some degree
- Able to import single-sided transactions into the ledger, and match them with another account for input into the journal
Along these lines, I would like the ability to rebuilt the ledger on demand. PBooks currently has the ability to recalculate the balance for each account and its transactions, but there is no way to automatically post all journal entries to the ledger with a click of a button. Sometime soon though!
P.S. - I just added a column to the general_ledger and entry_amounts tables called entry_amount_id. I had at first believed that there was no need for a transaction to have more than one transaction of the same account for the same journal entry. However, for invoices, which may or may not be split into separate journal entries, may have several discounts for different services or jobs. In that case, it clearly makes sense to have a separate transaction for each one.
Latest Comments
RSS