This release is scheduled to go live beginning on the evening of August 20, 2021.

Note: The release notes and documentation are subject to change until that date.


Accounts Payable

Improved usability for vendor functions including behavior changes on existing functions

This release fixes a known issue related to updating vendors with contact lists, and provides additional capabilities related to vendor contacts, vendor email templates, vendor account number/locations, Pay to/Return to/Contact to 1099 functionality, and electronic vendor payments functionality.

Vendor contact changes (2.1 and 3.0 functions)

Previously, when using a 3.0 update function on a vendor that had an existing list of contacts (CONTACT_LIST_INFO elements), you had to re-supply the complete set of existing contacts or they were deleted. This is now fixed—you can update vendors without supplying the CONTACT_LIST_INFO without any loss of data.

Similarly, when using the 2.1 update_vendor function in previous releases, you had to re-supply the complete set of existing contacts (contactlist elements) or they were deleted. This is also fixed.

In addition, when you use either a 2.1 or 3.0 update and provide contact list entries, those contacts are now appended to the set—it is not a complete replacement as it was in previous releases.

To delete all the contacts, you can pass empty contact lists using either a 2.1 or 3.0 update.

In a related enhancement, you can now use VENDORCONTACTS in 3.0 create or update functions instead of supplying contacts via individual CONTACT_LIST_INFO elements. If both VENDORCONTACTS and CONTACT_LIST_INFO are provided, VENDORCONTACTS is used.

The two approaches provide the same functionality, but use a different model:

VENDORCONTACTS example
<VENDORCONTACTS>
  <VENDORENTITYCONTACTS>
    <CATEGORYNAME>Home</CATEGORYNAME>
    <CONTACT>
        <NAME>Despereaux, Pierre</NAME>
    </CONTACT>
  </VENDORENTITYCONTACTS>
  <VENDORENTITYCONTACTS>
    <CATEGORYNAME>Office</CATEGORYNAME>
    <CONTACT>
        <NAME>Despereaux, Pierre</NAME>
    </CONTACT>
  </VENDORENTITYCONTACTS>
</VENDORCONTACTS>
CONTACT_LIST_INFO example
<CONTACT_LIST_INFO>
    <CATEGORYNAME>Home</CATEGORYNAME>
    <CONTACT>
        <NAME>Despereaux, Pierre</NAME>
    </CONTACT>
</CONTACT_LIST_INFO>
<CONTACT_LIST_INFO>
    <CATEGORYNAME>Office</CATEGORYNAME>
    <CONTACT>
        <NAME>Despereaux, Pierre</NAME>
    </CONTACT>
</CONTACT_LIST_INFO>

For more information, see the VENDORCONTACTS and CONTACT_LIST_INFO parameters on the following operations:

Provide vendor email templates (3.0 functions)

You can now specify vendor email templates (VENDOREMAILTEMPLATES) using 3.0 create and update functions:

<VENDOREMAILTEMPLATE>
    <EMAILTEMPLATENAME>Purchase order email</EMAILTEMPLATENAME>
    <DOCPARID>Purchase Order</DOCPARID>
</VENDOREMAILTEMPLATE>

Important: If you perform an update and provide VENDOREMAILTEMPLATE, the existing set is completely replaced by the new set. This is a different model than that of the vendor contact list elements discussed previously.

If you perform an update without passing VENDOREMAILTEMPLATE, the existing email templates are not affected. To delete all the specified email templates, pass an empty VENDOREMAILTEMPLATE element.

For more information, see the VENDOREMAILTEMPLATE parameter on the create and update vendor functions, as well as the functions for reading vendor email templates.

Vendor account number/location changes (3.0 functions)

You can now specify the vendor account number and location (VENDORACCTNOLOCATIONS) in 3.0 create and update functions as an alternative to using VENDOR_ACCTNO_LOC_HEAD. If both are supplied, VENDORACCTNOLOCATIONS is used.

<VENDORACCTNOLOCATIONS>
    <VENDORACCTNOLOCHEAD>
        <LOCATION>CA</LOCATION>
        <ACCOUNTNO>123456</ACCOUNTNO>
    </VENDORACCTNOLOCHEAD>
</VENDORACCTNOLOCATIONS>

Important: If you perform an update and specify VENDORACCTNOLOCATIONS, the existing set is completely replaced by the new set. This is a different model than that of the vendor contact list elements discussed previously.

If you perform an update without passing VENDORACCTNOLOCATIONS, the existing data is not affected. To delete all the vendor account number/locations, pass an empty VENDORACCTNOLOCATIONS element.

For more information, see the VENDORACCTNOLOCATIONS parameter on the following operations:

Enhanced Pay to, Return to, and Contact to 1099 functionality (2.1 and 3.0 functions)

Using a 3.0 update on a vendor with PAYTO or RETURNTO entries now appends PAYTO and RETURNTO to the contact list.

Similarly, using a 2.1 update_vendor with contactinfo, payto, returnto, and contactto1099 appends to the contact list.

Important: All behavior changes for existing vendor functionality (2.1 and 3.0)

Function Current behavior Previous behavior
3.0 update Updating a vendor without supplying the CONTACT_LIST_INFO or VENDORENTITYCONTACT does not cause data loss. Updating a vendor without supplying the CONTACT_LIST_INFO resulted in loss of the existing CONTACT_LIST_INFO data.
2.1 update_vendor Updating a vendor without supplying the contactlist does not cause data loss. Updating a vendor without supplying the contactlist resulted in loss of the existing contactlist data.
3.0 create
3.0 update
Providing empty CONTACT and CATEGORYNAME values in CONTACT_LIST_INFO or VENDORENTITYCONTACTS does not create the CONTACT_LIST_INFO or VENDORENTITYCONTACTS and does not not throw an error. Providing empty CONTACT and CATEGORYNAME values in CONTACT_LIST_INFO resulted in a CONTACT_LIST_INFO with blank values.
2.1 create_vendor
2.1 update_vendor
Providing an empty contactname and category in contactlist does not create the contact list and does not not throw an error. Providing an empty contactname and category in contactlist resulted in a contact list with blank values.
3.0 create
3.0 update
Providing a nonexistent contact name in the PAYTO or RETURNTO throws an error and prevents the system from creating that vendor. Providing a nonexistent contact name in the PAYTO or RETURNTO did not prevent the system from creating that vendor.
2.1 create_vendor
2.1 update_vendor
Providing a nonexistent contactname in the payto or returnto throws an error and prevents the system from creating that vendor. Providing a nonexistent contactname in the payto or returnto did not prevent the system from creating that vendor.
3.0 update Updating a vendor with new CONTACT_LIST_INFO or VENDORENTITYCONTACTS entries appends new entries to the existing set (both CONTACT_LIST_INFO and VENDORENTITYCONTACTS). Updating a vendor with new CONTACT_LIST_INFO entries resulted in a complete replacement of the existing set.
2.1 update_vendor Updating a vendor with new contactlist entries appends new entries to the existing set. Updating a vendor with new contactlist entries resulted in a complete replacement of the existing set.
3.0 create
3.0 update
Providing CONTACTINFO, PAYTO, and RETURNTO without CONTACT_LIST_INFO creates the contact list (both CONTACT_LIST_INFO and VENDORENTITYCONTACTS). Providing CONTACTINFO, PAYTO, and RETURNTO without CONTACT_LIST_INFO did not create the contact list.
2.1 create_vendor
2.1 update_vendor
Providing contactinfo, payto, and returnto without contactlist creates the contact list. Providing contactinfo, payto, and returnto without contactlist did not create the contact list.
3.0 update Updating a vendor with CONTACTINFO, PAYTO, and RETURNTO appends PAYTO and RETURNTO to the contact list (both CONTACT_LIST_INFO and VENDORENTITYCONTACTS) Updating a vendor with CONTACTINFO, PAYTO, and RETURNTO did not append PAYTO and RETURNTO to the contact list.
2.1 update_vendor Updating a vendor with contactinfo, payto, returnto, and contactto1099 appends these to the contact list. Updating a vendor with contactinfo, payto, returnto, and contactto1099 did not append the contact list with the existing contact.

