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.
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/
Facing problem when fetching amadeus flight search api. When fetching flights details for two different timezone unable to see "Flight Duration" in the response we are receving. Got confused weather we can get flight duration in the API response or we should have to calculate it manually
Fare_MasterPricerTravelboardSearch reply also contains information about an itinerary travel duration.
You may find it in groupOfFlights/propFlightGrDetail/flightProposal node where unitQualifier equals to EFT (Elapsed Flying Time).
Please note, that this is a total time for all legs of the itinerary.
Try calling Air_FlightInfo.
You can find the flight duration in:
Air_FlightInfoReply -> flightScheduleDetails -> boardPointAndOffPointDetails -> additionalProductDetails -> legDetails -> duration
It will be in the format hhmm.
I am very very happy with Alphavantage.
BUT I can't find the german stocks (Xetra)
I have tried:
https://www.alphavantage.co/query?function=TIME_SERIES_DAILY&symbol=xtr:lin&apikey=MYKEY
(But this works https://www.alphavantage.co/query?function=TIME_SERIES_DAILY&symbol=NYSE:DIN&apikey=MYKEY)
https://www.alphavantage.co/query?function=TIME_SERIES_DAILY&symbol=Lin.be&apikey=MYKEY
(But this works: https://www.alphavantage.co/query?function=TIME_SERIES_DAILY&symbol=Novo-b.CO&apikey=MYKEY)
So my question is - has anyone had any luck getting german stocks on Alphavanta (or another free service. Realtime is not crucial, but obviously a plus).
I use the "Search Endpoint" function to find german stocks on alphavantage.
Let's say you look for "BASF" you could query:
https://www.alphavantage.co/query?function=SYMBOL_SEARCH&keywords=BASF&apikey=[your API key]&datatype=csv
You get a list with possible matches:
symbol,name,type,region,marketOpen,marketClose,timezone,currency,matchScore
BASFY,BASF SE,Equity,United States,09:30,16:00,UTC-05,USD,0.8889
BFFAF,BASF SE,Equity,United States,09:30,16:00,UTC-05,USD,0.8889
BASFX,BMO Short Tax-Free Fund Class A,Mutual Fund,United States,09:30,16:00,UTC- 05,USD,0.8889
BAS.DEX,BASF SE,Equity,XETRA,08:00,20:00,UTC+02,EUR,0.7273
BAS.FRK,BASF SE,Equity,Frankfurt,08:00,20:00,UTC+02,EUR,0.7273
BASA.DEX,BASF SE,Equity,XETRA,08:00,20:00,UTC+02,EUR,0.7273
BAS.BER,BASF SE NA O.N.,Equity,Berlin,08:00,20:00,UTC+02,EUR,0.7273
BASF.NSE,BASF India Limited,Equity,India/NSE,09:15,15:30,UTC+5.5,INR,0.6000
See documentation: https://www.alphavantage.co/documentation/
It seems to work with the yahoo symbols on alphavantage, at least for a few stocks (I did not check all). BASF for example works with:
https://www.alphavantage.co/query?function=TIME_SERIES_DAILY&symbol=BASF.TI&apikey=MYKEY
The alphavantage symbols for German securities consist of the Xetra symbol + .DE. For example EUNL.DE (for iShares MSCI World Core ETF). You can find a list of all Xetra stocks here.
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.