2022 Release 2 by Sage Intacct on 2022-04-18

This release is scheduled to go live beginning on the evening of May 13, 2022.

Accounts Receivable

Create Dunning Level Definitions

You can now create dunning notifications to send to customers. Dunning notices allow the collection of payments after the invoice is due. You can also use Dunning notices to track the previously sent email notices that have already been sent to customers.

You can also set Dunning level rules for any combination of minimum/maximum days or amounts for which to send dunning notifications. You can define dunning levels to trigger specific email or print templates associated with a particular level to be sent to customers.

Note that emails and print dunning notices are sent using the Intacct UI.

You can also set a default currency to use for Dunning Notifications based on the location of the company.

For more information, see:

Construction

Create project contracts that are integrated with change management and billing

A new Project Contracts feature has been added to Sage Intacct to meet the contract and billing needs of construction projects. Project contracts include many new capabilities that are fully integrated with existing Sage Intacct functionality in the areas of projects, timesheets, invoicing, and more.

Some of the new project contract capabilities are:

The new API objects for Project Contacts are:

Integration with project contacts has been added to:

Use rate tables for efficient, standardized contract billing

Rate Tables let you define markup or discount rates and prices for specific types of construction-related expenses. You can use these rate tables with Time & Materials billing to set markups to match your business needs. You can define rate tables for each of these expense areas and apply them to project contract lines:

For more information, see Rate Tables.

New employee timesheet options to bill by position, class, shift, and union

Sage Intacct now includes several new objects related to employee labor that you can use on timesheets and as the basis for billing rates in rate tables:

Control the post of updates to GL budgets from project estimates and project contracts

Construction projects sometimes have a need to control when updates post to GL budgets, or to show change orders that fall within a specific billing period when applying for payment. New fields have been added to change requests and project change orders to make this possible:

Contracts

Support for perpetual terms

To better support business-to-customer (B2C) contracts, a new perpetual (Evergreen) term type is available for contracts.

The new TERMTYPE parameter lets you specify whether you want a termed or Evergreen contract. For a termed contract, an end date is required. For an evergreen contract, an Evergreen template is required.

By default, lines for an Evergreen contract have their RECURRING flag set to True.

See the TERMTYPE and EVERGREENMACRO parameters for the following contract functions:

See the RECURRING parameter for the following contract-line functions:

Create invoices using policies

You can now create invoices using policies through the Contract Invoice Policy object (note that this object used to be named Contract Invoice Filter Sets).

Using the Contract Invoices object, you can reference a specific policy using the POLICYNAME field.

For more information, see:

Data Delivery Service

Ability to select filters, fields to return, and field order

The runDdsJob request now accepts an optional query parameter that allows you to limit the data to only objects that match a filter, and specify the fields that you want included in the data and the order of the fields. The documentation now includes a list of aggregated objects and common fields that can be used for filtering those objects.

General Ledger

Journal entry transaction source marked for bank transactions

An optional TRANSACTIONSOURCE parameter has been added to journal entries to identify the source of each entry. The value is set to BANK for entries that are created from bank transactions.

Create Journal Entry

Run standard reports asynchronously

To increase efficiency and reduce timeouts, the Get Account Balances by Dimensions report can now be run asynchronously, and the report retrieved when it is complete.

Get Account Balances by Dimensions, Asynchronous

Inventory Control

Inventory Work Queue Orders and Inventory Work Queue Details

This feature is currently available to early adopters only.

Fulfillment is the process of taking a sales order through shipping and invoicing.

The new Inventory Work Queue Orders and Inventory Work Queue Details features allow for organizing which orders get processed first, kinds of items being shipped, the ability to fulfill the entire order, and so on.

The Work Queue Orders object (INVENTORYWQORDER) allows for a high-level querying of which items are on hand, which items are available, allowing for items to be held, and tracking the pick and pack containers in which items are shipped.

The Inventory Work Queue Details object (INVENTORYWQDETAIL) allows for a detailed listing of items in your inventory, and whether or not the product is paused within the fulfillment workflow.

For more information, see:

Include non-inventory items in inventory

The addition of an ENABLEFULFILLMENT parameter to ITEM objects allows non-inventory items to be visible in inventory so that they can be added to kits.

The new parameter has been added to these operations:

Inventory tracking for stockable kits and components

