jkeen / tracking_number Goto Github PK

While extracting a tracking number from a text, the random number 16666851810162483643 was identified as a FedExSmartPost and returned as 9216666851810162483643, adding 92 at the beginning.

this shouldn't be identified as a tracking number, or at least literal matching should be configurable.

First off, thank you for the great work on this gem!

We are using this gem to parse out tracking numbers from emails.

In version 1.3.0, we are now seeing a large number of false positives. Many strings that look like coupon codes or SKUs are being parsed as tracking numbers.

I imagine it has to do with new couriers added having fairly loosely structured tracking number formats. Not sure if there is a good solution to this? Perhaps a way to configure "strict" (minimize false positives) vs "eager" (minimize false negatives) modes or similar?

We've had to downgrade to 1.0.7 in the meantime. Any ideas on how to fit our use case would be appreciated.

Thanks!

I have noticed that the latest version (1.3.0) is misidentifying some USPS tracking numbers. The number 420773169261290283641500004181 is a USPS tracking number (not SmartPost) yet the library is identifying it as FedEx. I had to rollback to version 1.0.7 to get these tracking numbers to be identified correctly. I tried to look at the changes made since 1.0.7 that might have caused this, but could not pin it down. Any direction you can provide is greatly appreciated.

I have this tracking numbers from USPS

420967849405510200829415553590
420940059405510200828480912387
420969299405510200829448809619

All of them are valid, but according to the gem they are invalid.

Any idea why is this happening?

Hi @jkeen ,

Thank you for this library - it is very wonderfully helpful! I wanted to share with you that I created a Java port (well almost a port) of this library. It does not have the string searching functionality, but adds support for lookup of a package by tracking url. I spent some time cleaning up the check digit algorithms, as I found that most carriers share basically the same mod10 algorithm.

I am wondering if you would be interested in keeping our projects more or less in sync? For instance, I just responded to one of your issues ( #21 ) that I added RoyalMail support. A company I work for will be using this library to parse many packages, and I suspect bugs will be noticed regularly as carriers make updates and don't notify us :)

The java library:
https://github.com/adgaudio/MysteryTrackingNumber

Thank you,
Alex

https://tools.usps.com/go/TrackConfirmAction!input.action

On USPS' website it lists some sample numbers, for example 9400 1000 0000 0000 0000 00 fails, and so do the others. Did their tracking number specs change?

I have a bunch of tracking numbers that start with 9205. according to this page https://tools.usps.com/go/TrackConfirmAction_input that is for Priority Mail. I am able to see them in USPS's tracking system. When I use this code:

t = TrackingNumber.new("9205......")
puts t.carrier

It just says "fedex". What might be wrong here?

I'm using ruby 2.3.1p112 on windows 7 with tracking_number (0.10.2).

Hello,

I am looking to use this gem in my project, but noticed a comment here that seems to imply that there is something wrong with the current implementation of a couple of the FedEx subclasses.

Can you clarify if there is something wrong with the subclasses or if the comment was leftover after a fix was made.

If you know the fix, but haven't had time to apply it I would be willing to submit a PR.

Thanks

It's me again!

Using the new 1.0.2 I'm trying the sample code in Readme and it's returning nothing:

irb(main):001:0> require 'tracking_number'
=> true
irb(main):002:0> TrackingNumber.search("Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, 1Z879E930346834440 nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute9611020987654312345672 dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum")
=> []

returns an empty array.

First of all, thanks for the great lib ❤️

From my testing, a USPS91 number always instantiated with FedEx SmartPost class, due to the nature that they're sharing the same format.

For example:

irb(main):083:0> TrackingNumber.new('92001903060085300042901077')
=> #<TrackingNumber::FedExSmartPost:0x1fa838 92001903060085300042901077>

Unsure if it's the best way, but here's my workaround atm.

ORDER = [TrackingNumber::USPS91, TrackingNumber::FedExSmartPost]
tracking_numbers = TrackingNumber.detect_all(tracking_number)
sorted_tracking_numbers = ORDER.sort_by { |tracking_number| TRACKING_NUMBER_ORDER.index(tracking_number.class) || 99 }
sorted_tracking_numbers.first

broke my damn build

Please could you add Royal Mail tracking number recognition? Thanks. You have the info here: http://www.royalmail.com/sites/default/files/COSS_Spec_03_-_Barcodes_and_Tracking_Numbers_v1_1.pdf

So this may end up being a feature request, but I think I see some logic in the controller about a URL, but I can't seem to find any way to get a tracking URL.

I do see the base URLs in your other repo json file, so maybe it just hasn't been implemented. I can dig deeper and see how I'd do it myself.

I got this tracking number in an amazon order, which starts with "94": 9400111201080805483016
It is a valid tracking number, but is not picked up by USPS91.

I monkey-patched the problem away by creating a USPS94 (replacing instances of 91 with 94) class and adding it to TrackingNumber::TYPES, but this might be a more general issue. I couldn't find anything in USPS documentation to support this change, but they do seem to be issuing different tracking numbers than are supported by this gem.

Thanks for making this gem!

• Lucas

After installing v1.0.0 (gem install tracking_number -v 1.0.0), I get the following when trying to use it:

irb(main):001:0> require 'tracking_number'
Traceback (most recent call last):
       11: from /usr/local/bin/irb:11:in `<main>'
       10: from (irb):1
        9: from /usr/local/lib/ruby/site_ruby/2.5.0/rubygems/core_ext/kernel_require.rb:39:in `require'
        8: from /usr/local/lib/ruby/site_ruby/2.5.0/rubygems/core_ext/kernel_require.rb:135:in `rescue in require'
        7: from /usr/local/lib/ruby/site_ruby/2.5.0/rubygems/core_ext/kernel_require.rb:135:in `require'
        6: from /usr/local/bundle/gems/tracking_number-1.0.0/lib/tracking_number.rb:6:in `<top (required)>'
        5: from /usr/local/lib/ruby/site_ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'
        4: from /usr/local/lib/ruby/site_ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'
        3: from /usr/local/bundle/gems/tracking_number-1.0.0/lib/tracking_number/base.rb:2:in `<top (required)>'
        2: from /usr/local/lib/ruby/site_ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'
        1: from /usr/local/lib/ruby/site_ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'
LoadError (cannot load such file -- pry)

I'm relatively inexperienced with Ruby, but it seems that 'pry' is an alternative to IRB. Does it need to be included in this package?