Inter-entity bill back templates in responses

Functions that read AP bills now provide the name of the bill back template if one is in use, for example:

<BILLBACKTEMPLATE>BBTMP-022</BILLBACKTEMPLATE>

See the Sage Intacct product help for information about bill back templates.

Electronic payments for vendors - CSI payment provider (Early Adopter Program)

You can now flag vendors as individual persons to mask personally identifiable information (PII).

See the ISINDIVIDUAL parameter on the following operations:

Provide vendor bank file details when using electronic payment providers (3.0 functions)

Now, when creating or updating vendors, you can provide your country code and vendor bank file details.

See the FILEPAYMENTSERVICE, PYMTCOUNTRYCODE and VENDORBANKFILEDETAILS parameters on the following operations:


Accounts Receivable

Improved usability for customer functions including behavior changes on existing functions

This release fixes a known issue related to updating customers with contact lists, and provides additional capabilities related to customer contacts and Bill to/Ship to functionality.

Customer contact changes (2.1 and 3.0 functions)

Previously, when using a 3.0 update function on a customer that had an existing list of contacts (CONTACT_LIST_INFO elements), you had to re-supply the complete set of existing contacts or they were deleted. This is now fixed—you can update customers without supplying the CONTACT_LIST_INFO without any loss of data.

Similarly, when using the 2.1 update_customer function in previous releases, you had to re-supply the complete set of existing contacts (contactlist elements) or they were deleted. This is also fixed.

In addition, when you use either a 2.1 or 3.0 update and provide contact list entries, those contacts are now appended to the set—it is not a complete replacement as it was in previous releases. To delete all the contacts, you can pass empty contact lists using either a 2.1 or 3.0 update.

In a related enhancement, you can now use CUSTOMERCONTACTS in 3.0 create or update functions instead of supplying contacts via individual CONTACT_LIST_INFO elements. If both CUSTOMERCONTACTS and CONTACT_LIST_INFO are provided, CUSTOMERCONTACTS is used.

The two approaches provide the same functionality, but use a different model:

CUSTOMERCONTACTS example
<CUSTOMERCONTACTS>
  <CUSTOMERENTITYCONTACTS>
    <CATEGORYNAME>Home</CATEGORYNAME>
    <CONTACT>
        <NAME>Kristensen, Linda</NAME>
    </CONTACT>
  </CUSTOMERENTITYCONTACTS>
  <CUSTOMERENTITYCONTACTS>
    <CATEGORYNAME>Office</CATEGORYNAME>
    <CONTACT>
        <NAME>Kristensen, Linda</NAME>
    </CONTACT>
  </CUSTOMERENTITYCONTACTS>
</CUSTOMERCONTACTS>
CONTACT_LIST_INFO example
<CONTACT_LIST_INFO>
    <CATEGORYNAME>Home</CATEGORYNAME>
    <CONTACT>
        <NAME>Kristensen, Linda</NAME>
    </CONTACT>
</CONTACT_LIST_INFO>
<CONTACT_LIST_INFO>
    <CATEGORYNAME>Office</CATEGORYNAME>
    <CONTACT>
        <NAME>Kristensen, Linda</NAME>
    </CONTACT>
</CONTACT_LIST_INFO>

For more information, see the CUSTOMERCONTACTS and CONTACT_LIST_INFO parameters on the create and update customer functions.

Enhanced Bill to and Ship to functionality (2.1 and 3.0 functions)

Using a 3.0 update on a customer with CONTACTINFO, BILLTO, and SHIPTO entries now appends BILLTO and SHIPTO to the contact list.

Similarly, using a 2.1 update_vendor with contactinfo, billto, and shipto appends to the contact list.

Important: All behavior changes for existing customer functions (2.1 and 3.0)

Function Current behavior Previous behavior
3.0 update Updating a customer without supplying the CONTACT_LIST_INFO or CUSTOMERENTITYCONTACT does not cause data loss. Updating a customer without supplying the CONTACT_LIST_INFO resulted in loss of the existing CONTACT_LIST_INFO data.
2.1 update_customer Updating a customer without supplying the contactlist does not cause data loss. Updating a customer without supplying the contactlist resulted in loss of the existing contactlist data.
3.0 create
3.0 update
Providing empty CONTACT and CATEGORYNAME values in CONTACT_LIST_INFO or VENDORENTITYCONTACTS does not create the CONTACT_LIST_INFO or VENDORENTITYCONTACTS and does not not throw an error. Providing empty CONTACT and CATEGORYNAME values in CONTACT_LIST_INFO resulted in a CONTACT_LIST_INFO with blank values.
2.1 create_vendor
2.1 update_vendor
Providing an empty contactname and category in contactlist does not create the contact list and does not not throw an error. Providing an empty contactname and category in contactlist resulted in a contact list with blank values.
3.0 create
3.0 update
Providing a nonexistent contact name in the BILLTO or SHIPTO throws an error and prevents the system from creating that customer. Providing a nonexistent contact name in the BILLTO or SHIPTO did not prevent the system from creating that customer.
2.1 create_vendor
2.1 update_vendor
Providing a nonexistent contactname in the billto or shipto throws an error and prevents the system from creating that customer. Providing a nonexistent contactname in the billto or shipto did not prevent the system from creating that customer.
3.0 update Updating a customer with new CONTACT_LIST_INFO or CUSTOMERENTITYCONTACTS entries appends new entries to the existing set (both CONTACT_LIST_INFO and CUSTOMERENTITYCONTACTS). Updating a customer with new CONTACT_LIST_INFO entries resulted in a complete replacement of the existing set.
2.1 update_customer Updating a customer with new contactlist entries appends new entries to the existing set. Updating a customer with new contactlist entries resulted in a complete replacement of the existing set.
3.0 create
3.0 update
Providing CONTACTINFO, BILLTO, and SHIPTO without CONTACT_LIST_INFO creates the contact list (both CONTACT_LIST_INFO and CUSTOMERENTITYCONTACTS). Providing CONTACTINFO, BILLTO, and SHIPTO without CONTACT_LIST_INFO did not create the contact list.
2.1 create_customer
2.1 update_customer
Providing contactinfo, billto, and shipto without contactlist creates the contact list. Providing contactinfo, billto, and shipto without contactlist did not create the contact list.
3.0 update Updating a customer with CONTACTINFO, BILLTO, and SHIPTO appends BILLTO and SHIPTO to the contact list (both CONTACT_LIST_INFO and CUSTOMERENTITYCONTACTS). Updating a customer with CONTACTINFO, BILLTO, and SHIPTO did not append BILLTO and SHIPTO to the contact list.
2.1 update_customer Updating a customer with contactinfo, billto, and shipto appends billto and shipto to the contact list. Updating a vendor with contactinfo, billto and shipto did not append billto and shipto the contact list.