Stockable kits and/or their components can now be tracked for inventory management and tracking purposes as stockable kits are built and disassembled. A Build Kits transaction will decrease component stock from specified inventory locations and increase the number of stockable kits in inventory. A Disassemble Kits transaction reverses the inventory changes.

See Stockable Kit Transactions for more information.

API support for Inventory Cycle Counts

This release adds initial API support for working with inventory cycle counts, including the ability to create cycle counts, add items to be counted, and update item quantities after the count.

See Inventory Cycle Counts for more information.

Tax Schedules

Setting the default tax solution and tax schedule for contacts, vendors, or customers (AU, GB, and ZA only)

You can now set a default tax schedule for contacts, vendors, or customers using the TAXSCHEDULE and TAXSOLUTIONID fields.

With this update, you can set the tax information for contacts, vendors, or customers to a default value that will be used on Accounts Receivables and Account Payable transactions. This would avoid the need for manual entry of a tax solution for these types of transactions.

For contacts, vendors, and customers, you can set the default tax schedule through the respective APIs to be applied to all AP or AR transactions. The default tax schedule can be overridden through the UI for a particular contact, vendor, or customer if needed.

This feature is supported in both the legacy 2.1 and updated 3.0 APIs.

For more information, see:

2022 Release 1 by Sage Intacct on 2022-01-15

This release is scheduled to go live beginning on the evening of February 18, 2022.

Projects

Track federal grant information for your projects

You can now track CFDA (Catalog of Federal Domestic Assistance) grant information for your projects. See the CFDA and other related parameters for the following project functions:

Cash management

Credit card reconciliation in bank feeds

In previous releases, only bank accounts were supported when using bank feeds via the API. With this release, credit card accounts are supported as well. You can provide a financial entity (FINANCIALENTITY) to identify your connected credit card account, then reconcile your account via the API. You can use online bank feeds from Sage Cloud Services, or you can manually create a bank feed that provides your own XML transaction records.

When creating XML transactions for a credit card account, you can specify either charge or payment as the transaction type. Alternatively, you can specify withdrawal or deposit for a bank account. For more information, see the TRANSACTIONTYPE parameter here:

In addition, a read operation on a bank feed object now provides the name of the financial entity (FINANCIALENTITYNAME), whereas in the past, only the financial entity ID was included. There is also a new parameter that indicates the account type (FINANCIALACCOUNTTYPE), either Bank or Credit card.

Construction

Specify primary documents for workflows

In construction, users might need to associate specific documents with any resulting downstream transactions. Likewise, the downstream transactions should link back to the originating document. Now when you create or update a purchasing transaction definition in the API, you can set the PRIMARYDOC parameter to true so that the transaction is identified as a primary document. Then, all documents created from the transaction definition, whether automatically or manually, will contain a link to that primary document. Once you enable PRIMARYDOC for a purchasing transaction definition, you can’t disable the option.

When reading a downstream transaction, your response might include something like the following, where two transaction items point back to a primary doc:

<PRIMARYDOCKEY>51</PRIMARYDOCKEY>
<PRIMARYDOCLINEKEY>169</PRIMARYDOCLINEKEY>

See the PRIMARYDOC parameter for the following:

Purchasing and Order Entry

Override calculated VAT

When importing or updating Purchasing and Order Entry transactions in VAT-enabled companies, you may need to override the calculated VAT amount to match a tax invoice or for other reasons. There are two ways to use the new linesubtotals object within order entry and purchasing transactions to override the calculated VAT:

See the linesubtotals object for the following:

Accounts Payable

No required fields when creating draft bills

You can now create a draft bill (ACTION set to DRAFT) without providing the minimum fields that are required when posting a bill. You must provide values for those fields before a draft bill can be posted. This change only applies to the create APBILL request and not to the legacy create_bill request.

Contracts

Support for renewal forecast

To support the renewal forecast feature, the system can create CONTRACTDETAIL, CONTRACTBILLINGSCHEDULE, and CONTRACTREVENUESCHEDULE objects with a new STATE value of Renewal forecast.

Objects in this state cannot be modified. If you have existing integrations that involve these objects, you might see unexpected data after February 18, 2022.

To ensure that your integrations affect only the data you want, exclude objects in this state, for example:

<query>
    <object>CONTRACTDETAIL</object>
    <select>
        <field>RECORDNO</field>
        <field>STATE</field>
    </select>
    <filter>
        <notequalto>
            <field>STATE</field>
            <value>Renewal forecast</value>
        </notequalto>
    </filter>
