This release is scheduled to go live on the evening of November 16, 2018 Pacific Time.
Enhanced API session management
You can now initiate a new entity-level session from a top-level session using an existing session ID. You can also use this approach to create a new entity-level session from the current entity-level.
To allow for this, the getAPISession function has been enhanced to accept a
locationid parameter that lets you specify the entity ID. The following example shows a request that uses an existing session ID for authentication and gets a new session for the entity whose
locationid is Arizona:
You can also provide the
locationid when getting a new session using your company login credentials.
You cannot currently get a top level session ID from an entity level session.
Entity ID now returned in all responses
All API functions now provide a location ID in the authentication element of the response so that you always know whether you are interacting at the top level of a company or at an entity level. An empty
locationid element means you are at the top level.
Return the dimension information of a company
You can now return the dimension information of a company using the new getDimensions function. This is especially useful for integrators needing to dynamically load a company’s dimensions.
Return financial information of a company
You can now return financial information of a company using the new getFinancialSetup function.
The replenishment process lets you automate reordering and fulfillment for cost-effective inventory management. With this release, you can use the API to set up warehouses, vendors, and items to include varying levels of replenishment settings so that you are ready to run snapshots and replenishments in the Sage Intacct UI.
You can enable replenishment on warehouses. See the
ENABLE_REPLENISHMENT parameter on these functions:
You can specify a default lead time on vendors. See the
DEFAULT_LEAD_TIME parameter on these functions:
You can enable replenishment on an item and set up replenishment parameters for the item across vendors, for specific vendors, and for specific warehouse/vendor combinations. See the various replenishment parameters on these item functions:
The following correlates the replenishment parameters for items on the UI page (blue text) to their location in API calls (orange text):
Learn more about setting up replenishment in the Sage Intacct product help.
Landed cost for inventory items
You can now create inventory items with landed costs.
See the information about the
LANDEDCOSTINFO parameter on these functions:
Cost of goods sold adjustments for closed periods
Landed costs and other inventory operations, such as changing an item’s standard cost, can affect the cost of goods sold (COGS) in closed periods. Consider the following examples:
- You add/modify landed costs for an item and want the changes to apply for purchase orders in closed periods.
- You change the standard cost of an item and use the Maintain Inventory Valuation tool to adjust the unit cost in the inventory subledger for closed periods.
In both scenarios, the inventory subledger is correctly updated, but the general ledger is not. Starting with this release, you can use the API to clear such variances. With the new
COGSCLOSEDJE object, you can view the variances and then selectively apply adjustments to the general ledger in an open period.
This means you no longer need to make manual GL adjustments for each item, warehouse, and entity as you did in previous releases.
Customization and Platform Services
Interactive Custom Reports
The new Interactive Custom Report Writer in the Sage Intacct UI provides powerful features for creating even the most complex reports. After creating your report definitions, you can use API functions to view these new reports and run them.
For more information:
Customizations for multiple transaction definitions
Previously, if you wanted the same customization to apply to different transaction definitions, you had to recreate the customization for each definition. In both Customization and Platform Services, you can now create a single customization that applies to multiple definitions in the UI. Simply choose Inventory Control Transaction Detail, Purchase Order Transaction Detail, or Order Entry Transaction Detail in the Object field when creating the customization, then add as many transaction definitions as you want in the Document Type field. Usage information for Customization and Platform Services is available in the Sage Intacct product help.
You can use the
<documentTypes> tag in packages to create a single customization that points to multiple transaction definitions. This excerpt from a package file shows how to do this:
When a custom application with multiple transaction definitions for a customization is exported, it does not include multiple document types in the XML, but rather provides separate customizations that use the same ID for each transaction definition. When your custom application is installed, these customizations are merged into one customization record in the UI.
The XML file for a custom application should not be edited directly.
Synchronous API Smart Events
You can now ensure that a group of events, including the triggering action, are executed in order as a set using synchronous API Smart Events. With synchronous API Smart Events, the triggering action and the chain of synchronous API Smart Events succeed or fail as a group (think in terms of a larger task that includes multiple actions). On failure, the system provides direct feedback through an error message.
Previously, all Smart Events were asynchronous, which meant that these events were executed in parallel and could occur out of order. For instance, you could have written an API Smart Event to create a sales invoice when a vendor was updated, and then written another event to update that same sales invoice. Since Smart Events were all asynchronous, the update event could have occurred before the create event, rendering both events invalid.
When creating API Smart Events in the Sage Intacct UI, there is a new checkbox for choosing synchronous execution:
In addition to grouping a set of events and the trigger into a single set that succeed or fail as a group, this feature also eliminates the possibility of collision, concurrency, and overwriting between events since they are executed one after another.
About execution triggering and rollback
When an action triggers a synchronous API Smart Event, the system attempts to execute all synchronous events that are part of the resulting chain of actions in alphabetical order according to Smart Link IDs. This happens before the triggering action is committed. If the chain executes successfully, the triggering action is saved and any asynchronous Smart Events are then executed.
If the chain of synchronous events cannot be executed successfully, the transaction or record is rolled back and the originating trigger action is prevented. Additionally, an error message is emitted. No synchronized API Smart Events or asynchronous Smart Events (of any type) are executed that would have been part of the chain.
You can see if your asynchronous Smart Events were executed or failed in your offline job history.
Though powerful, synchronous API Smart Events add a level of complexity, so you should be thoughtful in your approach. For this reason, we recommend the following:
- Only use synchronous API Smart Events when you want to ensure a group of events are executed in a particular order and as a group.
- Use synchronous API Smart Events when you want to ensure the triggering action is tied to the event actions in terms of success and failure.
- Use a prefix in your IDs to group your related synchronous API Smart Events and ensure they are occurring in the correct order. A good format to use is NAMESPACE_PREFIX_DESC. For example, you could use a convention like:
- If you want to re-order synchronous API Smart Events that were created from a package, inactivate the synchronous API Smart Events in the package, then create new ones.
Automatically reallocate revenue and expense schedules
You can now automatically reallocate daily rate or straight line revenue or expense schedules based on different start and/or end dates. Previously if you needed to reallocate a revenue or expense schedule, you had to manually edit the schedule.
For more information:
- Reallocate Contract Expense Schedule
- Reallocate Contract Expense 2 Schedule
- Reallocate Contract Revenue Schedule
- Reallocate Contract Revenue 2 Schedule
More control over hold and resume for contract lines
You can now track the hold and resume dates for billing, revenue, and expense schedules and capture comments related to the hold or resume. You can also specify the type of revenue adjustment to make when resuming a revenue schedule from hold.
REVENUEADJUSTMENT parameters for these functions:
In addition, a hold date (
ASOFDATE) is no longer required when holding a contract line. If you leave the Hold date field blank, the hold date will default to the last posted schedule entry date + 1.
List Contract lines by line type
A new query parameter lets you search for contract lines by line type (