Error handling to prevent paying foreign currency invoices using undeposited funds

The system now prevents using the 3.0 API to create a batch payment of foreign currency invoices using undeposited funds. A helpful error message is provided.


Purchasing

Specify project IDs on Purchasing transactions

When creating or updating a Purchasing transaction using the API, you can now provide a project ID on the header.

See the projectid parameter on the header portion of the following:

New standard reporting categories

You can choose from industry-standard reporting categories when creating or updating Purchasing transaction definitions using the API:

For more information, see the REPORTINGCATEGORY parameter on the following operations:


Order Entry

Retrieve PDF data for transactions

This release introduces a new retrievepdf function to return Base64-encoded data for PDF versions of transactions.

For more information, see Get Order Entry Transaction PDF Data

New standard reporting categories

Industry-standard reporting categories for Order Entry transaction definitions can be specified in the UI, and can be viewed in the responses of API functions that read Order Entry transactions.


Inventory Control

New standard reporting categories

Industry-standard reporting categories for Inventory Control transaction definitions can be specified in the UI, and can be viewed in the responses of API functions that read Inventory Control transactions.

Density item attributes

Density measurements can now be added to item details with the DENSITY (decimal) and DENSITYUOM (string) fields.

For more information, see the parameter lists here:

Tracking extended to stockable kits (parent-level only)

You can now track stockable kits by serial numbers, lot numbers, bins, expiration dates, and so forth. Previously, this was supported only for inventory items.

When creating (or updating) a stockable kit, you can provide item details with the tracking information for each kit item.

In addition, when creating or updating Inventory Control, Purchasing, or Order Entry transactions, you can provide item details for items of type stockable kit.

For more information, see the itemdetails parameter on the following operations:

In addition, lot numbers and serial numbers are no longer mutually exclusive in item details for Purchasing and Order Entry transactions.

In-transit warehouse transfers

The new “in transit” warehouse transfer type lets you account for inventory that takes time to move from one warehouse to another. The inventory is categorized as “in transit” while it is being moved and is not counted as being on hand in either the originating or receiving warehouses.

How it works:

Immediate transfers now also have a Draft state. You can save a draft of the warehouse transfer as you plan on what inventory to move. You might save the transaction as a draft to print the warehouse transfer information and verify that the items are ready to be moved before posting the transaction.

For more information, see the ACTION, TRANSFERTYPE, OUTDATE, and INDATE parameters on the following operations:


Contracts and Revenue Management

Consolidate invoices by Bill To contact

Invoices can now be consolidated by contract line level Bill to contacts, at the customer, contract, or project level. This capability is available for contract invoice previews and for contract invoice filter sets.

For more information, see the INVOICEBY parameter on the following operations:

Committed quantity billing

Committed quantity billing is now supported. With this approach, you predefine the quantity to consume over the course of the contract.

For more information, see the USAGELINETYPE, COMMITTEDUSAGEENDACTION, and COMMITTEDUSAGEEXCESS parameters on the following operations:


Construction (Early Adopter Program)

Enhanced reporting

This release provides expanded reporting capabilities for Construction projects.

Cost categories for accumulation types

You can choose from a set of industry-standard cost categories for your accumulation types:

For more information, see the COSTCATEGORY parameter on the following operations:

Estimate categories for project estimate types

You can choose from a set of industry-standard estimate categories for your project estimate types:

For more information, see the ESTIMATECATEGORY parameter on the following operations:

Project change orders

The new project change order object lets you group change requests so you can present them to the customer for approval, and ultimately, for billing. You can associate your project change order with a change request status (such as Approved Changes), which is an existing user-defined object that is now shared by change orders and change requests.

After creating a project change order, you can create links from one or more change requests to that change order. To do this, use the new PROJECTCHANGEORDERID parameter when creating or updating change requests. Change requests must be in a Posted state in order to be linked to a change order. Once linked, change requests inherit their change request status from the change order.

When you get a project change order, the sum of the total cost and total price for all the linked change requests is provided in the response.

For more information, see:

Tracking changes to a source transaction when using change management (Purchasing and Order Entry)

A new changelognumber parameter helps you track the number of changes applied to a source transaction. When you create a source transaction, its changelognumber is set to 0 by default. Then, each time you submit a change transaction, the number is incremented.

This parameter is available only in transactions where the transaction definition is configured for change management.

See changelognumber on the following operations:



This release is scheduled to go live beginning on the evening of May 21, 2021.


General Ledger

Enhanced functionality when listing account balances by dimensions

This release offers more functionality when listing account balances by dimension.

List actual and budget data

Previously, get_accountbalancesbydimensions returned only actual data. You can now choose to return actual data, budget data, or both. You can also specify how to calculate the difference between budgeted and actual data.

For example, the following lists account balances for actual and budgeted amounts and calculates the difference by subtracting actual from budgeted:

<get_accountbalancesbydimensions>
    <reportingperiodname>Month Ended January 2021</reportingperiodname>
    <contentselection>Actual and Budget</contentselection> <!-- New parameter -->
    <budgetid>Proj_01-budget</budgetid> <!-- New parameter -->
    <budgetcomparison>Budget minus Actual</budgetcomparison> <!-- New parameter -->
    <glaccountno>4000</glaccountno>
    <locationid>CA</locationid>
    <groupby>location</groupby>
</get_accountbalancesbydimensions>

A response such as the following is returned:

<data>
    <accountbalance>
        <glaccountno>4000</glaccountno>
        <budgetbalance>150.00</budgetbalance>
        <periodbalance>100.00</periodbalance>
        <difference>50.00</difference>
        <currency>USD</currency>
        <locationid>CA</locationid>
    </accountbalance>
</data>

Show zero balance accounts with activity

A new showzerowithactivity parameter, when set to true, provides information about accounts with zero ending balances if they have had activity. By default, such accounts are not included.

List data according to location and department groups

Previously, you could not provide location or department groups when listing data. The location and department parameters now accept location and department groups (as well as locations and departments as before).

Currency included in responses

All responses now include the currency.

Create journal entries with tax solutions

The 3.0 style create function for journal entries now supports providing a tax solution.

For more information, see the TAXSOLUTIONID parameter here:

Deprecation of legacy budget APIs

Back in 2020-R3, a new GL budget object (GLBUDGETHEADER) was added to support creating a budget with details in the same call. In subsequent versions of release notes, we explained that the legacy functions on BUDGETHEADER and GLBUDGET were scheduled for deprecation in 2021-R2.

