Payables Management History missing after processing a payment in Microsoft Dynamics GP

Are you missing any Payables Management History after a successful payment posting in Microsoft Dynamics GP?

Recently I have had a few support cases with this same unexpected result so I thought I'd shed some light on a possible cause to help others that may run into this odd situation down the road.

In my casework the end users had been processing payments in the Select Checks/Build Checks windows in default Dynamics GP and the resulting historical records were no longer in the system for review after the posting had completed as they were completely missing from the Historical PM SQL tables.

After insuring the end users were not removing data selectively via the Purchasing Remove Document History utility and there were no absolutely no errors generated with the process, I knew this was going to be difficult to solve.  As such, it took much troubleshooting to determine a cause.

What we finally determined was occurring was that the Connection option of 'XACT_ABORT' had been checked as an active property in the SQL Server housing the erring Dynamics GP application.

To access the Server Properties window, right-click the top SQL instance icon in SQL Server Management Studio and select 'Properties':

https://docs.microsoft.com/en-us/sql/t-sql/statements/set-xact-abort-transact-sql?view=sql-server-2017

When processing payments in Dynamics GP an expected Primary Key (PK) error is generated after an insert to the PM30300 (PM History Apply) table during the data move to the PM history series. 

Having the XACT_ABORT setting intact will cause the process to terminate once the PK error occurs and as a result the transaction data does not move to the PM30200 (PM History) but will be vacant from the system as it has already been removed from the PM20000 (PM Open) series accordingly.
Because this Primary Key error is expected it is not displayed to the end user as an issue nor is there any sort of error generated on the Dynamics GP side to indicate there was a problem on the SQL side.

Once we unchecked this SQL setting and rebooted the SQL Server instance in our next testing the Dynamics GP payments saved the payment history without issue.

As there is also no default action in Dynamics GP that would cause such a setting switch, at some point it would have needed to be either turned on manually or by a SQL process outside of the Dynamics GP application accordingly.

In closing, if you do run into this issue in future payment processing in Dynamics GP the very first place to look would be the XACT_ABORT SQL setting outlined above:

- If the option is checked it is most likely the cause and unchecking it and rebooting the server should resolve this performance as outlined.

NOTE: If the community has any information as to why their XACT_ABORT setting was enabled (due to a SQL maintenance, 3^rd party code, performance recommendation, etc.) please feel free to comment below.

- If it is not checked then I hope to be the support case resource digging into this performance as a next troubleshooting step.