Dynamics GP Batch Selection Errors: Troubleshooting and Solutions

Table of Contents

This article provides a comprehensive guide to resolving common errors encountered when attempting to select or process a batch within the Build Payroll Checks window in Microsoft Dynamics GP. These issues often stem from payroll work tables not being properly cleared, leading to various system impasses. Understanding the root causes and applying the correct resolution steps is crucial for maintaining efficient payroll operations within your Dynamics GP environment.

Understanding the Problem: Symptoms of Batch Selection Errors¶

Users frequently encounter a range of error messages that prevent them from proceeding with payroll check building. These errors indicate that a payroll process might be stuck, or that critical temporary files and database records are in an inconsistent state. Identifying the specific error message is the first step toward diagnosing the underlying problem.

Here are the common error messages you might encounter:

• Error Message 1: “Open operation on UPR_Temp_Post2 has incorrect record length”
  This error typically points to corruption or inconsistency within temporary payroll posting files. It suggests that the system is trying to access a file that is either malformed or incomplete from a previous, perhaps interrupted, process. Such issues often prevent Dynamics GP from accurately reading and processing payroll data.

• Error Message 2: “Remove Range Operation on Table ddDeposits has caused known error 2”
  This message is specific to direct deposit functionalities within Dynamics GP. It indicates a problem when the system tries to clear or manage records related to direct deposits, suggesting a potential hang-up or data integrity issue within the direct deposit work tables. This can occur if a prior direct deposit run was not completed cleanly.

• Error Message 3: “Batches with zero transactions cannot be marked”
  This self-explanatory error occurs when a user tries to mark a batch for processing that, despite being created, contains no actual payroll transactions. This might happen if transactions were cleared or if the batch was created without any entries being added, yet the system still perceives it as an active batch.

• Error Message 4: “Another user is performing a check run”
  This is a concurrency error, indicating that the system believes another user or process is currently engaged in a check run. Even if no one else is actively running checks, this message can appear if a previous check run process was not properly concluded, leaving a lock or flag in the system that prevents new runs.

• Error Message 5: “UPR_Work_Post failed accessing SQL data”
  This error indicates a critical failure during the posting process, specifically related to accessing SQL Server data. It suggests that Dynamics GP cannot read from or write to the necessary payroll work tables in the SQL database, potentially due to locks, corrupt data, or network communication issues with the SQL server.

• Error Message 6: “The employee record cannot be inactivated or deleted Pay run is in progress for this employee”
  This message typically appears when an attempt is made to modify an employee record (e.g., inactivate or delete) while the system still perceives that employee as being part of an active or pending payroll run. It highlights a conflict between administrative tasks and an ongoing payroll process.

• Error Message 7: “Checks cannot be calculated. Errors were found.”
  This is a general error indicating that the system encountered various inconsistencies or data integrity issues that prevent the successful calculation of payroll checks. The underlying problems could range from missing employee data to incorrect tax settings or corrupted transaction records.

• Error Message 8: “You cannot void a check. A computer check run is in process.”
  Similar to Error 4, this message signals that the system is currently locked into a computer check run process. It prevents actions like voiding checks, which could interfere with the integrity of the ongoing or perceived ongoing payroll run. This lock needs to be cleared before any voiding can occur.

• Error Message 9: “You cannot edit a batch marked for posting”
  Once a payroll batch has been marked for posting, Dynamics GP locks it to prevent any modifications that could compromise the accuracy of the payroll run. This error appears if a user attempts to edit such a locked batch.

• Error Message 10: “Batch is marked for posting and cannot be edited.”
  This is essentially a reiteration of Error 9, providing the same message in a slightly different phrasing. It reinforces the system’s strict control over batches that are prepared for final processing, ensuring data integrity during critical payroll operations.

In addition to these specific messages, you might also encounter generic “Open Operation error,” “Get/Change error,” or “Save Operation error” messages. These more general errors often appear when Dynamics GP attempts to interact with one of the following critical payroll work tables and fails, signaling that the payroll batch is “stuck”:

