QAD 2017 Enterprise Edition > Installation-Conversion > Conversion Guide > Pre-conversion > Run Pre-conversion Utilities > Pre-conversion Integrity Report (gpinckrp.p)
  
Pre-conversion Integrity Report (gpinckrp.p)
This report assesses the status of financial transaction data before conversion. It reports AR, AP, and GL transaction integrity information in a single report.
You cannot correct all of the highlighted inconsistencies. Where possible, the necessary tools are noted in the section for each applicable area.
The report is not intended to highlight issues that require correction before conversion. It is used with the Post Conversion Integrity Check (36.16.23.3, acinckrp.p) in the Enterprise Edition Financials after conversion to substantiate that the conversion did not alter the integrity of the financial data. See Post Conversion Integrity Check (36.16.23.3, acinckrp.p).
The report output file name is gpinckrp-dtl-<dbname>-<date>_<time>.prn or gpinckrp-sum-<dbname>-<date>_<time>.prn.
Setting Build Integrity Check Records to Yes stores data in the database for the current report execution, enabling later reproduction of the report showing the same information. Anytime the status of the database is required, set this field to Yes. Set this field to No to run the report using the data collected from a previous execution.
Report Integrity Check Records displays the information collected during the first step. This field is usually set to Yes.
For eB2.1 or later, the reports span all active domains regardless of the domain where they are launched.
If data is corrected, run this report again to capture an accurate pre-conversion snapshot. Rerun this report as many times as necessary.
AR Transaction Integrity
This portion of the report compares the sum of open AR invoices and payments by account to the sum of the corresponding amounts for each AR GL account. It reports any differences in the local and/or transaction currency amounts. The report also lists any non-AR GL transactions posted against an AR control account. Finally, the sum of open AR invoices and unapplied payments by customer is compared to each customer’s Open Balance in Customer Maintenance, reporting any differences. You can correct differences by running the Adjust Customer Balance Utility (36.25.5, utcsbal.p).
It also performs various database integrity checks:
The customer referenced on each invoice still exists.
Every invoice has detail line information.
AP Transaction Integrity
This portion of the report compares the sum of open AP vouchers by account to the sum of the corresponding amounts for each AP GL account.
It reports any differences in the local and/or transaction currency amounts. The report also lists any non-AP GL transactions posted against an AP control account. Finally, the sum of open AP vouchers by supplier is compared to each supplier’s Open Balance in Supplier Activity Inquiry, reporting any differences. You can correct differences by running the Adjust Supplier Balance Utility (36.25.4, utvdbal.p).
It also performs various database integrity checks:
That the supplier referenced on each voucher still exists.
That every voucher has detail line information.
GL Transaction Integrity
The totals of posted GL transactions by account in the General Ledger Transaction History (gltr_hist) table are compared to the amounts stored in the Account Balance (acd_det) table. Differences are reported and can be corrected by running the Recalculate acd_det Totals Utility (36.25.39, utacdfix.p).
Warning Running the Recalculate acd_det Totals Utility in a database containing consolidated GL transactions zeros-out the period totals for all periods other than the consolidation period.
Any out-of-balance transactions are reported because the conversion must balance them by creating offsetting entries. If the database contains GL transactions consolidated using selected accounts, run the report in Summary mode, which verifies that the transactions are in balance for the year, not by individual transaction.
It also performs these database integrity checks:
That the entity in each GL transaction still exists.
That the account for each GL transaction still exists and is active.
That all effective dates for GL transactions have corresponding periods in the GL calendar.
If any of these types of errors are reported, fix them manually before beginning the conversion.