Implementing batch pick

Note: Batch pick features for SIM enabled stores, are being revised to offer better performance and usability. Ongoing revisions to these core features might impact future compatibility. Wait for the updated version before you begin integrating these features.

A store associate can pick a batch of products available in the backroom and place them in a staging location to fulfill ship from store or pickup in store shipments.

The batch pick task is implemented with the help of APIs, services, and other components.

Assumptions

  • The store associate is assumed to have permissions to pick at least one of buy online pick up in store order or ship from store order.
  • The prerequisite configuration steps for a batch pick must be completed. For more information about the configurations for the backroom pick task, see Configuring batch picking.

Solution

Pick portlet
  • The Pick Orders portlet has a Pick batches button. This button is visible to a store user with batch pick resource permission ISF000043.
  • Batch list screen is displayed on clicking the Pick batches button.
Batch list screen
The Batch list screen displays the list of batches that are segregated in different tabs according to the order type, that is, pick-up and ship order type.
  • Batch creation is a back-end process that can be scheduled and run on regular intervals, for example, once a day. Batch configurations drive how batches are created.
    Note: You can have batch configurations at store level.
  • No batches are created or listed if batch pick criteria are not configured or scheduled.
  • The batches are displayed in different tabs based on the order types, that is, ship from store or buy online and pick up from orders. If a batch contains mixed order types, then the batches are displayed under one tab. The list displays order type for mixed batches.
  • A store associate can see the list of existing batches and completed batches of the last 24 hours and new batches based on configuration.
    Note: The new batches must be draft batches.
  • Batches are listed such that the batch with the highest SLA orders always appear at the top.
  • By default the Batch list screen lists the Ready for picking, Picking in progress and New batches.
  • A store associate can filter batches, in the UI, based on Assigned to user, Zones, Categories, and Status.
  • Batch details like Batch ID, Status, Number of orders, Products, Zone, Category, and SLA are shown in the UI.
  • Custom batch criteria are also displayed in UI along with Zone and Category.
  • A store associate starts picking the batch by clicking the Pick button. The DRAFT batch is confirmed at this stage and moves to NOT_STARTED status and also gets assigned to the logged in store associate.
    Note:
    • If the batch is already confirmed by a different store associate, a confirmation window is displayed prompting for confirmation to continue picking the batch.
    • The AssignedToUserId attribute on Pick Request are not updated.
  • Batch ID is a link that clicked upon displays the Batch summary screen.
    Table 1. API inputs
    API input Description
    /stores/{storeId}/v1/batch:summary?group_by=deliveryMethod&status=DRAFT,NOT_STARTED,IN_PROGRESS,PICKED,DEPOSIT_IN_PROGRESS/COMPLETED Summary API to display the count of batches based on delivery method or status, a GET call.
    /:tenantId/v1/stores/:storeId/batch-picks A non paginated GET API to get the batch list.
    /{tenantId}/v1/stores/zones A GET API to get the zones of a store.
    /{tenantId}/v1/stores/product-categories A GET API to get the product categories.
    /{tenantId}/v1/stores/{storeId}/batch-picks/{batchPickId}/confirm A POST API to confirm draft batches.
    /{tenantId}/v1/stores/{storeId}/batch-picks/{batchPickId}

    Request body:

     [
  {
    "op": "add",
    "path": "/assignedToUserId",
    "value": "amgr"
  }
]
    		 A PATCH API to stamp user on a batch.
Batch summary screen
The Batch summary screen displays the overview of the batches, batch status, assigned to user and expected ship date. You can also see the products and orders that belong to a batch.
  • The Batch Summary screen displays the batch header information along with products and orders details.
  • The Batch Summary screen has the related tasks to Start or Continue batch picking along with the Print batch and Reset batch tasks.
