Step 3: Application parameters

These application parameters must be established:

Application Parameter Description Default Value
documentExport.completedRetentionPeriod Numbers of days before completed transactions (status of 4) are removed from the export tables. 30
documentExport.errorRetentionPeriod Numbers of days before error transactions (status of 3 or 5) are removed from the export tables. 45
documentExport.inactiveRetentionPeriod Numbers of days before all other transactions are removed from the export table. 365
LCFOption Indicates whether LCF option is turned on for Travel Plans Export. If set to true, this allows loss carried forward to be tracked within Infor Expense Management. This enables "Amounts Due the Company" to be subtracted from future reimbursable expenses, so a negative "Amount Due Employee" is not exported to an external system. False
documentExport.TSExportLevel Indicates whether the export is at document or line item level.
  • 0 - Document
  • 1 - Line item
1 - Line item level.
documentExport.TSExportVerifyClass Timesheet Standard Export Verification Background Process verification class. largesoft.documentExport.tsexportTSStagingExportVerifier
documentExport.TSExportExceptionTransitionName Name of the export exception transition TS Export Exception
documentExport.purgeER Flag for purging exported expense reports. A true value purges exported expense reports. true
documentExport.purgeTP Flag for purging exported travel plans. A true value purges exported travel plans. true
documentExport.purgeTS Flag for purging exported timesheets. A true value purges exported timesheets. true
documentExport.purgeCR Flag for purging exported payment requests. A true value purges exported payment requests. true
documentExport.ER.checkErrorsFirst documentExport.TP.checkErrorsFirst documentExport.CR.checkErrorsFirst If you wish to have errors processed before successful verifications, set this parameter to 1 instead of 0. You may do this separately for each supported application. false
documentExport.ER.maxHeadersPerSearch documentExport.TP.maxHeadersPerSearch documentExport.CR.maxHeadersPerSearch This controls how many headers the Bkg can process before searching again. This affects:
  1. this count must be <= 1000 because of an Oracle requirement;
  2. more headers means fewer searches which means fewer queries, which means better performance;
  3. on the other hand, more headers means more data in memory, which means more memory required. 750 is a reasonable number.
1000
documentExport.ER.maxSuccessfulPerSweep documentExport.TP.maxSuccessfulPerSweep documentExport.CR.maxSuccessfulPerSweep If checkErrorsFirst is set to 1, maxSuccessfulPerSweep causes the validater to stop processing after some number of successful verifications and start over with error verifications. The same thing happens with maxHeadersPerSearch also. No limit