2021 Release 3

This release went live on the evening of August 20, 2021.

Accounts Payable

Improved usability for vendor functions including behavior changes on existing functions

This release fixes a known issue related to updating vendors with contact lists, and provides additional capabilities related to vendor contacts, vendor email templates, vendor account number/locations, Pay to/Return to/Contact to 1099 functionality, and electronic vendor payments functionality.

Vendor contact changes (object-specific and generic functions)

Previously, when using a generic update function on a vendor that had an existing list of contacts (CONTACT_LIST_INFO elements), you had to re-supply the complete set of existing contacts or they were deleted. This is now fixed—you can update vendors without supplying the CONTACT_LIST_INFO without any loss of data.

Similarly, when using the object-specific update_vendor function in previous releases, you had to re-supply the complete set of existing contacts (contactlist elements) or they were deleted. This is also fixed.

In addition, when you use either an object-specific or generic update and provide contact list entries, those contacts are now appended to the set—it is not a complete replacement as it was in previous releases.

To delete all the contacts, you can pass empty contact lists using either object-specific or generic updates.

In a related enhancement, you can now use VENDORCONTACTS in generic create or update functions instead of supplying contacts via individual CONTACT_LIST_INFO elements. If both VENDORCONTACTS and CONTACT_LIST_INFO are provided, VENDORCONTACTS is used.

The two approaches provide the same functionality, but use a different model:

VENDORCONTACTS example
<VENDORCONTACTS>
  <VENDORENTITYCONTACTS>
    <CATEGORYNAME>Home</CATEGORYNAME>
    <CONTACT>
        <NAME>Despereaux, Pierre</NAME>
    </CONTACT>
  </VENDORENTITYCONTACTS>
  <VENDORENTITYCONTACTS>
    <CATEGORYNAME>Office</CATEGORYNAME>
    <CONTACT>
        <NAME>Despereaux, Pierre</NAME>
    </CONTACT>
  </VENDORENTITYCONTACTS>
</VENDORCONTACTS>
CONTACT_LIST_INFO example
<CONTACT_LIST_INFO>
    <CATEGORYNAME>Home</CATEGORYNAME>
    <CONTACT>
        <NAME>Despereaux, Pierre</NAME>
    </CONTACT>
</CONTACT_LIST_INFO>
<CONTACT_LIST_INFO>
    <CATEGORYNAME>Office</CATEGORYNAME>
    <CONTACT>
        <NAME>Despereaux, Pierre</NAME>
    </CONTACT>
</CONTACT_LIST_INFO>

For more information, see the VENDORCONTACTS and CONTACT_LIST_INFO parameters on the following operations:

Provide vendor email templates (generic functions)

You can now specify vendor email templates (VENDOREMAILTEMPLATES) using generic create and update functions:

<VENDOREMAILTEMPLATE>
    <EMAILTEMPLATENAME>Purchase order email</EMAILTEMPLATENAME>
    <DOCPARID>Purchase Order</DOCPARID>
</VENDOREMAILTEMPLATE>

Important: If you perform an update and provide VENDOREMAILTEMPLATE, the existing set is completely replaced by the new set. This is a different model than that of the vendor contact list elements where entries are appended to the set.

If you perform an update without passing VENDOREMAILTEMPLATE, the existing email templates are not affected. To delete all the specified email templates, pass an empty VENDOREMAILTEMPLATE element.

For more information, see the VENDOREMAILTEMPLATE parameter on the create and update vendor functions, as well as the functions for reading vendor email templates.

Vendor account number/location changes (generic functions)

You can now specify the vendor account number and location (VENDORACCTNOLOCATIONS) in generic create and update functions as an alternative to using VENDOR_ACCTNO_LOC_HEAD. If both are supplied, VENDORACCTNOLOCATIONS is used.

<VENDORACCTNOLOCATIONS>
    <VENDORACCTNOLOCHEAD>
        <LOCATION>CA</LOCATION>
        <ACCOUNTNO>123456</ACCOUNTNO>
    </VENDORACCTNOLOCHEAD>
</VENDORACCTNOLOCATIONS>

Important: If you perform an update and specify VENDORACCTNOLOCATIONS, the existing set is completely replaced by the new set. This is a different model than that of the vendor contact list elements where entries are appended to the set.

If you perform an update without passing VENDORACCTNOLOCATIONS, the existing data is not affected. To delete all the vendor account number/locations, pass an empty VENDORACCTNOLOCATIONS element.

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

Enhanced Pay to, Return to, and Contact to 1099 functionality (object-specific and generic functions)

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

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

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