The legacy budget functions are now deprecated and unavailable for the majority of clients.

A few remaining clients are still using the legacy budget functions and must update their integrations. If you are one of these clients:

Important: The majority of legacy objects (BUDGETHEADER and GLBUDGET) have been migrated to the new object types (GLBUDGETHEADER and GLBUDGETITEMS) in this release. After migration, create, update, and delete, when used on the old object names, will return error messages explaining that you need to use the new objects. Contact support now if you still need to have data migrated.


Accounts Payable

Specify the starting check number for electronic payments (Early Adopter Program)

Last release introduced a new electronic payments service for paying US vendors. Starting with this release, you can specify the starting number for the check sequences in payment provider bank accounts.

For more information, see theCHECKSTARTNO parameter for the following:

Note: Electronic payments requires a subscription to Outbound Payment Services. Once subscribed and configured, you can use the API to make an electronic payment, designating the provider. Currently, Corporate Spending Innovations (CSI) is the only supported provider.


Accounts Receivable

Ability to list customer charge card records will no longer be supported

The get_list function for customer charge cards is scheduled for deprecation. This function will become unavailable in a future release, likely, 2021-R4. At this time, the only way to access customer credit card information will be through the Sage Intacct UI.

Important: Check your integrations now and remove this function to avoid problems when this function becomes unavailable, planned for the 2021-R4 release.


Contracts and Revenue Management

Bill to contact on contract lines

Previously, you could set the Bill to contact only on the contract itself. Starting with this release, you can provide Bill to contacts for individual lines. You can also control whether the values on such lines are overridden when the Bill to on the contract itself is changed.

For more information, see the BILLTOCONTACTNAME and BILLTOSOURCE parameters for the following:

Enhanced validation and usability for contract billing price lists

When you create billing price list entry details (CONTRACTITEMPRICELISTENTRIES), the system now validates that the start dates are in ascending order (earliest to most recent) and that there are no duplicate entries.

In addition, when using a Tiered price type, several parameters are now automatically assigned the correct values, whether you supply values or not:

Finally, for a Range price type, the variable unit rate is now required.


Project and Resource Management

Include billable credit card transactions in project invoices

Now, when you mark credit card transactions as billable to a project, those transactions flow directly to project invoicing.

For more information, see the billable parameter here:


Inventory Control

Expanded rules for negative inventory

Previously, even though a company was configured to allow negative inventory, warehouse transfers that would result in negative inventory were blocked. With this release, such warehouse transfers are no longer blocked.

Because allowing negative inventory across the system can be complicated, you might want to turn off negative inventory for the company, then enable it only for selected warehouses.

For more information, see ENABLENEGATIVEINV here:

Provide alternatives for out-of-stock items with item cross-references

Release 2021-R1 introduced external item cross references, which enable your customers or vendors to provide their own identifiers for inventory items that can be used in transactions.

This release adds internal item cross references for identifying alternatives for items you sell. You can suggest substitute, upgrade, downgrade, or complement items. The alternatives are available when creating Order Entry transactions in the Sage Intacct UI.

For more information, see the REFTYPE and ALTERNATEITEMID parameters here:

Additional item attributes

Over 40 standard fields have been added for items to enhance item data points and reduce the need to create custom fields. Use these new fields that are based on industry research in wholesale distribution, third-party integrations, and your feedback to further define the unique characteristics of an item according to your business needs.

The new fields are in three broad categories:

For more information, see the parameter lists here:


Sales Tax, VAT, and GST

Accounts Payable

Partial exemption for AP bills (United Kingdom)

This release provides support for partial exemption in Accounts Payable so that you can reclaim a portion of your input VAT on purchases. Assuming your company is set up for partial exemption, you can mark bill lines as eligible for partial exemption and have the system automatically handle the details.

For more information:

The Sage Intacct product help has examples that show the details of the calculations.


SDK for Node.js Update

You can now use a fully-qualified domain name (FQDN) in the endpoint URL.


Construction (Early Adopter Program)

Identify how changes impact project costs with the new change request object

The change request object enables construction companies to track changes to their projects by price and cost at the lowest work breakdown structure level (project + task + cost type), and post the changes to the project’s primary estimate.

A change request object typically owns multiple change request entries, where each entry represents a price and/or cost change for the project. You can create individual entries when you create the change request, or you can create a change request without entries and use update to add them later.

If a change should not be billed to the customer, you need only capture the cost for the entry. To pass the cost onto the customer, use the same amount for cost and price.

When you post a change request, the system posts its costs to the project’s primary estimate (if present) based on the assigned change request status. If the primary estimate is set to post to a GL budget, entries from the change request are included.

If you want to associate change requests with workflow types, you can create change request status objects that provide this mapping. You can also specialize your reporting with change request types.

For more information:

Supporting changes in project estimates

Project estimate entries now include the following read-only parameters with links to associated change requests and change request entries:

A project estimate entry that is linked with a change request entry cannot be updated or deleted. Also, a primary project estimate with linked entries cannot be set to non-primary.

For more information:

Order Entry change orders

You can now manage changes to Order Entry agreements as your Construction job progresses.

To do this, modify or create Order Entry transaction definitions that enable change management in the Sage Intacct UI. A transaction definition can identify a transaction as either a source transaction or a change-order transaction. By default, Order Entry transaction definitions have change management disabled.

Using your new transaction definitions, you can create a source transaction, then create change orders that modify that source. You can create a change order even if the source transaction has been partially or fully converted.

A change order can add new lines or modify existing lines on a given source transaction. For example, assume there is a source transaction definition, Source_Doc01, and a change order transaction definition, Change_Doc01.

The following creates a source transaction with one line:

<create_sotransaction>
    <transactiontype>Source_Doc01</transactiontype>
    <datecreated>
        <year>2021</year>
        <month>04</month>
        <day>01</day>
    </datecreated>
    <customerid>BTI</customerid>
    <termname>N15</termname>
    <datedue>
        <year>2021</year>
        <month>05</month>
        <day>15</day>
    </datedue>
    <basecurr>USD</basecurr>
    <currency>USD</currency>
    <exchratedate>
        <year>2021</year>
        <month>03</month>
        <day>31</day>
    </exchratedate>
    <exchratetype/>
    <state>Pending</state>
    <sotransitems>
        <sotransitem>
            <itemid>A001</itemid>
            <itemdesc>Desktop-HP</itemdesc>
            <warehouseid>1</warehouseid>
            <quantity>10</quantity>
            <unit>Each</unit>
            <price>100</price>
            <locationid>1</locationid>
            <conversiontype>Quantity</conversiontype>
        </sotransitem>
    </sotransitems>
</create_sotransaction>

Assume the record number for the created source transaction is 255, and the record number for the created line is 257. The following provides a change order that modifies the existing line (changes the quantity to 25) and adds a new line to the source transaction:

