When Dynamics GP users are looking at a way to automate some of their payroll processes, they often look at implementing a time entry or time card system that will produce an electronic file that can be used for import. Some of the time entry software has its own built-in import functionality with Dynamics GP, but the software companies that provide this functionality are in the minority and may not always be a fit for an end-user due to cost or features. Because there are a variety of ways to import time entry information into Dynamics, we recommend that customers focus on the features of the time entry software, and not on whether there is already a pre-built import to Dynamics.
The two methods of import into Dynamics GP that will be discussed here are Table Import and Integration Manager. Both of these modules are Dynamics GP modules, but the features and requirements are fairly different between the two. For a payroll work transaction batch, both modules can import into the payroll work table destination. Both modules have some fields that are required to be part of the import file, but Table Import has more requirements than Integration Manager. Table Import is a default part of Dynamics, meaning it is not a separate install, and it is also included in the initial Dynamics software cost, so it is not a separate purchase. Integration Manager is a separate install and is an additional cost to purchase and use, but it is probably the easier of the two modules to use for imports.
From a recent test file I received from a customer, the fields that I found to be required in the import file for Table Import are as follows: Computer TRX Number, Employee ID, UPR TRX Code (pay code), TRX Beginning Date, TRX Ending Date, TRX Hours/Units, Department, and Job Title. These fields can be set as constant values, in a lot of cases, although some of them may have to be present in the import file, depending on where all of the job sites are located: Batch Number, Computer TRX Type (typically set as the value for pay code), State Code, and SUTA State. The Computer TRX Number is simply a column that will have sequential numbers assigned to each transaction line, so this number can start at 1 each time and increment by 1 up to the ending row; once entries are posted, the transactions used for import are not present in any history files, so the value used for the Computer TRX Number is usually unimportant. Depending on the complexity of the data contained in the import file, there may be other field values that either have to be set as constants or be present in the file, but the above example should cover most hourly pay code batches. A final step normally needed after an import with Table Import is to run Check Links file maintenance on the Payroll Transactions, which creates the Batch Number, among other things. In summary, Table Import needs to have most of the data that would be keyed into a transaction line present in the file, and for the most part, it cannot pull default information from the Employee Maintenance window. The exception to this is the Pay Rate Amount, which will default in from Employee Pay Code Maintenance.
As a part of the same test for the customer, I modified the sample Payroll Transactions import in Integration Manager, after making a backup of the sample integrations file. Integration Manager can be used for import with a lot fewer fields being present in the file, and you can also set Integration Manager to prompt for user input on certain fields, such as beginning and ending dates for the pay period (Date From and Date To in IM). As a bare minimum for Integration Manager, the fields needed for import are: Employee ID, Transaction Code (usually pay code), and Amount (hours). Oftentimes, a column or columns for start and end date are present, but they could be set as a prompt or as a default to the system date, if desired. Fields such as Department, Position (aka Job Title), State Code, and Suta State may also need to be present in the file if they change based on where the employee is working for a given set of hours. But we usually see most of those fields just mentioned being pulled in from the defaults in Employee Maintenance in Dynamics GP. Integration Manager does not need any Check Links file maintenance to be run after importing payroll transactions.
As you can see, imports of payroll transactions are easier to accomplish, even with a limited amount of data in the import file. The Integration Manager files can be stored locally or at a shared location on a server, as opposed to Table Import, which stores imports on the local C drive of the user who created the import. Integration Manager also produces a log file of any warnings or errors that it encountered during the import, to notify a user of exceptions found in the file, such as pay codes not existing on an employee, or employee id’s not yet set up in Dynamics. And fault tolerances for number of warnings and errors can be set on the Integration Manager imports. While there is a lot more functionality included in Integration Manager, some users do opt to use Table Import, and each import tool has pros and cons that an individual company can look at to determine the best fit for their needs.
By Margaret Saville, Summit Group Software