Resuming Interrupted Check Runs in Dynamics GP: A Step-by-Step Guide

Table of Contents

An interrupted check run in Microsoft Dynamics GP’s Payables Management can be a significant disruption, potentially leading to incorrect financial records, duplicate payments, or missing transactions. Such interruptions can occur due to various reasons, including network issues, power outages, system crashes, or even user errors. Prompt and accurate recovery is essential to maintain data integrity and ensure smooth financial operations.

This guide outlines the professional steps required to continue a check run after an unexpected interruption. We will explore two primary approaches: restoring from a recent backup or performing a meticulous manual recovery. Each step is designed to help you efficiently resolve the issue while minimizing further complications and ensuring the accuracy of your financial data in Microsoft Dynamics GP.

Step 1: Restore Microsoft Dynamics GP from a Backup¶

When a check run is interrupted, the immediate priority is to assess the situation and choose the most appropriate recovery path. The simplest and most recommended approach, whenever feasible, is to restore your system from a recent, reliable backup. This method typically negates the need for complex manual data manipulation and helps preserve data integrity.

Option 1: Restore from a Prior Backup¶

If you have a viable and recent backup of your Microsoft Dynamics GP company database created before the interruption occurred, this is the preferred recovery method. Restoring from a backup allows you to revert the system to a known good state, effectively undoing any partial or corrupted changes caused by the interruption. After the restoration, you can simply rebuild and restart the check run from scratch, ensuring all transactions are processed correctly and cleanly. This approach minimizes the risk of data discrepancies and is often the quickest way to resume operations without intricate troubleshooting. No further steps are typically required once a successful restoration and re-creation of the check run are completed.

Option 2: Manual Recovery Process (If Backup is Not Feasible)¶

If restoring from a backup is not an option, or if a backup restoration doesn’t fully resolve the issue, a more detailed manual recovery process is necessary. This involves carefully clearing temporary system tables and resetting the batch status to make it available for reprocessing. It’s a delicate procedure that requires precision to avoid further data corruption.

1. Make a Current Backup¶

Before attempting any manual data manipulation, it is critically important to create a new, current backup of your company database. This backup will serve as a safety net, allowing you to revert to the current state of the data if any of the subsequent manual steps lead to unintended consequences. To perform this essential backup, ensure all users are signed out of Microsoft Dynamics GP to prevent any active transactions from interfering. Navigate to the File menu, select Backup, choose the specific company you intend to back up from the list, and then specify a secure location for the backup file.

2. View TEMP Tables¶

To confirm that all users are truly logged out and to identify any “stuck” session records, you need to examine the contents of several temporary tables. These tables hold session and locking information for active users in Dynamics GP. Run the following SQL scripts against your Dynamics database to view the records within these tables:

SELECT * FROM DYNAMICS..ACTIVITY
SELECT * FROM DYNAMICS..SY00800
SELECT * FROM DYNAMICS..SY00801
SELECT * FROM TEMPDB..DEX_LOCK
SELECT * FROM TEMPDB..DEX_SESSION

Ideally, when all users have successfully logged out of Microsoft Dynamics GP, these tables should appear empty. Any records that remain in these tables indicate “stuck” sessions or locks, which can prevent proper system functioning and batch processing. These stuck records must be cleared before proceeding.

3. Delete TEMP Tables¶

If the previous step revealed any records in the temporary tables, these stuck entries must be cleared. This action will forcibly remove any lingering session information or locks that might be preventing the batch from being processed. Re-verify that all users are completely logged out of Microsoft Dynamics GP before executing these DELETE statements, as deleting records while users are active can lead to data corruption or further system instability. Run the following SQL scripts to clear these tables:

DELETE DYNAMICS..ACTIVITY
DELETE DYNAMICS..SY00800
DELETE DYNAMICS..SY00801
DELETE TEMPDB..DEX_LOCK
DELETE TEMPDB..DEX_SESSION

