Acumatica connectors overview

  • Updated

As of January 2023, Optimizely allows partners and the implementation community to build ERP connectors to increase the number of ERP connectors and enhancements available to customers. Optimizely continues to offer existing ERP connectors in their current state, and partners have access to the connector code for future enhancements.

This article outlines the integration elements included in the Optimizely Configured Commerce connector for Acumatica ERP. It identifies and defines the default integration points and the necessary details, including field mapping and high-level technical processes. While these integration points and jobs cover a majority of the integration requirements with Acumatica, there may be customer-specific requirements that you need to incorporate into a customer's Configured Commerce implementation.

Optimizely's Acumatica connector uses standard integration mechanisms between Acumatica and Configured Commerce through the Generic Inquiry and standard Web Service Endpoints. This document focuses on Optimizely customers implementing a version of Configured Commerce and integrating it with Acumatica, with implementation assistance from Optimizely partners.

Connector requirements

Optimizely based this integration on the following:

  • Versions Supported: API version 18.200.001
  • Cloud Implementation The Optimizely Windows Integration Service application on a local Windows machine is NOT required for this version of InsiteConnect.
  • Payment Gateways: The Order Submit job assumes you use with Acumatica
  • Tax Calculators: Configured Commerce can call Avalara, which returns tax amounts

Complete the following pre-requisites before attempting this integration:

  • A user must be created in Acumatica for Configured Commerce to access Generic Inquiries and Web Service Endpoints.
    • You should set this user up with the BI, Internal User, and Portal User rights. Other rights may be necessary in your instance.
  • If your instance of Acumatica is multi-tenant, the tenant must be added to each job.
  • Install the default Generic Inquiries set in your Acumatica instance.

Business issues or considerations

Many portions of this document refer to tables or objects within Acumatica. See Acumatica documentation for definitions of those tables and potential values.

Some instances of Acumatica may not have all of the default fields pulled in Generic Inquiries

Technical issues

Configured Commerce relies heavily on the Odata functionality and APIs, so Optimizely assumes that these endpoints are responsive. Any issues with the speed of the APIs may require an ERP expert to assist, as Optimizely does not have the resources or expertise to troubleshoot standard ERP APIs.

Known limitations

Acumatica's current endpoints do not provide adequate responses for sets of items or warehouses for real-time pricing. Because of this, one of the default integration jobs is to create a price matrix with pricing from Acumatica. These jobs assume that customer-specific pricing resides in the price records being imported.

Overview of integration jobs

The integration tasks between Acumatica ERP and Configured Commerce are separated by the source and destination of the datasets and the mechanism used to implement the integration. The three types of integration tasks are designated as Refresh (Pull data in batch through Odata), Submit (Push a transaction) or RealTime (direct calls to the APIs).

Refresh (Pull): Configured Commerce relies on Acumatica to provide product, customer, order history, and invoice data. Refresh tasks are typically run at scheduled intervals to synchronize new or updated data with Configured Commerce . Generic Inquires exposed via Odata are used for refreshes.

Direct API Calls (Real-Time): Direct calls to the exposed Acumatica API are made for inventory.

Submit (Push): Configured Commerce relies on the Acumatica APIs for functions like order submissions that require data to be submitted to the ERP.

Refresh mapping

Refreshes use the Field Map capability of the Configured Commerce integration architecture. When we construct a connector, we create a series of job definitions that encode these mapping rules for refresh jobs. The mapping documents below call out the standard connector logic and it is up to the implementation partner or customer to adjust as needed for their particular project needs.

For example, by default, the product length/width/height are not visible in the Admin Console, and therefore are not available in the Field Mapper. The Acumatica connector query will retrieve this data from the ERP, but it will not be in the standard field map tool to populate the Configured Commerce database. If the field is configured to be available via the application dictionary, it must be added to the field mapper in order for the data to flow into Configured Commerce.

Deletion strategy

For each entity being refreshed, there must be a strategy on how to handle records that are not in the dataset retrieved from the source tables. The Configured Commerce options are to Ignore, Delete or Set a field such as IsActive or DeactivateOn. These strategies will depend on several factors, including:

  • Are there child collection considerations? (Records that relate to a parent, such as invoice history lines being children to the invoice history header table)
  • Are we retrieving the data in separate queries? (Such as Customer Bill-Tos and Ship-Tos.)

Each refresh will define the standard deletion strategy being used.

API list

The following is the list of standard APIs used for integration:

  • Inventory Availability: InventoryAllocationInquiry
  • Order Submit: SalesOrder