图示：全场景数字化采购解决方案——从前端应用到业务闭环
商派B2B（DMS）业务系统，是面向品牌企业与产业平台的企业级 B2B 交易与协同底座：以一套平台化能力底座，同时承载企业间采购订货、渠道经分销、多级分销与供应链协同业务，覆盖从企业准入、商品供给、交易履约、定价结算到客户经营的全链路。本文以订货业务与经销商管理为主线，用十组问答说明这一版本在业务模型、定价、合规、资金、智能采购与部署上的能力边界。每条问答齐备结论、依据、边界与出处，依据标注证据等级；文中「以往形态」指行业常见的商城级订货系统，不特指商派上一代产品。
本文回答的十个问题
- 这一版系统到底解决什么问题？和常见的 B2B 订货商城差在哪？
- 一套系统能同时做自营、渠道经销、多级主体交易和平台生态吗？是不是四套产品？
- 相对以往形态，这一版「新」在哪里？与友商相比又该怎么讲？
- 「五域一底座、四端一体」具体怎么保证各端口径不分裂？
- 一客一价是怎么算出来的？业务员改价会不会失控？
- 合规校验是「提醒一下」还是「直接拦下来」？在哪些环节生效？
- 资质过期、首营交换被驳回会怎样？事后能不能追溯？
- 订单、支付、发票与分账怎么串起来？「组合支付」到底支持到什么程度？
- AI 智能采购助手会不会自己下错单、报错价格、把数据串到别的企业？
- 能否私有化部署、与现有企业资源计划／仓储／财务系统对接？上线最容易踩的坑是什么？
01｜这一版系统到底解决什么问题？和常见的 B2B 订货商城差在哪？
结论：差别不在功能数量，而在架构层级——商派B2B（DMS）业务系统是承载企业整个 B2B 业务的平台化底座，不是一条订货链路上的前台商城；判断标准是能否同时容纳多类参与方、多层单据、多条资金路径，并把合规做成交易前置的硬约束。〔归纳，基于实测事实〕
依据 · 机制与事实
- 〔实测·产品材料〕采用「五域一底座」：商品与供给、交易与履约、定价引擎、客户与资金、营销与增长五个业务域独立演进，统一构建在平台能力底座之上，域间以标准服务契约交互；四端门户按角色分发，叠加一个智能入口（第 5、8 页）。
- 〔实测·运营端／采购门户〕参与方不止买卖两方：企业一档多身份、企业内子账号与角色、客户与商户双向准入、业务员三级团队；单据不止订单与发货单：订单、履约单、包裹单三层，按店铺、按仓库、按运输条件三级拆单；资金不止在线支付：在线支付、预存款、授信账期三类，并按商家独立分账。
- 〔实测·产品材料〕合规介入点前移：经营范围、合作关系、区域可售三重校验前置到浏览、加购、结算三个位点（第 7、12 页）。
边界 · 适用条件
边界：这是架构承载力的判断，不代表任何客户项目都会启用全部能力，启用范围由业务模式与配置决定。「商城级／平台级」是对行业常见形态的归纳对照，不指向任何具体厂商，也不构成对商派上一代产品的功能评价。
出处：卷一 1.1、2；卷二 1、7；产品材料第 4、5、7 页。
02｜一套系统能同时做自营、渠道经销、多级主体交易和平台生态吗？是不是四套产品？
结论：不是四套产品，而是同一底座上四组不同的「角色 × 规则 × 数据范围」配置；差别在参与层级与平台是否居中，不在产品形态。
依据 · 机制与事实
- 〔实测·产品材料〕同一平台化底座同时承载企业间采购订货（B2B）、渠道业务／经分销、b2B2B 多级主体交易、S2B2B 平台赋能渠道伙伴服务企业客户四类业务模型（第 4 页）。
- 〔实测·运营端〕支撑多主体交易的是企业一档多身份、企业登记审核中「加挂另一端身份」、授信按「商户 × 客户」独立开户；支撑平台生态的是运营端十二个模块（客户、商户、标品、商品、审核、订单、活动、财务、分销、装修、系统管理、数据面板）。
- 〔实测·产品材料〕两类经营模式——单一企业自营与多方生态协同——共用同一套代码与能力模型，差别在租户与配置，不在产品分支（第 42 页）。
边界 · 适用条件
边界：现实业务中 b2B2B 与 S2B2B 常并存，界线不必强行划清，按实际参与方与结算关系判断即可。系统提供能力不等于替客户完成组织设计、价格策略制定或合规制度建立；两种模式在运营团队、招商流程与结算主体上的组织要求不同。
出处：卷一 3、4；卷二 5、6；产品材料第 4、16、23、27、42 页。
03｜相对以往形态，这一版「新」在哪里？与友商相比又该怎么讲？
结论：新在架构层级与约束介入时点——把定价、合规、资金与履约从流程中的人工环节，变成由规则引擎与状态机实时执行的硬约束，并让 AI 接入真实交易链路；对外讲优势只讲「能力覆盖面与约束承载度」，不做点名对标。〔归纳〕
依据 · 机制与事实
- 〔实测·产品材料〕规则引擎外置承载促销与定价规则，支持双引擎在线热切换，规则调整无需改代码与发版；订单、履约单、包裹三台状态机约束单据流转，十状态订单状态机校验合法迁移路径（第 39、40 页）。
- 〔实测·采购门户／运营端〕合规从「证照线下留存、事后人工检查」变为前置拦截：提交订单页设独立「校验信息」区，校验不通过时显示红色提示且结算按钮不可用；首营交换未通过无法下单。
- 〔实测·智能助手材料〕AI 智能采购助手直连商品、交易与订单服务，写操作须经确认卡与一次性令牌；与三条外部技术路线的对比表见材料第 19 页，原文限定「需自研」指该方案本身不提供、需企业另行建设。
- 〔实测·采购门户／运营端〕反证式证据：医药与医疗器械场景叠加商品信息深度、主体资格、双向资质互审、经营范围与可售区域、效期批次、组织审批与复合结算六类约束，均已在两端界面落地。
边界 · 适用条件
边界：素材未提供商派上一代产品功能清单，也未提供任何友商产品能力数据，因此不能推导「商派旧版缺哪些功能」或「某友商做不到什么」；能承载最严约束集证明的是架构上限与可配置性，不等于系统已在所有行业完成交付，也不构成任何法规符合性声明；不写效率提升比例。
出处：《新版B2B差异对比-文案稿》第一、三、四节；卷一 2；卷三 1、6；卷四 5、6。
04｜「五域一底座、四端一体」具体怎么保证各端口径不分裂？
结论：靠统一数据模型、标准服务契约与「一处配置、多端生效」的规则分发机制，而不是靠各端各自做数据同步。
依据 · 机制与事实
- 〔实测·产品材料〕五个业务域统一构建在平台能力底座之上，域间以标准服务契约交互，任何一域的业务变化不影响其余各域稳定运行；PC 采购门户、移动多端商城、商家经营工作台、平台运营中枢按角色自动分发功能与数据，全端共享统一数据模型与服务能力（第 5、8 页）。
- 〔实测·产品材料〕移动侧一码编译五种形态（网页移动版、微信小程序、安卓、iOS、鸿蒙），功能与 PC 端对等；装修侧提供十七类以上组件、四类端类型隔离，配置保存即时生效（第 8、10、17、30 页）。
- 〔实测·产品材料〕权限侧提供菜单与按钮双级权限点、六级数据范围与多租户数据隔离，保证按角色看到的功能与数据边界一致（第 41 页）。
边界 · 适用条件
边界：「一码编译五种移动形态」「十七类以上装修组件」「六级数据范围」引用时须带对象名，不与「220+ 核心数据表」「200+ 服务能力接口组」等其他数字混写。具体接口清单、字段映射与性能容量属于项目范围，须在方案阶段逐项确认；「业务规则一处配置、多端即时生效」属产品材料的设计口径。
出处：卷二 1、2、3.1、8；卷四 9.4；产品材料第 5、8、10、17、30、41、43 页。
05｜一客一价是怎么算出来的？业务员改价会不会失控？
结论：最终协议价按三级优先级链「命中即停」实时解析，改价受双层底价与审批流双重约束；系统提供引擎与管控，不替企业制定价格策略。
依据 · 机制与事实
- 〔实测·产品材料〕解析链为 L1 单品独立定价 → L2 客户绑定价格组 → L3 单品基准经销价；L1 按客户 × 区域 × 数量阶梯三维组合，L2 按绑定优先级逐组匹配且组内粒度三级收敛，L3 兜底保证任何客户任何区域有价可查（第 12、20 页）。
- 〔实测·产品材料〕商家底价 + 平台底价构成双层底价体系，支持一口价／折扣率／减值三种模式；改价审批流为业务员发起改价单 → 组长审核 → 凭单结算，全程留痕（第 20 页）。
- 〔实测·运营端〕分销管理「底价模板」维护指定商品的分销底价清单，底价数值必填；模板被业务员绑定时删除会被系统拦截并提示先解绑；订单列表带「凭改价单结算」标识。
- 〔实测·产品材料／采购门户〕结算页统一试算协议价、优惠与费用；商品详情、搜索结果与购物车三处促销口径一致，下单价与结算价一致；AI 智能采购助手与门户共用同一套价格，不存在智能体专享价。
边界 · 适用条件
边界：价格规则须由业务侧先定义清楚；商家底价与平台底价在界面层的优先级落点、底价模板与三级链的联动界面、定价快照缓存的失效时间与更新频率，素材均未涉及，不作推断。「协议价」与「分销底价」、「分账」与「佣金」、「企业预存款／授信」与「平台电子账户」是三对不同对象，不可混用；可售范围另受经营范围、合作关系与首营交换约束，价格规则不能单独决定能否下单。
出处：卷二 3.2、4；卷八 6.1、6.6；《价格引擎-六卡片文案》卡片二～五；产品材料第 12、20、24 页。
06｜合规校验是「提醒一下」还是「直接拦下来」？在哪些环节生效？
结论：是硬拦截，不是可忽略的提示；拦截落在商品可见性、加购、结算、履约与资金四个位点。
依据 · 机制与事实
- 〔实测·产品材料／运营端〕经营范围、合作关系、区域可售三重校验前置到浏览与下单；未登录隐藏价格并引导注册，登录后按身份展示专属协议价。
- 〔实测·采购门户〕商品详情页「配送到」下拉明确提示所选省份是否在可售区域内，不可售地区商品无法加入购物车；提交订单页设「校验信息」区，校验不通过时显示红色提示且结算按钮不可用（3.2、4.2 节）。
- 〔归纳，基于实测字段〕两条判定式：可售范围 = 客户经营范围 ∩ 商品经营范围 ∩ 区域可售；交易资格 = 合作商户状态 × 首营交换状态 × 资质有效期状态（卷八第 4 节）。
- 〔实测·产品材料〕客户核心证照过期即时计算禁购范围并在下单前强制校验；商户资质过期按策略触发店铺限制或对应经营范围商品下架；标品资质过期级联封禁引入商品（第 28 页）。
边界 · 适用条件
边界：是「全部禁购」还是「按经营范围禁购」、是否自动封禁，取决于平台配置，不能以默认行为向客户承诺。能承载该约束集证明的是能力覆盖面与可配置性，不构成任何法规符合性声明；校验项、必填属性与处置方式由单位类型、资质模板与业务开关决定，不同项目不同。
出处：卷二 7；卷三 1、5.4；卷八 4；企业采购门户 3.2、4.2；产品材料第 7、11、12、28 页。
07｜资质过期、首营交换被驳回会怎样？事后能不能追溯？
结论：系统按配置自动限制经营并生成可处置的预警记录；签章资料按下单时点匹配历史版本，支持一键打包下载，全链路可回放。
依据 · 机制与事实
- 〔实测·运营端／采购门户〕首营交换是医药购销双方在建立业务关系前的资质互审环节，商户审核通过后方可下单；企业中心设「首营交换申请」一级功能，含审核单号、交换状态、驳回／过期原因与重新发起操作（7.3 节）。
- 〔实测·运营端〕客户入驻审核逐项核验资质，单项驳回与一键驳回均须填写不少于 5 个字的具体理由；客户尚未维护经营范围时，系统不允许提交审核通过；提交前汇总本次核验结论（客户管理 3.5、3.7）。
- 〔实测·运营端〕资质预警分临期／过期／已关闭三池，可更新处置状态并填写备注；商户资质过期按资质模板配置的处置方式自动封禁店铺或按经营范围下架商品并标记「资质过期不可上架」；续期后预警自动关闭（客户管理 3.8、商户管理 3.2）。
- 〔实测·产品材料／运营端〕首营认证通过后，签章证照在客户详情「首营签章信息」中展示并支持一键打包下载，按下单时点自动匹配历史版本；订单、履约单、包裹单、支付流水、发票与操作日志可完整下钻回放（第 28 页；卷二 7）。
边界 · 适用条件
边界：具体需要哪些资质项、必填还是选填、过期如何处置，由单位类型、资质模板与资质场景绑定决定；「资质过期自动限制经营」是系统机制描述，不写「符合某法规」「通过某认证」。资质变更审核通过后覆盖原资质信息并同步经营范围，该链路依赖配置顺序正确。
出处：卷三 2、3；卷六客户管理 3.5／3.7／3.8、商户管理 3.2、系统管理；卷八 3.1、3.2；产品材料第 28 页。
08｜订单、支付、发票与分账怎么串起来？「组合支付」到底支持到什么程度？
结论：订单、履约单、包裹单三层单据配合状态机流转，订单号贯穿支付流水、售后单、发票记录与分账台账；支付方式的设计口径与已落地界面事实证据强度不同，必须分开表述。
依据 · 机制与事实
- 〔实测·产品材料〕十状态订单状态机校验合法迁移路径；三级履约拆单（按店铺、按仓库、按运输条件）；售后三类型八状态独立流转，售后审核通过自动触发发票红冲（第 15 页）。
- 〔实测·采购门户〕发票分数电专票、纸质专票、数电普票、纸质普票四类，所选类型须与发票抬头类型匹配；开票记录与抬头独立维护（4.2、8 章）。
- 〔实测·运营端〕分账比例为全局默认与商户单独两级，商户单独优先；分账基数为在线实付减已退线上金额；基数不大于 0、无生效比例或抽佣为 0 的订单标记为无需分账（财务管理）。
- 〔实测·采购门户〕已落地界面事实：支付方式为线上支付／扣减预存款／扣减授信三选一，后两者以企业已开通对应账户为前提，不足部分在线支付（4.2 节）。
- 〔实测·产品材料〕设计口径：组合支付开关开启后多方式并行勾选，预存款优先扣减、授信兜底、在线补足差额；各商家资金账户互不混用，退款按实付占比原路拆分、尾差自动归集（第 13 页）。
边界 · 适用条件
边界：涉及「已实现」的表述以前述界面事实为准，不得写成「已支持自由组合支付」，也不将两种口径调和成一种。分账比例、费率、具体数值与取数公式，素材未涉及。售后与退款的票据红冲、税额折算按界面规则执行，不对实现方式作推断。
出处：卷二 3.3、3.4；卷八 6.2～6.5；《价格引擎-六卡片文案》卡片六；产品材料第 13、15、23、24 页；企业采购门户 4.2、5、6、8 章。
09｜AI 智能采购助手会不会自己下错单、报错价格、把数据串到别的企业？
结论：写操作不绕过用户，价格与库存不来自模型生成，租户／企业／用户三层身份由系统注入；助手是加法不是替换，原有下单路径照常可用。
依据 · 机制与事实
- 〔实测·智能助手材料〕三个「同一」：同一套账号、同一套商品与价格、同一个购物车与订单；核心主张为「让 AI 做理解，让系统做交易」，金额由业务系统计算（第 3、17 页）。
- 〔实测·智能助手材料〕五道工程闸门依次为身份作用域隔离、工具白名单管控、预算前置扣减、写入授权确认、数字溯源与复核；下单提交走宿主内部通道，不在模型可见的工具白名单里（第 14、15 页）。
- 〔实测·智能助手材料〕确认卡三条铁律：点确认后才会下单；金额一字不差且携带 120 秒有效、用过即废的一次性令牌；购物车版本变化则卡片作废、须重新确认；每轮对话、工具调用、模型调用与确认卡全部落库可回放（第 10、15 页）。
- 〔实测·智能助手材料〕同名多规格时弹选择卡由用户决定，规格编码与起订倍数由系统给出；助手与门户共用同一套价格，不存在智能体专享价（第 7、14 页）。
边界 · 适用条件
边界：机制防的是越权与数据漂移，不替代用户对商品、数量、金额与收货信息的人工核对；产物面板展示的是查询时点同步快照，价格与库存以重新核验为准。助手当前以右下角挂件嵌入、与门户同域部署并共用登录态，为单实例部署，多实例所需的运行态外置方案在规划中；耗时对比数据尚未按真实样本统计，当前只描述操作路径差异。
出处：卷四 1、2、5、6、8；智能助手材料第 3、7、10、14、15、16、17、21、23 页。
10｜能否私有化部署、与现有企业资源计划／仓储／财务系统对接？上线最容易踩的坑是什么？
结论：支持两种交付形态与四套环境，具备契约化集成基础；上线风险主要在主数据质量、规则配置顺序与权限数据范围三处，而不在代码本身。
依据 · 机制与事实
- 〔实测·产品材料〕两种交付形态为平台化多租户运营（统一升级、即开即用）与客户独立部署（独立域名、独立品牌、独立环境整套交付，数据完全私有），共用同一套代码与能力模型；开发／预发／生产／客户独立部署四套环境，配置中心命名空间隔离（第 42 页）。
- 〔实测·产品材料／运营端〕后端按业务域拆分为十个微服务模块，服务间接口与数据结构版本化管理；客户与商品支持批量导入（单次最多 10 万行），订单与商品统计报表支持自定义列导出（第 39、40 页；卷四 10.1）。
- 〔实测·产品材料／运营端〕组织与权限侧为部门、岗位、用户、角色四级组织，菜单／按钮双级权限点、六级数据范围与多租户隔离（第 41 页）。
- 〔实测·运营端〕配置链存在依赖顺序：单位类型 → 资质模板 → 资质场景绑定 → 经营范围 → 商品类目资质绑定；系统已提示「若客户尚未维护经营范围，不允许提交审核通过」（系统管理；客户管理 3.5）。
- 〔建议·前向部署经验〕三处高风险：主数据清洗应作为独立阶段；规则配置不可跳步；客户、商户、平台、业务员四类角色的数据边界须在配置阶段一次性明确。可用反例用例验收：经营范围外商品、未通过首营交换的商户、不可售省份、临期与过期证照、未点确认卡与确认前购物车被改、任选一单全链路回放（卷四 10.2、10.3；卷八 9.2）。
边界 · 适用条件
边界：具体接口清单、字段映射、性能容量、实施周期与对接方式属于项目范围，须在方案阶段逐项确认，不能凭产品材料承诺；独立部署的运维责任、升级节奏与硬件资源由项目合同界定。上述三处风险与验收用例标注为〔建议〕，属前向部署经验，不是产品已实现的功能；素材未提供任何法规符合性或认证结论。
出处：卷一 4；卷四 9.5、10；卷八 8、9；产品材料第 39、40、41、42 页。
证据分级与编制说明：〔实测·产品材料〕为产品设计能力；〔实测·采购门户〕〔实测·运营端〕为已落地界面事实，涉及「已实现」优先引用界面事实；〔归纳〕为基于实测事实的架构判断；〔建议〕为前向部署经验，不构成产品承诺。本文依据商派B2B（DMS）业务系统结构化知识库八卷及两份能力比对稿编制，编制日期 2026 年 11 月 10 日。
