System.xml Explained

March 20, 2006

Copyright 2006, R. James Holton

This document describes the system.xml file.  The system .xml file is the primary configuration for the ESS system.  It contains both site specific and database specific information. The system.xml element is broken-down into subelements, which for purposes of this document, are lettered A through Z.

A. configuration

This element contains basic configuration information for the ESS Report, Audit and Disconnect systems. Unlike the other elements in the system.xml file, this element is cached. Any changes require that the server be restarted prior to the changes taking effect.

  1. company - company name (e.g., Adisoft)
  2. exp_email_address - return address for email messages (e.g.,expense@site.com)
  3. smtp_address - address of SMTP server for sending e-mail messages (e.g., mail.site.com)
  4. smtp_domain - domain name for user's emails. This is only used to construct email address's if required (e.g., adisoft-inc.com)
  5. smtp_delimiter - character used to delimit first and last name in constructed e-mail address. . This is only used to construct email address's if required (e.g., '.')
  6. xml_folder - Full path of the folder that holds the register files. The register files are comprised of the XML version of the expense reports. (e.g., E:\ess_test\xmlr\/xml_folder, or, /var/ess/xmlr/)
  7. pal_email_address - set to the same value as exp_email_address unless there is a specific reason not to do so.  This address is used specifically for receiving forms in the SubmitForm.jsp
  8. personal_folder - Full path for the folder that holds personnel information. (e.g. E:\ess_test\xmlu\)
  9. rep_reference - This element tells the XML2ESS class how to summarize department totals. Within department options are: 1. Project/Client, by unique project and client, 2. Entity/Client, by unique entity (stepno) and client, 3. Clientno, by unique client.
  10. xmlstatus - fullpath for Status.xml. Status.xml holds information on routing and processing of reports. (e.g., E:\ess_test\xmls\Status.xml)
  11. xmlsecurity - fullpath for security.xml. Security.xml specifies who can perform the audit, profile generation and password reset funcitons. (e.g., E:\ess_test\xmls\security.xml)
  12. receipt_req_amt_fld - this is the field to use in the EXPENSE table for the amount at which a receipt is required. Normally it will be LIMIT or XLIMIT. Use XLIMIT for MySQL databases and LIMIT for others where LIMIT is not a reserved word.
  13. xmlrules - Full path of the rules.xml file. The rules.xml file describes the rules used for the initial processing of reports that have been submitted. (e.g., /var/ess/rules.xml)
  14. pwd_expires_days - number of days before a user is required to change there password. A '0' indicates that the user is never forced to change their password. (e.g., a 28 requires a user to change their password every four weeks)
  15. pwd_minimum_length - specifies the minimum length of a password.
  16. pwd_approval - a 'Yes' indicates that approvers need to enter their password when approving reports. 'No' indicates that they don't. 'Yes' is akin to requiring a signature on a report and is more secure in the event of an unattended browser.
  17. pwd_audit - a 'Yes' indicates that auditors need to enter their password when OKing reports for payment. 'No' indicates that they don't. 'Yes' is akin to requiring a signature on a report and is more secure in the event of an unattended browser.
  18. personal_code - Enter the expense type that indicates a personal item that should not be reimbured. This item will eventually be depricated and replaced with process.personal below. (e.g., PERSONAL)
  19. xmlremove - Full path of Remove.xml which describes what happens to a report that a user selects for removal. (e.g., E:\ess_test\xmls\Remove.xml/xmlremove)
  20. xmlreports - Full path of reports.xml. Reports.xml holds report descriptions for the simple report generator. (e.g., /var/ess/reports.xml)
  21. project_report_name - The name for the title of the project field that displays in the trip section of the detailed report. (e.g., 'Project/Acct')
  22. manager_report_name - The name for the title of the reporters physical location on the report header. This is usually either the name of their manager or the name of there department. (e.g., 'Dept Name')
  23. show_company_name - A 'No' indicates that the company name with not be displayed as part of the expense line items in the Trip section of the report. Any other value indicates the title on the company column. (e.g., 'Entity Charged')
  24. add_merchant_comment - a 'Yes' indicates that the merchant name will be added to the comment detail of an expense line item in the Trip section. 'No' indicates that it will not.
  25. dump_mail - In the ESSApprover class, reporters who do not have a manager assigned will have there messags sent to this e-mail address.
  26. update_exp_approval - Set to 'Yes.' Will be deprecated.
  27. home_page - This is the URL that you wish the user to be transferred to after they logout. ( e.g., 'http://www.adisoft-inc.com')
  28. background_color - the color used as the background for trip boxes, offset lines, etc. This color should match the colors used in the expense.css style sheet. (e.g., '#EAEAEA')
  29. xmlnacha - Full path for the NACHA file description. (e.g. 'E:\ess\xmls\nacha.xml/xmlnacha')
  30. xmlcalendar - Full path for the calendar file. The calendar file describes bank holidays and other important dates. (e.g., 'E:\ess_test\xmls\calendar.xml/xmlcalendar')
  31. xmlimport - Full path for the import file. The import file describes the various layouts or files that ESS uses to transfer information from and to other systems. (e.g., '/var/ess/import.xml')
  32. xmlexpoty – Reserved.
  33. xmledit - Full path of the edit file. The edit file describes the interaction between the various file maintenance screens in the Audit module and the database. (e.g., '/var/ess/xmls/edit.xml')
  34. xmlschema - Full path of the schema file. The schema file E:\ess_test\xmls\schema.xml/xmlschema
  35. xmlsecurityE:\ess_test\xmls\security.xml/xmlsecurity
  36. xmlprepopulatedmap - XML file used to map the pre-populated information to a valid expense type. (e.g., /var/ess/xmls/prepopulated.xml)
  37. reportfolder - reserved for future.
  38. htmloutput - reserved for future.
  39. essprofile - Full path for the ESSProfile.js. This is the physical location of the web ess folder. (e.g., e:\Inetpub\wwwroot\ess\ESSProfile.js)
  40. referenceprefix - Prefix to the central reference number of a report. The central reference number is generated as an eight-digit number. If specified, this prefix replaces the first digit. (e.g., 'X')
  41. alternateprefix - Prefix to the alternate reference number of a report. The alternate reference is generated from the user's reference number and is a packed eight-digit number. If specified, this prefix replaces the first digit. (e.g., 'A')
  42. alternatelength - Specified length of the alternate number. Currently leave as '8.'
  43. step_display - The purpose table contains a stepno column. The column is used to further classify expenses that are tied to this expense in an manner that they client wishes. This is the title of the associated field. (e.g., 'Aircraft' may be appropriate is you want to know the type of aircraft being used for travel)
  44. prepopulateditems - Set to 'Yes' if you import credit card items, etc. to pre-populated report entry or else 'No' if you do not.
  45. pwd_audit – A ‘Yes’ means that auditors need to enter their password (as their signature) when they approve reports for payment.  A ‘No’ means the auditor just has to click the button.
  46. currency – Default currency in the event that one is not specified in the company record in the the company table.
  47. transactionlimit – Limit of a single transaction if one is not specified in the currency table for this currency.
  48. distance – Default mileage units for the site. (Note: translated by property file)
  49. billable_name – Label for the billable field. (Note: translated by property file)
  50. omitforeignguidelines – A ‘Yes’ will omit the guideline check from the audit copy for reports that are in a foreign currency.
  51. omitguidelines – A ‘Yes’ will omit the guideline check from the audit copy.
  52. purposescreen – {deprecated}
  53. historycopy – Status a copy of a report is given after it is converted from a foreign currency.
  54. normalizetest – A ‘Yes’ will convert names, titles, etc. to uppercase before saving them.
  55. omitforeignconversion – A ‘Yes’ will not allow auditors to convert reports in foreign currency to local currency.
  56. dateformat – default date format to use if none is specified in the user profile.  Options are MM/dd/yyyy, dd/MM/yyyy, and yyyy-MM-dd.
  57. numberformat – Controls the default numeric display to be used if there is not a value set in the user’s profile. It can be set to decimal, period, or comma.  Decimal and period are effectively the same.
  58. language – Default language to use.  Current languages supports are ‘en’ for English and ‘fr’ for French.
  59. country – Default country code to use.  Currently not used.
  60. location – Default location to use for location field.
  61. importwork – physical location of the user import file.
  62. requireauditcomment – If set to ‘Yes’ the audit is required to provide a comment/email to user regarding any report that is rejected.
  63. appserver - Enter the URL with ending slash of your application server. If you use a conduit, the application server with be the same as your Web server. (e.g., http://www.yourserver.com:8080).  As of version 7, this element should be left blank unless there is an overwhelming reason to use it.
  64. webserver - Enter the URL with an ending slash of the Web server. (e.g., http://www.yourserver.com').  As of version 7, this element should be left blank unless there is an overwhelming reason to use it.
  65. appfolder - This is the name of the application as it appears in webapps. Normally should be 'ess-app,' but can be customized.
  66. webfolder - This is the name of the Web folder the application resides in. Normally should be 'ess,' but can be customized.
  67. customfolder - Normally should be 'ess' unless you have done customized purpose screens, menu's etc that you wish to maintain separately for upgrade purposes.
  68. localserver - Address of the server port used by the disconnected application. Normally should be 'http://localhost:8085/localserver.'
  69. localsecuritystring - This string is used to test is the request to the disconnected server is coming from the local machine. Leave as '/127.0.0.1' unless you have a reason to change it.
  70. centraldatabase - This is the name of the JDBC driver. (e.g., jdbc:odbc:adisoft)

The following items are found in the system.xml file, but are not used in the online version.  They can be removed if you don’t want to look at them.

  1. localserverport - The port number that the disconnected server is using. Leave as '8085' unless there is a conflict. This needs to be coordinated with the localserver element.
  2. localfolder - Normally should be './' unless there is a special problem.
  3. localserverfile - This is the html screen that is used for the initial disconnected login. (e.g., './x1x.html')
  4. remotedomain - This is the application domain that this disconnected version uses for uploading, etc. (e.g., 'http://www.adisoft-inc.com:8080/ess-app/')
  5. remoteprofileupdate - Full path name of the profile update JSP. The profile update JSP updates disconnected users with the latest tables for editing as well was sending them their pre-populated items. (e.g., http://www.adisoft-inc.com:8080/ess-app/ProfileFeed.jsp)
  6. remoteusersetup - This is the name of the screen that is used to accept logins for the initial setup and update processes. (e.g., 'http://www.adisoft-inc.com/ess/ess/LoginLocalSetup.html')
  7. xmluser - Name of the XML file that stores information about the user in the disconnected system Leave as 'user.xml' unless debugging.
  8. lessprofile - path name of the ESSProfile location in the disconnected system. Leave as '.\ess\ess\ESSProfile.js.' unless instructed by technical support.
  9. remotesave - http://192.168.0.2:8101/ess-app/SubmitLocal.jsp/remotesave
  10. testjsp - Disconnected system process. Leave as 'Less.HelloWorldServlet.'
  11. intro - Disconnected system process. Leave as 'Less.IntroServlet.'
  12. submitform - Disconnected system process. Leave as 'Less.HelloWorldServlet.'
  13. submitformn - Disconnected system process. Leave as 'Less.HelloWorldServlet.'
  14. savexml - Disconnected system process. Leave as 'Less.SaveXMLServlet.'
  15. getreport - Disconnected system process. Leave as 'Less.GetReportServlet.'
  16. localmessage - Disconnected system process. Leave as 'Less.LocalMessageServlet.'
  17. lessscreen - Disconnected system process. Leave as 'Less.LessScreenServlet.'
  18. saveprofile - Disconnected system process. Leave as 'Less.SaveProfileServlet.'
  19. savepersxml - Disconnected system process. Leave as 'Less.SavePersXMLServlet.'
  20. prepopfeed - Disconnected system process. Leave as 'Less.PrepopFeedServlet.'
  21. prepopsave - Disconnected system process. Leave as 'Less.PrepopSaveServlet.'
  22. printreport - Disconnected system process. Leave as 'Less.PrintReportServlet.'
  23. loginprofile - Disconnected system process. Leave as 'Less.LoginProfileServlet.'
  24. logout - Disconnected system process. Leave as 'Less.LogoutServlet.'
  25. recoverlog - Disconnected system process. Leave as 'Less.RecoverLogServlet.'
  26. guidelines - Disconnected system process. Leave as 'Less.GuidelineServlet.'
  27. removesave - Disconnected system process. Leave as 'Less.SaveRemoveServlet.'
  28. submitxmlwguide - Disconnected system process. Leave as 'Less.SubmitWithGuideServlet.'
  29. submitlocal - Disconnected system process. Leave as 'Less.SaveXMLServlet.'

B. process

This element is used by various processes, such as the generic G/L and payment feeds, to avoid having to hard code information. Other sub-elements flow into the JavaScript profiles.

  1. defaultpayment - Used to designate the default payment method. (e.g., CASH)
  2. defaultlodging – Not currently used.
  3. lodging - Expense type to be used for hotel receipt screens. (e.g., LODGING)
  4. fleetallowance - Expense type used for fleet vehicle maintenance allowances. (e.g., ALLOWANCE)
  5. advance - Receipt type used to account for cash advances. There can be multiple elements. If there are multiple elements, the first occurring element is the default. (e.g., ADVANCE)
  6. personal - Expense type used to account for personal usage items that get removed from the reimbursement calculation. There can be multiple elements. If there are multiple elements, the first occurring element is the default. (e.g., PERSONAL)
  7. returned - Receipt type used to account for cash returned against advances. There can be multiple elements. If there are multiple elements, the first occurring element is the default. (e.g., CASH-RETD)
  8. mileage - Items to translate to mileage receipts when imported to your legacy system.   There can be multiple elements.  Also, any expense items where the units are 'miles' will also be imported as mileage receipts.
  9. defaultmileage - Used to designate the default mileage expense type (e.g., MILEAGE)
  10. airfare – used to designate the airfare entry on the “new” report screen.
  11. defaultcompany – Not currently used.

 

C. generaloffset

Items in this element are used by the generic EOD G/L creation to create debit entries for receipt types that do not have expense information. Currently, these receipt types are identified in the process element above. In the non-customized installation, they are 'advance' and 'cash-retd.' Inportant, the element names are constructed by the program. Credit information is stored in the payment type table.

  1. advance_debit_account - major account number for the advance debit.
  2. advance_debit_costcenter - cost center for the advance debit.
  3. advance_credit_account - major account number for the credit.
  4. advance_credit_costcenter - cost center for the credit.
  5. cash-retd_debit_account - major account number for the debit offset.
  6. cash-retd_debit_costcenter - cost center for the debit offset.
  7. cash-retd_credit_account - major account number for the debit offset.
  8. cash-retd_credit_costcenter - cost center for the debit offset.
  9. cash_search
  10. cash_debit_account - major account number for the debit offset.
  11. cash_debit_costcenter - cost center for the debit offset.
  12. cash_credit_account - major account number for the debit offset.
  13. cash_credit_costcenter - cost center for the debit offset.
  14. billable_debit_account - major account number for the debit offset.
  15. billable_debit_costcenter - cost center for the debit offset.

 

D. registertable

The register table element contains elements needed to describe the register table to the application. Currently there is only one element.

  1. listreports - This is the SQL statement that is used to display the report selection list in the "Your Reports" option. The statement must contain the following columns: register status, reference, message, central database status, account date, accounting time, register file date, personnel number and, report total receipt amount. The following macro substitutes are used: $owner$ - personnel number of the reports desired. Used in Intro.jsp.

E. encrypt

Certain columns in the report, purpose and expense tables can be scrambled to prevent prying eyes from easily discerning trip purposes or locations. It is not a true encryption but actually a simple XOR cipher feedback process. It is not recommended for general usage but available if strongly desired. Please note, that if you decided to use this feature, you'll need to write routines to decrypt the columns in the event you wish to use this information outside the expense system. Scrambling occurs during the SQL write process so the values of the following sub-elements are dependent upon the database being used.

  1. apply - Set to 'Yes' to scramble, otherwise leave as 'No.'
  2. key - The decimal equivalent of the character to XOR with the first character of text. Additional characters are XORed against the previous results (i.e., feedback). (e.g., '6')
  3. base - Numeric base to use to describe the characters in the SQL statement. Needs to be 'Decimal,' 'Octal,' or 'Hex'
  4. head - Text string that begins each column value in the SQL statement.
  5. tail - Text string that ends each column value in the SQL statement.
  6. delimit - Text string that is between each character value in the column.

F. mileage

This element is a collection of rate elements and describes the default mileage rates to used over a period of time. Your can thus change the default rate but still allow creation of back dated reports with the effective rate for that period. This is especially useful during January or February as many companies set yearly rates. Each rate sub-element contains the following elements:

  1. value - Mileage reimbursement rate expressed in dollars or major currency. (e.g., 0.3450)
  2. effective01/01/2004/effective

G. sql

This is a desciption of the SQL format used for a particular database. If you have selected a standard configuration that matches your database, you shouldn't have to change this. If you are using a new database that doesn’t have a standard system.xml already for it, then you may have to tweak this section as well as most of the other SQL templates in this file.

  1. driver - simply identifies the driver for documentation purposes (e.g., 'VFP ODBC Setup')
  2. dateformat - Either 'MM/DD/YYYY' , 'YYYY-MM-DD’, or ‘DD-MMM-YYYY’.
  3. datesql - This is the string which to embed the date string to write to a date type SQL column. The macro $data$ is replaced with the date string. (e.g., "CTOD('$date$')" works for FoxPro)
  4. yessql - Column value to use for true. (e.g., '1')
  5. nosql - Column value to use for false. (e.g., '0')
  6. acceptnulls - Indicates whether the database accepts null values. If the database doesn't accept null values, the values are converted to either empty strings or zeros. 'No' indicates that the database does not accept nulls and a 'Yes' indicates that it does accept nulls.
  7. blankdate - String to use for a blank date. (e.g., '00/00/0000')
  8. locktablesql - Reserved.
  9. unlocktablesql - Reserved.
  10. insertmethod - Database method to use to insert a record. Available methods are 'SimpleSQL' or 'PreparedStatement.'
  11. reservedwordlist - List of column names, seperated by semi-colons, that will be double quoted when the standard AdisoftDbase routines are used. Note, this is database dependant and does not cover non-constructed SQL statements in the system.xml file.

H. passwordchange

This element contains the SQL statements that are used to change and reset passwords. Passwords can be originally set as part of the USER table maintenance process which is defined in the edit.xml file.

  1. updatesql - Used by end users to change their passwords. Supports macros: $password$, $date$, and $email$. Used by ChangePWD.jsp.
  2. resetsql - Used by support staff to reset their passwords. Supports macros: $password$, $date$, and $email$, however the $date$ macro is always set to a blank date. Used by ResetPassword.jsp.

I. personneltable

This information is used by PersonnelTalble.java to access the personnel table (i.e., USER).

  1. emailinfoallsql - Used be setEmailInfoAll method to load a personal profile and supports $email$.
  2. persinfosql - Used be setPersInfo method to load a personal profile and supports $email$.
  3. persinfoallsql - Used be setPersInfoAll method to load a personal profile and supports $persnum$.
  4. persnuminfosql - Used be setPersNumInfo method to load a personal profile and supports $persnum$
  5. blanktopersnum - Normally set to 'No.' A 'Yes' lets the personnel number be used as a password.
  6. persnumendcount - In conjunction with above, lets a portion of the personnel number be used as a password. This value indicates the offest to the portion to use. (e.g., '0')
  7. userlistsql - SQL statement used by auditor and administrators to pull up a list of users from which to select for report header entry. Must have last name, first name, phone, location, department code, email, vehicle, and service date columns. The $lname$ macro (last name) is used.

J. departtable

The DepartmentTable class to access the department table.

  1. departinfosql - Selets a row from the department table. Uses the $depart$ macro which is the unique department code or description.

K. vouchertable

This element describes how to generate central reference numbers.

  1. voucherobject - Should be set to 'ServerSystemTable' for all new installations.
  2. voucherprefix - Prefix for central reference numbers. (e.g., 'K')
  3. voucherlength - Reserved.

L. reportstatus

The ProcessESSReport class uses this element to accept and provide the initial state of a report into the central database.

  1. submitstatus - This is the initial status that a report is set to prior to running a guideline check. This should correspond to a status that is located in the default element and status sub-element. (e.g., ST_SUBMIT_ON)
  2. findsql - This is a SQL statement that will determine if the submitted report already exists in the database. Normally this is done be searching for a report with a valid processing status (i.e., hasn't been rejected of deleted) for this user and previous reference number. Macros $persnum$ and $pvoucher$ are used.
  3. updatecharsql - This SQL statement that is used to update a single date column in the report. Macros $column$, $value$, $persnum$ and $pvoucher$ are used.
  4. pdatesql - This SQL statement that is used to update a single non-date column in the report. Macros $column$, $value$, $persnum$ and $pvoucher$ are used.
  5. avoidduplicatesql - This SQL statement is used to check to see if this specific instance already exists in the central database. It uses macros $persnum$, $pvoucher$, $status$, and $voucher$.

M. reporttable

This element provides SQL status which are used to create report lists for various tasks. Each statement needs to return these columns: name, personnel number, total receipt (report) amount, report status (translated), report date, first approval signature, central reference number, previous reference number, second approval signature and, report department.

  1. selectapprove - List of reports for approval purpose. This is the list of all reports requiring approval. There is logic in the Approve List that will match reports against the current approver and only actually display the reports they can act on.
  2. selectaudit - List of reports that can be audited. This is the list of all reports requiring audit that met any work queue control rules. The work queue rules are part of the SQL statement.
  3. selectfasttrack - Similar to selectaudit above, but should only show reports that do not require physical receipts. If receipts are required before payment, these reports can be audited immediately avoiding an unnecessary delay in payment.

N. prepopulateditems

Pre-populated items generally enter the system through credit card feeds.

  1. selectcards – SQL that will retrieve a list of cards for a specific user from the card file.  The $persnum$ macro is used.
  2. selectallitems - SQL that selects all items that have not yet been used to pre-populate a report. Macros are $card$ and $number$. The unique reference or cursor must be in the first column.
  3. updateitem - SQL that updates the item as having been selected for a report. Macro is $recordcursor$.
  4. selectitem - SQL that identifies the individual, based on a unique reference number or cursor, for receipt creation. Macro is $readcursor$. Columns are the transaction type, and the transaction date.

O. prepopulatedrecovery

Recovery option in case user needs to repost an item.

  1. selectallitems - SQL that selects all items that have been marked as used but not reconciled as paid. Macros are $card$ and $number$. The unique reference or cursor must be in the first column.
  2. updateitem - SQL that updates the item as having been selected for a recovery. Macro is $recordcursor$.
  3. selectitem - SQL that identifies the individual, based on a unique reference number or cursor, for recovery. Macro is $readcursor$. Columns are the transaction type, and the transaction date.

Q. reconcilement

The reconcilement function allows auditors to reconcile charges that have been paid to credit card statements. It is primarily used to account that all items have been passed on an expense report, but can also be used to detect fraud caused by overcharging.

  1. selectallcarditems - This SQL selects the items from the vendor file that have been selected for a report but not yet reconciled. Macros are $card$ and $number$. Columns are the record cursor/unique reference, vendor status, card type, amount, transaction date, statement date, vendor reference, and detail.
  2. carditemtable - Physical name of the vendor table. (e.g., 'STATEMNT')
  3. selectallreceiptitems - This SQL selects the items from the receipt file that have been paid but not yet reconciled. Macros are $card$ and $number$. Columns are the record cursor/unique reference, status, payment type, anount, transaction date, report date, receipt reference, and merchant.
  4. receiptitemtable - Physical name of the ESS receipt table. (e.g., 'RECEIPT')

R. post

This element consists of a single sub-element that is executed by the reconcilement process to indicate that an item is OK. The pre-populated POST JSP select which statement to use based upon the table the item comes from. The table is the actual statusok sub-element. Below is an example of a statusok element that can handle a STATEMNT table or a RECEIPT table:

  • <statusok>
  • <STATEMNT>
  • UPDATE STATEMNT SET VND_STAT = 'OK' WHERE recno() = $rowkey$;
  • </STATEMNT>
  • <RECEIPT>
  • UPDATE RECEIPT SET OK_STAT = 'OK' WHERE recno() = $rowkey$;
  • </RECEIPT>
  • </statusok>

S. history

This element is used to generate the report history list. The report history list lets users access reports in the central database for personal investigations.

  1. approval - Should correspond to the first level approval type in the Status.xml. (e.g., 'MANAGER')
  2. reporter - This SQl lists all reports submitted for this user over the selected time frame. Macros are $persnum$, $begdate$, and $enddate$.
  3. approver - This SQl lists all reports approved by this user over the selected time frame. Macros are $persnum$, $begdate$, and $enddate$.
  4. admin - This SQl lists all reports entered by this user over the selected time frame. Macros are $persnum$, $begdate$, and $enddate$.
  5. subordinates - This SQl lists all reports for people who report to this user over the selected time frame. Macros are $begdate$ and $enddate$.

T. sendmessages

This element provides information needed to send payment notices.

  1. messagelistmsg - This is the screen message for the operator.
  2. messagelistsql - This is the SQL that selects the reports to have processing messages sent for. It uses the $update$ macro. It needs to specify name, personnel number, receipt (report) amount, report status (translation), report date, batch date, central reference number, previous reference number, and department columns for a specific batch date. Specific reports can be deselected so a message will not be delivered.
  3. messagesendsql - This SQL collects information on a report for the actual message send process, one report at a time. It needs colums personnel number, report status, name, receipt (report) amount, previous reference number, central reference number, batch date, department, report create date. It selects based on the $voucher$ and $status$ macros.

U. delinquentmessages

This element defines how the delinquent message routine will act, including the text of the follow-up messages that are sent out.

  1. resendafterdays - Number of days that will elapse, since submittal, before the orignal router is re-notified that they need to take action. This is calendar days (e.g., '7' would be two weeks). This person will then be notified everytime the delinquient message routine is run until they either approve/reject the report or until their manager is notified.
  2. notifymanagerdays - Number of days that elapse since submittal on non-approved reports before the original approvers manager is notified that the report is still in the queue.
  3. sendtoreporter - This is a list of central database status codes (i.e., Status.xml, translation element) that will notify the original reporter that his report needs action. These are normally manager and system reject stati.
  4. messagelistmsg - Instruction to the operator on running the delinquent report module.
  5. messagelistsql - The SQL that will select which reports need attention. This would be a list of specific stati where the last operation occurred prior to the current date adjusted for the number of "resend after days" number. The macro $update$ is substituted for the adjusted date.
  6. messagesendsql/messagesendsql
  7. notifymessage - Message sent to a reporter if there is a report that needs his attention. The follow are the macros used $pvoucher$, $voucher$, $amount$, $date$ and $status$.
  8. approvermessage - Message sent to an approver if there is a report that needs his attention. The follow are the macros used $pvoucher$, $voucher$, $amount$, $date$ and $status$. Note: It is customary to provide a link to the ESS system with this message.
  9. escalatemessage - Message sent to an approver's manager if there is a report that needs his attention. The follow are the macros used $pvoucher$, $voucher$, $amount$, $date$ and $status$. Note: It is customary to provide a link to the ESS system with this message.
  10. messagelistsql – SQL that retrieves the base set of reports for which to generate  delinquent approval messages. The $curdate$ macro is used.  The $curdate$ macro refers to the current date of the report (i.e., cur_date clomun). (In pre-1.7, the $update$ macro is used.  It is resolved with the cur_date.  The $update$ macro is still maintained, but has been deprecated.)

V. releasepayments

This element groups reports together in a 'daily' batch and updates their status so that they can be included in the posting and payments processes.

  1. screenmessage - This is the screen message for the operator.
  2. listsql - This lists the reports that can be included in the batch. The process allows an operator to deselect a specific report after it have been listed.
  3. retrievesql – used to verify the existence of a report.  Uses macros: $voucher$ and $status$.
  4. updatesql - Used to update the report status in the central database to indicate that it has been processed into a batch. Uses the macros: $status$, $date$, $persnum$ and $voucher$
  5. updatesqlreceipts – Used to update the receipt status in the central database to indicate that it has been processed into a batch. Uses the macros: $status$, $date$, $persnum$ and $voucher$
  6. updatesqlexpenses - Used to update the expense status in the central database to indicate that it has been processed into a batch. Uses the macros: $status$, $date$, $persnum$ and $voucher$

W. endofday

This element is used be the end of day feed creation process to take information from the ESS system and post it to other corporate systems.

  1. screenmessage - Message that describes the process to the person who runs the feeds.
  2. listsql - This is the SQL that selects the reports to be included in the feed. It uses the $update$ macro. It needs to specify name, personnel number, receipt (report) amount, report status (translation), report date, batch date, central reference number, previous reference number, and department columns for a specific batch date.
  3. feed - This element specifies an ESS complient class to run as part of the EOD feed creation process. Some generic classes are ess.NACHAFeed, ess.GeneralFeed and ess.GeneralPayment. This element type can appear multiple times.
  4. folder - This is the folder to deposit the output of the feeds in.
  5. prenote - A 'Yes' indicates that the prenotes should be included at the end of the daily NACHA.FIL file automatically. A 'No' indicates that prenotes will be handle in a separate process./prenote

X. achprenote

This element controls the ACH prenote process. The ACH prenote process also uses information in the nacha.xml file.

  1. listsql - SQL statement that selects users who have been designated to be prenoted.
  2. batchupdatesql – Reserved.
  3. updatesql - This updates a single user as having been prenoted. Uses the $date$ and $persnum$ macros. screenmessage - Instructions to the person running the prenote process.
  4. listsqlstatus - this SQL list the items that have been prenoted so that they can be marked as OK to send via ACH after the ten days have elapsed. Need columns: Personnel number, Lanst name, First name, payment method, prenote date, bank routing number and bank account.
  5. screenmessagestatus - Instructions to the person running the OK Prenote process.
  6. updatesqlstatusUPDATE USER SET CASH='ACH' WHERE PERS_NUM = '$persnum$';/updatesqlstatus

 

XX. auditreport

Contains only one sub-element, receiptcheckupdate, that contains the SQL statement to update a receipt with the status of a physical receipt.

Y. removereport

This is the set of SQL statements required to fully delete a report from the central database. There is one type of sub-element call sql. There can be a multiple number of sql statements, each one of which will be executed. The only macro is $voucher$.

Z. messages

This element consists of text messages that system uses to communicate with the user.

  1. email_name - Used as the email title in the acceptance notification generated by ProcessESSReport class.
  2. email_reporter - Used as the title for the reporters name in the accept notification generated by ProcessESSReport class.
  3. central_reference - Used as the central reference number title in the acceptance notification generated by ProcessESSReport class.
  4. personal_reference - Used as the previous reference number title in the acceptance notification generated by ProcessESSReport class. Note: the letter prefix is stripped from the previous reference number in this display.
  5. email_routeto - Title for the name of the individual that this report has been routed to for approval. Used in ProcessESSReport class.
  6. email_subject - This is the text that will appear on the subject line of the acceptance notification. Uses macros $voucher$ and $name$.
  7. email_new_line – the new line character to use.  Defaults to “\n”.
  8. submission_link - This is the text of the submission link that the user sees after the guideline check has been run.
  9. introduction - This is the text the user will see the first time that they log into the system.
  10. approvallist - Text that displays below the approval queue.
  11. auditlist - Text that displays below the approval queue.
  12. received - Screen message the user sees to indicate that the report has been submitted and persisted OK. Macros available are: $time$, $email$, $personalReference$, $personalStatus$, $centralStatus$ and, $centralReference$.

###