• UPR_WORK_MSTR
• UPR_WORK_MSTR_Detail
• UPR_WORK_HDR
• UPR_WORK_Pay_Type
• UPR_WORK_Deduction
• UPR_WORK_Benefit
• UPR_WORK_State_Tax
• UPR_WORK_Local Tax
• UPR_WORK_Check
• UPR_WORK_Post
• UPR_Flat_Tax_Records
• UPR_Account_Cache

These tables are temporary holding areas for payroll data during the calculation and processing phases. When a process is interrupted, these tables may not be cleared, leading to the system perceiving an ongoing operation and subsequently blocking new payroll runs.

Root Cause of the Problem¶

The fundamental cause of these errors is typically the incomplete clearing of payroll work tables. During a normal payroll process, Dynamics GP uses a series of temporary “work” tables to store data as calculations are performed, checks are built, and processes are initiated. If a payroll run is interrupted—due to a power outage, network disconnection, user force-quitting the application, or a system crash—these work tables may retain data.

When subsequent attempts are made to perform payroll functions, Dynamics GP encounters data in these tables that suggests an operation is already in progress, or that the data is in an inconsistent state. This triggers the various error messages and prevents further processing. Effectively, the system believes a payroll batch is still active or “stuck,” preventing any new operations until these temporary table locks and data remnants are cleared. Releasing these “stuck” batches requires manual intervention to clear these tables.

Resolution: A Step-by-Step Guide¶

Before initiating any of the following steps, it is imperative to create a complete backup copy of your Microsoft Dynamics GP database. This precaution ensures that you can restore your data to its original state in the unlikely event that a problem occurs during the resolution process. Data integrity is paramount, especially when dealing with financial records.

Step 1: Delete Records in Payroll Work Tables using SQL¶

This step involves directly clearing the contents of specific payroll-related work tables in your Dynamics GP company database and the shared DYNAMICS system database. This action effectively tells Dynamics GP that any previously “stuck” payroll processes are now clear.

1. Access SQL Server Management Studio (SSMS):
   Open Microsoft SQL Server Management Studio. This is the primary interface for interacting with your SQL Server databases. To launch it, navigate to Start > All Programs > Microsoft SQL Server [Your Version] > SQL Server Management Studio. Connect to the SQL Server instance hosting your Dynamics GP databases.

2. Execute Delete Statements:
   Once connected to SSMS, open a new query window. You will need to run DELETE statements against both the DYNAMICS system database and your specific company database where the payroll issue is occurring. The first two lines of the script target the DYNAMICS database, which stores system-wide activity files. The remaining lines target the payroll work and activity files within your company database.

   Delete DYNAMICS..UPR10300
   Delete DYNAMICS..UPR10304
   Delete UPR10200
   Delete UPR10201
   Delete UPR10202
   Delete UPR10203
   Delete UPR10204
   Delete UPR10205
   Delete UPR10206
   Delete UPR10207
   Delete UPR10208
   Delete UPR10209
   Delete UPR10213
   Delete UPR19900
   Delete UPR19901
   

   Important Note: Ensure you select the correct company database from the dropdown menu in SSMS before executing the DELETE statements that do not specify DYNAMICS.. in front of them (e.g., Delete UPR10200). The DYNAMICS.. prefix explicitly tells SQL to delete from the DYNAMICS database, regardless of which database you currently have selected.

   The tables listed above are temporary payroll work tables. Clearing them signals to Dynamics GP that no payroll process is active. Here’s a brief explanation of what some of these tables typically store:

   SQL Table Name	Description
   DYNAMICS..UPR10300	Payroll Batch Header Activity – Stores information about active payroll batches across all companies. Clearing this helps release system-wide locks.
   DYNAMICS..UPR10304	Payroll Work File – Another system-wide temporary table used during payroll processing.
   UPR10200	Payroll Work Header – Holds header details for the current payroll run in the specific company.
   UPR10201	Payroll Work Check – Stores detailed information for each check being built.
   UPR10202	Payroll Work Deduction – Contains details of deductions for checks in progress.
   UPR10203	Payroll Work Benefit – Holds information about benefits calculated for payroll checks.
   UPR10204	Payroll Work Pay Type – Stores pay type details for employees in the current run.
   UPR10205	Payroll Work State Tax – Temporary storage for state tax calculations.
   UPR10206	Payroll Work Local Tax – Temporary storage for local tax calculations.
   UPR10207	Payroll Work Master – General master work table for payroll.
   UPR10208	Payroll Work Master Detail – Detailed master work table.
   UPR10209	Payroll Work Post – Temporary table used during the payroll posting process.
   UPR10213	Payroll Work Check Information – Additional check-related work data.
   UPR19900	Payroll Cache Account – Caches account information for faster processing.
   UPR19901	Payroll Cache Flat Tax Records – Caches flat tax rate information.

