简介国内BSP电子客票培训教程聚焦旅客订座记录PNR面向航空票务代理、航空公司营业员及民航专业学员帮助理解订座系统核心逻辑。教程用14页PPT清晰拆解PNR的航段组、姓名组、联系组、证件组、出票时限组、票价组与备注组并给出SD、NM、CT、SSR FOID、TKTL等指令的标准格式和常见状态代码例如HK/DK表示已订座、RR表示已出票同时涵盖儿童票与婴儿票的独立PNR操作、封口与出票注意事项。资源包为1个PPT文件大小1.58MB内容精炼、结构完整适合培训教学或自学复训。已有246人学习下载可作为航空票务从业者提升操作准确率、规范处理PNR记录的实用参考资料。1. 机票后台的PNR是比订单更底层的真相在BSP电子客票链路中C端下单只是第一步。真正把航班、姓名、票价变成一张可结算客票的是系统里的旅客订座记录PNR。很多做电商订单的工程师习惯把订单ID当唯一键可在航司、代理和结算系统之间PNR才是那个贯穿始终的关联键。航班取消为什么APP里没提示退票为什么显示成功但钱没到这些现象十有八九是PNR状态与客票状态不一致造成的。下面直接从PNR的字段结构讲起梳理它在国内BSP电子客票业务里的创建、提取、出票联动和异常排查方式。票务系统开发、结算对账工程师以及刚接手航司接口的产品同学都能在这里找到直接能用的判断依据。2. 国内BSP电子客票里PNR到底存了什么为什么要先弄清楚PNR里面装了什么因为所有自动化操作——自动出票、自动退改、自动对账——本质上都是对PNR字段的读和写。字段边界不清后面每一条规则都可能在边缘情况下出错。2.1 PNR不是订单号BSP、ET和PNR的三角关系先拆清三个概念。BSPBilling and Settlement Plan开账与结算计划是国际航协IATA搭建的票款清算体系它管的是“代理人卖出的票怎么和航司结算”。电子客票ET是客票的数字化形态代替了原来的纸质票联。而PNRPassenger Name Record是旅客订座记录的缩写它记录了一次预订里几乎所有动态信息姓名、行程、联系信息、票价计算、出票状态等。这三者最容易混淆的地方在于一张客票不一定只对应一个PNR。比如旅客从北京经上海中转去广州两段可能分别在两个PNR里出票反过来一个PNR里五个人出行却可能因为支付方式不同拆出五张电子客票。所以做数据关联时不能用PNR当唯一的票务主键必须把PNR和ET票号绑定起来看。从数据流来看PNR诞生在订座阶段ET实现在出票阶段BSP则在整个开账周期里对票价、税费、代理手续费做结算。PNR是源头一旦源头的字段写错后面结算对账就全是脏数据。在实际生产系统中我见过太多订单系统只存“订单号关联PNR”等航司接口返回新PNR时不回写最终导致退票找不到原PNR。这个关联字段建议在订单表里设成唯一索引并且要求更新时带上航司返回的原始PNR编号。2.2 PNR的五大信息块从姓名到票价计算组一个典型的PNR由多组信息拼装而成。下面这个表是提取PNR时最常看到的字段组不同GDS和航信系统的命名会略有差异但字段含义基本一致信息块常见字段典型内容出错后果旅客信息NM、SSR证件姓名、证件号、常旅客号证件不符无法值机航段信息SS、SA航班号、日期、舱位、起降地舱位错误导致运价失效联系信息AP、CTCM手机号、邮箱航班变动通知不到出票信息TK/TL、票号出票时限、票号、航司Office号超时未出票PNR自动取消运价信息FC、FN/FQ票价计算、NUC、实收金额结算金额与系统不符这里面最值得开发关注的是运价信息。国内BSP电子客票的票价字段里保留了完整的fare calculation例如“CNY1050.00”或“Y60CN”这些值会被BSP结算系统抓取用于计算代理手续费和税金。如果PNR里的运价字段和订单实收不一致对账一定会出问题。另外航段信息里的舱位字段比仓位代码本身更重要它直接决定运价是否有效。解析PNR报文时我一贯的做法是先按固定分隔符切块再按字段名取value。比如下面这段Python代码就是把PNR报文里的票号尽量稳定地摘出来import re def extract_ticket_numbers(pnr_text): # 匹配BSP电子客票票号3位航司前缀 连字符 10位票号 pattern re.compile(r\b(\d{3})[- ]?(\d{10})\b) matches pattern.findall(pnr_text) # 把前缀和票号拼回标准格式 return [f{a}-{b} for a, b in matches]这段代码看着简单但实际解析时要注意两个点。第一部分PNR报文里票号和其它数字连在一起正则容易误匹配第二南航、东航的票号前缀不同784是南航781是东航而不能只按13位数字去猜。这个正则要求三位前缀必须存在否则宁可放过也不能误报。2.3 电子客票票号在PNR里怎么体现电子客票票号通常由13位数字组成前3位是航司结算前缀后10位是票号本身。在PNR中票号一般以ET、TKN或SSR TKNE形式存在。常见格式为999-1234567890其中999代表国航的IATA前缀连字符后的10位是票序号。这个票号会在出票成功后被回写到PNR中。判断是否已出票最简单的方法就是看PNR里有没有有效票号。注意部分PNR里会有多个票号比如联程机票拆成两张票时。这时不能取第一个就算完要按航段分别配对。后面第4章会专门讲出票回写联动。2.4 PNR与订单、客票的状态机PNR不是一成不变的静态记录。它的生命周期可以用一个状态机概括创建 - 已确认 - 已出票 - 已值机 - 已取消/已退票。每一状态变化都会在PNR里留下至少一条历史记录。订单状态和PNR状态是两套体系订单可以“已完成”但PNR可能还在“已出票”。在对账和售后场景里要以PNR状态为准。例如如果用户取消订单但PNR没有同步取消票号就不会释放最终影响后续改期。因此定一个定时任务把订单状态和PNR状态做比对能提前发现这类遗漏。比对的关键不是看两边是不是同一个状态而是看PNR里是否缺少对应票号。3. 用PNR指令在BSP环境里完成创建、修改与提取真正在终端上手工建PNR的人越来越少了但理解终端指令能帮你在接口排错时快速定位问题。接口报文有时表达不清晰回终端看一眼就知道问题出在哪个字段。3.1 最小指令集从提取到修改在字符终端里PNR的创建和修改有固定套路。这里以国内常见的航信终端指令为参照原则是“先建组再放航段最后加联系和出票时限”。一个最小的PNR创建过程可以这样看NM:张三/张 SS:CA123/Y/01NOV/PEK/SHA/0730/1000/0 AP:13800000000 TK:TL10/01NOV/PEK/001NM行定义姓名SS行定义航段AP行是联系手机号TK行是出票时限。别看这些字段简单任何一行格式错了PNR都可能建不进去。比如SS行里的航段状态码如果是“0”表示只订座不立即出票如果是“1”可能代表需要立即出票。做自动化时不能只看PAX人数还得看每个航段的状态码。提取PNR和修改PNR是高频操作RT:ABC123提取后可看到旅客名单、航段、票号等。如果只是修改联系方式可以在RT后直接输入AP:13900000000这个动作会更新原PNR的联系组保留原有航段和票号。下面这个表是常用指令和适用场景做定时任务时可以直接当参考用途指令示例说明提取PNRRT:ABC123标准提取返回完整PNR提取票号RT:ABC123/ET同时返回电子客票票号修改联系信息AP:13900000000覆盖原联系组查看历史ER:ABC123返回修改历史删除PNRXE:PNR释放订座一般需先取消票号3.2 用接口报文提取PNR的空铁组合现在的BSP电子客票业务多走API不再是人盯终端。常见做法是通过航信或GDS的PNR检索接口把PNR编号传进去返回一段结构化的PNR报文。解析的时候要按“姓名组-航段组-票号组”的顺序去拆不能只靠字符串片段。下面是一段模拟报文和解析思路PNR Name张三/张/Name SegmentCZ3101/Y/01NOV/PEK/CAN/Segment Ticket784-1234567890/Ticket /PNR如果有五个旅客、四段航程XML里会重复出现多个Name和Segment。解析时要用数组承接不能直接取第一个。常见错误是只解析了首要旅客就停止结果后续航段全部丢失。解决思路是在拿到响应后先按结构把“旅客列表”和“航段列表”拆开再按旅客维度组织成一个树形结构最后再给每个旅客匹配票号。3.3 参数设计PNR的提取深度与返回格式调用PNR接口时通常有三个参数需要重点调返回格式JSON还是XML。传统GDS偏XML新接口多支持JSON。机场值机系统对XML兼容性最好。是否返回票号有些接口默认不返回票号必须显式请求电子客票信息。历史记录层数默认返回最近一次修改记录做审计时要请求全量历史。这些参数写死在代码里等出问题时再排查会非常吃力。我一般会在配置中心把这几个字段做成可动态调整的配置项。下面这段Python代码模拟了带参数请求和第一个票号的提取import requests resp requests.post( https://api.example.com/pnr/query, json{pnr: ABC123, with_ticket: True, history: 0} ) data resp.json() # 取第一个旅客、第一段航程、对应的票号 ticket data[passengers][0][tickets][0][number]这里的逻辑是先取旅客数组的第一个元素再取该旅客下的第一个票号。适用于单个旅客单票号场景多旅客时必须遍历所有旅客和票号。3.4 常见返回码与排错路径PNR接口返回码因系统而异但有一组语义几乎通用HK表示成功UN表示座位不可用NE表示票号不存在HX表示航段被取消。遇到UN时不要急着重新创建PNR先查原PNR是否还有候补状态。遇到HX时要同时查航班是不是取消而不是直接退票。返回码含义推荐动作HK座位确认继续出票UN座位不可用换航班或候补HX航段取消先确认航班状态NE票号不存在查ET记录很多自动化系统把NE当成出票失败直接触发退款。但NE也有可能是票号还没回传过几分钟再看就有了。因此处理NE前最好加一个重试窗口避免误退款。4. PNR与出票、退票、改签的数据联动4.1 出票动作如何回写PNR当出票成功时PNR里会多出票号同时航段状态码从HK已订座变为RR或HS。不同状态码含义需要记清楚状态码英文含义中文解释下一动作HKHolding Confirmed已订座出票RRRequest Received已接收已值机UNUnable未确认换航班UCWaitlist候补等待确认XXCancelled已取消重新预订回到代码场景出票成功后需要把PNR里的票号回写进订单表。很多系统在出票后只更新了订单状态没把票号同步到PNR对应记录导致后续退改签时检索不到票号。这里建议用一个定时任务扫PNR报文把新出现的票号统一回填UPDATE booking_order SET ticket_no {ticket_no} WHERE pnr {pnr} AND ticket_no IS NULL;这个SQL的作用是只把还没有票号的订单补上票号避免覆盖已有数据。扫描频率不用太高每5分钟轮询一次就足够。4.2 退票和改签时PNR里的票联状态怎么变化退票并不是直接把PNR删掉。通常退票动作会保留PNR结构但票联状态被标记为“已退”或“OPEN FOR USE”。如果退的是联程票中的一段PNR会保留其他未退航段并重新计算运价。这时候如果只看航段状态码可能会误判整张票已失效。改签的逻辑则相反。改签会新增一个航段组同时原航段状态变为“取消”票号不变但航段与票号的关联会被重排。简而言之票号是认人的航段是会变的。4.3 对账逻辑PNR结算字段与BSP结算单BSP结算不是按订单金额而是按PNR中的运价字段批处理。因此订单里的实收金额必须与PNR的FCfare calculation字段一致否则结算单会出现差额。对账SQL常这样写SELECT p.pnr, p.ticket_no, p.total_amount, b.total AS bsp_amount FROM pnr_record p JOIN bsp_settlement b ON p.ticket_no b.ticket_no WHERE p.total_amount b.total;如果查出大量差异先查的不是钱而是PNR里的运价字段有没有被重新计算。常见坑是改签后运价变了PNR里票号没变结算却延续旧运价。这类差异往往不是“偷钱”而是运价过期。4.4 退改签后的PNR数据一致性验证退改签操作后PNR里旧航段会出现状态变更新航段出现新记录。验证动作是重新提取一次PNR比较航段数量、票号数量和运价字段。写成一个检查脚本比较变更前后是否一致。例如Python脚本对比JSON结构def compare_pnr_snapshot(old, new): fields [ticket_no, segments, fare_computation] for f in fields: if old[f] ! new[f]: log_diff(f, old[f], new[f])这段代码的意义在于让系统在改签完成后自动检查关键字段是否被正确更新。如果出现差异不必等旅客投诉才察觉。5. 从PNR状态排查票务异常的3个常用技巧5.1 用历史记录看“谁改了舱位”当发现PNR被改舱但系统没记录操作人时查看历史记录是最快的定位方式。指令或接口里的“history”字段会返回修改时间、操作人编号、修改前后值。我通常会先拉最近10条历史找到舱位字段的变化点。ER:ABC123返回的记录里能看到“B-Y”之类的变更轨迹比翻业务日志更直接。5.2 用票号反查PNR旅客只知道票号、不知道PNR时可以通过电子客票记录反查。接口里传入票号返回PNR编号。这个操作在退票场景中很常用因为用户提供的订单号往往和系统PNR对不上。注意票号要去掉连字符再传。curl https://api.example.com/et/query \ -d {ticket_number:7841234567890}返回结果包含PNR、航段、运价字段。有了这些再走正常退票流程。5.3 看“未出票”的PNR一共停了多久所谓“未出票”是指PNR已创建但还没有票号。系统会给出票时限字段超过时限而未出票PNR自动取消。排查这类问题时我会用查询脚本扫出所有“HK状态且无票号”的PNR然后计算创建时间到当前时间的时间差超过预设阈值就告警。SELECT pnr, create_time, ticket_no FROM pnr_record WHERE status HK AND ticket_no IS NULL AND create_time NOW() - INTERVAL 20 MINUTE;这个查询非常实用。20分钟的阈值可以根据业务调整但通常来说BSP出票不需要超过20分钟。超过这个时间优先检查支付回调而不是直接改PNR。本文还有配套的精品资源点击获取 BSP电子客票中的PNR：从字段解析到异常排查
简介国内BSP电子客票培训教程聚焦旅客订座记录PNR面向航空票务代理、航空公司营业员及民航专业学员帮助理解订座系统核心逻辑。教程用14页PPT清晰拆解PNR的航段组、姓名组、联系组、证件组、出票时限组、票价组与备注组并给出SD、NM、CT、SSR FOID、TKTL等指令的标准格式和常见状态代码例如HK/DK表示已订座、RR表示已出票同时涵盖儿童票与婴儿票的独立PNR操作、封口与出票注意事项。资源包为1个PPT文件大小1.58MB内容精炼、结构完整适合培训教学或自学复训。已有246人学习下载可作为航空票务从业者提升操作准确率、规范处理PNR记录的实用参考资料。1. 机票后台的PNR是比订单更底层的真相在BSP电子客票链路中C端下单只是第一步。真正把航班、姓名、票价变成一张可结算客票的是系统里的旅客订座记录PNR。很多做电商订单的工程师习惯把订单ID当唯一键可在航司、代理和结算系统之间PNR才是那个贯穿始终的关联键。航班取消为什么APP里没提示退票为什么显示成功但钱没到这些现象十有八九是PNR状态与客票状态不一致造成的。下面直接从PNR的字段结构讲起梳理它在国内BSP电子客票业务里的创建、提取、出票联动和异常排查方式。票务系统开发、结算对账工程师以及刚接手航司接口的产品同学都能在这里找到直接能用的判断依据。2. 国内BSP电子客票里PNR到底存了什么为什么要先弄清楚PNR里面装了什么因为所有自动化操作——自动出票、自动退改、自动对账——本质上都是对PNR字段的读和写。字段边界不清后面每一条规则都可能在边缘情况下出错。2.1 PNR不是订单号BSP、ET和PNR的三角关系先拆清三个概念。BSPBilling and Settlement Plan开账与结算计划是国际航协IATA搭建的票款清算体系它管的是“代理人卖出的票怎么和航司结算”。电子客票ET是客票的数字化形态代替了原来的纸质票联。而PNRPassenger Name Record是旅客订座记录的缩写它记录了一次预订里几乎所有动态信息姓名、行程、联系信息、票价计算、出票状态等。这三者最容易混淆的地方在于一张客票不一定只对应一个PNR。比如旅客从北京经上海中转去广州两段可能分别在两个PNR里出票反过来一个PNR里五个人出行却可能因为支付方式不同拆出五张电子客票。所以做数据关联时不能用PNR当唯一的票务主键必须把PNR和ET票号绑定起来看。从数据流来看PNR诞生在订座阶段ET实现在出票阶段BSP则在整个开账周期里对票价、税费、代理手续费做结算。PNR是源头一旦源头的字段写错后面结算对账就全是脏数据。在实际生产系统中我见过太多订单系统只存“订单号关联PNR”等航司接口返回新PNR时不回写最终导致退票找不到原PNR。这个关联字段建议在订单表里设成唯一索引并且要求更新时带上航司返回的原始PNR编号。2.2 PNR的五大信息块从姓名到票价计算组一个典型的PNR由多组信息拼装而成。下面这个表是提取PNR时最常看到的字段组不同GDS和航信系统的命名会略有差异但字段含义基本一致信息块常见字段典型内容出错后果旅客信息NM、SSR证件姓名、证件号、常旅客号证件不符无法值机航段信息SS、SA航班号、日期、舱位、起降地舱位错误导致运价失效联系信息AP、CTCM手机号、邮箱航班变动通知不到出票信息TK/TL、票号出票时限、票号、航司Office号超时未出票PNR自动取消运价信息FC、FN/FQ票价计算、NUC、实收金额结算金额与系统不符这里面最值得开发关注的是运价信息。国内BSP电子客票的票价字段里保留了完整的fare calculation例如“CNY1050.00”或“Y60CN”这些值会被BSP结算系统抓取用于计算代理手续费和税金。如果PNR里的运价字段和订单实收不一致对账一定会出问题。另外航段信息里的舱位字段比仓位代码本身更重要它直接决定运价是否有效。解析PNR报文时我一贯的做法是先按固定分隔符切块再按字段名取value。比如下面这段Python代码就是把PNR报文里的票号尽量稳定地摘出来import re def extract_ticket_numbers(pnr_text): # 匹配BSP电子客票票号3位航司前缀 连字符 10位票号 pattern re.compile(r\b(\d{3})[- ]?(\d{10})\b) matches pattern.findall(pnr_text) # 把前缀和票号拼回标准格式 return [f{a}-{b} for a, b in matches]这段代码看着简单但实际解析时要注意两个点。第一部分PNR报文里票号和其它数字连在一起正则容易误匹配第二南航、东航的票号前缀不同784是南航781是东航而不能只按13位数字去猜。这个正则要求三位前缀必须存在否则宁可放过也不能误报。2.3 电子客票票号在PNR里怎么体现电子客票票号通常由13位数字组成前3位是航司结算前缀后10位是票号本身。在PNR中票号一般以ET、TKN或SSR TKNE形式存在。常见格式为999-1234567890其中999代表国航的IATA前缀连字符后的10位是票序号。这个票号会在出票成功后被回写到PNR中。判断是否已出票最简单的方法就是看PNR里有没有有效票号。注意部分PNR里会有多个票号比如联程机票拆成两张票时。这时不能取第一个就算完要按航段分别配对。后面第4章会专门讲出票回写联动。2.4 PNR与订单、客票的状态机PNR不是一成不变的静态记录。它的生命周期可以用一个状态机概括创建 - 已确认 - 已出票 - 已值机 - 已取消/已退票。每一状态变化都会在PNR里留下至少一条历史记录。订单状态和PNR状态是两套体系订单可以“已完成”但PNR可能还在“已出票”。在对账和售后场景里要以PNR状态为准。例如如果用户取消订单但PNR没有同步取消票号就不会释放最终影响后续改期。因此定一个定时任务把订单状态和PNR状态做比对能提前发现这类遗漏。比对的关键不是看两边是不是同一个状态而是看PNR里是否缺少对应票号。3. 用PNR指令在BSP环境里完成创建、修改与提取真正在终端上手工建PNR的人越来越少了但理解终端指令能帮你在接口排错时快速定位问题。接口报文有时表达不清晰回终端看一眼就知道问题出在哪个字段。3.1 最小指令集从提取到修改在字符终端里PNR的创建和修改有固定套路。这里以国内常见的航信终端指令为参照原则是“先建组再放航段最后加联系和出票时限”。一个最小的PNR创建过程可以这样看NM:张三/张 SS:CA123/Y/01NOV/PEK/SHA/0730/1000/0 AP:13800000000 TK:TL10/01NOV/PEK/001NM行定义姓名SS行定义航段AP行是联系手机号TK行是出票时限。别看这些字段简单任何一行格式错了PNR都可能建不进去。比如SS行里的航段状态码如果是“0”表示只订座不立即出票如果是“1”可能代表需要立即出票。做自动化时不能只看PAX人数还得看每个航段的状态码。提取PNR和修改PNR是高频操作RT:ABC123提取后可看到旅客名单、航段、票号等。如果只是修改联系方式可以在RT后直接输入AP:13900000000这个动作会更新原PNR的联系组保留原有航段和票号。下面这个表是常用指令和适用场景做定时任务时可以直接当参考用途指令示例说明提取PNRRT:ABC123标准提取返回完整PNR提取票号RT:ABC123/ET同时返回电子客票票号修改联系信息AP:13900000000覆盖原联系组查看历史ER:ABC123返回修改历史删除PNRXE:PNR释放订座一般需先取消票号3.2 用接口报文提取PNR的空铁组合现在的BSP电子客票业务多走API不再是人盯终端。常见做法是通过航信或GDS的PNR检索接口把PNR编号传进去返回一段结构化的PNR报文。解析的时候要按“姓名组-航段组-票号组”的顺序去拆不能只靠字符串片段。下面是一段模拟报文和解析思路PNR Name张三/张/Name SegmentCZ3101/Y/01NOV/PEK/CAN/Segment Ticket784-1234567890/Ticket /PNR如果有五个旅客、四段航程XML里会重复出现多个Name和Segment。解析时要用数组承接不能直接取第一个。常见错误是只解析了首要旅客就停止结果后续航段全部丢失。解决思路是在拿到响应后先按结构把“旅客列表”和“航段列表”拆开再按旅客维度组织成一个树形结构最后再给每个旅客匹配票号。3.3 参数设计PNR的提取深度与返回格式调用PNR接口时通常有三个参数需要重点调返回格式JSON还是XML。传统GDS偏XML新接口多支持JSON。机场值机系统对XML兼容性最好。是否返回票号有些接口默认不返回票号必须显式请求电子客票信息。历史记录层数默认返回最近一次修改记录做审计时要请求全量历史。这些参数写死在代码里等出问题时再排查会非常吃力。我一般会在配置中心把这几个字段做成可动态调整的配置项。下面这段Python代码模拟了带参数请求和第一个票号的提取import requests resp requests.post( https://api.example.com/pnr/query, json{pnr: ABC123, with_ticket: True, history: 0} ) data resp.json() # 取第一个旅客、第一段航程、对应的票号 ticket data[passengers][0][tickets][0][number]这里的逻辑是先取旅客数组的第一个元素再取该旅客下的第一个票号。适用于单个旅客单票号场景多旅客时必须遍历所有旅客和票号。3.4 常见返回码与排错路径PNR接口返回码因系统而异但有一组语义几乎通用HK表示成功UN表示座位不可用NE表示票号不存在HX表示航段被取消。遇到UN时不要急着重新创建PNR先查原PNR是否还有候补状态。遇到HX时要同时查航班是不是取消而不是直接退票。返回码含义推荐动作HK座位确认继续出票UN座位不可用换航班或候补HX航段取消先确认航班状态NE票号不存在查ET记录很多自动化系统把NE当成出票失败直接触发退款。但NE也有可能是票号还没回传过几分钟再看就有了。因此处理NE前最好加一个重试窗口避免误退款。4. PNR与出票、退票、改签的数据联动4.1 出票动作如何回写PNR当出票成功时PNR里会多出票号同时航段状态码从HK已订座变为RR或HS。不同状态码含义需要记清楚状态码英文含义中文解释下一动作HKHolding Confirmed已订座出票RRRequest Received已接收已值机UNUnable未确认换航班UCWaitlist候补等待确认XXCancelled已取消重新预订回到代码场景出票成功后需要把PNR里的票号回写进订单表。很多系统在出票后只更新了订单状态没把票号同步到PNR对应记录导致后续退改签时检索不到票号。这里建议用一个定时任务扫PNR报文把新出现的票号统一回填UPDATE booking_order SET ticket_no {ticket_no} WHERE pnr {pnr} AND ticket_no IS NULL;这个SQL的作用是只把还没有票号的订单补上票号避免覆盖已有数据。扫描频率不用太高每5分钟轮询一次就足够。4.2 退票和改签时PNR里的票联状态怎么变化退票并不是直接把PNR删掉。通常退票动作会保留PNR结构但票联状态被标记为“已退”或“OPEN FOR USE”。如果退的是联程票中的一段PNR会保留其他未退航段并重新计算运价。这时候如果只看航段状态码可能会误判整张票已失效。改签的逻辑则相反。改签会新增一个航段组同时原航段状态变为“取消”票号不变但航段与票号的关联会被重排。简而言之票号是认人的航段是会变的。4.3 对账逻辑PNR结算字段与BSP结算单BSP结算不是按订单金额而是按PNR中的运价字段批处理。因此订单里的实收金额必须与PNR的FCfare calculation字段一致否则结算单会出现差额。对账SQL常这样写SELECT p.pnr, p.ticket_no, p.total_amount, b.total AS bsp_amount FROM pnr_record p JOIN bsp_settlement b ON p.ticket_no b.ticket_no WHERE p.total_amount b.total;如果查出大量差异先查的不是钱而是PNR里的运价字段有没有被重新计算。常见坑是改签后运价变了PNR里票号没变结算却延续旧运价。这类差异往往不是“偷钱”而是运价过期。4.4 退改签后的PNR数据一致性验证退改签操作后PNR里旧航段会出现状态变更新航段出现新记录。验证动作是重新提取一次PNR比较航段数量、票号数量和运价字段。写成一个检查脚本比较变更前后是否一致。例如Python脚本对比JSON结构def compare_pnr_snapshot(old, new): fields [ticket_no, segments, fare_computation] for f in fields: if old[f] ! new[f]: log_diff(f, old[f], new[f])这段代码的意义在于让系统在改签完成后自动检查关键字段是否被正确更新。如果出现差异不必等旅客投诉才察觉。5. 从PNR状态排查票务异常的3个常用技巧5.1 用历史记录看“谁改了舱位”当发现PNR被改舱但系统没记录操作人时查看历史记录是最快的定位方式。指令或接口里的“history”字段会返回修改时间、操作人编号、修改前后值。我通常会先拉最近10条历史找到舱位字段的变化点。ER:ABC123返回的记录里能看到“B-Y”之类的变更轨迹比翻业务日志更直接。5.2 用票号反查PNR旅客只知道票号、不知道PNR时可以通过电子客票记录反查。接口里传入票号返回PNR编号。这个操作在退票场景中很常用因为用户提供的订单号往往和系统PNR对不上。注意票号要去掉连字符再传。curl https://api.example.com/et/query \ -d {ticket_number:7841234567890}返回结果包含PNR、航段、运价字段。有了这些再走正常退票流程。5.3 看“未出票”的PNR一共停了多久所谓“未出票”是指PNR已创建但还没有票号。系统会给出票时限字段超过时限而未出票PNR自动取消。排查这类问题时我会用查询脚本扫出所有“HK状态且无票号”的PNR然后计算创建时间到当前时间的时间差超过预设阈值就告警。SELECT pnr, create_time, ticket_no FROM pnr_record WHERE status HK AND ticket_no IS NULL AND create_time NOW() - INTERVAL 20 MINUTE;这个查询非常实用。20分钟的阈值可以根据业务调整但通常来说BSP出票不需要超过20分钟。超过这个时间优先检查支付回调而不是直接改PNR。本文还有配套的精品资源点击获取