23 October 2011

Weekly Dynamic: PM Keys Corruption and econnect

Ok this one is a little complicated. In the GP interface when you open a Payables Transaction it reserves a voucher number. Once the voucher is saved the number can’t be reused. If the voucher is discarded, GP will reuse up to 1,000 numbers back and properly manage the numbers to avoid wasting discarded voucher numbers.

If this gets screwed up you get duplicate PM_Key errors.The fix is easy enough, run checklinks on Payables and increase the next voucher number in Payables setup.

image

But we ran into a scenario where this kept recurring and it seemed to be related to an integration but we couldn’t pin it down. We sent the details off to Microsoft and they figured it out.

GP manages the next voucher and econnect also manages the next number. What seems to have been happening is:
  • A user would reserve an voucher number in AP
  • An econnect based integration would bring in more than 1,000 payables transactions.
  • The user would discard their voucher and release the voucher number 
  • GP would then reset the next voucher number to the discarded voucher resulting in duplicate PM Keys and our error.
The kicker is the 1,000 record limit. This seems to be hard coded in GP.  If this happens with an integration of less than 1,000 records, GP works correctly. Additionally, in our scenario, the main AP processing takes place on the east coast and many of the large AP integrations are run from a west coast office. This means that often the timing of the integrations worked to prevent this error. That’s why it was so sporadic.

Microsoft doesn’t have a great fix, don’t run large econnect integrations while processing AP or keep AP integrations below 1,000 records.

We chose to manage AP voucher numbers ourselves via econnect and not use the econnect process to get the next voucher number.