Purolator Details

You might also like

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 11

Screen of Purolator Cockpit

1. Input packed HU
2. Display delivery, HU’s (picked, partially picked, or planned), and HU status from that delivery
(Should check if already processed and error)
• Green = All materials complete on the TO
• Yellow = Some materials picked but TO is not complete
• Red = TO creation has not yet happened (display the name of the pallet (same table))
– Use MPS table to determine
– If all HU’s not green, display message “HU’s not complete, please correct”
3. Weight input (all HU’s must be green for this side to be active):
• At first only displays 1 row (black row), after weight input and pressing enter, save data
in the custom table, the next row (blue rows) is added to screen
• Default weight UOM will be determined from a warehouse configuration table
• Liquid is a check box (influences data passed to Purolator)
User allowed to position cursor on a row to correct the weight
Functionality of buttons
4. Refreshes delivery data (used in cases you have corrected the ECC data causing yellow or red and
now you want to see if all is green; could also be done by in putting HU again)
5. Clears entire screen and puts the cursor in scan HU field
6. Calls Purolator for all boxes with weight, prints the labels (ask Purolator if “box #” is printed on the
label), and sends data back to ECC, (clear screen, display child HU last 4 digits??)
7. Clears all box weights inputted on the right side and let’s user start again on the right (prompt for are
you sure?)

First part Quantity calculation logic and Logic for Showing Traffic Light:

When the user Scans the HU, the system should determine the delivery from the HU entered. Using the
delivery, it should get all the TRs from MIXPAL table.

From TRs we can get the delivery status (Red/Yellow/Green) as below.

Copy first TR# 0010442347 in table LTBP:


Read matching TO# from the table (896702)

Copy TO# 896702 and use as input for table LTAP:


Check if TO was confirmed and not cancelled status:
TO is confirmed [LTAP-PQUIT] = [X] and Actual Pick Qty (LTAP-NISTA] not equal to zero [0] and
Transfer Procedure [LTAP-VORGA] = QB
Hence, matching HU# 376130307081453913 is shown as a green traffic light.

Repeat the above steps for the second TR# .


Take the second TR 10442348) from table MXPAL:

Copy second TR# 0010442348 in table LTBP:


Read matching TO# from the table (896703)

Copy TO# 896703 and use as input for table LTAP:


No entry exists in LTAP since the TO# is cancelled in the previous step.
Even if it had found the matching TO number in LTAP, system needs to validate if TO was not cancelled
in another way (for example via LT15 instead of via eTEC cockpit).
Hence, an additional check if TO was confirmed and not cancelled status:

TO is confirmed [LTAP-PQUIT] = [X] and Actual Pick Qty (LTAP-NISTA] not equal to zero [0] and
Transfer Procedure [LTAP-VORGA] = QB
TO is cancelled if Actual Pick Qty [LTAP-NISTA] = zero [0] and Transfer Order Procedure [LTAP-VORGA]
= ST. See a random example from A8A below:

Hence, the second HU# PAL002 must be shown as a red traffic light.
Logic for Quantity Calculation:

Operator scans the HU# to be packed and system determines the related Delivery# and related HU’s:

Copy the values of the Mixed Pallet HU’s found for the delivery 891009588:
00376130307000003328
00376130307000003335
00376130307000003359

Now go to table LTAP and search for Destination SU’s equal to the ones above (note: leading zero’s
removed): Delivery# in Destination Bin field for TO’s with Destination Storage Type 955, see below on the
right.  
 

Result:
For each Destination SU it shows the Source Actual Qty that was picked/confirmed plus the Alternative
UoM:

For the test data (delivery 0891009588 in ND2), expected the following Quantities:
Note: The Layer Pick pallet should be displayed in LAY UoM as also found in the LTAP table (4 LAG = 4
LAY)

Note: For the majority of Mixed Pallets, multiple items will be grouped into one single Mixed Pallet (TO).
Take a look at the Mixed Pallet HU below:  
It shows multiple materials against the Destination HU. In that case, the program need to consolidate all
quantities (2+3+5) and in the frontend screen show
HU 00376130307000003496        10 CS

Similarly, if the Mixed Pallet is an EA pick pallet, the EA quantities must be consolidated, see example in
A7A below:

The Quantity for HU 376130307034111655 should be 5 EA (1 EA + 2 EA + 2 EA)

Second part for the Generate Label logic:


Custom table /GLB/UGTT_COUR was created to capture the Delivery#, Box# (serial nmbr), Weight,
UoM, Liquid flag, Parent Pin# and Child Pin#

Before Packing Operator starts packing and weighing boxes, no entries in this table.
Once operator packed all items, he or she will select Generate Labels button.
As per design, this should trigger API (3) [Create Shipment] to Purolator.

Purolator returns Parent- and Child Pin# (4) which should update custom table /GLB/UGTT_COUR and
populate Parent- and Child Pin#. In background, API (5) [Get Documents] is triggered to request Label
Data. This is returned by Purolator in step (6).

If API (3) fails, Parent and Child Pin# will not be populated in custom table /GLB/UGTT_COUR and the
Generate Labels button should still be enabled for the Packer to retrigger the API.
Since entry for delivery exists in custom table, the screen on the right should show the boxes plus
individual weight on the right side of the screen and user should be able to change weights or add more
boxes.
Next scenario is where API (3) [Create Shipment] was successfully returned and Parent- and Child Pin#
are being populated.

Normally, labels should have printed but in case of printer problems, the user may have to request label
data again.

Now when the user selects ‘Generate Labels’, system to check table /GLB/UGTT_COUR and if Parent
and Child Pin# populated, it should retrigger API (5) [Get Documents].
The right-hand screen should be disabled for the user to change weight or enter additional boxes, since
the Parent and Child Pin# are already populated.

Cancel the Tracking Number:

If the user has created the tracking number by mistake and wants to cancel that number and
regenerate new tracking number, then a new cancel tracking number button is added to the
screen.
Once User clicks on the Cancel Tracking#, it asks for Confirmation 'Are you sure. Once user confirms,
then the parent pin is cancelled and if it is successfully cancelled, then message appears on
Purolator Screen as 'Tracking Number Successfully Cancelled'.

Click on Submit.

After cancelling the parent PIN the corresponding entries in /GLB/UGTT_COUR is set to Void = 'X'.
As the tracking number is successfully completed, the same will be deleted from Delivery header/Sales
order invoice instructions.

You might also like