近日听闻上海地区的两家主要的航空公司要在某些共飞航线上进行代码共享。作为存在竞争的两家航空公司进行代码共享合作，有些令人感到意外。猜测大约最主要的目的是在航班时刻上进行互补，比如在某航线上东方航空的航班是上午的、而上海航空的航班是晚上的，在这条航线上进行代码共享，对于双方来说，都可以达到增加航班密度、使原有的竞争对手变成合作伙伴等代码共享的最主要的目的。当然，上述只是猜测，航空公司的合作是否有其他意图，不得而知。
当今国际航空界的各种战略合作形式中，最流行也最成功的无疑就是代码共享(CodeShare)。首先，当今世界没有一家航空公司自身的航线网能覆盖全球。而代码共享则可以使航空公司利用合作伙伴现成的航线、飞机，绕过国家间市场准入的限制，使自身的航线结构快速全球化。第二，航空业是一种资本密集型的高风险行业，在一些对盈利并没有很大把握的航空市场上，利用代码共享的安排，航空公司可能既满足了航线扩张的需要，又不用投入巨额资金，这不失为一种一举两得的好办法。第三，即使是对飞的航空市场上，代码共享也可使航空公司在不增加新的运力的情况下，增加航班班次，提高航线质量，降低单位营运成本，提高市场占有率并使原有的竞争对手变成合作伙伴，优化经营环境。第四，代码共享可以利用旅客越来越喜欢认同某一航空公司，并参加其常客奖励计划的趋势，吸引旅客。[本段文字摘自网络]
正是由于代码共享有上述诸多的好处，使得全球各航空公司对于代码共享这种合作模式趋之若鹜，而随着航空公司对代码共享业务需求的不断复杂化，航空公司要求其IT系统也能随之有所创新和发展，以求很好地支持其代码共享业务的发展。这些IT系统涉及到订座系统、离港系统、结算系统和常旅客系统等航空公司核心业务系统。
这里对代码共享座位控制的三种IT技术解决方案进行阐述。阐述之前，先对几个概念加以说明。参与代码共享的两方航空公司一个叫做承运方(OC，Operating Carrier)，一个叫做市场方(MC，Marketing Carrier)，顾名思义，OC是指实际承运的航空公司，而MC是指有航班号但没有实际的飞机进行运输的一方航空公司。
1. 包座方式
航空公司之间最初的代码共享合作模式，叫做包座(Block Space)，其运作模式为：OC方将一定数量的座位包给MC进行销售。例如，OC1234航班和MC1234航班进行BlockSpace方式的代码共享，OC控制人员在OC1234航班上锁定40个座位，而MC的控制人员则建立一个共有40个座位的航班MC1234进行销售。
观察现在国内航班控制系统中的RO数据(Read Out，航班销售情况数据)。先看一下某一个OC航班某天的RO数据，部分截取如下：
SEG CLS BKD GRS BLK WL LSV LSS LT SMT IND
PEKSHA F 0 0 0 0 - - - EAK
A 0 0 0 0 3 3 - EAK
Y 20 0 20 0 - - - EAK
注意到，BLK一列的Y舱数为20，表明该航班上的Y舱锁定了20个座位。锁定就意味着这20个座位是不能销售的。
再观察该OC对应的MC的该天的RO数据，部分截取如下：
C LEG AV OPN MAX CAP T/B GT GRO GRS BLK LT LSS PT AT CT SMT IND
Y
PEK AS 16 20 20 4 0 0 0 0 0 1 0 0 1
SEG CLS BKD GRS BLK WL LSV LSS LT SMT IND
PEKSHA Y 4 0 0 0 - - - K
可以看到，该航班的布局只有Y舱，且最大可利用座位数(CAP值)为20个座位。这里的20个座位无疑就是从对应的OC上“包座”得来的。
不难看出，这种代码共享方式对于航班控制系统来说，不需要增加新的功能即可生成相应的两个航班。航班信息可遵循相关标准通过OAG发布至各GDS的系统。对于离港系统而言，要求离港系统能建立代码共享航班信息，但在接收旅客时，调用的座位图都是OC航班的座位图，以保证座位分配的正确性。如果OC和MC两家航空公司使用不同的离港系统(如FM在SHA用的是航信离港、而MU用的是MU自己的离港系统)，则要求OC航班和MC航班都必需到OC航班所使用的离港系统平台下去办理Check-In。
从航班控制的角度来说，由于是两个航班分别进行销售，分别由OC和MC的控制人员进行控制，但在航班接近起飞时，如果MC由于销售方面没有将20个包座售完，而OC此时有能力销售更多的座位，则需要控制人员手工调整航班座位，将20个座位中的一部分归还给OC进行销售，这种控制方式，要求航空公司的航班控制人员对于参与代码共享的航班进行随时监控，以便MC及时归还座位给OC。
这里需要补充说明的是，包座方式又分为硬包座(Hard Block)和软包座(Soft Block)两种模式。这两种方式的区别在于：软包座方式下MC方在一定时候可以将包座归还OC方而只支付已经实际发生销售的座位的票价给OC方;硬包座方式下MC方需支付所包座的所有座位的票价给OC而不论MC方的销售情况如何。
2. 自由销售模式
自由销售(FreeSale)模式是在Block Space方式的基础发展起来的。其初衷是为了减轻MC的控制人员对MC航班控制的手工劳动，减少MC控制人员因控制不当或不及时而导致的收益损失。
从业务的需要看，包座是一种不得已而为之的模式，如果MC能够直接从OC实时取得座位，那么就很好地解决了包座模式带来的控制问题。再进一步的需求是：既然MC无需对MCxxxx这个航班进行任何控制，那么是否也可以不去建立这个航班呢?
在这种情况下，基于SMAP(Seat Mapping)理念的FreeSale模式逐渐浮出水面。SMAP的核心是MC和OC共用一个IV(Inventory)，这样保证了MC和OC能够自由销售。
但SMAP的功能建立起来后，MC确实也无需再单独额外建立MCxxxx航班的T-Card(航班基础信息)。只要OC航班在自己的T-Card里面根据商务协议通过T6项设定MC的航班号即可，关于T6项的定义，可参考TravelSky的相关技术资料。
另外一个问题是，OC和MC作为不同的相互独立的两个航空公司，其对舱位等级的定义也许是不同的。例如，上海航空公司的H舱为90%票价舱，而东方航空公司的H舱为80%票价舱、B舱为90%票价舱。为此，需要定义OC和MC的舱位对应关系，使得MC在销售一个n%票价舱位等级座位时OC航班减少一个相应票价舱位等级的座位数。
舱位对应关系表例如：
NBR CLASS MAPPING RELATIONSHIP
1 OPER: A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
MKT: A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
2 OPER: Y H K L M T
MKT: Y B E H L M
第1号对应关系表为系统缺省的对应关系表。而2号表表明了OC的H舱和MC的B舱对应。
在OC设定了T-Card和舱位对应关系表之后，Availability display和Booking即可正常进行。而其OAG发布、离港等流程和Block Space方式一致。
由于上述提到的SMAP技术的核心是建立在OC和MC都在同一个Host系统中的前提下的，例如，当前国内9家航空公司以及N8、NX均适用TravelSky的航班控制系统，因此这些航空公司之间的代码共享都可以适用上述描述的代码共享方式。
对于OC为TravelSky Host而MC为其它系统Host的航空公司，例如MU和AA之间的代码共享，也可以采用FreeSale方式，比如MU583/PVGLAX和AA7951进行共享，目前已经是采用FreeSale方式，这种方式要求两个host系统间利用IATA标准报文进行座位预订的确认和反馈，因而显得更为复杂一些。
对于在指用不同Host系统的航空公司之间进行FreeSale代码共享时，OC和MC首先需要确定对应的航班号以及舱位对应关系，并发布SSIM文件。另外还需要设定销售配额(Quota Limit Number)，通常为F/C/J/Y 2/2/2/4。由于牵涉到两个系统，引入Guaranteed Sale机制，即OC应当处理相关Queue来保证销售的顺利。除此之外，在两个系统或Host和GDS系统发生舱位状态不匹配时，OC所在Host系统会拍发AVS进行修正。
3. 航空公司内部代码共享
上述1/2两种模式的代码共享都指的是航空公司之间的代码共享。那么利用发散性思维不难想到：一个航空公司的一个航班和另外一个航班能否进行代码共享呢?也就是说，OC和MC航班都是一家航空公司的航班，例如MU1583和MU583进行“代码共享”，即MU1583为MC而MU583为OC。
为什么要这么做?这么做有什么意义?下面来实际看一个例子。
以黑龙江省的省会哈尔滨为例。作为东北老工业基地，在中央复兴东北的号召下，哈尔滨希望能有一条国际航线直达美国LA，这对于招商引资无疑会有积极的促进作用。因为对于旅客来说，只需在HRB办理相关手续即可到LA，而在没有这条国际航线开通之前，旅客只能乘坐国内航班到PEK或者PVG转国际航班，在中转点手续烦琐、还要带行李，十分不便。
在这种情况下，HRB和国内某家具有飞往LA航班的航空公司协商，要求其开通HRBLAX的直达国际航班，这家航空公司比如说东航、国航均有可能。
对于航空公司来说，要开通一条新航线牵涉到许多问题，比如航权谈判、客源能否得到保障、机场地面保障、海关、边防等。对于HRBLAX这条航线来说，客源是航空公司考虑的首要问题，因为根据市场统计数据，HRBLAX之间并没有充足的客源，如果航空公司开通这条直达航线无疑是要亏本的。
于是，观察原有中转联程，以PVG中转为例，OC1234执行HRBPVG，OC5678执行PVGLAX，旅客通过在PVG换飞机达到飞往LAX的目的。此时，如果有MC9898分别和OC1234和OC5678进行代码共享，则可以认为MC9898从HRB直飞LAX，注意这里的OC和MC是同一家航空公司，而MC9898既然是原有中转联程产品的替代，那么客源问题就不存在了。
在解决了HRB的海关、行李等问题之后，通过在PVG一点提供具有针对性的地面服务，则可以达到旅客直接在HRB出关后在PVG稍做停留换飞机后直接飞往LAX的目的，这样看起来MC9898就是HRBLAX的一个直达国际航班。
由于这里OC和MC是同一家航空公司，必然在同一个host系统里，因此这种共享模式也是基于SMAP理念设计的。即在OC1234和OC5678的T-Card中分别设定MC9898为其共享航班(T6项)，并分别设定舱位对应关系，这样在Availability display时就出现了HRB到LAX的直达航班MC9898，可以进行正常的Booking，在MC9898上订一个座位，则同时在OC1234和OC5678上减一个座位。
对于离港系统而言，需要实现OC1234和OC5678的Through Check-In(联程值机)，在始发站给旅客两张登机牌，分别用于在始发站和中转站登机。
当然，由于这种代码共享模式在国内乃至国际都是一个新鲜事物，还有许多地方需要完善，例如：控制问题，由于国内航空公司的国内航班OC1234和国际航班OC5678分别由不同的人员控制，因此控制MC9898的控制人员需要不断和两个OC的控制人员协商，以便正确的进行航班座位销售，以防止座位虚耗或贱卖。另外，这种航班在OAG的发布和在各GDS销售中由于标准欠缺还有一些问题亟待解决。
不管是那种方式的代码共享，其目的无非是扩大航线网络、增加航班密度从而提高航空公司知名度和获得相应的收益，而航空公司内部代码共享模式还可以对航空中转枢纽港的建设有较大的促进作用。上述的几种代码共享方式已经在国内各家航空公司逐步使用。
（本文仅代表作者观点，中国民用航空网保持中立。）
