5 Integration Configuration
This chapter covers configuration that needs to be done in order to extract WMS transaction records and set up the outbound interfaces.
Schedule Jobs
Create a schedule job for Inventory History that will extract the relevant information during scheduled intervals from WMS Cloud. This needs to be set up for Receipts, RTVs, Stock Orders, Inventory Adjustments, and Outbound ASNs. You can create one schedule for all of these entities, or separate schedules by functional area. Segregating has the advantage of setting different frequency on each scheduled job which is set using the Every and Period fields. The example below shows how the Generate Inventory History extract in WMS Cloud could be setup in three different schedules based on the activity code that correlates to a Merchandising entity.
Table 5-1 Inventory History Extract in WMS Cloud
Job Type | Activity Code | Schedule Name | Schedule Type | Every | Period |
---|---|---|---|---|---|
Generate Inventory History Extract |
1 |
Receipts |
Interval |
Set these fields to values between 1 and 5 minutes, depending on the volume of transactions that are being processed in your warehouse. The more transactions being processed, the shorter the interval should be. |
|
Generate Inventory History Extract |
10 |
SOStatus |
Interval |
||
Generate Inventory History Extract |
19 |
InvAdj |
Interval |
Enabled Auto Send
The main way to extract WMS transaction records is through scheduled jobs at pre-determined intervals. You can also automatically send inventory history records in a real-time manner as and when they are created. They are sent through the Output Interface setup just like other outgoing messages configured through scheduled jobs. To enable Auto-Send of Inventory History for an activity code, choose enable_auto_send from the Inventory History Activity Parameter screen. If you are using this option for integration, ensure all activity codes generated in the same group in WMS are integrated using the enable_auto_send option. This ensures that these integration messages are interfaced in the required order, making consistent updates to Merchandising.
Configure Outbound Interfaces
Outbound interface configurations must be created in WMS Cloud for each facility, one for each of the following exports:
-
Inventory History
-
Outbound Loads
-
Outbound Manifest
Inventory History Export
The Inventory History export is used to communicate updates to receipts, for purchase orders, transfers and allocations, stock order status updates, and inventory adjustments. To configure this for export, set the interface format to XML on the Output Interface Configuration for Inventory History Export.
Note:
Although these exports require configuration in WMS, these are not customizable integrations. Only the activity codes described in this section are supported in the base integration.
Next, create three targets for Inventory History Export, using the appropriate host and port for your implementation in the URL definition. The target creation can be done in the WMS Cloud application under the Output Interface Configuration tab.
Figure 5-1 Output Interface Configuration
![Output Interface Configuration Output Interface Configuration](img/inventory-historyexport.png)
Target 1: Receipts
URL: http://<host>:<port>/usm/EventListener.do?app=rib-lgf&family=Receiving&type=ReceiptMod
Output Interface Target Criteria:
-
Column name = Activity Code
-
SQL operator = '='
-
Column value = '1|4'
Target 2: SOStatus
URL: http://<host>:<port>/usm/EventListener.do?app=rib-lgf&family=SOStatus&type=SOStatusCre
Output Interface Target Criteria:
-
Column name = Activity Code
-
SQL operator = IN
-
Column value = '10|11|12|27|31|32|54|85'
Target 3: InvAdj
URL: http://<host>:<port>/usm/EventListener.do?app=rib-lgf&family=InvAdjust&type=InvAdjustCre
Output Interface Target Criteria:
-
Column name = Activity Code
-
SQL operator = IN
-
Column value = '2|4|17|19|22|23|24|25|29|30|49|50|53|65'
-
See "Appendix - Activity Codes" for more details on these activity codes.
-
Outbound Loads Export
The Outbound Loads export is used to map shipments that are shipped via TL/LTL from the warehouse to Merchandising (RTVs and stock order shipments), SIOCS (stock order shipments to stores), and OROB (stock order shipments for customer orders), as opposed to via a parcel service such as UPS or FedExFoot 1. To configure this for export, set the interface format to XML on the Output Interface Configuration for Outbound Loads Export.
Note:
This determination is made based on the presence or absence of a parcel service in the Ship Via field for an order.
Next, create two targets for Outbound Loads Export, using the appropriate host and port for your implementation in the URL definition. The target creation can be done in the WMS Cloud application under the Output Interface Configuration tab.
Figure 5-2 Output Interface Configuration
![Output Interface Configuration Output Interface Configuration](img/inventory-historyexport.png)
Target 1: RTV
URL: http://<host>:<port>/usm/EventListener.do?app=rib-lgf&family=RTV&type=RTVCre?interfaceType=ObLoad
Output Interface Target Criteria:
-
Column name = Order type
-
SQL operator = IN
-
Column value = RTV
Target 2: ASNOut
URL: http://<host>:<port>/usm/EventListener.do?app=rib-lgf&family=ASNOut&type=ASNOutMod?interfaceType=ObLoad
Output Interface Target Criteria:
-
Column name = Order Type
-
SQL operator = IN
-
Column value = B2B | B2C
Target 3: ASNOut
URL: http://<host>:<port> /usm/EventListener.do?app=rib-lgf&family=ASNOut&type=ASNOutCre&interfaceType=OblpnShipping
Output Interface Target Criteria:
-
Column name = Order Type
-
SQL operator = IN
-
Column value = B2B
Outbound Manifest
The Outbound Manifest export is also used to map shipments to Merchandising (RTVs and stock order shipments), SIOCS (stock order shipments to stores), and OROB (stock order shipments for customer orders). But unlike the Outbound Load Export, it is done via a parcel serviceFoot 2. To configure this for export, set the interface format to XML on the Output Interface Configuration for Outbound Manifest.
Note:
This determination is made based on the presence or absence of a parcel service in the Ship Via field for an order.
Figure 5-3 Output Interface Configuration
![Output Interface Configuration Output Interface Configuration](img/inventory-historyexport.png)
Next, create two targets for Outbound Manifest, using the appropriate host and port for your implementation in the URL definition. The target creation can be done in the WMS Cloud application under the Output Interface Configuration tab.
Target 1: RTV
URL: http://<host>:<port>/usm/EventListener.do?app=rib-lgf&family=RTV&type=RTVCre?interfaceType=ObManifest
Output Interface Target Criteria:
-
Column name = Order type
-
SQL operator = IN
-
Column value = RTV
Target 2: ASNOut
URL: http://<host>:<port>/usm/EventListener.do?app=rib-lgf&family=ASNOut&type=ASNOutMod?interfaceType=ObManifest
Output Interface Target Criteria:
-
Column name = Order type
-
SQL operator = IN
-
Column value = B2B | B2C
For ALL of the targets listed above, include the following:
-
Interface Protocol = REST Web Service
-
Username = <username for your XXX account>
-
Password = <password for your XXX account>
Note:
If the account password expires or is changed, it needs to be changed here as well.
Other Configurations
There are a few other configurations you'll need to consider in WMS Cloud that are used in the integrations with Merchandising, SIOCS, and OROB.
Sequence Counters
You will need to configure the sequence length for specific counters in the Sequence Counters tab in WMS Cloud to ensure the generated sequence numbers do not exceed the length supported by the integration to Merchandising. The following are the counter codes that need to be configured:
BOL Number
The sequence count used for generating BOL numbers is used in the integration of stock order shipments from the warehouse and mapped to the BOL number in Merchandising. It must be configured such that the combined prefix and sequence number does not exceed 17 characters in length that are allowed by the integration.
Inbound Shipment Number
The sequence counter used for generating shipment numbers is used in the integration of DC to DC shipments. It must be configured such that the combined prefix and sequence number do not exceed 30 characters.
Load and Parcel Manifests
The sequence counter used for generating load and parcel manifest numbers is mapped to the RTV external reference number in Merchandising. It is also used for mapping to the ASN number for outbound shipments from the warehouse. For both of these, the sequence must be configured such that the combined prefix and sequence number do not exceed 14 characters.
IB Shipment Types
When mapping inbound ASNs to WMS Cloud, the integration will map to a specific shipment type if the ASN does not contain cartons - this could be a vendor ASN or an ASN from another warehouse or store. This shipment type will be determined, on receiving the ASN, whether or not carton details should be mapped to Merchandising. This is needed because WMS Cloud will create an LPN if one doesn't exist, and if Merchandising also received the inbound ASN from an external system that did not contain carton IDs, it won't be able to understand the carton details from WMS Cloud. To support this, you will need to configure the following shipment type:
-
NO CARTON - the other required fields in WMS Cloud to values that make sense for your business. Only the shipment type itself is used in the integration.
Company Configurations
Decimal Support
Merchandising supports up to 4 decimal places for quantity and currency values. Hence, it must be ensured that WMS Cloud is also configured to support that many decimal places as well. This is done using the Companies view in WMS Cloud by clicking on the Decimal Settings option. You will need to configure both the Max Qty Decimal Precision and the Max Weight Volume Dimension Decimal Precision.
![Decimal Settings Decimal Settings](img/dec_sppt_set.png)
Next, decimal tracking has to be enabled on the items that would be handled in decimal quantities. In the Items view, select the item and click on the edit icon. In the edit pane, check the Handle Decimal Qty check box.
![Items Screen with Handle Decimal Quantity Checkbox Items Screen with Handle Decimal Quantity Checkbox](img/dec_tracking.png)
Enforce Ship Dates
There are parameters at the company level in WMS CloudFoot 3 that determine whether a message will be displayed to the user during loading if the dates sent for an outbound shipment (transfer, allocation, or RTV) are earlier than the start ship date or later than the stop ship date when compared to the current date. If this is not set, then these dates will be for reference only. It is recommended that for implementations with Merchandising that these be set to No.
![Enforce Ship Dates Parameter Enforce Ship Dates Parameter](img/enfce_shp_date.png)
Packing Routing Mode
To support the Ship Via configurations described below, the company level parameter PACKING_ROUTING_MODE should be set to mode_0.
![Packing Routing Mode Parameter Packing Routing Mode Parameter](img/pack_route_mode.png)
Default Inventory Status
For inventory adjustments, you will also need to configure the value ATS into the DEFAULT_ERP_BUCKET_FOR_RECEIVED_INVENTORY parameter in the Company Parameters page, as shown in the image below. This is used to differentiate inventory adjustments that are moving inventory out of stock completely in the warehouse (which is sent to Merchandising as a null disposition) and those that would move inventory from a locked status to available status in the warehouse, or vice versa.
![Default Inventory Status Default Inventory Status](img/dflt_inv_status.png)
Ship Output Merge Details
The company parameter SHIPOUTPUT_MERGE_DETAILS should be set to Yes when integrating with Merchandising. This parameter is to ensure that if an outbound shipment (e.g. allocation to the store) has the same item being picked from multiple locations in the warehouse that the details are merged together on a single line item in the outbound integration, rather than one line per warehouse location.
Facility Configurations
Ship Via Configuration
The Ship Via code is used by WMS Cloud to determine the carrier that should be used for shipping and is required for all order types. For B2C orders, this will be communicated from Merchandising based on the information sent from OMS. However, for other order types, B2B and RTV, Merchandising doesn't communicate a preferred carrier. For B2B orders, it is recommended that you set a default at the facility level to prevent having the user from having to enter a value manually for each shipment. This can be done by doing the following:
-
At the company level, configure the Packing Routing Mode, as described above.
-
At the facility level, select the default ship via code to use for B2B orders. For B2B orders, the Ship Via code must not be longer than 4 characters in order to correctly map to Merchandising.
![Default Ship Via Code Default Ship Via Code](img/dflt_ship_code.jpg)
For the RTV order type, this will have to be manually selected for each order.
![Manually Select Shipper Manually Select Shipper](img/mnl_slct_shipper.png)
Create Facility Transfer Shipment for All
This parameter is used by WMS Cloud to enable automatic creation of an ASN in the destination facility. However, the shipment created doesn't contain the order number, which means it cannot be used to communicate the order number as expected by Merchandising on receipt at the destination facility. Instead, when integrated with Merchandising, the inbound shipment will be created by the integration layer based on the outbound ASN from the shipping facility, including the order number, so this parameter should be set to N.
![facility parameters facility parameters](img/facility_params.png)
RF Configuration
WMS Cloud allows for configuration of certain RF screens to support defaulting and influence system behavior. The following configurations are strongly suggested when integrating with Oracle Retail solutions.
Create LPN
Create {lpn} (or Createlpn) is an RF option in WMS Cloud that can be used to add to inventory or move inventory out of an active location. Usually two different screens are used to handle these two functions.
If you plan to use the Createlpn RF option to move inventory out of an active location by setting the inventory-source to Active, then it is mandatory that you configure it to have the mode set to No reason code prompt in order to properly integrate with Merchandising.
In the example below, you can see that two modules have been created, one to add inventory and one to move inventory out of active, called Split from Active.
![RF Configuration RF Configuration](img/rf_config.jpg)
Then, in the screen below, the inventory-source and mode have been configured as required to Active and No reason code prompt, respectively.
![Screen Parameters Set Screen Parameters Set](img/params_set.jpg)
Receive LPN
Depending on the receiving module you are using, Receive {lpn} Shipment or Receive {lpn} Load, you should configure the parameter prevent-entire-po-to-asn-conversion-flg to be set to Yes. This flag prevents WMS Cloud from converting the entire purchase order into an ASN in situations where an ASN is not received from the supplier, which can limit updates to the PO that can be made in Merchandising during receiving.
![Receive LPN Receive LPN](img/receive_lpn.png)
Configure Integration Layer
Configure USM
In USM, URLs will need to be configured for your environment to allow the RIB to communicate with WMS Cloud. This configuration will be done by the Oracle Cloud Operations team, but you may be asked to help provide the URLs for this configuration. These are the two URLs that need to be configured:
-
LogFire_Host_Url_Key – this is your link to the WMS Cloud application; configure this appropriately to allow USM to connect to the WMS Cloud application.
-
RibLgf_host_UrlKey – this is the link to the RIB application for this integration; set this field in USM to enable it to connect with the RIB
Configure Static DVMs
Once the links to the end applications are configured, the static DVMs have to be configured with values from your specific implementation for company code and facility codes. These are mandatory values. The DVMs that are to be edited are:
-
CompanyCode_dvm.LogFireIntegration – this is where the company code is to be set. The company code to use here can be found in the WMS Cloud Companies screen. The entry to be made in the DVM is "CompanyName" in the name column and your company code in the value column. Company code is case sensitive.
-
FacilityCode_dvm.LogFireIntegration – this is where the facility codes are to be set - one record for each physical warehouse that you configured in WMS Cloud in the Warehouse conversion section. The entry to be made in the DVM is the warehouse ID in the FacilityId column, facility type in the FacilityType column and facility time zone in the FacilityTimeZone column. This should match exactly how you have configured your facilities in WMS Cloud.
Note:
There is also a static DVM for country code, however this is not required for the integration so does not need a configuration.
More details about the configuration of the USM application can be found in the Oracle Retail Integration Cloud Service Universal Service Mapper User Guide, a link for which is provided in "Appendix - Activity Codes".
Configure RIB
When being sent from Merchandising to WMS Cloud, data passes through an application called RIB-TAFR (Transformation Addressing Filtering Routing). As part of the standard RIB configuration, the warehouse facility IDs need to be configured in the RIB in order for the TAFR logic to filter and route messages. This is done by the Oracle Cloud Operations team. Once you have your warehouse facilities set up in WMS Cloud, you will need to provide these IDs to the Oracle Cloud Operations team for them to do this configuration. More details can be found in the Oracle Retail Integration Bus Operations Guide.
Figure 5-4 RIB Warehouse Facility IDs
![RIB Warehouse Facility IDs RIB Warehouse Facility IDs](img/rib-systemoptions.png)
Configure Merchandising
The standard RIB messages used for WMS Cloud integration with Merchandising are generally the same as those that are used for integration with other solutions, such as SIOCS. However, for certain integrations, due to the way that WMS Cloud requires data to be sent in a different manner for modified data. In the standard RIB messages used for SIOCS, only the data elements that have changed are sent. For example, if an item description is updated, only the item ID and description that changed are included in the published modification. However, for WMS Cloud, the full item details need to be resent in the case of a modification or delete. To support this, the Publish Full Objects system option in Merchandising must be checked (Y) in order for the modified data to correctly update WMS Cloud.
Finally, the Retain Customer Information flag must also be checked (Y) in order for customer details to be passed to WMS Cloud for customer order fulfillment.
Configure OMS
OMS does not integrate directly with WMS Cloud to send customer orders; instead customer order details are integrated through Merchandising, including attributes like carrier codes, necessitating coordination of codes used between solutions. In particular, the shipping carrier codes (Ship Via codes in OROMS), which identify the shipping company to be used for the customer order, need to be setup to match the Ship Via codes in WMS Cloud.
For more details on how customer orders integrate to WMS Cloud from OROMS, OROB, and Merchandising, see the Merchandising and SIM Integration with OMS and OB white paper found on My Oracle Support under ID 2088235.1.
Note:
There is no special configuration required in SIOCS in order for it to receive messages from WMS Cloud. That is all managed through RICS.
Footnote Legend
Footnote 1:This determination is made based on the presence or absence of a parcel service in the Ship Via field for an order.
Footnote 2:
This determination is made based on the presence or absence of a parcel service in the Ship Via field for an order.
Footnote 3:
ENFORCE_STOP_SHIP_DATE and ENFORCE_START_SHIP_DATE