A+ connectors reference

Optimizely's ERP connectors do not support .NET 8. Work with your partner or development team to take the open-source code and modify it to work with .NET 8 for your projects.

Optimizely lets partners and the implementation community build ERP connectors to increase the number of ERP connectors and enhancements available to customers. Optimizely offers existing ERP connectors in their current state, and partners can access the connector code for future enhancements.

Order history

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.

Field mapping: Order history header

Field mapping: Order history detail

Invoices

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.

Field mapping: Invoice history header

Existing orders

A/R aging balances API

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.

Field mapping: A/R aging

A/R aging balances (invoices)

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.

Credit card processing

Order submit API

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

Field mapping: Order submit header

Field mapping: Credit card data

Field mapping: Order submit detail/line

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.

Tax (Order Simulation)

Pricing API

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.

Field mapping: Pricing and availability

Pricing tables

Customer

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.

Field mapping: Customer (bill-to)

Field mapping: Customer (ship-to)

Customer products

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.

Field mapping: Customer product

Customer tables

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.

Inventory tables

Products

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.

Field mapping: Product refresh product

Product cross-sell

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.

Field mapping: Product cross-sells

Product restriction group

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:

• The list of groups is in ORCTL and defines the default behavior for the group (that is hide/show)
• The table OECAU defines the relationships
• We will need to create a restriction group with the customer # and optional Ship to # for distinct product restrictions which will be by customer
• If there is an entry in OECAU for a customer and a carscd (restriction code) field, then they override the behavior of the entire group. These customers will be added to the Restriction Group which will have an opposite behavior of the product
• If there is an entry in OECAU for a customer and a caitno field (product), then they override the behavior for just that product. These customers will be added to a customer-specific restriction group with just the products specified and the opposite behavior of the default.

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.

Field mapping: Restriction groups

Field mapping: Restriction group products

Product alternate unit of measure

Configured Commerce retrieves Alternate Units of Measure via a direct call to the Prophet 21 database. This refresh is done as a separate step in the Product Refresh

Deletion Strategy: Configured Commerce uses the Delete option for this data.

Field mapping: Product alternate unit of measure

Product tables

Salespeople

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.

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

Field mapping: Salesperson refresh

Payment methods

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 .

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

Field mapping: Payment terms refresh

Ship codes

The ship codes are refreshed to help support the default ship via codes for customers which is then surfaced in the review and pay page on the site. Configured Commerce has a Carrier/Service structure while most ERPs only have the service. To that end, we will pull in the data and duplicate it between the carrier and the actual service. The end users can then either re-arrange the data as needed or remove the integration steps (Carriers/ShipVias).

Deletion Strategy: We will use Ignore and not delete any ship via records automatically during the refresh due to referential integrity concerns.

Field mapping: Ship codes

Vendors

The vendors table is imported just to support the vendor to product relationship if needed.

Deletion Strategy: We will use delete option on the table to remove unneeded vendors. If a vendor is already assigned to a product, then the deletion will fail.

Field mapping: Vendor