Labels Printing
User journey plus requirements to allow for label printing to be happening for Very
| Version | Created/Updated by | Notes |
|---|---|---|
| 1.0 | Danail Deltchev | Initial Version |
Label Request
The Label request is a fairly straightforward process for Very. We submit the OrderID and request a type based on which we get back pdf, png or zpl (depending on our preferences). We need to automatically request a label for each order that lands successfully in Hemisphere and that is not cancelled (in a case where we’ve had a cancellation prior to the label request itself)
Field Names and Specifics
| Field Name | Format | Node | Comments | WAP Mapping | WAP Notes |
|---|---|---|---|---|---|
| Label Type | X(7) | /PRINT_REQUEST/LABEL_TYPE | “WHOLE” or “CARRIER” - for CMS orders only. | Account Very > Label Type | If not setup no label is to be requested |
| Response Format | X(5) | /PRINT_REQUEST/RESPONSE_FORMAT | See table below. | Account Very > Label Format | *Dependent on the Type, see available types table below |
| Order Number | X(8) | /PRINT_REQUEST/ORDER/NUMBER | Order Item > Order Item Line ID | For MO orders requesting label for only one Order ID should return a label for all | |
| Order Date | YYYY-MM-DDThh:mm:ss | /PRINT_REQUEST/ORDER/DATE | Orders > Order Created Time | From everything read I believe their unique value for recognising orders is the pair between OrderID and OrderDate, hence this is the date we’ve stored not the current date when we are creating the request |
Example XML
Available Label Types and Formats
| LABEL_TYPE Value | RESPONSE_FORMAT Value(s) | WAP Notes |
|---|---|---|
| WHOLE | This will return an A4 pdf containing different sections to peal off and stick in the parcel or outside the package | |
| CARRIER | PNG, ZPL | Just the outside shipping label |
| CARRIERRETURN | PDF (Return note), PNG, ZPL (Carrier) | Should return both the outside shipping label and a return label for inside the package |
Actions
- We need to store a label request in Hemisphere against every order to be able to track and capture file/s accordingly. This either needs to happen at the point of order successful creation or as a next step. The label request is NOT a blocker for an order but depending on Very’s requirement it can be for fulfilment. The label request should be created on pending with the Type it is using as well to be able to then just pass it through to BluJay
- Every Order should be in a different request file. Even if their functionality allows for multiple order requests we want to 1) track better and 2) receive different labels per order. If we request many orders at once we will receive a file for them all at once (with the idea that whoever is dealing with this will want this functionality near live time and will select a batch of orders, request a label and print the whole thing for all orders once.
- Once a Label request has been generated we should put the record in Hemisphere on sent to be able to track the progress
- As we read the files we need to store them in a url accessible folder as label files (to be able to export and provide access to them) and “close” the label request as completed
Note: at a future date we should incorporate this label request into our UI functionality as well - to be able to request a label manually (or request a new one) both single and in bulk with all its current validations and variations
File Name and Limitations
- Label Request filename has only a requirement to start with “PrintReq” and have a unique ID. I propose we use the Label Request in Hemisphere ID for easier mapping and end up with a file of this sort “PrintReq_1.xml“
- The Label Output file that we need to store will be generated on the FTP with the Label Request Filename as prefix. meaning it will look like this: “PrintReq_1_XXXXXXXXXXX.pdf” where the XXX is an unknown at the moment
- File size limitations are not stated but expectations are the same (500kb) which should not be a problem having in mind we will request single labels, order by order