电商进销存软件：增长负责人避坑指南：做销售管理时别忽略选型踩坑

电商业务最容易出现的一种假增长，是销售额已经翻倍，利润和现金流却开始恶化：订单越来越多，仓库不断催补货，客服频繁解释缺货，财务月底还在用表格核对退款和应收款。很多增长负责人把原因归结为供应链能力不足，真正复盘后却发现，问题往往从电商进销存软件选型那天就埋下了。软件没有把销售、库存、采购、退货和结算连成一条可追溯的链路，增长越快，错误放大的速度越快。

电商进销存软件：增长负责人避坑指南：做销售管理时别忽略选型踩坑

一、先讲核心结论：软件选型不是采购问题，而是增长模型问题

1. 先看结论：不要先问功能有多少，要先问订单能否被准确履约

我参与过不少电商系统选型和上线复盘，最明显的规律是：失败项目几乎都不是因为“少了一个功能”，而是因为企业没有定义清楚订单从产生到结算的责任边界。销售看到的是成交额，仓库看到的是可拣货库存，采购看到的是在途数量，财务看到的却是扣除退款、平台佣金和优惠后的实际收入。

如果这几套口径不能在同一套业务规则下对齐，系统即使拥有采购、销售、库存、报表等完整模块，也只是把原来的混乱搬进了软件。真正值得采购的，不是功能清单最丰富的产品，而是能让关键业务口径稳定、异常可追溯、数据能驱动下一步动作的系统。

我判断一套电商进销存系统是否值得上线，通常先看四个结果：销售订单能否自动分配到正确仓库，库存是否区分可售、锁定、在途和质检状态，退货是否能回到原订单和原批次，经营报表是否能解释利润变化。只要其中两个环节依赖人工二次整理，后续的增长分析就很容易失真。

2. 选型的第一性原理：把“销售管理”还原成一条闭环

增长负责人不应把销售管理理解为“记录客户和订单”。在电商场景里，销售管理至少包括流量进入后形成订单、订单占用库存、库存触发补货、采购完成入库、仓库完成履约、售后形成退款、财务完成对账这七个相互影响的动作。

其中任何一环延迟，都会在下一环产生放大效应。例如销售团队为了完成活动目标提前放量，系统却没有扣除锁定库存，客户下单后才发现无法发货。此时表面问题是缺货，实际问题是销售承诺没有读取供应链约束。

我更看重系统能否给销售团队提供“可承诺库存”，而不是简单展示“账面库存”。可承诺库存通常应综合现有可售库存、已锁定数量、在途采购、预计入库时间、渠道预留和安全库存。这样销售在制定活动和报价时，才不会把仓库暂时不能交付的数量当成可销售资源。

3. 规模越小，越不能忽略数据结构和权限

很多中小电商团队认为，业务规模不大，先用表格和简单工具过渡即可。我的经验是，规模小的时候确实可以容忍部分人工操作，但不能容忍基础数据没有统一规则。商品编码、规格、组合装、赠品、仓库、供应商和渠道名称一旦重复，后期迁移的成本往往比早期规范成本高得多。

权限也是经常被低估的基础设施。销售可以改价，运营可以改促销，仓库可以调整库存，采购可以修改到货日期，财务可以冲销金额，这些操作如果没有审批和日志，企业很难判断利润下降究竟来自市场变化、活动策略还是人为修改。

我会建议增长负责人在选型前先画出“谁能看、谁能改、谁要审批、谁负责复核”的权限矩阵。权限越模糊，后面越容易出现“大家都能操作，但没有人真正负责”的情况。

二、背景和真实场景：销售增长为什么会把库存和结算问题一起放大

1. 电商增长已经不是单纯的流量增长

国家统计局发布的相关数据表明，2024年全国网上零售额达到约15.52万亿元，同比增长7.2%；其中实物商品网上零售额约13.08万亿元，同比增长6.5%。这说明电商仍然是巨大的交易场，但增长环境已经从“只要上架就有机会”转向精细化运营。

在这样的环境里，企业往往同时经营自营商城、综合电商平台、内容电商、社群分销、直播间和线下渠道。不同渠道的订单格式、结算周期、优惠规则、售后责任和发货承诺都可能不同。销售额看起来可以合并，实际经营规则却不能简单相加。

