Skip to end of banner
Go to start of banner

Multi Pack Boxes Support for a B2C Shipment

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Champ configuration is_multi_pack_box_allowed(for b2c) +1 more cponfig at channel level /wiki/spaces/AD/pages/471434257

same property will flow to order.

Configuration to allow Multiple Packboxes in the Packing

Increff WMS now provides flexible Packing Options for B2C shipments.

Users can pack orders in multiple boxes or a single packet, depending on the order requirements. Users can enable/ disable the toggle Allow Multiple Packboxes configuration in the Piece Packing screen’s Configuration. The toggle is provided for users to generate multiple Pack boxes for an order, allowing for easy management of multi-pack box orders
This allows for better handling of orders with large or bulky items, as well as orders containing items from multiple categories.

Packing process when Allow Multiple Packboxes configuration is turned Off

When Allow Multiple Packboxes configuration is tuned off, users can scan the Item codes as usual.

  • add 2 sections: single shipment partial and other 1 for normal processing

Packing process when Allow Multiple Packboxes configuration is turned On

When Allow Multiple Packboxes configuration is tuned on, user will have to scan the item code and place the item code into a box while scanning the Box Id at the same time.

User can print a new box Id after scanning Item Code if required.

  • pack order in a Single Box in UI- If the flag is true from backend and Ui flag is turned on, then user

In below case pack order in single box won’t come if any 1 box is already closed

Below case would be in rare scenarios

Manifest

Get Shipment details for a scanned AWB

  • A GET call in OMS is exposed in which an AWB and Transporter are provided.

  • OMS fetches the Shipping Label (SL)with above detail.

  • OMS extracts Shipment Id(S1) from SL.

  • Fetches all Shipping Labels using S1 from SL tables, If any PackBox Type SL exists, fetches box Ids from pack box details relation

  • Prepares a data , with all Shipping Label (PACK_BOX, SHIPMENT) level and sends to WMS.

 

Add AWB to Manifest

  • Scan the AWB to add.

  • WMS to trigger a proxy API to OMS to fetch the shipment details for the AWB.

  • Based on the workflow, UI to validate the scanned AWB as mentioned here.

  • Once all the validations are successful, trigger “Add AWB to manifest” API for the parent AWB ((blue star) the scanned child AWBs are temporarily saved at the UI end, if the user refreshes it they will have to scan it once again).

    • Add validations in “Add AWB to manifest” API in OMS to support only parent AWBs.

 

  • In case multiple boxes are present in a shipment, display the count of scanned Box AWBs for the shipment AWB. This will be temporarily saved in the UI until all the box AWBs are scanned.

 

 

Remove AWB from Manifest

  • Scan the AWB to remove.

  • WMS to trigger a proxy API to OMS to fetch the shipment details for the AWB.

  • Based on the workflow, UI to validate the scanned AWB as mentioned here.

  • Once all the validations are successful, trigger trigger “Remove AWB from manifest” API for the parent AWB ((blue star) the scanned child AWBs are temporarily saved at the UI end, if the user refreshes it they will have to scan it once again).

    • Add validations in “Remove AWB from manifest” API in OMS to support only parent AWBs.

 

Close Manifest

  • During the close manifest request send list of Box ID for every parent AWB

  • Currently we will print the count of boxes in the document. In future, we can customize and print box IDs if required.

  • OMS to send all Box Details also to CIMS and Proxy during Close Manifest call

  • Proxy Commons to include the count of boxes for every AWB in the manifest document. Line items in Manifest Doc to be sorted in descending order of box count.

  • Document should also have total box count in the end.

Handover

Handover By AWB

  • Scan the AWB to handover.

  • WMS to trigger a proxy API to OMS to fetch the shipment details for the AWB.

  • Based on the workflow, UI to validate the scanned AWB as mentioned here.

  • Once all the validations are successful, trigger “Confirm Handover” option will be enabled for the parent AWB.((blue star) the scanned child AWBs are temporarily saved at the UI end, if the user refreshes it they will have to scan it once again).

    • Send the list of Box ID for AWB in “Handover Shipments” API from OMS to CIMS.

    • RMS to use this list of box ID and include the count of boxes for every AWB during the handover document creation.

 

