B2B订货与S2B2C供应链小程序方案前期需要准备哪些资料？

这类项目最容易卡住的地方，往往不是少了一张图片，而是同一笔生意在不同人嘴里有不同版本。

业务负责人说，这是给经销商补货用的订货平台；运营希望经销商还能把商品转发给消费者；财务理解的是平台统一收款后再结算；供应链团队却按经销商先采购、再自行销售来备货。四种说法都能画成功能，但对应的账户、订单、库存、资金和责任完全不同。

所以，红数科技在方案前期会先拿一笔真实订单来问：谁向谁下单，谁收钱，谁开票，哪个仓库发货，发生退款时谁承担。这个问题没有答清楚，商城首页做得再漂亮，报价和工期也只能是一个大概数。

先画清交易关系，再谈小程序有哪些功能

“B2B 订货”和“S2B2C”不是一套固定的软件模板。前者通常解决企业客户、经销商或门店向上游订货的问题；后者还可能把供应商、供应链平台、渠道商和消费者连在一起。渠道商究竟是买货后自行销售，还是只负责推广并取得佣金，会直接改变订单和结算设计。

前期资料里应有一张能够看懂的业务关系图，并用几句话写清以下内容：

• 供应商、品牌方、平台公司、经销商、门店和消费者分别是谁；
• 商品所有权在哪个节点发生变化，谁是每一段交易的销售方；
• 消费者订单由谁收款、开票、发货和处理售后；
• 经销商是赚进销差价、佣金、服务费还是阶段返利；
• 平台是否允许多个供应商入驻，供应商能看见和处理哪些订单；
• 一张订单是否可能由多个仓库或多个供应商拆开发货；
• 赊销、预存款、在线支付和线下转账分别用在哪些客户与场景。

把资金流、货物流、订单流和发票流画在同一张图上，很容易发现口头需求里的矛盾。比如平台准备统一收消费者货款，却没有确定自己在交易中的身份；又或者供应商直接发货，经销商却要对发货时效和退换货作出承诺。这里涉及合同、税务或特定行业监管的内容，应由企业财务、法务和业务负责人按真实模式确认，开发方不能替经营主体下结论。

主体资质、平台账号和责任人资料

交易关系确认以后，再整理主体和账号资料。营业执照只是其中一项，名称、证照主体、收款主体、开票主体和小程序主办单位是否一致，也要一起核对。

截至 2026 年 7 月，微信开放文档仍分别提供小程序备案操作指引、开放服务类目和微信支付接入指引。具体申请材料会随着主体类型、服务类目和支付场景变化，准备阶段应直接核对当前申请页面，不要拿旧项目的材料清单照搬。

组织、客户和权限资料，要反映真实的销售管理方式

B2B 订货系统里，一个“客户账号”通常不够用。总部下面可能有区域公司，经销商下面有多家门店，一家公司里又有采购员、审批人、收货人和财务人员。有人可以看全部商品，但只能看自己的协议价；有人可以创建订单，却不能直接提交；区域经理需要看辖区数据，也不应该看见其他区域的客户。

建议先准备一份组织与客户主表，至少包括：

• 企业客户、经销商、门店的唯一编码、名称、归属区域和业务负责人；
• 客户类型、等级、渠道、授权品牌或可售区域；
• 合同有效期、结算方式、账期、信用额度和欠款处理规则；
• 采购员、审核人、收货人、财务等账号及权限；
• 常用收货地址、开票资料、税号和对账联系人；
• 新客户申请、资质审核、停用、转区域和恢复合作的处理方式。

如果需要把旧系统客户迁进来，还要处理重复名称、一个手机号关联多家公司、历史欠款和失效合同。不要只给一份销售通讯录。系统真正需要的是能够判断“这个账号代表哪家公司、可以按什么条件买哪些货”的客户资料。

商品资料必须落到可订购的SKU和包装单位

B2B 订货经常同时使用件、盒、箱、托等单位。同一商品按箱订货、按件扣库存，或者整箱与拆零价格不同，都会影响购物车、库存和发货。商品表如果只写商品名称和一个价格，开发阶段无法确认订单到底买了什么。

