Bu araç, IATA NDC 17.2 / Farelogix AirShoppingRS ve OfferPriceRS dosyalarından hangi bilgiyi tam olarak hangi XML path'inden çektiğini burada belgeliyor. Ekrandaki her paket kartında da (fiyat, kabin, bagaj, kural, yolcu chip'leri) doğrudan tıklayarak aynı bilgiyi üreten canlı XML fragmanını görebilirsin.

1. Kök seviye

Alan	XML Path	Örnek
Mod (AirShoppingRS / OfferPriceRS)	kök tag adı	—
Havayolu (Owner)	ShoppingResponseID/Owner	A3
Response ID	ShoppingResponseID/ResponseID	XB97C57F-...
Uyarılar	Warning/@Code + metin	Code 325...
Hatalar	Error/@Code + metin	Code 719: No fares available

2. Uçuş segmentleri

Alan	XML Path	Örnek
Segment ID	FlightSegment/@SegmentKey	Isgm0200c1a7c6cff
Marketing carrier / uçuş no	MarketingCarrier/AirlineID, /FlightNumber	A3, 995
Operating carrier	OperatingCarrier/AirlineID, /FlightNumber, /Name	LX, 1830, Swiss
Kalkış / varış	Departure|Arrival/AirportCode, /Date, /Time	IST, 2026-09-04, 20:55
Uçak tipi	Equipment/Name	Airbus A320neo

3. Uçuş / journey

Alan	XML Path	Örnek
Flight ID	Flight/@FlightKey	Iflt7700c1a7c6cff
Segment sırası	Flight/SegmentReferences (boşlukla ayrılmış)	Isgm1 Isgm2
Süre	Flight/Journey/Time (ISO 8601)	PT06H00M

4. Fiyat sınıfı / marka

Alan	XML Path	Örnek
Price class ID	PriceClass/@PriceClassID	Xpc2700c1a7c6cff
Marka adı	PriceClass/Name	Light, Flex, ComfortFlex
Özellikler	PriceClass/Description/Text	"Non Refundable"

Sadece ikon referansı taşıyan (Description/Media) girişler otomatik filtreleniyor. PriceClassList hiç yoksa (unbranded fare) paket adı "Standart" olarak gösteriliyor.

5. Teklifler (Offer / PricedOffer)

AirShoppingRS'te çoklu <Offer>, OfferPriceRS'te tek bir <PricedOffer> — ikisinin iç yapısı neredeyse aynı, aynı parser ikisinde de kullanılıyor.

Alan	XML Path	Örnek
Offer ID	Offer/@OfferID	XB97C57F-...-1
Toplam fiyat	TotalPrice/DetailCurrencyPrice/Total	15421 → 154.21
Hangi uçuş / OD	FlightsOverview/FlightRef (+ @ODRef, @PriceClassRef)	OD1
OfferItem ID	OfferItem/@OfferItemID	...-1-1

Kabin (uçuş no bazlı): FareComponent/CabinType/CabinTypeCode ve CabinTypeName, boşlukla ayrılmış birden fazla değer taşır — her değer aynı FareComponent'in SegmentRefs'indeki segmentlerle sırayla eşleşir.

<FareComponent>
  <SegmentRefs>Isgm1 Isgm2</SegmentRefs>
  <CabinType>
    <CabinTypeCode>Y Y</CabinTypeCode>
    <CabinTypeName>ECONOMY ECONOMY</CabinTypeName>
  </CabinType>
</FareComponent>

Bagaj: iki katmanlı — DataLists/BaggageAllowanceList genel tanımları taşır, Offer'ın direkt child'ı olan BaggageAllowance/BaggageAllowanceRef referansla bağlar.

Alan	XML Path	Not
Kategori	BaggageCategory	Checked | CarryOn
Adet	PieceAllowance/TotalQuantity	0 = dahil değil, hata değil
Ağırlık	PieceWeightAllowance/MaximumWeight/Value + /UOM	23, KG

Yolcu bazlı fiyat kırılımı: birden fazla PTC (ADT/CHD/INF) olan aramalarda her yolcu tipi için ayrı bir OfferItem oluşur, her birinin kendi TotalPriceDetail/.../Total'ı olur; PassengerRefs, PassengerList'teki PTC ile eşleniyor.