After executing these scripts, re-run the SELECT statements from step 2 to confirm that all tables are now empty. If any records persist, investigate why users might still be showing as active or if there’s a more persistent lock issue.

4. Reset Batch Status¶

Once the temporary tables are cleared, the next crucial step is to reset the problematic computer check batch back to an “available” status. Interrupted processes often leave batches in a “locked,” “posting,” or “edited” state, preventing further action. To clear this status and make the batch accessible again, execute the following SQL script against your company database:

UPDATE SY00500 SET MKDTOPST=0, BCHSTTUS=0 where BACHNUMB='XXX'

Important Note: Replace 'XXX' in the script with the exact batch number or batch ID of the interrupted check run. You can find this batch ID in the Batch ID window within Microsoft Dynamics GP. The MKDTOPST=0 and BCHSTTUS=0 settings effectively mark the batch as not being posted and set its status to available, allowing you to interact with it again.

5. Review the Batch¶

After resetting the batch status, it is imperative to thoroughly review the batch within Microsoft Dynamics GP. Open the batch and carefully examine all included transactions to ensure their accuracy and completeness. Look for any discrepancies, missing entries, or corrupted data that might have resulted from the interruption. This step is crucial for identifying any lingering issues before attempting to reprocess the checks. If any issues are found, they should be addressed before moving forward.

6. Transition to Step 2: Using the Appropriate Method¶

Upon successful completion of the initial recovery steps outlined above (especially if you followed Option 2), you are now ready to determine the specific method required to continue your check run. The path you take next depends entirely on the stage at which the check run was interrupted—whether checks were printed, partly posted, or neither. Proceed to the next section to identify and implement the most suitable method for your situation.

Step 2: Use the Appropriate Method¶

Having addressed the initial system and batch status issues from Step 1, it’s now critical to choose the correct recovery method based on the exact point of interruption. This decision tree will guide you to the most effective solution for restoring your Payables Management check run.

Consider the following scenarios:

• If all the checks were not printed and not posted: Proceed with Method 1. This scenario implies the interruption occurred very early in the process.
• If all the checks were printed but not yet posted: Use Method 2. Here, physical checks exist, but the accounting entries haven’t been finalized.
• If all the checks were printed, but only some were partly posted: Refer to Method 3. This is the most complex scenario, requiring careful reconciliation.
• If the posting was interrupted and resulted in data damage (e.g., a check appears applied but doesn’t exist): In such severe cases, immediately restore to a clean backup. If a restoration is not possible or insufficient, it indicates a need for advanced data repair. In such situations, contacting a certified Microsoft Dynamics GP partner and opening an advisory service request is highly recommended, as fixing damaged data often falls outside standard support policies and may incur consulting fees.

The following flowchart illustrates the decision process:

mermaid graph TD A[Start: Check Run Interrupted] --> B{Did checks print?}; B -- No --> C{Were checks posted?}; B -- Yes --> D{Were checks partly posted?}; C -- No --> M1[Method 1: Checks not printed, not posted]; C -- Yes --> RESTORE[Restore to Backup - Data Damage Likely]; D -- No --> M2[Method 2: Checks printed, not posted]; D -- Yes --> M3[Method 3: Checks printed, partly posted];

Method 1: The Checks Weren’t Printed¶

This method applies when the interruption occurred before any physical checks were printed, meaning no check stock was consumed, and no actual payments were issued. The goal here is to reset the batch and re-create it correctly from scratch.

1. Review Batch¶

Even if the batch status is now “Available” following Step 1, it is essential to review its contents thoroughly. Print a batch edit list to get a clear understanding of all transactions that were intended to be included in the original run. This list will serve as your reference for rebuilding the batch and identifying any potential data inconsistencies that may have arisen during the interruption. To generate this list, navigate to Transactions > Purchasing > Print Checks, select the relevant Payables batch ID, and then choose Print. Select your preferred report destination and confirm.

2. Run Check Links¶

