Manage Movement Requests

The Movement Requests UI makes it simpler and easier to handle internal warehouse movements by tracking how you move materials around your warehouse. If you need to move materials from certain areas to assembly areas or from one area to another, Movement Request will tell you, how much inventory you need to move, and where you need to put your inventory.

Some useful examples for Movement Requests in WMS include:

• Assists you in delivering required items to the assembly area when Work Orders are released by manufacturing.
• Handle internal warehouse movements like locked batches to the recall area.
• Handle slotting movements for moving LPNs/Skus from one location to another due to better positioning of the products to cater for changing demands.

Movement Request Header

In the “Movement Request Header” UI, you can track/view your Movement Request and create/update Movement Requests (depending on status.) To enable the Movement Request Header UI, add the following Group Permissions:

• movement_request/can create movement request
• movement_request/can edit movement request
• movement_request/can delete movement request

To enable movement request status updates, make sure that the Replenishment Template UI has the replenishment trigger mode set as "Movement Request Based Replenishment."

Note: Orders cannot be updated in the Movement Request Header UI after they move from created status. You must use the Movement Request PATCH API to update movement requests after they are in Created status. See the REST API Guide for more details.

The header section of this UI contains the following columns:

UI Column	Required	Description
movement_request_number	Yes	WMS Entered/Passed or Auto Generated number. Accepts letters or numbers.
company_code		Displays the company code in the movement request UI.
facility_code		Displays the facility code in the movement request UI.
movement_type	Yes	Drop down list from available Movement Types. For more details look at the movement type section below.
status	Yes	Options: Created Partly Allocated Allocated In Picking Complete Cancelled
external_movement_request_nbr		If Movement Request is initiated through Fusion Inventory or any other ERP System, erp_movement_request number will be passed.
priority	Numeric	Useful for prioritizing across different movement requests. Can be defaulted to 0 if priority is not specified.
Custom fields 1 to 5		Related custom fields.
Custom decimal (1 to 5)		Custom fields supporting decimals.
Custom Date (1 to 5)		Custom fields supporting Data time values.
Cust short text(1 to 12)		Short Text fields
create_user		Create User
mod_user		Mod User
create_ts		Create Timestamp
mod_ts		Mod Timestamp

From the Movement Request Headers UI, you can manage the From/To Movement Request Status.

Movement Request Detail

When you are creating Movement Request Details:

• Movement request detail provides the SKU and quantity information that will be picked and delivered.

• Movement request detail can contain a destination zone or destination location. If the destination zone is provided, replenishment logic will pick the location within the specified destination zone.

Deallocate/Short Quantities from Movement Request Detail

The following action buttons have been added to the Movement Request Detail UI:

Action Button	Allows you to:
Deallocate	Select movement request details to be canceled. Deallocate one or more details from the movement requests selected. Users will be able to rerun the deallocated movement request.
Short	Deallocation and cancel one or more movement request details.

Deallocation and Other Movement Requests

Note: There could be multiple movement requests which can be associated with Full LPN Replenishment, when one of the movement request detail is deallocated, other movement request details will be impacted, similarly the same scenario could happen for Replenishment with allocation UOM of cases or packs.

For Example:

A single LPN-1 with 100 units could have been allocated against three movement request details, MR1, MR2, MR3, each one pointing to different Work Orders for full LPN Replenishment. Let's say MR1 is pointing to Work Order-1, MR2 is pointing to Work Order-2 and MR3 is pointing to Work Order-3. When the user wants to deallocate Movement Request MR-2, then movement requests MR-1 and MR-3 will also be de-allocated.

Cancel a Movement Request

To cancel a movement request:

1. Select the movement request from the Movement Request Headers UI.
2. Go to the Movement Request Detail UI.
3. Click Short to cancel the the movement request.

Once you click Short, the system will prompt you to add a Reason Code:

Once the movement request is shorted, refresh your Movement Request Detail and Movement Request Header screens, and then the status should move to “Cancelled.”

Movement Type

The Movement Type UI allows you to configure Movement Types. This screen allows create, read, update, and delete operations. Movement Types are a great way to differentiate between types of moves in the warehouse. This will help you to identify movements such as component movements to assembly work stations or movements to handle recalls. Movement Types will help in segregating the needs and also gives a good selection criteria for filtering different kinds of movement while subjecting for Replenishment Wave Runs.

The detail section of the Movement Type UI will contain the following information:

UI Column	Required	Comments
Movement Type	Yes	Movement Type
Description	Yes	Description
allow_partial_allocation_flag		If enabled, it will allow partial allocation of the movement request,
Only Deallocate on short		If enabled, the system will decrement the movement request quantity upon performing shorting. Note: This is required for future usage. It will be used while shorting picks against relevant movement requests.

Input Interface

Movement Request is now an option in the Input Interface UI. This will allow external systems to create bulk Movement Requests. The interface will accept XML format.

From the Input Interface, you can access Movement Request from the drop-down. From here, you can access Movement Request Detail and it will show you all the movement requests that have been processed and their correct status. It provides another way for you to manage movement requests. You can view the interfaced movement request records that are in staging, view the status of the interfaced requests and details on errors (if any.)

In the Input Interface UI, you also have the option to create or delete a movement request with one or more details by uploading a movement request file (xml and flat files are supported.)

Create/Delete Movement Request Through Init Stage Interface API

You can also create or delete a Movement Request via the Init Stage Interface so that the movement requests created in Oracle Fusion/Manufacturing or any external manufacturing systems can be interfaced with Warehouse Management and the movement requests are created.

