Customized scripts
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.
Customized menus
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
New scripts
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
Stylesheets
SQL-Ledger comes with several stylesheet, a theme of sorts.
The stylesheets are in the css directory.
If you make changes to the stylesheets, copy the file to another file so
your changes are preserved during an upgrade.
Every time you upgrade, the default versions will be
overwritten and you will loose your changes!
Every user can have a different stylesheet. You can set the stylesheet
in your "Preferences" screen.
Console interface
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.
Batching transactions
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.
