Sage Intacct is a provider of cloud-based accounting software which can provide real-time financial and operational insights, as well as the ability to automate critical processes.
|Data blocking||check||Column level|
|API configurable||check||API configuration|
|Fivetran data models||check||Get the models: source / transform|
Follow our step-by-step Sage Intacct setup guide to connect Sage Intacct with your data warehouse using Fivetran connectors.
This schema applies to all Sage Intacct connectors.
We store timestamp-based attributes as TIMESTAMP. Previously, we stored these attributes as VARCHAR in the destination. If you have previously synced a table with timestamp-based attributes, to ensure data integrity, drop the table from your destination and trigger a table re-sync.
We use different strategies to capture deletes because the Sage Intacct API doesn’t offer a reliable mechanism to capture deletes:
AUDIT_HISTORYtable. We use the Sage Intacct API to fetch the deleted records.
NOTE: We observed data integrity concerns when using the
AUDIT_HISTORYtable to track deletes.
A custom strategy. For source tables with an INTEGER primary key column, we logically divide the table into contiguous chunks and import the chunks for which we detect change (using the checksums from the previous sync). We use these re-imported IDs to detect deletes that happened at the source. We use the chunk size to minimize the amount of data transferred from Sage Intacct.
NOTE: We don’t capture deletes for the
AUDIT_HISTORYtable doesn’t capture the deleted records as the
GL_DETAILtable is a view in Sage Intacct. In addition, the primary key column of the
GL_DETAILtable is non-numerical.
When you delete a record in the source, we mark the record as
_fivetran_deleted = TRUE in the destination table. We do the following:
- For a parent table, we mark the record as deleted in the destination. We set the
- For a child table, we don’t delete the record from the destination table. We don’t use another column to denote deletes.