Frequently Asked Question on Speed Post KPIs

Page |1

Index: Speed Post KPIs

Contents/ Questions/ Clarifications/ Issues Page No
1. Missorts KPI Calculation 2
2. Mismatch between Delivery scan compliance and its details 3
3. Mismatch between Inbound Operational Performance and its details 5
4. Why is the Articles with full scans Report on KPI web page is 7
not backed up by the raw data catered from CEPT?
5. Calculation logic of Missing PIN Code 8
6. Calculation logic of report – Delivery Scan Compliance 9
7. Does remarks other than “Final Delivery” impacts the KPI – Delivery
Information Upload 10
8. Does the NTD Missort Articles impact the Inbound Operational
Performance? 10
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? 11
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
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 22
20. What does the leg code in the Rawdata means? 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 PBD: 10 articles delivered P>D: Report viewed

A B C 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 27/10/2012 26/10/2012 25/10/2012
Day 5 Day 4 Day 3 Day 2 Sunday Id Ul Fitar Day 1 Booking Day
02/11/2012 02/11/2012 01/11/2012 31/10/2012 30/10/2012 29/10/2012 28/10/2012 27/10/2012 26/10/2012
Day 5 Day 4 Day 3 Day 2 Day 1 Sunday Id Ul Fitar Booking Day
03/11/2012 03/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 Booking Day
04/11/2012 04/11/2012 03/11/2012 02/11/2012 01/11/2012 31/10/2012 30/10/2012 29/10/2012
Sunday Day 5 Day 4 Day 3 Day 2 Day 1 Booking Day
05/11/2012 05/11/2012 04/11/2012 03/11/2012 02/11/2012 01/11/2012 31/10/2012 30/10/2012
Day 5 Sunday Day 4 Day 3 Day 2 Day 1 Booking Day
06/11/2012 06/11/2012 05/11/2012 04/11/2012 03/11/2012 02/11/2012 01/11/2012 31/10/2012
Day 5 Day 4 Sunday Day 3 Day 2 Day 1 Booking Day
07/11/2012 07/11/2012 06/11/2012 05/11/2012 04/11/2012 03/11/2012 02/11/2012 01/11/2012
Day 5 Day 4 Day 3 Sunday Day 2 Day 1 Booking Day
12/11/2012 12/11/2012 11/11/2012 10/11/2012 09/11/2012 08/11/2012 07/11/2012 06/11/2012
Day 5 Sunday Day 4 Day 3 Day 2 Day 1 Booking Day
13/11/2012 13/11/2012 12/11/2012 11/11/2012 10/11/2012 09/11/2012 08/11/2012 07/11/2012 06/11/2012
Diwali Day 5 Sunday Day 4 Day 3 Day 2 Day 1 Booking Day
18/11/2012 18/11/2012 17/11/2012 16/11/2012 15/11/2012 14/11/2012 13/11/2012 12/11/2012 11/11/2012
Sunday Day 5 Day 4 Day 3 Day 2 Diwali Day 1 Booking Day
19/11/2012 19/11/2012 18/11/2012 17/11/2012 16/11/2012 15/11/2012 14/11/2012 13/11/2012 12/11/2012
Day 5 Sunday Day 4 Day 3 Day 2 Day 1 Diwali Booking Day
20/11/2012 20/11/2012 19/11/2012 18/11/2012 17/11/2012 16/11/2012 15/11/2012 14/11/2012
Day 5 Day 4 Sunday Day 3 Day 2 Day 1 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
PBD: Delivery info of P>D: Report
remaining 20 articles is viewed & raw data
PAB : 80 articles delivered uploaded in historic date is extracted

A PAB : 60 article‟s B C D
delivery info is
uploaded
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
PBD: Delivery info of P>D: Report
remaining 20 articles is viewed & raw data
PAB : 80 articles delivered uploaded in historic date is extracted

A PAB : 60 article‟s B C D
delivery info is
uploaded
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:
th
KPI Date: 25 July, 2012
th
KPI Calculation Date: 29 July, 2012
th
Considered Date of booking of articles for the KPI:19 July, 2012

Thu Fri Sat Sun Mon Tue Wed

D-5 D-4 D-3 D-3 D-2 D-1

19-07-2012 20-07-2012 21-07-2012 22-07-2012 23-07-2012 24-07-2012 25-07-2012

th 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 drop-

down 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 / SPCto
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 Booking Date DateDelivered D+X (days)

XYZ 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 Status At Status
8/18/2012 10:50:00 Booking PO Item booked
8/18/2012 14:57:28 Booking PO Item bagged for Hub
8/18/2012 15:22:26 Booking PO Bag Dispatched to Hub
8/18/2012 19:28:00 Sorting Hub Bag Received
8/18/2012 19:28:14 Sorting Hub Bag Opened
8/18/2012 19:28:14 Sorting Hub Item Received
8/19/2012 4:55:24 Sorting Hub Item Bagged For Delivery BO
8/19/2012 4:55:35 Sorting Hub Bag Dispatched to Delivery BO
8/20/2012 8:16:55 Delivery SO Bag received
8/20/2012 8:35:54 Delivery SO Bag Opened
8/20/2012 8:35:54 Delivery SO Item Received
8/20/2012 0:00:00 Delivery BO 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

Transit
Leg Difference (Minutes) time(Days)
Booking PO Booking to Dispatch 272 0.19
Booking PO Dispatch to Hub Received 246 0.17
Hub Bag receive to Hub Bag open 0 0.00
Hub Bag open to Hub Bag Close 567 0.39
Hub Bag Close to Hub Dispatch 0 0.00
Hub Dispatch to Delivery Office Receive 201 0.14
Delivery office receive to Bag Open 19 0.01
Delivery Office bag Open to Final Delivery 564 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.