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:
- Create more than one contract per project.
- Create one or more contract lines for billing purposes and allow each contract line to be set to a specific billing type:
- Progress billing:
- Each contract line has its own billing value.
- Billing value can be updated by price changes from project change orders.
- Time & Materials billing:
- Cost plus to max.
- Unlimited costs billed to customer.
- Costs limited to contract line price.
- Universal rate tables that can be applied to contract lines for markup or pass-through purposes.
- Special fields and totals tracked on the project contract and contract line.
- Hold retainage on each billing.
- Task mapping - map one or more tasks to a project contract line to group T&M expenses for project contract billing.
- Produce an AIA G702-703 type bill.
- Progress billing:
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:
- Timesheet Entries
- Purchase Order Entries
- Account Payable Entries
- General Ledger Entries
- Credit Card Entries
- Employee Expense Entries
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:
- Change Requests now have COSTEFFECTIVEDATE and PRICEEFFECTIVEDATE fields
- Project Change Orders now have a PRICEEFFECTIVEDATE field.
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.
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:
- If you provide a new tax detail ID, the VAT amount for the line subtotal will be calculated using the percentage value set in the tax detail.
- If you provide a new tax detail ID and a new VAT amount, the new amount will be applied to the line subtotal.
See the linesubtotals
object for the following:
- Create Purchasing Transaction (Legacy)
- Update Purchasing Transaction (Legacy)
- Create Order Entry Transaction (Legacy)
- Update Order Entry Transaction (Legacy)
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.
Disregard temporary read-only fields related to assets
In this release, temporary fields related to assets will appear in responses from several API functions. In particular:
- An
inspect
call on the GLENTRY object returns anASSETID
parameter. - A
read
call on the GLBATCH object returnsASSETID
,ASSETNAME
, andASSETDIMKEY
parameters.
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)
- Provide vendor email templates (generic functions)
- Vendor account number/location changes (generic functions)
- Enhanced Pay to, Return to, and Contact to functionality (object-specific and generic functions)
- Important: All behavior changes for existing functionality (object-specific and generic functions)
- Provide vendor bank file details when using electronic payment providers (generic functions)
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.
- Create Vendor
- Update Vendor
- Get Vendor Email Template Object Definition
- List Vendor Email Templates
- List Vendor Email Templates (Legacy)
- Get Vendor Email Template
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)
- Enhanced Bill to and Ship to functionality (object-specific and generic functions)
- Important: All behavior changes for existing customer functions (object-specific and generic functions)
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:
Bids and Quotes
Purchase Orders
Purchase Order Change Orders
Purchase Receivers
Purchase Order Invoices
Purchase Returns
Purchase Credits
Purchase Debits
Purchase Clearing Receivers
Subcontract Bids
Subcontracts
Subcontract Change Orders
Subcontract Invoices
Internal Supply Requisitions
Purchase Requisitions
Blanket POs or Vendor Contracts
Grant Requests
Grant Awards
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.
Sales Quotes
Sales Orders
Sales Order Change Orders
Sales Order Invoices
Sales Returns
Sales Shippers
Sales Credits
Sales Debits
Sales Clearing Shippers
Contract Bids
Contracts
Contract Change Orders
Contract Invoice Preview
Contract Invoices
Project Invoices
Rev Rec Activation
Forecast Revenue
Pledges
Gifts and Donations
Pledge and Gift Invoices
Grant Applications
Grant Award Invoices
Event Reservations
Event Confirmations
Conferences and Gatherings
Event Invoices
Membership Registrations
Membership Invoices
Invoice Preview
Invoices
Tuition Registrations
Tuition Invoices
Sponsorships
Sponsorship Invoices
Subscriptions
Subscription Invoices
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.
Inventory Adjustment
Build Kits
Disassemble Kits
Inventory Damaged Goods
Inventory Receipt
Inventory Scrap or Spoilage
Inventory Shipper
Warehouse Transfer
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:
- Create Build / Disassemble Kit Transaction (Legacy)
- Create Purchasing Transaction
- Update Purchasing Transaction
- Create Order Entry Transaction
- Update Order Entry Transaction
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:
-
Create an in-transit warehouse transfer and set the TRANSFERTYPE to In transit. Specify the date the transfer was created as the TRANSACTIONDATE and the estimated shipping and receiving dates as the OUTDATE and INDATE, respectively. Include the list of items to move, and then save the transfer as a Draft or mark it immediately as In transit. The information in the draft transfer can be printed for warehouse workers to use as a pick list. When the items have been picked and shipped, you can change the transfer state to In transit.
-
Setting the transfer state to In transit decreases the WONHAND quantity of included items at the originating warehouse by the number of units being transferred, and adds that quantity to the receiving warehouse as WINTRANSIT. It also transfers the value of the quantity from an inventory account to an in-transit clearing account.
-
When the shipment arrives at the receiving warehouse, set the state of the transfer to Posted. Setting the state to Posted moves the items from WINTRANSIT to WONHAND at the receiving warehouse, and The value of the received inventory is moved from the in-transit clearing account into the appropriate inventory accounts.
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:
- Create Contract Invoice Preview
- Create Contract Invoice Filter Set
- Update Contract Invoice Filter Set
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:
- Labor
- Material
- Equipment
- Subcontract
- Overhead
- Other
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:
Current Estimate
Original Estimate
Current Forecast - At Completion
Historical Forecast - At Completion
Future Forecast - At Completion
Current Forecast - To Completion
Historical Forecast - To Completion
Future Forecast - To Completion
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:
- Project Change Orders
- The
PROJECTCHANGEORDERID
parameter on Create Change Request and Update Change Request
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:
- Create Purchasing Transaction (Legacy)
- Update Purchasing Transaction (Legacy)
- Create Order Entry Transaction (Legacy)
- Update Order Entry Transaction (Legacy)
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:
- Contact support to plan your data migration if you have not already been contacted. If you were using the legacy functions previously, you cannot start using the new functions without the migration.
- Update any function calls to use the new budget objects.
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:
- Variable unit divisor (
VARUNITDIVSR
) is set to 1. - Variable unit rate (
VARUNITRATE
) is set to 0.
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:
- Item details — General information for an item, such as the primary country of origin, the 12-digit Universal Product code, the 13-digit European Article Number, whether the item is a safety, restricted, compliant item, and whether the item has certain approvals.
- Measures — Physical characteristics of the item, such as height, weight, length, volume, thickness, and diameter. These attributes can help you select the correct-sized bins for putting items away or plan for packaging and freighting needs.
- Commercial — E-commerce information for the item, such as the brand, category, size, color, web name, and web description.
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:
- See the
PARTIALEXEMPT
parameter on these functions: - See the
partialexempt
parameter on these functions:
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:
- CHANGEREQUESTKEY
- CHANGEREQUESTID
- CHANGEREQUESTENTRYKEY
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:
HASCHANGE
istrue
if there are draft or posted change orders to this transaction. Once change orders have been applied, the amounts or dimensions for the source transaction cannot be modified with anupdate
call, nor can you delete the source transaction. However, you can submit additional change orders.REVISEDTOTAL
is the total base currency amount including line items and subtotal amounts.REVISEDSUBTOTAL
is the total base currency amount for line items only.TRX_REVISEDTOTAL
is the total transaction currency amount including line items and subtotal amounts.TRX_REVISEDSUBTOTAL
is the total transaction currency amount for line items only.POSTEDCHANGESTOTAL
is the sum of all amounts posted to this source transaction by change orders.
New Order Entry transaction line fields:
REVISEDUNITQTY
is the original quantity (before applying the unit of measure) plus changes from posted change order lines.REVISEDQTY
is the original quantity (after applying the unit of measure) plus changes from posted change order lines.DRAFTCHANGEUNITQTY
is sum of all the quantities (before applying the units of measure) of all draft change order lines.DRAFTCHANGEQTY
is sum of all the quantities (after applying the units of measure) of all draft change order lines.REVISEDUNITVALUE
is the revised extended price.REVISEDVALUE
is the revised base currency extended price.TRX_REVISEDVALUE
is the revised transaction currency extended price.REVISEDUNITPRICE
is the revised price.REVISEDPRICE
is the revised base currency price.TRX_REVISEDPRICE
is the revised transaction currency price.DRAFTCHANGEPRICE
is the sum of the price values of all applicable lines in draft change orders whereconversiontype
isPrice
.POSTEDQTYCHANGES
is the sum of the quantity values of all applicable lines in posted changes orders whereconversiontype
isQuantity
.POSTEDCHANGEEXTPRICE
is the sum of the price values of all applicable lines in posted change orders whereconversiontype
isPrice
.POSTEDCHANGEEXTBASEPRICE
is the sum of the base price values of all applicable lines in posted change orders whereconversiontype
isPrice
.
For more information:
See the relateddockey
and relateddoclinekey
parameters here: