谁真正需要一套B2B订货系统
如果你的下游客户数量有限、价格体系简单、订单频率不高，用现成的SaaS工具大概够用了。但有些业务形态下，通用工具很快就会碰到天花板：
- 品牌商或生产商向下游多级经销商铺货，不同区域、不同层级的价格和商品池不一样；
- 连锁零售企业向加盟店或直营店配货，需要统一管控配货节奏和货款结算；
- 生鲜、冻品等快消品按区域分仓订货，客户下单必须走对应仓库的库存；
- 工业品MRO平台面向企业采购，涉及起订量、阶梯价、账期审批等规则。
这类业务有一个共同特征：规则一旦复杂到需要专人记、专人审，出错和扯皮就只是时间问题。我们在金边做了12年开发，团队28人，每年交付约100个项目，主攻电商、娱乐、金融/交易、地产、物流五个方向。电商类系统有成品基础，开箱即用，交付周期比从零开发短不少。客户覆盖柬埔寨、菲律宾、越南、老挝、泰国、印尼、马来西亚七个市场，不同市场的渠道管控习惯差异很大——比如菲律宾的批发商普遍账期审批链条更长，越南的经销商层级划分更细，这些差异会直接影响系统设计，不是翻译一下界面就能复用。
客户分级与专属批发价：系统怎么算对每一笔价格
B2B业务最核心的差异在于，不同客户拿到的价格不一样。客户分级通常按交易量、合作年限、回款信誉几个维度划分，比如VIP、金牌、银牌、试销客户。每一级对应的批发折扣率不同，能看到的商品池不同，运费承担规则也可能不同。
系统层面的做法是建立一个价格策略引擎。客户登录后，系统根据客户所属分组即时计算该客户每个SKU的到手价，支持阶梯价格、合同价、促销价叠加计算。有一个细节容易被忽略：不同客户浏览同一商品时，系统必须根据其分组显示不同价格。如果高等级客户看到低等级客户的更低价格，商务关系会立刻出问题。技术上通过客户标签与价格组关联实现，商品价格存储多个版本，查询时按客户分组快速匹配。这套价格隔离逻辑在东南亚市场尤其重要——很多批发商同时供货给不同国家的经销商，跨境价格差异一旦暴露，渠道信任就没了。柬埔寨本地电商客户和菲律宾客户都踩过这个坑，后来我们把这套逻辑做成了电商成品的标准模块。
账期和信用额度的管控同样需要系统化。大客户往往采用月结或额度过账，系统需要设置授信额度、账期天数、付款提醒规则。订单提交时，系统校验“已使用额度+当前订单金额”是否超过授信上限，超限的订单要么自动转为预付款模式，要么触发审批流程。技术实现上，额度扣减和订单创建必须放在同一个数据库事务里保证原子性，避免并发下单时出现额度穿透。逾期利息计算和账户冻结通过定时任务自动执行。账务模块需要和财务ERP对接，确保应收数据对齐。我们在金融和交易类项目里积累的事务处理经验，在这类额度管控场景里直接复用，少走了不少弯路。交易类项目的资金流水并发写入比B2B额度扣减更复杂，把那里的行锁和事务边界策略平移过来，B2B这边基本没有出过额度穿透的问题。
商品、库存、订单、售后：一条链路上的几个硬骨头
商品管理不只是建个SKU档案。多规格SKU、批量导入导出是基础能力。真正体现B2B特性的是禁售区域设置——比如某区域经销商不能看到特定品类的商品。还有起订量和限购量控制，避免小客户恶意占库存。商品需要关联多仓库库存，并配置安全库存预警，库存低于阈值时自动通知采购或运营。前端展示上，针对客户等级隐藏或置灰特定商品，和价格策略一样，都是渠道管控的一部分。
多仓库库存同步和防超卖是技术难点。客户下单时选择发货仓，或者系统根据收货地址自动路由到最近的仓库。库存扣减必须保证高并发下的幂等性，常用Redis分布式锁或数据库乐观锁来处理。当WMS系统回传物理库存变化时，通过消息队列异步更新系统库存，同时广播给各前端实例清除缓存，避免用户看到过期的库存数字。消息队列选型上，团队在物流项目里用过RabbitMQ和Kafka两种方案：RabbitMQ用于库存同步这类需要可靠投递和手动ACK的场景，配合死信队列做失败重试；Kafka用于库存变更事件的广播分发，利用消费者组实现多实例同时接收。失败重试机制上，消费失败的消息会进入重试队列，采用指数退避策略，超过最大重试次数后写入告警表，由运维介入处理，不会静默丢弃。还有一个关键是预扣库存机制：订单未支付前占用可售库存，超时未支付自动释放，防止有人恶意占单导致真实客户无法下单。物流行业的项目里，多仓路由和库存同步的问题我们处理得比较多，这套方案在金边本地跑过生产环境，边界情况踩过不少坑，后来都补上了。库存同步延迟从最初上线时的【此处待填：定性描述延迟情况】，到调整消费者组分区策略和批量写入后显著下降，具体数值因不同仓库的网络环境而异，不在这里给一个统一数字。
订单生命周期需要可靠的状态机设计。从客户提交订单开始，系统校验价格、库存、账期，通过后生成订单进入待审核或自动审核状态，然后是确认拣货、部分发货或全部发货、客户签收、进入售后周期。支持按仓库拆单、合并发货、分批出库。状态变更通过事件驱动实现，每一步操作都记录日志，方便追溯问题。状态流转设计得过于简单是实际项目中反复出现的问题——上线后发现退货、换货、部分发货这些场景没法处理，再改状态机成本很高。我们接手过几个改版项目，都是第一版状态机没留扩展空间，后面加售后流程几乎要重构，所以现在做新项目时状态机设计会预留足够的状态节点和异常分支。这部分没有通用模板，因为每个客户的售后规则和审批链路都不一样，但预留扩展节点是必须的。
售后处理要和财务、仓库协同。退货申请必须关联原订单，支持部分退货，系统自动计算退款金额并处理发票冲红。换货生成新的换货订单，库存自动补回。售后流程需要审批流支持，同时记录退货原因，这些数据反向指导供应链改进。售后环节的系统化程度直接决定月底对账效率——如果售后数据散落在聊天记录里，统计退货率和责任归属基本靠猜。
多角色权限：业务员、代理商、客户各看各的
B2B订货系统不是给单一角色用的。平台管理员、财务、业务员、代理商管理员、客户采购员，不同角色看到的数据和能做的操作必须严格隔离。基于RBAC模型设计，权限分两层：菜单和操作权限控制能做什么，数据权限控制能看到谁的数据。
业务员只能查看名下客户及订单，可以为客户代客下单；代理商拥有子账号管理能力，可以查看整组客户数据；客户内部还可以设置下单人与审批人，订单超过一定金额需要内部审批。数据权限的技术实现通常通过SQL拦截器动态注入过滤条件，或者在API层统一封装部门和归属ID。前端菜单动态渲染，按钮权限精确到每个操作。越南和老挝的客户对多级经销商权限的需求尤其细，一个代理商下面挂几十个子账号，数据隔离必须做到位。这套权限体系设计好了，业务扩张时加角色加规则才不费力。我们在越南交付的一个项目里，客户方代理商层级从两级扩到四级，因为权限模型预留了层级深度，改造只用了几天。
开发周期、成本结构与上线节奏
开发周期和功能范围直接挂钩。小项目几天可以交付，大项目约2个月。电商类系统因为有成品基础，开箱即用，交付速度明显快于完全从零开发。如果涉及和ERP、WMS深度对接，或者多级分销逻辑特别复杂，周期会相应拉长。不同国家的业务习惯有差异，需求沟通阶段我们会把这些差异点提前列出来，避免做到一半才发现要改。每年约100个项目的交付量意味着大部分需求场景我们都有对应的模块积累，真正从零写代码的部分通常只占一小部分。
成本方面，按功能清单逐项评估报价，不报笼统的数字。付款方式为先付30%启动，验收后结清尾款。支付通道由客户提供资源，我们负责技术对接，不提供支付通道本身。报价和排期通过Telegram或面谈沟通，中文服务。系统上线后，bug修复免费，新增功能按工作量单独计费。日常运维有AI监控辅助，库存同步延迟或支付异常这类问题可以及时发现。部分成品系统已经有几十家客户在运营使用，成品模块经过了多轮生产环境验证，bug修复的边际成本已经摊薄，这是我们敢承诺免费修bug的原因。
上线前的准备工作容易被低估。历史客户、商品、价格数据需要迁移和清洗，确保和现有财务系统科目对齐；内部员工和外部经销商需要培训，操作手册和视频不能省；建议采用灰度发布策略，先让部分种子客户试单，观察系统压力和业务流转，收集反馈迭代后再全量切换。这些问题处理不好，系统开发得再好也推不动。我们一般会在交付计划里把数据迁移和培训单独列成阶段，不混在开发周期里。
如果你正在考虑B2B订货系统的开发，可以通过Telegram或面谈沟通。我们在金边的团队可以根据你的具体业务场景，基于现有电商成品快速搭建，也可以从零定制。先聊清楚需求，再决定怎么做。