HemiKnowledge BaseHemiCore
Table of Contents
Related Articles
Knowledge Base
Hemi System Administration Integrations Hemi PRD Library Hemi Content Stream General Information Custom additions Core Integrations & Marketplace Documentation Hemi Advanced Functionalities Data Management MP Tokens generation Hemi Technology Trainings Hemi Platform Integrations Release Notes
FAQs

Courier and Shipping Label management

Courier and Shipping Label management

The purpose of this page is to detail how we should hold Courier and any other related info in OMS so we can then interact with it to allow the user to work with Shipping labels. This section will also hold the detailed information of functionality options and management regarding the actual shipping label requesting, printing and automating

Version Created by Date Notes
1.0 Danail Deltchev 23.02.2025 First Publish

The premise - in OMS we need to have a functionality that allows our end users to request shipping labels on their orders and be able to print them. This is needed so our sellers can actually physically fulfil their orders,

The functionality should be available to work in singular order management, in bulk and fully automated. It should also allow for the user to manually specify requirements or automatically pickup preset information from rules sections and populate/use those for the further label request to be made.

To achieve this we will break down the whole flow in 4 major groups:

  1. Setup - how to setup your couriers so you can connect them and then request labels for them
    1. This setup will include also rules to apply a chosen courier/service automatically and the option to request labels automatically in the system without having to do anything
  2. Label Request - the actual interaction, validations and handle of how a label can be requested and what happens in the system while doing this
  3. Use the Label - how can the label actually be used by the end user (how can it be printed/downloaded/viewed etc) and again everything that happens in our system around the user activity while interacting with a generated label
  4. Ship - the action of actually sending the information to the Selling Channel. This is a necessary section as if we want to achieve a good work flow this should include an easy way to push label generated information to the marketplace

Below the document breakdown based on the major sections

Setup

  1. Courier creation and setup
    1. Input OMS Courier information
    2. Connect courier to SE (This needs a deeper API inspection)
    3. Set services (Download from SE and allow choosing)

  2. Courier rules setup - When to use which service. Below parameters which should be available in setup for decision process

    1. Channel
    2. MP Shipping Service
    3. Shipping Cost
    4. Order Total Cost
    5. Shipping Address Specifics
      1. Country of destination
      2. Post code includes
      3. State / Province includes
    6. Product info
      1. Weight
      2. Dimensions (This will need additional specifics. Can be first only based on general single product dimensions - if bigger than X in the order then use this. Then it can be moved to a more sophisticated combination algorithm)
    7. Overrules - these will be such rules that if applied they are to take precedence over any other rule - for example if we have a rule that applies because of a forced SKU list and another which applies because of Shipping total costs, etc. we are to use ONLY the Overrule and treat it as there is only one rule. IF there are multiple overrules for the same order we are to not apply any rule automatically the same way we won’t apply if we have multiple normal rules.

    Last but not least - only one type of Overrule can be applied within the same Rule (so either SKU list or Contains)

    1. SKU list - this is to work like a specific SKU’s list that will trump everything else. If a product is in this list we need to select this rule for it and it should be applied for the whole order when automatically requesting. As for every other such option if we have a clash (a SKU is in two separate lists) we should not apply a rule
    2. Contains - option to apply specific filter based on a few fields. It should always be if said field “contains” a specific value. If field is empty means no filter is to be applied
      1. SKU
      2. Title
  3. Automation setup - use a combination of rules to decide when to auto request a label without anyone needing to intervene
    1. Day / Time range (time range should be applicable based on a timezone which should be set on the OMS account in general as parameter for example)
    2. Courier / Shipping Service
    3. Order specifications
      1. Account
      2. OMS Tool Status
      3. Order Type

Label Request

Now that we have all the setup it is time to put it to work in our OMS section

To kick off we are starting from the singular order label request. This will cover everything as flow and statuses which then will be reused in bulk management and automated requesting too

The user should be able to chose a single order and request a label for it specifically. The label request functionality should open a modal with all relevant information for a label to be requested:

  1. Courier to be selected
  2. Shipping service to be selected - if a courier is not selected show all services. If a courier is selected show only the related services. IF a service is chosen without the courier being selected we should populate the correct courier
  3. Label count - allowing the user the fill in a specified number of labels for this specific request. This way if they need 2 labels due to 2 boxes being part of this they can request this from here manually. By default if not filled in with a value we always store and send 1
  4. Product information - in this section we need to showcase the products that are in the order to allow for multiple labels being created for different items within the order (same concept as Partial shipment)
    1. SKU
    2. Title
    3. Qty Ordered
    4. Qty not yet requested
    5. How much qty to put on the label for this product
    6. Full product click option

