Acumatica connectors reference

In Acumatica, the names of the fields may appear differently as exposed via OData versus how they appear inside the Generic Inquiry functionality. This article uses the Odata-exposed names when possible.

Configured Commerce retrieves Order history data from Acumatica via a direct call. The data is stored within the Configured Commerce database and refreshed on a regular interval, typically once a day.

To limit the number of order records analyzed, the integration process uses a lookback period in the query. This query is performed against the Acumatica order modified date.

Orders placed via Configured Commerce are immediately added to the Configured Commerce order history tables. This ensures that a user will immediately see their orders on the Order History pages under My Account. Because the Acumatica connector order submission uses the real-time API, the ERP order # should also be present.

This data is a combination of the SalesOrder, SOBillingAddress, and SOShipmentAddress Objects.

Implementation Note Lookback Days: Optimizely s strategy is to limit the amount of data being reviewed and transmitted to Configured Commerce for large history files. Configured Commerce only looks for records that have changed within a relatively short period of time, with a default of 5 days to cover any missed refreshes, weekends and holidays. The number can be modified based on implementation preferences. It is coded directly into the Generic Inquiry.

Deletion Strategy: There is a special strategy for Order History, as it s not ideal to do a full snapshot of the data. However, we need to catch any changes to, say, order lines that were deleted. A special option to Delete Children is used, with the delete action set to Delete. Any order that is processed clears and reloads the order line data to history.

Configured Commerce's shipment refresh gathers shipment information from the Shipments object and individual package information from the Packages object.. This refresh typically runs once per day and uses a lookback period from which to run the query.

To limit the number of order records analyzed, the integration process uses a lookback period in the query. This query is used against only the transaction date, since we do not expect records to change once invoiced.

Deletion Strategy: Since this is not a full snapshot and this data is highly unlikely to change once processed, the Ignore delete action is used.

Invoice data is retrieved from Acumatica via an Odata call to the ARInvoice object. The data is stored within the Configured Commerce database and refreshed on a regular interval, typically once a day.

To limit the number of invoice records analyzed, the integration process uses a lookback period in the query.

Refer to the Implementation Notes in Order History Refresh for additional information.

Deletion Strategy: We will employ the Ignore strategy, as we will only be taking a snapshot and do not expect line information to change once the status of the order is changed to Invoiced.

Configured Commerce calls the payment gateway (typically Authorize.net for Acumatica) directly to authorize a user s credit card. The authorization information is passed into Acumatica via the order submission process using an authorization token returned by the payment gateway. Card tokens will also be passed as a CustomerPaymentProfile.

Configured Commerce will submit orders to Acumatica via the API. Typical order submission data will be included: bill-to information, ship-to information, and line item information. If a credit card was used for the order, Configured Commerce will also submit the authorization token information. The SalesOrder endpoint is used for orders.

The standard Configured Commerce connector mapping for API calls is hard-coded but implemented with pipelines to allow the implementer to extend the integration to incorporate additional mapping information for other fields or adjust the standard mappings. The following shows the default approach to mapping the API call.

Acumatica supports Avatax out of the box and calls will be made directly to Avalara for this functionality.

Configured Commerce retrieves pricing via a refresh crafted specifically for Acumatica. Note that unlike many integrations, Acumatica does not have an ecommerce-focused inventory/pricing endpoint. Real-Time Inventory is retrieved separately.

Configured Commerce has a custom Integration Processor (PricingRefreshAcumatica) to read Acumatica price data and incorporate them into the correct price types in the price matrix.

Configured Commerce retrieves Bill-to customer data from the Customer object and Ship-to data from the Location object. We do this in three separate sweeps. First the Bill-Tos are retrieved, then the Ship-Tos are retrieved, then any Customer-Specific data is retrieved, due to issues joining the customer and locations tables in the same inquiry.

This information comes from a series of joined tables (BAccount, Location, Address, Customer, LocationExtAddress, Contact) and will be marked individually in the ERP Source fields.

Deletion Strategy: Configured Commerce retrieves all customer records and physically sets the IsActive flag directly from the data, so the Ignore delete action will be used. Configured Commerce must use Ignore, since the data will be retrieved in three separate sweeps.

Customer-specific product data will be retrieved by Configured Commerce via a direct call to Acumatica.

Deletion Strategy: Configured Commerce uses the Delete option to physically remove records that are no longer valid. Configured Commerce also uses Delta Datasets.

Configured Commerce retrieves Inventory via a Generic Inquiry to Acumatica. We retrieve the amount available for shipping and expect that real-time inventory will be used as the primary function for inventory.

This inquiry joins the InventoryItem, ItemStats, and Site objects.

Deletion Strategy: This refresh uses the ignore option.

Configured Commerce uses real-time calls to obtain pricing and availability via real-time calls. Real-time calls return the AvailableforShipping value. The below refresh will also be used to supplement the data, if needed.

The Product Refresh process retrieves item/product information directly from Acumatica. ISC's Connector looks at the InventoryItem object, which contains both StockItems and NonStockItems. Only records marked as active within Acumatica will be retrieved in the refresh job.

Depending on your business setup for NonStockItems, you may need to include additional logic in the base Generic Inquiry to retrieve only a subset of records, based on the type of NonStockItem.

Note that we only retrieve products that are in stock with an active status. Inactive products are not retrieved by default nor is the inactive flag set on the products directly. If an active product becomes inactive, it will be effectively discontinued on the site. This logic can be changed by the implementer.

Deletion Strategy: We use Set Field to make items deactivated in Configured Commerce.

Configured Commerce retrieves Product Alternate Units of Measure via a Generic Inquiry to Acumatica. This refresh can be modified or copied to use specific record types or relationships needed for a given implementation.

This refresh joins the InventoryItem and INUnit tables to return only the applicable values for a given product.

Deletion Strategy: This refresh uses the delete option to remove unsupported units of measure.

The salesperson information is important so that we can set the primary sales rep on the customer records. This allows your customers to know who their sales reps are, and allows your sales reps to view customer data in ISC. It is also required if using the Request for Quote functionality in ISC.

Note that Acumatica's SalesPerson object does not contain contact information for your sales force. We have joined the Contact object to get this information.

Deletion Strategy: We will use Ignore and not delete any salesperson records automatically during the refresh.

The payment terms refresh populates the payment methods table in ISC, which is referenced in history tables and sets the default value in the customer table used in order submission. Typically, once this is run, customers can update the descriptions in the Configured Commerce Admin Console to reflect the values displayed to the end user, such as Terms . The description, by default, uses Acumatica's friendly "Descr"/Description field.

Deletion Strategy: We will use Ignore and not delete any payment method records automatically during the refresh.