</query>

Miscellaneous

Get query response in CSV or JSON

A new returnformat option for query requests lets you specify the format that will be used in the response, either XML (default), CSV, or JSON. For example, this request would return the list of vendors that are owed more than $100 as plain-text CSV:

<query>
    <object>VENDOR</object>
    <select>
        <field>RECORDNO</field>
        <field>TOTALDUE</field>
    </select>
    <filter>
        <greaterthan>
            <field>TOTALDUE</field>
            <value>100</value>
        </greaterthan>
    </filter>
    <options>
        <returnformat>csv</returnformat>
    </options>
</query>

See Response data format on the Query page for more information and sample responses.

In this release, temporary fields related to assets will appear in responses from several API functions. In particular:

These parameters are not supported in any operations and will be removed in a future release.

2021 Release 4 by Sage Intacct on 2021-10-18

This release is scheduled to go live beginning on the evening of November 12, 2021.

Accounts Receivable

Create AR advances without first creating summaries

The new ARADVANCE object allows you to record advances from customers before creating invoices, such as if a customer pays a deposit or retainer. In addition, a company’s Accounts Receivable configuration can be set to post advances to automatically create payment summaries (daily, or monthly, or one per advance) or to existing summaries (which maintains pre-R4 workflows).

AR Advances can have multiple line items so that an advance can be applied to multiple locations, departments, or projects, etc., as needed.

Once an invoice is created, advances can be applied to the invoice with an ARPYMT request.

The new ARADVANCE object should be used to create advances instead of the legacy ARPAYMENT object.

For more information, see the AR Advances documentation:

Accounts Payable

Electronic payment service (Early Adopter program)

Create a provider bank account for rebates

When creating or updating a provider bank account, you can now specify that the account is for rebates.

See the ISREBATEACCOUNT parameter on the following functions:

Vendors now own their electronic payment provider information

When creating or updating vendors, you can use the new PROVIDERVENDOR parameter to include information to link to one or more electronic payment providers.

For details, see thePROVIDERVENDORS parameter on the following:

The existing functions that operate directly on the PROVIDERVENDOR object remain unchanged.

Payment provider bank account information for checking accounts

You now get information about the payment provider bank account when getting a checking account.

Note: 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. Currently, Corporate Spending Innovations (CSI) is the only supported provider.

2021 Release 3 by Sage Intacct on 2021-07-15

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

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 (object-specific and generic functions)

Previously, when using a generic 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 object-specific 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 an object-specific or generic 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 object-specific or generic updates.

In a related enhancement, you can now use VENDORCONTACTS in generic 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 (generic functions)

You can now specify vendor email templates (VENDOREMAILTEMPLATES) using generic 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 where entries are appended to the set.

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 (generic functions)

You can now specify the vendor account number and location (VENDORACCTNOLOCATIONS) in generic 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 where entries are appended to the set.

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 (object-specific and generic functions)

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

Similarly, using an object-specific update_vendor with contactinfo, payto, returnto, and contactto1099 appends to the contact list.

Important: All behavior changes for existing vendor functionality (object-specific and generic functions)

Function Current behavior Previous behavior
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.
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.
create
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.
create_vendor
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.
create
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.
create_vendor
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.
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.
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.
create
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.
create_vendor
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.
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.
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 (generic 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 (object-specific and generic functions)

Previously, when using a generic 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 object-specific 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 object-specific or generic updates 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 object-specific or generic updates.

In a related enhancement, you can now use CUSTOMERCONTACTS in generic 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 (object-specific and generic functions)

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

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

Important: All behavior changes for existing customer functions (object-specific and generic functions)

Function Current behavior Previous behavior
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.
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.
create
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.
create_vendor
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.
create
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.
create_vendor
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.
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.
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.
create
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.
create_customer
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.
 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.
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 generic 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.

You can include the tracking information in the item details when creating or updating a stockable kit. Note that lot numbers and serial numbers are no longer mutually exclusive in item details.

In addition, Inventory Control, Purchasing, and Order Entry transactions support entering tracking information in the item details for stockable kits.

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

In-transit warehouse transfers

With the new “in transit” warehouse transfer type, you can account for the time it takes to move inventory 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:

2021 Release 2 by Sage Intacct on 2021-03-26

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: