ERP Production Data Fix Request Template
Sometimes the only way to repair bad ERP data is a SQL update. When that happens, you need a record that shows what was wrong, what was run, how it can be undone and who agreed. This template is that record.
Fill in
ERP Production Data Fix Request Template
Production Data Fix Request
Ticket: CHG-20418 System: SyteLine PROD, database Acme_App Script author: Daniel Okafor
Problem and root cause
Problem: 212 item-warehouse rows carry a negative on-hand quantity after a failed cycle count import. Planning shows false shortages.
Root cause: Import template wrote the count as a delta instead of an absolute quantity.
Change details
Expected rows affected: 212 Script summary: UPDATE on the item-warehouse table inside a transaction, joined to a staging table of corrected quantities. Row count asserted before commit. Execution window: 2026-10-24 19:00 to 19:30, no users on inventory transactions
Safety net
Backup method: Table copy to backup schema
Rollback plan: Restore the affected columns from the backup table using the primary key. Rollback script tested in TEST on 2026-10-22.
Pre and post checks
| Step | Expected | Actual | Initials |
|---|---|---|---|
| Run SELECT with same WHERE clause | 212 rows | ||
| Script tested in non-production copy | Pass | ||
| Backup verified readable | Pass | ||
| Rows affected after UPDATE | 212 | ||
| Business check on ERP screen | Values correct | ||
| Dependent jobs and integrations checked | No errors |
Approvals
Direct database edits can bypass ERP business logic, audit trails and validations. Prefer an ERP supported import, API or utility where one exists, and check your vendor support terms. This is a starting template, not legal or vendor advice.
Stop repeat data defects
Optional: an expert look at the interface or import that keeps creating the bad rows you are patching.
Optional. The tool and every export work without this. No spam.
How to use the template
Complete the form before the script is run, not after. Write the problem and root cause plainly, state the row count you expect, and describe the backup and rollback in enough detail that a colleague could execute them at 2am. Export it as PDF and attach it to the change ticket. Fill in the actual column of the checks table during execution.
The control that matters most: expected row count
The single best protection against a bad UPDATE is a SELECT that uses the identical WHERE clause and returns a known count. Run it first, compare to the expected rows, then run the UPDATE inside a transaction and assert that the affected rows equal the same number before committing. A script that touches 21,200 rows instead of 212 is caught in seconds.
- Wrap the change in an explicit transaction
- Never run a script without a WHERE clause review by a second person
- Keep the backup table until the next period close
- Record the actual rows affected on the form
ERP specific cautions
ERP tables often have companion tables, audit columns, row version stamps and cached summaries. Updating one table directly can leave inventory balances, costing layers or workflow state inconsistent. Check whether your ERP offers a supported utility for the correction, and test the effect on screens and reports in a copy of production first.
Common mistakes
The usual failures are no backup, a rollback plan that was never tested, scripts run by the author without review, and fixes applied during peak transaction hours. Another is fixing the symptom repeatedly without closing the import or interface that created the bad data in the first place.
Frequently Asked Questions
Is it ever acceptable to update ERP tables directly?
Sometimes, when no supported utility exists and the vendor allows it. It should be rare, reviewed, backed up and recorded. Always check the vendor support policy, since direct edits can affect supportability.
How long should I keep the backup?
At least until the next period close and any audit cycle that touches the affected data. Many teams keep it for 30 to 90 days. Follow your own retention policy.
Do I need a peer reviewer for a small fix?
Yes. A second pair of eyes on the WHERE clause is the cheapest control available. Even a ten row fix can become a ten thousand row mistake with one missing condition.
What if the rollback fails?
That is why the rollback is tested in a non-production copy and the backup is verified readable before the change. If both fail you fall back to a full database restore, so know that recovery time in advance.
If the same data defects keep returning, we can review the source of the bad data and, where it makes sense, help you build a read-only monitor that flags them before planning sees them.
Related Tools
ERP Data Request Form Template
A fill-in form that turns a vague 'can you pull me a report' email into a complete, approvable ERP data request.
ERP OperationsERP Database Read-Only Access Request Form
A scoped, time-boxed request for a read-only SQL login or reporting role on an ERP database, with owner approvals.
Developer ToolsSQL Query Tuning Log Worksheet
A tuning log that records the change, before and after runtime and logical reads, and calculates percent improvement.
Developer ToolsERP SQL Query Catalog Worksheet
An editable inventory of the queries and reports your team runs, with owner, frequency, runtime and monthly effort.