This guide describes how to add a supplier to an existing IOM shop instance. It is addressed to IOM operators (e.g., an IOM administrator who has access to the whole system).
A questionnaire guides the target group to collect the necessary information in the run of the supplier configuration.
The guide does not cover any kind of supplier approval processes. So there is information on the following configuration tables in this document:
Supplier2ApprovalStateCodeDefDO
Supplier2ApprovalStateCodeReasonDefDO
Shop2Supplier2ApprovalTypeDefDO
Term | Description |
---|---|
COD | Cash on delivery |
DO | Data Object - used as persistence entities to represent stored values in the database |
DOSE | Dynamic Order Supplier Evaluation |
EOL | End Of Life - the sale or support of goods and services is terminated |
IOM | The abbreviation for Intershop Order Management |
OMS | The abbreviation for Order Management System, the technical name of IOM |
OMT | The abbreviation for Order Management Tool, the graphical management tool of the IOM |
RMA | Return Merchandise Authorization / Return Material Authorization |
To follow this guide, good experience with SQL is required. Also, an understanding of the retailing model between the shop and suppliers is helpful.
An essential parameter for the supplier configuration is the OMS internal ID of the OMS shop instance to which the new supplier should be connected. From now on this ID will be identified by <supplierid>
and <shopid>.
Note
After finishing the configuration a cache clear is required on all application servers. See Concept - IOM Synchronization of Java-based Caches, Overview - Intershop Order Management REST API.
Does the supplier support order responses? Does the supplier use the OMS ShopService to submit response messages? Does the shop system use the OMS feature to select a supplier with the order submission (shop system to OMS)? If TRUE, Shop2SupplierDO.shopSupplierName has to be agreed with the shop system. Which return reasons does the supplier use? Does the supplier use own identifiers/names for return reasons in the communication with the OMS? Does the shop/retailer support an RMA process? If TRUE: Which reduction reasons (name/identifier) does the retailer/shop use? Which reduction reasons (name/identifier) does the supplier use? What is the mapping of the reduction reasons between retailer/shop and supplier? Should the inventory of a product be set to 0 if a product is no longer included in the import data files? NoteQuestion Relates to Does the supplier use the OMS ShopService to submit dispatch messages (delivery notifications)? Does the supplier use the OMS ReturnService to submit return messages? Does the retailer/shop use the supplier for drop shipment? Does the retailer/shop allow the splitting of an order into multiple shipments? Does the supplier support the payment method COD in relation to the retailer/shop? If the order includes coupons, should these be transmitted to the supplier?
The following section describes how to add a new supplier to an existing shop instance.
The main entity of the supplier configuration is the database table SupplierDO.
All other supplier-related configurations refer to this table.
For all available values, please see Overview - IOM Database Documentation.
-- create a supplier instance INSERT INTO oms."SupplierDO" ( "id", "active", "contentSupplier", "countryCodeDefRef", "countryDefRef", "cutOffTime", "deliveringSupplier", "legal", "modificationDate", "name", "supplierName", "supportsReservation", "supportsResponse", "singlePositionArticle", "internalSupplierName", "parentSupplierRef", "cleanParentOnImport", "ignoreAdditionalPositions", "businessObjectProcessingDelay", "supplierTypeDefRef" ) VALUES ( 5000, TRUE, FALSE, 1, 29, '14:30', TRUE, TRUE, now(), 'Flagship store - North', 'Store - North', FALSE, FALSE, TRUE, 'warehouse_north', null, TRUE, TRUE, '15m', 2 );
Optional
This configuration is optional.
Note
This table is deprecated.
The table Shop2SupplierDO
defines the suppliers that are used by a shop. It defines the relation between a shop and a supplier. See Guide - IOM Shop Onboarding | Supplier for detailed configuration.
The following section describes further configurations of a supplier, such as used tax type, charge types, and the location of the shop including currency.
Taxes are essential to a business model.
Optional
This configuration is optional.
Use the table to configure if the supplier insists on its own values for the taxes. If nothing is configured, the IOM-internal values are used. It is used by Order Placement - IOM to supplier.
Note
In order to produce a complete match between the shop and the supplier, it is important to know which tax types the OMS shop instance uses.
SELECT "taxTypeDefRef" FROM oms."Shop2TaxTypeDefDO" WHERE "shopRef" = <shopId>
If there is nothing configured for the related shop instance, you have to find out which OMS-internal tax types are used by the shop.
-- assign a tax type INSERT INTO oms."Supplier2TaxTypeDefDO" ( "id", "supplierTaxTypeName", "taxTypeDefRef", "supplierRef" ) VALUES ( nextval('oms."Supplier2TaxTypeDefDO_id_seq"'), 'FULL-TAX', 5, 5000 );
The table contains all tax types that are supported by the application by default. For all available values, please see Overview - IOM Database Documentation.
In general, a supplier is located in a country that also determines the currency.
Use the table to configure if the supplier insists on its own values for countries. It is used for order placement - OMS to supplier.
Note
In order to produce a complete match between the shop and the supplier, it is important to know which countries are used by the shop.
SELECT "countryDefRef" FROM oms."Shop2CountryDefDO" WHERE "shopRef" = <shopid>
If there is nothing configured for the related OMS shop instance, you have to find out which IOM-internal countries are used by the shop.
-- assign a country INSERT INTO oms."Supplier2CountryDefDO" ( "id", "countryDefRef", "supplierCountryName", "supplierCurrencyName", "supplierRef" ) VALUES ( nextval('oms."Supplier2CountryDefDO_id_seq"'), 9, 'BELGIUM', 'EURO', 5000 );
The table contains all countries, including their assigned currencies and localization codes that are supported by the application by default. For all available values, please see Overview - IOM Database Documentation.
Payment is the process of money transfer from one party to another, e.g., customer to merchant.
Optional
This configuration is optional.
Use the table to configure if the supplier insists on its own values for payment methods. Otherwise the property PaymentDefDO.name
is used. The configuration is used by Order Placement - IOM to supplier (XML element "Sales"
> attribute "method"
).
-- assign a payment INSERT INTO oms."Supplier2PaymentDefDO" ( "id", "paymentDefRef", "supplierPaymentName", "supplierRef" ) VALUES ( nextval('oms."Supplier2PaymentDefDO_id_seq"'), 10, 'PP', 5000 );
The table contains all payment methods that are supported by the application by default. For all available values, see Overview - IOM Database Documentation.
A carrier is a company that transports products or services.
The delivery, therefore, defines forms (i.e., standard) and options (i.e., night shipping) the transport has to fulfill.
Optional
This configuration is optional.
Use the table to configure if the supplier insists on its own values for the carrier. Otherwise the property CarrierDO.name
is to be used. Please see Guide - IOM Shop Onboarding | Carrier for CarrierDO.
The configuration is used by SOAP ShopService
method storeDispatch.
See Dispatch transmission.
-- assign a carrier INSERT INTO oms."Supplier2CarrierDO" ( "id", "supplierCarrierName", "carrierRef", "supplierRef" ) VALUES ( nextval('oms."Supplier2CarrierDO_id_seq"'), 'DHL', 11, 5000 );
Optional
This configuration is optional.
This configuration contains the name of a delivery form, as used by the supplier, with reference to the IOM-internal delivery form. There is no usage by the IOM itself, but it can be useful for customization.
-- assign a delivery form INSERT INTO oms."Supplier2DeliveryFormDefDO" ( "id", "deliveryFormDefRef", "supplierDeliveryFormName", "supplierRef" ) VALUES ( nextval('oms."Supplier2DeliveryFormDefDO_id_seq"'), 20, 'FF', 5000 );
The table contains all delivery forms that are supported by the application by default. For all available values, please see Overview - IOM Database Documentation.
Optional
This configuration is optional.
This configuration contains the names of delivery options, as used by the supplier, with reference to the IOM-internal delivery options. It is used by Order Placement - IOM to supplier (XML attribute name at element OrderPos
> DeliveryOption
).
-- assign a delivery option INSERT INTO oms."Supplier2DeliveryOptionDefDO" ( "id", "deliveryOptionDefRef", "supplierDeliveryOptionName", "supplierRef" ) VALUES ( nextval('oms."Supplier2DeliveryOptionDefDO_id_seq"'), 8, 'OVERNIGHT', 5000 );
The table contains all delivery options that are supported by the application by default. For all available values, see Overview - IOM Database Documentation.
Optional
This configuration is optional.
Note
This table is deprecated.
The table contains all delivery types that are supported by the application by default. For all available values, see Overview - IOM Database Documentation.
After the IOM is sending a delivery request to a supplier, the supplier responds with a message. This message contains whether the supplier agrees (or partially agrees, or disagrees completely) to deliver the requested products including its conditions (i.e., prices).
Optional
This configuration is optional.
Note
This table is deprecated.
Optional
This configuration is optional.
The table is relevant if the supplier supports order responses and if the supplier insists on its own values for response state codes. Otherwise, the property name
from table ResponseStateCodeDefDO
is to be used.
It is used by Response Transmission.
-- assign a response state code INSERT INTO oms."Supplier2ResponseStateCodeDefDO" ( "id", "responseStateCodeDefRef", "supplierResponseStateCodeName", "supplierRef" ) VALUES ( nextval('oms."Supplier2ResponseStateCodeDefDO_id_seq"'), 1, 'OK', 5000 );
The table contains all response state codes that are supported by the application by default. For all available values, see Overview - IOM Database Documentation.
If a customer returns products that were delivered to the customer before, the products will arrive in a package at a supplier. The supplier will note this to the IOM using a return message.
The process of:
requires several configurations of the supplier. Business processes are not mentioned here.
The table contains the return types that should be supported by a supplier. It is used by the configuration table SupplierReturnAddressDO
, the SOAP ReverseService
method returnSlipRequest
OMS,
and returnSlipRequest.
Also see Reference - IOM SOAP Web Services.
Best practice: At least configure the return type Recall, Return and Inversion.
Using the column rmaNo
will return this static RMA number in web services.
Using the columns rmaCode*, interval, startDate, minEndDate
, and ejbLookup,
supplier-specific RMA numbers can be generated.
For more information and all available return types, see Overview - IOM Database Documentation.
-- assign a return type INSERT INTO oms."Supplier2ReturnTypeDefDO" ( "id", "returnTypeDefRef", "supplierReturnTypeName", "supplierRef", "rmaNo", -- static rma number "preselected", "modificationDate", "rmaCodeCounter", "rmaCodeStart", "rmaCodeEnd", "interval", "startDate", "minEndDate", "ejbLookup" -- rma number generation ) VALUES ( nextval('oms."Supplier2ReturnTypeDefDO_id_seq"'), 4, 'RET', 5000, null, TRUE, now(), null, null, null, null, null, null, null );
The table contains all return types that are supported by the application by default. For all available values, see Overview - IOM Database Documentation.
Optional
This configuration is optional.
The table contains the return reasons supported by the supplier and can be used if the supplier does not use the default internal return reasons. Also see Return Transmission.
If not configured, all IOM-internal return reasons are possible and displayed in a selection grouped by the return type at the OMT.
Note
You have to configure at least one return reason per configured return type.
-- assign a return reason INSERT INTO oms."Supplier2ReturnReasonDefDO" ( "id", "returnReasonDefRef", "supplierReturnReasonName", "supplierRef", "preselected" ) VALUES ( nextval('oms."Supplier2ReturnReasonDefDO_id_seq"'), 307, 'WRONG_ITEM', 5000, FALSE );
The table contains all return reasons that are supported by the application by default. For all available values, see Overview - IOM Database Documentation.
The address specifies the location where a return shipment will be received.
It is used by the SOAP ReverseService
method returnSlipRequest
,
return label creation, and shop customer mails. See Reference - IOM SOAP Web Services, Overview - IOM Customer E-Mails, and also Overview - IOM Database Documentation.
Note
For each configured return type (see Guide - IOM Supplier Onboarding#Supplier2ReturnTypeDefDO) a return address has to be configured.
-- assign a return address INSERT INTO oms."SupplierReturnAddressDO" ( "id", "addressLine1", "addressLine2", "addressLine3", "addressLine4", "addressLine5", "supplier2ReturnTypeDefRef", "shop2SupplierRef" ) VALUES ( nextval('oms."SupplierReturnAddressDO_id_seq"'), 'Sports In Motion Warehouse', 'c/o Intershop Communications AG', 'Intershop Tower', '07740 Jena', 'Germany', 10001, 15000 );
Optional
This configuration is optional.
If the supplier insists on his own identifiers for reduction units, configure this table. Additionally, set the property sendOrderCoupon