Preview, apply and undo a fix

Problems GP itself leaves behind (after a crash, an interrupted posting or a lost connection) have a one-click fix. Nothing changes until an approver previews the fix and applies it, every row is backed up first, and every fix can be undone until something else changes those records (see Undo).

About 55 seconds, narrated, with captions. Sample company, made-up data.

The fixes

Check	Fix	Its rule
C01 Batches held by users who are logged out	Release batches held by logged-out users	Only rows for users who aren't logged in to GP right now are removed.
C02 Leftover record locks	Clear leftover record locks	Only locks whose session doesn't belong to a logged-in user are removed.
C03 Users stuck as logged in	Log out users stuck as logged in	Only users whose GP session no longer exists are removed. Someone really working is never touched.
C04 Stuck batches	Make stuck batches available again	Only batches that are just marked for posting, or show Receiving and haven't changed today, while nobody is logged in to the company. Nothing posts. A batch that may have started posting is left to Batch Recovery.
C05 Hidden unposted journal entries	Delete empty hidden journal entry shells	Only entries with no batch and no lines, so no amounts at all, are deleted, while nobody is logged in to the company.
C54 Batches that claim transactions they don't have	Remove batches that claim transactions they don't have	Only single-use batches with nothing in them, while nobody is logged in to the company. Only the empty batch header goes. A recurring batch keeps its guide.
C12 Sales next-number collision	Move the sales next number past the numbers in use	Only document IDs whose next number is already used. The new number keeps the same letters and digits, one past the highest in use.
C25 Sales lines with no document	Remove sales lines whose document no longer exists	Only lines with no unposted sales document of that type and number. Run Inventory Reconcile afterward.
C27 Sales document both unposted and posted	Remove the unposted copy (with its lines)	Only when the posted copy has the same customer, total and number of lines.
C28 PO lines with no purchase order	Remove purchase order lines whose PO no longer exists	Only lines with no open PO of that number. Run Inventory Reconcile afterward.
C31 Receipt both unposted and posted	Remove the unposted copy (with its lines)	Only when the posted receipt has the same vendor, subtotal and number of lines.
C16 Vendor document in open and history	Remove the open copy*	Only open copies with nothing left to pay, whose history copy has the same vendor, type and amount.
C21 Customer document in open and history	Remove the open copy*	Only open copies with nothing left to collect, whose history copy has the same customer, type and amount.
C10 Sub-penny open balances	Clear sub-penny amounts (customers, and vendors)*	Only open amounts under a cent; they become 0.00. Run the Sales or Purchasing Reconcile afterward.
C75 Amount remaining doesn't match the applications	Set the amount remaining to what the applications leave (customers, and vendors)*	Only documents with at least one application, none in both the open and history tables, where what's left is between zero and the document amount. It becomes the document amount less what's applied to it, with discounts and write-offs (for a payment or credit, less what it applied).
C75, in another currency	The amount remaining in your company's currency (the fix above), and the amount remaining in the document's own currency (customers, and vendors)*	Only where the math is certain: the document's multicurrency record is complete and its amount is the document's at the exchange rate, every application is in the same currency with no realized gain or loss, and the two amounts remaining agree at the rate, allowing a cent for each rounding GP did. Run the Sales or Purchasing Reconcile afterward.
C75, with no applications at all	Set it to the full amount (an apply was removed): customers, and vendors, in your company's currency and in the document's own currency*	Only documents not voided with nothing applied to or from them, showing more than zero and less than the document amount. GP can't tell whether an application was removed without putting the amount back, or an earlier conversion or integration loaded the balance this way. If an application was removed, this fix makes the amount remaining the full document amount. If the balance was loaded this way, GP's figure is right: choose Mark as expected on the row instead. Nothing happens on its own: an approver picks one. In another currency, only when the document's multicurrency record is complete and its amount is the document's at the exchange rate; otherwise the row has no fix. A document GP shows fully paid with nothing applied is taken as closed and isn't listed. A move to Sage Intacct takes what GP shows when it goes: a document still listed goes over at GP's amount remaining, and your partner gets a warning that names this check.
Vendor balance doesn't match open documents	Rebuild vendor balances from their open documents	Only vendors with a vendor card. The current balance becomes the total of the vendor's open documents (invoices, finance and misc charges, less returns, credit memos and payments; voided ones left out). The period and year-to-date amounts on the vendor's summary aren't touched: GP's Purchasing Reconcile rebuilds those.
Customer balance doesn't match open documents	Rebuild customer balances from their open documents	The balance becomes the total of the customer's open documents (invoices, debit memos, finance charges, service and warranty, less credit memos, returns and payments; voided ones left out). The aging buckets refresh at the next aging; GP's Sales Reconcile rebuilds the period amounts.
Trial balance summary doesn't match detail	Rebuild open-year period summaries from posted detail*	Only periods 1 and up in an open year, with one summary row and every line in the base ledger. Their debits, credits and period balance become the posted detail's totals, to the cent. Beginning balances (period 0, which GP keeps as gross prior-year totals), history years, a summary row that's missing, and multicurrency summaries are left to GP's Financial Reconcile.

* These change posted data. They're refused in closed periods and years (see Fixes and closed periods), and they only work once your SQL Server administrator has run usp_grant_amount_fixes, so it's your decision to allow them.

When a record doesn't meet a fix's rule (a document with an amount still open, say), the preview says a person needs to look at it.

When GP has its own tool

Where Microsoft provides a tool for the job, the check says which one and where to find it, and Ledger Doctor doesn't do it itself:

