Dynamics Community Forum Thread Details

I have had an incident with Microsoft and we tried many things to attempt to resolve this issue.

TrackingID#2602180010001147

Here is what we tried:

Unfortunately, this issue continues to plague the GP database and we need it resolved.

I have been using self-created SQL scripts to

1) Apply the CRM to an invoice

2) Migrate the CRM and/or invoice to history

As you may be aware, this is very complex depending on if the invoice or CRM is in history or open tables.

Many tables and values are at play here and my client is not happy with having a consultant manually apply CRM's to invoices ... especially since Microsoft was assisting with this resolution.

Let me know if this is a common issue amongst GP users?

For the remaining Credit Memos (CMs) that still cannot be applied, the "lock" likely exists in one of the auxiliary tables used to manage transaction status and applications. Below are the details of the batch posting sequence and the specific tables you should validate to ensure the data cleanup is 100% complete.

Standard Posting Sequence (Work to Open)

When a Payables batch posts, the system performs these steps in a specific order. If an interruption occurs (like the July update), the sequence breaks, leaving "orphaned" records in the earlier tables or incorrect status flags in the later ones.

Status Check: The system verifies the batch is not locked in SY00500 (Batch Master) and SY00800 (Activity).
Move to Open: Data is "pasted" from Work tables (PM10000, PM10100) into the Open table (PM20000).
Keys Update: The Master Keys table (PM00400) is updated to change the document status from 1 (Work) to 2 (Open).
GL Integration: Distributions are written to the General Ledger tables (GL10000/GL20000).
Cleanup: The system deletes the original records from the Work tables and clears the BACHNUMB and BCHSOURC from the Open records.

Final Cleanup Checklist for "Stuck" CMs

If a CM is in PM20000 with a blank BACHNUMB but still won't apply, please validate these four areas:

1. The Keys Master (PM00400)

This table is the "traffic controller." If the status here is wrong, the CM will not appear in the Apply window.

Validation: Ensure DCSTATUS is 2 (Open). If it is 1, the system thinks it is still an unposted "Work" transaction.
Script: SELECT DCSTATUS, * FROM PM00400 WHERE CNTRLNUM = '[Voucher_Number]'

2. Orphaned Apply Records (PM20100)

If a CM was partially applied or selected in a previous "ghost" session, a record might exist in the PM20100 (Apply Open) table. This "claims" the CM, making it unavailable for new applications.

Validation: Check if the affected CM's Voucher Number exists in this table as either the APTODCNM or APFRDCNM.
Action: If a record exists for a session that no longer exists, it should be removed.

3. Activity Locks (SY00800 & SY00801)

Even if the batch appears gone, a SQL-level lock might still be tied to the User ID or the Batch ID.

Validation: Search for any records tied to the problematic batch name or the users who were posting during the July update.
Script: SELECT * FROM DYNAMICS..SY00800 WHERE BACHNUMB = '[Batch_Name]'

4. Document Amount Mismatch (PM20000)

Ensure the CURTRXAM (Current Transaction Amount) is exactly equal to the DOCAMNT (unless it was legitimately partially applied). If CURTRXAM is 0.00, the system considers it "fully applied" and will not show it in the Apply window.

Great catch on the BACHNUMB field. That is undeniably the "smoking gun."

In the Payables logic, a record in the PM20000 (Open) table should only have a populated BACHNUMB if it is currently being edited or sitting in an unposted payment batch. If a posted Credit Memo still carries a batch ID, the system treats it as "reserved." This is why they look perfect in the data but remain "invisible" to the Apply and EFT/Cheque Generation windows the application is essentially protecting them from being used twice.

Why this happened

The July 2025 tax table update likely caused an "interrupted posting" scenario. The transactions successfully moved to the Open table and updated the General Ledger, but the final "cleanup" trigger which clears the Batch ID failed to fire. Since then, these records have been stuck in a metadata limbo.

Recommended Resolution Path

To release these "ghost" records, we need to manually clear the BACHNUMB at the SQL level. Since your previous attempts with Checklinks and Reconcile didn't touch this specific metadata, a targeted script is the most direct path.

1. Verification Script

Before applying the fix, run this to confirm exactly how many records are affected:

SQL

SELECT VCHRNMBR, VENDORID, BACHNUMB, DOCAMNT, CURTRXAM
FROM PM20000
WHERE BACHNUMB <> ''
AND DOCTYPE = 5
AND VOIDED = 0;

2. The Fix (Update Script)

Note: Please ensure you have a fresh backup of the company database before running this update.

SQL

/* Clearing the batch lock to make CMs available for application */
UPDATE PM20000
SET BACHNUMB = ''
WHERE DOCTYPE = 5
AND BACHNUMB = '[Insert_Batch_Name_From_Report]'
-- Optional: Add VCHRNMBR filters if you want to test one record first

Next Steps

Once the BACHNUMB is set to an empty string (''), these Credit Memos should immediately populate in the Apply Payables Documents window and be available for your next EFT run.

Important Note: Always take a full backup of your SQL database before performing manual DELETE or UPDATE statements. Try this in your TEST environment.

Your prompt attention to this matter is appreciated. Please review the information above and share your feedback or any follow-up questions. Your insights are invaluable, and I’m eager to assist further.

Categories:

Microsoft Dynamics GP