To ensure the integrity of your Payables data, run the Check Links operation specifically on the Payables Transaction logical files. Check Links is a powerful utility within Dynamics GP that identifies and corrects inconsistencies in database records. It’s always a best practice to first run Check Links in a TEST company to preview the results and understand any proposed changes before applying them to your live company database. If you proceed in the live company, ensure you have a current backup and be prepared to restore if the results are not as expected. To run Check Links, go to Microsoft Dynamics GP menu > Maintenance > Check Links. In the Series list, select Purchasing. Move Payables Transaction Logical Files to the Selected Tables list by selecting Insert, then click OK. Finally, choose a report destination for the Check Links report.

3. Delete Batch¶

Once the data integrity is verified (or corrected by Check Links) and you have a clear edit list, you can safely delete the interrupted computer check batch. Deleting the batch removes all the problematic transactions from the system, allowing you to start fresh. It is crucial to have printed the edit list beforehand, as this is your sole reference for re-creating the batch accurately. To delete the batch, go to Transactions > Purchasing > Batches. Select the problematic batch ID, then click Delete. Confirm the deletion when prompted.

4. Rebuild Batch¶

With the old, problematic batch removed, you can now re-enter the checks and proceed with a new check run as normal. The information from your printed edit list will be invaluable here to ensure all the original payments are included. Microsoft Dynamics GP provides several windows for creating or editing Payables checks, allowing flexibility in how you rebuild your batch. You can access these from the Transactions menu, under Purchasing:

• Select Payables Checks window: Used for generating new check batches based on vendor invoices.
• Edit Payables Check Batch window: For reviewing and modifying an existing, but not yet printed, check batch.
• Edit Payables Checks window: Allows for detailed editing of individual checks within a batch.

Choose the appropriate window to re-create your checks, ensuring all details match your edit list, and then continue with your check run as if it were a new one.

Method 2: The Checks Were Printed, But Not Posted¶

This scenario is more complex than Method 1 because physical checks have already been printed. The key challenge is to reconcile the printed checks with the system records without duplicating payments or leaving unposted transactions. The goal is to post the already printed checks.

1. Review Batch¶

Even though checks were printed, the batch might still contain inconsistencies due to the interruption. After ensuring the batch status is “Available” (following Step 1), print a batch edit list. This list will detail the checks that were printed and the invoices they were intended to pay, serving as a critical reference for reconciliation. Navigate to Transactions > Purchasing > Print Checks, select the Payables batch from the Batch ID field, and then click Print. Choose your desired report destination and confirm.

2. Delete Batch¶

With the edit list providing a record of the printed checks, the next step is to delete the problematic Payables check batch from the system. This action removes the unposted batch entries, but crucially, it does not affect the physical checks that have already been printed. Deleting the batch clears the way for a clean re-entry and posting process. Go to Transactions > Purchasing > Batches, select the batch ID you wish to delete, and then click Delete. Confirm the deletion when prompted.

3. Run Check Links¶

To address any potential data inconsistencies that might have arisen during the interruption, run Check Links on both the Payables Transaction logical files and the Payables History logical files. The Payables History files contain information about posted transactions, so checking both ensures a comprehensive data integrity review. As always, it is highly recommended to perform this operation in a TEST company first to evaluate the results. If you proceed in your live company, always perform a current backup beforehand. To run Check Links, access Microsoft Dynamics GP menu > Maintenance > Check Links. In the Series list, select Purchasing. Insert both Payables Transaction Logical Files and Payables History Logical Files into the Selected Tables list. Click OK, then choose a report destination.

4. Revert Check Number¶

