Oracle® Retail Merchandising and WMS Cloud Implementation Guide Release 19.0 F25718-02 |
|
Previous |
Next |
This chapter covers configuration that needs to be done in order to schedule jobs and the outbound interfaces.
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 |
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
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.
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'
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|54'
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|53|63|64'
See "Appendix C - Activity Codes" for more details on these activity codes.
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.
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
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. |
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
Target 2: ASNOut
URL: http://<host>:<port>/usm/EventListener.do?app=rib-lgf&family=ASNOut&type=ASNOutMod?interfaceType=ObManifest
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. |
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. These include:
Sequence Counters
Decimal Support
Enforce Ship Dates
Ship Via Configuration
RF Configuration
Customer Order Returns
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:
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.
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.
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.
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.
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.
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.
Packing Routing Mode
To support the Ship Via configurations described below, the company level parameter PACKING_ROUTING_MODE should be set to mode_0.
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.
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.
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 the RTV order type, this will have to be manually selected for each order.
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.
Then, in the screen below, the inventory-source and mode have been configured as required to Active and No reason code prompt, respectively.
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
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 C - Activity Codes".
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.
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.
OMS does not connect directly to 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.