While selecting this request label option there are a few things to follow through

  1. Label status on the order - if we have a status that label is fully requested or created we should show a notification on top that as a warning that there is already a label requested for this order or that there is a label already in the system for this order. We should keep this info to the end as if user still requests a new label we want upon request the modal to switch to a second modal showing an “This label request contains products that already have a label requested for them - all previous labels involving selected products will be voided. Are you sure you want to proceed?” - this prompt should have 2 buttons - Request and Back - the Back one should return us back to the label request modal with the info that was filled in intact so the user can make changes if they want. There should also be an X at the top that completely stops the process. If a Request is made we should track the selected products and mark for voiding all labels in which they participate
  2. In the actual request modal we should allow always to request labels for all quantity even if there was already requested. This should be in a warning colour in the drop down but still available to select. In case this is made we should follow the same flow as above. This separated tracking method will allow us to void only labels that are for those partial products. This way if we have 3 labels on an order we might end up voiding only one of them and the other 2 to stay intact for the fulfilment process
  3. If nothing is selected on the products section we should always treat it as it was fully selected. This is true for all purposes as well in the above described validations. In case where there’s already been partial Label request (still not Shipped) if nothing is selected in the Products section we are to treat the new request as it is ONLY for products that don’t have a request
  4. A Label that was “Shipped” should result in not allowing any further requests for involved products. Shipment should be a process of migrating info from a Generated label to a Shipment that needs to be pushed to the Channel. We should add this as part of the Shipment flow as well and add it as a bulk option too - Generated Labels should be available to be transferred into a Shipment as they are essentially the package created by the Warehouse team and they just need to be “dispatched”

TODO - discuss the whole Package concept with Bobi - do we need to bring in the palleting option in there? Prolly not but better to check

  1. Label request should not be available at all if the order is not in a Ready for Shipping or Partially Shipped order status

‼ Please note - based on the previously described rules we SHOULD preset courier and service if there is any that is available. This should be made based on ALL AVAILABLE items in the order. This means while evaluating we should pick all items that we think will need to be part of the label request. IF we have an order with a partial label request made already the next evaluation for a label request should take into the automated application ONLY the items that are have not been “labeled” already. This is to work that way for both the single UI label request and for the bulk and automated label request ‼

OK, we have the validations in! Now we need to explore what happens when we actually succeed to make a label request!

  1. We should store all relevant information in the Label request section:
    1. Info about the label
      1. Courier
      2. Service used
      3. Label count
      4. Status - Requested so it can be picked by any follow up connection
      5. Other relevant information for the Integration (courier ID, service id, etc. whatever is needed for better communication)
    2. Info about the selected products
      1. Links to the ordered Products and their respective selected lines
  2. We should update the order with the relevant status so we know that it’s had a label requested (TBD - are we going to add statuses on every level (Order, Products, Lines) or is this something that we will update in UI to be accessible? What about API and Exports / Reports 🤔)
  3. IF the actual storing of the label fails we are to try and capture this and flag the Order status accordingly and store an Order Error message
  4. We should then invoke the relevant integration (SE and Amazon to kick off) and send the label request
    1. If the label request is a success
      1. We need to store in a separate section
        1. The label
        2. Tracking number
        3. Tracking URL
        4. Delivery dates
        5. Any other relevant information (integration unique ID, label type, etc. anything we deem useful in the integration)
      2. We need to update the Status of the label request as Generated
      3. We need to update the Order (and possibly other sections) with the relevant status that the label was generated
    2. If the label request is not a success we need to
      1. Store the correct error in Order Error
      2. Set the label status to error
      3. Set the order status to the correct status

The Label section itself should have the following statuses:

  • Requested - waiting to be sent to the connection
  • Generated - the label was successfully downloaded from the integration
  • Printed - the label was successfully triggered for printing or download from OMS
  • Error - the label was unsuccessful in generating or cancelling
  • Shipped - the package was transferred into shipment. This is an end status. Once reached it can’t be cancelled or updated
  • Cancelled - if the label generation was stopped before communication to the integration OR a void was requested post the generation of the label. This is an end status. Once reached it can’t be pushed to any other status

There should also be 2 communication flags, one for the generation one for the cancellation flows so whenever a request for any of these is made we can track them by the standard OMS statuses

The pickup for Label generation should be based on a Label Status = Requested and the relevant communication flag = pending

The pickup for Label cancellation should be based on a Label Status = Requested and the relevant communication flag = pending. Said flag is to be raised at the moment either by re-requesting labels for already generated labeled products or manually going into the Label record. This can be handled either in the Label print modal or it will be only automated based on other requests to kick off

Cancelled labels are not to affect in any way tracking for new Label requests. In other words anything that is Cancelled is to be treated as it doesn’t exist

Shipped labels are to 100% block the products that were processed through them. In other words if anything is shipped it should not be available for any further label request

Now that we know how a label request should act and calculate availability and statuses and actions it should be updating it is time to explore how to bulk request and auto request

Bulk Request