Since physical checks have already been printed, you need to ensure that when you reprocess, the system uses the same check numbers that are on those physical documents. To enable this, you must temporarily modify your Checkbook setup. Go to Cards > Financial > Checkbook. Select the Checkbook ID used for the Payables checks. In the Payables Options section, mark both the Duplicate Check Numbers and Override Check Number checkboxes. Then, critically, set the Next Check Number field back to the very first check number that was used in the interrupted run. Your previously printed Computer Check Edit List will be essential for identifying this starting check number. This setup allows Dynamics GP to process the checks using the original numbers. Be mindful that this setting should be temporary, and reverted after successful posting, especially if other users might be printing checks concurrently. Finally, click Save.

5. Rebuild Batch¶

Now, re-create the check batch to match the already printed physical checks. You can use one of the Payables checks windows accessed from Transactions > Purchasing: Select Payables Checks, Edit Payables Check Batch, or Edit Payables Checks. When re-creating the batch, carefully ensure that the check numbers align precisely with the physical checks you have. Before printing and posting, thoroughly verify the batch edit list and use the Payables Transaction Inquiry window to confirm that the invoices intended for payment still have an “Open” status. This crucial verification prevents duplicate payments or attempting to pay already-applied invoices.

6. Print to Screen/Plain Paper¶

Given that the physical checks have already been printed, you do not want to print to actual check stock again. Instead, you will “print” the checks to the screen or to plain paper. This action allows Dynamics GP to complete the printing process within the system, updating the necessary internal records without generating new physical documents. This step is necessary before the system will allow you to post the batch. Access the print function from the window where you created the checks and select “Print to Screen” or choose a plain paper printer.

7. Post Batch¶

With the checks virtually “printed” (to screen or plain paper) and all internal records aligned, you can now proceed to post the batch. Posting will finalize the financial transactions, update vendor balances, and generate General Ledger entries. To post the Payables check batch, go to Transactions > Purchasing > Post Checks. In the Post Payables Checks window, select the correct Batch ID. Enter the appropriate posting date for the checks. In the Process list, ensure Post Checks is selected, and then click Process. This action will complete the interrupted check run within your financial records.

Method 3: All the Checks in the Check Run Were Printed, But the Checks Were Only Partly Posted¶

This is often the most complex scenario, as it involves a partial update of your financial records. Some checks might have been fully posted, some might be in an intermediate state, and others might not have been posted at all. Careful reconciliation is paramount to avoid data discrepancies, duplicate entries, or unapplied payments.

Solution 1: Restore and Verify (If Backup Available)¶

If a recent and reliable backup exists from before the partial posting occurred, restoring to that backup can be the simplest recovery path. After restoring, you would then print the checks to the screen or to blank paper, as described in Method 2, and then post them. This assumes the backup effectively unwound the partial posting.

Crucially, after any restoration or partial posting scenario, you must diligently verify General Ledger (GL) entries.

• If your system is set up to ‘Post to General Ledger’ (meaning transactions create a batch in GL that needs manual posting), carefully review any saved GL batches to ensure they are correct and complete.
• If your system is set up to ‘Post Through to General Ledger Files’ (meaning transactions immediately update GL), run the Detailed Trial Balance report to confirm that all posted GL entries are accurate and reflect the true state of the transactions.

To verify GL entries, go to Reports > Financial > Trial Balance and select the Detailed Trial Balance report.
To review your posting setup, go to Microsoft Dynamics GP menu > Tools > Setup > Posting > Posting. Select Purchasing for the Series and Computer Checks for the Origin to see if batches are set to ‘Post to General Ledger’ or ‘Post Through to General Ledger Files’.

Solution 2: Manual Reconciliation and Reprocessing¶

If a full restoration isn’t viable or sufficient, a meticulous manual process is required to reconcile the partially posted batch.

1. Delete Batch¶

After completing Step 1 (making a backup and clearing temporary tables), and assuming the batch status is “Available,” you must delete the batch. This removes the problematic, partly posted batch from the system. Remember, deleting the batch does not undo any transactions that have already been posted to the General Ledger or reconciled in the bank. This step clears the stage for re-creating only the unposted elements. Navigate to Transactions > Purchasing > Batches, select the batch ID, and click Delete, confirming when prompted.

