对面还在传那个老字段，我方这边已经把它标成待停用。信息科的值守员把最近一周的记录按来源列了一遍，还剩 6 条，全部来自同一家渠道。版本升级看着是我方点一下的事，票务系统这一头一动，对面的售票系统就得跟着改，这类残留字段最容易在升级当天出事，也最容易在事后各说一套。带班的把那张按来源列好的表复印一份，压在值班台的玻璃板下。

老字段留一侧，先把时限算清

字段兼容要有明面上的日子，不能靠谁嗓门大，版本升级里吵得最久的就是这一条。我们的口径是：从新版本对外启用之日起算，老字段保留期不少于 2 个版本周期。短于 2 个周期就把老字段砍掉，等于逼对面在我们的日历里赶工。保留期内，每一次仍在传老字段的调用单独记一条，每周汇总一次发给对接方。汇总发出去不是留证据，是让渠道在排改造队列时，把自己那一条往前挪。

停用的日子由我方定，依据要摆在桌面上：这条老字段还剩几家在传、传得多不多、对面改完要几天，这三件事说清，停用时点就站得住。日子定了以后，停用日须提前 15 日书面告知，函件或者邮件都行，落到纸面才算数。到期之后，老字段的调用不再兼容，一律返回明确错误码。悄悄把数据吞掉最糟，对面只看见少了单，看不见原因，第二天才追过来。告知函我方自己也得归档一份，别只存在对接人的邮箱里。

票务系统定停用日之前，先查那张周表

现场能当场做的检查动作，是调最近一周仍在传老字段的调用条数，按来源列一遍，再对每一家问一句：你们的改造排在哪天。比出来的判断很直接。来源只剩一家、条数一周比一周少，版本升级照常推进，停用日不挪。来源散在好几家、条数不见往下掉，就把停用日往后压一个版本周期，同时把周汇总再发一次，字段兼容的说法保持不变。

对面还在传老字段，我方怎么先知道？靠两条线。一条是前面那张周表，另一条是自家窗口和闸机的挂单表：售票系统的单据进到票务系统里，字段对不上就挂在待处理那一栏，第二天一早对着表点名，比等游客在闸机口举着手机问快得多。挂单表上还看得出是哪一家渠道送来的，来源一栏直接指到对接人，省掉一轮到处打听。

并传一段时间，还是到点直接砍

两条路各走一遍。第一条，新老字段并传一段时间，对面按自己的节奏切，我方每周看条数有没有往下掉，代价是票务系统要同时认两套写法，版本升级的测试得多跑一轮。第二条，到点直接砍，界面干净，代价藏在渠道里：只要还有一家没改完，那家渠道当天的售票系统就送不进单，窗口排队、闸机口劝返，全压在上线头一天。头一天堵在窗口前的那批人，后面几天都在替这次升级补解释。

只有在老字段属于结算那一段的时候，保留期要拉长：结算类字段停用延长一倍保留期，以财务对账的需要为准。财务要的是一条能往回追的记录线，这条线断在版本升级当天，后面查差异要多花几天，还得反过来请对面补送记录。