Friday, October 3, 2008

core design and user interface

i think we have enough data to create our first module. it will be a simple one that manages the content of the nominal records table. however, remember that it links to 2 other tables via the hierarchy so we now have to allow for them.

More importantly, though, we need to design the css and html that will be used throughout all future modules. Also included in that is the AJAX library and supporting php server files that interact with it.

The difference between calling a function in php and calling it in AJAX is that php can preload the files and then later call the function/class, whereas AJAX calls the function/class by requesting the url. so AJAX requires 2 files where php only requires 1 but this prevents duplication of any code.

reserved nominal accounts

as mentioned earlier, some nominal accounts need to be protected from manual user input, such as the sales and purchase ledgers and the VAT control accounts. Also, any accounts that will be used as bank accounts can be flagged to be reconciled against an actual bank statement. both of these tasks can be achieved by means of the same feature.

it would be tempting to add a column in the core_nom_accounts table to indicate whether the account was restricted or not (or is a bank account). But, that goes against my normalization rules because you only need to reference reserved records, not all of them.

So i am going to create a new table that contains 2 fields, 1 to reference the unique id of the nominal account and 1 to indicate its function.

CREATE TABLE core_nom_reserved(id SMALLINT UNSIGNED, reserveType VARCHAR(2), PRIMARY KEY(id, reserveType))

Now really i should make reserveType a foreign key to another table but i cant be bothered. its a very simple reference that doesn't need much explanation. I will use codes like SL for Sales Ledger, PL for Purchase Ledger, VS for VAT Sales, VP for VAT Purchases, VC for VAT Control and BA for Bank Account (can be more than one).