Interface Standards for Agencies
  • 16 Sep 2024
  • 7 Minutes to read
  • Dark
    Light
  • PDF

Interface Standards for Agencies

  • Dark
    Light
  • PDF

Article summary

Overview

Florida PALM will interface with agencies, enterprise partners, and third parties (e.g., banks). Interfaces refer to data exchanges between Florida PALM and other systems. Interfaces will be exchanged with our interface partners via the Florida PALM Managed File Transfer (MFT) server. Florida PALM has developed standards for interface file folders and file names. Interface partners (e.g., any entity sending or receiving information with Florida PALM) must ensure interface files meet Florida PALM standards, as defined for each specific interface. Table 1 reflects the general standards for interfacing with Florida PALM. The standards applied to each interface (e.g., fixed length, delimited or XML format) are specified for the individual interface.

Table 1: Florida PALM Interface Standards

Interface File Type

Format*

Transfer Protocol

Process Method

Flat File

Fixed, Delimited, XML

SFTP

Batch

*Defined by the individual interface

Naming Standards

The file naming standard for the Project comprises elements specific to the interface partner receiving or sending the file.

  • Interface Partner Acronym (names-and-acronyms.pdf (myfloridacfo.com))
  • Interface ID
  • Frequency
    • D = Daily
    • W = Weekly
    • BW = Bi-Weekly
    • BM = Bi-Monthly
    • M = Monthly
    • Q = Quarterly
    • Y = Yearly/Annually
    • FY = Fiscal Year/Dual Year
    • BA = Biyearly/Biannual
    • O = On-Demand/Ad-hoc
  • Agency Business System name (inbound only) – A 3-byte field identifying the sending agency’s business system. This acronym will be defined by the interface partner and is limited to 3 characters (numeric values are allowed).
  • Process Instance (outbound only) - A 6-byte field which is randomly generated by Florida PALM for each file run (number will change each time the file is ran). This provides a unique job tracking number.
  • Date and Time
    • Inbound format is YYYYMMDD-HHMMSS (Inbound contains seconds)
    • Outbound format is YYYYMMDD-HHMM

File Names

Inbound

  • Interface Partner_Interface ID_Frequency_ Agency Business System(3)char_YYYYMMDD-HHMMSS.Extension
    • Example - DFS_API002_D_UPM_20200415-145422.txt

Outbound

  • Interface Partner_Interface ID_Recurrence_Process Instance_YYYYMMDD-HHMM.Extension
    • Example - LASPBS _GLI001_D_163555_20200415-1454.txt

Agency Folder Structure

There will be three primary folder structures, which will allow agencies to send files and retrieve files from Florida PALM, as described in Figure 1.

  • The first level provided will be the Agency folder. This folder will provide security, which will allow Florida PALM to control data access at the Agency level. Only users for a specific Agency will be allowed to access their data unless otherwise granted.
  • The second folder level will be based on system functionality. These include Banking (existing Cash Management), Financials and Payroll.
  • The third level will be the inbound and outbound folders which will be the location for agencies to place and retrieve files.

The top-level folder, following the Root folder, will be at the agency level and be represented by their assigned acronym (i.e., DFS for Department of Financial Services). The three subfolders under the Agency are meant to help if there is a division of work and duties within an agency. For example, certain staff may be able to access bank statement information for their agency, but not be privy to payroll-related activities.

The working folder is used internally by Florida PALM.


Figure 1 – Agency Folder Structure

Enterprise Partner Folder Structure

There will be one primary folder structure, which will allow enterprise partners to send files and retrieve files from Florida PALM.

  • The specific enterprise partner’s acronym will be used at the top level.
  • The Banking, Financials, and Payroll subfolders will be omitted from the folder structure for enterprise partners.
  • The remaining folder structure will consist of an Inbound and Outbound folder, which will be the location for the enterprise partner to place and retrieve files.

Figure 2 shows the folder structure for all files interfacing with the FFMIS/Enterprise partners.

Figure 2 – Enterprise Partner Folder Structure

Folder Paths for Interface Testing and User Acceptance Testing

Agency Interface Testing (INT2) Paths:

  • Inbound
    • /mftfs_primary_pl/mft/ftp_root/non-prod/INT2/Agency Acronym/Banking/Inbound/
    • /mftfs_primary_pl/mft/ftp_root/non-prod/INT2/Agency Acronym/Financials/Inbound/
    • /mftfs_primary_pl/mft/ftp_root/non-prod/INT2/Agency Acronym/Payroll/Inbound/
  • Outbound
    • /mftfs_primary_pl/mft/ftp_root/non-prod/INT2/Agency Acronym/Banking/Outbound/
    • /mftfs_primary_pl/mft/ftp_root/non-prod/INT2/Agency Acronym/Financials/Outbound/
    • /mftfs_primary_pl/mft/ftp_root/non-prod/INT2/Agency Acronym/Payroll/Outbound/

Agency User Acceptance Testing (UAT2) Paths:

  • Inbound
    • /mftfs_primary_pl/mft/ftp_root/non-prod/UAT2/Agency Acronym/Banking/Inbound/
    • /mftfs_primary_pl/mft/ftp_root/non-prod/UAT2/Agency Acronym/Financials/Inbound/
    • /mftfs_primary_pl/mft/ftp_root/non-prod/UAT2/Agency Acronym/Payroll/Inbound/
  • Outbound
    • /mftfs_primary_pl/mft/ftp_root/non-prod/UAT2/Agency Acronym/Banking/Outbound/
    • /mftfs_primary_pl/mft/ftp_root/non-prod/UAT2/Agency Acronym/Financials/Outbound/
    • /mftfs_primary_pl/mft/ftp_root/non-prod/UAT2/Agency Acronym/Payroll/Outbound/

