Tracking number patterns - tracking

Is there any place to get patterns for shipping tracking numbers for all shipping companies like UPS,FedEX, DHL, AirBorne, USPS ...

Fedex: 12, 14, 15, 20, 22 digits are all valid tracking number
UPS: 1Z + 16 digits or begin with W,T,H + 10 digits
DHL: 10 digits ONLY (if u mention the express shipping, as DHL also have cargo, sea shipment etc)
usps: https://tools.usps.com/go/TrackConfirmAction!input.action
Notice that as far as i know, there is not a complete list there.
If anyone know the new tracking number format, please let me know too.
As I run a startup http://www.aftership.com which also need to detect the tracking number pattern.

Fedex:
XXXXXXXXXXXX (12 numbers)
DHL:
International Air Freight Shipments -
7 digit HAWB number 1234567
International Ocean Shipments - 9
character HBL number SEA123456
U.S. Domestic Shipments* – 3
character origin code and HAWB
number, which can be up to 10 digits
in length. SEA1234567
DHL Tracking Number Information Page
Canadian Postal Service:
Canadian Postal Service Tracking Information Page
UPS:
Begins with 1Z
If it's UPS, Fedex or USPS, you can send the number into Google and get the type from the Google result.
Airborne is now DHL.

Related

Odd results from Google Reverse Geocode API

Recently I've been occasionally receiving odd results from the Google Reverse Geocode API.
For example when looking up the address for coordinates 43.2379396 -72.44746565 the result I get is:
6HQ3+52 Springfield, VT, USA
In another case looking up 43.703563 -72.209753 results with:
PQ3R+C3 Hanover, NH, USA
Does anyone know what the initial 7 bytes of the returned address symbolize? When I receive this type of result it's always 4 bytes of alphanumeric data followed by a plus sign then 2 more alphanumeric bytes.
After some additional research I found that these are Plus Code addresses, a relatively new feature in Google Maps. These are used for places that don't have a street address. These seem to have some similarities to "what 3 words" addresses.

AMAZON EDI / required payer name in NAD+IV segment is longer than 35 character limit

I am working for a big manufacturer and supplier to Amazon. We are currently in testing mode with them for EDI. We are using AS2, EDIFACT standard, like required from Amazon. regarding INVOIC messages, Amazon is insisting on a specific payer address in NAD IV segment - the company name of Amazon Germany, which is about 41 characters. We have exact payer address stored in SAP, but once we make EDI transfer, the payer name segment is cut to 35 character.
What we can transmit:
NAD+IV+5450534005838::9++AMAZON EU SARL:NIEDERLASSUNG DEUTSC+Marcel-Breuer-Str. 12+MUENCHEN++80807+DE'
What AMAZON expects:
NAD+IV+5450534005838::9++AMAZON EU SARL:NIEDERLASSUNG DEUTSCHLAND+MARCEL-BREUER-STR. 12+MUENCHEN++80807+DE
Amazon is consequently rejecting our invoices after transmission as long as there is no exact match.It is insane, as Amazon itself provides documentation where the field limit is stated.
However we do not get qualified response over their vendor central. (Everyone working with Amazon knows what I mean)
Has anybody experience with EDI setup with Amazon, their requirements and this specific field limitation?
We have tried to use an abbreviation of company name, but this is not accepted. Billing address cannot be changed.
Change of field length in code not possible at the moment
the NAD segment has several name and address fields in composite C080 (5 of them in release D96A in fact). You can store the required name in those fields, not just in the first one. The colon in your message example is not part of the name, it is a separator for fields in a composite. It's part of the EDIFACT syntax. The plus sign separates fields and composites, the colon separates fields within a composite.
dissecting the expected NAD segment it looks like this:
NAD (Segment name)
IV Field 3035, Party Qualifier
5450534005838 Composite C082, Field 3039, Party Identification
Composite C058 is left empty
AMAZON EU SARL Composite C080, Field 3036 (first occurrence), Party Name
NIEDERLASSUNG DEUTSCHLAND Composite C080, Field 3036 (second occurrence), Party Name
MARCEL-BREUER-STR. 12 Composite C059, Field 3024 Street
MUENCHEN Field 3164, City Name
Field 3229 is left empty
80807 Field 3251, Postcode
DE Field 3207, Country coded
I personally use the EDIFACT directories from Truugo to check the message definitions:
the NAD segment: https://www.truugo.com/edifact/d96a/nad/
the INVOIC message https://www.truugo.com/edifact/d96a/invoic/

VIN Vehicle Identification Number, how to figure out the WMI part?