Batch pick execution for Sort after pick
  • Batch pick execution flow has three screens:
    1. Pick screen
    2. Pick completion or Intermediate screen
    3. Deposit screen
  • When the store associate clicks the Pick or Continue or View summary button on the List screen, the user is taken to the appropriate screen in the flow based on batch status. The assignedToUser validation ensures that the current user does not start any batch that is already in progress by another user. A GET on batch-picks/<batchId> is called to get the updated assignedToUser and is matched with the current user. If the assignedToUser is null, the batch-picks/<batchId> API is called to update the assignedToUser and the pick execution screen opens.
    • If the assignedToUser is the same as the current user, the pick execution screen opens.
    • If the assignedToUser is not the same as the current user, a window opens to confirm if the current user wants to continue or not.

  • Pick screen

    • The Pick screen lists the products that needs to be picked in a batch grouped by the source location from where the products need to be picked. The list is generated with the help of the location sequence to optimize the traversal path for picking.
    • The GET on Batch stores/<<StoreID>>/batch-picks/<<BatchID>>?fields=pickTasks is called to display the batch pick tasks in the UI.
    • The batch pick tasks are combined based on the Item and Location combination for a multi location store. For a single location and no location store, the pick tasks are combined based on the Item.
    • The ItemID and UOM is a unique combination to identify the item. Even inventory attributes like InventoryStatus and ProductClass are considered while aggregating the pick tasks.
    • The Included in Orders pop-up window displays the product that belong to multiple orders in a batch and also the quantity in each order.
    • In case of a serial tracked inventory, the View serials pop-up displays the list of serials picked.
    • The Pick screen lists the products with primary information that need to be picked in a batch that is grouped by the Source location from where the products need to be picked from.
    • The GET API for BatchID is called with Fields as PickTasks to display the data in UI.
    • In the API output, batchPickTasks is the aggregation of pick tasks for a unique Item and Location combination. The pick tasks are combined based on the Item and Location combination for a multi location store. However, for single location and no location store, the pick tasks are combined based on Item.
    • ItemID and UOM is a unique combination to identify the item. Even inventory attributes like InventoryStatus and ProductClass are considered while aggregating the pick tasks.
    • In the Mashup layer, this API output is modified to group the pick tasks by sourceLocationId and also to stamp the item details on the pick tasks.
    • The Included in Orders pop-up window shows the split of orders that a product belongs to and also the quantity in each order. These attributes are computed in mashup layer.
    • The View serials pop-up displays the list of serials picked.
    • A get call is made to get the API details.

  • Scan flow

    The products in a batch are recorded as picked when a store associate first scans the pick location and then scans the product.
    • The input scan field can be used to scan both the location and product. If IS_LOC_SCAN_MANDATORY=Y then scanning the location is mandatory before a product scan.
    • On scanning a bar code, the translateBarCode API is called with the BarCodeType=StoreItemOrLocation.
      Note: The BarCodeType for a single location store and a location agnostic store will be Item.
    • When a location is scanned, the system sets it as a scanned or current location.
    • When an item is scanned, and if the translateBarCode API returns a valid translation, then the pick API is called to record picking of the item. The pick API is called with unique Item and location details from the previous scan.
    • If a location scan is mandatory, the minus (-) and plus (+) icons and quantity update units can be clicked only when a location is scanned. The operations are performed only if the scanned location matches the pick task source LocationId
    • A store associate can undo pick by clicking minus (-) in the product panel.
    • On clicking +, the PICK API is called and on clicking -, the UNDO-PICK API is called.
    Scan for a non-serialized item
    • On clicking the - button, the picked quantity is reduced by a unit. The UNDO-PICK API is called and the pick task is updated.
    • On clicking the + button, the picked quantity is increased by a unit. The PICK API is called and the pick task is updated.
    • When the quantity is edited, the PICK or UNDO-PICK APIs are called depending on whether the quantity is added or reduced.
    Scan for a serialized item
    • On clicking the - button a window to remove the item opens. The store associate scans the serial number and it will be marked as not picked. The translateBarCode API is called with BarCodeType=SIMSerial. If successful, the UNDO-PICK API is called by passing the serial number.
    • The quantity cannot be edited by entering the number of units. A serial numbers should be scanned or typed in the scan field to be marked as picked or removed.

  • Pick execution

    The following store rules and configuration are read from the application context to determine whether scanning location is mandatory and also if the store is single or multi or no location store:

    • Scan flow for multi location store

      • The input scan field can be used to scan both the location and product. If IS_LOC_SCAN_MANDATORY=Y then scanning the location is mandatory before a product scan.
      • The translateBarCode API is called with the BarCodeType=StoreItemOrLocation.
      • If scanned barcode is valid and is a location, then the location panel is highlighted and also currentLocation in Pick context is set in the screen.
      • When the item is scanned, and if the translateBarCode API returns a valid or single translation, then the PICK API is called to record picking of the item. This item is passing unique attributes of Item and also location details from the previous scan.
      • This PICK API identifies the pickTask that needs to be updated based on SLA or sort criteria that are configured as part of batch configuration.
      • After each PICK call, the Pick Tasks list is updated with the Pick task.
      • After each PICK call, the Batch status is checked for PICKED status. If the status is PICKED, the user is taken to Pick completion screen.
      • The store associate can undo pick by clicking minus (-) in the product panel. Use of + and - buttons on product panel call the PICK and UNDO-PICK API directly from UI.
        Note: Set BarCodeType=Item if location scanning is not mandatory or locations are not maintained in store.
      • translateBarCode input 
        <BarCode BarCodeData="" BarCodeType="StoreItemOrLocation" DisplayLocalizedFieldInLocale="xml:CurrentUser:/User/@Localecode" pickRequestId=""   isLocationScanMandatory="">
                    <ContextualInfo
                        EnterpriseCode="xml:CurrentStore:/Store/@EnterpriseCode" OrganizationCode="xml:CurrentStore:/Store/@EnterpriseCode" Node="xml:CurrentStore:/Store/@ShipNode"/>                   
                    <LocationContextualInfo SIMLocationId=""/>
