SQL-Ledger - Application Interface

SQL-Ledger Accounting

Application Interface

  1. 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
     # end of main
     sub form_footer {
       $form->hide_form(qw(path login sessionid callback));
       print qq|
       <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>
     # 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.

  2. 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.

     [ ]
     [Miscellaneous--Lookup Exchange Rate]

  3. 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

  4. 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.

  5. 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


    PLEASE NOTE: The examples given above are for demonstration purposes only to show the general syntax how to use the API.

  6. 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.