<create_sotransaction>
    <transactiontype>Change_Doc01</transactiontype>
    <datecreated>
        <year>2021</year>
        <month>04</month>
        <day>01</day>
    </datecreated>
    <customerid>BTI</customerid>
    <termname>N15</termname>
    <datedue>
        <year>2021</year>
        <month>05</month>
        <day>15</day>
    </datedue>
    <basecurr>USD</basecurr>
    <currency>USD</currency>
    <exchratedate>
        <year>2021</year>
        <month>03</month>
        <day>31</day>
    </exchratedate>
    <exchratetype/>
    <state>Draft</state>
    <sotransitems>
        <sotransitem>
            <itemid>A001</itemid>
            <itemdesc>Desktop-HP</itemdesc>
            <warehouseid>1</warehouseid>
            <quantity>25</quantity>
            <unit>Each</unit>
            <price>100</price>
            <locationid>1</locationid>
            <relateddockey>255</relateddockey>
            <relateddoclinekey>257</relateddoclinekey>
            <conversiontype>Quantity</conversiontype>           
        </sotransitem>
        <sotransitem>
            <itemid>A002</itemid>
            <itemdesc>Desktop-Dell</itemdesc>
            <warehouseid>1</warehouseid>
            <quantity>39</quantity>
            <unit>Each</unit>
            <price>120</price>
            <locationid>1</locationid>
            <relateddockey>255</relateddockey>
            <conversiontype>Quantity</conversiontype>
        </sotransitem>
    </sotransitems>
</create_sotransaction>

You can delete a draft change order, but not one that is approved.

When you read a source transaction in the API, new output parameters help identify the changes that led to the current state.

New Order Entry transaction (header) fields:

New Order Entry transaction line fields:

For more information:

See the relateddockey and relateddoclinekey parameters here:


This release is scheduled to go live beginning on the evening of February 21, 2021.


Web Services

Enhanced asynchronous callbacks for readReport

In the previous release, we introduced a new feature to support asynchronous callbacks when using readReport on original custom reports. With asynchronous callbacks, your readReport request could initiate a secondary process to automatically send the response and the first batch of results to a callback URL.

We’ve expanded this capability so that you can choose to notify the callback URL without including the first batch of results. To do this, set the new showStatusOnly flag to true.

For more information:


General Ledger

Migrate your data now to take advantage of the new budget API and avoid future problems

In 2020-R3, a new GL budget object (GLBUDGETHEADER) was introduced that supports creating a budget with details in the same call. In addition, the create and update functions on the new object provide better performance than the legacy functions on BUDGETHEADER.

If you were using the legacy budget APIs, it is recommended that you update your integrations now to be prepared when the legacy APIs become unavailable, likely 2021-R2:

Important: The legacy objects (BUDGETHEADER and GLBUDGET) will be migrated to the new object types (GLBUDGETHEADER and GLBUDGETITEMS) in a future release, planned for 2021-R2. After migration, create, update, and delete, when used on the old object names, will return error messages explaining that you need to use the new objects. You will need to contact support to have your data migrated.


Accounts Payable

Introducing a new electronic payments service for early adopters

This release introduces a more reliable and streamlined electronic payments service for paying US vendors. Talk to your account manager to learn if your company is eligible to participate as an early adopter.

Electronic payments requires a subscription to Outbound Payment Services. Once subscribed and configured, you can use the API to make an electronic payment, designating the provider. Currently, Corporate Spending Innovations (CSI) is the only supported provider.

A new PROVIDERPAYMENTMETHOD read-only object provides access to the names of payment providers and their supported payment methods. You can use the new PROVIDERBANKACCOUNT and PROVIDERVENDOR objects to link bank accounts and vendors to electronic payment providers.

For more information:


Accounts Receivable

Ability to list customer charge card records will no longer be supported

The get_list function for customer charge cards is scheduled for deprecation. This function will become unavailable in a future release, likely, 2021-R2. At this time, the only way to access customer credit card information will be through the Sage Intacct UI.

Important: Check your integrations now and remove this function to avoid problems when this function becomes unavailable in a future release, planned for 2021-R2.


Inventory Control

Available quantities for tracked items

A new object lets you get available quantities for tracked items according to serial number, lot number, bin number, and so forth.

Item cross references

You can enable your customers or vendors to provide their own identifiers for inventory items, which can then be used in transactions.

For example, you might have an inventory item with the ID C-55, but one of your customers might want that item to be identified by I-22. You can create an item cross reference to associate item C-55 with the alias of I-22 for that customer. Now when you create transactions for that customer, you can optionally provide the alias ID as well as the item ID.

For more information:


Contracts and Revenue Management

Clear MEA allocations

You can now use the API to clear MEA allocations and reset the applicable revenue schedules to the amounts that existed prior to the allocations. Clearing an MEA allocation unposts previously posted revenue, so the applicable reporting periods must be open.

You can clear all MEA allocations at once or one at a time, starting with the current one and working back in time.

For more information:

Ship to source for contract lines

You can now choose whether the Ship to contact on a contract line is overridden when the Ship to contact on the contract itself is modified. Set the new SHIPTOSOURCE parameter on the contract line to Contract value to allow this overriding or to User-specified value to preserve the Ship to contact name on the line.

See the SHIPTOSOURCE parameter on the following functions:

Billing frequency for contract lines

Previously, billing frequency was required at the contract level and applied to every contract line.

Starting with this release, billing frequency is optional at the contract level and can be set individually on the line. If not specified on the line, the billing frequency from the contract is used. Billing frequency is required on the contract line when the Flat/fixed amount frequency (BILLINGOPTION) is Include with every invoice.

See the BILLINGFREQUENCY parameter on the following functions:


Order Entry

Revenue recognition schedules API documentation moved to Order Entry

The API documentation for revenue recognition schedules is now under the Order Entry category instead of General Ledger. The Sage Intacct Postman collection also reflects this organization. (The functionality of the APIs has not changed.)


Platform Services

CSP administration

Last release provided more visibility into Content Security Policy (CSP) violations, allowing you to easily find instances of URLs that violated your company’s CSPs.

This release provides more flexibility in how you assign URLs to a company or page’s CSP. Now, when you view a list of CSP violations from the Company Information page or an individual page, you can assign that URL to a CSP directly from the list of violations.


Construction Early Adopter Program

Price conversion for Order Entry transactions

Converting a transaction moves the transaction to the next step in the workflow (for example, from sales order to sales invoice). In previous releases, an Order Entry transaction line could only be converted by quantity—you can now convert a line by price as well. The price you supply is used to to determine when a line is partially or fully converted. Price conversion is only supported for non-inventory items. When specifying price conversion, you must use a quantity of 1 and a unit that is a base unit (unit factor of 1).

For more information, see the conversiontype parameter on these functions:

Production units on PJ estimate entries

New Construction functionality enables you to track production unit estimates as part of a project estimate.

You can provide the number of production units (PRODUCTIONUNITS) when creating or updating a PJ estimate entry. You also need to supply a task ID for the entry, and if that task has a production units description (PRODUCTIONUNITDESC), it is inherited.

When you specify production units, posting to the GL budget becomes optional. In other words, you can omit amount/quantity/unit cost for the entry.

For more information, see the PRODUCTIONUNITS parameter on these functions:


Sage Intacct SDK Updates

SDK for Node.js

