第一次在 S/4HANA 里点 XD01 的人大概都有过一瞬间的失神屏幕没有跳进熟悉的地址/通讯/销售三个页签而是弹出一个叫业务伙伴维护的界面左上角还挂着一个组织按钮右边一排角色标签。很多做了十来年 FI/MM 的顾问第一反应是我是不是点错事务码了。没错你没点错只是客户主数据和供应商主数据在 SAP 里换了一层皮——业务伙伴也就是 BP成了这两类主数据唯一的前台入口。这篇内容就是把sap 业务伙伴维护这件事从界面往下挖到底BP 的基础视图到底分了哪几块、一般数据和公司代码数据各管什么、角色和账户组怎么配合决定哪些字段必输以及从零创建一个新的客户或供应商时前台该按什么顺序点、配置侧要先对齐哪几项。适合正在做 S/4HANA 主数据迁移的实施顾问、需要给业务写操作手册的关键用户以及被BP 建好了却开不了销售订单这类问题卡住的运维同学。看完你应该能自己判断一个 BP 到底缺哪块数据才导致下游单据跑不起来。1. BP 接手客户/供应商主数据后前后台的数据链路变成了什么1.1 一个人挂着三副面孔BUT000 和 KNA1/LFA1 的关系先建立一个正确的心理模型。传统 ECC 时代客户和供应商是两套彼此独立的主数据客户写 KNA1一般数据、KNB1公司代码数据、KNVV销售区域数据、KNBK银行供应商写 LFA1、LFB1、LFM1、LFBK。两套数据中间唯一的桥是那个用来对账的总账科目人和组织的信息是各存一份的。同一个某某贸易有限公司如果既买你的货又卖给你东西你得建两个主数据改一次地址要改两遍。BP 模型把这个结构彻底翻了过来。BP 的一般数据只有一份存在 BUT000 里配地址在 BUT020 关联到地址主数据 ADRC银行明细在 BUT0BK税号在 DFKKBPTAXNUM这是 FI 侧的税号存储表外部编码类的标识在 BUT0ID人和人之间的关系比如母公司-子公司、联系人-雇主在 BUT050BP 挂了哪些角色在 BUT100。客户和供应商不再是独立实体而只是这个 BP 身上的两个角色角色下面再挂各自的组织层数据客户挂 KNB1 和 KNVV供应商挂 LFB1 和 LFM1。地址、名称、银行、税号这些全公司共享的信息客户侧和供应商侧看到的是同一份。这里有个版本差异必须说清楚因为它直接决定你写程序时能不能直接碰 KNA1。在较早的 S/4HANA 版本1511、1610、1709 那一批里KNA1、LFA1 还是实打实的透明表BP 和客户/供应商之间靠 CVI客户/供应商集成做双向同步你改 BP系统背后帮你更新 KNA1反过来用老事务码改 KNA1也能触发同步回 BP。而在较新的版本里BP 是唯一的主数据载体KNA1、LFA1 这些已经以兼容视图的形式提供读没问题写不行。这个差异带来的后果比大多数人预想的严重。我见过一个自研的批处理程序直接UPDATE KNA1去改客户名称字段。在测试环境老版本、实体表跑得好好的一到新版本的生产环境程序跑完不报错但前台打开客户一看名称纹丝不动——因为那是个视图UPDATE 落到视图上等于什么都没干。所以一条硬规矩S/4HANA 里所有跟客户/供应商主数据相关的自研逻辑读可以走 KNA1/LFA1 兼容视图注意性能视图背后是 JOIN写一律走 BP 的 BAPI 或 BP 事务。数据类别业务伙伴侧客户侧供应商侧一般数据名称/搜索项/语言BUT000共享共享地址、通讯BUT020 ADRC共享共享银行明细BUT0BKKNBKLFBK税号DFKKBPTAXNUM共享共享外部标识、旧编号BUT0ID共享共享关系联系人/上下级BUT050共享共享角色BUT100——公司代码数据—KNB1LFB1销售区域数据—KNVV—采购组织数据——LFM11.2 兼容视图带来的两个反直觉现象第一现象改一般数据会一脚踩两只船。如果同一个 BP 编号上同时挂了客户角色和供应商角色你在一般数据里改一个名称、加一个银行账号那个 BP 对应的客户和供应商同时变了。这在 ECC 时代是不可想象的也是很多业务部门不理解的——他们习惯性地认为客户资料和供应商资料是两个东西。实施阶段如果业务方提出我们要求客户和供应商的名称可以不一样那就要认真讨论是不是该拆成两个 BP 用关系BUT050关联而不是硬塞在一个 BP 上。这个决策点必须在蓝图阶段定上线之后再拆成本极高。第二现象编号一致性问题。CVI 配置里有一个很关键的选项——BP 编号和客户/供应商编号是否相同。选了同号Same Number那么一个客户号码 100001它的 BP 号也是 100001调试时看到一个号要立刻反应过来它在哪一侧。同号的好处是脚本、报表、接口对号入座简单坏处是号段规划必须一次做对客户和供应商共享同一个 BP 号段未来要独立扩号段会很麻烦。选不同号则要为 BP 单独规划号段好处是客户和供应商的号段相互独立坏处是每个接口都要维护一张对应关系表。我在项目上更倾向同号理由很朴素主数据迁移时对账快出了问题能一眼定位是哪条数据而不是先去查映射表。还有一个细节BP 的编号范围是由BP 分组决定的客户/供应商的编号范围是由账户组决定的客户用 XDN1、供应商用 XKN1 维护。如果 CVI 要求同号那么 BP 分组的编号范围与客户/供应商账户组的编号范围就必须口径一致否则同步时报编号不在范围内是必然的。2. 基础视图的字段分区逻辑一般数据、公司代码、销售与采购组织怎么切2.1 一般数据里哪些字段是全局共享的BP 事务的界面是按角色分块的基础视图通常指角色下的三块内容一般数据、公司代码数据、以及销售区域/采购组织数据。这三块的划分不是随手切的它对应的是这份数据归谁管、什么时候用。一般数据是全局层任何组织单元公司代码、销售组织、采购组织都看得见同一份。姓名或公司名称、搜索项、语言、地址、通讯方式电话、邮箱、传真、银行明细、税号、标识、关系全在这里。注意标识这个块很多项目会忽略它其实是把历史系统的旧编号搬进 BP 的最佳位置——你可以定义一个标识类型如旧客户号把原来 ECC 里的客户编码存进去迁移期间做新旧对照、查历史报表时非常省事。字段长度和唯一性可以按标识类型配置用得好的话上线后的半年内你会感谢当初多做这一步。通讯方式那一块有个容易踩的点BP 支持多个电话、多个邮箱但如果不指定标准通讯方式下游的单据打印比如订单确认、发票邮件发送取不到收件人会出现打印报错说找不到邮件地址这种看起来莫名其妙的问题。判断方法很直接打开 BP 的通讯数据看有没有哪一条被标记为标准。2.2 公司代码视图与销售/采购组织视图的职责边界公司代码数据是财务视角的。客户侧主要管对账科目、付款条件、付款方式、催款程序、清账相关设置、利息计算标识供应商侧主要有对账科目、付款条件、付款冻结、预付款相关、计划付款等。这些字段的共同特征是跟钱怎么走有关所以它按公司代码隔离——同一家客户跟集团内两家公司做买卖完全可以给不同的付款条件和不同的对账科目。销售区域数据是给 SD 用的按销售组织/分销渠道/产品组的组合来细分。装运条件、交货优先级、定价过程、客户组、销售地区、货币、合作伙伴功能还有最重要的销售区域专属的付款条件注意不是公司代码那个都在这里。这也就解释了一个经典问题为什么销售订单里带出的付款条件跟客户主数据公司代码视图里填的不一样因为订单取的是销售区域层的那一份不是公司代码层的那一份这是两个字段。采购组织数据是给 MM 用的。采购组、订单货币、国际贸易条件Incoterms、收货处理时间、交货条件采购日历、发票校验相关标识如基于收货的发票校验、采购冻结、供应商的其他数据里还有确认控制、装运指令这些。这些字段直接影响采购申请和采购订单的默认值也影响发票校验能不能过。典型字段存在哪一层影响的下游名称、地址、银行、税号一般数据所有模块、单据打印、报表对账科目、付款条件公司代码层FI 记账、清账、付款程序催款程序、付款方式公司代码层催款运行、自动付款装运条件、定价过程销售区域层SD 订单、交货、定价销售区域付款条件销售区域层销售订单的付款条件采购组、Incoterms采购组织层采购申请、采购订单收货处理时间采购组织层MRP、交期计算我自己判断该改哪一层的方法很简单问一句这个变更要不要按组织差异化。不需要差异化的放一般数据需要就下沉到组织层。这个判断问句能过滤掉九成放错层的问题也能避免业务方提出我们想在 A 公司用这个付款条件、B 公司用另一个时你却把它放到了全局层。3. 前台实操一个新客户和一个新供应商从零录到能开票、能下单3.1 创建前先确认三件事别急着敲屏幕第一件BP 分组。分组决定这个 BP 用哪个编号范围、内部还是外部给号。1自然人、2组织、3组这些是 BP 类别分组是在类别之上再细分号段的机制通常组织类会专门配一个分组给公司客户用自然人另配一个分组给个人客户用方便区分号段和后续的字段状态策略。第二件角色。这个客户是纯 FI 客户只做账不做销售角色 FLCU00还是完整的客户既做销售又做账角色 FLCU01还是供应商侧对应的 FLVN00/FLVN01角色选少了界面右上角的标签就少一块你以为系统里没这个字段其实是角色没挂。这一步的对应关系记牢00 结尾的是 FI 视角01 结尾的是带组织层数据的完整视角。第三件客户账户组 / 供应商账户组。这个字段决定了字段状态哪些字段必输、哪些可选、哪些隐藏和客户/供应商编号范围。售达方、送达方、付款方这些不同账户组字段状态配置是分开的如果你的业务里存在只维护必输的最小集的账户组那建单速度会快很多。3.2 标准的录入顺序BP → 角色 → 一般数据 → 组织数据打开 BP 事务先在工具栏点组织把 BP 类别和分组定下来。如果想用外部编号就在这里手工输入编号用内部编号的话留空保存后系统给号。然后选定角色比如 FLCU01界面会展开对应的数据区。第一屏填一般数据公司名称名称 1 是法定名称名称 2 常用来放简称或部门搜索项建议用拼音首字母或简称结尾可以做模糊搜索的匹配项这个技巧在老客户主数据时代就有现在依然管用、语言、地址国家、地区、城市、邮编、街道。地址这块强烈建议在录之前确认邮编城市主数据已经维护好否则系统会提示城市与邮编不匹配或者允许你保存但后续地址清洗时一堆脏数据。接着往下走通讯数据至少留一个标准电话或标准邮箱、银行明细如果这个客户要走自动收款或供应商要走自动付款必须在这里维护注意区分银行代码、银行国家、账号、IBAN 这几项IBAN 填了系统会做校验、税号按需要维护税号类别跨境业务尤其要注意税号类别选对。一般数据保存之后再回来补组织层客户的公司代码视图里确认对账科目如果配置了自动确定系统会自动带出来没有配置就得手工填这个字段空着会导致发票过账报错未找到对账科目、付款条件、付款方式销售区域视图里填装运条件、定价过程、销售地区、客户组、货币供应商的采购组织视图里填采购组、订单货币、Incoterms、收货处理时间。整个顺序之所以是先一般、后组织是因为地址和编号属于必须最先确定的身份信息很多必输校验会在保存时一次性触发先做身份再补组织数据报错信息更集中、更好排查。3.3 修改和显示查找方式与改错视图的坑BP 事务的查找入口比老事务码方便得多可以按 BP 编号、名称、地址、标识比如你存的旧客户号来查。这里有个实用技巧给业务用户培训时教他们用标识里的旧客户号来查比让他们记新的 BP 编号靠谱得多尤其在上线初期新旧编号并存的阶段。修改的时候最容易出问题的是改错了层面。比如业务反馈银行账号填错了你在一般数据的银行明细里改一次就够了客户和供应商两侧都生效但如果业务反馈付款条件错了那要看是销售订单里的付款条件错了还是 FI 凭证里的付款条件错了前者改销售区域视图后者改公司代码视图。这两个地方各改一次、改完之后互相打架的案例我见过不止一次。判断口诀是跟单据打印/合同抬头相关的信息在一般数据跟钱和账期相关的分两层——SD 单据取销售区域FI 凭证取公司代码。另外提醒一点BP 的修改是有权限区分的一般数据、银行、税号、角色这些块可以分别授权。运维同学如果发现某个字段灰的、点不动先别怀疑屏幕配置去查用户的权限对象里有没有对应的 BP 数据块权限。这是新手最容易绕进去的坑之一。4. 配置侧的对齐角色、账户组、字段状态三张牌怎么打4.1 业务伙伴角色与客户/供应商账户组的映射BP 角色定义在 SPRO 里跨应用组件 → SAP 业务伙伴 → 业务伙伴 → 基本设置 → 业务伙伴角色 → 定义业务伙伴角色。这里最容易被忽略、但影响最大的是角色分类这个字段。角色分类决定这个角色挂上之后界面显示哪一套数据区和底层映射哪一套 DDIC 结构。标准角色 FLCU00/FLCU01/FLVN00/FLVN01 已经配好了相应的角色分类自建角色如果角色分类选错会出现角色挂上了但客户数据区打不开这种诡异现象。角色到账户组的映射在跨应用组件 → 主数据同步 → 客户/供应商集成 → 业务伙伴设置下面里面要定义 BP 角色与客户账户组、供应商账户组的对应关系。这一步如果漏配表现是新建 BP 挂了 FLCU01 角色但客户抬头里的账户组是空的或者直接报找不到账户组的对应关系。这类问题在配置检查清单里必须单独列一行。还有一个经常被拿来问的配置点CVI 的方向控制。系统支持创建客户时同步生成 BP创建 BP 时同步生成客户两个方向的开关实际项目里通常要求两个方向都开同时要求同号。如果只开了一个方向会出现BP 有了但客户没有的不一致数据后期得用一致性检查报表去捞。4.2 字段状态为什么这个字段在 A 客户上必输、在 B 客户上可选字段状态的配置入口是账户组的定义账户组并检查字段状态客户和供应商各占一份配置。它把字段分成必输、可选、隐藏、只显示四档按一般数据 / 公司代码 / 销售区域 / 采购组织分别设置。这里是 BP 项目里冲突最集中的地方财务要求付款条件必输销售要求装运条件必输而主数据的创建者希望必输项越少越好——因为必输项多一个批量导入的失败率和录入的时间就往上走一段。我的处理经验是字段状态的判断标准应该是这个字段缺席会不会导致下游业务跑不动。付款条件缺席会导致发票无法正常计算到期日必输合理客户组缺席只是影响报表统计维度设成可选就行。凡是能通过自动确定带出来的字段都不要设必输减少人工录入量。顺带说一个具体的坑迁移期间为了赶进度把字段状态放宽上线后再收紧要重新盘点存量数据工作量是一次性设对的三倍。所以字段状态必须在迁移前定稿迁移脚本按定稿的字段状态来准备数据。4.3 编号范围内部分配、外部分配与编号不一致的后果BP 分组的编号范围在跨应用组件 → SAP 业务伙伴 → 业务伙伴 → 基本设置 → 编号范围和分组里维护客户用 XDN1、供应商用 XKN1。四个组合方式内部/外部 × BP/客户供应商如果混用最常见的报错就是同步时编号不在编号范围内或者该编号已存在。一个具体场景BP 分组配的是内部编号客户账户组配的是外部编号CVI 又要求同号。这时候新建 BP 系统自动给一个号然后尝试用这个号去创建客户客户账户组不允许外部编号直接报错。解决办法只有两个要么两边都改成内部要么两边都改成外部。没有第三条路。外部给号的场景里还有一层责任划分编号由业务提供时重复编号的检查压力就在录入端。建议在批量导入前先用 BP 的查找功能把待导入的编号过一遍确认没有占用再跑导入不然跑到一半中断、一半成功一半失败回滚起来很痛苦。5. 高频报错与排查链路从报错消息倒推到配置项5.1 CVI 激活或同步失败按什么顺序查BP 激活失败这类问题本质上多是存量客户/供应商转 BP或者 BP 往客户/供应商侧同步时被校验拦住了。我按下列顺序排查通常能在前三步定位到八成问题。第一步看日志而不是猜。同步作业和一致性检查都会留日志日志里带消息号的那一条才是真正的根因前面那些处理中的提示可以跳过。很多人只看第一条就下结论结果修错了地方。第二步查编号范围。日志里出现编号相关的消息就去核对 BP 分组的编号范围与客户/供应商账户组的编号范围是否还有余量、内外部编号是否一致。存量迁移量大的时候号段耗尽是很常见的低级错误。第三步查地址和必输字段。存量数据从老系统带过来的地址常常缺城市、邮编或者地区字段国家/地区的地址格式校验在迁移时会直接拦住。跑迁移前先做一次地址数据体检把缺关键字段的捞出来补比跑到一半中断再回头补要省事。第四步查银行与税号。同一银行账号银行国家分行挂在多个 BP 上会触发重复性检查同一个税号挂在多个 BP 上也会被拦。这两类检查在业务上往往是有正当理由的集团共用账号、共用税号所以要么调整检查策略为警告要么在数据层面做区分处理。第五步查 BP 分组与角色映射是否完整以及执行者的权限是否覆盖所有数据块。权限导致的失败比较隐蔽日志里经常只写无权执行某操作不带具体字段信息。5.2 银行、税号、地址这三类校验报错的处理思路银行类的报错源头通常是两个数据层没分清银行主数据银行代码、银行名称那一层和 BP 的银行明细某个 BP 挂在某家银行的账号那一层。前者缺了要补银行主数据后者缺了在 BP 里加明细。IBAN 填了之后系统会反推银行代码如果推出来的与填的不一致也会报错。税号类的报错重点在税号类别选对没有。税号类别不同校验规则和唯一性范围都不一样。跨境业务里一个 BP 同时有本国税号和对方国税号是常态这时要按类别分别维护别在一个类别里塞两个号。地址类的报错绝大多数是邮编与城市主数据对不上。解决路径有两条补邮编城市主数据治本但工作量大或者在配置里把地址校验放宽治标但脏数据会持续产生。我一般建议做数据体检加上必要的放宽纯放宽的后果会在半年后以报表按地区统计总对不上的形式还回来。现象或报错最可能的原因先查哪里同步报编号不在范围内内外部编号口径不一致或号段耗尽BP 分组编号范围、账户组编号范围客户抬头账户组为空角色与账户组映射漏配客户/供应商集成的 BP 角色设置角色挂上但客户数据区打不开角色分类配错业务伙伴角色定义银行账号重复提示重复性检查触发银行明细、检查策略配置税号校验失败税号类别选错或格式不符一般数据里的税号类别发票过账报未找到对账科目公司代码层对账科目为空且无自动确定客户/供应商公司代码视图邮件的单据发不出去没有标记标准通讯方式一般数据的通讯块5.3 BP 建好了但开不了单、过不了账的三步定位法这是现场最常被叫去救火的问题我用一个固定顺序走很少失手。第一步确认角色挂全了没有。只挂 FLCU00FI 客户是绝对做不了销售的因为销售需要销售区域数据而销售区域数据只在 FLCU01 角色下才有。同理只挂 FLVN00 做不了采购订单。第二步确认组织层数据维护了没有。销售订单取不到装运条件、定价过程通常是销售区域视图空着采购订单带不出采购组、订单货币是采购组织视图空着发票过账报对账科目找不到是公司代码视图空着。这三类症状各有固定的字段出口对着日志里的消息号去查对应视图效率最高。第三步确认同步状态。在较早版本的 S/4HANA 里BP 侧数据齐全但客户/供应商侧没同步时用老事务码看客户是空的。这时候要么手工触发同步要么用主数据同步驾驶舱批量处理。较新版本里 BP 即客户、BP 即供应商通常不涉及这一步但要确认兼容视图能正常读出数据。6. 批量与接口BAPI、批输入与主数据治理的取舍6.1 BAPI 组合拳的执行顺序与提交逻辑单条创建用前台最稳但迁移和接口场景必须走 BAPI。BP 的 BAPI 不是一个大而全的接口而是一组按数据块拆开的方法顺序很重要DATA: ls_central TYPE bapibus1006_central, ls_central_x TYPE bapibus1006_central_x, lt_return TYPE TABLE OF bapiret2, lv_bp TYPE bu_partner. ls_central-partnercategory 2. 组织 ls_central-name1 某某贸易有限公司. ls_central-searchterm1 MMMY. ls_central_x-partnercategory X. ls_central_x-name1 X. ls_central_x-searchterm1 X. CALL FUNCTION BAPI_BUPA_CREATE_FROM_DATA EXPORTING partnercategory 2 centraldata ls_central centraldatacheck ls_central_x IMPORTING businesspartner lv_bp TABLES return lt_return. 关键逐条检查返回值不能只看第一条 READ TABLE lt_return TRANSPORTING NO FIELDS WITH KEY type E. IF sy-subrc 0. 继续挂角色 CALL FUNCTION BAPI_BUPA_ROLE_ADD_2 EXPORTING businesspartner lv_bp businesspartnerrole FLCU01 TABLES return lt_return. ENDIF. 地址、银行、税号分别调用对应 BAPI 追加 最后统一提交 CALL FUNCTION BAPI_TRANSACTION_COMMIT EXPORTING wait X.三个必须记住的点。第一每一个 BAPI 都会返回 RETURN 表必须逐条扫只要出现类型 E 就要停下来处理不能跑完了就算成功。第二所有 BAPI 调用完成后统一用 BAPI_TRANSACTION_COMMIT 提交参数 WAIT 传 X 让提交同步完成否则后面立刻按 BP 编号去查会查不到接口日志看起来像失败了。第三失败时调用 BAPI_TRANSACTION_ROLLBACK 回滚避免半成品数据留在系统里——BP 这种多表关联的主数据半成品最难清理。组织层数据公司代码、销售区域、采购组织在部分版本里没有独立的 BP BAPI需要结合客户/供应商侧的接口或者批输入补齐。落地方案前务必在你所在版本的系统里用 SE37 把 BAPI_BUPA_、BAPI_CUSTOMER_、BAPI_VENDOR_* 的实际清单查一遍以查到的为准不要照抄网上的函数名——不同版本差异不小。6.2 批输入在 BP 场景下的适用边界批输入BDC/LSMW 的批量输入录制在 BP 上有它的位置组织层字段特别多、BAPI 覆盖不到的场景录制是最实际的方案。但 BP 是单屏事务页签多、字段分散在同一屏里录制时要注意几点技巧。一是录制时不要用回车跳屏尽量把所有字段一次性填在同一屏提交减少屏幕流的变化带来的脆弱性。二是测试运行时用显示错误的模式BDC 的 MODE 参数设成 E让它停在出错的屏幕上方便定位是哪个字段的问题。三是留意 BP 界面上有些字段是只显示的录制时把它们也填上会导致报错需要在录制结果里手工删掉对应的 BDC 行。四是账户组、角色这类会影响屏幕结构的值尽量在录制时一次性设定好不要指望运行期切换。至于 LSMW 的 Direct Input 方式BP 基本不适用因为它是基于标准批输入程序的接口层面不支持。老老实实用批量输入录制虽然慢但稳定。6.3 上线前的数据体检清单主数据项目的成败八成在上线前的那几轮体检里就决定了。我把每次项目都会过一遍的清单放这儿你可以直接拿去用编号范围余量BP 分组、客户、供应商三套编号范围各留多少空位测算按未来三年的新增量估。角色与账户组映射完整逐条列出业务用到的账户组确认每个都有对应的 BP 角色映射没有遗漏的自建组合。字段状态定稿必输项清单与实际存量数据的满足率对比对不上的先补数据再收紧配置。银行重复检查策略是拦为错误还是降为警告业务和财务要签字确认并写明理由。税号唯一性范围按税号类别确认唯一性口径跨境业务尤其要确认清楚。地址主数据完整度邮编城市主数据缺失清单以及清理责任人。同步日志清零迁移完成后跑一致性检查把不一致的记录清零再放行。权限检查新的事务码、新的数据块权限是否已配到关键用户和运维角色上。我个人在实际操作中的体会是BP 这套模型最考验人的地方不在于会不会点屏幕而在于分层意识——同一个字段放一般数据还是放组织层放错了当期没感觉等到业务提出这一家公司要单独用另一个付款条件时才发现改不动那才是真正花时间的时候。所以每次新建 BP 之前我都会多花三十秒想清楚这三件事这个号是内部给还是外部给、角色要挂哪几个、账户组选哪个。三十秒的思考通常能省掉后面两个小时的排查。还有一个很小的技巧分享给做运维的同学把 BP 的标识块用起来把旧客户号、旧供应商号、合同编号都存成标识类型以后业务拿着任何一张老单子来问这家客户现在的资料在哪你都能一条命令查出来比翻迁移对照表快得多。