商品资料建议一行对应一个可独立定价、管理库存或履约的 SKU，写清商品编码、规格、条码、品牌、分类、图片、参数、包装清单、保质期或批次要求。订货相关字段还应包括最小起订量、整箱数量、单位换算、订货倍数、销售区域、可售客户、默认仓库、交期、限购和退换条件。

供应商较多时，要另外保存供应商货号和平台商品编码的对应关系。两家供应商都把商品叫“经典款”，系统仍然需要稳定的编码来区分采购、库存、订单和结算。

商品主图、规格图和详情资料要提供可用原文件，并确认品牌和图片授权。影响检索、筛选、价格或履约的信息应保留成字段，不能全部埋在一张详情长图里。

价格不是一个数字，要写清适用条件和计算顺序

同一个 SKU 可能有经销价、门店价、区域价、客户协议价、阶梯价和活动价。哪一个价格生效，取决于客户、渠道、数量、时间、地区、税费口径和合同。前期应准备真实价格样本，不要只写一句“支持千人千价”。

至少要确认这些问题：

• 未登录或未审核的客户能不能看价格；
• 价格含税还是未税，运费是否另算，金额如何取整；
• 阶梯价按单个 SKU 数量算，还是按系列、整单或累计采购量算；
• 客户协议价、活动价和阶梯价同时满足时听哪一个；
• 满减、优惠券、赠品、返利和包邮是否叠加；
• 改价是否需要审批，已经提交的订单是否保留原价格；
• 部分退款时，优惠、运费、返利和赠品怎样回退。

选三到五个有代表性的客户，再选几种价格情况，把系统最终应显示的金额手工算一遍。财务、销售和运营算出的结果一致，这套规则才适合交给开发。

订单资料要把正常流程和例外一起写出来

标准下单只是最短的一条路。真实的企业采购还可能经过询价、报价、合同、采购单上传、内部审批、平台审核、信用检查、付款和财务确认。先确定项目真正需要哪几步，不必因为别的平台有就全部加入。

可以拿一笔订单从创建走到结束：谁能代客下单；订单超过额度或低于起订量怎么办；缺货时是阻止提交、允许预售还是等待审核；线下转账怎样认款；未付款、已付款、配货中、部分发货、已完成和已取消分别由什么动作触发；订单修改后是否重新审批。

再单独走一遍异常情况。部分商品缺货能否先发其余商品，客户拒收怎样记录，一张订单能否多次发货，售后申请到哪个主体，退货入哪个仓，换货是否生成新单。只有状态名称，没有进入和退出条件，后台很快会出现谁也解释不清的“处理中”。

库存、仓库和履约资料决定承诺能不能兑现

多仓和供应商代发是 S2B2C 项目里很容易低估的部分。企业需要明确哪套系统记录真实库存，库存按“SKU + 仓库”还是还要细到批次、库位和效期。页面显示的可售量也不一定等于仓库现存量，它可能还要扣掉已占用、冻结和安全库存。

前期应提供仓库清单、覆盖区域、发货时段、合作物流、运费模板、拆单规则、缺货处理和退货地址。若平台会自动分仓，需要给出优先级：按距离、成本、库存完整率、供应商归属，还是由运营人工选择。食品、化妆品等涉及批次和效期的商品，还要确认先进先出、临期限制与售后回库条件。

库存同步不能只写“对接 ERP”。需要确认商品、库存、订单和物流各自以哪套系统为准，多久同步一次，接口失败以后谁处理，重复推送会不会造成重复扣减。没有接口文档时，可以先把这部分列为待验证范围，不能直接承诺实时双向同步。

对账、分账、佣金和返利要由财务给出口径

订货系统做到了支付成功，还没有完成交易。供应商要对账，经销商可能有返利或佣金，平台可能收服务费，售后又会改变原来的结算金额。这里应先由财务提供几张脱敏后的真实单据和计算样例。

