2020 Release 4

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

Web Services

Query custom objects

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

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

Hierarchy of application objects

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

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

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

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

Asynchronous callback for readReport

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

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

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

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

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

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

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

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

For more information:

Sage Intacct SDK enhancements

SDK for .NET

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

Version 3.0.0

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

The SDK includes:

  • New PurchasingTransactionApprove and PurchasingTransactionDecline classes.
  • Enhanced AP payment:
    • New ApPayment* classes that support the latest AP payment model (introduced in the XML API as APPYMT in 2017-R3). The old ApPaymentRequest* classes are no longer available.
    • New classes that let you apply line level credits and discounts for payments:
      • ApPaymentDetailBill
      • ApPaymentDetailCreditMemo
  • Microsoft.Extensions.Logging support.

See the getting started example to learn about the SDK.

Version 2.3.0 of the SDK includes:

  • New ApPaymentRequestDecline class.
  • New TaskId parameter on AbstractGlEntry.
  • New ShowPrivate parameter on NewQuery.QueryFunction.
  • New SummaryRecordNo parameter (known as batchkey in the XML API) on ArPaymentCreate.

SDK for PHP

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

  • New ApPaymentRequestDecline class.
  • New TaskId parameter on AbstractGlEntry.
  • New ShowPrivate parameter on NewQuery.QueryFunction.
  • New PurchasingTransactionApprove and PurchasingTransactionDecline classes.
  • New SummaryRecordNo parameter (known as batchkey in the XML API) on ArPaymentCreate class.

Refer to GitHub for complete information, including fixes.

See the getting started example to learn about the SDK.

SDK for Node.js

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

  • New ApPaymentRequestDecline class.
  • New TaskId parameter on AbstractGlEntry.
  • New showPrivate parameter on Query function.

Refer to GitHub for complete information, including fixes.

See the getting started example to learn about the SDK.

Customization Services and Platform Services

Improved flow for moving custom pages to Action UI

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

  • Use the new UI option (Custom and customized pages) in your user preferences to update pages created or customized using Platform and Customization Services to Action UI.
  • Check that each page looks correct in Action, then set its layout to Action UI in Page Editor. This overrides individual preferences so that the page is only available in Action UI.

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

Content Security Policy administration

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

  • View all CSP violations in a company on the Company Information page.
  • View the CSP violations on a specific page in Page Editor mode in Platform Services.

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

Trigger log

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

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

General Ledger

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

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

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

  • Contact support to plan your data migration—you cannot start using the new APIs without the migration if you were using the legacy APIs previously.
  • Update any API calls to use the new budget objects.

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

Accounts Receivable

Customer email templates

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

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

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

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

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

Order Entry

Purchase order numbers in recurring order entry transactions

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

See the customerponumber parameter for more information:

Automatically calculated, persistent ship-by dates

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

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

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

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

Contracts

Bill partial periods

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

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

Generate invoices by customer

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

Construction Early Adopter Program

Purchasing Change Orders

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

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

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

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

The following creates a source transaction with one entry:

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

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

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

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

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

New Purchasing transaction (header) fields:

  • HASCHANGE is true if there are draft or posted change orders to this transaction. Once change orders have been applied, the amounts or dimensions for the source document cannot be modified with an update call, nor can you delete the source document. 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.

New Purchasing transaction entry fields:

  • REVISEDUNITQTY is the original quantity (before applying the unit of measure) plus changes from posted change orders.
  • REVISEDQTY is the original quantity (after applying the unit of measure) plus changes from posted change orders.
  • DRAFTCHANGEUNITQTY is sum of all the quantities (before applying the units of measure) of all draft change order lines against this line.
  • DRAFTCHANGEQTY is sum of all the quantities (after applying the units of measure) of all draft change order lines against this line.
  • 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.

For more information:

Price conversion for Purchasing transactions

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

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

Posting estimate entries to different budget periods

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

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

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

For more information:

Provide feedback