Implementing backroom pick

Assumptions and limitations

• The carrier (SCAC) details and ship date (ExpectedShipmentDate) are already stamped on the shipment. By default, store associate does not have access to choose the carrier.
• The complete order is picked together and placed in the staging area. Partial picking and moving the products to the staging area is not supported.
• The Staging location required and Staging location translation required rules, which are set by using Sterling Business Center, are no longer applicable. When inventory is tracked in the store, a staging location is mandatory because this solution tracks inventory and the inventory moves to the packing station or to the customer pickup area after picking. Configuring automatic staging moves the inventory automatically to the staging location without any manual intervention.
• Passing serials as requested serials in shipment is currently not supported. This is because, usually in online ship orders or pickup orders, the customer does not pass a specific serial number.
• The prerequisite configuration steps that are required for backroom pick is completed. For more information about the configurations required for backroom pick task, see Configuring backroom pick.

Solution

Pick request creation

In Applications Manager, enable the on_success event of createShipment transaction to change the shipment status to Ready for Backroom pick or Ready for customer pick. Enabling this event will invoke the action that will change the shipment status to ready for backroom pick.

You must also add the Change Status Required condition and Change Shipment Status to Backroom Pick action.

The action invokes the YCD_Change_Status_Backroom_Pick_8.0 service. This service checks if backroom picking is required for BOPIS and SFS orders and invokes the ISFSIMCreatePickRequest service.

When Store Inventory Management is enabled, changeShipmentStatus invokes the update pick request API to create the pick request for that shipment.

Pick orders

• A store associate can start the backroom pick or the single order pick from the Pick orders portlet in the Order fulfillment view. In a store, which maintains inventory at location level, the store associate begins the picking process by looking at a list sorted by SLA, which is the expected shipment date.
• The store associate can click the count displayed at the center of the Pick orders portlet to view the complete list of shipments to be picked. The pick-requests:summary API is called to retrieve these counts.

  GET call on stores/{storeId}/pick-requests:summary?group_by=status&deliveryMethod=CARRY,PICK,SHIP

• The In progress and Not started count includes walk-in (or carry), pickup in store, and ship from store shipments. Hence, the resource permissions to pick shipments of each fulfillment type are considered.

  If a store associate does not have permissions to any delivery method, the portlet is not displayed at all.

• The store associate can also scan the order number in the portlet to open the pick request directly.

  Scanning an order calls the translateBarCode API with BarCodeType=StoreOutboundShipment and matches the bar code input with the shipment number and then the order number.

  If the bar code matches the shipment number, the pick request with that shipment number is fetched by using a GET on stores/{storeId}/pick-requests?shipmentNo API.

  If it matches the order number, the pick request is fetched by using the orderNo query parameter.

  If pick request is not started or is in progress, the Pick orders page opens. Else, Pick summary page opens.

  If the bar code input does not match any shipment number or order number or if a matching pick request is not found, an error is displayed.

• An action to print the pick request, which invokes the ISFPrintSIMPickRequestSummary service, is available. You can customize the out-of-the-box print capabilities by customizing this service or using the sample XML, /template/prints/ycd/xsl/ISFPrintPickRequest_multiApiInput.xsl.sample and /template/prints/ycd/xsl/ISFPrintPickRequest_output.xsl.sample.

  

• Another action, Pick all, is available on the Pick orders page if permission is given to 'Pick all' resources. This action invokes pick-tasks:pick-all API to pick all the non-serialized products, if available. The serialized products will not be marked picked because serial products must still be scanned.

Pick order list

• A store associate can click the In progress count to view shipments that are in the Backroom Pick in Progress status. Similarly, clicking the Not started count displays the shipments that are in the Ready for Backroom Pick status.
• The pick-requests and pick-requests:summary APIs are called to retrieve these counts:
  • GET call on stores/{storeId}/pick-requests?deliveryMethod=CARRY&status=NOT_STARTED,IN_PROGRESS&fields=requestedProducts&order_by=createdTimestamp%20asc&page_size=10
  • GET call on stores/{storeId}/pick-requests:summary?group_by=deliveryMethod&deliveryMethod=CARRY&status=NOT_STARTED,IN_PROGRESS
• By default, the pick requests are sorted from oldest to newest based on the pick request created timestamp. You can also sort pick requests by requestedBy. The default value for requestedBy is stamped as SYSTEM by the pick-requests API.

  Once sorting is changed. a GET call on pick-requests API is made with the appropriate order_by values, for example, createdTimestamp asc, createdTimestamp desc, requestedBy asc, or requestedBy desc.

  stores/{storeId}/pick-requests?deliveryMethod=CARRY&status=NOT_STARTED,IN_PROGRESS&fields=requestedProducts&order_by=requestedBy%20asc&page_size=10

• You can filter pick orders based on user to whom the pick request is assigned to, status, and order type.
  • The Assigned to list shows all the users of the stores with the current user as the first entry. The getUserList API is called at the time of login and stored in AppContext. The same user list is used to display the users in the Assigned to list. Whatever is selected is passed to GET pick-requests as the assignedTo query parameter.
  • Status binding is performed with pick request binding. Completed pick requests cannot be displayed with other statuses because open pick requests are stored in a different table than the completed pick requests. So, if user selects the Completed status, the other statuses are deselected automatically.
  • The Order type field is shown only in the Ship tab as only ship orders can be of different types, sales and transfer. Walk-in and pickup orders are taken as sales orders. Depending on the order type, pick-requests purpose query parameter is populated (SALES or TRANSFER).
  • On applying filter, a GET call is made on the pick-requests API with the appropriate query parameters.

