D Appendix - Known Issues

The following are features that are areas that are not supported in both solutions, the integration, or both.

Table D-1 Known Issues

Issue	Notes
Receiver Unit Adjustments	WMS Cloud does not have a concept of a receiver unit adjustment (RUA) for purchase orders. To support this concept in the integration between solutions, you can configure a reason code of RUA for use with pre-verification adjustments related to a purchase order. This will then map the resulting IHT-4 record in WMS Cloud, using the PO number captured on the record, as a receiver unit adjustment in Merchandising. Any other reason code used for a pre-verification adjustment, or if a PO is not associated with the adjustment, will result in the adjustment being mapped as a regular inventory adjustment in Merchandising, without impacting the receipt. Care should be taken to ensure the correct reason code is selected by WMS users when performing this operation to ensure adjustments are correctly made. Additionally, this reason code should not be used for any other adjustment situations in WMS, as a non-numeric reason code is not supported in Merchandising for inventory adjustments, so an error would be raised. If you don't wish to use this feature, do not configure the RUA reason code in WMS Cloud.
RTVs from unavailable status	RTVs cannot be created in Merchandising from an unavailable status when integrating with WMS Cloud, as the inventory status code to use for each item/quantity on the RTV is not available in the integration. Additionally, RTVs initiated in WMS Cloud and sent to Merchandising on shipment must have items moved to an allocatable status prior to shipping in order to correctly update the item inventory in Merchandising.
Merchandising update on waving	Currently Merchandising is not updated when WMS Cloud starts working on a stock order (transfer or allocation) by waving, as the activity code used to support this update do not have sufficient information (items and quantities) available to update Merchandising. Care should be taken when making changes in Allocation Cloud Service or Merchandising to stock orders that have been sent to WMS Cloud that may have been waved but not yet picked, as these updates will be rejected by WMS Cloud.
Item Delete	When an item is deleted in Merchandising, it is not communicated to WMS Cloud. Items must be manually deleted from WMS when deleted from Merchandising.
Transfers with Finishing	Integration of finishing details is not supported between Merchandising and WMS Cloud. If you have internal finishers in your warehouses where you need to send finishing information to the warehouse, this integration will need to be field enabled in order to support this process.
Customer Order Returns	Integration between Oracle Retail Order Management Cloud Service (OROMS) and WMS Cloud for customer order returns to a warehouse is not currently supported in the integration. Customers requiring this functionality can look at these two options: Processing the return in both WMS Cloud and OROMS manually. In WMS Cloud, it would be processed as an adjustment using reason code RMA (which is not mapped to Merchandising). Then, when the return is processed in OROMS, it will be communicated to Merchandising (including the warehouse details) to update inventory.Foot 1  Field enable the integration between WMS Cloud and OROMS using standard APIs for each product.
Cycle Counts	Cycle counts between WMS and Merchandising will require manual communication of the items to be counted and the date for the count, based on the cycle count request created in Merchandising. After the count, the results should be extracted into a file to be sent to Merchandising in the format specified in the Conversion of WMS Stock Count Results File (lifstkup) integration. See the Merchandising Operations Guide for more details.
Allocatable Lock Codes	Allocatable lock codes, which allows different classifications of available inventory, are not supported in the WMS Cloud and Merchandising integration. This functionality should not be configured in WMS Cloud.
Ship Via for RTVs	The ship via code on an order is used by WMS Cloud to determine the carrier that should be used for shipping and is required for all shipments by WMS Cloud. For B2C or B2B order types, this is either provided in the integration (B2C) or able to be derived (B2B). However, for RTVs this must be manually selected on the order.
Transaction Item with a Parent	Transaction-level items setup in Merchandising with a parent, where the diffs at the parent level are all Diff IDs, rather than one or more diff groups cannot be supported when integrating with WMS Cloud. This is due to the way that WMS Cloud handles the item code, by concatenating item parts a-f together in a way that must be unique. See the Convert Master Data section for information on how items are mapped to the WMS Cloud parts. Items with a parent that does not use diff groups or diffs is supported and will be treated like an item without a parent in WMS Cloud.

^Footnote 1 See also the Merchandising and SIM Integration with OMS and OB white paper at My Oracle Support ID 2088235.1.