Private / Corporate Fare: Offer içinde CorporateFare/Account elementi varsa ★ ile işaretleniyor.

Fare kuralları: FareComponent/FareRules/Penalty'nin RefundableInd/CancelFeeInd/ChangeFeeInd attribute'ları + Detail/@refs'in doküman genelindeki RuleMetadata/@MetadataKey → Instruction (Allowed/Not Allowed) eşlemesiyle çözülüyor. Ücret tutarı varsa Detail/Amounts/Amount[MIN|MAX]/CurrencyAmountValue'dan geliyor.

6. Yolcular

Alan	XML Path	Örnek
Passenger ID	Passenger/@PassengerID	T1, T2, T1.1
Yolcu tipi	Passenger/PTC	ADT | CHD | INF
Bebek bağlantısı	Passenger/InfantRef	T1.1

7. RS-geneli ekstralar

Şemada tanımlı ama pratikte çoğu RS'de boş gelir — kod her zaman "yoksa gösterme" mantığıyla yazıldı:

• Koltuk bilgisi: SeatDefinitionList/SeatDefinition → karakteristik kod, pitch, width
• Ek hizmetler: ServiceDefinitionList/ServiceDefinition → ad, açıklama
• Promosyon: Promotions/Promotion/@PromotionID
• Fiyat takvimi: Offer/PriceCalendar/PriceCalendarDate + TotalPrice/@LeadPriceInd

8. OfferPriceRQ üretimi

Gerçek çalışan bir Farelogix isteğiyle doğrulanmış yapı — genel IATA NDC pattern'inden farklı: Owner/ResponseID, <Offer>'ın attribute'ları, ayrı bir ShoppingResponse sarmalı yok.

<Query>
  <Offer OfferID="..." Owner="A3" ResponseID="...">
    <OfferItem OfferItemID="...">
      <PassengerRefs>T1</PassengerRefs>
    </OfferItem>
  </Offer>
</Query>

9. Bilinen kenar durumlar

• SOAP zarfı: RS bazen SOAP-ENV:Envelope > ... > AirShoppingRS içinde sarılı gelir — otomatik algılanır.
• JSON-escape'li string: RS bazen "<AirShoppingRS...\">" şeklinde gelir — otomatik JSON.parse ile temizlenir.
• PriceClassList eksik: bazı RS'ler brandsız gelir, paket adı "Standart" olur.
• Checked bag = 0: gerçek bir değer, "dahil değil" demek — hata değil.
• <Errors> bloğu: RS hiç Offer içermeyebilir, sadece hata döner (örn. Code 719: No fares available).
• Büyük Offer XML'i: her Offer 10-12KB'a kadar çıkabiliyor — bu yüzden "Kaynak XML" gösterimi lazy (sadece tıklayınca serialize edilir).

10. TK / IATA "EASD" şeması (farklı bir NDC nesli)

