Standardized Letters (ODT)

The printed forms module is used to print "standardized" or "official" forms based upon the data in the system. For example, it might be the registration number for a nurse. The output will be an Open Office Document. This document can be read readily by Microsoft Word 2003.

This module first appears in version 4.0.5 of the iHRIS Suite.

Source Data

The source data for the printed form will be based on a form relationship.

Page Interaction

Print

At the first phase of this module, the only interaction is to produce the printed forms based on what is stored in magic data. There will be no "document design" component. The standard form will be accessed through a URL with the name of the standardized form and a GET/POST variable containing one or more of the id's for the primary form in the form relationship. For example:

http://<SITE_URL>/PrintedForms/print/registration?ids[]=person|12&ids[]=person|14&ids=[]person|22

Hitting this URL would cause the following to happen:

• verify that a standardized form called registration exists
• verify that the user has the appropriate permission to view this standardized form:
  • Check to see if the user has the task 'printed_forms_all_generate'
  • If not, check to see if the task 'printed_forms_generate_registration' exists and the user has this task
• for each of the ids, person|12, person|14, person|22 fill out the details of the standardized report by using the corresponding row in the report table if it exists (see below).

Menu

One should be able to see which forms can be generated for a given id. Calling

http://<SITE_URL>/PrintedForms/menu?id=person|12

will show all the printed forms whose primary form is person. Then for each of these you will have a link to the corresponding print page.

You should also link to the corresponding archive page and show which PDF forms have already been archived for that person sorted by type and date.

Archive

You should also create a form, say generated_doc which contains the following fields:

• document: A binary field which will contain the PDF it
• date: the date it was generated by
• type: the print standard form (e.g. registration in the above example)

When calling the archive page as:

http://<SITE_URL>/PrintedForms/archive/registration?ids[]=person|12&ids[]=person|14&ids=[]person|22

It will:

• check to see if 'generated_form' is a child form of person. If not execution stops.
• for each of the id's it will created the PDF form (only one on each page/document) and save it as a child generated_doc form

Magic Data Details

All standardized forms will be stored under the magic data node:

/modules/PrintedForms/forms

In the example above the details defining the registration form would stored under:

/modules/PrintedForms/forms/registration

The details for a specific form are as follows (all measurements are in mm):

• relationship: Required scalar node. the name of the form relationship that this form is based off of. It needs to be the name of a child node of /modules/CustomReports/relationships
• displayName: Optional scalar node. The name of the printed letter as displayed to the end user.
• archive: Optional scalar node. If set it should be a named form in the relationship. If it is a valid named form, then it will enable archiving of this printed letter as a child form of the corresponding named form. You should ensure that this form has generated_doc as a valid child form.

Text Subsitutions

Whenever the text {{{XXXXXX}}} is found in the open office document, it will attempt to substitute the text according to the following rules if XXXXXXX' matches the following forms:

• formname+field: a report form fields to substitute into the printf. E.g. "person+surname,person+fisrtname,registation+number":
• +relationshipFunction: The evaluation of the named function in the the form relationship. Example +age65 which be the year the person turns 65 in the staff relationship
• ++date(XYZ): The data formatted according to XYZ (unquoted) via strfrtime functions. Example ++date(%Y) is the four digit year
• ++date: The date. This is the same as ++date(%x).
• ++user: The name of the user printing the form
• ++eval(XYZ): Evaluate the php code XYZ. Example is ++eval(strftime("%Y")+60) would add 60 to the current year

Example

This module is in use in Botswana to generate a data verification form, based on the "botswana_staff" report. The two parts are:

• Registering the template file "verify.odt" with the botswana staff report. Here is the configuration .xml. The important bits are:
  • lines 12-14: register a new path with category "ODT_TEMPLATE" to look for .odt files in
  • line 17: Tells us we are working under the magic data node "/modules/PrintedForms/forms"
  • lines 18-34: registers the "verify" standard letter with the following infomration:
    • lines 19-21: the report relationship we are using is "botswana_staff"
    • lines 22-24: tells us that this standardized form should be generated from an open office, odt, document
    • lines 26-27: tells us that when you archive this form, it should be saved as a child form of the person form
    • lines 28-30: the display name, "Personnel Data Verification", that is shown for when this standard form is added to a page
    • lines 31-33: the name of the template .odt file that is used to generate this standard form. In this case it is "verify.odt." The system will search any paths registered in the categoru "ODT_TEMPLATE" to find this form.
• The open office[template document]