LTB 406/20 - Mail Centre Processing - Alphanumeric Barcoding

[Tamsk]

One of the problems I’ve noticed is if a postcode of say AN1 2QQ is written as AN12QQ, with no spacing, the “system” tends to recognise this as AN12, and therefore allocates the wrong DO/inward code to the item. That’s not the only time the codes are incorrect, but it’s certainly a common example.

The software doesn't need a "space" to interpret the code. If you manually input a postcode for testing purposes no space is inputted between the characters.

And conversely, if the software somewhere is using is buggy (the places that send Chinese packets into our system as tracked are the most visibly regular offenders here), it'll quite often ignore a space that is there, giving "AN1 2QQ" AN12's alphanumeric anyway.

[Tman]

If the code was read as AN12 (rather than AN1 2XX) the code would fail as it would be missing the third numeral. There is no code in the format of "AN12 XX"

[Tamsk]

I assure you that I've seen many, many packets come through that have been miscoded in exactly the fashion I described. Clearly every sender isn't using the same program to generate them.

[POSTMAN]

Inward Delivery Office Alpha Numeric to now be shown on the Tracked York Card.

To support sortation and quality checks the Delivery Office Tracked Alpha Numeric will now be shown on the York card.

This is part of the ongoing deployment to make sortation easier within Processing by only requiring the operation to match the Alpha Numeric code on the item to the sort aid containing this code.

The York’s cards will start to be seen as new sticks are ordered from central stores to ensure no wastage of old labels.

alpha.png

[Steve_claret]

If the code was read as AN12 (rather than AN1 2XX) the code would fail as it would be missing the third numeral. There is no code in the format of "AN12 XX"

The alphanumeric sort codes are totally different to postcodes. The Inward alphanumerics I see are only 2 or 3 characters.

[Lockardian]

One of the problems I’ve noticed is if a postcode of say AN1 2QQ is written as AN12QQ, with no spacing, the “system” tends to recognise this as AN12, and therefore allocates the wrong DO/inward code to the item. That’s not the only time the codes are incorrect, but it’s certainly a common example.

The software doesn't need a "space" to interpret the code. If you manually input a postcode for testing purposes no space is inputted between the characters.

And conversely, if the software somewhere is using is buggy (the places that send Chinese packets into our system as tracked are the most visibly regular offenders here), it'll quite often ignore a space that is there, giving "AN1 2QQ" AN12's alphanumeric anyway.

That’s what I’ve noticed a lot, not just with the “Chinese” packets, but now I come to think about it this happens mainly with small packets. At least we know it’s not gonna happen in all cases.

[Lockardian]

Can anyone from a DO confirm if there is a procedure in place to correct incorrect codes?

We are constantly being told by mail centre managers to sort Tracked items by Alphanumeric codes only and to completely ignore addresses and postcodes. Even items that have been returned from DOs with the correct location/DO written on! The managers say the only way to get the codes corrected is to mis-sort the item and send it to the DO represented by the AN code. Yet it seems such mail just goes around in circles until a sensible/insubordinate member of staff sends it to the correct place.

[SpacePhoenix]

Can anyone from a DO confirm if there is a procedure in place to correct incorrect codes?

We are constantly being told by mail centre managers to sort Tracked items by Alphanumeric codes only and to completely ignore addresses and postcodes. Even items that have been returned from DOs with the correct location/DO written on! The managers say the only way to get the codes corrected is to mis-sort the item and send it to the DO represented by the AN code. Yet it seems such mail just goes around in circles until a sensible/insubordinate member of staff sends it to the correct place.

We only sort outward by the AN codes, inward is done by address and postcode

[Lockardian]

Inward Tracked is sorted by AN codes at our mail centre. This is where the issue of incorrect codes being “mis-sorted” comes in (as explained above). Anyone I’ve asked from DOs don’t even know what the codes mean, let alone have the ability to amend them.

[SpacePhoenix]

Do the incorrect AN codes get crossed out?

[Lockardian]

Do the incorrect AN codes get crossed out?

Occasionally but not often. We even get items bouncing back and forward from other MCs when the first part of the AN code is incorrect. Because many MCs use the same AN codes for DOs (eg. A1 could refer to any number of DOs around the country) and our inward sorters only seem to look at the second part of the AN, they often go to the wrong DOs before being sent back to the MC and hopefully picked up as a mis-sort/forward.

I asked about this elsewhere but didn’t get an answer- but it appears the PSMs may be routing mail back to the wrong MC, even when the wrong AN code/address and postcode have been crossed out. You can’t really cross out the 2D barcode as it’s needed for onward tracking, so I don’t know what the solution is. All the above issues are delaying mail, and I can’t believe we are still being told by managers to sort purely by the AN codes.

[SpacePhoenix]

Occasionally but not often. We even get items bouncing back and forward from other MCs when the first part of the AN code is incorrect. Because many MCs use the same AN codes for DOs (eg. A1 could refer to any number of DOs around the country) and our inward sorters only seem to look at the second part of the AN, they often go to the wrong DOs before being sent back to the MC and hopefully picked up as a mis-sort/forward.

Just cross out both parts of the AN code. Provided each office scans the missorted items as a missorts then it'll get flagged up against the sending office each time.

I asked about this elsewhere but didn’t get an answer- but it appears the PSMs may be routing mail back to the wrong MC, even when the wrong AN code/address and postcode have been crossed out. You can’t really cross out the 2D barcode as it’s needed for onward tracking, so I don’t know what the solution is. All the above issues are delaying mail, and I can’t believe we are still being told by managers to sort purely by the AN codes.

Cross the 2D barcode out but make sure the printed tracking number is still readable. It'll force it go go wherever rejects get sorted but the tracking code can still be entered manually. Probably 80-90% of the Tracked items that have 2D barcodes on them also have a 1D barcode as well

[Lockardian]

Thanks SP. So - if I’ve understood you correctly- crossing out both the QR-type barcode and the 2D code, but leaving the tracking number legible so it can be entered manually should cause the PSM to reject the item to manual? And if the AN code has been crossed out and the postcode/address has been manually amended a human *should* route the item correctly.

I really wish our managers would allow us to use such common-sense ideas, instead of “sort by the second part of the AN code and nothing else” or (fair enough in normal circumstances) “don’t write on packets”* etc etc.

PS: What does scanning an item as a missort (wrong mail centre) do, other than generate an apology message to the customer? You imply it “informs” the sending mail centre in some way?

[SpacePhoenix]

PS: What does scanning an item as a missort (wrong mail centre) do, other than generate an apology message to the customer? You imply it “informs” the sending mail centre in some way?

It gets flagged up on a report which shows for each combination of which office an item was meant to go and where it actually ended up. It also has a total occurrences count for each combination

[NW11851]

Inward Tracked is sorted by AN codes at our mail centre. This is where the issue of incorrect codes being “mis-sorted” comes in (as explained above). Anyone I’ve asked from DOs don’t even know what the codes mean, let alone have the ability to amend them.

Many of our MC manual sorters supplied by Angard, dont understand the AN codes.

Many of us were told how to use them when they were introduced but a combination of dissipated knowledge, lack of interest and language unfamiliarity means that they sort by postcodes, if we’re lucky and town names.

It’s far from ideal.