Journal Import Requirements and Technical Guidance
Total Page:16
File Type:pdf, Size:1020Kb
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: <Source>_<Date>_<SourceType>_<File Sequence>.<Extension> . <Source> - The file name must contain the name of the source; the “SOURCE” name in the name of the file MUST MATCH the name of the directory in which the source will place its files . <Date> - The file name will include the date in the format YYYYMMDD; The date should pad months and days with 0 when applicable (1-9) . <SourceType> - The file name must have either “ISP” or “NSP” depending on whether the Source is or is not an ISP . <File Sequence> - The file name must then have a sequence number, starting with the number 0001 (one). This will allow users and systems to submit multiple files per day; each day the sequence restarts at one (“0001”) This document is intended for technical audiences focused on remediation of systems impacted by Release 4 functionality of Workday 1 . <Extension> - The file extension will be .txt o Example: YDARCY_20170405_NSP_0001.txt • The schedule will import the files every 8:00AM, Noon, and 5:30PM – Monday through Friday 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 <Source>_<Date>_<SourceType>_<File Sequence>_<Journal Sequence> o The source systems or users that need to create multiple journals per file are responsible for generating this sequence number and placing the sequenced strings in the multiple GLH “Accounting Journal ID” fields o When a file contains only one Journal, the Journal Sequence is still a required part of the Accounting Journal ID attribute 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: <Source>_<Date>_<SourceType>_<Date>_<Sequence>.bad 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 .