Handover By Manifest

Since we have done all the checks during adding AWB to manifest, no further checks are required here. No changes in this flow.

Generate Handover Document

  • OMS to include the count of boxes for every AWB in the handover document. Line items in Handover Doc to be sorted in descending order of box count.

  • Document should also have total box count in the end.

  • Sample handover and manifest doc to be added
  •  

The Multi Pack Boxes Support for B2C Shipment feature from an end-user perspective includes the following key points in more detail:

  1. Users can create new boxes by pressing the "Create New Box" button and scan items to these pack boxes for tracking.

  2. Efficient Tracking and Management: The system handles both pack box and shipment AWBs, ensuring proper tracking and management of multi-pack box orders. This includes support for child AWBs used by some couriers to track multi-piece shipments, as well as the main AWB for the entire shipment.

  3. Error Handling: The system will display errors in the user interface, guiding users to remove items from the Pack Box if needed. This helps prevent issues such as extra boxes being added after shipment closure or unclosed boxes with items.

  4. Seamless Integration: The feature integrates with RMS and OMS systems, ensuring smooth handling of multi-pack box orders and AWB management. This includes sending a flag "is_pack_box_label_reqd" from CIMS to proxy, which needs to be sent to RMS, and populating this field during order creation in WMS.

  5. Invoicing and Shipping Labels: For multi-pack box orders, there will be one invoice for the entire shipment. Shipping labels will have multiple pages for each box, with markings like "1/2" and "2/2" to indicate the box number within the shipment.

  6. Manifest and Handover Management: The multi-piece shipments need to be treated as a unit, so if some packets are not scanned and added to the manifest, manifest close should not be allowed. This ensures that all child boxes are accounted for and scanned during the handover process.

Please note that this is a more detailed explanation of the feature release note from an end-user perspective, and more details can be found in the provided documents.

Today system will be relying on operator to decide whether multi-box or not.

There will be following types of parent & child AWB combinations:

  • Child AWB to be a unique number just like parent AWB.

    • Derived: Child AWB will be derived from the parent AWB. If parent AWB is 1234 then child AWBs will be 1234-1 and 1234-2 for two piece shipment.

    • Coming from Logistics aggregator : Child AWB on a box level will be given by Logistics agrator.

  • Child AWB is same as parent AWB.

Provision to capture the number of pack boxes at the time of packing.

As a warehouse operator I should be able to enter the number of pack boxes and scan items to these pack boxes for tracking.

The same data should flow to integration layer.

Provision to consume child and parent AWBs for the shipment from the aggregator or marketplace.

Aggregator will generate a master AWB for the complete shipment and have child AWBs to identify the packets.

Incase of shipping label from RMS, We will use box labels as box level shipping labels if aggregators provide this else RMS will generate this.

Shipping labels & Package SKU to be consumed for each child packet.

Each child box will have the same shipment attributes as we now have for a single B2C shipment.

Manifest/Handover addition and removal for multi-piece shipments to track that all child boxes are accounted for and scanned.

The multi-piece shipments need to be treated as a unit, so if some packets are not scanned and added to the manifest, manifest close should not be allowed.

Manifest and handover docs to have multi-piece shipment information.

For seamless operations one would need this data on the documents as well.

We will need to have Increff pack box Id pasted on box

No changes will be there for single box packing flow.

Will pack box stickers be printed for B2C shipments as well?

Will one need to scan Increff pack box Ids?

  • yes stickers will be printed.

  • we can get them to scan items id and then box id.

  • no need for a separate scan to validate box id

All boxes of a shipment can be manifested at once only.

like if 3 boxes are there then all the should be together.

  • No labels