Version 2.1.0 of the Sage Intacct SDK for Node.js is available on GitHub and NPM.

This version targets Node.js 12.18.0 (or higher). The following enhancements are included in the SDK since it was last mentioned in these release notes.

Version 2.1.0

Version 2.0.0

See the getting started example to learn about the SDK. Refer to GitHub and NPM for complete information, including fixes released in these versions.

SDK for PHP

Version 3.0.0 of the Sage Intacct SDK for PHP is available on GitHub.

This version targets PHP 7.3 (or higher), and provides several enhancements, including:

See the getting started example to learn about the SDK. Refer to GitHub for complete information, including fixes released in this version.



This release is scheduled to go live beginning on the morning of November 15, 2020.


Web Services

Query custom objects

The new query function is now available for custom objects. Compared with the legacy readByQuery function, the new query provides more operators, lets you sort results, performs aggregate operations such as sum or average, and uses a larger pagesize limit. Perhaps most importantly, you can get the values for fields on related objects, both standard and custom, and use them in filters.

For example, consider the following related objects that are part of a sample Platform application. Customer is a standard object and the other three objects are custom.

Hierarchy of application objects

You can perform simple queries or complex ones that cross both standard and custom objects across relationships. For example, the following queries the MCA_attendee custom object, which has a many-to-one relationship to customer via the R_attendee_customer field. The query seeks any attendee where the related customer owes more than 5000:

<query>
    <object>MCA_attendee</object>
    <select>
        <field>NAME</field>
        <field>email</field>
        <field>R_attendee_customer.CUSTOMERID</field>
    </select>
    <filter>
        <greaterthan>
            <field>R_attendee_customer.TOTALDUE</field>
            <value>5000</value>
        </greaterthan>
    </filter>
</query>

If you need help knowing what fields are available for querying, you can return the query-able fields and relationships with the lookup function. For example, lookup on the MCA_attendee object would include the following relationship, which we used in our query above.

<Relationship>
    <OBJECTPATH>R_attendee_customer</OBJECTPATH>
    <OBJECTNAME>customer</OBJECTNAME>
    <LABEL>Customer</LABEL>
    <RELATIONSHIPTYPE>MANY2ONE</RELATIONSHIPTYPE>
    <RELATEDBY>RCUSTOMER</RELATEDBY>
</Relationship>

Asynchronous callback for readReport

In previous releases, after sending a readReport call for an original custom report, you had to send readMore to get the first batch of results. This release provides a new callback capability on readReport, which notifies your callback URL when the report is ready to be consumed and provides the first batch of results.

You must be configured to use asynchronous processing, where you have a unique asynchronous transport policy associated with a URL with your handler.

When you send readReport, you include your transport policy ID in the control block. You can optionally provide a unique report ID:

<request>
    <control>
        <senderid>test_sender</senderid>
        <password>test_password</password>
        <controlid>446ca3a4-28b3-4379-8760-a12812c8b02c</controlid>
        <uniqueid>false</uniqueid>
        <dtdversion>3.0</dtdversion>
        <policyid>myPolicyID</policyid> <!-- asynchronous transport policy ID -->
        <includewhitespace>false</includewhitespace>
    </control>
 <operation>
    ...
    <content>
      <function controlid="99x">
        <readReport>
          <report>Employee Time by Project</report>
              <arguments>
                  <REPORTINGPERIOD>Current Year</REPORTINGPERIOD>
              </arguments>
          <reportId>empTimeByProject20200626NO001</reportId> <!-- unique report ID -->
        </readReport>
      </function>
    </content>
  </operation>
</request>

A synchronous response provides an acknowledgement with the status of the request. Then, when the first batch of results are ready (1000 by default), they are sent to the handler. The response with the results also provides information about data still to be read (numremaining) and includes the reportId.

  <authentication>
        <status>success</status>
        ...
    </authentication>
  <result>
      <status>success</status>
      <function>readReport</function>
      <controlid>9c4a7a1b-5bcb-49bb-83a6-eceb05375a2e</controlid>
      <data listtype=“report” count=“1000" totalcount=“1014” numremaining=“14">
          <report reportId="empTimeByProject20200626NO001">
                <data>
                    <RECORDID>Bill#1-#2</RECORDID>
                    <WHENCREATED>04/15/2001</WHENCREATED>
                    ...
  </result>

If data is still pending, the handler can take the desired action, such as calling readMore with the reportId to get the next batch of results.

Note: This functionality is not supported for Interactive Custom Reports.

For more information:


Sage Intacct SDK enhancements

SDK for .NET

Several enhancements to the Sage Intacct SDK for .NET are now available. See the highlights below, then refer to GitHub for complete information, including fixes.

Version 3.0.0

Version 3.0.0 targets .NET Standard 2.0 and supports NET Core >=2.0 and .NET Framework >=4.6.1. See the system requirements for complete information, such as requirements for the NuGet package manager.

The SDK includes:

See the getting started example to learn about the SDK.

Version 2.3.0 of the SDK includes:

SDK for PHP

Version 2.3.0 of the Sage Intacct SDK for PHP provides several enhancements and fixes, including:

Refer to GitHub for complete information, including fixes.

See the getting started example to learn about the SDK.

SDK for Node.js

Version 1.3.0 of the Sage Intacct SDK for Node.js provides several enhancements and fixes, including:

Refer to GitHub for complete information, including fixes.

See the getting started example to learn about the SDK.


Customization Services and Platform Services

Improved flow for moving custom pages to Action UI

This release lets you optimize your custom and customized pages in the Action UI before making them available to all users:

See the information about personalizing Platform and Customization Services in your display prefererences in the Sage Intacct product help for more information.

Content Security Policy administration

With this release, we’re letting you know when a URL violates a Content Security Policy (CSP) and is blocked from loading. You can:

See the information about installed components and CSPs in the Sage Intacct product help for more information.

Trigger log

Get visibility into when your triggers fail to execute properly in the new trigger log. Here you can find the status of triggers and execution times, as well as details about the triggers.

See the information about triggers in the Sage Intacct product help for more information.


General Ledger

Migrate your data now to take advantage of the new budget API and avoid future problems

In 2020-R3, a new GL budget object (GLBUDGETHEADER) was introduced that supports creating a budget with details in the same call. In addition, the create and update functions on the new object provide better performance than the legacy functions on BUDGETHEADER.

If you were using the legacy budget APIs, it is recommended that you update your integrations now to be prepared when the legacy APIs become unavailable, likely 2021-R2:

Important: The legacy objects (BUDGETHEADER and GLBUDGET) will be migrated to the new object types (GLBUDGETHEADER and GLBUDGETITEMS) in a future release, planned for 2021-R2. After migration, create, update, and delete, when used on the old object names, will return error messages explaining that you need to use the new objects. You will need to contact support to have your data migrated.


Accounts Receivable

Customer email templates

You can now assign custom email templates to your customers so you can organize and style your content. Your custom email templates replace standard email templates that are sent based on transactions such as statements and invoices.

You can create or update a customer to add/modify the email templates. For more information:

Ability to list customer charge card records will no longer be supported