我在复盘一家具备多个销售渠道的消费品企业时，发现它的核心矛盾并不是没有库存，而是库存被不同渠道重复承诺。直播间按总库存推品，商城按可售库存推品，分销商又提前锁定了一部分货。三个团队都认为自己看到的是“真实库存”，最终却有超过一成订单需要人工改仓或延迟发货。

2. 最常见的真实场景：销售完成了，企业却没有赚到钱

有一个典型案例值得警惕。一家日用品商家在大促期间支付金额增长约42%，管理层认为活动效果很好。活动结束后，财务按渠道核算发现，退款、平台扣点、达人佣金、赠品和仓配费用合计增加得更快，活动商品的实际毛利率从约28%下降到约11%。

问题不是活动本身，而是系统只把支付订单当作销售结果，没有把优惠分摊、赠品成本、渠道服务费和售后损失回填到商品及订单维度。增长团队因此把“高支付金额”误判成“高价值商品”，下一次活动继续加大资源投入，利润进一步被稀释。

我认为，销售管理至少要同时看三个层次：成交层看订单和金额，履约层看发货、签收和售后，经营层看毛利、现金回款和库存占用。只看第一层，增长团队很容易在数据上自我激励，在现金流上被动承压。

3. 销售、仓库、采购、财务为什么总是在争论同一个数字

一个数字出现多个版本，通常不是谁算错了，而是每个部门的统计时点不同。销售在上午看的是下单数，仓库在下午看的是已审核并可拣货的订单，财务月底看的是扣除退款后的结算单，采购关注的是预计到货而不是已入库数量。

如果系统没有明确订单状态和库存状态，部门之间的争论就会从业务问题变成口径争论。增长负责人此时很难判断真实转化率、真实缺货率和真实毛利，管理层也无法根据报表及时调整价格、补货或投放。

三、常见误区：看似买到了系统，实际上买回了新的手工活

1. 误区一：把功能数量当成选型评分

供应商演示时，功能数量最容易制造安全感。采购人员会记录是否有采购单、销售单、库存预警、报表、审批流和移动端，却很少追问这些功能在真实订单异常时如何协同。一个系统拥有十个报表，不代表它能回答“哪一场活动造成了哪一批库存积压”。

我会要求演示人员不要只展示标准流程，而要现场处理异常订单：一个商品同时参加满减和赠品活动，客户拆成两单，仓库有两个发货地，其中一仓缺货，客户又申请部分退款。能否把这类复杂场景讲清楚，比演示页面上有多少按钮更能反映系统的实际能力。

2. 误区二：只让财务或仓库主导，增长团队却不参与

财务和仓库是系统使用的核心部门，但增长负责人如果不参与选型，系统很可能只解决记账和出入库，无法支持商品决策、活动复盘和渠道经营。销售团队需要知道什么货能卖、能卖多少、什么时间能交付，运营团队需要知道促销后毛利是否仍然健康。

我见过一种常见结果：仓库系统上线后，库存准确率提高了，但运营仍然需要每天把销售数据导出到表格里，手工计算活动毛利和渠道费用。对于增长团队来说，这并不是真正的数字化，只是把仓库的准确性和运营的手工分析并存了下来。

3. 误区三：把“实时库存”理解成所有库存都能随时卖

实时只说明数据更新及时，不代表这个数字具备销售意义。库存可能处于待检、残次、已锁定、渠道预留、在途、待入库或冻结状态。把所有状态相加展示为一个总数，会让销售误以为货物充足。

我建议至少把库存拆成五个可解释的状态：现有库存、可售库存、锁定库存、在途库存和不可售库存。对于有保质期、批次或序列号管理要求的商品，还要进一步确认系统能否按批次进行先进先出、临期预警和召回追踪。

4. 误区四：只看首次报价，不看三年总成本

低价方案不一定便宜，高价方案也不一定适合。真正的成本包括软件许可、接口费用、实施服务、历史数据清洗、培训、定制开发、仓库设备改造、售后支持和后续账号扩展。很多企业只比较首年采购价，忽略了每月人工对账和异常处理的隐性成本。

我通常会把人工成本折算进去。例如一个团队每月有4个人各投入30小时做订单、库存和结算核对，按每小时综合人力成本80元计算，每月隐性成本就是9600元，一年约11.52万元。若系统年费便宜3万元，却让企业长期保留这类工作，实际并没有省钱。

