Skip to main content

Notifications

Announcements

No record found.

Microsoft Dynamics GP (Archived)

Penny discrepancy on one account

Posted on by Microsoft Employee

We have an account that has had a 1 cent overpayment showing on the reports (both built in and the SSRS reports) since 2011 (it was just pointed out me today). Normally when there is a discrepancy the accounting dept. just makes an adjustment in GP Dynamics and all is good - however, in this particular case any attempt to make the normal adjustment comes with a response from GP that there are no overpaid or unbalanced documents to apply against. I have checked in the database and can see the entry in both tables RM30101 and RM30201 for $55.76 (should have been $55.75) and can see the document trail the reports are building from which does confirm the 1 cent discrepancy - not sure why GP says there isn't anything to apply against. Has anyone else come across this and if so what is the proper solution. (I would rather a solution that is run from within GP 2013 rather than one that involves directly meddling with the data in SQL - I have already tested changing the value in both tables indicated - but that yielded a broken report so I rolled them back to their original values - I assume there are other tables involved.)

*This post is locked for comments

  • Suggested answer
    Community Member Profile Picture
    Community Member Microsoft Employee on at
    RE: Penny discrepancy on one account

    Thanks Tristan. I will check out the list of tables you provided and see if I can manually tweak this out of the system - otherwise they can continue to live with it as they have for the past 2 years.

  • Verified answer
    Tristan Clores Profile Picture
    Tristan Clores 2,812 on at
    RE: Penny discrepancy on one account

    Hi Tharpur,

    Since the transactions involved are already in History (RM30101 and RM30201), GP will definitely find nothing to apply any overpayments to.  

    Normally, you can just use the RM Transaction Unapply tool (PSTL) to move the transaction involved from History to Open.  However, the problem here is the transaction is way back 2011.  Unless you haven't closed your years yet, this is a viable solution.

    The only option I can see here is to use SQL scripts to correct the data.  Now you mentioned that you tried this but came down to a broken report.  You are right, there are other tables involved.  You may need to check the following:

    RM30101

    RM30201

    RM30301

    GL30000 (if 2011 is historical)

    GL20000 (if 2011 is not yet historical)

    TX30000 (if taxes are involved)

    You'll need some extensive search on the accounts involved on the transaction and update accordingly.

    Please let me know if you have further questions.

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

Quick Links

December Spotlight Star - Muhammad Affan

Congratulations to a top community star!

Top 10 leaders for November!

Congratulations to our November super stars!

Tips for Writing Effective Suggested Answers

Best practices for providing successful forum answers ✍️

Leaderboard

#1
André Arnaud de Calavon Profile Picture

André Arnaud de Cal... 291,269 Super User 2024 Season 2

#2
Martin Dráb Profile Picture

Martin Dráb 230,198 Most Valuable Professional

#3
nmaenpaa Profile Picture

nmaenpaa 101,156

Leaderboard

Featured topics

Product updates

Dynamics 365 release plans