Function Current behavior Previous behavior
update Updating a vendor without supplying the CONTACT_LIST_INFO or VENDORENTITYCONTACT does not cause data loss. Updating a vendor without supplying the CONTACT_LIST_INFO resulted in loss of the existing CONTACT_LIST_INFO data.
update_vendor Updating a vendor without supplying the contactlist does not cause data loss. Updating a vendor without supplying the contactlist resulted in loss of the existing contactlist data.
create
update		 Providing empty CONTACT and CATEGORYNAME values in CONTACT_LIST_INFO or VENDORENTITYCONTACTS does not create the CONTACT_LIST_INFO or VENDORENTITYCONTACTS and does not not throw an error. Providing empty CONTACT and CATEGORYNAME values in CONTACT_LIST_INFO resulted in a CONTACT_LIST_INFO with blank values.
create_vendor
update_vendor		 Providing an empty contactname and category in contactlist does not create the contact list and does not not throw an error. Providing an empty contactname and category in contactlist resulted in a contact list with blank values.
create
update		 Providing a nonexistent contact name in the PAYTO or RETURNTO throws an error and prevents the system from creating that vendor. Providing a nonexistent contact name in the PAYTO or RETURNTO did not prevent the system from creating that vendor.
create_vendor
update_vendor		 Providing a nonexistent contactname in the payto or returnto throws an error and prevents the system from creating that vendor. Providing a nonexistent contactname in the payto or returnto did not prevent the system from creating that vendor.
update Updating a vendor with new CONTACT_LIST_INFO or VENDORENTITYCONTACTS entries appends new entries to the existing set (both CONTACT_LIST_INFO and VENDORENTITYCONTACTS). Updating a vendor with new CONTACT_LIST_INFO entries resulted in a complete replacement of the existing set.
update_vendor Updating a vendor with new contactlist entries appends new entries to the existing set. Updating a vendor with new contactlist entries resulted in a complete replacement of the existing set.
create
update		 Providing CONTACTINFO, PAYTO, and RETURNTO without CONTACT_LIST_INFO creates the contact list (both CONTACT_LIST_INFO and VENDORENTITYCONTACTS). Providing CONTACTINFO, PAYTO, and RETURNTO without CONTACT_LIST_INFO did not create the contact list.
create_vendor
update_vendor		 Providing contactinfo, payto, and returnto without contactlist creates the contact list. Providing contactinfo, payto, and returnto without contactlist did not create the contact list.
update Updating a vendor with CONTACTINFO, PAYTO, and RETURNTO appends PAYTO and RETURNTO to the contact list (both CONTACT_LIST_INFO and VENDORENTITYCONTACTS) Updating a vendor with CONTACTINFO, PAYTO, and RETURNTO did not append PAYTO and RETURNTO to the contact list.
update_vendor Updating a vendor with contactinfo, payto, returnto, and contactto1099 appends these to the contact list. Updating a vendor with contactinfo, payto, returnto, and contactto1099 did not append the contact list with the existing contact.

Inter-entity bill back templates in responses

Functions that read AP bills now provide the name of the bill back template if one is in use, for example:

<BILLBACKTEMPLATE>BBTMP-022</BILLBACKTEMPLATE>

See the Sage Intacct product help for information about bill back templates.

Electronic payments for vendors - CSI payment provider (Early Adopter Program)

You can now flag vendors as individual persons to mask personally identifiable information (PII).

See the ISINDIVIDUAL parameter on the following operations:

Provide vendor bank file details when using electronic payment providers (generic functions)

Now, when creating or updating vendors, you can provide your country code and vendor bank file details.

See the FILEPAYMENTSERVICE, PYMTCOUNTRYCODE and VENDORBANKFILEDETAILS parameters on the following operations:

Accounts Receivable

Improved usability for customer functions including behavior changes on existing functions

This release fixes a known issue related to updating customers with contact lists, and provides additional capabilities related to customer contacts and Bill to/Ship to functionality.

Customer contact changes (object-specific and generic functions)

Previously, when using a generic update function on a customer that had an existing list of contacts (CONTACT_LIST_INFO elements), you had to re-supply the complete set of existing contacts or they were deleted. This is now fixed—you can update customers without supplying the CONTACT_LIST_INFO without any loss of data.

Similarly, when using the object-specific update_customer function in previous releases, you had to re-supply the complete set of existing contacts (contactlist elements) or they were deleted. This is also fixed.

In addition, when you use either object-specific or generic updates and provide contact list entries, those contacts are now appended to the set—it is not a complete replacement as it was in previous releases. To delete all the contacts, you can pass empty contact lists using either object-specific or generic updates.

In a related enhancement, you can now use CUSTOMERCONTACTS in generic create or update functions instead of supplying contacts via individual CONTACT_LIST_INFO elements. If both CUSTOMERCONTACTS and CONTACT_LIST_INFO are provided, CUSTOMERCONTACTS is used.

The two approaches provide the same functionality, but use a different model:

