SQL-Ledger is designed to be customized relatively easily and rapidly. In general, the source code is well written and compartmentalized. This section covers the basic possibilities involving customization.

SQL-Ledger is an application with over 34000 lines of code. While it is not possible to cover the entire application here, a brief overview of the source code is in order. In the root of the install directory, one will find a setup.pl program, a number of other .pl programs, and a number of directories. The setup.pl program is used to update or install SQL-Ledger. The other .pl programs provide a basic set of services for the framework (including authentication) and then pass the work on to the data entry screen file in the bin directory. The bin directory contains another directory for each terminal type. The main two offered are lynx and mozilla. Lynx would be used for web browsers that do not support frames and is ideal for a text-mode VGA terminal. Mozilla is the terminal type used for most other web browsers. The perl files within these directories provides the user interface of the software. The css directory in the root install directory contains CSS documents to provide various stylesheets one can select for changing various aspects of the look and feel of the application. The locale directory contains translation files that SQL-Ledger uses to translate between different languages. One could add translations to these files if necessary. The SL directory is where the Perl modules reside that provide the core business logic in SQL-Ledger. These modules provide functionality such as form handling, email capabilities, and access to the database through its at least partially object oriented API. Finally, the sql directory provides the database schemas and upgrade scripts.

One can customize the data entry screens to optimize work flow, display additional information, etc. h3. Examples

We set up hot keys for payment lines, automatically focused the keyboard on the last partnumber field, removed separate print and post buttons to ensure that invoices were always printed and posted together, and removed the ability to print to the screen, and even the ability to scan items in when an invoice was received (using a portable data terminal) and import this data into SQL-Ledger. Finally we added the ability to reconcile the till online in a paperless manner. For another customer, we added the ability to print AR invoices in plain text format and added templates (based on the POS sales template) to do this.

One can add functionality to the Perl modules in the SL directory and often add missing functions easily.

Examples

For one customer, we added a module to take data from a portable data terminal collected when inventory items were taken and use that to add shrinkage and loss adjustments. We also extended the parts model to add a check id flag (for alcohol sales) and added this flag to the user interface. For another customer, we added a complex invoice/packing slip tracking system that allowed one to track all the printed documents associated with an order or invoice.

As noted before templates can be modified or extended, though sometimes this involves extending the user interface scripts. Most templates are easy enough to modify.

Examples

For one customer we added text-only invoices for AR and AP transactions/Invoices and an ability to use Javascript in them to automatically print them on load.

The fact that all the data is available within the database manager is a huge advantage of SQL-Ledger over Quickbooks and the like. The rapid development of reports allows for one to easily develop reports of any sort within SQL-Ledger.

Next: Integration Possibilities

(First version from: An Introduction to SQL-Ledger by Chris Travers, 2006)