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.
Featureslink
Feature Name | Supported | Notes |
---|---|---|
Capture deletes | check | |
Custom data | ||
Data blocking | check | Column level |
Column hashing | check | |
Re-sync | check | Table level |
History | ||
API configurable | check | |
Priority-first sync | ||
Private networking | ||
Fivetran data models | check | Get the models: source / transform |
Setup guidelink
Follow our step-by-step Sage Intacct setup guide to connect Sage Intacct with your data warehouse using Fivetran connectors.
Schema informationlink
This schema applies to all Sage Intacct connectors.
To zoom, open the ERD in a new window.Sync notelink
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.
Capture deleteslink
We use different strategies to capture deletes because the Sage Intacct API doesn’t offer a reliable mechanism to capture deletes:
-
AUDIT_HISTORY
table. We use the Sage Intacct API to fetch the deleted records.NOTE: We observed data integrity concerns when using the
AUDIT_HISTORY
table 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
GL_DETAIL
table. TheAUDIT_HISTORY
table doesn’t capture the deleted records as theGL_DETAIL
table is a view in Sage Intacct. In addition, the primary key column of theGL_DETAIL
table 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
_fivetran_deleted
column. - For a child table, we don’t delete the record from the destination table. We don’t use another column to denote deletes.