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

Notifications

Announcements

No record found.

Community site session details

Community site session details

Session Id :
Microsoft Dynamics GP (Archived)

Print Remit To Address Information Associated with Voucher on Check

(0) ShareShare
ReportReport
Posted on by 894

Hello,

Is anyone aware if you can print information from the Address ID that is set as the 'Remit To' address for a voucher on checks being printed?  We are currently using Mekorma MICR in our check process.

Quick background on the request

We have vendors who occasionally have multiple assignees who have to sign for a check.  To do this, we wanted to use the native GP functionality of using different Remit To address IDs in the payable transaction to automatically create separate checks. 

Ie.) John AND Mary are REMIT1 while John AND Billy are REMIT2.  When Remit1 is used, Payable to John AND Mary is printer; REMIT2 - Payable to John AND Billy.

There is an option in MICR to print the 'Contact Name' which is a step in the right direction, however, this pulls the contact name from the primary address in the vendor setup, not the contact name associated w/ the Remit To ID of the transaction.

Thanks in Advance.

*This post is locked for comments

I have the same question (0)
  • Heather Roggeveen Profile Picture
    9,146 on at

    Hi

    I can't speak for MICR - but I would have thought that in the GP standard reports you could pull the details from the Remit To address, otherwise it doesn't seem to make any sense to have it.

    Cheers

    Heather

  • Suggested answer
    Beat Bucher  GP Geek  GPUG All Star Profile Picture
    28,058 Moderator on at

    Hi Kyle,

    We do use MICR for many years now and I ran across a similar issue, though not related to check printing, but requisition / procurement... the ISV product we use was reading the ship-to / contact information from the defaulted one in the vendor card, not the one that was identified as PRIMARY or SHIPTO, so sometimes it was the REMIT-TO card that was defaulted, because the AP person would do this to be able to print a check correctly in MICR :-)... thus not aware that the requisition system would then pull the wrong ship-to address...

    I'd call this just bad programming.. but you know, sometimes developers are taking shortcuts in the application creation and don't challenge themselves about all the options...

    With a product like GP, there are so many possibilities, that I can understand the difficulty of covering all, but sometime enough is just not enough. What makes the game even more difficult is the fact that GP offers so many open doors to play with the information (read free-field data), that nothing forces you actually to call your vendor / customer cards PRIMARY or REMIT-TO... :-)

    I worked with a MfG company where the cards were names by store locations...

  • kmalone43 Profile Picture
    894 on at

    Thanks for the responses.  Makes complete sense.  We found that if we were using normal Report Writer that we'd be able to pull this information no sweat.  With MICR, we're a little more restricted on what we pull (can only pull 'elements' defined by MICR in the template) & unfortunately cannot pull the contact name from the Remit To address.  

    The closest bit of information in Mekorma MICR is the Vendor::Payment Address element which only lists the Address 1, 2, 3 City & state fields.  

    There's the Vendor::Vendor Address with Contact Name field that lists all of the information that we're seeking but pulls from the vendor setup and not the voucher being paid.

    We've put in a request for Mekorma to add Vendor::Payment Address with Contact Name to future builds.

    In the meantime, we're going to work around the issue and utilize the 3 address fields instead of the Contact Name field.

    Thanks again.

  • Suggested answer
    Beat Bucher  GP Geek  GPUG All Star Profile Picture
    28,058 Moderator on at

    Yes.. that's almost all you can do.

    I usually work closely with the ISV to provide them suggestion for product improvement, and depending on the interest from other customer, they might include it there next release.. or not. Often they will try to get someone pay for it :-), so they agree to do the customization for some $$$ in exchange for the dev time.

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

Responsible AI policies

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

Neeraj Kumar – Community Spotlight

We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…

Leaderboard > 🔒一 Microsoft Dynamics GP (Archived)

#1
mtabor Profile Picture

mtabor 1

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans