电商进销存软件：连锁企业进阶教程：围绕采购协同建立降低沟通成本闭环

电商进销存软件：连锁企业进阶教程：围绕采购协同建立降低沟通成本闭环

连锁企业采购最容易被低估的成本，往往不是采购价差，而是同一件事在门店、区域、采购、仓库和供应商之间被重复确认。一次补货可能产生十几条聊天记录、三张表格和四次电话，但最终仍然无法回答“谁在什么时候确认了什么、货为什么没到、差异由谁承担”。我在评估连锁企业进销存项目时，通常不会先看系统有多少按钮，而是先追踪一张采购单从需求产生到供应商结算的完整路径，因为采购协同的本质不是让所有人获得更多消息，而是让关键事实只被录入一次，并在正确节点自动流转。

这篇教程讨论的不是单纯的采购下单功能，而是一套围绕采购协同建立的经营闭环：门店需求被准确汇总，采购建议有依据，供应商确认有时限，仓库收货有差异记录，财务付款有凭证，采购复盘又能反过来修正安全库存和供应商策略。文中的企业名称、项目数据和人员信息均已匿名化；经营指标采用匿名项目区间化复盘或情景模拟，不等同于行业统计。宏观背景参考国家统计局公开的社会消费品零售统计、商务部公开的电子商务发展报告以及连锁经营行业公开研究资料。

一、先讲核心结论：降低沟通成本，先减少沟通发生的必要性

1. 采购协同的第一目标不是“消息可见”，而是“状态可信”

很多企业上线进销存软件后，第一件事是把采购通知、到货提醒、审批消息全部搬到系统里。结果是消息数量增加了，沟通成本却没有下降。采购员仍然需要在群里追问供应商是否看到了订单，门店仍然通过电话修改数量，仓库收货后再单独通知采购，财务还要拿着纸质单据核对。

问题不在于消息没有发送，而在于系统没有形成可信状态。所谓可信状态，至少要包括采购单当前处于什么阶段、下一步责任人是谁、承诺日期是什么、实际到货多少、差异是否已经被确认，以及这次差异会不会影响后续补货。

我会把采购单状态压缩成几个业务上真正有意义的节点：需求待汇总、建议待审核、订单待供应商确认、部分确认、运输中、到货待验收、差异待处理、完成待结算。状态越少越好，但每个状态都必须有进入条件、退出条件和责任人，否则只是换了一种颜色展示混乱。

2. 真正的闭环必须覆盖八个节点

一条成熟的采购协同链路，至少需要覆盖以下八个节点。缺少其中任何一个节点，前面的自动化都可能在最后被人工沟通打断。

1. 需求采集：门店销售、库存、在途、促销计划和最低陈列量共同形成需求，不再只靠店长主观报数。
2. 需求汇总：系统按区域、仓库、供应商、商品规格和交期汇总，避免同一商品被不同人员重复下单。
3. 采购建议：根据可用库存、预测销量、采购周期和最小订货量生成建议，并保留人工调整原因。
4. 订单确认：供应商对数量、价格、交期、包装和配送方式逐项确认，不能只回复一句“收到”。
5. 到货协同：供应商提前提交预计到货时间，仓库据此安排月台、人员和验收批次。
6. 差异处理：短装、破损、错发、临期、价格变化必须形成差异单，并关联原采购单。
7. 结算核对：采购订单、收货记录、发票或对账单进行三方核对，避免“货收了但金额对不上”。
8. 复盘反馈：到货及时率、完整交付率、缺货损失、价格偏差和差异关闭时长反向影响下一轮采购策略。

这八个节点并不意味着系统越复杂越好。相反，我更倾向于先把流程中的关键事实固定下来，再把低价值提醒删除。一个采购单如果需要五个人分别抄录同一组数量，系统即使增加十个提醒，也无法消除根本问题。

3. 用一个公式判断沟通成本是否真的下降

我不建议用“群消息少了多少条”衡量协同效果，因为消息减少有时只是问题被隐藏了。更实用的口径是把沟通成本拆成四个变量：沟通触发次数、每次处理耗时、重复录入次数、异常返工次数。

采购沟通成本指数
= 沟通触发次数 × 平均处理分钟数

+ 重复录入次数 × 单次录入分钟数

+ 异常返工次数 × 平均返工分钟数

例如，采购员每天少看十条提醒，不一定代表效率提高；如果短装问题在月底才集中暴露，返工成本反而更高。只有当订单确认、到货差异和结算核对都能沿着同一业务单据完成，沟通成本才是真正下降。

二、先还原真实场景：连锁企业为什么总在采购环节反复沟通

1. 门店看到的是销售机会，采购看到的是供应约束

门店希望货架不断货，采购希望集中下单拿到价格，仓库希望到货均匀，供应商希望订单稳定且不频繁修改。四方看的是同一批商品，却使用不同的判断依据。

门店可能根据昨天卖得快就上调需求，采购看到仓库还有库存，供应商则受制于整箱包装和最低起订量。若系统只传递一个“要多少”的数字，就会把复杂的经营判断压缩成一个无法解释的结果。

因此，采购需求至少要携带销售预测、当前可用库存、在途数量、预计消耗天数、采购周期、最小订货量和促销标签。采购员不一定完全接受系统建议，但必须知道建议为什么是这个数，并能够记录调整原因。

2. 连锁规模扩大后，沟通对象呈几何式增加

一家拥有八家门店的企业，可能由一个采购员直接对接二十家供应商，沟通对象还算可控。当门店增长到三十家、供应商增长到一百家，采购员面对的就不再是单纯的订单数量，而是门店、区域仓、供应商、物流和财务之间的组合关系。

如果每个对象都通过独立表格或聊天窗口传递信息，变化会产生叠加效应。商品规格改一次，采购表要改，供应商模板要改，仓库收货标准要改，财务对账表还要改。真正需要治理的不是“消息太多”，而是同一个业务事实在不同环节拥有多个版本。

3. 电商订单波动会放大采购协同问题

传统门店的需求变化通常较慢，而电商渠道会受到直播、平台活动、短期投放、天气和社交传播影响。一个商品上午销量正常，下午因为活动曝光突然增加，采购员可能在群里临时追加，供应商也可能用替代品应急。

如果系统没有区分常规补货、活动备货和紧急采购，所有订单都会进入同一套审批路径。结果是紧急订单等审批，常规订单被频繁打断，采购员只能通过电话推动流程。

我通常会要求企业至少建立三种需求类型：常规补货、活动备货、异常补货。三种类型可以使用不同的审批时限、库存阈值和供应商确认规则，但必须共享同一商品主数据和收货标准。

4. 沟通成本高，常常是责任边界没有被写进流程

“供应商没按时发货”这句话往往不够准确。可能是采购单没有明确交期，可能是供应商确认了数量但没有确认日期，也可能是仓库临时调整收货窗口，甚至可能是采购员修改了订单却没有留下版本。

如果责任只在聊天里表达，后续复盘必然陷入争论。有效的协同流程必须把责任拆成可验证的事件：订单发送时间、供应商确认时间、承诺发货时间、物流发运时间、仓库预约时间、实际收货时间、差异确认时间。

这些事件一旦被结构化记录，沟通就从“你当时是不是答应了”转变为“哪一个节点发生了偏差”。这也是进销存软件能够产生管理价值的地方：它不是替企业争论，而是把争论变成可追溯的业务证据。

三、常见误区：看起来协同，实际上只是把混乱搬进系统

1. 误区一：把即时通讯当成采购协同平台

群聊适合处理临时问题，不适合承载采购主流程。聊天记录通常缺少结构化字段，无法稳定表达采购数量、交期、价格、税率、包装单位和差异责任。更严重的是，群消息的上下文会不断下沉，后来加入的人很难知道哪些内容已经被确认。

我并不主张完全禁止聊天工具。更合理的做法是让聊天承担提醒和解释，让进销存系统承担订单、确认、收货、差异和结算。凡是会影响库存、成本或付款的事实，都应回到正式单据中。

可以采用一个简单规则：如果一条消息需要在月底作为证据，它就不应该只存在于聊天记录里。例如“这次少发两箱，下次补”必须转化为短装差异和补发承诺，而不是停留在文字回复。

2. 误区二：审批层级越多，采购风险越低

审批是控制风险的手段，但不是所有采购都适合相同的审批深度。低金额、高频、标准化商品如果每次都经过多级审批，企业得到的不是更安全，而是更长的响应时间和更多的线下催办。

我会把采购订单按照金额、毛利影响、供应商风险、商品敏感度和需求类型分层。常规补货可以采用额度内自动通过，活动备货需要核对活动计划，临时高金额采购则进入人工复核。审批规则应该围绕风险差异设计，而不是围绕组织层级设计。

3. 误区三：供应商能登录系统，就等于完成了协同

供应商是否能够使用系统，不等于供应商愿意持续使用。供应商最关心的是订单是否准确、确认是否减少重复询问、交付后是否能快速对账。如果系统只是把采购员的工作转移给供应商，却没有减少供应商的重复录入，供应商很快会回到原来的沟通方式。

供应商协同页面应当尽量只保留与供应商相关的任务：查看订单、逐项确认、申请交期调整、提交发运信息、上传送货资料、处理差异、查看对账状态。不要把企业内部审批、毛利、其他供应商价格等无关内容暴露给供应商，也不要让供应商重复填写系统已经知道的信息。

4. 误区四：只追踪准时率，不追踪完整交付率

供应商在承诺日期送来一半货，系统可能仍然记录为“准时到货”。但对于门店而言，如果核心规格缺失，准时并没有解决缺货问题。

采购协同至少要同时关注准时交付率、完整交付率、合格收货率和差异关闭时长。四项指标分别对应时间、数量、质量和问题处理效率，不能用其中一项代替全部表现。

四、专业判断逻辑：先设计协同规则，再选择系统功能

1. 先问“采购决策需要什么输入”，不要先问“系统有哪些模块”

采购建议的准确性，取决于输入数据是否足够稳定。最低限度需要有商品编码、规格、采购单位、库存单位、转换关系、供应商、采购周期、最小订货量、最近采购价、可用库存和在途数量。

如果一箱商品有二十四个，门店按瓶销售，采购按箱下单，仓库按箱收货，财务按含税金额结算，那么单位转换就必须在主数据中被明确表达。否则系统看似自动生成了采购建议，实际只是把错误计算自动化。

我会在项目初期抽取一个月的采购数据，随机检查至少五十个高频商品，重点看四件事：商品名称是否唯一、规格是否一致、单位是否可换算、供应商是否明确。只要其中一项的错误率较高，就不应该急着上线自动采购建议。

2. 把“正常路径”和“异常路径”分开设计

很多流程设计只画正常路径：门店提交需求、采购下单、供应商发货、仓库收货。实际经营中，最消耗时间的却是异常路径：需求突然增加、供应商缺货、交期变化、商品替代、部分到货、价格变化和临期拒收。

正常路径应尽量短，异常路径则要保留足够证据。比如供应商申请延期时，不应只提供“同意”或“拒绝”两个按钮，还应要求填写新承诺日期、影响商品、影响数量和补救方案。采购员可以快速处理，但系统仍然留下可复盘的信息。

• 数量变化：记录原订购量、变更量、变更原因和批准人。
• 日期变化：记录原承诺日期、新承诺日期、延期原因和影响门店。
• 规格变化：记录原商品、替代商品、价差和验收要求。
• 质量差异：记录批次、照片或验收备注、处理结论和责任方。
• 价格变化：记录原价格、调整价格、生效时间和合同依据。

3. 协同对象越多，越要采用“例外驱动”而不是“全量干预”

采购员不应每天逐单查看所有正常订单。系统应先筛出需要人判断的例外，例如预测覆盖天数低于阈值、供应商未在规定时间确认、订单金额异常、交期临近仍未发运、到货数量偏差超过容差。

例外规则不是越多越好。规则过多会让采购员每天面对大量所谓异常，最终再次回到人工筛选。一个好规则必须同时满足三个条件：能够影响经营结果、可以用现有数据判断、触发后有明确动作。

4. 评价系统时，重点看“跨角色连续性”

采购员在系统里完成下单，并不代表协同完成。需要从不同角色连续走一遍流程：门店能否看见预计到货和可售库存，采购能否看见需求来源，供应商能否快速确认，仓库能否提前准备，财务能否依据收货结果对账。

我建议用一张贯穿全链路的采购单做验收，不要分别演示采购、库存和财务模块。验收人员应该故意制造一次部分到货、一次交期延期和一次规格替代，观察系统能否保留原始订单、生成差异、通知相关人员并影响后续结算。

五、案例与数据观察：一次三十家门店的采购协同改造

1. 项目背景：问题不在订单生成，而在订单之后

下面是一家匿名连锁零售企业的区间化复盘。企业拥有三十家门店、两个区域仓和约四千个活跃商品编码，采购团队九人，长期合作供应商约一百二十家。项目启动时，企业已经有基础进销存系统，也能生成采购单，但供应商确认、到货差异和对账主要在线下完成。

改造前，采购员每天上午先从门店表格汇总需求，再在系统里下单；下单后把订单截图发送给供应商；供应商通过聊天回复可供数量和预计到货时间；采购员再回到表格修改备注。仓库收货时如果发现短装，通常先让司机签收，之后再由仓库主管发消息给采购。

这个流程看起来每一步都有记录，实际却存在三个版本：系统里的订单版本、采购员手里的表格版本、供应商确认后的聊天版本。月底对账时，财务拿到的是第四个版本，因为发票金额又可能不同。

2. 改造方法：只改四个关键动作

项目没有一开始就重做所有采购流程，而是先集中处理四个最影响协同的动作。第一，把商品采购单位和库存单位统一，并对箱规建立换算关系。第二，把供应商确认拆成数量、交期和价格三个字段。第三，把仓库收货差异直接关联采购单。第四，把未确认、延期和超容差收货纳入异常看板。

采购员不再手工维护一张“供应商回复表”。供应商确认后，系统自动回写采购单状态；供应商只能在授权范围内申请调整，任何数量和价格变化都保留版本。仓库收货时录入实收数量和差异原因，采购员处理差异后，财务才能看到可结算数量。

需要特别说明的是，项目没有要求所有供应商第一天就使用完整协同入口。对订单量大、交付频繁的核心供应商，要求结构化确认；对订单量小的供应商，先由采购员代录，但字段和状态仍然保持一致。这样既保证数据结构，又避免一次性把供应商全部挡在流程之外。

3. 数据观察：最明显的改善来自“提前知道不能交付什么”

很多人以为协同改造的价值是让供应商更准时。这个案例里，更明显的变化是供应商更早暴露了不能完整交付的商品。采购员可以在发运前重新分配库存、调整门店优先级或启动备用供应商，而不是等到仓库收货后才发现短装。

这会带来一个容易被误读的现象：系统上线初期，异常单数量可能上升。原因不是经营变差，而是原来隐藏在聊天记录里的问题被正式登记了。只有先让异常可见，企业才有机会判断哪些供应商、商品和仓库环节在重复制造问题。

4. 反面案例：把所有商品都套用同一个安全库存公式

同一项目中，曾经有一类商品因为统一设置了十四天安全库存，导致采购金额明显上升。采购团队原本希望避免缺货，却忽略了这类商品保质期短、活动波动大，而且供应商可以每天配送。

后来团队把商品分成三类。高频稳定商品按历史消耗和采购周期计算；活动商品按活动计划、预售数据和退出周期计算；短保商品则降低安全库存，增加补货频次，并把临期风险纳入采购建议。

这说明系统不能替代商品策略。采购协同的规则必须同时考虑交付能力、商品生命周期、毛利、保质期和缺货损失。一个看似统一的公式，可能在不同商品上产生完全相反的结果。

六、不同阶段的行动建议：不要一开始就追求全自动采购

1. 数据混乱阶段：先做主数据和责任盘点

如果企业仍然存在同品多码、采购单位不一致、供应商名称重复、门店库存不可信等问题，第一阶段不适合直接上线自动补货。此时最有价值的工作是建立问题清单，而不是采购更多功能。

• 抽取销售排名前二十的商品，核对名称、规格、条码和采购单位。
• 抽取采购金额排名前二十的供应商，合并重复名称和无效账号。
• 随机抽查最近一个月的收货记录，统计短装、错发、破损和临期占比。
• 逐张追踪十笔采购单，记录每次人工转录、电话确认和表格修改。
• 明确门店、采购、仓库、财务和供应商分别对哪些字段负责。

这一阶段的验收标准不是“系统上线”，而是至少百分之九十的重点商品能够被唯一识别，采购单位和库存单位可以正确换算，关键供应商有明确的交付联系人和结算条件。

2. 流程可视阶段：先让订单状态和异常状态统一

当主数据达到可用水平后，可以先上线订单确认、到货登记和差异处理。此时不要急着开放复杂预测模型，先解决“订单现在在哪里”和“异常由谁处理”两个问题。

建议用四周观察基线。第一周记录平均确认时长、延期订单比例和差异关闭时长；第二周只上线状态统一；第三周加入逾时提醒；第四周加入供应商履约评分。这样可以区分改善来自哪里，而不会把所有变化归因于软件。

3. 规则优化阶段：把采购员时间转向例外判断

当订单状态和差异数据稳定后，才适合启用补货建议、供应商评分和自动分配规则。此时要重点检查系统建议被人工修改的原因。若大量订单被采购员手工改高，可能是促销计划没有输入；若大量订单被改低，可能是库存数据延迟或安全库存过高。

每月复盘时，我建议把人工修改原因分成几类：活动因素、季节因素、供应商约束、库存不准、商品策略变化、价格变化和临时经营决策。修改原因本身就是训练采购规则的重要数据，不应该被当成系统失败。

4. 管理复制阶段：把成熟规则复制到新门店和新区域

连锁企业真正的规模效应，不是总部可以看见更多数据，而是新门店可以快速采用经过验证的采购规则。成熟的模板应包括商品分层、补货周期、供应商分组、审批阈值、收货容差和异常处理时限。

复制时不要直接复制所有参数。不同区域可能有不同物流周期、消费结构和供应商密度。可以复制流程骨架，但允许区域调整安全天数、配送频次和备选供应商。

七、不同情况下的取舍：采购协同没有唯一最优解

1. 集中采购与区域采购的取舍

集中采购更容易获得价格优势、统一质量和规模化结算，也更适合标准化商品。但它可能忽略区域需求差异，增加运输距离和临时补货难度。区域采购响应速度快，能够处理本地商品和短保商品，但供应商价格、质量和合同管理更难统一。

我的建议不是二选一，而是按商品属性拆分。全国性标准商品、品牌授权商品和价格敏感商品适合集中采购；短保商品、区域特色商品和运输半径受限商品可以由区域采购负责。系统需要允许两种模式共存，但必须明确同一商品在不同区域的供应责任。

2. 供应商数量与交付稳定性的取舍

减少供应商数量可以降低沟通对象和对账工作，但会提高单一供应风险。增加供应商可以提升议价和替代能力，却会增加准入、质量检查和订单分配的复杂度。

对于高频核心商品，我通常建议采用“主供应商加备用供应商”结构，而不是所有订单平均分配。主供应商承担稳定供货，备用供应商保持必要的交易频率和可切换能力。备用供应商如果长期没有真实订单，真正需要时可能无法立即承接。

3. 自动化程度与人工判断的取舍

自动下单适合需求稳定、规格标准、供应商交付可靠的商品。对活动商品、短保商品、新品和高金额商品，完全自动化可能放大预测错误。人工判断并不是低效的代名词，低效的是让人工把时间花在复制粘贴和重复确认上。

4. 低成本系统与深度定制的取舍

标准化进销存软件通常上线快、成本可控，适合流程尚未稳定或门店规模仍在增长的企业。深度定制可以贴合复杂业务，但会带来更长实施周期、更高维护成本和对服务商的依赖。

选型时应先判断企业是否真的拥有稳定且特殊的流程。如果企业连采购单位、供应商确认和差异责任都没有统一，定制只会把现有混乱固化成更复杂的系统。只有当标准流程已经运行稳定，并且存在明确的行业差异，定制才更有价值。

八、系统选型与验收：不要被功能清单带偏

1. 选型时优先检查五类能力

第一类是主数据能力。系统是否支持商品规格、采购单位、库存单位、箱规、供应商和价格有效期的统一管理，决定了后续数据能否被正确使用。

第二类是协同状态能力。供应商是否能逐项确认数量、交期和价格，是否能申请变更，是否能看到历史版本，比有没有一个醒目的“协同中心”更重要。

第三类是异常能力。系统是否能识别未确认、延期、部分到货、超容差收货和价格异常，并把异常分配给明确责任人，是降低沟通成本的关键。

第四类是跨单据追溯能力。采购订单、收货单、差异单、退货单、发票和付款状态能否互相关联，决定了财务和采购能否基于同一事实对账。

