Journal Import Requirements and Technical Guidance
Document Purpose
The purpose of this document is to provide technical requirements information regarding the Journal Import process for those involved in the remediation of systems impacted by Workday Release 4 functionality. Prior to Workday Release 4 in July 2017, journal import utilizes the Journal Staging Area (JSA). This document provides information about the design that will be used to replace the JSA process of uploading files into Oracle with the new process for loading files into Workday. The process covers both non-Internal Service Provider (non-ISP) and Internal Service Provider (ISP) Journal Imports.
Process
Due to the large number of JSA sources, one of the guiding principles for the new Journal Import process has been that the overall process should feel familiar and require minimal training for end-users. In order to accomplish this goal, the design(s) utilizes the existing Managed File Transfer (MFT) source directories; the file formats, while different, utilize a file format that contains a Header (GLH) record and multiple Detail (GLD) records. The formats can be viewed in the template file - ISP and non-ISP journal file layouts.
The designers of the process are aware that there are use cases that will require some sources to submit both JSA files to be routed to EBS at the same time that they are submitting Journal Import files to be imported into Workday. This use case is very constrained and will only last for a very short period of time. If you think this may apply to you, the team would like to hear from you. The expectation is that if you are today using JSA, you will need to remediate your system to use the new Journal Import process.
The file naming conventions listed below ensures that the Oracle EBS and Workday processes remain discrete and that files are routed to the appropriate target system. If your use case requires creation of files to be sent to both target systems, please note that nothing in the Oracle EBS JSA process will change, and that all file names, etc. will remain the same. Please also note that this does not mean that you can continue to process JSA files indefinitely and thereby avoid cutting over to the new Journal Import process. The following information pertains to the new Journal import process.
• The Journal Import file name will have four (4) fields separated by underscores (“_”), plus a file extension o Format:
This document is intended for technical audiences focused on remediation of systems impacted by Release 4 functionality of Workday 1
.
Directory • The process will use the same Source directories that are used by the legacy Journal Staging Area Process; users/system owners will use the same location currently used o During the period from go-live in July 2017 to about November 2017 when the final Fiscal year close occurs, users/systems may need to submit journals both to EBS JSA and to Workday Journals Import. The file naming convention will insure that both kinds of files can be submitted without issue
File Attributes
• The file will be created as a Tab-delimited file (as it is in the legacy process); the file submitted will be based on any one of multiple templates for different use cases (ISP and non-ISP journal file layouts) • The template contains headings or field/column names. When a file is created, either through automation or though manually saving the appropriate template, it must be saved as Tab- delimited and the headings/column labels must be removed. This follows from the current process and file format • The “SOURCE” name in the file name MUST MATCH the name of the directory in which you place the file. This is your MFT source directory • The file must not contain more than 10,000 GLD (detail) records. This is a Workday limitation and cannot be extended • Though any given Journal may not exceed 10,000 GLD records, it is acceptable to send a single file with multiple Journals. This would be characterized as a file that has multiple GLH records, followed by the GLH records pertaining to that GLH record. However, any one Journal in the file may not exceed 10,000 GLD records. The only other limit is that file size must not exceed 1 Gigabyte • The Journal Source name must be placed on the header (GLH) record in “Journal Source” attribute • The Journal “name” must be placed on the GLH record in the attribute called “Accounting Journal ID.” This attribute will be the concatenation of the file name and an additional sequence number representing the journal counter. This will allow for single or multiple journals per file. The format of the Accounting Journal ID will be: o
Validations
This document is intended for technical audiences focused on remediation of systems impacted by Release 4 functionality of Workday 2
Generally, there will be two types of validations: 1. Validations performed prior to import o These validations will be referred to as “Pre-Load Validations” and will be performed prior to invoking the import of the Journal(s) 2. Validations performed as a part of the import o These validations will be referred to as Workday Validations • The flow of validations and errors will be as follows: o If a file fails Pre-Load Validations, it will be rejected, and will not be loaded into Workday; appropriate error reporting will be performed to inform users of the erroneous submission. Details of that reporting are documented in subsequent sections o When a file fails Pre-Load Validations, the system owner or user will need to correct the errors, regenerate a file and upload that file to the appropriate MFT location o If a file passes Pre-Load Validation, it will be loaded into Workday. At this point, the data in the file will be transformed, submitted and will become subject to Workday Validations (validations built into Workday) for Journal Import o If any data in the file fails Workday Validations, it will likely be the result of issues with the COA segments. In that case, the file will be imported into Workday, with errors. o In the event of either data issues or success, an error report will be created and placed in the appropriate location. Details follow in the detailed specification o If there are data issues, the system owner/user will be responsible for reviewing the Journal(s) in Workday and correcting the errors o In the event that there are too many errors to be corrected efficiently, the system owner/user will have the ability to cancel the Journal(s), correct the issues in their source system, and resubmit a file using the next file sequence number
Detailed Pre-load Validation Requirements • Pre-Load Validations - o Duplicate Journal Name – The Accounting Journal ID in the header record(s) of the template; this Accounting Journal ID will be the filename of the current file concatenated with a journal sequence; the integration will look at the first six characters of that Reference ID and insure that it matches the SOURCE segment from the Accounting Journal ID . The purpose of this requirement is to insure that the file source represented in the header actually matches the source from which it came o Empty Submission – validate that the document is not null/empty o Control Totals – The Control Total on the header must match total credits and total debits in the file o Required Fields – Validate that required fields are present and filled – these include . Company . Debit or Credit populated on all lines . Debit or Credit precision to two decimals . Date Fields are correctly formatted . COA present and valid; COA Validation must be performed for each of the Journal Lines o If there are any failures of these Pre-Load Validations, the Workday integration will rename the existing Source file on the MFT as “.bad” . Source File Name Format:
This document is intended for technical audiences focused on remediation of systems impacted by Release 4 functionality of Workday 3
. Example: A file named YDARCY_20140405_NSP_0001.process will become YDARCY_20140405_NSP_0001.bad o If there are any failures of these Pre-Load Validations, the Workday integration will create and deliver an HTML Error Report(s) to MFT that indicates the error that triggered the failure for the source file, e.g., Control Totals do not match . Single Journal Error Report Name Format (Single Journal):
Error Process
• Where multiple files are submitted, multiple error/success reports will be returned to the source directory after processing; where a single file is submitted with multiple journals, multiple files with success/error reports will be returned to the source directory • In the event that the file does not match the directory from which it was taken, the WebMethods should log the error in the job-run log; the filename and the error, i.e., “Filename Source segment does not match Source Directory Name” should be recorded. The Summary line at the top of the job-run log should specify that errors were encountered. This would include a status of ERROR • After the report is created, the original source file will be renamed to either “.done” for success and “.error” for files in error o Successful Submissions . Source Name Format:
Other
Workday cannot handle Journals larger than 10K lines reliably. This limitation was imposed by Workday. The option of splitting files programmatically leads to too many issues with respect to error handling, and having the sources slit the files is simply the most reliable way of handling this limit
• Files on the MFT will be retained for a minimum of 45 days and may be destroyed afterwards • The Workday integration events will have retention set to 180 days in production (90 days in DEV/TEST)
Definitions
Term Definition Journal Source A Journal Source may be characterized as a Sub-ledger that needs to submit Journal files to the general ledger. Sub-ledgers record economic events that take place outside Workday. Such events include transactions with parties external to the University, or internal transactions such as interdepartmental sales or transfers and adjustments of estimates. See: http://your.yale.edu/policies-procedures/procedures/1305-pr01-journal- entries#Journal Entry Process
Internal Service An Internal Service Provider is a unit that regularly provides goods and/or Providers (ISP) services to other University Organizational Units or Departments and charges for those goods or services. ISPs include: Specialized Service Facilities, Recharge Centers, and Cost Allocation Units, as defined in this section. http://your.yale.edu/policies-procedures/policies/1410-internal- service-providers
Non-Internal Service A Non-Internal Service Provider is all sources that do not conform to the Provider (non-ISP) definition for an Internal Service Provider, above.
Managed File Transfer Managed File transfer is a Secure FTP server used for transferring data to (MFT) and from sources to Workday Journals; today all JSA sources use the Managed File Transfer server to transfer JSA files. The replacement for existing JSA will continue to use the MFT for transferring files, as outlined in this document.
This document is intended for technical audiences focused on remediation of systems impacted by Release 4 functionality of Workday 5