SQL-Ledger can be extended with external custom_{module}.pl scripts and with external private {login}_{module}.pl scripts.
Global scripts apply to every login, whereas {login}_{module}.pl scripts apply to one login only. For instance, if the login is 'joe' you can add a script 'joe_ar.pl' in the bin/{terminal} directory to provide a customized version for joe. So, whenever joe logs in he sees his customized version while the other users work with the standard version.
External code is pulled into the core only if it compiles. If it fails to compile you are informed about the error. The program will continue to run and your custimized scripts are simply ignored.
Code example to customize the footer for the AR module
add a file custom_ar.pl in bin/mozilla.
likewise if you want to have one for lynx, add
the file in bin/lynx.
# customized AR
# customized form footer without the "Delete" button
# check for ID, if present, you cannot post
1;
# end of main
sub form_footer {
$form->hide_form(qw(path login sessionid callback));
print qq|
</table>
<br>
<input class=submit type=submit name=action value="|
.$locale->text('Update Form').qq|">|;
# only show the post button if this is a new transaction
# $form->{id} is only set for existing transactions
if (!$form->{id}) {
print qq|<input class=submit type=submit name=action value="|
.$locale->text('Post Transaction').qq|">|;
}
print qq|</form>
</body>
</html>
|;
}
# end of file
Every subroutine can be replaced in the system by loading a subroutine with the same name.
IMPORTANT! If you use a foreign language follow the programming style and use $locale->text('string') instead of hardcoding strings. When you are done with your code run ./locales.pl from the appropriate locale/{countrycode} directory. This will parse your code and build the translation strings and cross-references for subroutine calls. If you do not run locales.pl you'll probably end up with error messages informing you to make an entry for the missing subroutine in the translation file in the self{subs} section.
Menus can also be customized globally or per login. To add a global customized menu add the file 'custom_menu.ini' in the root directory.
To customize menus per login add a '{login}_menu.ini' file in the root directory.
This is also a good way of building dynamic content from some other source or from within.
Menu entries are organized into section entries.
Here is an example of a menu file. It is called demo_menu.ini Whenever the user demo logs in, this menu is loaded in addition to the main menu.
[ ] module=NULL [Miscellaneous] [Miscellaneous--FAQ] module=NULL href=doc/faq.html [Miscellaneous--Lookup Exchange Rate] module=NULL href=http://www.xe.com target=_blank
In addition to custom scripts you can also add new modules by simply copying am.pl in the root directory to a new file and creating a library file with the same name in the bin/{terminal} directory. The general programming scheme is module.pl in the appropriate terminal directory (i.e bin/mozilla) for the frontend code and MODULE.pm in the SL directory.
Example setup for a timetool module. cp am.pl tt.pl create tt.pl in bin/mozilla and add your frontend code create TT.pm in SL and add the backend code
Every user can have a different stylesheet. You can set the stylesheet in your "Preferences" screen.
SQL-Ledger can also be accessed from the command line by passing all the variables to the perl script. The variable=value pairs must be separated by an ampersand.
i.e to display the search screen from the ct module. (this is the module for processing data for customers and vendors)
cd /usr/local/sql-ledger ./ct.pl "login=name&path;=bin/mozilla&password;=the_password&action;=search&db;=customer"
This displays the search screen for customers on screen.
You can send the output to another application, convert to some other format or send it to a printer. To do anything useful with this you have to capture the output and process with another program. There is no console interaction with the program and the script will not ask you for search criterias as it would when you run it in a browser.
Scheduled transactions, like sending out monthly invoices, can be done with a cronjob the same way. Or to import data send to the save (post) subroutines.
i.e to import a customer
./ct.pl "login=the_login&path;=bin/mozilla&password;=the_password
&action;=save_customer&name;=this is a new name&contact;=my contact&db;=customer"
The variables between the double quotes must be in one line!
Names of variables are identical to the field names in the tables.
Do not pass the ID, it is generated by the SQL server. DO NOT import this ID unless you know what you are doing.
Some subroutine calls require a distinct variable to be passed, like db=
subroutines are generally called
add edit save delete form_header form_footer update_form ...........
PLEASE NOTE: The examples given above are for demonstration purposes only to show the general syntax how to use the API.
SQL-Ledger can easily be adapted for batching transactions to and from stand-alone POS terminals or off-line systems. The backend office can be synchronized on an as need basies. The stand-alone application can simply write the transactions to a file which are then uploaded to the backend office. Inventory can be exported to a format readable by the POS software so that each terminal has current pricing information. Because there are no restrictions in which order transactions must be posted you can synchronize a backoffice from many terminals at any time.
This procedure is typically used in Franchise operations or remote operations where it is not feasable to have a direct link to the backoffice software.
The same concept as for the console interface can be used with some additional subroutines to generate an inventory listing with raw data instead of the html formatted lists.