A+ connectors reference

Order history data is pulled from A+ 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 A+ order records analyzed, the integration process will use a lookback period when constructing the query but only against history. Note that there are 2 source tables: orhed is for open orders and hshed is for historical orders. The intent is to pull this data through a union query to present a single dataset. We will pull the entirety of the current order table and only use the lookback for historical orders.

During end of day in A+, invoiced orders are moved from orhed to hshed so the order never lives in both places simultaneously. In orhed, the order is defined by ohcono/ohorno/ohorgn (company, order #, generation) and in history this is company/order/origin and sequence (oahssq) to make it unique. Technically, the sequence itself is unique but it s possible to have more than one although we will not be supporting duplicates.

Note that we understand that, over time, the order number itself can wrap around are be restarted. We are not accounting for this in the standard connector under the premise that we would not store more than, say 3 years of historical data and that this wraparound of the orders will not occur in this timeframe

Orders placed on the site are immediately added to the Configured Commerce order history tables. This ensures that a user will immediately see their orders if they go to Order History pages in the My Account area of the site. If the order submission works in real-time, then the ERP order # should be present as well.

Implementation Note - Performance: Because many A+ customers have very large tables and the system must perform a table scan which can make this refresh take a very long time. For performance purposes, the customer may wish to establish a custom index on hshed.oadndt.

Implementation Note Lookback Days: There is a general strategy to limit the amount of data being reviewed and transmitted to the website for large, history files. The idea is to only look for records that have changed within a relatively short period of time. We use a default of 5 days to cover any missed refreshes, weekends and holidays. The number could be expanded or shortened based on implementation preferences. It is coded directly into the WHERE clauses of the history refreshes. For history, use hshed.oadncc = 20 and hshed.oadndt - #/days (integer field).

Deletion Strategy: There is a special strategy for Order History because we don t want to do a full snapshot of the data but we need to catch any changes to, say, order lines that were deleted. A special option to Delete Children will be used with the delete action set to Delete. This way, any order that is processed will clear and reload the order line data to history.

Invoice data is pulled from A+ 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 A+ order records analyzed, the integration process will use a lookback period when constructing the query. This query is used against the A+ order header transaction date only since we do not expect invoice records to change once invoiced.

There are 2 files for invoices open (ardhd) and closed (arhhd). Except for general backloading of the data, we will only be pulling from the open file. Additionally, since we will only be displaying invoice summary and A/R information, we will not be obtaining full customer/ship-to addresses and other order-related items. If additional order level information is required, tie to hshed using hshed.oahssq = ardhd.rhhsid. We will use a delta dataset and grab the entire open invoice table on each refresh.

Deletion Strategy: We will employ the Ignore strategy since 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.

A standard direct call to the API endpoint will be used on the standard Invoice History page to display the A/R aging information. The standard aging buckets must be set up in Settings as global options for the aging ranges. We will not be using the returned labels from the API, only the balances themselves.

The API used for this information will be ARSummary.

Configured Commerce will call the payment gateway (CenPOS) directly to authorize a user s credit card. The authorization information is passed into A+ via the order submission process using a token returned by the payment gateway.

Configured Commerce submits order to A+ via real-time calls. The API used for this function is OrderImport.

As part of the standard connector for A+, there will be a Tax Calculator specific to the connector which will make an API call to A+ to calculate the tax amount and return the tax amount to the website on the Cart (if configured) and Checkout screens. If another tax calculator, such as Avalara, is used, then this Order Simulate function will not be used.

The API CreateOrder will be used for this function.

Pricing and inventory will be done using real-time calls to A+ so no refresh will be needed. The API used for this function is GetAvail.

Pricing: The requested information will be calculated and returned on the basis of customer number, company number, item number, unit of measure, and quantity.

Availability: If it is Default and alternate warehouses then the quantity will be the sum of the default warehouse and the quantity available in the alternate warehouses. If the DftWhsOnly element is N then the quantity will be the sum of the default warehouse and the quantity available in the alternate warehouses. If the DftWhsOnly element is Y then it will only display the quantity available in the default warehouse.

The Customer refresh will be pulling both Customer (cusms) and Ship-To (addr) information over to Configured Commerce into a common customer table.

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.

Customer-specific product data will be pulled into Configured Commerce via a direct call to the A+ database. While A+ supports ship-to level customer-specific products, Configured Commerce integration will only pull the bill-to level records.

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 uses real-time calls to obtain pricing and availability via real-time calls. No refresh of inventory will be used. See the section on Pricing for the API call mapping.

The Product Refresh integration process retrieves item/product information directly from the A+ ERP database. The field itmst.impwbu will be used to determine which products are active.

Deletion Strategy: Since these tables can be large, we do want to only retrieve records that are important to pull into ISC. This job may be run using Delta Datasets to minimize transaction volume coming over. We will use the Set Field option to set the DeactivateOn field automatically based on using a snapshot strategy for data retrieval.

Configured Commerce retrieves Product Cross-Sells via a direct call to the A+ database. This refresh can be modified or copied to use specific record types or relationships needed for a given implementation.

Deletion Strategy:

We will use the Ignore option users may create manual entries for different types of relationships that are not managed in A+.

The data will be coming from table imxrf with A records mapped to Accessories relationship and C records mapped to Cross-Sells relationship.

There is the concept of restriction groups within A+ and the following tables can be used to refresh them. Note that we are not supporting the opt-in/opt-out flag in cusms.cmckrs which has a Y/N/S flag indicating if product restrictions are applied or not.

Restriction groups in A+ work as follows:

Note that if a customer is assigned to both a restriction group and has overrides to that restriction group, this will only effectively work to HIDE a product, not show one. For example, if the default behavior is HIDE and they are in a restriction group to SHOW with an exception to HIDE, the individual product will be hidden. The guiding rule in restriction groups is that any override with a hide supersedes overrides to show.

On the other hand, if a product is defaulted to SHOW and the customer is in a restriction group to HIDE the product but there is an individual override of the product to SHOW it again, the HIDE on the restriction group will supersede the SHOW of the individual product so that override will have no effect.

The standard integration will set up the restriction groups and overrides correctly, they just, under certain circumstances, may not have the impact desired.

Deletion Strategy: We will use the Delete option for this data (entire restriction group only). Note that there is no current way to synch/delete records in a child collection which all assigned products to the restriction group are. A process will need to be implemented to remove individual products from customer-specific restriction groups or customers from standard restriction groups.