需要确认结算对象、结算周期、结算依据和调整方式。按支付、发货、签收还是售后期结束后结算；退款发生在结算前后分别怎样处理；佣金按含税商品金额、实收金额还是扣除运费后的金额计算；季度返利如何累计，退货是否冲回；平台、供应商和经销商分别开什么票。

“自动分账”也要区分业务计算与支付机构实际提供的产品能力。先确认资金路径和合同关系，再核对商户号、账户体系及可用接口。未经平台和财务验证，不要把页面上算得出金额等同于资金可以自动划转。

现有系统和历史数据，需要交到字段与接口层面

如果项目要连接 ERP、WMS、OMS、CRM、财务、电子发票、物流、客服或企业微信，准备系统名称远远不够。还要提供版本、部署方式、已购模块、开放接口文档、测试环境、测试账号、调用限制、字段说明和对接负责人。

每一类核心数据都要确定最终来源。商品由 ERP 下发还是小程序后台维护，客户等级由 CRM 还是订货系统管理，库存冲突时相信 WMS 还是 ERP，订单状态由谁回传。数据来源没有定，双向同步很容易变成两个系统互相覆盖。

历史数据也要先选范围。客户、商品、未完成订单、余额、欠款、返利和历史对账单的迁移难度不同。旧编码与新编码怎样对应，迁移日以后旧系统是否只读，都应在方案里留下明确答案。

隐私、协议和平台规则要跟着功能准备

小程序收集手机号、收货地址、定位、发票信息或采购联系人资料，应当与实际功能相对应。前期可以做一张个人信息清单，写明在哪个页面收集、用于什么、是否必需、保存多久、谁能查看、是否提供给第三方，以及用户怎样行使查询、更正、删除等权利。

微信开放文档提供了用户隐私保护指引的填写要求。《个人信息保护法》要求处理个人信息有明确、合理的目的，并与处理目的直接相关；不能因为以后“可能用到”，就把权限和字段一次收全。

交易页面还应准备平台服务协议、订货规则、价格与运费说明、发票说明、交付和售后规则。平台型业务应结合真实经营模式，核对经营者信息展示、平台内经营者管理和交易记录保存等责任。《电子商务法》和《网络交易监督管理办法》给出了基本要求；涉及消费者订单时，还要按实际商品和交易场景复核消费者权益相关规则。

开工资料要能支持原型、报价和验收

资料齐不齐，可以用一个很朴素的办法判断：产品人员能不能据此画出页面和状态，开发人员能不能确定字段与接口，测试人员能不能判断每个结果对不对。

正式开工前，建议确认页面原型、功能清单、角色权限、数据字典、接口范围、非功能要求和验收用例。企业内部指定一位有权协调业务、销售、供应链、财务和技术的负责人，其他意见由他汇总。否则同一个“价格调整”，销售理解为改单价，财务理解为重算税额，仓库又认为订单已经不能改，项目只能反复返工。

整理文件时，可以采用下面的目录。没有准备好的项目不用留空糊弄过去，写明负责人和最晚确认时间更有用。

01_业务模式与交易关系
02_主体资质与平台账号
03_组织客户与角色权限
04_供应商商品与SKU资料
05_价格促销与信用政策
06_订单审批与支付规则
07_库存仓储物流与售后
08_对账结算佣金与发票
09_现有系统接口与迁移
10_协议隐私与合规材料
11_原型确认与验收用例

资料不必等到百分之百齐全才开始梳理，但交易主体、收款与开票路径、客户价格、库存来源、订单状态和结算口径不能带着模糊答案进入开发。它们一旦改变，受影响的通常不只是一个页面，而是账户、订单、财务和后台权限整条业务线。

前期准备真正完成时，团队应当能拿出一个客户、一个 SKU 和一笔订单，从登录看到价格开始，一直讲到发货、退款、对账和开票。中间每个数字从哪里来、每个动作由谁完成，都有资料可查。到了这个程度，小程序方案才算从“想做什么”走到了“可以怎样做”。

参考资料

以下公开资料核验于 2026 年 7 月 24 日。平台材料、服务类目和接口能力会调整，实际申请与配置应以当时的官方页面为准。