I am trying to figure out how to breakdown a vehicle vin number.
There is an explanation of how a VIN is build (http://en.wikipedia.org/wiki/Vehicle_Identification_Number#Components_of_the_VIN) but it fails to explain what to do with manufacturers that only have 2 digits assigned instead of 3 digits.
If I understand correct what is written there then every VIN number must be 17 characters long, and the first 3 characters are the WMI (World Manufaturer Identification).
Then there is a list of WMI on the same page, but some manufacturers only have 2 characters in that list, not 3.
How to read such a VIN number ? Will it be only 16 characters long or how do I regognize that a WMI is 2 or 3 characters ?
for example nissan has WMI = JN which is only 2 characters.
2 VIN numbers for Nissan that I know that are valid are :
JN1UC4E26F9001391 and JNKCP0106TT541680
How can I know that for these 2 VIn numbers only the first 2 digits are to be read and used for the WMI ?
In you examples it is in fact 3 characters that Set the WMI information
JN1UC4E26F9001391
NISSAN MOTOR COMPANY, LTD. JN1,1N4 3995 RESEARCH PARK DRIVE ANN ARBOR MI 48104 PASSENGER CAR SEE MEMO 7/29/1986
JNKCP0106TT541680
NISSAN RESEARCH & DEVELOPMENT JN1,JNK 750 17TH STREET, N.W. WASHINGTON DC 20006 PASSENGER CAR ALL 1/13/1992
1st character- Identifies the country in which the vehicle was manufactured.
For example: U.S.A.(1or 4), Canada(2), Mexico(3), Japan(J), Korea(K), England(S), Germany(W), Italy(Z)
2nd character- Identifies the manufacturer. For example; Audi(A),
BMW(B), Buick(4), Cadillac(6), Chevrolet(1), Chrysler(C), Dodge(B),
Ford(F), GM Canada(7), General Motors(G), Honda(H), Jaquar(A), Lincoln(L), Mercedes Benz(D), Mercury(M), Nissan(N), Oldsmobile(3), Pontiac(2or5), Plymouth(P), Saturn(8), Toyota(T), VW(V), Volvo(V).
3rd character- Identifies vehicle type or manufacturing division.
Per VIN descriptor
This link contains the most current WMI information for all, this is were I got my data
WMI for all manufactures
In any Case it is not 3 or 2 for WMI it is
1 for country
2 for manufacturer
3 for type
this gets a little tricky because IF "2" = "N" that is not necessarily Nissan, for example 1N9 = NOMAD CUSTOM CYCLES INC.
Let me know if that helps or if you find a place to get VDS information
Your wiki page seems pretty clear that it's either a 3-character WMI, or a 2-character WMI followed by a 9.
There are an abundance of libraries out there, on GitHub and elsewhere, which are designed to decode VINs. "Do not do a thing already done."

Does the Luhn algorithm work for all mainstream credit cards? (Discover, Visa, Mastercard, Amex)

Reference: Luhn Algorithm
The Luhn Algorithm is a great way to quickly verify that the user typed their CC # in correctly.
However, I am concerned that there may be a subset of mainstream credit cards that do not use Luhn-Algorithm-friendly numbers.
I do have logging in place in our application to detect a pattern in all Luhn-Algorithm-rejections, but I'd rather know definitively.
Almost.
China UnionPay and one kind of Diners Club card (enRoute) do not use Luhn validation. (LazyOne’s answer is wrong about Diners Club.)
Nearly everyone else does.
Citing Wikipedia's 'Bank card' page:
Don't validate at all:
Diners Club enRoute
China UnionPay
Validate with Luhn 2:
American Express
Bankcard
Diners Club Carte Blanche
Diners Club International
Diners Club United States & Canada
Discover Card
InstaPayment
JCB
Laser
Maestro
Dankort
MasterCard
Solo
Switch
Visa
Visa Electron
Yes -- it works for all mainstream card types.
I have a custom PHP class to handle card data that was compiled from various "validate card number" and alike functions from few programming languages + information from Wikipedia & some Payment Processing systems. It successfully validates test card numbers (every payment system has few of such numbers) for these card types:
VISA debit / credit
VISA Electron
VISA Delta
MasterCard
AMEX
Maestro
Switch
Solo
Diners Club
Discover
JCB
The LUN check works on most credit cards. It is a modulus 10 check digit system to guarantee that the card number has been accurately read/recorded (mag stripe, virtual terminal or manual entry in the old days of the manual card imprinter).
Back in the days of manual data entry, these check systems were used to make sure that keys like UPS's pickup book numbering system were accurately entered (modulus 7 check digit).
It is even used in barcoding systems like code 128 which needs a modulus 103 digit added to the encoded data string to verify that the code was read right.

How to get card type information using unimag credit card reader

I want to integrate card swipe feature in my application using unimag card reader device provided by ID Tech. It provides name, account number and expiry date in a single string. But no information about the card type. Is there a way to retrieve the information about the "The type of Card" user hols. Like visa, master, etc.
Card type is determine from first couple of digits
example code here
http://cuinl.tripod.com/Tips/o-1.htm
a quick google for implementations :-)
The cliff notes version:
If card starts with:
3 - Amex (15 digits)
4 - Visa (13-19 digits, usually 16)
5 - Mastercard (16 digits)
6 - Discover (16 digits)
There are some other more rare card types like JCB and Diners which you might need to account for if your solution has to deal with those.