Frequently Asked Question on Speed Post KPIs
Page |1
Index: Speed Post KPIs Contents/ Questions/ Clarifications/ Issues
Page No
1. Missorts KPI Calculation 2. Mismatch between Delivery scan compliance and its details 3. Mismatch between Inbound Operational Performance and its details 4. Why is the Articles with full scans Report on KPI web page is not backed up by the raw data catered from CEPT? 5. Calculation logic of Missing PIN Code
2 3 5 7
6. Calculation logic of report – Delivery Scan Compliance 7. Does remarks other than “Final Delivery” impacts the KPI – Delivery Information Upload 8. Does the NTD Missort Articles impact the Inbound Operational Performance? 9. Will the BOs or non-computerized offices appear in the drop-down menu? If a particular office does not appear, what do we do?
9
10. What‟s the provision of Intercepting Station Articles in SpeedNet?
12
11. Do prescribed number of scans for TD Full Scan Compliance KPI also apply for Station articles
16
8
10 10 11
12. Number of TD-NTD Missort/Scans/Delayed articles reflecting in Transit Analysis Tool does not match with data available on KPI webpage 16 13. How is delivery information upload efficiency KPI calculated
16
14. Why the delivery information upload efficiency shows the SO Name only, however the delivery has actually happened through the BOs
17
15. Whether all the Speed Post articles are taken while calculating the TD/NTD transit time or not
17
16. What is reason behind the difference in delivery data reflecting in Speed net MIS and on KPI webpage
17
17. Why less scans are reflecting in raw data whereas track and trace report is showing all the mandatory scans? 18 18. Why does the Leg level transit time for TD/ NTD do not sum up to the average D+x numbers 20 19. Why is the D+x numbers different from D+x number in Transit Analysis Tool 20. What does the leg code in the Rawdata means?
22 22
21.What is the calculation Logic of „Delivery PO Efficiency Report‟ ?
24
Page |2
1. How is Missorts KPI Calculated? Basic Assumptions: UID Articles are discarded RGI and EPP Articles are discarded Return to Sender (RTS) articles are discarded th New Calculation is applicable from 25 Feb, 2012 and onwards for all sorting hubs TD Missorts:
Consider all the articles delivered under the catchment area of a Sorting hub, (being booked in the same sorting hub) on a specific date. Check the delivery office and corresponding PIN Code of the delivery office Also, look for the bag closing data, and get the office to which the article was sent from the Sorting Hub for delivery – There could be three possibilities: o A Bag has been closed for the Sorting Hub o A Bag has been closed for the Nodal Delivery Office o A Bag has been closed for the delivery office If the PIN code of the delivery office is not Mapped to either of the three possibilities in the previous step, i.e. o If the PIN code of the delivery office is not the part of the catchment area of the IC Hub o If the PIN code of the delivery office is not mapped to the Nodal Delivery Office o If the PIN code of the delivery office is not same to that of the Bag sent Office‟s PIN code then the article is considered Missent NTD Missorts: Consider all the articles delivered outside the catchment area of a Sorting hub of booking, on a specific date. Check the delivery office and corresponding PIN Code of the delivery office Find the delivery Sorting Hub based on the PIN code of the delivery office and all the IC Hubs of the circle of the origin sorting hub Find the destination Sorting hub to which the bag was closed for that particular article In case the destination sorting hub and delivery sorting hub are not the same or to the IC Hubs then it‟s a missent.
Page |3
2. Why the Delivery Scan Compliance report not backed up by it‟s linked details? Basic Assumption
UID Articles are Discarded RGI and EPP Articles are discarded Only TD articles are considered
The Summary report (The First screen) is calculated as part of the regular KPI calculation every night and de-facto is information is stored for any time reference purposes, however, the linked details are not static and whenever the report is evoked, a fresh query is run to display the current snapshot. While calculating the KPI, we are based on the D-1 snapshot, whereas while seeking the details, we get 1 more day of refreshed data, which may lead to mismatch, in case there is more delivery information uploaded during the day. ILLUSTRATIVE EXAMPLE PAB : 60 articles delivered
A
PBD: 10 articles delivered
B
C
P>D: Report viewed
D
A:= 100 articles were booked on D-6 PAB:= 60 Articles were delivered in Next 5 working days till D-1 B:= Data is loaded for KPI calculation for D-1 C:= KPI is calculated on D-1 snapshot of the data and stored with 40% of the TD articles not having delivery information which is displayed on the summary (first) screen of this report PBD:= 10 more articles are delivered out of those 100 booked D-6 D:= Data is loaded on D snapshot for reference and future KPI calculations P>D:= Report is viewed for the first time, which shows 40% missing scans on Summary but only 30 Articles in details – mismatch is noticed.
Page |4
For Day schedule example for Delivery scan compliance. The gazette holidays and Sundays are excluded when calculating the dates. Report Date
Day
01/11/2012 01/11/2012 31/10/2012 30/10/2012 29/10/2012 28/10/2012 Day 5
Day 4
Day 3
Day 2
Sunday
02/11/2012 02/11/2012 01/11/2012 31/10/2012 30/10/2012 29/10/2012 Day 5
Day 4
Day 3
Day 2
Day 1
03/11/2012 03/11/2012 02/11/2012 01/11/2012 31/10/2012 30/10/2012 Day 5
Day 4
Day 3
Day 2
Day 1
04/11/2012 04/11/2012 03/11/2012 02/11/2012 01/11/2012 31/10/2012 Sunday
Day 5
Day 4
Day 3
Day 2
05/11/2012 05/11/2012 04/11/2012 03/11/2012 02/11/2012 01/11/2012 Day 5
Sunday
Day 4
Day 3
Day 2
06/11/2012 06/11/2012 05/11/2012 04/11/2012 03/11/2012 02/11/2012 Day 5
Day 4
Sunday
Day 3
Day 2
07/11/2012 07/11/2012 06/11/2012 05/11/2012 04/11/2012 03/11/2012 Day 5
Day 4
Day 3
Sunday
Day 2
12/11/2012 12/11/2012 11/11/2012 10/11/2012 09/11/2012 08/11/2012 Day 5
Sunday
Day 4
Day 3
Day 2
13/11/2012 13/11/2012 12/11/2012 11/11/2012 10/11/2012 09/11/2012 Diwali
Day 5
Sunday
Day 4
Day 3
18/11/2012 18/11/2012 17/11/2012 16/11/2012 15/11/2012 14/11/2012 Sunday
Day 5
Day 4
Day 3
Day 2
19/11/2012 19/11/2012 18/11/2012 17/11/2012 16/11/2012 15/11/2012 Day 5
Sunday
Day 4
Day 3
Day 2
20/11/2012 20/11/2012 19/11/2012 18/11/2012 17/11/2012 16/11/2012 Day 5
Day 4
Sunday
Day 3
Day 2
27/10/2012 Id Ul Fitar 28/10/2012 Sunday
26/10/2012 Day 1 27/10/2012 Id Ul Fitar
25/10/2012 Booking Day 26/10/2012 Booking Day
29/10/2012 Booking Day 30/10/2012 Day 1 31/10/2012 Day 1 01/11/2012 Day 1 02/11/2012 Day 1 07/11/2012 Day 1 08/11/2012 Day 2 13/11/2012 Diwali 14/11/2012 Day 1 15/11/2012 Day 1
29/10/2012 Booking Day 30/10/2012 Booking Day 31/10/2012 Booking Day 01/11/2012 Booking Day 06/11/2012 Booking Day 07/11/2012 Day 1 12/11/2012 Day 1 13/11/2012 Diwali 14/11/2012 Booking Day
06/11/2012 Booking Day 11/11/2012 Booking Day 12/11/2012 Booking Day
Page |5
3. Why is the Inbound Operational Performance Report on KPI web page is not backed up by the raw data catered from CEPT? Basic Assumption
UID Articles are Discarded RGI and EPP Articles are discarded Only Inbound TD articles are considered Articles which are made RTS after receipt by the hub or any office under the hub are excluded.
The said report is calculated as part of the regular KPI calculation every night and de-facto information is stored for any time reference purposes, however, the raw data is extracted always on a refreshed set of data. While calculating the KPI, we are based on the D-4 snapshot, whereas while generating the raw data, we get at least 1 more day of refreshed data, which may lead to mismatch, in case there is more delivery information uploaded during the day. Articles which are made RTS after receipt by the hub or any office under the hub is not taken in to count. ILLUSTRATIVE EXAMPLE
PAB : 80 articles delivered
A
PAB : 60 article‟s delivery info is uploaded
P>D: Report viewed & raw data is extracted
PBD: Delivery info of remaining 20 articles is uploaded in historic date
B
C
D
A:= 100 articles were received during the cutoff Period of D-4 PAB:= 80 Articles were delivered in Next possible delivery round however information for only 60 articles were being uploaded and communicated to the central server.
B:= Data is loaded for KPI calculation for D-4; only for 60 articles has the delivery information on D-4 C:= KPI is calculated on D-4 snapshot of the data and stored with 60% of the Inbound Operational Performance and remains available on web page PBD:= Delivery information for remaining 20 articles are uploaded on D-3 or later; delivered through either BO or some non computerized office is uploaded on historical date/ communication glitch from the delivery office is resolved and the delivery date remains D-4
Page |6
D:= Data is loaded on D-3 snapshot for reference and future KPI calculations P>D:= Raw data is extracted and those articles loaded in Step C shows up as mismatch, however bearing the delivery date of D-4 only. Hence the Report shows 60% only, the track and trace as well as the raw data would suggest 20 more articles were delivered in time.
Page |7
4. Why is the Articles with full scans Report on KPI web page is not backed up by the raw data catered from CEPT? Basic Assumption UID Articles are Discarded RGI and EPP Articles are discarded The said report is calculated as part of the regular KPI calculation every night and de-facto information is stored for any time reference purposes, however, the raw data is extracted always on a refreshed set of data. While calculating the KPI, we are based on the D-4 snapshot, whereas while generating the raw data, we get at least 1 more day of refreshed data, which may lead to mismatch, in case there is more delivery information uploaded during the day. ILLUSTRATIVE EXAMPLE
PAB : 80 articles delivered
A
PAB : 60 article‟s delivery info is uploaded
P>D: Report viewed & raw data is extracted
PBD: Delivery info of remaining 20 articles is uploaded in historic date
B
C
D
A:= 100 articles were received during the cutoff Period of D-4 PAB:= 80 Articles were delivered in Next possible delivery round however information for only 60 articles were being uploaded and communicated to the central server.
B:= Data is loaded for KPI calculation for D-4; only for 60 articles has the delivery information and full scans information on D-4 C:= KPI is calculated on D-4 snapshot of the data and stored with 60% of the articles having full scans and remains available on web page PBD:= Delivery information and scans information for remaining 20 articles are uploaded on D-3 or later; delivered through either BO or some non computerized office is uploaded on historical date/ communication glitch from the delivery office is resolved and the delivery date remains D-4 D:= Data is loaded on D-3 snapshot for reference and future KPI calculations P>D:= Raw data is extracted and those articles loaded in Step C shows up as mismatch, however bearing the delivery date of D-4 only. Hence the Report shows 60% only, the track and trace as well as the raw data would suggest 20 more articles with full scan and delivered in time
Page |8
5. Calculation logic of Missing PIN KPI Basic Assumption: UID Articles are discarded RGI and EPP Articles are discarded Articles having bag closing scan at the Hub, booked under the catchment area of the Hub is considered for the KPI Calculations For the said KPI, all articles having the bag closing scan at the hub, being booked under the same hub formulates the denominator of the KPI. Out of these articles, those without 6 digits, non numeric PIN Code formulates the numerator of the KPI. ILLUSTRATIVE EXAMPLE: Say, 100 articles have the bag closing scan from a hub X on a particular day D. Say out of these 100 Articles, there‟s 2 articles which either does not have the Numeric PIN Code or does not have the 6 digit PIN Code. Share of Missing PIN Code = (Articles with without 6 digit non numeric PIN Code) X 100 (Total number of articles having bag closing scan at the hub)
Page |9
6. Calculation logic of report – Delivery Scan Compliance (Share of articles without delivery scans after 5 days of booking) Basic Assumption:
UID articles are excluded RGI and EPP Articles are discarded Articles meant to be delivered in India only is considered Sundays and gazette holidays are not considered Only TD Articles are considered
For the said KPI, for any day calculation of the KPI, booking of all the articles on 5 working days back is considered from the same hub and for all those articles, date of delivery is checked. If date of delivery is not available or is more than the date of KPI calculation then the share of articles without delivery scans after 5 days of booking is calculated as Total articles with missing delivery information or greater than the KPI date X 100 Total articles booked on D-5 of the KPI date
ILLUSTRATIVE EXAMPLE: KPI Date: 25
th
July, 2012
KPI Calculation Date: 29
th
July, 2012
Considered Date of booking of articles for the KPI:19
Thu
19-07-2012
D-5
Fri
20-07-2012
D-4
Sat
21-07-2012
Sun
D-3
22-07-2012
th
D-3
th
Mon
23-07-2012
July, 2012
D-2
Tue
D-1
24-07-2012
Wed
25-07-2012
th
Say 100 Articles were booked on 19 July, 2012 so for the KPI of 25 July, 2012. For share of articles not having delivery information after 5 days of th booking, all articles having no delivery information till 25 July or delivery done th after 25 July, will be considered for the KPI. Say, 10 articles were delivered th after 25 and 5 articles out of these 100 do not have the delivery information yet, then the KPI will show (10 + 5) = 15%
P a g e | 10
7. Does remarks other than „Final Delivery‟ impacts the KPI – Delivery Information Upload Only the final delivery information is counted as valid delivery information upload for the KPI. Any other non-delivery remarks are not considered for this KPI.
8. Does the NTD Missort articles impact the Inbound Operational performance of the receiving Hub? No. Articles which are made RTS after receipt by the hub or any office under the hub are excluded Basic Assumption: UID articles are excluded RGI and EPP Articles are discarded Articles meant to be delivered in India only is considered Sundays and gazette holidays are not considered ▪ Only Inbound TD Articles are considered
P a g e | 11
9. Will the BOs or non-computerized offices appear in the drop-down menu? If a particular office does not appear, what do we do?
Normally, a linked BO or non-computerized office should be visible in the dropdown menu at the delivery PO (HO/SO) and the desired office can be selected. However, if a particular office does not appear in the drop-down menu, it means such an Office is not linked. There may be following reasons for the same:
1. Latest Circle Data file for Offices has not been updated into local DB. Update the same and then check the status. 2. Or else, such office might not be appearing due to the fact that: a) Such an Office exists in the Office Master but it is not having the Linked “To Office” information, or b) Such an Office exists in the Office Master but it is Linked to some Other Office, or c) Such an office does not exist In this case, the System Administrator can send a list of such Offices which are not appearing even after updating the Circle Data of Offices under the “Other Office Invoice” option to
[email protected]. The status of a particular office may be known through the following:
System Administrator can know the status of the Office at SPC Site under the option -Linked Office -> Modify OfficeName. He should type the pin code of the office which is not appearing and fetch to get the details of the Office. If the Office Name exists there, then please copy the OfficeID, Office Name , Linked Office Name into an Excel Sheet. This excel sheet may be sent to ptcdesk@gmail through Division Head/RO/Circle Office .
Excel
Sheet may have the following columns: OfficeID / Office Name / SPCto which linked / SPC to which it is to be Linked
Note: If the Office name does not exist in the SPC site, then give the Office name with status of the Article as “Does not Exist” in the Excel Sheet. On checking the data received through Excel File, PTC helpdesk will update the Office data and will advise the office to down load the circle data for update at local DB.
P a g e | 12
10. Under the new network, all booking offices are required to send Speed Post articles to the concerned Sorting hub. However, an exemption was given in case of articles booked in an office and to be delivered from the same office (generally known as “Station Articles”). Does Speed Net have a provision for intercepting such articles? Yes, the provision exists in Speed Net to intercept such articles. Please follow the steps given below: Articles to be Delivered – Locally (From same office and BO) 1. Invoicing Station Articles to be delivered locally: Articles would have been collected through BNPL Booking / POS Booking – which are station Articles meant for Local Delivery. There is a provision to directly invoice those articles into Delivery Invoicing option. Note: There is no change in the process of Invoice / Returns to Station Articles – is same as those other office articles received through Bag for delivery at the office. Operator->Delivery->Invoicing->SpeedPost Articles or Express Parcels>Articles for Delivery.
The following invoice Screen appears. Scan the Article to the concerned beat of your office.
P a g e | 13
To take the Returns – use the following option.
2. Invoicing Articles to be delivered at Other Office to Other Office Articles ( Including BO) Option in Speed Net: Operator->Delivery->Invoicing->SpeedPost Articles or Express Parcels-> Articles or Parcels to Other Office.
P a g e | 14
Invoice the Articles in the following option:
The Offices Combo Box is shown open to see the Offices therein. Return Remarks entry for Articles sent out for Delivery to Other Offices / BOs. Operator ->Delivery->Remarks from Other Offices option.
P a g e | 15
The following screen appears for Remarks from Other Office:
Here you may fetch the Articles for the offices by selecting the invoice date Give the Delivery Remarks Select the Delivery Date as remarks Date. This date can be the actual Date at which the Article is delivered at BO or other office. And save it. Delivery Remarks Message will be created for that Article and sent to Central Server.
P a g e | 16
11. Do prescribed number of scans for TD Full Scan Compliance KPI also apply for Station articles which are booked and delivered from the same office and which do not travel to the Sorting Hub? Are these excluded from TD full scan compliance scores shown in the VC?
As these articles do not travel to the Sorting hub, 8 scans are not mandatory for these articles. However, they are not excluded from the TD scan compliance scores as of now. This is because the system has to check every article whether it is a station article in order to exclude such article from TD scan compliance which puts a lot of strain on the system and the process becomes too lengthy to be manageable. To overcome this, the maximum target for TD scan compliance for a city would be 90% assuming that not more than 10% article would fall under this category.
12. Number of TD-NTD Missort/Scans/Delayed articles reflecting in Transit Analysis Tool does not match with data available on KPI webpage Excel based Transit Analysis Tool works on the sample data of particular day to just reflect the problem area. Circles can request the raw data for further analysis.
13. How is Delivery Information Upload KPI calculated? Basic Assumption
UID articles are excluded RGI and EPP Articles are discarded Articles meant to be delivered in India only is considered KPI once calculated does not refresh again for rectified communication failures/ delayed communications with the central speed net server
This KPI aggregates the number of articles sent as well as number of articles for which the delivery information for the articles have been uploaded on a particular day over a PIN Code. I.e. for each PIN code in catchment area of a Sorting Hub, this KPI reports the number of articles sent on a day as well as total number of articles for which the delivery information has been uploaded. While counting the two numbers, the KPI does not necessitate the commonality of the articles; I.e. the KPI counts independently the set of two articles for reporting. Further the KPI, displays the delivery office against each PIN code.
P a g e | 17
14. Why the delivery information upload efficiency shows the SO Name only, however the delivery has actually happened through the BOs? According to the new Mail Network, every PIN code can only have one delivery office. However the actual delivery may be done through some branch offices. The shown names in the KPI/ report are actually those one Delivery Office Names which is associated with the specific PIN code. 15. Whether all the Speed Post articles are taken while calculating the TD/NTD transit time or not. All the Speed Post article (excluding UID and International) are taken in count while calculating the TD/NTD transit time. 16. What is reason behind the difference in delivery data reflecting in Speed net MIS and on KPI webpage? Speed net articles delivery is a continuous process and the communication of the delivered articles keeps happening to the central server as per availability of the data and communication channels from the fields. There are three reasons for the differences: 1. Types of articles considered for MIS vs KPIs 2. Instance of KPI/ report processing 3. Availability of the reports Types of articles considered KPI system only considers Speed net articles – excluding UIDs and International Articles; however MIS considers all Speed net articles Instance of KPI/ report processing The KPIs are calculated every night for D-4 and once calculated for a day, it never refreshes the numbers again. Whereas the communication of an article delivered in past may get communicated to the central server. The MIS runs on the live server‟s data and always reflects all the activities recorded till the point of time of fetching the report whereas KPIs are calculated at one instance and is never refreshed again a/c to the changes in the central server‟s data. Availability of reports KPI reports are available since October, 2010 and will remain available for ever as it‟s once calculated and stored, however the MIS can‟t be fetched beyond 90 days in past.
P a g e | 18
It is observed that typically the numbers in MIS is higher than the numbers on the KPIs but in cases when the barcodes are re-used/ duplicated then there could be a case when the KPI numbers may go up than MIS.
17. Why less scans are reflecting in raw data whereas track and trace report is showing all the mandatory scans? Please see the below examples Case 1: Article Number: EN042322942IN: It has two scans missing according to the mail which is evident into the track and trace. The first scans which is missing is booking office dispatch scan as is being done by some other office and not from the same office. Second scan which is missing is the Dispatch scan from the Visakhapatnam which closes the bag but fails to put dispatch scan .
P a g e | 19
Case 2: Article number: EN042323231IN: It has got 11 scans reported by hub even and the only missing scan is due to Dispatch of articles from different office than that of the booking office.
P a g e | 20
18. Why does the Leg level transit time for TD/ NTD do not sum up to the average D+x numbers? Core reason of these two numbers never summing up is the way it‟s being calculated. Example: Let us consider just one TD article being booked on Saturday, 18 August 2012 at 10:50 AM in a Post office and delivered on Monday 20 August 2012 by 1:30 PM and the delivery information is uploaded for the same at 5:30 PM. Hence the information recorded against this article is as follows:
ArticleNumber XYZ
Booking Date DateDelivered D+X (days) 8/18/12 10:50 8/20/12 0:00
1
Calculating the D+X for this Article, We‟d get 1 day as there was a Sunday in between which is a non-working day hence discounted from D+X calculations.
Now let us see the movement of this article from Booking till Delivery and convert the scenario into Leg wise transit time Date
Time 8/18/2012 8/18/2012 8/18/2012 8/18/2012 8/18/2012 8/18/2012 8/19/2012 8/19/2012 8/20/2012 8/20/2012 8/20/2012 8/20/2012
10:50:00 14:57:28 15:22:26 19:28:00 19:28:14 19:28:14 4:55:24 4:55:35 8:16:55
Status At Booking PO Booking PO Booking PO Sorting Hub Sorting Hub Sorting Hub Sorting Hub Sorting Hub Delivery SO
8:35:54 Delivery SO 8:35:54 Delivery SO 0:00:00 Delivery BO
Status Item booked Item bagged for Hub Bag Dispatched to Hub Bag Received Bag Opened Item Received Item Bagged For Delivery BO Bag Dispatched to Delivery BO Bag received Bag Opened Item Received Item Delivered
Now the Calculation of leg level transit time is calculated as difference in Minutes between successive scans and then convert that minute difference into Days to finally display this on report. Highlighted scans are considered for the leg level transit time calculations:
P a g e | 21
Leg Booking PO Booking to Dispatch Booking PO Dispatch to Hub Received Hub Bag receive to Hub Bag open Hub Bag open to Hub Bag Close Hub Bag Close to Hub Dispatch Hub Dispatch to Delivery Office Receive Delivery office receive to Bag Open Delivery Office bag Open to Final Delivery
Transit Difference (Minutes) time(Days) 272 246 0 567 0 201 19 564
0.19 0.17 0.00 0.39 0.00 0.14 0.01 0.39
Due to a fault in common practice while loading the delivery info for any article of Not selecting the current time the time of delivery is always loaded as 00:00:00 hours and to factor that effect, the delivery time is taken by default as 6 PM (18:00:00). If we sum up the D+X in the days in this example, it comes out to be 1.3 Days. Few Important points to be noted are, which makes leg level transit time impossible to sum up to D+X: 1. While calculating leg level transit analysis – scan time is considered however while calculating D+x only the days of booking and delivery is considered irrespective of their booking and delivery time stamps. 2. While calculating transit time the operations running over the weekends and even gazette holidays are considered however these are discounted while calculating the D+x numbers.
P a g e | 22
19. Why is the D+x numbers different from D+x number in Transit Analysis Tool? Basic Assumption UID Articles are Discarded Excel Based Transit Analysis Tool is designed to quickly provide diagnostics of speed post articles and related operations. Only a sample of articles is extracted for this toolkit hence the numbers in Transit Analysis Tool is just the representative; calculated based on the sample set of articles extracted. The KPI on web page considers all the articles for calculating the KPI. Given the case where in unequal number of articles are processed in two different tool kits, there‟s a difference in the numbers of D+x.
20.What does the leg code in the raw data means ? These are the description for the leg codes appearing in the raw data. An article should have following mandatory scans for NTD/TD articles. FOR PO NTD ARTICLES 110 booking scan 111 closing scan 112 bag receiving scan at Sorting HUb 113 bag opening scan at sorting hub 114 bag closing scan at sorting hub 115 bag dispatch scan at sorting hub 116 bag receiving scan at destination sorting hub 117 bag opening scan at destination sorting hub 118 bag closing scan at destination sorting hub 119 bag dispatch scan at destination sorting hub 120 bag receiving scan at delivery PO 121 final delivery scan
Pa g e | 23
FOR PO TD ARTICLES 110 booking scan 111 closing scan 112 bag receiving scan at sorting hub 113 bag opening scan at sorting hub 114 bag closing scan at sorting hub 115 bag dispatch scan at sorting hub 120 bag receiving scan at delivery PO 121 final delivery scan FOR BNPL NTD ARTICLES 110 booking scan 111 closing scan 115 bag dispatch scan at sorting hub 116 bag receiving scan at destination sorting hub 117 bag opening scan at destination sorting hub 118 bag closing scan at destination sorting hub 119 bag dispatch scan at destination sorting hub 120 bag receiving scan at delivery PO 121 final delivery scan
FOR BNPL TD ARTICLES 110 booking scan 111 closing scan 115 bag dispatch scan at sorting hub 120 bag receiving scan at delivery PO 121 final delivery scan
P a g e | 24
21.What is the calculation Logic of „Delivery PO Efficiency Report‟ ? Basic Assumption
UID articles are excluded RGI and EPP Articles are discarded Articles booked and meant to be delivered in India only are considered Articles which don‟t have booking information or have been booked before 45 days will not be counted. Articles having both bag closing and bag dispatch scan from the Sorting Hub/IC Hub/BNPL Unit, will only be counted. Bags despatched from Sorting Hub between 00:00 to 24:00 hours are taken into account for the calculation of a day/date Articles sent from a Sorting Hub/IC Hub/BNPL Unit to a delivery Post Office are taken into account for calculation of this report KPI once calculated does not refresh again for rectified communication failures/ delayed communications with the central speed net server This KPI aggregates the number of articles dispatched on a particular day as well as number of articles for which the delivery information/delivery attempt/RTS have been uploaded .Also the report takes into account the number of days taken from the receipt to delivery/ delivery attempt/RTS and booking to delivery /delivery attempt/RTS for the articles. D+X split is provided for receipt to delivery/ delivery attempt/RTS for each delivery office. National holidays and Sundays will not be counted for D+X values. If the delivery office is using old or incorrect office code for receiving and delivery information, updation will not be reflected in the report.