3. Direct Deposit Specific Table (If Applicable):
   If your organization utilizes the Direct Deposit functionality in Dynamics GP, you must also run an additional DELETE statement for the Direct Deposit Work table. This table (DD10100) specifically manages temporary data related to employee direct deposits during a payroll run. Clearing it ensures that any direct deposit process that might have been stuck is also released.

   Delete DD10100 -- (Direct Deposit Employee Deposit Work)
   

   
   Execute this command in the context of your company database, just like the other UPR tables.

Step 2: Delete Temporary Files¶

Beyond database entries, Dynamics GP also uses local temporary files on the workstation or server where the payroll process was initiated. These files can sometimes become corrupted or remain locked, contributing to the “stuck batch” symptom.

To delete these temporary files:

1. Open Windows Explorer: Navigate to the Windows Temporary directory. The typical path is C:\Windows\Temp. It’s important to differentiate this from the user-specific temporary directory (often C:\Users\[YourUser]\AppData\Local\Temp). The system-wide C:\Windows\Temp is more likely to contain relevant Dynamics GP temporary files.
2. Identify and Delete Files: Within this directory, locate and delete any files that begin with TNT. These are often temporary files created by Dynamics GP. Additionally, delete any files that have a .tmp file name extension. These are generic temporary files, but Dynamics GP might use them. Ensure that Dynamics GP and any related applications are closed on the machine before attempting to delete these files to avoid “file in use” errors.

Step 3: Run Check Links on Payroll Transactions¶

Check Links is a powerful maintenance utility in Dynamics GP that verifies the logical integrity between related tables in the database. In this scenario, running Check Links on Payroll Transactions is crucial because it can reconstruct the batch header record (UPR10301) if it was inadvertently deleted during the SQL cleanup, by referencing the existing transaction records (UPR10302). This ensures that your payroll transactions are correctly associated with a recognizable batch.

To perform Check Links:

1. Access Check Links: In Microsoft Dynamics GP, navigate to Microsoft Dynamics GP menu > Maintenance > Check Links.
2. Select Series: In the Check Links window, from the Series dropdown list, select Payroll. This filters the available logical tables to those relevant to payroll.
3. Select Logical Table: In the Logical Tables list, highlight Payroll Transactions. Then, select the Insert button to move it to the “Selected Tables” area. This specifies that you want Check Links to run specifically on your payroll transaction data.
4. Confirm and Run: Select OK. A Report Destination dialog box will appear. Choose your preferred destination for the integrity report (e.g., Screen, Printer, File) by marking the appropriate checkbox. It’s highly recommended to print or save this report for review, as it will list any discrepancies found and actions taken by Check Links. Finally, select OK to begin the process.
   The system will then scan your payroll transaction data, reconcile any inconsistencies, and recreate any necessary batch header records based on existing transaction details.

Step 4: Build the Check File Again¶

After completing the database cleanup, temporary file deletion, and data integrity check, you should now be able to return to the Build Payroll Checks window in Dynamics GP. The previously “stuck” batch should now be accessible, and you can proceed with building the check file without encountering the prior errors. All the transactions that were part of your original payroll batch will still be present, as the SQL scripts primarily cleared temporary work tables and not the main transaction tables.