TK'nın RS'leri kök tagden itibaren bambaşka bir şema kullanıyor — Farelogix/PTG'nin "klasik 17.2" tarzı yerine IATA'nın daha yeni 2015/EASD/00/IATA_OffersAndOrdersMessage şemasını. Kök tag <ns2:IATA_AirShoppingRS> (namespace'li) — bu araç bunu getElementsByTagNameNS('*','IATA_AirShoppingRS') ile algılayıp otomatik olarak ayrı bir ayrıştırma yoluna (extractTkRoutes) yönlendiriyor. Aşağıdaki bilgi aynen çekiliyor ama tamamen farklı path'lerden:

Kavram	Farelogix (17.2)	TK (EASD)
Kök tag	AirShoppingRS	ns2:IATA_AirShoppingRS
Segment	FlightSegment (direkt)	PaxSegment → DatedMarketingSegment → DatedOperatingSegment/DatedOperatingLeg (3 katmanlı ID referansı)
Uçuş no	MarketingCarrier/FlightNumber	MarketingCarrierFlightNumberText
Havalimanı	AirportCode	IATA_LocationCode
Tarih/saat	ayrı Date + Time	birleşik AircraftScheduledDateTime (örn. 2025-02-10T09:05:00) — regex ile ayrıştırılıyor
Uçak tipi	Equipment/Name	DatedOperatingLeg/CarrierAircraftType/CarrierAircraftTypeCode
Journey (bizim "Flight")	Flight/SegmentReferences	PaxJourney/PaxSegmentRefID (PaxSegment üzerinden çözülüyor)
OD (yön)	FlightRef/@ODRef	OriginDest/PaxJourneyRefID listesi
Fiyat	tam sayı kuruş: 31719 → 317.19	ondalıklı, direkt: 131.02 — araç bunu ×100 yapıp iç sisteme uyduruyor
Kabin	her FareComponent'te ayrı	PriceClass/CabinType — tek yerde, journey/price-class eşlemesiyle (JourneyPriceClass) dağıtılıyor
Bagaj	PieceAllowance/TotalQuantity + ağırlık	WeightAllowance/MaximumWeightMeasure (adet kavramı yok, sadece ağırlık — 0 ise "dahil değil")
Yolcu	PassengerList/Passenger	PaxList/Pax (PaxID/PTC aynı mantık)
Owner (havayolu)	ShoppingResponseID/Owner	Offer/OwnerCode (direkt child) — yoksa ilk segmentin CarrierDesigCode'undan türetiliyor
Fare kuralları	Penalty/RuleMetadata (izin + ücret tutarı)	FareComponent/CancelRestrictions+ChangeRestrictions, JourneyStageCode'a göre (Prior To Departure / No Show / After Departure) — ücret tutarı yok, sadece AllowedModificationInd (true/false)

11. TK — OfferPriceRS ve "upsell" mantığı

TK'nın OfferPriceRS'i de aynı kök namespace mantığıyla algılanıyor (ns2:IATA_OfferPriceRS) ve tek bir <PricedOffer> döndürüyor — ama Farelogix'in aksine, bu tek `PricedOffer` genelde birden fazla alternatif fiyat/esneklik kademesi ("upsell") içeriyor: aynı uçuş için hem en ucuz (değiştirilemez/iade edilemez) hem daha pahalı ama tam esnek seçenekler aynı yanıtta birlikte geliyor. Tool bunları otomatik olarak ayrı paket kartları halinde gösteriyor — tıpkı normal bir arama sonucu gibi, sıralanıp karşılaştırılabiliyor.

12. TK — OfferPriceRQ (tam istek)

TK'nın gerçek çalışan bir isteğiyle doğrulanmış yapı — Farelogix'ten tamamen farklı, ve Ajet'in SOAP zarfından da (bölüm 16) farklı: kök <n1:IATA_OfferPriceRQ>, mesaj-seviyesi elemanlar (DistributionChain/PayloadAttributes/Request) n1: (message) namespace'inde, bunların altındaki her şey cns: (common types) namespace'inde:

<n1:IATA_OfferPriceRQ xmlns:n1="..." xmlns:cns="...">
  <n1:DistributionChain>
    <cns:DistributionChainLink>
      <cns:Ordinal>1</cns:Ordinal>
      <cns:OrgRole>Seller</cns:OrgRole>
      <cns:ParticipatingOrg><cns:Name>...</cns:Name><cns:OrgID>...</cns:OrgID></cns:ParticipatingOrg>
      <cns:SalesBranch><cns:SalesBranchID>...</cns:SalesBranchID></cns:SalesBranch>
    </cns:DistributionChainLink>
    <cns:DistributionChainLink>
      <cns:Ordinal>2</cns:Ordinal>
      <cns:OrgRole>Carrier</cns:OrgRole>
      <cns:ParticipatingOrg><cns:Name>Turkish Airlines</cns:Name><cns:OrgID>TK</cns:OrgID></cns:ParticipatingOrg>
    </cns:DistributionChainLink>
  </n1:DistributionChain>
  <n1:PayloadAttributes>
    <cns:CorrelationID>...</cns:CorrelationID>
    <cns:PrimaryLangID>EN</cns:PrimaryLangID>
    <cns:TrxID>...</cns:TrxID>
    <cns:VersionNumber>2023.3</cns:VersionNumber>
  </n1:PayloadAttributes>
  <n1:Request>
    <cns:PricedOffer>
      <cns:SelectedOfferList>
        <cns:SelectedOffer>
          <cns:OfferRefID>...</cns:OfferRefID>
          <cns:OwnerCode>TK</cns:OwnerCode>
          <cns:SelectedOfferItem>
            <cns:OfferItemRefID>...</cns:OfferItemRefID>
            <cns:PaxRefID>PAX_1</cns:PaxRefID>
          </cns:SelectedOfferItem>
        </cns:SelectedOffer>
      </cns:SelectedOfferList>
    </cns:PricedOffer>
  </n1:Request>
</n1:IATA_OfferPriceRQ>

Farklar (aynı kalanlar): kök element Offer değil SelectedOffer, ID alanları OfferID/OfferItemID değil OfferRefID/ OfferItemRefID (Ref son eki var), PaxRefID Farelogix'teki gibi tek bir PassengerRefs metninde boşlukla ayrılmış değil, her yolcu için ayrı bir element olarak tekrarlanıyor. Bu araç, RS'nin TK şeması olup olmadığını otomatik hatırlayıp "OfferPriceRQ Oluştur" butonuna bastığında doğru formatı üretiyor — elle değiştirmene gerek yok.

13. Pegasus — iki farklı NDC şeması

Pegasus'tan iki tamamen farklı RS örneği geldi — muhtemelen iki farklı ortam/versiyon. Araç ikisini de otomatik algılıyor, birbirine hiç karışmıyor.

13a. Yeni nesil (TK ile aynı EASD ailesi) — kök ns2:IATA_AirShoppingRS, bölüm 10'daki her şey geçerli, ama birkaç yerde TK'dan farklı:

Kavram	TK	Pegasus
Fiyat	OfferItem/Price/TotalAmount	her FareComponent'in kendi içinde ayrı Price/TotalAmount — toplam için hepsi toplanıyor
Kabin	PriceClass/CabinType	her FareComponent'in kendi içinde CabinType
Paket adı	PriceClass/Name okunabilir ("Eco Fly")	PriceClass/Name opak bir ID (base64 benzeri) — FareBasisCode ("UWEB/QC") ya da Code ("U") kullanılıyor
PriceClassRefID	Offer/JourneyOverview/JourneyPriceClass seviyesinde	yok — her FareComponent'in kendi PriceClassRefID'si kullanılıyor
Bagaj ağırlığı	MaximumWeightMeasure	TotalMaximumWeightMeasure
Bagaj bağlantısı	Offer/BaggageAllowanceRefID (direkt)	dolaylı: Offer/.../Service/ServiceDefinitionRefID → DataLists/ServiceDefinition/ServiceDefinitionAssociation/BaggageAllowanceRef → gerçek BaggageAllowanceID

13b. Eski nesil (Postman'dan alınan, IATA2017.2 SOAP) — kök düz AirShoppingRS (Farelogix ile aynı!), ama her elementte ns2: prefix'i var (sadece kökte değil). FlightSegment, Flight, PriceClass, PassengerList yapıları Farelogix ile birebir aynı; farklı olan sadece:

Kavram	Farelogix	Pegasus (eski)
Fiyat	Offer/TotalPrice/DetailCurrencyPrice/Total	OfferItem/TotalPriceDetail/TotalAmount/SimpleCurrencyPrice
OD eşleme	FlightRef/@ODRef (offer üzerinde)	OriginDestinationList/OriginDestination/FlightReferences (ayrı bir liste, Flight→OD ters eşleme)
Price class ref	FlightRef/@PriceClassRef (leg bazlı)	FlightsOverview/ItineraryPriceClassRef (offer bazlı, tek)
Yolcu fiyatı	OfferItem/FareDetail/PassengerRefs	OfferItem/Service/PassengerRefs — her yolcu için ayrı OfferItem, genelde aynı OfferItemID tekrarlanarak
Kabin / Bagaj	var	bu örnekte hiç yok

Bu ikinci varyantı ayırt etmek için tek güvenilir işaret: dokümanda SimpleCurrencyPrice tag'inin var olması — Farelogix bu tag'i hiç kullanmıyor.

14. Hitit Crane NDC — dördüncü bir varyant

Hitit Computer Services'in "Crane PAX" platformunu kullanan havayolları (VF/Hitit, Ajet dahil) da kök olarak IATA_AirShoppingRS kullanıyor (TK/Pegasus ile aynı aile) ama ara katman yok — DatedMarketingSegment/ DatedOperatingSegment hiç bulunmuyor, uçuş bilgisinin tamamı doğrudan PaxSegment'in içinde. Algılama işareti tam olarak bu: kök IATA_AirShoppingRS olduğu halde DatedMarketingSegment yoksa, Hitit varyantı demektir.

Kavram	TK/Pegasus (EASD)	Hitit Crane
Segment	PaxSegment → DatedMarketingSegment → DatedOperatingSegment (3 katman)	PaxSegment tek başına her şeyi taşıyor (MarketingCarrierInfo/OperatingCarrierInfo direkt içinde)
Journey→Segment	PaxJourney/PaxSegmentRefID → PaxSegment → DatedMarketingSegmentRefId (dolaylı)	PaxJourney/PaxSegmentRefID doğrudan PaxSegmentID'ye işaret ediyor
Fiyat/paket adı	PriceClass/Name (TK okunabilir, Pegasus opak ID)	PriceClass hiç yok — bundle ServiceDefinition varsa oradan ("FLEX"), yoksa FareComponent/FareTypeCode ("ECO") veya FareBasisCode'a düşülüyor
Fiyat yapısı	Pegasus: her FareComponent'in kendi Price'ı, toplanıyor	Farelogix'e yakın: OfferItem/Price/BaseAmount+Fee+Surcharge+TaxSummary+TotalAmount — direkt OfferItem'ın çocuğu
Yolcu paylaşımı	her yolcu için ayrı OfferItem	tek OfferItem'ın Service'i birden fazla PaxRefID taşıyabiliyor (örn. 2 yetişkin aynı fiyata, aynı OfferItem altında paylaşımlı)

Marka/paket isimleri (FLEX, ECOJET, PREMIUM): Bazı Hitit RS'lerinde de tıpkı Pegasus'ta olduğu gibi gerçek okunabilir marka adları, Offer'ın referans ettiği bir bundle ServiceDefinition'da saklı (Name "FLEX" gibi, ServiceBundle/ServiceDefinitionRefID listesiyle paketin içeriğini — bagaj, koltuk vb. — taşıyor). Bu mekanizma Pegasus ile birebir aynı olduğu için kod tekilleştirildi (buildServiceBundleData() — hem Pegasus hem Hitit extraction'ı aynı fonksiyonu paylaşıyor). Bundle bulunamazsa (RS'de böyle bir tanım yoksa) FareTypeCode/FareBasisCode'a düşülüyor (örn. "ECO").

15. Hitit/Ajet — JSON log formatı

Bazı ortamlarda RS, XML değil JSON olarak loglanıyor — ama içerik birebir aynı Hitit Crane şeması (bölüm 14), sadece .NET tarzı bir JSON serialization'ı: her XML tag'i bir JSON key'i olmuş, attribute+metin ikilileri {CurCode, Value} gibi iç içe objelere dönüşmüş, XSD "choice" grupları bir Item sarmalayıcısına (ServiceDefinitionAssociation.Item.BaggageAllowanceRefID gibi) çevrilmiş. Araç dosyanın { ile başlayıp başlamadığına bakarak bunu otomatik algılıyor ve DOM yerine düz JS objesi/array navigasyonu ile aynı iç veri modelini (segs/flights/groups/vb.) üretiyor — render katmanı hiç değişmiyor.

Kavram	Hitit XML	Hitit/Ajet JSON
Kök	IATA_AirShoppingRS	{"Items":[{...}]} — Items yoksa objenin kendisi kullanılıyor
Fiyat	OfferItem/Price/TotalAmount (attribute+metin)	OfferItem.Price.TotalAmount.{Value, CurCode}
Yolcu bağlantısı	OfferItem/Service/PaxRefID	OfferItem.FareDetail[].PaxRefID[] (segment bazlı tekrarlanan, birleştiriliyor)
Bagaj bağlantısı	Offer/.../Service/ServiceDefinitionRefID	OfferItem.Service[].ServiceAssociations.Item.ServiceDefinitionRefID
Bagaj kategorisi	TypeCode okunabilir metin ("Checked")	TypeCode sayısal enum — sadece 1 gözlemlendi, "Checked" olduğu varsayılıyor (kesin değil)

16. Ajet (VF) — OfferPriceRQ, Hitit Crane için tam SOAP zarfı

Ajet'in gerçek çalışan bir isteğiyle doğrulanmış yapı — TK'nin ("EASD") aksine iki önemli fark var: SelectedOffer bir SelectedOfferList sarmalı olmadan doğrudan PricedOffer'ın çocuğu, ve Ajet'in gateway'i sadece seçim bloğunu değil tam SOAP zarfını bekliyor (Party/ PayloadAttributes/DataLists/OfferPriceParameters dahil). Bu yüzden araç, yüklenen RS Hitit Crane şeması (XML ya da JSON — bölüm 14/15) olarak algılandığında "OfferPriceRQ Oluştur" ile TK'den ayrı bu formatı üretiyor.

<soapenv:Envelope xmlns:soapenv="..." xmlns:iata="...">
  <soapenv:Body>
    <IATA_OfferPriceRQ xmlns="...">
      <Party><Sender><TravelAgency>...</TravelAgency></Sender></Party>
      <PayloadAttributes><PrimaryLangID>EN</PrimaryLangID></PayloadAttributes>
      <Request>
        <DataLists><PaxList>...</PaxList></DataLists>
        <OfferPriceParameters><CurParameter><CurCode>TRY</CurCode></CurParameter></OfferPriceParameters>
        <PricedOffer>
          <SelectedOffer>
            <OfferRefID>...</OfferRefID>
            <OwnerCode>VF</OwnerCode>
            <SelectedOfferItem>
              <OfferItemRefID>...</OfferItemRefID>
              <PaxRefID>...</PaxRefID>
            </SelectedOfferItem>
          </SelectedOffer>
        </PricedOffer>
      </Request>
    </IATA_OfferPriceRQ>
  </soapenv:Body>
</soapenv:Envelope>

17. TK'nin kendi JSON log formatı — Hitit/Ajet'inkiyle karıştırılmamalı

TK'nin log sisteminden de (bölüm 15'teki Hitit/Ajet formatından tamamen ayrı) bir JSON varyantı geliyor. Şema aynı IATA "EASD" ailesi (bölüm 10) — DatedMarketingSegment, JourneyOverview/JourneyPriceClass, PriceClass/CabinType hepsi aynen orada — ama iki önemli fark var:

• Kök zarf: {"Error":null,"Response":{"DataLists":{...},"OffersGroup":{...}}, "Xmlns":null,...} — asıl içerik Response'un altında.
• Liste sarmalı: Hitit/Ajet'in JSON'ında her liste düz bir dizi iken ("PaxList":[...]), TK'de XML yapısı birebir korunuyor — her XxxList, içinde tekil Xxx anahtarlı bir obje ("PaxList":{"Pax":[...]}, "OffersGroup":{"CarrierOffers": {"Offer":[...]}} gibi).

Bu yüzden Hitit/Ajet JSON extractor'ı ile karıştırılamıyor — algılama, Response.DataLists.DatedMarketingSegmentList'in varlığına bakıyor (XML'deki TK-vs-Hitit ayrımıyla aynı mantık), bulunursa ayrı bir extractTkJsonRoutes() devreye giriyor ve TK'nin (Ajet'in SOAP zarfı değil) n1:IATA_OfferPriceRQ formatını (bölüm 12) üretiyor.

Alan	TK XML	TK JSON
Fiyat	OfferItem/Price/TotalAmount (attribute+metin)	OfferItem.Price.TotalAmount.{Text, CurCode} — ondalıklı, direkt (kuruş değil)
Havalimanı	IATA_LocationCode	IATALocationCode (alt çizgisiz)
Bagaj bağlantısı	BaggageAllowanceRefID (offer'ın direkt çocuğu)	Offer.BaggageAssociations[].BaggageAllowanceRefID — dolaylı ServiceDefinition araması gerekmiyor
Bagaj kategorisi	TaxonomyCode (13EC/0FA0) tercih edilir	TypeCode zaten okunabilir metin ("CarryOn"/"Checked") — taxonomy yok, direkt kullanılıyor
Kabin	FareComponent/CabinType varsa öncelikli, yoksa PriceClass	bu formatta FareComponent'de CabinType hiç yok (sadece RBD) — her zaman PriceClass seviyesinden