The get_list function for customer charge cards is scheduled for deprecation. This function will become unavailable in a future release, likely, 2021-R2. At this time, the only way to access customer credit card information will be through the Sage Intacct UI.

Important: Check your integrations now and remove this function to avoid problems when this function becomes unavailable in a future release, planned for 2021-R2.


Order Entry

Purchase order numbers in recurring order entry transactions

You can now include the customer provided purchase order number in your recurring order entry transactions.

See the customerponumber parameter for more information:

Automatically calculated, persistent ship-by dates

Order Entry transactions now include a persistent ship-by date that indicates when the shipment must be sent in order to meet the customer’s need-by date. The ship-by date is automatically calculated based on the need-by date and the estimated days in transit (as per the shipping method specified in the UI). If the estimated days in transit is not set, the ship-by date will be the same as the need-by date.

The ship-by date remains unchanged even when the transaction is converted, which is useful for tracking across workflows.

There is also a new shipped-date parameter for the transaction to indicate when the shipment was sent. The shipped date can be overriden at the line level.

For more information, see the shipbydate and shippeddate parameters on the following:


Contracts

Bill partial periods

Prorated billing schedules are now supported for contract lines. So, if you create lines at mid month for which you want to prorate billing, you can set the new PRORATEBILLINGPERIOD parameter to true. This option is available only when BILLINGMETHOD is Fixed price and BILLINGOPTIONS is Include with every invoice.

For more information, see the PRORATEBILLINGPERIOD parameter for the following:

Generate invoices by customer

You can now generate separate invoices for each customer. See the INVOICEBY parameter on the following:


Construction Early Adopter Program

Purchasing Change Orders

You can now manage changes to Purchasing agreements as your Construction job progresses.

To do this, modify or create Purchasing transaction definitions that enable change management. A transaction definition can identify a transaction as either a source transaction or a change-order transaction. By default, Purchasing transaction definitions have change management disabled.

Using your new transaction definitions, you can create a source transaction, then create change orders that modify that source. You can create a change order even if the source transaction has been partially or fully converted.

A change order can add new entries or modify existing entries on a given source transaction. For example, assume there is a source transaction definition, Source-001, and a change order transaction definition, Change-001.

The following creates a source transaction with one entry:

<create_potransaction>
    <transactiontype>Source-001</transactiontype>
    <datecreated>
        <year>2020</year>
        <month>06</month>
        <day>17</day>
    </datecreated>
    <vendorid>201</vendorid>
    <datedue>
        <year>2020</year>
        <month>07</month>
        <day>05</day>
    </datedue>
    <message>Source for project 19</message>
    <returnto>
        <contactname></contactname>
    </returnto>
    <payto>
        <contactname></contactname>
    </payto>
    <state>Pending</state>
    <potransitems>
        <potransitem>
            <itemid>A001</itemid>
            <warehouseid>WareHouse10004</warehouseid>
            <quantity>10</quantity>
            <unit>Each</unit>
            <price>99.99</price>
            <locationid>1</locationid>
        </potransitem>
    </potransitems>
</create_potransaction>

Assume the record number for the created source transaction is 255, and the record number for the created entry is 256. The following provides a change order that modifies the existing entry (changes the quantity to 15) and adds a new entry to the source transaction:

<create_potransaction>
    <transactiontype>Change-001</transactiontype>
    <datecreated>
        <year>2020</year>
        <month>06</month>
        <day>30</day>
    </datecreated>
    <createdfrom></createdfrom>
    <vendorid>201</vendorid>
    <message>Change for new requirements</message>
    <returnto>
        <contactname></contactname>
    </returnto>
    <payto>
        <contactname></contactname>
    </payto>
    <state>Pending</state>
    <potransitems>
        <potransitem>
            <itemid>A001</itemid>
            <warehouseid>WareHouse10004</warehouseid>
            <quantity>15</quantity>
            <unit>Each</unit>
            <price>100.99</price>
            <locationid>1</locationid>
            <relateddockey>255</relateddockey>
            <relateddoclinekey>256</relateddoclinekey>
        </potransitem>
        <potransitem>
            <itemid>A006</itemid>
            <warehouseid>WareHouse10006</warehouseid>
            <quantity>100</quantity>
            <unit>Each</unit>
            <price>80.99</price>
            <locationid>1</locationid>
            <relateddockey>255</relateddockey>
        </potransitem>
    </potransitems>
</create_potransaction>

You can delete a draft change order, but once it has approved, it cannot be deleted.

When you read a source transaction in the API, new output parameters help identify the changes that led to the current state.

New Purchasing transaction (header) fields:

New Purchasing transaction entry fields:

For more information:

Price conversion for Purchasing transactions

Converting a transaction moves the transaction to the next step in the workflow (for example, from purchase order to vendor invoice). In previous releases, a Purchasing transaction line could only be converted by quantity—you can now convert a line by price as well. The price you supply is used to to determine when a line is partially or fully converted.

For more information, see the conversiontype parameter on these functions:

Posting estimate entries to different budget periods

Customers sometimes need to post estimate entries to different budget periods in order to reflect ongoing changes to the project estimate. This can be important for financial reporting purposes.

You can now assign a period to the project estimate itself using ESTIMATEDATE, or assign different GL budget periods to estimate entry lines with EFFECTIVEDATE.

To choose between these two values for posting, you set the POSTTO parameter on the header to Estimate date or Effective date.

For more information:



This release is scheduled to go live beginning on the evening of August 21, 2020.


Web Services

Look up fields and relationships for querying

A new lookup function helps you get the most out of the query function. The lookup function lists all the fields and relationships for an object that can be used in the select and/or filter statements of your query. You can use lookup on both standard and custom objects (query does not yet support custom objects though).

The following shows part of a response from a lookup on the journal entry object, GLBATCH. Note the information provided for the fields, which includes valid values. Relationships that can be queried are listed after the fields.

<Type Name="GLBATCH" DocumentType="">
    <Fields>
        <Field>
            <ID>RECORDNO</ID>
            <LABEL>Record number</LABEL>
            <DESCRIPTION>Record Number</DESCRIPTION>
            <REQUIRED>false</REQUIRED>
            <READONLY>false</READONLY>
            <DATATYPE>INTEGER</DATATYPE>
            <ISCUSTOM>false</ISCUSTOM>
        </Field>
        ...
        <Field>
            <ID>STATE</ID>
            <LABEL>State</LABEL>
            <DESCRIPTION></DESCRIPTION>
            <REQUIRED>true</REQUIRED>
            <READONLY>false</READONLY>
            <DATATYPE>TEXT</DATATYPE>
            <VALIDVALUES>
                <VALIDVALUE>Draft</VALIDVALUE>
                <VALIDVALUE>Submitted</VALIDVALUE>
                <VALIDVALUE>Partially Approved</VALIDVALUE>
                <VALIDVALUE>Approved</VALIDVALUE>
                <VALIDVALUE>Posted</VALIDVALUE>
                <VALIDVALUE>Declined</VALIDVALUE>
                <VALIDVALUE>Reversal pending</VALIDVALUE>
                <VALIDVALUE>Reversed</VALIDVALUE>
            </VALIDVALUES>
            <ISCUSTOM>false</ISCUSTOM>
        </Field>
        ...
    </Fields>
 ...
    <Relationships>
        <Relationship>
            <OBJECTPATH>JOURNAL</OBJECTPATH>
            <OBJECTNAME>JOURNAL</OBJECTNAME>
            <LABEL></LABEL>
            <RELATIONSHIPTYPE>MANY2ONE</RELATIONSHIPTYPE>
            <RELATEDBY>JOURNAL</RELATEDBY>
        </Relationship>
        ...
    </Relationships>