Common Questions and Clarifications¶

Q1: I don’t want to delete the whole payroll batch and start over. Should I still follow the steps above?¶

A1: Yes, absolutely. The resolution steps outlined above are specifically designed to clear temporary work files and batch header records, not the actual payroll transactions. Your payroll transactions are stored in the UPR10302 (Payroll Transactions) table, which is not included in the DELETE scripts. Therefore, the transactions themselves are preserved. When you run Check Links (Step 3), the system will intelligently re-create the batch header record (UPR10301) based on the existing transactions in UPR10302, effectively “re-linking” your transactions to a valid batch structure. This process ensures data integrity while resolving the “stuck” batch issue without requiring you to re-enter all payroll data.

Q2: I posted the new batch, and it disappeared. It should have been a recurring batch.¶

A2: If a batch that was previously set as recurring disappears after posting, it likely means its “recurring” status was inadvertently lost or not re-established during the recovery process. While the transactions posted correctly, the system no longer recognizes the batch as one that should regenerate for the next payroll cycle.

To address this, you have a couple of options:

1. Manually Recreate the Recurring Batch: Navigate to Transactions > Payroll > Batches. Create a new batch with the exact same name and settings as your original recurring batch. Ensure you mark it as a “Recurring” batch and set the appropriate frequency (e.g., Weekly, Bi-weekly). This will re-establish the recurring batch for future use.
2. Review Batch Setup after Check Links: In some complex scenarios, if the batch was truly recurring and its definition was corrupted, you might need to run Check Links on other Payroll tables (e.g., Payroll Setup) if the batch definition itself wasn’t recovered. However, typically recreating it manually is the most straightforward approach if it simply “disappeared” from the recurring list.
   It’s always a good practice to verify the recurring batch settings after any significant database maintenance or recovery, to ensure they are correctly configured for future payroll periods.

Additional Troubleshooting Tips and Best Practices¶

To minimize the recurrence of these errors and ensure smoother payroll processing in Microsoft Dynamics GP, consider the following:

Preventative Measures¶

• Proper User Exit: Always ensure all users log out of Dynamics GP cleanly. Instruct users to never forcibly close the application or shut down their computers without exiting GP first.
• Dedicated Payroll Workstation: If possible, perform critical payroll runs on a dedicated, stable workstation with a robust network connection. This minimizes the chance of network interruptions during processing.
• Scheduled Maintenance: Implement a routine schedule for running Check Links and Reconciliation utilities in Dynamics GP. While not always needed daily, regular checks can identify and resolve minor inconsistencies before they escalate.
• Database Health: Work with your IT team or Dynamics GP partner to ensure your SQL Server environment is well-maintained. This includes regular indexing, statistics updates, and ample disk space.

Further Troubleshooting Steps (If issues persist)¶

• Clear Dex.ini Locks: Sometimes, a workstation-specific lock can persist in the Dex.ini file (found in the GP client application directory). This lock can prevent certain processes. While less common for batch selection errors, it’s worth checking if other users are getting locked out.
• Run Microsoft Dynamics GP Utilities: If you suspect deeper database integrity issues, running Microsoft Dynamics GP Utilities and selecting “Synchronize data and create security” can sometimes resolve underlying table structure problems. This should be done with caution and usually under guidance from a GP professional.
• Review Event Viewer Logs: Check the Windows Event Viewer logs on the SQL Server and the Dynamics GP client machine for any errors or warnings that coincide with the time the batch selection error occurred. These logs can provide clues about network issues, SQL Server problems, or application crashes.

By following these steps and adopting best practices, you can effectively resolve Dynamics GP batch selection errors and ensure a more stable payroll environment.

We hope this comprehensive guide has been helpful in resolving your Dynamics GP payroll batch selection issues. Do you have any further questions or perhaps a related experience to share? Feel free to leave a comment below and let’s discuss!