Through our standard bulk actions bar we should allow for a user to request labels for multiple orders at same time. Please note that the bulk request should always try to pick all orders fully and then apply the validations, checks, and the request label logic (for example if an order fits all validations but there is a partial label request we should request a new label fully for the other products)

  1. First we should showcase a notification warning the user they are about to request labels for XX orders, where XX is the selected number no matter of any further validations. As they select Request we are to proceed with validations
  2. We go and evaluate all selected orders if they fit the profile - are they RFS or Partial Shipped orders? No = skip them, Yes = continue with evaluation for those that fit and so on. The label request should act on the following assumptions
    1. Use rules to chose what to select for the courier and service
    2. Use all default values everywhere where needed
    3. Select all available products for this label request
  3. We should end up with 3 toasts notification options
    1. Green - XX orders successfully requested labels
    2. Yellow - XX orders can be requested but don’t fit any or one singular rule
    3. Red - XX orders Failed label request - these should be specifically those that we tried to create a label for but they failed
    4. We are not to show a toast for skipped orders - TBD should be? 😀
  4. The bulk request should store labels and update statuses the same way as the singular label request module does this

Auto Request

The Auto Request should use the exact same functionalities but instead of being triggered by a UI it should be triggered by the setup. In the setup we should’ve already set what needs to happen so it is just about the functionality running and picking the correct Orders (if any are available) and then run them through the same validation process. Difference is we don’t expect any output from the Automatic label request (for now) besides updating the statuses correctly which will be used for further filtering and finding if anything needs attention

Use the Label

One way or another we’ve acquired a label in OMS and now it is ready to be used! All options for this to be done will be bundled under this section

Any of the actions below if successfully executed is to treat the label as “used”. Used for the moment will mean 1 of 2 things

  1. Add to manifest
  2. Mark for shipment

This is to be controlled on Courier level as part of the setup which option is to be used. Below what the two options do:

  1. Add to manifest - Add the order to a manifest that later will be used to either send to the courier or just for internal purposes to streamline process of dispatch. The adding to manifest itself should work the following way:
    1. Check if there is a Pending manifest for this courier for this date. If not create one
    2. Add the order ID to the list of orders for this specific manifest
  2. Mark for shipment - This is with the idea that if we are already printing the label we are preparing to ship this order so we might not want any further confirmation. This will reduce work in the tool as the “packing” step can essentially automatically update the order for Shipping as well. The mark for Shipping should work by selecting the products within the label and trying to create an Order Shipment on pending statuses the same way the UI would create a new such request. We should have a validation to check if the products are available to be shipped. Even if only one of the products from this Label (Package) can be shipped now we should still create an Order Shipment at this point. If we successfully create a Shipment OR all products are already shipped we are to mark the Label as Shipped too. If we don’t manage to store a Shipment we are to store an error and set the correct status on the Label

Use Courier, Tracking, etc from the Label to update the Order Shipment accordingly

Any label that was successfully “used” should also have it’s status updated as “Printed”

At the end of the day we want to allow for a user to be able to trigger a printing for the label on the order. From our standard printing section people can print their labels. We should make a slight adjustment to the current modal to make it better segmented and have the option to keep multiple documents in there.

TBD if against each Label we should show a summary of the products in it? Also should we change a status on click for printing to be visible what’s already been clicked?

Clicking on any of the “labels” is to trigger a native browser printing functionality, always opened in new screen if possible.

Successfully opening a label for printing is to trigger an update for this label as “used”

If we are unsuccessful we are to display an error in a toast message for the user to be able to use for communication with support (or figure out themselves)

Print in bulk? - There should be a way to combine PDFs together and send to browser for printing together. We should explore this as well and if possible we should implement as bulk option. There should be of course rules - bundle not more than 50 orders together for example, If there are multiple labels for a single order we will print all of them? (TBD - should we track printed labels and then print only those that are not printed? 🤔) Also - any such combined PDF if sitting in temp with us should be disposed of after operation is complete!

Download

‼DO WE FUCKING NEED THIS IF WE CAN PUSH A COMBINED PDF TO BROWSER? AS ESSENTIALLY IT WILL BE A DOWNLOADABLE VERSION TOO FROM THERE ‼

The other option we should have for each label is to download it. I don’t have 100% the interaction in mind - suggestion - the modal can have a more table like view with the sections of Labels and Invoices. Then we can have 2 actions against each Label - print or download. This essentially is not adding anything more to the user interaction as clicks just gives them more options to work with 🤔 We can even add the void in here as mentioned above there is no option for Void in the UI atm 🤔

One way or another clicking on this should lead to downloading the label as a file

A successful download is completed it should update this label as “used”

If we are unsuccessful we are to display an error in a toast message for the user to be able to use for communication with support (or figure out themselves)

Download in bulk? - Same as for the printing - we should have an option to either combine PDFs into one for a download or better for the download - push all selected files separately (TBD maybe zipped? - Archives are a problem for enterprises sometimes as it might be blocked by security checks 🤔)

Ship

The only question and interaction left is what to do when there is no trigger for the labels or if someone wants to manually update. We have two options to discuss (@Bogomil Pavlov)

  1. Leave as is - meaning they just chose what they want to ship from the standard modal and that’s it
  2. Add a new section to the Shipping modal called Labels for example and in there have the Generated/Printed Labels to chose from with their respective SKUs and quantities so people can just select and ship 1 or more labels which will trigger the same flow as described above - creating a Shipment for each selected label

Note - this might be an overkill and we can simply add a “ship” action to the Labels section described above 🤔

Is this article helpful?
0 0 0