</BarCode>

    • Record Shortage and Alternate Location

      • A store associate can choose to pick from an alternate location if the inventory that is needed is not available at suggested source location.
      • If the product is not available at any alternate location, then the store associate can record shortage.
      • When a store associate chooses an alternate location from the Alternate Location pop-up, the Exception API is called to create an Alternate task with the newly chosen location.
      • When the Alternate location is chosen, the Pick screen is refreshed completely to show the new task generated.
      • The same exception API is called to record shortage.
      • After Pick, Undo Pick or Short, the Get Batch pick request is called and the batch status is checked. If the status is picked, the Pick completion screen is displayed. If status is canceled, the Batch summary screen is displayed.
      • On clicking the Continue button, the Pick completion or Intermediate page is displayed.
      • If inventory is damaged or there is a shortage of inventory, a store associate must check if the inventory is available in any other location in the store before marking it short. Click Alternate location to view other locations.
      • The GET alternate-source-locations API is called to get the alternate locations for a 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, exception API is called on a PICK task 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. The quantity in the original pick task is reduced. If the alternate location is not available, then shortage quantity on the pick task is updated.
      • If all the products in a batch are recorded short, the batch and the shipment both are canceled.
  • Partial pick of batch
    • If a store associate cannot pick all the products in a batch, he can choose to split the batch. The Split API is called to move the unpicked products to a new batch.
    • A store associate can continue to deposit the picked products once the split is successful.

  • Pick Completion or Intermediate Page

    When All the products in a batch are picked, the user is taken to the Pick completion screen.
    • When picking is complete in the Pick screen, a success dialog is shown to the user, acknowledging which the user is taken to the Pick completion screen.
    • Alternatively, the store associate clicks the Continue button on the Pick screen to navigate to the Pick completion page.
    • If the Status is NOT_STARTED, then the Warning dialog is displayed.
    • If the Status is PICKED, the Pick completion screen is displayed.
    • If the Status is IN_PROGRESS, then the warning Do you want to pick the unpicked items in another batch? is displayed. If Yes, the Split API is called. After successful completion of the split, the Pick completion screen is displayed, else an error is thrown.
    • The Split API needs to read the batch configuration to see whether the order can be split across batches. If the configuration is false or an order is partially picked, then the API throws an error. The error contains the pickRequests and pickTasks that are partially picked.
    • If AUTO_STAGE_PRODUCTS rule is enabled, the preferences API is called to set AutoStaging location for each DeliveryMethod.
    • The Pick Completion screen reads the AUTO_STAGE_PRODUCTS rule and a new store configuration that is added to specify the staging location is used for AUTO_STAGING. This configuration is for a Delivery method and Document Type combination.
    • The Assign All is an option that is resource permission controlled.
    • The staging location on Pick Request is not considered during batch picking.
    • Clicking Finish Batch deposits all the products in the configured or default location, the batch moves to Completed status and the user is taken to the Batch summary screen.
    • Clicking Continue takes the user to the Deposit screen.
    • Clicking Assign All opens the Assign staging location pop-up. After the staging location is chosen, the Deposit-all API is called, batch status is updated by using the update API and the user is taken to the Batch summary screen.

    • Assign all

      • All the picked products are deposited at one location using the Assign All option. This button is resource permission controlled.
      • Clicking Assign All opens a location selection pop-up.
      • The translateBarCode API is called with BarCodeType="HoldLocation" and on successful translation, depositAll API is called. The Batch status moves to DEPOSIT_IN_PROGRESS.
      • After deposit is successful, Update API is called to move the Batch status to COMPLETED.
    • Sort while staging
      • A store associate can navigate to the Deposit screen to sort the picked products into different orders and stage them.
    • Auto staging
      • The Pick Completion screen reads the AUTO_STAGE_PRODUCTS rule by calling GET on rules and pick-preferences APIs to read a auto staging location.
      • A store associate can auto stage all the picked products by clicking the Finish Batch button. The deposit-all API is called to record depositing of all the picked products and the batch status is updated to Completed status by calling the update-status API and the user is taken to the Batch summary screen.
    • Staging to one location
      • A store associate can choose to deposit all the products in one location by scanning the location in Staging location window.
      • The store associate is prompted to scan the staging location where the products are to be deposited. When the scan is performed, the translateBarcode API is called with source as SIMLocation. If the scanned location is a valid location and the store associate clicks Done, the deposit-all API on the batch is called with the scanned location.
      • The batch status is updated to Completed by calling update-status API and the user is taken to the Batch summary screen.

  • Deposit screen

    The Deposit screen allows a store associate to sort the picked products into different orders and simultaneously stage them.
    Note: The Deposit screen allows sorting and depositing even for single and no location stores. These stores can create location of type TOTE for sorting.
    • The Deposit screen lists the orders that need to be deposited. Each order has the list of products that are picked.
    • The GET on BatchID /<<StoreID>>/batch-picks/<<BatchID>>?fields=PickRequests is called to display the orders in a batch
    • Clicking the Continue button takes the user to Deposit screen.
    • The Deposit Screen allows sorting and depositing even for single and no location stores. These stores can create location of type TOTE for sorting purpose .
    • A new rule BP_ALWAYS_SCAN_STAGING_LOCATION is read to determine whether scanning the location is mandatory for depositing each product in the order. The default value of the rule is N.
    • The Deposit screen lists the orders of the batch to help the store associate to sort and deposit the picked products.
    • Each order lists its products that are grouped by target location.
    • The GET API for BatchID is called with fields="PickRequests" and the products in order are grouped by target location in the mashup layer to display in the UI.
    • The store associate stages the order if all the products are sorted with the help of the product panel and by using the Stage Order option.
    • Alternatively the store associate deposits the products by scanning the products one by one.

    • Depositing products individually

      • Product needs to be scanned before location is scanned or selected.
      • If BP_ALWAYS_SCAN_STAGING_LOCATION=Y, then the same scan field can be used for scanning the product or location alternatively.
      • If BP_ALWAYS_SCAN_STAGING_LOCATION=N, then the Select staging location pop-up is shown only when the system does not suggest any target location.
      • The UI maintains the map of the order and recently used staging location.
      • When product is scanned, the translateBarcode API is called, if the translation is successful, the matching-pick-tasks API is called to find the matching pick task. If the matching pick task is found and BP_ALWAYS_SCAN_STAGING_LOCATION=Y, the product panel is highlighted. On scanning the location, the translateBarcode API is called and on successful translation, the deposit API is called with the matching pick task and scanned staging location. This deposit API internally handles the logic of splitting the pick task into two if the targetLocationId is different from the one that is already stamped on it. The batch status is also updated to DEPOSIT_IN_PROGRESS.
      • If BP_ALWAYS_SCAN_STAGING_LOCATION=N, when the matching pick task is found, the UI map of Order-StagingLocation is checked to derive the recently used staging location on the order. If the map has a location for the order that the matching pick belongs to, then the deposit API is called with that targetLocationId. If the map does not have a staging location for the order, then the UI displays Select staging location. Upon successful selection of staging location, deposit API is called to record staging and also UI Map is updated.
      • While depositing, if a particular staging location is full, the store associate can click Alternate location link and scan the new staging location for the order.
      • After the store associate deposits the products, the pick task status is checked. If COMPLETED, then Get Batch details API is called to check whether all the pickTasks are completed in the batch to evaluate whether the complete batch is deposited.
      • The UI refreshes the order panel when the targetlocationId changes on the pickTask or a new targetlocationId. Other tasks are listed under unassigned.
      • The store associate can also undo deposit by clicking - button in the product panel.

    • Deposit order

      • A store associate can choose to deposit all the products in one staging location using Stage Order option. Stage Order always opens Alternate location pop-up to get the target location.
      • If the PickRequest has a different targetLocationId other than the one passed in the request body, an exception is created for the remaining tasks. The new alternate tasks are updated with the new targetlocationId.
      • When staging is complete the UI evaluation of the batch is completed by going through all the pick tasks that to the batch. If the batch is complete, a success dialog is displayed in the UI. Upon user confirmation, the Batch status is updated to COMPLETED by calling the update-status API.
      • Upon completion of deposit, the update-status API validates if all the pick tasks that belong to the batch are staged and then moves the PickRequest status to COMPLETED. The PickRequest status is not updated if all the PickTasks in a PickRequest do not belong to the same batch and batch status is not updated to COMPLETED status.

    • Shipment updates on IBM® Sterling Order Management System

      • All the shipments that belong to the batch need to be updated with BackroomPickedQuantity, ShortedQty, and StagedQunatity.
      • The shipment status also needs to change if all the shipment lines are picked.

    • In progress Single Order Pick changes

      • The includedInBatch attribute on the pickRequest checks whether the pick request is included in a batch. If includedInBatch is true, a confirmation dialog box is displayed where the user can choose to do a single order pick for this pickRequest.
      • If the PickRequest status is NOT_STARTED, then single order pick is allowed.
      • If the PickRequest status is IN_PROGRESS or PICKED, then a notification with a message Contact the user associated with the batch is displayed.
      • This API removes a pickrequest from a batch when the pickrequest status is NOT_STARTED.
      • The Pick Request Summary displays the batch information.

    Stage order

    • A store associate can sort and stage all the products in an order in one step using the Stage Order link if the products belonging to different order can be visually identified.
    • The store associate is prompted to scan the staging location where the products are 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 depositAll API is called.
    • The store associate can continue to deposit all the orders one by one.

    Staging products individually

    • A store associate can sort and deposit all the products by scanning the products one by one using scan input field.
    • A product needs to be scanned before the location is scanned or selected.
      • If BP_ALWAYS_SCAN_STAGING_LOCATION=Y, then the same scan field can be used for scanning the product or location alternatively.
      • If BP_ALWAYS_SCAN_STAGING_LOCATION=N, then the Select staging location pop up is shown only when the system does not suggest any target location.
      • When a product is scanned, the translateBarcode API is called, if the translation is successful, the pick-task:for-deposit API is called to find the matching pick task. If the matching pick task is found and BP_ALWAYS_SCAN_STAGING_LOCATION=Y, the product panel is highlighted. On scanning the location, the translateBarcode API is called and on successful translation, the deposit API is called with the matching pick task and scanned staging location.
      • If BP_ALWAYS_SCAN_STAGING_LOCATION=N, when the matching pick task is found, the system tries to derive the recently used staging location for the order and the deposit API is called with the targetLocationId. If the system cannot find the recently used staging location, then the UI displays Select staging location window. Upon successful selection of staging location, deposit API is called to record staging.

    Staging orders in multiple locations

    • While depositing, if a particular staging location is full, the store associate can click the Alternate location link and scan the new staging location for the order and continue depositing the products. The new alternate location will be used for further deposits.
    • The store associate can also undo deposit by clicking (-) button in the product panel.

    Staging completion

    • The system evaluates if staging of all products is complete after each deposit. If the batch is complete, upon user confirmation, the batch status is updated to COMPLETED by calling the update-status API.
    • The user is then taken to Batch summary screen.

    Shipment updates on Sterling Order Management System

    When batch status is completed, the corresponding shipments in the batch are updated with picked and shortage quantity information by calling the ISFUpdateShipmentsOfBatchSynchronously service. This service will also update the shipment status to Ready for packing or Ready for Customer if the shipment is picked completely.

    Single Order Pick changes

    • A store associate can choose to pick a order individually even when it is already included in a batch and picking is in progress.
    • The includedInBatch attribute on the pickRequest checks whether the pick request is included in a batch. If includedInBatch is true, a confirmation dialog box is displayed to the user where the user can choose to perform a single order pick for an order.
    • This batch-picks:remove API is called to remove a pickrequest from a batch.
    • The Pick Request Summary displays the batch information.

    Sort while pick changes

    • The user is taken to the pick execution flow, based on the batchSortType attribute of the batch.

    Batch pick execution for sort while pick

    • Batch Pick Execution flow has three screens.
      1. Pick screen
      2. Pick completion or Intermediate screen
      3. Deposit screen
    • When a store associate clicks the Pick or Continue or View summary buttons on the list screen, the appropriate screen is displayed in the flow based on Batch status.
      • If the Status is NOT_STARTED or IN_PROGRESS then the Pick screen is displayed.
      • If the Status is PICKED or DEPOSIT_IN_PROGRESS then the Pick Completion screen is displayed.
      • If the Status is DEPOSIT_IN_PROGRESS then theDeposit screen is displayed.
      • If the Status is COMPLETED then the Batch summary screen is displayed.

    Pick screen

    • The Pick screen lists the products and its primary information that need to be picked in a batch grouped by its source location.
    • The GET API for BatchID is called with fields="PickTasks" to display the data in UI.
    • In the API output, batchPickTasks is the aggregation of pick tasks for a unique Item and Location combination. The pick tasks are to be combined based on location and item combination for a multi location store. However, for single location and no location store, the pick tasks are combined based on Item.
    • The ItemID and UOM is a unique combination to identify the item. Even inventory attributes like InventoryStatus and ProductClass are considered while aggregating the pick tasks.
    • In Mashup Layer, this API output is modified to group the pick tasks by sourceLocationId and also to stamp the item details on the pick tasks.
    • Included in Orders pop up displays the split of orders that a product belongs to and also the quantity in each order. These attributes are computed in the Mashup layer. It also shows tote information that the products are placed in.
    • View serials pop up displays the list of serials picked.
    • View orders in batch displays the orders view of the batch along with the tote information.

    Pick execution

    • Store Rules and configuration are read from application context to determine whether scanning location is mandatory and also whether store is single location or multi location or a no location store.
    • * IS_SINGLE_LOC_STORE and IS_LOC_SCAN_MANDATORY rules from the Store Inventory Management and inventoryTracked flag from Sterling Store Engagement configuration.
    • If IS_LOC_SCAN_MANDATORY=N then, the UI assumes that the location is scanned during batchpick process unlike other flows where the store associate can still scan location when rule is turned off.

    Multi location store scan flow

    • The input scan field can be used to scan both location and product. If IS_LOC_SCAN_MANDATORY=Y, then the location scanning is mandatory before a product is scanned.
    • The translateBarCode API is called with BarCodeType="StoreItemOrLocation".
    • If the scanned barcode is valid and is a location, then the location panel is highlighted and also the currentLocation in pick context is set in the screen.
    • If the translateBarCode API returns a valid or single translation when an item is scanned, the matching pick task for the scanned item is determined by making "pick-task:for-pick?productId=<<productID>>" API call.
    • After the order is determined, it is validated with the UI map of Order to Totes. The Selected tote window is shown to capture the tote information.
    • You can pass the matching pick task identifier, the PICK API is called to record picking of the item and also the toteID as inTransitLocationId.
    • This PICK API updates the pickTask with picking and inTransitLocationId.
    • After each PICK call, the pick task list is updated with the pick task.
    • After each PICK call, the batch status is checked for the PICKED status. If the status is PICKED, the user is taken to PICK completion screen.
    • A store associate can undo pick by clicking minus (-) in the product panel that opens the remove products pop-up.
    Note: The record shortage and alternate location selection while picking will be same as sort after pick flow.

    Pick completion or intermediate page

    • When picking is complete in the Pick screen, a success dialog is shown to the user, acknowledging which the user is taken to the Pick completion screen.
    • Alternatively, the store associate clicks the Continue button in Pick screen to navigate to the Pick completion page.
    • If the Status is NOT_STARTED, then the Warning dialog is displayed.
    • If the Status is PICKED, then the Pick completion screen is displayed.
    • If the Status is IN_PROGRESS, then the warning Do you want to pick the unpicked items in another batch? is displayed. If Yes, the Split API is called and after the split is successful, the Pick completion screen is displayed, else an error is thrown.
    • The Split API needs to read the batch configuration to see whether the order can be split across batches. If the configuration is false and orders are partially picked, then the API throws an error. The error contains the pickRequests and pickTasks that are partially picked.
    • The Pick Completion screen reads the AUTO_STAGE_PRODUCTS rule and a new store configuration that is added to specify the staging location is used for AUTO_STAGING. This configuration is for a Delivery method and Document Type combination.
    • The Assign All option is resource permission controlled.
    • The staging location on Pick Request is not considered during batch picking.
    • Clicking Finish Batch deposits all the products in the configured or default location, the batch moves to Completed status and the user is taken to the Batch summary screen.
    • Clicking Continue takes the user to the Deposit screen.
    • Clicking Assign All opens the Assign staging location pop-up. After the staging location is chosen, the Deposit-all API is called, the batch status is updated by using the update API and the user is taken to the Batch summary screen.

    Deposit screen

    • On clicking the Continue button, the Deposit screen is displayed.
    • The Deposit screen lists the orders of the batch to help the store associate to deposit the totes with picked products.
    • Each order lists the totes of a particular order that is grouped by target location.
    • The GET API for the BatchID is called with fields="PickRequests" and the products in order are grouped by the target location in the mashup layer to display in the UI.
    • A store associate can use the Stage Order option to stage all the totes of a particular order.
    • Alternatively a store associate can also deposit the totes by scanning the totes one by one.

    Depositing orders

    • A store associate can choose to deposit all the totes in one staging location using the Stage Order option. Stage order always opens the Select staging location pop-up to get the target location.
    • While depositing, if a particular staging location is full, a store associate clicks the Alternate location link and scans the new staging location for the order.

    Depositing totes

    • A store associate can start depositing the orders by scanning totes by using the scan field. The translateBarcode API is called with BarcodeType="HoldLocation".
    • The corresponding order for the scanned tote is identified by iterating through the pickRequests of the Batch.
    • The UI maintains the map of order and recently used staging location.
    • The Deposit API is called passing the PickRequest information along with the ToteID.
    • After the products are deposited, the pick task status is checked. If the status is COMPLETED, then the Get Batch details API is called to check whether all the pickTasks of a batch are deposited.
    • For a new target locationId, the UI refreshes the order panel when the target locationId changes on the tote. Other tasks are listed under unassigned.
    • A store associate can also do or undo deposit by clicking the placed link in the tote panel.
    • After each deposit, the UI evaluates if the entire batch is staged by going through all the pick tasks that belong to the batch. If the batch is completed, a success dialog is displayed in the UI. Upon user confirmation, the batch status is updated to COMPLETED by calling the update-status API.
    • This API validates if all the pick tasks that belong to the batch are staged. Then, the PickRequest status is updated to COMPLETED. The pick request status is not updated if all the PickTasks in a PickRequest do not belong to the same batch and batch status is updated to COMPLETED status.