Report Generator MODULE (RPG)

From FMYiRCWiki

Freemed-YiRC: Report Generator Module Help Page

For more information please see Freemed-YiRC Report Generator article.

Contents 1 Summary 2 DB Tables 3 Menu Structure 4 Table: fy_reportgen_vars 5 DRAFT: Timeline 6 Custom Segments 7 Helpful Variables 8 Module History

Summary

This is the Freemed-YiRC Report Generator module. It was designed to replace the Freemed-YiRC Service Plan module, which was highly specific to one agency. For less technical information, please see the Report Generator article.

DB Tables

Menu Structure

Table: fy_reportgen_vars

This database table contains a list of variables available for use in FMYiRC Report Generator reports. Functionality has been added to provide those with DB/SQL experience, but no PHP programming experience, the ability to ferret out relevant information without programming.

Additionally, those with some PHP experience can also use this to add small snippets of code to return certain information. For example, in a situation where an SQL statement may not be enough, but a custom segment may be much more than necessary. A situation where logic needs to be applied to returned information in order to produce a wanted variable, this is where a PHP code snippet would come in very handy. NOTE: PHP Code can be VERY VERY dangerous! You must exercise EXTREME CAUTION when using custom PHP code here!!!

• Fields:
  • var_name - The name of the variable. Must be short, yet discreet.
  • var_inactive - This indicates if a variable is inactive... i.e., no longer available for use in new template segments. Variables should never be deleted unless initially entered in error! Deleting a variable which is actively used in report templates can result in errors in your reports!
  • var_descr - Description. Should be short, but can be long if necessary.
  • var_type - The type of variable:
    • Custom - This type of variable requires programming to return data. This type of variable requires that the var_custom_code field is filled out.
    • DB - This type of variable uses a database lookup to return a value linked to a resident. This type of variable requires that the var_db_* fields are filled out
    • SQL - This option allows for a custom SQL statement to be used to retrieve a value. The SQL statement can make use of several helpful hard-coded variables. This type of variable requires that the var_sql_* fields are filled out.
  • var_formattype - This is used to indicate any type of special formatting for the return text of the variable. Options include:
    • upper - Indicates text should be returned in ALL UPPER CASE.
    • lower - Indicates text should be returned in all lower case.
    • upperwords - Indicates text should be returned with the first letter of each word in uppercase and the rest in lowercase (So It Looks Like This)
    • date - Indicates text should be returned in the local date format
    • time - Indicates text should be returned in the local time format
    • number2 - Indicates text should be returned in a number format, with commas, and two decimal places (1,234.50).
    • number1 - Indicates text should be returned in a number format, with commas, and one decimal place (1,234.5).
    • number0 - Indicates text should be returned in a number format, with commas, and no decimal places (1,234).
    • money - Indicates text should be returned in a monetary format ($1,234.50)
  • var_db_table - The DB table to retrieve a value from
  • var_db_fid_field - The name of the DB table field which will house the resident's contact ID
  • var_db_get_field - The name of the DB table field we wish to retrieve
  • var_db_sort_fields - OPTIONAL: The name(s) of the DB table field(s) which are used to sort by.
    • If a DB table will return multiple records for a given resident, the field(s) will be used to sort. For example, a date field can be given.
    • Multiple fields should be separated by the pipe character ("|")
  • var_db_where_data - OPTIONAL: One or more sets of DB table fields and values
    • A set of DB expressions to narrow down the number of records returned. Multiple expressions should be separated with pipes.
    • FORMAT: field=value|field=value
  • var_db_getlastrecord - OPTIONAL: If this is set to "X" and more than one record is returned, will get the value of the last record as opposed to the first. This is useful for date ranges where the most recent value is wished.
  • var_sql_text - The text of the SQL statement. Can make use of the variables in the Helpful Variables section of this document.
  • var_sql_get_field - The name of the DB table field we wish to retrieve.
    • May include the DB table name with a period prepended to indicate which table the field belongs to for SQL statements involving multiple tables.
  • var_sql_getlastrecord - OPTIONAL: If this is set to "X" and more than one record is returned, will get the value of the last record as opposed to the first. This is useful for date ranges where the most recent value is wished.
  • var_custom_code - This is an open text field for populating with PHP code. The PHP code should return the variable $ret with the appropriate data.

DRAFT: Timeline

Users can create timelines which include parameters for indicating when documents are due. Timelines are used to help guide users by alerting them to when reports are upcoming and/or due and to provide a structure to follow.

Options:

• Have Initial report?
  • Used to indicate if the first report of a series does not conform to Periodic Basis or if a different report template is used.
  • Report Template
    • Include CHOICE (value 0) if the template type should be a choice

• Have Periodic report?
  • Report Template
    • Include CHOICE (value 0) if the template type should be a choice
  • Periodic Basis, i.e., how often are documents due (especially used for document target dates and e-mail alerts)
    • Static - Day X of Months Y,Z - Can choose individual months, as well as day (with option to grab day from DOE)
      • i.e., Monthly: Jan X, Feb X, Mar X, etc...
      • i.e., Quarterly: Jan X, Apr X, etc...
    • Dynamic - Seed Date + X Days/Months
      • i.e., Seed Date can be DOE, then DOE + 30 Days + 30 Days
    • Dynamic - Last report + X Days/Months
    • N/A (No periodic structure - reports can be generated at-will as often as wished)
  • Create Calendar Events via the User Calendar and Group Calendar modules (only if Periodic Basis is not N/A)
    • Specify:
    • Create Calendar E-Mail Alerts via the User Calendar and Group Calendar modules (only if Periodic Basis is not N/A)
      • Specify:
        • Alert Alarm_interval (i.e., X days before event target date)
  • Strict? i.e., must follow Periodic Basis, cannot have additional reports created in-between the structured Periodic Basis target dates
• Have Final report?
  • Report Template
  • Used to indicate if the last report of a series uses a different report template (i.e., a Discharge Summary type document when a resident is discharged).
    • Include CHOICE (value 0) if the template type should be a choice

Custom Segments

• Custom report segment PHP code stored in an SQL table, versus the old Service Plans module which used a .inc PHP script which would likely have to be custom modified for each agency. Keeping the code in an SQL table would allow for easier export/import between agencies wishing to share custom report segments.

Helpful Variables

• The following are variables, but not FMYiRC Report Generator Variables. These are internal FMYiRC variables which are available to custom segments and Report Variables themselves for use in returning data.
  • $fy_res - The Contact ID (fy_con.id) of the resident the report is being generated for.
  • $fy_curdbdate - The current date, in the appropriate DB format
  • $fy_curdate - The current date, in locale format.
  • $fy_curdbtime - The current time, in the appropriate DB format
  • $fy_curtime - The current time, in locale format.

Module History

• Created: 08/2008 By: Joe Thielen