USPS tracking number issue

[lacherogwu]

Here are some examples of USPS tracking numbers that are received as FedEx instead of USPS

{
  "name": "FedEx SmartPost",
  "trackingUrl": "https://www.fedex.com/apps/fedextrack/?tracknumbers=%s",
  "description": "IMpb CO3 standard",
  "trackingNumber": "9202090339598350198298",
  "courier": {
    "name": "FedEx",
    "code": "fedex"
  }
}

Actually, it matches the USPS tracking numbers, but also matches FedEx, and since FedEx is prior in the checklist it results in FedEx output

Here are some USPS tracking numbers: 9202090339598352279018 9202090339598352366718 9201990153540214710128 9202090339598351457004 9202090339598350916519 9202090339598350819421 9202090339598350198298

[jkeen]

Which library are you using to detect this? The ruby gem? And are you up to date on the latest version?

All of those numbers you listed are detected as USPS numbers for me on the latest version.

[lacherogwu]

I was using the typescript library, should they update to the latest version and it should be fixed?

[jkeen]

For your specific issue, I believe so, yes.

There's additional functionality that could be put in that typescript library to display shipping partners, which is not exactly what you're dealing with but close—USPS and FedEx often collaborate and the numbers reflect that. In the ruby library it will now detect both parties, the shipper (who delivered it) and the carrier (who initiated the shipment) from the single tracking number

[lacherogwu]

Got it, the question is if in the ts lib implementation if it will update the source code to the latest changes it will resolve the issue I had?

because from you're saying it is okay that FedEx and USPS matches, because they collaborate. now from what I've seen the ts lib looping thru all carriers files and matching by the rules defined in the json file and since fedex is prior in that list, it returns fedex, even tho USPS also matching and if it will continue loop thru it will fetch USPS as well

[lacherogwu]

I'm fixing the ts lib and I'm getting some error and not sure how to approach, would like your suggestion

I've updated the submodule to the latest changes, and seems like the USPS issue I was facing was fixed. but when building the lib I had 1 failed test related to DHL Express

I've looked into the dhl.json file and seems this tracking number JVGL0999999990 is where is fails, and this tracking number is listed under the "valid" key

I've tried to lookup this tracking number in 17track and seems like its unknown

What do you suggest to do?

You can check my fork here: https://github.com/lacherogwu/ts-tracking-number

[jkeen]

Not sure, all the tests pass for tracking_number_data, so those are all valid numbers as listed and I don't think it's an issue with the data side of it.

Sounds like something unique to the TS implementation. I've never looked at or used that library, so your guess is as good as mine

[lacherogwu]

I see that the validation has changed completely since the current version of the ts lib uses commit: 0f8b344d9a774202def15977c575026829ba7c31

upon checking I saw it fails in the mod7 validation function where it tries to convert this JVGL0999999990 to int and gets NaN (not a number) and I've seen in the previous version you also had here the same check and you didn't have the JVGL0999999990 tracking number in your valid object

but now, I see you don't have anywhere in the src code mod7 check, and seems like all the validation is different, the only place I find information is in the CHECKSUM_ALGORITHMS.md but I guess this is not updated...

Will you be able to walk me through the validation changes? so I could implement the changes on the ts lib from what I can tell with my 0 knowledge in ruby, the validation is removed and yet implemented?

[jkeen]

Great investigating!

The group should contain only numbers, but For DHL Express numbers that contained letters as well. The ruby client didn't error due to this since in ruby "JD000000".to_i == 0, but in other clients this caused an issue.

Additionally, it turns out with that correction that "JVGL0999999990" does not pass mod7 validation, so I have split those oddball J* dhl numbers into their own group without validation until more information is found about them.

Thanks so much for the extra effort in looking into this! I'm going to merge this PR and a new minor version will be released of tracking number data. Using that in the ts library should resolve your issue.

[jkeen]

Should be resolved in 1.6.1 @lacherogwu

[lacherogwu]

Great job!!! appreciate your help! I've created a PR for the ts lib

hopefully it would be merged https://github.com/rjbrooksjr/ts-tracking-number/pull/29