Enterprise Partner Interface Testing (INT2) Paths:

  • Inbound
  • /mftfs_primary_pl/mft/ftp_root/non-prod/INT2/Enterprise Partner Acronym/Inbound/
  • Outbound
  • /mftfs_primary_pl/mft/ftp_root/non-prod/INT2/Enterprise Partner Acronym/Outbound/

Enterprise Partner User Acceptance Testing (UAT2) Paths:

  • Inbound
  • /mftfs_primary_pl/mft/ftp_root/non-prod/UAT2/Enterprise Partner Acronym/Inbound/
  • Outbound
  • /mftfs_primary_pl/mft/ftp_root/non-prod/UAT2/Enterprise Partner Acronym/Outbound/

Archiving Files

After every instance of an interface process, whether inbound or outbound, the process will rename and move the files to the Archive folder for retention purposes, inclusive of the source or output file, log file, and error file, as applicable.

The archive process will be controlled by the MFT process rules and settings. Interface partners will have access to view their outbound files for a period of one week in the Outbound folder and inbound files will be almost immediately moved to archive and renamed. Interface partners will have access to the archival folders, which will retain files either consumed or produced (including process and error logs) by an interface process. There are four folders where files are stored.

Inbound Archival Folders

  • Archive Folder – contains a copy of the inbound interface file (.txt), summary log (.log), and error log (.err) with dates less than or equal to 90 days.
  • Logs folder - contains a copy of the summary log (.log) and error log (.err) files with dates less than or equal 90 days.
  • GT 90D archive files folder - contains a copy of the inbound interface file (.txt), summary log (.log), and error log (.err) with dates greater than 90 days and less than 180 days.
  • GT 180D archive files folder - contains a copy of the inbound interface file (.txt), summary log (.log), and error log (.err) with dates greater than or equal to 180 days (Up to 15 months).

Outbound Archival Folders

  • Archive Folder – contains a copy of the outbound interface file (.txt) and summary log (.log) with dates less than or equal to 90 days.
  • Logs folder - contains a copy of the summary log (.log) file with dates less than or equal 90 days.
  • GT 90D archive files folder - contains a copy of the outbound interface file (.txt) and summary log (.log) with dates greater than 90 days and less than 180 days.
  • GT 180D archive files folder - contains a copy of the outbound interface file (.txt) and summary log (.log) with dates greater than or equal to 180 days (Up to 15 months).

The archive file naming convention can be found below:

Inbound 

  • InterfacePartner_Interface ID_Frequency_AgencyBusinessSystem_YYYYMMDD-HHMM_YYYYMMDDHHMMSS.Extension

NOTE: The file name remains the same except for the date time added to the end of the file. This date time, as opposed to what is on the original file, will represent the date and time that the file was moved to the Archive Folder.

Outbound 

  • InterfacePartner_Interface ID_Frequency_YYYYMMDD-HHMM_YYYYMMDDHHMMSS.Extension

NOTE:The file name remains the same except for the date time added to the end of the file. This date time, as opposed to what is on the original file, will represent the date and time that the file was moved to the Archive Folder.

Log Files

During processing, log files (.log) will be created which will be stored in the Logs folder and give the general details from the program execution. Log files will primarily contain counts of received, processed, erred and warning records as well as possible control total amounts. The log file naming convention can be found below.

Log for Inbound File:

  • InterfacePartner_Interface ID_ Frequency _ABS_YYYYMMDD-HHMM.log

NOTE: Date Time will be the same as the matching inbound file.

Log for Outbound File:

  • InterfacePartner_Interface ID_ Frequency _Process Instance_YYYYMMDD-HHMM.log

NOTE: Date Time will be the same as the matching outbound file.

An example of a log file can be seen below in Figure 3.

Figure 3 – Sample log file

Error Files

If there were errors noted in the log file, each interface will also produce an error file (.err) for purposes of investigation and correction. This file can also be found in the Logs folder mentioned previously. The error file should be used to see which data records need to be resent or corrected in a subsequent file or within Florida PALM, specifically giving an account of the data elements and values that will assist with troubleshooting. There will be an accompanying error message to explain the error that has occurred during processing. The error file naming convention can be found below:

  • InterfacePartner_Interface ID_ Frequency _ABS_Process Instance_YYYYMMDD-HHMM.err

NOTE: Date Time will be the same as the matching inbound file that contained the errors.

An example of an error file can be seen below in Figure 4.

Figure 4 – Sample error file

General Information Concerning Errors

  • If a single transaction has failed multiple pre-validations, the error log will list both the input file row number and the key transaction data which will allow end users to locate and correct errored rows.
  • If a header passes pre-validation but there are rows with errors, the entire transaction (header and associated lines) will be removed from processing and listed on the error log. Only transactions that pass both header and line validations will be allowed to enter the Florida PALM staging tables for final processing.
  • Each transaction will have both the input file number and the key transaction information to locate the row(s) in error. The key transaction information provided will be dependent on the interface being executed. Example (Journal ID, Journal Date) for General Ledger Journals.

Version History

DateRevision Description
09/16/2024Original Version



Was this article helpful?

Changing your password will log you out immediately. Use the new password to log back in.
First name must have atleast 2 characters. Numbers and special characters are not allowed.
Last name must have atleast 1 characters. Numbers and special characters are not allowed.
Enter a valid email
Enter a valid password
Your profile has been successfully updated.