I am trying to extract the shipping address from a commercial invoice.
One commercial invoice has ship to destination as Singapore.
The other invoice has ship to destination as Hong Kong
How do I write a regex to extract the destination address, which ends either with Singapore or Hong Kong ?
I wrote a regex to extract the shipping address from a Commercial Invoice. see below:
shipto = re.findall("Shipped To/FRT Forwarder\n[a-zA-Z0-9\s\#\-\,]*SINGAPORE", text).
My problem is the shipping address could be SINGAPORE or HONG KONG or another location. How can I make the regex more generic?
for example:
my shipping address could be
XXXX Singapore
or
YYYY Hong Kong
How do I implement a "either OR" logic in REGEX in the address extraction ?
I found this link helpful.
Here is how you would search for "HONG KONG" or "SINGAPORE".
shipto = re.findall("Shipped To/FRT Forwarder\n[a-zA-Z0-9\s\#\-\,]*(SINGAPORE|HONG KONG)", text)
If you want to generalize, you can do something like this:
shipto_regular_expression_template = "Shipped To/FRT Forwarder\n[a-zA-Z0-9\s\#\-\,]*(LOCATIONS)"
# You could get your list of locations from anywhere.
# These locations will be treated as regular expressions. themselves
list_of_locations = ["SINGAPORE", "HONG KONG", "ELSEWHERE"]
list_of_locations_joined = "|".join(list_of_locations)
shipto_regular_expression = shipto_regular_expression_template.replace("LOCATIONS", list_of_locations_joined)
re.findall(shipto_regular_expression_template, text)
Related
I'm learning to use the Amadeus API...
I'm able to search flights using "flight-offers-search", but as the title states, if I restrict results to American Airlines (AA), it returns nothing.
There absolutely are AA flights from DFW on the specified day (I'm on one), so not sure why it would fail.
So far I am unable to return ANY flights on ANY day, if "includedAirlineCodes=AA" is specified.
What is special about American Airlines? What am I missing?
url <- "https://test.api.amadeus.com/v2/shopping/flight-offers?originLocationCode=DFW&destinationLocationCode=SAN&departureDate=2021-09-03&travelClass=ECONOMY&adults=1&max=5¤cyCode=USD&includedAirlineCodes=AA"
Content from American Airlines is not included in the Self-Service APIs as described in the API overview.
url = "https://itunes.apple.com/lookup?id=1510853708
This only returns English results. I want to add a language or country code for China, but none of these worked:
url = "https://itunes.apple.com/lookup?id=1510853708&country=cn
url = "https://itunes.apple.com/lookup?id=1510853708&l=zh
It returned 0 results. I changed id to bundleId, but is the same.
However, search api worked with country=cn. So why doesn't lookup api doesn't work?
try this "https://itunes.apple.com/cn/lookup?id=",
and confirmed that your app sales areas contains China mainland.
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/
I am using VK API to get list of cities in specific country. Does anyone know how to show Russian cities (which are in Cyrilic) in Latin?
Example of JSON response:
http://api.vk.com/method/places.getCities?lang=en&country_id=1&count=1000&need_all=1
I am trying to check if city exists, but if someone enter city name in latin, in some cases city check works, for example Vladivostok is Владивосток, but Moscow is Москва.
I found one solution that works for me: firstly get all cities ids by places.getCities (database.getCities) method and then use database.getCitiesById providing saved cities ids like following:
database.getCitiesById?lang=en&city_ids=1,2,123
In request to this API method you can specify needed language by parameter "lang" (e.g. lang=en) and up to 1k comma-separated cities ids (e.g. city_ids=1,2,123,...).
database.getCitiesById official documentation
As an alternative, you can get the static list of Russian cities here. This JSON array contains the slug name of each city in English. It's a free list, so anyone can edit and add correct information for any localities.
I'm trying to understand in what order and what precedence the geocoding API takes when processing the pieces of the address that was passed to it.
I have this example of why I'm asking the question. The correct address is:
2608 N Ocean Bv
Myrtle Beach, SC 29577
Running that into the API, absolutely no problems:
http://maps.googleapis.com/maps/api/geocode/json?address=2608+n+ocean+bv+myrtle+beach+sc+29577&sensor=false
However, take this typoed version of the address:
2608 N Ocean Bv
Mrytle Beach, NC 29577
The city is spelled wrong, and it has the wrong state. Street number, name and zip code are correct. Mrytle Beach does not exist anywhere, and not in NC.
http://maps.googleapis.com/maps/api/geocode/json?address=2608+n+ocean+bv+mrytle+beach+nc+29577&sensor=false
Google comes back with:
2608 N Ocean Bv
North Myrtle Beach, SC 29582
Now, that is a valid address. But why did Google decide that was the address I was looking for?
If you remove the incorrect state, and don't replace it with anything:
http://maps.googleapis.com/maps/api/geocode/json?address=2608+n+ocean+bv+mrytle+beach+29577&sensor=false
Google returns a corrected version of the correct address. So it seems that state trumps zip code - however, North Myrtle Beach does not exist in NC.
I'm thinking that omitting city and state eliminates most of this issue - but I'd like to understand why - if possible. Thanks.
Edit:
After some further playing around - it seems that Google looks for a city match as highest priority, then state - ignore all else. In this case:
Can't find a city called "Mrytle Beach" anywhere in the world.
Let's start in NC then and find the closest match to the street address if there is one.
Ah, here is the closest one to NC - in North Myrtle Beach.
If you change the state in my example above from NC to FL, the more southern Myrtle Beach match is closer to Florida than the more northern North Myrtle Beach address, and that is what Google returns.
I'm trying to understand the reasoning behind this. It seems that this sort of logic would be near last resort - or at least after making use of the zip code passed - which it appears it doesn't use at all.