Mark Polino's Blog, page 309
October 24, 2011
FRx Error 5 An Invalid character was found in text content
Francisco Hillyer feels special with FRx Error 5 An Invalid character was found in text content
[image error]
[image error]
Updating the Year stamp on the W4 in HRMSSS/Business Portal - Dynamics GP Support and Services Blog - Site Home - MSDN Blogs
From the Dynamics GP Support and Services Blog comes help with Updating the Year stamp on the W4 in HRMSSS/Business Portal
[image error]
The Dynamics Community Site: The Value of Interactions | MSDynamicsWorld.com
Andy Leapaldt, writing at MSDynamicsWorld.com, looks at The Dynamics Community Site: The Value of Interactions
[image error]
October 23, 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.
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.
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.
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.
October 20, 2011
FRx Error 988672
Francisco Hillyer addresses "FRx Error 988672 Access denied because another caller has the file open and locked."