Batch Recovery for batches stuck partway through posting (resetting one by hand could post it twice).
Check Links for transactions with no batch, and for voided documents still open.
Reconcile (Financial, Purchasing, Sales) for what the summary rebuilds above leave out: beginning balances, history years, period and year-to-date amounts, and summary rows that are missing.
Paid Transaction Removal, Reconcile Purchasing Documents, Reconcile-Remove Sales Documents and Fixed Assets Reconcile.
User Access Setup for users missing from DYNGRP, unless an admin adds them from Ledger Doctor (below).

Users missing from DYNGRP (admins)

GP gives its users their table permissions through the DYNGRP role in each company database. A user who's missing from it gets permission errors. In GP you fix that one user at a time, by clearing and reselecting the company in User Access Setup. A Ledger Doctor admin can do it from the issue's page instead:

Open the issue on the Health page. Admins see Add these users to DYNGRP, listing the GP users who have access to the company and whose database user isn't in the role right now. A user GP no longer lists can't be added; set them up in GP first.
Tick the users to add and choose Add to DYNGRP. Ledger Doctor asks first, naming them. It checks again before it changes anything, and if anyone on the list no longer qualifies, nothing changes.
Only their DYNGRP membership changes: nothing else about their GP or SQL Server security. It's recorded in the security log with who did it, and the page lists each time with an Undo that takes those users out of the role again.

Ledger Doctor's own SQL login can't change roles. Your SQL Server administrator turns this on once by running EXEC LedgerDoctor.dbo.usp_grant_dyngrp_fix; in SQL Server Management Studio as a sysadmin, so it's your decision to allow it. That signs one Ledger Doctor procedure with a certificate that may change only the DYNGRP role in each GP company, and then throws away the certificate's private key, so nothing else can ever use it. Run it again after you add a GP company. Setup never runs it.

Preview

On the health dashboard, choose Preview fix on the issue.
Under Records found, each record has a Fix? box, checked to start with. Uncheck any you don't want included. (Clearing record locks has no boxes: it works on every leftover lock at once.)
Choose Preview fix. Ledger Doctor checks GP again right now and lists exactly which records will change, like "2 records will be removed". Records that no longer meet the fix's rule are left out.

Anyone can preview. If none of the records can be fixed, the preview says they need a person to review them.

The preview also says when something stops the fix right now, and Apply stays off until it's sorted:

Someone is signed in to the company in GP. Most fixes wait until nobody is, so nothing changes under someone entering or posting. The preview still lists the records the fix would change, and names who GP shows as signed in, by GP user ID; Apply stays off until everyone has signed out of that company. If GP lists someone who isn't really working, check C03 (users stuck as logged in) and clear them with its fix first.
Ledger Doctor's SQL login doesn't have the access the fix and its undo need. A fix is never applied if it couldn't be undone. The preview names what's missing, like "INSERT on DYNAMICS.dbo.SY00800", and the procedure your SQL Server administrator runs to give it: EXEC LedgerDoctor.dbo.usp_grant_access; (running Ledger Doctor's setup again does the same), or EXEC LedgerDoctor.dbo.usp_grant_amount_fixes; for the fixes that change posted data. Add @company = N'TWO' (your company's database name) to either one to turn fixes on for that company only; the preview shows the line with the company filled in. A one-click update can't refresh these itself, because it doesn't run as a SQL Server administrator. Setup gives access to GP's housekeeping tables (batch headers and the user, batch and resource activity tables) up front, so new fixes on those work right after an update; for anything else, the Health page shows which fixes are waiting, with the line to run and a message you can copy to send.

When fixes are turned off

Ledger Doctor's own procedures in its SQL database are installed encrypted, and its fixes run only while those procedures and its fix rules are exactly what setup installed. If someone changes one in SQL Server Management Studio, the fix panel says what changed and fixes stay off until Ledger Doctor's setup runs again, which reinstalls them. Scans and everything else keep working. If nobody at your company changed it, ask whoever has SQL Server administrator access.

Apply

As an approver, choose Apply fix, then confirm: Ledger Doctor asks first, and says so when the fix changes posted amounts. In one step, Ledger Doctor backs up the rows to its own database, removes or changes them, and checks that exactly the previewed rows changed. A fix that changes a value shows each new value in the preview, in the columns ending in "after". If anything differs, for example someone logged back in since the preview, nothing changes and you're asked to scan again. When it's done, the page says what to do next in GP, and the check runs again.

A processor can preview a fix and choose Ask an approver to apply it; it then waits under Needs approval. They can say why they're asking; the approver sees it. An approver can turn a request down with one click, and can say why first. The issue page shows the latest request for each fix with both reasons, so whoever asks again can say what changed, and the approver sees the earlier turn-down beside it. Fix history shows why each applied fix was asked for. Once Security is on, a fix that changes posted amounts needs two different approvers: the first approval waits, and the second applies it. See the approval rules.

Undo

Before you apply a fix, its confirmation says what undo can do. Undo is refused, and nothing changes, when:

a fix changed posted amounts and a period it touched has been closed since (the confirmation for these fixes is highlighted and says so);
GP or someone has changed the same records again, for example the batch a fix released has posted since;
someone is logged in to the company in GP (try again once they're out).

A fix that couldn't be undone at all would say so in red, with a red button and an "I understand this can't be undone" box to tick first. None of today's fixes are like that.

Right after a fix, an Undo button puts the rows back, or the old values. Later, open Health in the menu and choose Fix history: it lists every fix with when, its name, the table, how many rows, who applied it, and what to do next in GP. Approvers can choose Undo on any fix that hasn't been undone, and confirm. A fix can only be undone once: a second click, or two people at once, gets "That fix was already undone".

Rows a fix removed come back with new GP row IDs (DEX_ROW_ID) unless Ledger Doctor's login may set them, which it normally can't. GP doesn't depend on them.