Pick request execution flow

• When a store associate clicks the Pick or Continue pick button in the Pick order list page or when he scans the order or shipment number from the portlet, the pick task is assigned to that user. The assignedToUser validation ensures that the current user does not start any pick request that is already in progress by another user.
• A GET on pick-request/<pickRequestId> is called to get the updated assignedToUser and is matched with the current user.
  • If assignedToUser is not set, the pick-request/<pickRequestId> API is called to update assignedToUser and the pick execution screen opens. Also, the changeShipment API is called to update the AssignedToUser and changeShipmentStatus to Backroom pick in progress.
  • If assignedToUser is the same as the currently logged in user, the pick execution screen opens.
  • If assignedToUser is NOT the same as the currently logged in user, a window opens to confirm if the current user wants to continue or not.
• The Pick orders page displays the pick tasks with source location ID, item, quantity, inventory status, product class, and shorted products, if any.
  • If multiple pick tasks appear for the same source location, they appear under one location in the user interface.
  • If it at the time of the pick request creation, inventory is not found for any product or the store associate records shortage for a product, then the shorted products are displayed.
  • If the store is configured as a single location store, location labels are not displayed
• On scanning a bar code, translateBarCode API is called with BarCodeType = StoreItem/Location.
  • If location scan is mandatory, then location must be scanned before picking the product. If location scan is not mandatory, item can be scanned directly. System finds the matching location for that item and uses it.
  • If location is scanned, system sets it as the scanned or current location.
  • If item is scanned and if it is not a serialized item, matching pick task is found by a GET call on pickrequest/<pickrequestid>/picktasks?productId=<>&unitOfMeasure=<>&sourceLocationId=<>. Then, pick-requests API on this pick task is called with 1 unit. In the user interface, the pick task is updated to display that 1 unit is picked.
  • If a serial is scanned, matching pick task is found and pick-requests API is called with the serial. In the user interface, that pick task is updated by displaying the picked serial.
• If location scan is mandatory, the minus and plus icons and quantity update units can be clicked only when a location is scanned. Then, the operations are performed only if the scanned location matches the pick task source LocationId.
• In the quantity box, the minus and plus icons are enabled only when the Manually update quantity while picking resource permission is given in Applications Manager

  For a non-serialized item:

  • Clicking minus reduces the pick quantity by 1 unit. The undo-pick API is called and the pick task is updated.
  • Clicking plus increases the pick quantity by 1 unit. The pick API is called and the pick task is updated
  • When quantity is edited, the pick or undo-pick APIs are called depending on whether the quantity is added or reduced.
  For a serialized item

  • Clicking minus opens a window to remove the item. The store associate can scan the serial number and it will be marked as not picked. On scan, translateBarCode API is called with source as SIMSerial. If successful, undo-pick API is called by passing serial # and the picked serials are displayed.
  • Quantity cannot be edited by entering the number of units. Serial numbers should be scanned or typed in the scan field to be marked as picked or removed.

Record shortage

• If a store associate finds that in a location, the inventory is damaged or is in shortage, they must check if inventory is available in any other location in the store before marking it short. Click Alternate location to view other locations.
• GET alternate-source-locations API is called to get the alternate locations for that pick task. The API returns the list of locations that can fulfill the remaining units. If remaining units cannot be fulfilled, it will return locations with whatever units of inventory are available.
• If there are no locations with available inventory, then the store associate can record a shortage. They must also select the reason for choosing a different location or recording a shortage. Reasons are listed by calling the exception-codes API.
• Once the store associate selects an alternate location and a reason, the exception API on pick-task is called and an exception object is created on the pick task. If another location has the required inventory, a new pick task is created with the alternate location given as sourceLocationid and the quantity is updated as the remaining or available units. Quantity in the original pick task is reduced. If alternate location is not available, then shortage quantity on the pick task is updated.
• It is also possible that at the time when a pick request is created or when a shortage is recorded, inventory was not available, but later the store receives inventory. In such cases, the store associate can look for that available quantity and update the pick request by clicking the Refresh button.

  When a store associate clicks Refresh, the generate-tasks API on the pick request is called. This API checks if any other locations have inventory for the shorted products and if inventory is not found, a message is displayed. New pick tasks are created and the pick orders screen is refreshed. The generate-tasks API does not consider the locations where the shortage is already marked for that product.

• If all the products in the pick request are completely shorted, the pick request and the shipment are canceled.

Assign staging location

When the picking is done, the system checks if the pick request is completely picked or shorted.

• If the inventory for the pick request is completely shorted, the pick request and the shipment are canceled.
• If the order is completely picked with some shortages recorded, the Assign staging location window opens depending on the automatic staging rule.
  If the automatic staging rule is set to true:

  • If stagingLocationId is stamped, the pick-tasks:deposit-all API is called on that stagingLocationId.
  • If stagingLocationId is not stamped, the Scan staging location window is displayed.

  If the automatic staging rule is set to false, the Scan staging location window is displayed.

The store associate is prompted to scan the staging location where the products are to going to be deposited. On scan, the translateBarcode API is called with source as SIMLocation. When a valid location is scanned and the store associate clicks Done, the pick-tasks:deposit-all API on the pick-request is called. Along with the pick-tasks:deposit-all API, the ISFUpdateShipmentsOfBatchSynchronously service is invoked, which internally calls changeShipment to update the BackroomPickedQuantity and ShortageQty on the ShipmentLine. The service also calls changeShipmentStatus to move the shipment to Ready for packing or Ready for customer pickup status depending on the ShipmentDelivery method.

After staging is done, the store associate is navigated to the Shipment summary page.