Data Delivery Service
- DDS job file
- Job queueing
- Multi-entity handling
- Record change types
- File compression
- Loader sample
Data Delivery Service (DDS) enables companies to extract massive amounts of data from Intacct and send that data to a cloud storage location. DDS is useful for companies that do cross-system reporting, want to use analytics tools outside of Intacct, and/or need to share information across other companies they own or manage.
Data Delivery Service can be subscribed in your company by navigating to Company > Subscriptions.
DDS is not a free subscription. Make sure to verify that this subscription has been purchased beforehand.
DDS Jobs can be scheduled or run on demand in the Intacct system, or they can be run on demand from the API . You must define a cloud storage target in the Intacct system before you can run a job.
For each job, you can get all of the records for an object or only the records that were changed since the last export.
Job files are delivered as separate CSV files. Files can be split based on a maximum number of records.
It is your responsibility to process and load the files into your own database.
DDS allows certain Intacct standard objects and all custom platform objects to be exported as jobs. The standard objects can be found on the DDS Objects page, or you can list both standard and custom objects using the get getDdsObjects API call.
DDS job file
The result of a DDS job is one or more CSV job files, where the name of the object is used at the beginning of the file name. Information about fields in the job file is provided below.
The following fields are included in every job file.
|ddsReadTime||Timestamp when the record was read from the Intacct system. See the information about data integrity between objects below.|
|ddsChangeType||For jobs that publish only changed records, this field indicates whether the record was created, updated, or deleted. Reported values are
|WHENMODIFIED||Timestamp when an Intacct user last modified the record. Note that this field might have slight variations in its name. Derived tables will have a link to a table that provides this value. If the value is
|MODIFIEDBY||Foreign key that identifies the user who last modified the record. Typically, this is the
|WHENCREATED||Timestamp when the record was initially created. Note that this field might have slight variations in its name and derived tables will not have this value. If the value is
|CREATEDBY||Foreign key that identifies the user who created the record. Typically, this is the
About ddsReadTime and data integrity
In order to prevent issues with data integrity, DDS runs all related jobs against data as it existed when the job started (at
This prevents problems that might have otherwise occurred when:
- Exporting an especially large set of records, such that the contents of the table might change during job execution.
- Exporting several objects in a single job, such that a record in one table may be related to a record that does not yet exist or has changed.
Many objects contain fields that were physically stored in related tables within Intacct. These fields are added directly to reduce needed joins. For example, the
CUSTOMER table includes many fields from the related
The following fields merit additional attention.
|RECORDNO||Most objects have a
|MEGAENTITYKEY||In multi-entity shared implementations, the foreign key (
|STATUS||Inactive records are typically hidden from list views in Intacct and are often prohibited in transactions. Values can be either
DDS follows the published object definitions as closely as possible. If data types for a field are not found here, refer to the object list in the Intacct system under Platform > Objects.
Alternatively, the inspect API function will return data types for fields when the details argument is set. Following are general notes about data types:
Boolean values are typically represented as either
FALSE. There may be a few exceptions where these values are represented as
false. Null values are possible in Boolean fields and usually indicate an unset value.
Date and Datetime
All date and datetime values follow the ISO-8601 standard for date formatting,
YYYY= four-digit year
MM= two-digit month (01=January, etc.)
DD= two-digit day of month (01 through 31)
hh= two digits of hour (00 through 23) (am/pm not allowed)
mm= two digits of minute (00 through 59)
ss= two digits of second (00 through 59)
TZD= time zone designator (Z or +hh:mm or -hh:mm)
2017-04-26T06:55:40Z. Note that the
Z is a special UTC (Coordinated Universal Time) designator.
DDS follows a few patterns for defining relationships between objects:
Refer to the entity relationship diagrams or object definitions to get details on foreign keys relationships.
Intacct stores all data encoded in UTF-8. Differences in observed formatting may be related to the tool used to view or import the data.
DDS Jobs can consume extraordinary computing resources. For this reason, DDS jobs are queued for execution. DDS jobs run in a queue shared by other offline jobs such as scheduled transactions and offline reports. DDS jobs do not compete with either user interface or API requests. Organizations with the standard Level of Service are limited to serial execution of these jobs. Customers with a premium Level of Service may be allowed two or more parallel job executions (depending on their Level of Service).
In general, DDS does not observe multi-entity restrictions. That is, DDS jobs run at the top level and may not be invoked by users with entity restrictions. Each object that may have entity restrictions includes columns for defining those restrictions. Refer to the
MEGAENTITY prefixed fields above in Special Fields.
Record change types
By default, DDS separates records that were either created or updated from records that were deleted. This allows developers to run a single routine to handle all creates and updates and a separate routine to handle record deletions. DDS takes special care to record the correct action:
- If a record was created and then updated after the “as of” date for the execution, DDS will simply report the record was created. An update is not required in this case.
- If a record was updated and then deleted after the “as of” date of the execution, DDS will simply report the record was deleted.
Optionally, you can configure a DDS job to compress files. In this case, DDS uses simple gzip compression. Any standard gzip decompression tool should work to decompress the files.