When doing the Account Combiner from the Professional Services Tool received this error message.
[Microsoft]SQL Server Native Client 10.0 [SQL Server] Violation of PRIMARY Key constraint 'PK_OSRAcTr_39B61B6A5828F04'.
Cannot insert duplicate key in object 'dbo.OSRAcTr'. The duplicate key value is (1039, 2013, 1, Open, ACQDB) [MIcroosft]SQL Server
The database that is referenced is a historical company database at this time. After clicking OK on the message I was prompted to do reconcile on the Year(s)
Any suggestions on what would be the best way to identify the duplicate records?
Regards,
Kevin
*This post is locked for comments
Kevin,
I ran into a similar issue with a different 3rd party product table.
Investigating the values in the database led me to understand the table contained records which produced duplicates when accounts were combined. The table OSRAcTr is part of a 3rd Party product called OneStop Reporting (OSR).
The error message you included contains the values 1039, 2013, 1, Open and ACQDB.
An educated guess is that 1039 is an account index, 2013 is a year, 1 is a code specific to OSR and Open means 2013 is an open year and ACQDB is likely a database ID for one of your companies.
So Account Index 1039, likely corresponds to one of the GL Accounts you are trying to combine. You can find the Account Number String in the GL00105 that corresponds to account index 1039.
OSR Tables correspond to numerous Dynamics GP tables. Here's a short list:
Budget Model: GL00200 -> OSRBgt
Budget Transactions: GL00201 -> OSRBgtLn
Segment Data: GL40200 -> OSRSegValue
GL Account String Data: GL00100 -> OSRAc
GL Account Category Data: GL00102 -> OSRAcCat
GL Summary Transaction Data: GL10111, GL10110 -> OSRAcTr
GL Detail Transaction Data: GL20000, GL30000, GL10001 -> OSRAcTrDetail
Refer to the following link, the source of the above information:
products.onestopreporting.com/.../OneStop%20Reporting%20Multi%20Company%20Loading.pdf
My suspicion is even if you get past this error you may encounter more.
My suggestion would be as follows: If it is possible to disconnect OSR from Dynamics GP while you are making these changes, you should be able to successfully make the changes. Then you could reconnect OSR and recreate the OSR reporting datamart.
Please let me know if you require further assistance with this issue.
Errata: Account Number field rather than Customer Number :)
Hi,
Looks like a 3rd-party table that has a CUSTNMBR field in it.
Try disabling it and see if the issue persists.
Hello Kevin,
As the OSRAcTr table or object is not a Dynamics GP object, but that of some third-party vendor, we would need to either refer to the vendor that supplies that object, or remove the third-party product from Dynamics GP if it isn't actually used any longer.
I did find two cases with this object name and issues with PSTL, so chances are this vendor knows about this issue and may have a resolution already for it.
Thank you,
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
André Arnaud de Cal... 291,240 Super User 2024 Season 2
Martin Dráb 230,149 Most Valuable Professional
nmaenpaa 101,156