How to Recreate the Reports.DIC in Dynamics GP
If you’ve been working with Microsoft Dynamics GP for any length of time, you’ve probably run into a corrupted or misbehaving Reports.dic file. Maybe a modified report stopped printing correctly, the file ballooned in size, or something just feels off after an upgrade. The good news: recreating Reports.dic is straightforward, and you don’t have to lose your customizations to do it.
Below are two reliable methods I still use today. Method 1 is the cleanest and is what I’d recommend in almost every case. Method 2 is handy when you can’t easily kick everyone out of GP.
Before you start: a quick word about Dynamics GP
Microsoft has announced the end of mainstream support for Dynamics GP, with security patches continuing only through 2028 and full end-of-life in 2031. If you’re still on GP, this guide will keep you productive—but it’s also worth thinking about what comes next. Many GP customers we work with are evaluating Dynamics 365 Business Central as their next step. If that’s on your radar, we’re happy to talk through it.
What is Reports.dic, and why recreate it?
The Reports.dic file stores all of your modified reports in Dynamics GP—everything you’ve customized in Report Writer. Over time it can become bloated or corrupted, especially after upgrades, network interruptions during saves, or when multiple users edit reports simultaneously. Recreating the file clears out the cruft while preserving the modified reports you actually use.
Always make a backup of Reports.dic before doing anything else. You’ll find its location listed in your Dynamics.set file.
Method 1: Export and re-import via Customization Maintenance (recommended)
This is the cleanest approach. It uses GP’s built-in package file format and brings everything back in one shot.
-
Make a backup copy of
Reports.dic. -
In GP, go to Microsoft Dynamics GP > Tools > Customize > Customization Maintenance.
-
Highlight all of the modified reports and click Export. Save the package file somewhere you’ll remember.
-
Have all users log out of GP.
-
Delete the
Reports.dicfile from its location on disk. -
Log back into GP and return to Microsoft Dynamics GP > Tools > Customize > Customization Maintenance. GP will create a fresh, clean
Reports.dicautomatically. -
Click Import and select the package file you saved in step 3.
That’s it. You now have a brand-new Reports.dic with all of your customizations intact.
Method 2: Rebuild through Report Writer (no full user lockout required)
If getting everyone out of GP is a problem—month-end, a busy AP run, you name it—Method 2 lets you do most of the work while users stay logged in. The trade-off is that you have to import each report individually.
-
Make a backup copy of
Reports.dic. -
Either delete
Reports.dic, or openDynamics.setand temporarily rename the path to something likeReports2.dic. The rename trick lets you avoid kicking users out for now. -
Log into GP and go to Microsoft Dynamics GP > Tools > Customize > Report Writer.
-
On the right side of the Report Writer menu, choose Import.
-
Browse to the backup copy of
Reports.dicyou created in step 1. -
Insert each report you want to bring over (unfortunately, this is one at a time).
-
Click Import to finalize.
-
If you renamed the path to
Reports2.dicin step 2, change it back toReports.dicinDynamics.set.
One thing to keep in mind: that final rename step in Dynamics.set usually does require everyone out of GP, so you’re often just delaying the lockout rather than avoiding it entirely. Still, for shops with sensitive timing windows, a planned five-minute rename is a lot easier than a longer maintenance window.
Which method should you use?
-
Use Method 1 when you can schedule a brief maintenance window. It’s faster, cleaner, and less error-prone.
-
Use Method 2 when you need to do the heavy lifting during business hours and only want a short lockout at the end.
A few practical tips
-
Document your modified reports. Before you delete anything, take a screenshot of the Customization Maintenance list so you can verify nothing went missing after the rebuild.
-
Test a couple of key reports immediately. Run a check stub, an AP edit list, or whatever your users rely on most—right after the import—so you catch issues before anyone else does.
-
Keep the package file. The exported
.packagefile from Method 1 is a great periodic backup of your report customizations. Store it with your other GP recovery assets. -
Watch file size over time. A
Reports.dicthat keeps growing unexpectedly is often a sign it’s time to rebuild again.
Thinking beyond GP
Maintenance tasks like this are part of life with Dynamics GP, and they’ll continue to be for as long as you run it. But if you find yourself doing more troubleshooting than reporting, it may be time to evaluate whether GP is still the right fit for your business. At eIS Business Solutions, we help finance and operations leaders weigh their options—staying on GP, modernizing to Dynamics 365 Business Central, or exploring other ERP paths—based on what actually serves the business. If a conversation would help, reach out anytime.