This release is scheduled to go live on the evening of November 22, 2019 Pacific Time.


General Ledger

Organize account groups by purpose

You can now define purposes for account groups so that you can more easily build financial reports. Account group purposes are also available for filtering in lists.

You can work with account group purposes as follows:

You can specify account group purposes when creating and updating account groups. See the GLACCTGRPPURPOSEID parameter on the following:

Specify managers for account groups

When creating or updating account groups, you can use the new ACCTGROUPMANAGER parameter to designate a person to be consulted if changes are made to the account group. This is a free form field not tied to users—you can provide a partner name, or any other name.

For more information:

Enhanced transaction allocation

You can now create transaction allocations that use a combination of fixed amounts and percentages. The new Fixed amount with over/under logic choice for the TYPE parameter lets you distribute fixed amounts first, in the order they occur in the transaction allocation definition, then apply any remaining amounts specified as percentages. Entries for absolute values must come before percentages, and percentages must always total to 100%. You use the new VALUETYPE parameter to identify whether each entry is an Amount or a Percent.

See the TYPE and VALUETYPE parameters on the following:


Accounts Receivable

New AR Payment object

You can use the new ARPYMT object to record payments against AR invoices or debit memos. The new object lets you apply credits/discounts at the line level through one or more payment detail (APPYMTDETAIL) objects. You can even apply multiple credits to the same line by providing multiple payment details for that single line. Finally, you can apply credits or discounts from a different invoice (for the same customer) on the current invoice. The new payment object does not currently support advances—continue to use the legacy apply_arpayment function for that purpose.

When an ARPYMT does not cover the total balance, invoice lines are paid in full, starting with the first line and continuing down the list until the payment amount is used. This is known as the waterfall method, and it means that you should list any high priority payments first in invoices/debit memos.

In the past, a partial payment was distributed across multiple lines instead of using the waterfall method. For multi-entity companies with inter-entity payments, the waterfall method can reduce the number of inter-entity transactions simply by not touching every line.

Starting with this release, if you create a payment using the legacy create_arpayment function, the resulting record will an ARPYMT object, not an ARPAYMENT object. The existing ARPAYMENT object is still available for backwards compatibility (and to support advances), but it does not allow for line level credits/discounts.

Smart Events, Smart Rules, and Smart Links can be used on the new ARPYMT object.


Accounts Payable

Legacy create_paymentrequest now creates APPYMT object

To coordinate with the retirement of the Select bills to pay functionality in the UI, the create_paymentrequest function now creates an instance of the new payment object, APPYMT, instead of an instance of the legacy APPAYMENT object as in previous releases. With this comes a new distribution method called waterfall—lines are paid in full, starting with the first line and continuing down until the payment amount is used.

Any Smart Events, Smart Rules, or Smart Links on the legacy APPAYMENT payment object were migrated to the new APPYMT object for this release, but you need to verify these changes as described below.


Contracts

Generate invoices by project

Prior to this release, you had to set filters and create multiple contract invoice runs in order to create separate invoices for each project associated with a contract. You can now use the INVOICEBY parameter to generate separate invoices for each project.

See the INVOICEBY parameter on the following:


Project and resource management

Project tasks available on transactions

Starting with this release, you can provide a task ID along with the parent project when creating and updating various transactions using the API. This let’s you report on projects at a more granular, task level.

See the task ID parameter on the following:


Inventory Control

More comprehensive inventory totals tracking

You now have visibility into all the inventory totals your organization uses, including onhand, onhold, onorder, damaged, requisitioned, scrap/spoilage, or custom totals. For example, at the end of each month, warehouse managers can now report on inventory that was dispositioned as damaged, lost, or scrapped.

For more information:

More precise date tracking

More precise date tracking for order management is now available. Instead of creating custom fields for more detailed tracking, you can enable a new configuration option to increase the number of shipping date fields in Purchasing and Order Entry transactions.

New fields for tracking numbers and customer PO numbers are also available on Order Entry transactions.

Purchasing transactions

New Purchasing header fields

  • needbydate
  • donotshipbeforedate
  • donotshipafterdate
  • promiseddate
  • contractstartdate
  • contractenddate
  • cancelafterdate

New Purchasing line level fields

  • needbydate
  • donotshipbeforedate
  • donotshipafterdate
  • promiseddate
  • dateconfirmed
  • cancelafterdate
  • dateshiptosupplier

Order Entry transactions

New Order Entry header fields

  • needbydate
  • cancelafterdate
  • donotshipbeforedate
  • donotshipafterdate
  • servicedeliverydate
  • trackingnumber
  • customerponumber

New Order Entry line level fields

  • needbydate
  • shipby
  • donotshipbeforedate
  • donotshipafterdate
  • datepickticketprinted
  • cancelafterdate

Support for integrated scanner label printing

