B2B订货商城小程序

这是企业订货系统，不是零售商城换个名称

B2C商城通常对所有消费者展示统一零售价，付款后直接发货。B2B订货的前提是先确认客户是谁，再决定他能看什么、按什么价格买、最少买多少、能否使用账期以及订单是否需要审批。

本服务默认是供货企业自营：商品由同一企业管理，客户向该企业订货，订单和收款也归该企业。多个供应商入驻、撮合交易、平台抽佣和商户分账不会作为普通B2B功能顺带加入，因为那会改变合同关系、资金处理、数据权限和平台责任。

传统订货为什么越忙越容易错

不少批发企业仍靠微信消息、电话、Excel和手写单接单。熟客少时还能应付，客户和SKU增加后，同一个商品在不同群里出现不同报价，销售反复查库存，订单内容还要重新录入ERP。问题通常不在销售不努力，而在规则散落在个人手里。

真正可用的B2B商城，需要先把企业已经执行的销售规则写清楚。若实际业务允许销售人员临时改价、部分商品按合同价、部分客户先款后货，就不能用一张简单的等级价格表强行解决。

从客户申请到完成一笔采购

一个常见的企业订货过程是：客户提交企业资料，销售或管理员审核，通过后分配客户等级、区域、业务员、可购范围和付款条件。采购人员登录小程序，按品类、商品编码或历史订单找货，填写数量，系统检查价格、起订量、包装倍数、库存和授信，再生成订单进入付款、审核或备货。

企业账号要区分主体和使用人。一个客户公司可能有多名采购员、审批人和财务人员，地址与发票资料由企业共用，但订单查看范围和操作权限不同。离职人员的账号应能停用，不应继续看到价格、订单或客户资料。

价格和购买条件必须算得准

B2B价格通常比零售复杂，常见做法包括客户等级价、客户单独合同价、区域价、数量阶梯价和限时协议价。开发前要确定优先顺序，避免同一订单同时符合多种价格却没有明确结果。

页面上显示什么价格，也要有明确规则。未登录访客可以不显示价格、显示建议价或提示申请企业账号；审核通过的客户只看到自己有权购买的商品和价格。管理后台导出订单、生成对账单和传入ERP时，必须使用订单成交时保存的价格，不能因为后台后来改价就改变历史订单。

授信和账期不是加一个开关

账期客户下单时没有立即付清，系统需要知道可用额度、已占用额度、待还款、到期日和逾期状态。额度在订单提交、审核、发货还是出库时占用，订单取消或退货后如何释放，都要按企业财务制度确认。

小程序可以执行已经确认的授信规则，但不能替企业判断客户信用，也不能替代财务审批。客户的额度、账期和放行结果由企业授权人员负责。若需要与财务或ERP系统共用余额数据，还要确定哪个系统是最终依据以及同步失败时是否禁止继续下单。

管理后台要适合销售、仓库和财务一起用

业务员的数据权限尤其要提前确认。有人只能查看自己负责的客户，有人负责一个区域，也有人需要代客户下单。代下单、改价、人工放行授信和线下收款核销都属于重要操作，应记录操作人、时间、修改前后内容和原因。

ERP和仓库对接要写到字段

“需要对接ERP”还不能直接估价。至少要确认商品、SKU、客户、价格、库存、订单、出库、物流、收款和退款中哪些数据要交换，哪个系统负责修改，多久同步一次。

例如，商品和库存以ERP为准，小程序只读取；客户申请先在小程序提交，审核后再传入ERP；订单由小程序创建，ERP审核出库后回传发货状态。这三类数据的方向并不相同。接口还应处理重复通知、网络超时、缺少字段、数据格式错误和第三方系统停机，成功与失败都要留记录，不能只做一次正常演示。

若现有系统没有开放接口，只能通过文件导入导出或人工处理，也应如实说明。定时交换Excel可以减少录入，但不等于实时同步，库存和价格仍可能存在时间差。

账号、支付和平台条件

企业需要准备与业务相符的小程序主体、AppID、微信认证、小程序备案、服务类目、服务器域名和相关经营资质。启用微信支付时，需要符合条件的微信支付商户号、结算账户与接口配置。消费者或采购人员授权的手机号、企业资料、地址和订单信息，应按实际功能说明用途并妥善保护。

企业采购常见的线下转账、账期和对公付款，不等于微信支付能力。线下款项由企业财务确认，系统负责保存凭证和核销结果；消费者通过微信支付的款项进入客户自己的商户账户，红数科技不代收营业款。

开发完成不代表平台一定审核通过。审核还取决于主体、类目、资质、页面内容、隐私说明和微信当期规定。红数科技负责按确认范围完成配置、提交和必要修改，企业负责提供真实有效的主体、商品、授权和经营资料。涉及平台能力变化时，以微信开放文档及微信支付商户平台的现行说明为准。

项目从规则确认开始

