QuickBooks for Wild Apricot - Never miss an entry and have peace of mind knowing your books are always up-to-date with accurate transactions. Reduce stress and errors with automated, categorized entries from Wild Apricot to your QuickBooks accounts.
TCM had an issue where a Payment did not get created inside QBO as a result of a "false duplicate customer" error. This occurred for a customer that had an apostrophe in their name: O’Neill, Connor
Background/analysis:
As seen in other QBO areas, quotes and carriage returns can cause issues. Logic has been used in several areas to remove the special characters and avoid errors.
Scenario with issue: WAQM-Txn-QBO
In this case, the QB Display Name has "replace" logic used to ensure escape characters are inserted as part of the SQL query that is used to search for existing characters. That logic did not work on the customer name and left an extra escape slash in place. As a result, the existing customer could not be found. (When a customer is created by QBWA, the QB Display Name is used without manipulation.)
In the scenario run, the result was 0 records found. With some ad-hoc testing in a separate support scenario, the query actually resulted in a execution error. Not sure why.
Scenario fix used for TCM and recommended for next version:
In the module that searches for existing QBO customers, change the module to use a specific field and search for the direct QB Display Name (as represented by the grouped Key of the previous aggregator).
In the ad-hoc testing scenario, this successfully found the existing customer and did not yield an error.
TCM had an issue where a Payment did not get created inside QBO as a result of a "false duplicate customer" error. This occurred for a customer that had an apostrophe in their name: O’Neill, Connor
Background/analysis:
As seen in other QBO areas, quotes and carriage returns can cause issues. Logic has been used in several areas to remove the special characters and avoid errors.
Scenario with issue: WAQM-Txn-QBO
In this case, the QB Display Name has "replace" logic used to ensure escape characters are inserted as part of the SQL query that is used to search for existing characters. That logic did not work on the customer name and left an extra escape slash in place. As a result, the existing customer could not be found. (When a customer is created by QBWA, the QB Display Name is used without manipulation.)
In the scenario run, the result was 0 records found. With some ad-hoc testing in a separate support scenario, the query actually resulted in a execution error. Not sure why.
Scenario fix used for TCM and recommended for next version:
In the module that searches for existing QBO customers, change the module to use a specific field and search for the direct QB Display Name (as represented by the grouped Key of the previous aggregator).
In the ad-hoc testing scenario, this successfully found the existing customer and did not yield an error.