SXev (v11) connectors reference

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

To limit the number of SX.e order records analyzed, the integration process uses a lookback period in the query. This query is performed against the SX.e order header transaction date AND the order line transaction 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 SX.e connector order submission uses the real-time API, the ERP order # should also be present.

Implementation Note - Performance: Because many SX.e customers have very large tables and there is not an index on the transdt field, the system must perform a table scan, which can greatly increase refresh run time. A setting exists to capture the starting order number so that the refreshes will look back by date but limit the search to orders beginning at a specific number. This improves performance and this value can be updated periodically (that is quarterly) if performance is an issue. This applies to order history refresh, invoice history, and shipment history refreshes.

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 WHERE clauses of the history refreshes.

Record Selection: Only records for the currnet company, stagecd between 1 and 5, selected transdt withing the lookback days, and for transtypes not BL, QU, ST, FO, or BR.

Deletion Strategy: There is a special strategy for Order History, as it is 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.

ISC's shipment refresh assumes some sort of shipping interface is used within SX.e so that OEEHP records are being generated with tracking information. This refresh typically runs once per day and uses a lookback period from which to run the query.

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

Refer to the Implementation Notes in Order History Refresh for additional information. (Anchor link)

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 SX.e via a direct call to ERP database. The data is stored within the Configured Commerce database and refreshed on a regular interval, typically once a day.

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

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

The filter for these records only includes the specified company; stagecd 4 or 5; excludes transtypes BL, QU, ST, FO, and BR; enterdt not null; and transdt within the specified timeframe window.

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 uses a standard direct call to an API endpoint to display the A/R aging information on the Invoice History page. The standard aging buckets must be set up as global options in Settings. We do not use the labels returned from the API, only the balances themselves.

The API used is sxapiARGetCustomerBalanceV2.

Configured Commerce calls the payment gateway (typically CenPOS for SX.e) directly to authorize a user's credit card. The authorization information is passed into SX.e via the order submission process using an authorization token returned by the payment gateway. This information does not apply to SX.e v6.

Configured Commerce will submit orders to SX.e 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.

A new customer is created if the user self-registers or adds a new ship-to address.

If a 1-time order address is submitted, it will be placed into the Order Header (OEEH).

Note that SX.e's order submit assumes that only authorizations are being committed for credit card orders through CenPOS. Our recommendation is to not run credit card transactions as Sales in Configured Commerce to prevent downstream issues with the ERP.

The API sxapiSFOEOrderTotLoadV4 is used for this function. The data below will show the net differences for the actual order submission.

The standard Configured 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 and only calls out the changes from the tax calculation.

Note that SX.e's order submit assumes that only authorizations are being committed for credit card orders through CenPOS. Our recommendation is to not run credit card transactions as Sales in Configured Commerce to prevent downstream issues with the ERP.

These fields are "edinsprodfl" in both ARSC and ARSS

As part of the standard connector for SX.e, there is a Tax Calculator which makes an API call to SX.e to calculate and return the tax amount to Configured Commerce on the Cart (if configured) and Checkout screens. If another tax calculator, such as Avalara, is used, then this Order Simulate function will be disabled. When using another tax calculator, be sure to review the Product & Customer refresh to ensure the correct data is being pulled into those records to pass into the tax service.

The API sxapiSFOEOrderTotLoadV4 will be used for this function.

Configured Commerce retrieves pricing from SX.e via real-time calls, so no refresh is needed. The API used for this function is sxapiOEPricingMultpleV4.

Note that Configured Commerce does not retrieve price breaks from this call - OEPricingMultipleV4 does not return enough information to calculate pricing based on the price break information returned. However, if price-break-based pricing is set up inside of SX.e, Configured Commerce sends in the correct quantity values for the pricing call and will retrieve the correct pricing for the price tier in the cart.

Configured Commerce retrieves both Customer (ARSC) and Ship-To (ARSS) information into a common customer table via the Customer refresh.

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 two separate sweeps. Delta Dataset option will be disabled.