5. 误区五：没有把实施失败纳入选型风险

系统能不能上线，不只取决于软件，也取决于主数据和流程纪律。商品编码混乱、历史库存不准、供应商资料重复、仓库盘点不完整，都会让系统在上线第一周暴露问题。此时团队常常把责任推给软件，实际上是前期没有留出数据治理和试运行时间。

我在项目中最看重供应商是否愿意把实施边界写清楚：谁负责数据清洗，谁负责接口联调，谁确认业务规则，谁签署上线验收，出现库存差异时谁负责定位。只承诺“快速上线”的方案，往往没有说明“谁来承担复杂部分”。

四、专业判断逻辑：用业务证据筛选，而不是被演示牵着走

1. 第一步：先画业务链路，再列功能清单

我建议选型前先画出从“商品建立”到“利润确认”的完整链路，并在每个节点标出输入、处理、输出和责任人。不要从“系统有哪些模块”开始，因为模块是供应商的语言，链路才是企业自己的语言。

1. 商品建立：确认商品、规格、组合装、赠品、成本和条码的主数据来源。
2. 渠道接单：确认订单如何进入系统，重复订单、异常地址和价格异常如何拦截。
3. 库存分配：确认仓库优先级、渠道预留、锁定规则和缺货后的替代方案。
4. 采购补货：确认安全库存、采购周期、最小起订量和在途库存如何参与计算。
5. 仓库履约：确认拣货、复核、出库、物流单号和异常件如何回写。
6. 售后结算：确认退货入库、退款、平台费用、佣金和毛利如何关联到原订单。

这张链路图的价值在于，它会迫使团队发现一些通常被忽视的断点。例如，销售要求系统提供“爆款排行”，但商品成本没有按批次维护，退货没有回到原销售订单，所谓爆款排行最终只能按销售金额排序，而不能判断真实利润。

2. 第二步：给关键场景设置“一票否决项”

不是所有需求都值得高成本定制，但有些场景一旦失败，就会直接影响现金流或客户体验。我通常会把这些内容设为一票否决项：库存扣减准确性、订单幂等性、退款回写、权限审计、批次追踪和关键接口稳定性。

一票否决不是要求系统一次性解决所有问题，而是要求供应商明确说明实现方式、边界和验证方法。如果供应商只说“可以定制”，却说不清楚由谁开发、如何测试、何时交付、失败如何回滚，就不能把它当成已经具备的能力。

3. 第三步：用加权模型区分“必须有”和“有了更好”

我建议建立一个至少包含五个维度的评分模型，并按照企业当前阶段设置权重。订单规模较小但渠道复杂的企业，应提高流程灵活性和接口能力的权重；库存金额高、SKU多的企业，应提高库存准确性、批次能力和成本核算的权重。

4. 第四步：要求供应商用你的数据演示，而不是用样板数据演示

样板数据几乎总是干净的，真实数据则会暴露重复规格、空地址、异常价格、组合装和历史退货。选型阶段至少准备一组脱敏数据，包含20到50个高频商品、3个主要渠道、2个仓库、若干组合装、赠品和近一个月的退款订单。

我会让供应商现场完成五个动作：导入商品，接收订单，按规则分仓，处理部分退款，再按渠道和商品输出毛利。每个动作都要记录耗时、人工步骤、异常提示和最终数据是否能回溯到原单。

如果演示必须由供应商顾问手工修改数据库、导出后再计算，或者无法展示异常日志，那么即使页面看起来流畅，也不能认定系统适合正式运营。

5. 第五步：把“可验证”写进合同和验收标准

选型文档里最有价值的不是功能描述，而是验收指标。例如，订单同步成功率不低于99.5%，重复订单率低于某个约定阈值，库存盘点差异率低于1%，关键异常必须在规定时间内有日志和责任人。

指标要结合企业基础水平设置，不能为了好看而虚构精确目标。上线前可以先用两周历史订单做基线，上线后再比较同一渠道、同一仓库、同一订单类型的变化，避免把业务结构变化误判成系统效果。

五、案例与数据观察：一个看似成功的上线，为什么仍然可能失败

1. 案例背景：订单增长后，团队开始每天救火

下面这个案例来自匿名项目复盘，企业名称、商品名称和金额已做脱敏及情景化处理，但问题结构和指标口径保留了真实项目中常见的特点。该企业销售多个线上渠道，拥有约1800个活跃SKU、2个仓库，月均订单约6万单。

系统上线前，团队使用多个表格分别管理渠道订单、采购到货、仓库库存和退款数据。销售每天早上看一次库存，运营下午再导出一次订单，财务月底按照平台账单重新核对。大家都很忙，但没有任何一个人能在当天回答“某个活动商品现在还能卖多少、预计什么时候补货、卖一件到底赚多少”。

上线前一个月，订单履约准时率约86%，人工改仓订单占比约9%，库存盘点差异率约6.8%，月度对账耗时约92小时。最严重的问题不是某一个指标低，而是异常没有统一入口，团队只能靠经验寻找责任人。

2. 改造动作：先收缩范围，再逐步扩展

项目没有一开始就把所有渠道和历史数据全部接入，而是选择一个主渠道、一个仓库和80个高频SKU做试运行。我们先冻结商品编码规则，清理重复规格，确认组合装和赠品的库存扣减方式，再处理订单同步和退货回写。

试运行阶段只关注四个指标：订单是否完整进入系统，库存是否按状态扣减，仓库是否能按系统任务发货，退款是否能回到原订单。其他高级报表暂时不做，避免团队在基础链路没有稳定前就分散精力。

第二阶段才接入另一个仓库和其他渠道，并增加采购建议、渠道预留和活动毛利分析。这样做的缺点是前期看起来进度不快，优点是每个问题都能被定位，不会在一次大切换中同时出现几十种异常。

3. 结果观察：效率提升来自减少返工，而不是让员工按得更快

经过约12周的分阶段上线，试点范围内的准时履约率从86%提高到94%，人工改仓订单占比从9%降至3.1%，盘点差异率从6.8%降至1.7%，月度对账耗时从92小时降至29小时。

值得注意的是，仓库员工的操作次数并没有简单减少。系统增加了扫码复核、异常原因选择和退货质检步骤，但这些动作替代了后续的人工追单和反复核对。数字化效率不是让每个人少做一步，而是让错误尽早暴露，避免错误在流程末端变成更昂贵的返工。

项目也暴露了一个没有被预估的短板：活动毛利在第一个月仍然不稳定，因为部分渠道费用账单晚于订单发生时间。后来团队把“订单预计毛利”和“结算确认毛利”分开展示，避免运营把估算值当成最终财务结果。

4. 失败的地方：没有提前定义“活动毛利”的确认时间

这个项目并非所有指标都一次达标。活动毛利在上线初期仍然受到账单延迟影响，运营报表中的预计费用和财务最终结算存在差异。若团队把两者混成一个数字，管理层会认为系统不准确，实际上是业务确认时间不同。

后续我们把毛利拆成三个状态：下单时的预测毛利、发货后的履约毛利、结算后的确认毛利。每个状态都标明数据来源和更新时间，运营用于快速决策，财务用于最终核算。这个改动看似只是报表字段调整，却减少了很多跨部门争执。

六、不同情况下的行动建议：不要用同一套方案解决所有企业

1. 如果你处于单渠道、单仓库、SKU较少阶段

这类企业的第一目标不是购买复杂系统，而是把商品、订单、库存和收付款建立统一口径。系统应该足够简单，让业务人员愿意每天使用，并能导出可审计的数据。

• 优先确认商品编码、规格、组合装和赠品规则。
• 优先确认订单状态、库存状态和退款状态是否可追溯。
• 优先选择配置清晰、培训成本低、基础接口稳定的方案。
• 暂时不要为复杂预测、深度定制和过多报表支付高额成本。

这个阶段最容易犯的错误，是把未来五年的复杂需求全部提前买下。企业还没有稳定的业务流程时，复杂系统只会增加学习成本。更合理的做法是保留扩展接口和数据导出能力，先把基础数据做干净。

2. 如果你处于多渠道、多仓库和活动频繁阶段

这类企业的核心问题通常是库存分配和订单履约，而不是缺少一个销售报表。选型时要重点测试多仓优先级、渠道预留、活动锁库存、拆单合单、缺货转仓和售后回库。

• 用真实活动规则测试满减、赠品、组合装和部分退款。
• 要求系统同时展示账面库存、可售库存、锁定库存和在途库存。
• 确认订单同步失败是否会自动重试，并能查看失败原因。
• 确认仓库异常能否回传销售和客服，而不是停留在仓库内部。
• 按渠道和活动计算贡献毛利，不要只看商品销售额。

这个阶段可以接受一定的配置复杂度，但不能接受规则依赖个人记忆。只要一个关键分仓规则只能由某位运营经理解释，企业就存在明显的人员风险。

3. 如果你处于大促、直播和高峰订单阶段

高峰业务最重要的不是平时能否录入订单，而是突发流量下系统是否能保持数据一致。选型和压测时要关注接口限流、消息重复、订单幂等、库存并发扣减和异常恢复，而不是只看日常页面操作。

我建议至少进行三种演练：一是订单突然增加时能否持续接单，二是库存不足时能否准确阻止超卖，三是接口中断后恢复时能否避免重复订单。演练必须留下日志和结果，不要只听供应商口头说明。

高峰期还要提前规定人工应急方案。例如系统短暂中断时，哪些渠道可以暂停销售，哪些商品可以限制库存，仓库如何获取最后一次可靠的拣货清单。没有应急预案的自动化，遇到故障时反而可能比人工更难恢复。

4. 如果你处于多组织、多品牌或复杂供应链阶段

此时选型重点会从“能否用”转向“能否控制”。组织、仓库、渠道、供应商、货主和结算主体之间的权限与核算边界必须清晰，否则数据虽然集中，责任却更加模糊。

• 确认不同组织是否可以独立核算，同时支持集团层面的汇总分析。
• 确认商品成本是按采购批次、移动平均还是其他规则计算。
• 确认跨仓调拨、代销、寄售和委外业务是否有独立流程。
• 确认价格、库存、退款和采购合同的修改是否完整留痕。
• 确认系统是否支持按组织和岗位设置数据可见范围。

这类企业不一定要选择最复杂的平台，但一定要选择边界表达清楚的方案。复杂业务最怕“表面上都支持，实际靠定制拼接”，因为每一次定制都会增加后续升级和排障成本。

七、不同情况下的取舍：系统越强不等于决策越正确

1. 低成本快速上线，与深度定制之间怎么选

标准化方案的优点是上线快、成本相对可控、后续升级路径清晰，缺点是某些特殊流程可能需要调整业务习惯。深度定制的优点是贴合现有流程，缺点是需求变更、测试和后续维护成本都更高。

我的判断原则是：如果流程是企业真正的竞争壁垒，可以考虑定制；如果只是历史习惯，不应轻易定制。比如独特的计费模型、复杂的批次规则可能值得保留；某个员工习惯用特殊字段记录备注，通常不值得为此修改系统。

2. 一体化系统，与多个专业系统组合之间怎么选

一体化系统便于统一数据和权限，适合希望减少系统数量的团队；多个专业系统可以在各自领域做得更深，但需要承担接口、主数据和故障排查的责任。

如果企业的主要痛点是数据分散、员工重复录入，一体化方案通常更容易产生价值。如果企业已经拥有成熟的仓储、财务和客户系统，贸然全部替换可能带来更大的迁移风险，此时应先确认哪个系统是主数据源，再设计接口边界。

我特别反对“每个部门都选自己最喜欢的工具，再让接口解决一切”的做法。接口不能自动解决业务口径冲突，系统越多，越需要明确商品、客户、订单、库存和结算的唯一主责系统。

3. 追求实时，与保留人工复核之间怎么选

实时数据很重要，但并非所有动作都适合自动化。高金额采购、异常退款、库存盘盈盘亏和价格大幅调整，仍然需要人工复核。自动化的目标不是取消所有判断，而是把人工判断集中到真正高风险的环节。

我会把业务动作分成三类：低风险且高频的动作自动执行，中风险动作自动建议并由负责人确认，高风险动作必须审批并留下完整证据。这样既能提高日常效率，也能避免系统把错误快速扩散。

4. 看短期回报，与看长期数据资产之间怎么选

有些系统上线后很快能减少录入和对账时间，但未必马上提升销售额；有些系统前期投入较大，却能持续沉淀商品、客户、渠道、库存和利润数据。增长负责人不能只用一个月的销售增幅评价系统，也不能无限期等待所谓长期价值。

我的做法是把收益拆成三类：三个月内可观察的效率收益，例如对账耗时和人工改单减少；六个月内可观察的经营收益，例如缺货率、库存周转和活动毛利改善；一年以上的数据收益，例如预测准确度、供应商议价和渠道资源分配能力提升。

八、下一步怎么做：用一个小范围验证替代一次性押注

1. 用七天完成选型前的业务盘点

第一天盘点渠道、仓库和订单入口，明确哪些渠道必须接入，哪些可以暂缓。第二天盘点商品主数据，找出重复编码、规格不一致、组合装和赠品。第三天盘点库存状态，区分可售、锁定、在途、质检和残次。

第四天盘点订单异常，统计取消、改地址、拆单、合单、部分退款和换货。第五天盘点采购与供应商，确认采购周期、最小起订量、安全库存和在途规则。第六天盘点报表，区分销售看板、仓库看板、采购看板和财务报表。第七天确定首期范围、验收指标和项目负责人。

这七天不是为了写一份漂亮的需求文档，而是为了找出最贵的业务错误。企业不需要一开始就把所有需求表达完，但必须先知道哪三类错误一旦发生，就会影响客户、现金流或库存。

2. 用真实数据做一次小型压力测试

准备一组脱敏数据，至少包含一个高频商品、一个低频商品、一个组合装、一个赠品、一个有退款的订单和一个库存不足的订单。让候选方案完成从订单进入、库存锁定、分仓发货到退款回写的完整流程。

1. 记录从导入数据到完成订单分配需要多少人工步骤。
2. 检查每个库存变化是否都有原因、时间和操作人。
3. 制造一次接口重复推送，观察系统是否会生成重复订单。
4. 制造一次部分退款，检查商品数量、金额和库存是否正确回写。
5. 导出经营报表，确认销售额、退款、费用和毛利的口径是否可解释。

测试结束后，不要只问“能不能用”，而要问“异常发生时，谁能在多长时间内定位”。系统的稳定价值不在于正常订单处理得多漂亮，而在于异常订单出现后不会让整个团队失去方向。

3. 设定上线后的四组核心指标

第一组是销售与履约指标，包括订单同步成功率、准时发货率、取消率和售后率。第二组是库存指标，包括库存差异率、缺货率、库存周转天数和滞销库存占比。第三组是经营指标，包括活动贡献毛利、渠道净收入、退款损失和采购资金占用。

第四组是系统使用指标，包括异常关闭时长、人工改单率、报表使用频次和关键字段完整率。很多系统上线后看起来没有效果，原因是团队仍然绕开系统使用表格。使用率本身不是最终目标，但它能反映流程是否真正进入日常工作。

4. 让选型结果由增长、供应链、财务共同签字

增长负责人负责确认销售和活动场景，供应链负责人负责确认库存、采购和履约，财务负责人负责确认成本、退款和结算。三方必须共同参与测试和验收，不能由一个部门替所有人做决定。

如果三方意见不一致，不要急着投票。先把争议转成可验证的问题，例如“组合装是否按套扣库存”“部分退款后毛利如何分摊”“跨仓发货费用由哪个渠道承担”。争议一旦变成具体规则，通常就能通过测试数据和财务口径解决。

5. 最后的判断：买之前先问三个问题

第一个问题是，如果订单量在三个月内增加一倍，当前方案最先会在哪个环节失效。这个问题能帮助团队提前识别接口、仓库、权限和人工核对的瓶颈。

第二个问题是，如果今天出现一笔异常订单，系统能否在五分钟内告诉我发生了什么、谁处理过、下一步该做什么。这个问题比“有没有异常报表”更能验证系统的可操作性。

第三个问题是，如果更换一个运营负责人，业务规则能否继续运行。若答案是否定的，说明企业买到的可能只是个人经验的电子化，而不是可复制的经营能力。

我对电商进销存软件选型的最终判断是：增长负责人真正要买的不是一套记录交易的工具，而是一套限制错误扩散、解释利润变化、连接销售承诺与供应链能力的经营基础设施。

下一步不要先安排一场只看功能的产品演示。先拿出最近一个月的真实订单、库存差异和退款记录，画出从成交到结算的链路，找出最昂贵的三个断点，再让候选方案用你的数据现场验证。能经得住异常场景、真实口径和三个月复盘的方案，才值得进入正式采购。