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.
After version v0.6:
Current design: Secondary WAQM scenario for QBO uses 1 large payload from core scenario to process all invoice transactions. Success notification email gets sent from secondary QBO scenario.
Potential change: Refactor so that secondary QBO scenario runs for each individual invoice transaction. An HTTP response is sent to core scenario with success/failure and any incremental info needed to send the notification email (with list of invoices processed and link to invoice transaction).
May also require sending datastore config as part of payload.
PRO:
May be easier to troubleshoot QBO transaction failures and re-process with individual transactions going to incomplete execution.
In future, secondary scenario could be housed in central location without cloning to client account. If operations could be charged to each client, this could be interesting.
CON:
-Core scenario becomes dependent on multiple runs of the secondary scenario before it can finish.
-Would need to understand how to handle situations where Incomplete transaction on secondary scenario is processed? How would response be processed and managed?
removing from v0.7. Significant change that can have many impacts to error handling and resolution. Needs to be considered as a larger change when WAQM moves closer to a DevOps model?
After version v0.6:
Current design: Secondary WAQM scenario for QBO uses 1 large payload from core scenario to process all invoice transactions. Success notification email gets sent from secondary QBO scenario.
Potential change: Refactor so that secondary QBO scenario runs for each individual invoice transaction. An HTTP response is sent to core scenario with success/failure and any incremental info needed to send the notification email (with list of invoices processed and link to invoice transaction). May also require sending datastore config as part of payload.
PRO:
CON: -Core scenario becomes dependent on multiple runs of the secondary scenario before it can finish. -Would need to understand how to handle situations where Incomplete transaction on secondary scenario is processed? How would response be processed and managed?