第五类是开放能力。企业未来可能需要连接电商订单、仓储设备、物流平台和财务系统，因此要确认接口、导入导出、权限和日志能力，而不是只看当前页面是否漂亮。

2. 用真实业务事件做验收，不要只看演示

验收时至少准备五个真实或脱敏场景：正常采购、部分确认、临时延期、到货短装和商品替代。每个场景都要由门店、采购、供应商、仓库和财务依次操作，观察信息是否能够连续传递。

验收人员还应主动检查权限边界。门店不应修改供应商价格，供应商不应看到企业内部毛利，仓库不应直接改变采购价格，采购员的改价是否需要审批也应符合金额和合同规则。

3. 建立一组能驱动行动的指标

指标不应该只是看板上的数字，而要对应具体动作。订单确认及时率低，就要检查供应商提醒和交期字段；完整交付率低，就要检查供应商承诺和订单拆分；差异关闭慢，就要检查仓库登记和责任分配；采购人工修改率高，就要检查需求输入和商品分层。

建议至少保留以下指标：订单确认及时率、订单完整确认率、供应商承诺达成率、准时交付率、完整交付率、合格收货率、差异关闭时长、采购建议采纳率、人工修改原因分布、采购沟通处理时长。

九、下一步怎么做：用一张采购单验证整个闭环

1. 先选一个可控范围，而不是全公司同时上线

最适合作为试点的范围通常是十家以内的门店、一个区域仓、二十到五十家供应商以及一百到五百个高频商品。这个范围足够暴露问题，又不会因为全公司同时切换导致企业无法判断原因。

试点商品应同时包含稳定商品、活动商品和短保商品。只选择简单商品，无法验证系统是否能处理真实经营中的波动；只选择问题商品，又容易把所有失败归因于系统。

2. 在上线前记录四周基线

没有基线，就无法判断系统带来的变化。至少记录四周的订单确认耗时、供应商逾期确认比例、完整交付率、差异关闭时长、人工抄录时间和月底对账返工时间。

基线不必追求精确到每一分钟，但必须统一口径。例如订单确认耗时应从订单发送时间算到数量、交期和价格全部确认的时间，而不是供应商回复“收到”的时间。

3. 上线后三十天只观察，不急着扩规则

第一阶段最重要的是确认流程是否被真实使用。哪些供应商仍然在线下回复，哪些门店不登记差异，哪些商品单位仍然混乱，哪些异常规则触发过多，都要被记录下来。

不要在第一周看到一个问题就新增一个审批节点。先判断问题是数据问题、流程问题、培训问题还是规则问题。把所有问题都交给审批解决，最终只会让系统更慢。

4. 用“成本下降还是成本转移”做最终判断

如果采购员少做了表格，但仓库增加了大量手工登记，或者供应商少接了电话，却需要重复录入三次数据，那么企业只是把沟通成本从一个部门转移到了另一个部门。

真正的闭环应同时改善至少三个维度：内部人工处理时间下降，异常问题更早暴露，库存和结算数据的一致性提高。若只有其中一项变化，企业还不能判断协同已经成熟。

5. 给管理层的最终判断

如果企业目前最痛苦的是门店需求不准，先改善需求采集和商品主数据；如果最痛苦的是供应商反复确认，先建立订单分项确认和逾时提醒；如果最痛苦的是仓库与财务对不上，先打通收货差异、退货和结算；如果最痛苦的是采购员被大量催办淹没，先做异常规则和供应商分层。

不要因为别的企业使用了复杂的预测模型，就跳过基础协同。连锁企业的采购进阶通常不是从“自动下单”开始，而是从“每个人看到的订单事实一致”开始。事实一致之后，企业才有资格讨论预测、优化和自动决策。

我的核心判断是：降低采购沟通成本，不是让人少说话，而是让关键事实不必被重复解释。当门店需求有来源、供应商承诺有字段、仓库差异有凭证、财务结算有依据、采购复盘有反馈时，系统才真正成为经营闭环的一部分。

下一步可以从一张最近发生过争议的采购单开始：找出它经历了多少次转发、多少次重复录入、多少个版本，以及哪一个节点最晚暴露问题。再用十家以内门店和一批高频商品做四周基线，先统一状态、责任和差异处理，最后才逐步增加自动补货和供应商评分。这样做不一定是最快的上线方式，却是最容易证明投入是否带来真实经营改善的方式。