web
You’re offline. This is a read only version of the page.
close
Skip to main content
Community site session details

Community site session details

Session Id :
Dynamics 365 Community / Forums / Microsoft Dynamics GP (Archived) / Manual Check Printing ...
Microsoft Dynamics GP (Archived)

Manual Check Printing Error Message

(0) ShareShare
ReportReport
Posted on by Kmalcolm 110

When trying to print manual checks in GP I encountered an error message that read "  A get/change operation on table ME_CHECK_SETUP failed accessing SQL data".   This is preventing me from cutting manual checks.  Please advise on what I have to do to correct.  Thanks

*This post is locked for comments

I have the same question (0)
  • Community Member Profile Picture
    Community Member on at
    Re: Manual Check Printing Error Message

    Hi, I haven't seen this error before but one possibility is that your reports.dic is corrupted. Most likely your manual cheque layout is customised.  If you rename your reports.dic (to say reports.dictodaysdate), and then launch GP and open the report writer, then try and import the manual Cheque report. If it imports successfully, try and print your cheques again.

     

  • Stephen Schilling Profile Picture
    Stephen Schilling 10 on at
    Re: Re: Manual Check Printing Error Message

    This is actually an error related to Mekorma MICR, a 3rd party check printing product.  Im thinking you may not have set up the security to allow access to the tables. If you're on GP 10 youll need to do the following:

    Administration tab
    Tasks -> Create a task named MICR, category of Other, and find Mekorma MICR for the product. Go thru each series and file type and click 'Mark All' to check each.  IE  Windows (Financials, Payabales, etc) and Files Access (Financials, Payables, etc).

    Roles -> Create a role named MICR and select the MICR task to be a part of the role

    User Security -> Select the user and company you want to give access to, and check the MICR role to give access

    Alternatively, logging in as 'sa' should should the problem without doing any of this as it, by default, has access to all SQL tables.  However, this might not be a good idea long term. Hope that helps!

    -Steve

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

News and Announcements

Join experts in person to explore low code and AI agents at the Power Platform Community Conference sponsored by Microsoft

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Abhilash Warrier – Community Spotlight

We are honored to recognize Abhilash Warrier as our Community Spotlight honoree for…

Congratulations to the September Top 10 Community Leaders!

These are the community rock stars!

Leaderboard > 🔒一 Microsoft Dynamics GP (Archived)

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans