Standardized Letters (ODT): Difference between revisions

From IHRIS Wiki
(Created page with '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…')
 
No edit summary
Line 1: Line 1:
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.
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.
This module first appears in version 4.0.14 of the iHRIS Suite.
==Source Data==
==Source Data==
The source data for the printed form will be  based on a [[Custom Reporting -- Creating Form Relationships|form relationship]].
The source data for the printed form will be  based on a [[Custom Reporting -- Creating Form Relationships|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 Details|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==
==Magic Data Details==
All standardized forms will be stored under the magic data node:
All standardized forms will be stored under the magic data node:
  /modules/PrintedForms/forms
  /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''
*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.
*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 [[Defining Forms | child form]].
*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 [[Defining Forms | child form]].
*
*template: Required scalar node.  The name of a .odt file that will be used as a template to generate this report.  It should be located in a directory/path registered in the category ODT_TEMPLATE
*render: Required scalar node.  Needs to be set to ODT


===Text Subsitutions===
===Text Subsitutions===

Revision as of 19:38, 23 May 2011

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.14 of the iHRIS Suite.

Source Data

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

Magic Data Details

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

/modules/PrintedForms/forms
  • 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.
  • template: Required scalar node. The name of a .odt file that will be used as a template to generate this report. It should be located in a directory/path registered in the category ODT_TEMPLATE
  • render: Required scalar node. Needs to be set to ODT

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]
Retrieved from "https://wiki.ihris.org/mediawiki/index.php?title=Standardized_Letters_(ODT)&oldid=38295"