1. 了解业务：确认客户类型、商品、价格、订货方式、付款、仓库和现有系统。
2. 整理规则：列清客户等级、可见范围、价格顺序、起订量、审批、授信与订单状态。
3. 确认页面：完成注册、商品、快速订货、订单、对账及后台主要页面草图。
4. 设计界面：根据品牌资料设计小程序端与管理后台常用页面和状态。
5. 开发系统：完成小程序、后台、服务器程序、数据库和约定接口。
6. 平台联调：连接微信登录、支付、订阅消息及实际第三方系统。
7. 业务测试：用不同等级客户、不同价格和异常订单完成完整测试。
8. 审核发布：协助备案、类目、隐私说明、体验版、平台审核与发布。
9. 培训交接：培训销售、运营、仓库和管理员，交付合同约定资料。

设计确认后改变价格规则、订单审批或接口范围，会影响数据库、后台和测试，不只是改几个页面。每次变化都应书面确认影响，避免上线前才发现双方理解不同。

周期要看业务规则和接口条件

以下时间用于前期判断，正式排期以功能清单、资料和第三方接口条件为准。

如果客户资料、价格表、商品编码和包装单位本身不一致，整理时间也要计入项目。第三方系统未提供接口文档、测试环境或技术人员时，联调无法按开发方计划单独推进。平台审核时间同样受材料和平台处理影响，不承诺固定天数。

服务费用按确认范围核算

B2B商城的价格差异主要来自业务规则，不是小程序页面数量。一个只做等级价和在线支付的订货商城，与包含客户合同价、授信、分批发货和ERP双向同步的系统，开发与验收工作相差很大。红数科技会先确认业务，再提供对应报价。

报价会注明页面与功能范围、代表数据数量、第三方费用、接口数量和字段、源码与设计源文件是否交付、维护期限以及超出范围的计费方式。企业比较方案时，应重点看价格、授信、订单和接口规则是否写清，而不是只比较功能名称多少。

更适合哪些企业

• 工厂、品牌商、批发商，希望经销商或门店直接在线订货；
• 客户分级明显，不同客户执行不同商品范围和价格；
• SKU较多，客户经常一次采购几十种商品；
• 有起订量、整箱倍数、含税未税或区域价格要求；
• 支持先款后货、订金尾款、对公转账或授信账期；
• 销售每天大量查价、查库存、接单和重复录入；
• 已有ERP或仓库系统，希望减少人工重复处理；
• 需要把客户、价格、订单、欠款和售后权限收回企业统一管理。

如果交易对象主要是个人消费者，应选择B2C商城；若多个供应商分别入驻、收款和结算，应评估平台型商城；若各连锁门店有独立库存和履约，应按多门店系统设计。业务类型先选对，后续的报价和验收才有意义。

客户最终应拿到什么

• 已确认的客户、商品、价格、起订、审批、付款、发货和售后规则；
• 小程序页面草图、视觉设计稿和常用状态说明；
• 可提交微信审核的采购端小程序；
• 客户、商品、价格、订单、收款、发货、售后和权限后台；
• 服务器程序、数据库与部署配置，具体范围按开发方式确定；
• 微信登录、支付、订阅消息及合同约定的第三方接口；
• 代表客户、商品、价格、库存和订单测试数据；
• 功能、权限、支付、授信与接口测试记录；
• 备案、类目、隐私说明、平台审核和发布协助；
• 管理账号、操作说明、培训记录和后续维护边界；
• 合同约定的源码、部署包、设计源文件或第三方授权说明。

源码交付要看开发方式。独立定制项目可按合同交付自研源码和部署资料；基于开源系统时，第三方代码仍受原许可约束；使用SaaS时，客户通常取得使用权与自己的业务数据，不会获得平台全部源码。签约前应明确系统到期后的数据导出、续费和迁出条件。

验收要用不同客户跑真实采购单

验收客户不能只建一个默认等级。至少准备未审核客户、普通客户、重点客户、单独合同价客户和账期客户；商品要覆盖多规格、阶梯价、起订量、整箱倍数、缺货和停用；订单要覆盖审核通过、驳回、改价、在线支付、线下核销、额度不足、部分发货、取消和退货。系统在这些情况都算对，才适合正式给客户使用。

上线后的维护与责任

红数科技按合同提供约定期限内的程序故障修复、平台适配、接口检查、备份或技术维护，并完成客户、商品、价格、订单和权限后台培训。企业负责客户审核、合同价格、授信决定、财务核销、商品资料、库存和履约的真实有效，也负责保管主体账号、支付账户和管理员权限。

新增价格算法、增加仓库、改变审批方式、接入新ERP、开放供应商入驻或调整财务制度，不属于原功能故障，需要重新确认。微信接口、支付要求或第三方系统升级造成的变化，按维护合同评估兼容工作。

B2B订货系统好不好用，最终要看最普通的一天：客户能快速找到货，看到自己的价格，数量符合包装要求；销售不再反复查价抄单，仓库知道该发什么，财务能查到应收和已收。规则算得准、记录查得清，才是这套小程序真正省下来的时间。