经销商订货与订金结算平台

项目背景

这是一家面向企业经销商做批发的潮玩消费品牌，业务同时跑三种货期：预订商品先收定金、按约定日期截单、等发售到货后再催补尾款；现货商品依赖多个仓库的库存即时售卖；还有组合套餐形态。买方是企业主体，要先通过资质审核、建立合同与付款账户，再按授权范围把部分商品设为定向可见。订金与保证金走线下对公汇款，只能凭付款凭证入账，必须经财务审核后才能放行订单；到货本身不确定，未按时到的部分要单独处理，并影响客户额度与欠款累计。

客户当时的状态

客户当时不是“没有工具”，而是流程散落在表格与即时通讯里：订货靠沟通确认，订金靠人工核对汇款凭证，到货靠仓库口头同步。订单该不该放行，取决于财务有没有看过那张凭证；而这张凭证对应哪张订单、占用了客户多少可预定额度，全靠人工记忆与来回核对。三种货期还各自演化出不同做法，一套手工流程很难同时覆盖，资金状态与到货状态长期对不上。

我们的做法与取舍

第一个取舍是把订单对象做成一套：用订单、订单明细、后台订单、销售单四层对象承载三种货期，明细上区分普通、定金与保证金类型，并区分预定、现货与套餐商品，定金与尾款各自有独立支付状态；后台订单侧再记录货期、提货日期、已收定金与是否全部到货。代价是对象字段比单一货期的系统更复杂，收益是三种货期共用一套流转逻辑，不必维护两套互相漂移的流程。

第二个取舍是把资金侧建成独立单据，而不是在订单上直接改金额。订金与保证金分别生成收款单，收款单自动编号，经销商上传付款凭证后单据转入待审核；财务审核通过即回写关联订单的定金支付状态并放行订单，驳回必须填写原因并退回待付款，可修正后重新提交。这里的边界要在前面讲清楚：平台只承载收款单登记、付款凭证留痕与审核流转，不代客收款、不自动划扣资金，资金流与支付通道以实际签约通道为准。

第三个取舍是先做单据与台账，再补报表与分析：先把订单、收款单与履约单据之间的状态打通，再上补款进度查询与预定、补款两类报表。我们刻意没有先做自动催办与自动核销的强规则，线下汇款的到账与审核节奏由财务掌握，规则过早自动化容易造成误判和误催。

平台如何承载资金与货期

资金侧，收款单按客户滚动维护一套台账：应付定金、已付定金、待付定金与已付保证金，以及可预定额度、已用额度与剩余额度，随每次开单与审核同步增减；未按时到货的异常处理会同步形成客户额度约束与欠款累计，作为后续准入与额度调整的依据。保证金走独立链路，有独立的凭证字段与审核链路，并保留退款流程与退款凭证留痕。

货期与履约侧，后台用分货、提货单、入库单与发货明细，把“从哪个仓出、什么时候提货、入了哪个仓”结构化下来；销售单确认收货后逐级回写后台订单与订单明细的到货数量和状态，未按时到货的部分走异常处理流程。经销商在小程序与 PC 端完成选购、下单、查看付款单、上传凭证、批量开票与售后申请，销售、仓库与财务在后管端作业，同一单据在各端保持一致状态；商品、库存与往来单位资料与第三方进销存系统同步。

架构与边界

公开架构归纳为五层：入口层覆盖经销商小程序、PC 订货端与后管端；订货交易层承载商品货期、订单与销售单；资金与结算层承载收款单、凭证审核与客户额度台账；履约与库存层承载分货、提货、入库与到货处理；平台与集成层提供权限与数据范围、数据字典、定时任务、消息通知与第三方进销存同步。技术上采用前后端分离、服务端按业务域分层的自研订货业务层，在成熟开源底座之上扩展，以便按客户流程做定制而不重写通用能力。

交付状态与口径说明

平台已交付并持续迭代，规则和报表按运营反馈继续调整，项目周期未披露。本文只描述系统的单据、状态与流程能力，不涉及订单量、金额、经销商数量与库存规模等经营数据；客户内部的业务口径已替换为通用表达；涉及外部系统处统一表述为与第三方进销存系统同步，不披露厂商、版本与接口细节；平台具备的是收款单登记与凭证审核能力，资金流与支付通道以实际签约通道为准。