The basis for the data exchange between Business Central (BC) and the webshop are provided web services of BC. From the BC side it is possible to send configurable http requests to the webshop to trigger certain actions, that master data, stocks etc. have changed and are ready to be picked up by the webshop via webservice.
The orders are made available by the webshop in container tables based on the web services in BC. After a successful check in the container tables, the target documents are created in the system (orders).
A separate BC user is required for data exchange via web services.
All relevant master data can be maintained in BE-terna Commerce Interface in any language. The webshop channel itself determines which languages are relevant for it.
In BE-terna Commerce Interface, any number of webshop channels can be managed. Each webshop channel symbolizes a web store. The following important information can be stored at the webshop channel:
Deviating from the goods hierarchy relevant in BC, webshop categories can be maintained per webshop channel. Each item has to be assigned to at least one webshop category per webshop channel. Webshop categories can have any depth. Items can later be sorted into any nodes of the category tree.
Dynamic attributes are properties that can be assigned to items. These attributes have any number of predefined values from which can be selected later.
Free text attributes are also properties that can be assigned to items. The difference to the dynamic attributes is that the possible values are not predefined at the attribute, but can be freely defined later at the item.
Various properties can be maintained on items. These include:
The description of the items can be done in long texts as plain text or in HTML format. For this purpose an editor is opened so that the texts can be entered comfortably.
The details of the master data maintenance and the assignment of these to the items can be found in the attachment "Documentation BE-terna Commerce Interface".
There are 2 possibilities to map the webshop customers in BC. In the 1st variant, all customers are managed as customers. The 2nd variant maps the customers as contacts in the system. In this case a collective customer is necessary for each delivery country.
The customers are automatically created or updated via the order interface, the customer number is predefined by the store. Relevant fields at the customer are:
BC is the leading system for coding payment terms, forms of payment, deliverers, etc. Mapping tables are provided in BC for this purpose.
Discount reasons can be maintained in NAV. These are made available to the store via an interface.
In the BE-terna Commerce Interface standard, the release of items for a store can be done on 2 levels (item, variant).
The following information can be specified at this level:
A release function is used to check various mandatory fields before the item can be transferred to the webshop. The item release can be done manually for individual items. In the process, an error log is written listing properties that prevent the item from being released. This log can be called from the item. The detailed errors are listed in this log. The release function is automatically executed periodically and releases all items or checks those already released for correctness.
In the BE-terna Commerce Interface standard, the following information is checked: - at least one main category for the channel - meta title in the languages defined for the channel - short description in the languages defined for the channel - long description in the languages defined for the channel - prices for all items/variants in the price groups defined at the channel
All changes to master or transaction data relevant to the webshop are recorded in a change queue. This queue can be communicated to the store via freely configurable http requests. The following changes are logged:
o any changes to the item
o contacts
o prices
o inventories
o webshop Categories
o dynamic Attributes
o free Text Attributes
o changes to webshop orders
BE-terna Commerce Interface provides export interfaces for all shop-relevant master data, which the store can use to retrieve the communicated changes.
The webshop has to be provided with the availabilities initially every night. For performance reasons, this daily stock reconciliation is done via a pre-calculated table incl. timestamp of the calculation. In the webshop the entered sales orders are deducted independently from the available quantities. As soon as a movement occurs in BC that affects availability, a request must be sent to the web store so that it can retrieve the current availability for the corresponding item variant. Individual requests in BC via the interface are calculated live. The stock relevant for the webshop is located by the location group on the webshop channel.
For the multi-channel approach, it is also necessary to consider the stocks in the stores. Items that are only sold in the stores should also be displayed in the store. For this purpose, the webshop can provide a store finder that allows the customer to see where items are available.
The sales orders created in the store are transferred to BC via a sales order interface, whereby the webshop specifies the sales order number. A buffer table is filled from which the sales orders are created. The matching to already existing customers takes place via the unique customer number. Sales Orders for new customers are marked as such. New customers can be created in the system via the sales order interface. Prices and discounts are transferred identically from the webshop to the BC sales order. For the sales orders, the freight costs are transferred in the sales order header. The sales orders created in BC are automatically released after various checks. These sales orders can be displayed in a separate batch. A sales order confirmation mail is generated for the customer from the webshop. A subsequent change of transferred sales orders in the webshop is not possible.
The status of a sales order is communicated to the store on an item-by-item basis via the sales order status interface. (created, cancelled, delivered, invoiced, credit note).
A possible packing station in the delivery address can be transferred via the "Address Supplement" field in the interface.
Customers should be able to reserve goods in the store that are in stock only in stores. A separate interface is provided for such a reservation. The result of an import via this interface is a stock transfer request from the corresponding store to its stored reservation warehouse. These requests are also displayed in the role center and the goods must be searched out. If the goods are found, the request must be posted. This transfers the items to the reservation warehouse in terms of inventory. The document number of this booking is communicated to the store and the customer is informed about the store. When the customer picks up his reserved goods, the document can be found via the communicated number and a transfer back to the store stock can be booked. After checking the goods, the customer buys his items normally through the checkout. For reservation, the webshop is not allowed to perform pre-authorization and therefore capture. For items not found, the stock transfer request must be cancelled. The store is informed about it and passes the information to the customer.
Returns are recorded in the webshop by the customers and transmitted to BC on line level via the returns interface. Return reasons are to be used for this. The leading system for the return reasons is BC. After the return has been checked, it is created in BC. A reference to the original sales order is necessary and visible.
Voucher purchases in the webshop are realized in the sales order interface via a separate line type.
In BC, all voucher bookings are mapped either directly via G/L accounts or via resources. These bookings are voucher sales or voucher redemptions.