Sample Request URL

//intqa.wms.ocs.oraclecloud.com/lgf_21d_qa/wms/api/init_stage_interface/

Additional Details about Init Stage Interface:

• The movement request entity will process in both synchronous and asynchronous mode (async can be true or false).
• Both xml and flat files are supported.
• The only action codes currently supported are CREATE and DELETE at the movement request header level.
• Multiple movement requests can be provided in a single payload.
• If a single movement request has multiple details, the system will process the movement request only if all details successfully pass validations.
• Numbers are generated in Warehouse Management Cloud for the external movement request interfaced based on the movement request number interfaced from ERP/Manufacturing/any other external system.

Note: if there are errors with some of the movement requests in the passed data, only the movement requests with errors should not get processed. The rest of the movement requests should be created/deleted based on action code.

Configure and Manage Movement Requests via Replenishment Waves

You can configure and manage movement requests in the Replenishment Template UI. The replenishment wave will create tasks and tell you where to move the materials associated with movement requests.

Note: In Movement Request Based Replenishment, to support Work Order processing, the Assembly Flag needs to be enabled in the Locations UI.

For more information about the Assembly Flag, see Location Master.

Replenishment Trigger Mode

In the Replenishment Template UI, you can configure a new Replenishment Trigger Mode for movement requests. If Movement Request based replenishment is selected as the Trigger Mode, then the Replenishment logic will only search for eligible movement requests.

Also, when you select Movement Request Based Replenishment as the Replenishment Trigger Mode, the option to select a “Movement Request Search Rule” and “Movement Request Sequence Rule” becomes enabled and allows you to select Movement Request Searches and Movement Request Sequence Rules you have previously created.

Movement Request Search

When you are fulfilling movement requests through waves, you can now configure a search using the new action button Movement Request Search based on movement request related fields and filter based on a combination of fields. This allows you to filter any relevant movement requests to be processed at a given time.

In the Replenishment Template UI, you can now create movement requests using the Movement Request Search action button.

Movement request related fields added in Movement Request Search - Selection Criteria

• In the Replenishment Template -> Movement Request Search UI, selection criteria button is available
• In the selection criteria, movement request related fields are added and allow you to define criteria with them
• In the selection criteria, common fields related to item entity are available and can be used with movement request fields to configure selection criteria

Movement Request Sequence Rule Action Button

The Movement Request Sequence Rule button (in the Replenishment Template UI), allows you to configure rules in a pre-defined sequence, in order to prioritize fulfillment of movement requests. From the create/edit/copy pane of the Replenishment Template >> Sequence Rule, “Dynamic Movement Request Search” is added in the Template Type drop-down as an additional option to define sequence rules.

Note: To create a movement request sequence rule, you must first create a template (from the Replenishment Template UI) with Replenishment Trigger Mode= 'Movement Request Sequence Rule'. Next, select the record and click on the movement request sequence rule button.

Inventory History Transactions (IHTs) for Movement Request Status Changes

Whenever a movement request status changes, Warehouse Management Cloud creates an Inventory History Activity 88-Movement Request Status Change and IHT-89 Movement Request Detail Status Change so that it can be picked up by external systems/ERP systems/slotting systems to make any necessary actions. You can view the history activity in the Inventory History Activity Parameters UI.

Note: Standalone replenishment always replenishes to a permanent location. If the Replenishment Trigger Mode is set to “Movement Request Based Replenishment” you can now replenish to dynamic locations also.

Warehouse Management can replenish to a particular location (has to be type active) via the Replenishment Trigger Mode field. In the Movement Request Detail UI detail, the destination replenishment zone can be permanent or dynamic.

In the Replenishment Template View ->Replenishment Rules action button, the following is also supported:

• round up one uom
• Consolidate and distribute replenishment

Note: Ignore capacity for last permanent location will not be supported for movement request replenishment.

In the Replenishment Rules ->Replenishment Rule Sequence, all allocation methods are supported (for example, First in First Out, Last in First Out.) Also, all types of Replenishment UOM (LPNs, Cases, Packs, and Units) and Consolidate and Replenishment are supported.

The corresponding replenishment related Task Types (for example, Consolidate-Replenish, Replenish-LPN, Replenish-Cases) can also be used for movement request.

If you want to run cancellation waves, you can do this in the Replenishment Template View UI via the following fields:

• Cancel Partially Allocated – will cancel partially allocated part of movement request line
• Cancel Fully Allocated – will cancel corresponding unallocated part of movement request line

Movement Request Status Updates

Now, when movement requests are fulfilled through standalone replenishment, in the Movement Request Detail UI, the respective status of movement requests is updated to "Partly allocated" or "allocated", depending on the allocation done. The following table details the status changes that will happen depending on the scenario:

UI	Status Changes To
Movement Request Detail	"Partly Allocated" - when there is some quantity allocated for the movement request detail but it is less than the movement request detail required quantity "Allocated" - when the quantity allocated is same as the movement request detail required quantity The Allocated quantity in the respective Movement Request Detail will be updated
Movement Request Header	"Partly Allocated" - when any one of the movement request details associated with that movement request header are partly allocated or allocated "Allocated" - when all the movement request details associated with that movement request header have a status of "Allocated"

Update Action Code in Movement Request Interface

If you interface a file with action code UPDATE and there is no existing record found in the application for that Movement Request, the system will create the Movement Request.

Then, if the movement record is already present in WMS, the system will update the existing record.