2. Run Check Links¶

To ensure data integrity, run Check Links on both the Payables Transaction logical files and the Payables History logical files. This helps to identify and correct any inconsistencies that might have resulted from the partial posting. As always, test this in a TEST company first and ensure a current backup if performing in your live environment. Access Check Links via Microsoft Dynamics GP menu > Maintenance > Check Links. Select Purchasing for the Series. Insert both Payables Transaction Logical Files and Payables History Logical Files into the Selected Tables list. Click OK, then choose a report destination.

3. VERIFY Posted Items¶

This is a critical verification step. You must confirm which items were actually posted correctly and which were not. Focus on the Apply information (which invoices were paid) and the Distribution information (which GL accounts were affected) for all Payables checks.

To verify this information using the Payables Transaction Inquiry - Vendor window:
* Go to Inquiry > Purchasing > Transaction by Vendor.
* Select the Vendor ID associated with the interrupted checks.
* Locate the relevant document, and then click the Document Number link to open the Payables Transaction Entry Zoom window.
* In this zoom window, click Apply to review the details of how the check was applied to invoices, credit memos, or returns.
* Then, click Distributions to examine the general ledger accounts that were debited and credited.
* Thoroughly verify that all information is accurate and complete for each transaction. This will help you identify what still needs to be processed.

4. Rebuild/Repost Unposted Checks¶

After meticulously verifying the posted items, you need to rebuild a new computer check batch, selecting only those invoices that still have an “OPEN” status and were not successfully posted in the previous, interrupted run.

• When rebuilding the batch, pay close attention to the check numbers. You will likely need to align the new batch’s check numbers with the numbers on the physical checks that were already printed but not fully posted. This may involve temporarily enabling Allow duplicate check numbers via Cards > Financial > Checkbook.
• It might be necessary to process vendors one at a time or by a specific range to ensure the correct check numbers align with the specific vendors.
• Determine the exact check number you need to “start” on for the unposted checks.
• Proceed with the check run. Update the check number as needed to match your previously printed physical checks. Then, “Print” the checks to the screen or to blank paper, as you did in Method 2, to update the system records.
• After printing, carefully review the batch to ensure the check numbers and vendor IDs align perfectly with what was previously printed. If all is correct, then you can Post the batch.
• Perform a final review for accuracy after posting.

5. Verify GL was Updated Correctly¶

After reprocessing, it is critical to ensure that the General Ledger accurately reflects all transactions.

• Missing GL entries: If any General Ledger entries are missing for the reprocessed checks, first check if there’s an unposted GL batch within Dynamics GP. If not, you may need to manually key a General Ledger entry directly under Transactions > Financial > General to correct the discrepancy.
• Duplicate Journal Entries: If you find duplicate Journal Entries (JEs) in GL, identify their JE numbers. Go to Transactions > Financial > General, select the CORRECT button, choose the original JE and year, and back out the duplicate entry. Alternatively, you can simply key an offsetting JE to reverse one of the duplicate entries.

6. Verify Bank Reconciliation was Updated Correctly¶

Finally, ensure that your bank reconciliation records are accurate.

• Review the CM20200 table (Cash Management transaction table) to verify that all checks, both initially posted and reprocessed, are present under the correct checkbook ID and without duplication.
• Duplicate checks in bank reconciliation: If checks appear duplicated in the bank reconciliation module, it is recommended to key an offsetting “increase adjustment” in bank reconciliation. This will increase your checkbook balance and typically updates GL. If you don’t want GL updated by this adjustment, ensure the GL batch is stopped and deleted, or consider using a “deposit without receipts” instead of an increase adjustment, as deposits generally do not hit the GL. Always add a clear note explaining the adjustment.

By following these detailed steps, you can methodically recover from an interrupted check run, preserving your financial data integrity and resuming your operations with confidence.

Have you experienced an interrupted check run in Dynamics GP? Share your challenges and successful recovery tips in the comments below!