CUSTOMERCONTACTS example
<CUSTOMERCONTACTS>
  <CUSTOMERENTITYCONTACTS>
    <CATEGORYNAME>Home</CATEGORYNAME>
    <CONTACT>
        <NAME>Kristensen, Linda</NAME>
    </CONTACT>
  </CUSTOMERENTITYCONTACTS>
  <CUSTOMERENTITYCONTACTS>
    <CATEGORYNAME>Office</CATEGORYNAME>
    <CONTACT>
        <NAME>Kristensen, Linda</NAME>
    </CONTACT>
  </CUSTOMERENTITYCONTACTS>
</CUSTOMERCONTACTS>
CONTACT_LIST_INFO example
<CONTACT_LIST_INFO>
    <CATEGORYNAME>Home</CATEGORYNAME>
    <CONTACT>
        <NAME>Kristensen, Linda</NAME>
    </CONTACT>
</CONTACT_LIST_INFO>
<CONTACT_LIST_INFO>
    <CATEGORYNAME>Office</CATEGORYNAME>
    <CONTACT>
        <NAME>Kristensen, Linda</NAME>
    </CONTACT>
</CONTACT_LIST_INFO>

For more information, see the CUSTOMERCONTACTS and CONTACT_LIST_INFO parameters on the create and update customer functions.

Enhanced Bill to and Ship to functionality (object-specific and generic functions)

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

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

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

Function Current behavior Previous behavior
update Updating a customer without supplying the CONTACT_LIST_INFO or CUSTOMERENTITYCONTACT does not cause data loss. Updating a customer without supplying the CONTACT_LIST_INFO resulted in loss of the existing CONTACT_LIST_INFO data.
update_customer Updating a customer without supplying the contactlist does not cause data loss. Updating a customer without supplying the contactlist resulted in loss of the existing contactlist data.
create
update		 Providing empty CONTACT and CATEGORYNAME values in CONTACT_LIST_INFO or VENDORENTITYCONTACTS does not create the CONTACT_LIST_INFO or VENDORENTITYCONTACTS and does not not throw an error. Providing empty CONTACT and CATEGORYNAME values in CONTACT_LIST_INFO resulted in a CONTACT_LIST_INFO with blank values.
create_vendor
update_vendor		 Providing an empty contactname and category in contactlist does not create the contact list and does not not throw an error. Providing an empty contactname and category in contactlist resulted in a contact list with blank values.
create
update		 Providing a nonexistent contact name in the BILLTO or SHIPTO throws an error and prevents the system from creating that customer. Providing a nonexistent contact name in the BILLTO or SHIPTO did not prevent the system from creating that customer.
create_vendor
update_vendor		 Providing a nonexistent contactname in the billto or shipto throws an error and prevents the system from creating that customer. Providing a nonexistent contactname in the billto or shipto did not prevent the system from creating that customer.
update Updating a customer with new CONTACT_LIST_INFO or CUSTOMERENTITYCONTACTS entries appends new entries to the existing set (both CONTACT_LIST_INFO and CUSTOMERENTITYCONTACTS). Updating a customer with new CONTACT_LIST_INFO entries resulted in a complete replacement of the existing set.
update_customer Updating a customer with new contactlist entries appends new entries to the existing set. Updating a customer with new contactlist entries resulted in a complete replacement of the existing set.
create
update		 Providing CONTACTINFO, BILLTO, and SHIPTO without CONTACT_LIST_INFO creates the contact list (both CONTACT_LIST_INFO and CUSTOMERENTITYCONTACTS). Providing CONTACTINFO, BILLTO, and SHIPTO without CONTACT_LIST_INFO did not create the contact list.
create_customer
update_customer		 Providing contactinfo, billto, and shipto without contactlist creates the contact list. Providing contactinfo, billto, and shipto without contactlist did not create the contact list.
 update Updating a customer with CONTACTINFO, BILLTO, and SHIPTO appends BILLTO and SHIPTO to the contact list (both CONTACT_LIST_INFO and CUSTOMERENTITYCONTACTS). Updating a customer with CONTACTINFO, BILLTO, and SHIPTO did not append BILLTO and SHIPTO to the contact list.
update_customer Updating a customer with contactinfo, billto, and shipto appends billto and shipto to the contact list. Updating a vendor with contactinfo, billto and shipto did not append billto and shipto the contact list.

Error handling to prevent paying foreign currency invoices using undeposited funds

The system now prevents using the generic API to create a batch payment of foreign currency invoices using undeposited funds. A helpful error message is provided.

Purchasing

Specify project IDs on Purchasing transactions

When creating or updating a Purchasing transaction using the API, you can now provide a project ID on the header.

See the projectid parameter on the header portion of the following:

New standard reporting categories

You can choose from industry-standard reporting categories when creating or updating Purchasing transaction definitions using the API:

  • 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:

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:

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:

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:

Provide feedback