</Type>

The information in the response helps you compose a query such as:

<query>
    <object>GLBATCH</object>
    <select>
        <field>RECORDNO</field>
        <field>STATE</field>
    </select>
    <filter>
        <equalto>
            <field>STATE</field>
            <value>Posted</value>
        </equalto>
    </filter>
</query>

Note that owned objects are not included in the lookup output. For more information, see Building more complex queries.

Query into private entities

By default, in a multi-entity company, queries from the top-level entity do not access data in private entities. You can set the new showprivate option to true if you want to query data in private entities. For example:

<query>
    <object>APBILL</object>
    <select>
        <field>RECORDNO</field>
        <field>VENDORID</field>
    </select>
    <options>
        <showprivate>true</showprivate>
    </options>
</query>

ReadByName now supports names with commas

Previously, you could not use readByName for a name that included a comma. To address this, a backslash escape character (\) is now supported. For example, assume you have two contact IDs:

The following returns both contacts:

<readByName>
    <object>CONTACT</object>
    <keys>Roberts\, Bob, Sara Sharpes</keys>
    <fields>*</fields>
</readByName>

Updated .NET and Node.js SDKs

In 2020 Release 1, Sage Intacct released a new XML query function that supports more robust, complex query statements than the legacy readByQuery function. The new query provides more operators, lets you sort results, perform aggregate operations such as sum or average, and use a larger page size limit. Perhaps the most interesting new capability is that you can get the values for fields on related objects and/or use them in filters.

The Sage Intacct SDKs for .NET and Node.js have been updated to include this new query capability. (The PHP SDK already supported the new query.)

Note: The new query does not currently support custom objects.

New examples

New examples for the SDKs show you how to use the new query and take advantage of its powerful features. Building and running the new examples will update the versions of the Sage Intacct SDKs:


Platform Services

List Platform Services applications

A new object, PTAPPLICATION, provides information about each Platform Services application installed in your company.

For example, the following lists the record number and application name for each installed Platform Services application:

<query>
    <object>PTAPPLICATION</object>
    <select>
        <field>RECORDNO</field>
        <field>APPLICATIONNAME</field>
    </select>
</query>

Data such as this is returned:

<PTAPPLICATION>
    <RECORDNO>10014</RECORDNO>
    <APPLICATIONNAME>T2 Additional features</APPLICATIONNAME>
</PTAPPLICATION>
<PTAPPLICATION>
    <RECORDNO>10016</RECORDNO>
    <APPLICATIONNAME>MCA My Conferencing App</APPLICATIONNAME>
</PTAPPLICATION>

For more information, see the functions that operate on PTAPPLICATION:

Visibility into installed components

Now, when a Platform application is published, all CSPs and onload scripts are included in the application wrapper. These components are also added to the Application Definition page when the application is installed. This reduces the risk of existing CSPs and onload scripts being accidentally deleted or overwritten in target companies.

More information about visibility into installed components is available in the Sage Intacct product help.

Trigger enhancements

We’ve simplified the process of creating a trigger that uses a document template, removing manual steps that took you out of your workflow. You no longer have to create and upload a document template prior to creating a trigger. See XML document templates in the Sage Intacct product help for details.

Problematic seed records now ignored

We fixed a potential issue with seed records in Platform applications. Before this release, you were able to install a Platform application that included seed records with problematic relationships. The problematic relationships used record numbers to specify related standard objects when they should have used the unique IDs. (Record numbers are not unique across companies.)

Starting with the current release, any seed records with these problematic relationships are ignored when installing Platform applications.

Important: Platform developers need to use the unique ID and not the record number when creating relationships in seed records.


General Ledger

Create budgets with details

You can now create a budget and its details all at once (batch) by creating a GLBUDGETHEADER object with owned GLBUDGETITEMS. You can also use update on GLBUDGETHEADER to add more budget details or modify existing budget details. A delete function lets you remove budget details.

For more information:

Important: The legacy budget objects (BUDGETHEADER and GLBUDGET) will be migrated to the new object types (GLBUDGETHEADER and GLBUDGETITEMS) in a future release (planned to occur between the 2020-R3 and 2021-R2 releases). After migration, create, update, and delete, when used on the old objects, will return error messages explaining that you need to use the new object names.

Cross-entity account allocation

You can now use cross-entity and cross-currency dynamic account allocations. To do so, enable the functionality in the header of the allocation definition, then specify the exchange rate for the allocation target.

See the ALLOWALLOCATION and EXCH_RATE_TYPE_ID parameters on these functions:


Project and Resource Management

Timesheet approval by proxy

You can now approve or decline timesheets on behalf of a different user. To do this, first create a Web services only user in the UI and grant this user Project permissions that include List and API Proxy for approving timesheets.

Next, send a request using the Web services only ID for the login, and provide the ID of a qualified user (in the approval chain) as the value for APPROVEDBY or DECLINEBY in the appropriate funtion.

For example, assume API_Proxy_1 is the Web services only user. The following request approves a timesheet on behalf of the user with ID jsmith:

<request>
    <control>
        <senderid>jsmith_ws_sender</senderid>
        <password>1234567</password>
        ...
    </control>
    <operation>
    <authentication>
        <login>
            <userid>API_Proxy_1</userid>
            <companyid>Johnson's Tractors</companyid>
            <password>3456789</password>
        </login>
        </authentication>
        <content>
            <function controlid="x99876">
                <approve>
                    <TIMESHEET>
                        <RECORDNO>1</RECORDNO>
                        <COMMENT>Approved for jsmith by API_Proxy_1</COMMENT>
                        <APPROVEDBY>jsmith</APPROVEDBY>
                    </TIMESHEET>
                </approve>
            </function>
        </content>
    </operation>
</request>

For more information:


Construction Early Adopter Program

Introducing project estimates

A project estimate enables you to track actual costs against estimated costs to determine whether your project is profitable. You can also create a project’s work breakdown structure (WBS) from an estimate.

After creating your project estimate, you use the project, task, and cost type dimensions to track actual costs across other applications, like AP, Purchasing, and the General Ledger.

For more information:

Override retainage percentage

You can now override the retainage percentage on entries of Purchasing or Order Entry transactions. For more information, see the new trx_amountretained parameter on create and update functions for:


Data Delivery Service

We are improving the Data Delivery Service processing times by limiting the duplicate objects in the queue. Only one object of the same type is allowed in the queue or processing state at the same time. If you run a delivery with an object that is already in the queue, your delivery job is cancelled.

For more information, see Data Delivery Service in the Sage Intacct product help.