Over the last couple of days I have been working on installing an interface between Optimum Solutions Payroll (OSI) and VAI System 2000 (VAI) to automatically generate and post payroll General Ledger entries.
The process involved downloading what OSI calls an Opticom which contains the programs and files needed to post payroll General Ledger journal entries to VAI. Next I created a library GLI.VAI and through the OSI Opticom process I posted the downloaded Opticom to GLI.VAI.
Next, I had to update three OSI data area’s that identifies the GLI.VAI program library, VAI files library, and the new G/L interface menu. Step five from the instructions require that I move cross reference file to the OSI files library. As I typed the command I realized something is afoot. The library I created in step one, GLI.VAI is not the object library specified in the MOVOBJ command as documented. No biggie, I just changed it to what it should be and notified OSI of the inaccurate instructions.
I then added the appropriate records to the cross reference file. To make things a little easier I created a Query of the OSI GLMASTL1 file which contained all the defined G/L accounts in OSI and output to a file. I transferred the file to my PC and opened in Excel. I then added the corresponding VAI G/L account for each OSI G/L account. I also added an addition field to hold the company number. I named the columns exactly the same name of the fields in the OSI cross reference file. I then uploaded the completed spreadsheet back to the iSeries to my personal library. I then used CPYF command with *MAP to copy the records to the live cross reference file.
To test the process all I needed is the VAI system in test mode which requires I change the prefix of two data libraries in the library list from “R” to “T”. The programs OSI provided allows me to recreate the records from the last payroll run and populate VMOPOST file, VAI daily posting file. The process generates an error report of cross references errors and I had none.
The actual posting of the G/L journal entries are done during the VAI end of day process. To fully test, I triple checked my library list settings to make sure I am working with test files and, ran the end of day job. After a few minutes the job halted and display a program message, decimal data error.
I tracked the problem down to a numeric field in VMOPOST that was not initized when the records were added. This problem will occur when fields are added to end of a file and the program that uses the file has not been recompiled. I decided to just recompile the program that adds the records to the file. The compile failed, external field names exceed six positions. At this point I realize that I could convert the program to ILE but decide to consult with OSI helpdesk.
In our discussion we talked about the several different versions of VAI; R37.2, R37.4 and R37.6. There is a different Opticom for R37.6 and the one I was instructed to download only works with R37.2. No problem, 30 minutes later I had downloaded and installed the new version and reset my test data and the end of day finished with no error.
So another lesson learned the hard way, always give the complete version number of software you are working with. One decimal place made all the difference.
~Richard
The process involved downloading what OSI calls an Opticom which contains the programs and files needed to post payroll General Ledger journal entries to VAI. Next I created a library GLI.VAI and through the OSI Opticom process I posted the downloaded Opticom to GLI.VAI.
Next, I had to update three OSI data area’s that identifies the GLI.VAI program library, VAI files library, and the new G/L interface menu. Step five from the instructions require that I move cross reference file to the OSI files library. As I typed the command I realized something is afoot. The library I created in step one, GLI.VAI is not the object library specified in the MOVOBJ command as documented. No biggie, I just changed it to what it should be and notified OSI of the inaccurate instructions.
I then added the appropriate records to the cross reference file. To make things a little easier I created a Query of the OSI GLMASTL1 file which contained all the defined G/L accounts in OSI and output to a file. I transferred the file to my PC and opened in Excel. I then added the corresponding VAI G/L account for each OSI G/L account. I also added an addition field to hold the company number. I named the columns exactly the same name of the fields in the OSI cross reference file. I then uploaded the completed spreadsheet back to the iSeries to my personal library. I then used CPYF command with *MAP to copy the records to the live cross reference file.
To test the process all I needed is the VAI system in test mode which requires I change the prefix of two data libraries in the library list from “R” to “T”. The programs OSI provided allows me to recreate the records from the last payroll run and populate VMOPOST file, VAI daily posting file. The process generates an error report of cross references errors and I had none.
The actual posting of the G/L journal entries are done during the VAI end of day process. To fully test, I triple checked my library list settings to make sure I am working with test files and, ran the end of day job. After a few minutes the job halted and display a program message, decimal data error.
I tracked the problem down to a numeric field in VMOPOST that was not initized when the records were added. This problem will occur when fields are added to end of a file and the program that uses the file has not been recompiled. I decided to just recompile the program that adds the records to the file. The compile failed, external field names exceed six positions. At this point I realize that I could convert the program to ILE but decide to consult with OSI helpdesk.
In our discussion we talked about the several different versions of VAI; R37.2, R37.4 and R37.6. There is a different Opticom for R37.6 and the one I was instructed to download only works with R37.2. No problem, 30 minutes later I had downloaded and installed the new version and reset my test data and the end of day finished with no error.
So another lesson learned the hard way, always give the complete version number of software you are working with. One decimal place made all the difference.
~Richard
No comments:
Post a Comment