You can use the new AUTOPRINTLABEL parameter for inventory items as part of your process to trigger an integrated third-party tool that creates scanner labels.


DDS enhancements

You can now run multiple DDS jobs from the same runDdsJob call. The jobs must be of the same job type—either get all records or get the changed records only.

You can also run a set of synchronous DDS jobs for changed records for up to five objects. Synchronous jobs can help avoid reporting gaps because each job has the same starting timestamp.

For more information:

Individual asynchronous DDS jobs are supported as before.


Customization and Platform Services

Content security policy enforced by default

All new companies are now configured with the content security policy enforced by default. As a result of this change, any Customization Services package or Platform Services application that requires outside resources, such JavaScripts or images, require that their resource domains be whitelisted.

Sage Intacct is moving towards enforcing content security policy in all companies, instead of just turning it on by default.

See content security policy in the Sage Intacct product help for more information.

Customization Services in Action UI

With this release, Customization Services can take on the modern look and feel of the Action UI. You can use Action with the click of a button in your personal preferences—see the product help for details.

You will see the Action UI in pages for working with Smartlinks, Smart Events, Smart Rules, and custom reports. You are encouraged to switch to the Action UI now to enjoy the improved experience before the Action UI becomes the default for Customization Services in a future release.

Smart Event job history enhancements

When viewing the history of Smart Events that ran in a company, you can now click the name of the record that triggered the Smart Event to open it.

Platform Services in Action UI

With this release, Platform Services applications can take on the modern look and feel of the Action UI. Platform developers enable their applications to use the new UI with the click of a button in their personal preferences—see the product help for details.

Important: Application developers are encouraged to turn on the Action UI now so there is ample time to correct any display issues before the Action UI becomes the default for Platform applications in a future release.

Application developers also experience this enhanced UI as they build and update their applications.

The retirement of the Select to pay functionality in AP corresponds with the retirement of the underlying legacy object, APPAYMENT. When you work with AP payments in the UI or via Web Services APIs, you only create and access APPYMT objects from now on.

Any Smart Events, Smart Rules, or Smart Links on the legacy APPAYMENT object have been migrated to the new APPYMT object as part of this release. This should be seamless, but we recommend that you take action to avoid any potential issues.

Important: Check any relevant Smart Events, Smart Rules, or Smart Links to confirm the migration was successful. Also, you may have older Smart Events, Smart Rules, or Smart Links that were not working in previous releases that may be activated by the migration to the new object.

Better browser support in Platform

When working with the page editor in Safari and Chrome browsers, error messages about browser support no longer appear.

Cardinality and direction of relationships in Platform

As part of a long term effort to improve the performance of relationships, we are updating some of our infrastructure.

As a result of these changes, we no longer support the capability of changing the cardinality or direction of an existing relationship. For example, you cannot change a one-to-one relationship to a one-to-many relationship. Instead, delete the relationship and re-add it with the cardinality and direction you want.

This restriction applies when using the UI or when updating platform applications with a new XML file.


Infrastructure Changes

This section includes information about current and upcoming infrastructure changes that may affect developers.

These changes should have minimal impact on your day-to-day work, but you may notice differences related to the changes and you probably need to prepare for upcoming changes.

If you have concerns after reading this section, submit a support case.

Server timezone migrating to UTC

Historically, servers for Sage Intacct applications ran with their operating system in Pacific Standard Time (PST). Moving forward, servers will use Coordinated Universal Time (UTC) with timezone offsets to better support international standards.

In general, developers should not be affected by this change. However, there are situations where this change might cause events to occur earlier or later. For example, this can happen if you have:

  • Scheduled DDS jobs
  • Processes where scheduled CSV reports delivered to cloud storage trigger automation

As before, Sage Intacct uses company locale settings as the primary source for date and time operations in the application.

There are some cases where UTC was exposed prior to the timezone change. For example, this is true for the value returned for session timeout in Web Services API calls: <sessiontimeout>2019-09-20T11:10:31-07:00</sessiontimeout>

Scheduled offline job execution now tied to company locale

Previously, daily scheduled jobs executed after midnight PST for all companies. Scheduled jobs now execute based on your company’s locale setting, so these jobs execute closer to midnight for your location.

Data center expansion

Sage Intacct is adding global data centers to support international expansion. You may notice that the Sage Intacct URL subdomain now reflects the instance where company runs.

You continue to use www.intacct.com to log in, but after logging in you might see the URL change to www-p02.intacct.com, www-p03.intacct.com, or something similar.

This change has no impact on the API endpoint, which remains https://api.intacct.com/ia/xml/xmlgw.phtml as before.

Note for Platform developers

Platform applications should not include links to Sage Intacct features using absolute or relative URLs. If your Platform application includes a link with an absolute path (such as https://www.intacct.com/ia/acct/dash.phtml), it is susceptible to breaking due to data center expansion (or other causes) and should be removed.


Provide feedback