B2B订购门户与ERP系统对接：经销商订货范围指南

B2B订购门户让获批客户登录后查看自己的目录与价格、下单与重复下单、追踪随货单据，数据与ERP系统同步。范围要分阶段划：账户、价格和订单先行，付款与审批跟上——试图一次上齐的门户，往往既延期又只用起来一半。

什么是B2B订购门户？

B2B订购门户是一条自有品牌的网络渠道：获批的分销商和贸易客户登录后自己做生意——浏览其账户可见的目录、看到与他们议定的价格、组装订单或重复上一单、找到属于其账户的单据——报价、订单、发票、贷项通知单、交货单。ERP仍是记录系统；门户是通往它的窗口，带着"每个账户能看什么、能做什么"的规则。

有必要把它与常被混淆的三个邻居分开：

网上商店。 零售价、开放注册、银行卡结账。分销商门户恰恰相反：访问按账户授予，价格是合同价，付款按约定账期走，而不是结账。

营销网站上的客户账户区。 对下载和工单有用，但没有目录、定价和订单逻辑，它连销售台的一通电话都省不掉。

邮件里的PDF价目表。 大多数分销商在门户之前的状态：发出当天是对的，下一周就是错的，而且无法按账户检索。

让它成为项目而不是一个网站的，是集成：目录、价目表、信用状况和未结单据都住在已经在运转公司的系统里，门户必须按账户、按币种、按当下与它们对得上。下面各节把这当作核心范围问题，而不是技术细节，因为大多数令人失望的门户项目败在"对得上"，不是败在设计。

功能取舍：必须有、应当有、以后有

厂商的功能页一次把所有东西都列出来。分阶段定范围，才保得住第一版能上线。下表把反复出现的功能分为第一版需要的、第二版通常补上的，以及可以等真实使用数据再做的：

表 A：功能 | 用途 | 阶段（1/2/3） | 对ERP的依赖

功能	用途	阶段	对ERP的依赖
客户账户与登录	每个分销商只看到自己的数据	1	账户与联系人
分账户价目表	合同价、价格组或按账户分层定价	1	价目表与价格组
按账户可见的目录	每个账户可采购的产品，含文档与图片	1	产品主数据、账户-产品规则
快速下单与重复下单	货号输入、CSV或上传面板、重复上一单	1	产品主数据、最小起订规则
订单提交进ERP	订单成为ERP凭证，而不是一封邮件	1	订单API或集成通道
订单状态与单据可见	发票、贷项通知单、交货单按账户可见	2	单据档案或财务系统
报价与报价转订单	询价、审批、转成订单	2	ERP中的报价单据
信用额度与净账期	向账户展示其状况与账期；超规则时拦截订单提交	2	ERP中的信用数据与账期
门户内付款	针对发票或订单的在线结算	3	支付网关加ERP对账
订单审批角色	采购员提议、审批人放行、按角色限额	3	审批数据或门户侧工作流
多语言目录与单据	按市场或按账户的贸易语言	3	产品翻译、单据模板
物流跟踪与发货通知	不打销售台电话即可看到发货状态	3	物流或船运数据

第1阶段是改变行为的那一版：分销商能登录、看到自己的价格、重复上月的订单并把它送进ERP，电话和表格这条通道就会开始自己收拢。第2和第3阶段加上钱和治理两层，它们需要组织先做出信用、财务和审批方面的决定，软件才能承载。

ERP系统与CRM集成

集成决定门户究竟是业务的镜子，还是一个带登录的宣传册。选定任何架构之前，四个问题需要书面答复：

同步方向。 主数据——账户、产品、价格、账期——从ERP流向门户；订单、报价请求和付款流回。其他任何流向都要有明确的负责人：谁可以改价，改动能落在哪里？

同步频率。 夜间批量、白天定时刷新，还是准实时。诚实的规则：价格和信用状况比产品图片更值得频繁同步，所以混合策略是常态——关键数据多同步，目录内容少同步。

失败处理。 ERP宕机或某条记录校验失败时，门户怎么办：排队、拒绝，还是显示最后一次已知状态并给出明确提示？无声失败的结果，是分销商按上周的价格下了单，变成你的争议，而不是他们的。

对账。 怎么知道门户里的每张订单都恰好变成一份ERP凭证——不重复、不遗漏、不半途转换？答案是一份头几个月里每天有人看的运营报表，它也是下面的验收测试之一。

两种部署模式覆盖多数项目。ERP原生路径把门户建在ERP自身能力的延伸上，需要互相一致的系统最少，但也继承了ERP前端的限制。平台路径运行一套商务平台——厂商资料里的常见例子是Shopify一类系统——通过中间件或连接器与ERP相连；这条路线换来前端灵活性和熟悉的管理界面，代价是多一套要保持同步的系统。自研与成品ERP对比页讨论这个"自建还是外购"问题的更大版本，供应商RFP清单则把两种选项变成你在提案里可以打分的问题。

多语言与多币种目录

出口商早早就会撞上这两个问题，而事先决定比事后改造便宜。

语言。 目录需要产品名、品类和单据的翻译；账户结构需要每个账户的语言偏好，门户不该让同一个买家每次访问都重选一遍。两个实务要点：谁负责翻译、更新节奏如何——对在意的买家来说，半翻译的目录比只有英文的更糟；以及单据（报价、发票）是跟随界面语言，还是保持财务系统要求的语言。第二个问题不是技术问题：语言不对的发票是会计问题。

币种。 约定用什么币种，就应展示什么币种，与访客所在地无关；把展示币种和合同币种混着来，争议就是这么开始的。一个账户用不止一种币种交易时，规则必须住在ERP数据里，而不是门户设置里；门户绝不能成为凭空发明汇率换算的地方。

两个话题都与分阶段计划相互作用：面向三个市场销售的出口商，第1阶段可以先用这三个市场在订单中实际使用的语言上线，市场扩大时再加目录语言。商业网站语言工作的一般规则——一个负责人、一个源文件、一条更新路径——见互联网营销页，它同样适用于门户目录。

安全与角色

门户是通往你商业数据的一扇门，所以设计问题就是访问问题：

访问是授予的，绝不自助注册。 每个账户由你的团队对照ERP账户创建；另一种做法——开放注册加一道审批——只会招来噪音，模糊谁才是客户。

基于角色的权限。 采购员可在限额内拟单和提交；审批人可放行；只读者只能看单据。按角色的限额是商务条款的一部分，不是技术上的事后补充——它们编码了你客户组织里谁可以代表他们做承诺。

账户隔离。 这个产品类别里最严重的失败形态，是一个分销商看到另一个的价格或单据。按账户的数据可见性必须专门测试，它也是下面的验收测试之一。

审计轨迹。 谁下的单、谁批的、谁在什么时候改了价——作为数据保存，而不是需要费力说服别人去看的日志文件。贸易里的纠纷，了结靠这条轨迹的时候多过靠记忆。

身份与单点登录。 对较大的分销商，接入其自有目录的SSO是常见需求，值得放在后期而非早期定范围——大多数账户用邀请加密码就跑得很好，直到总部要求联邦认证。

数据保护。 门户中的客户数据适用公司对客户记录本就承担的同一套义务：土耳其业务是KVKK框架，欧洲客户是GDPR——在与开发伙伴合作的语境下，IT外包页有详细讨论。

自建还是用平台

这个选择不是抽象的"定制还是成品"，而是你实际买的是哪一层：

表 B：路线 | 你得到什么 | 你承担什么 | 适合何时

路线	你得到什么	你承担什么	适合何时
ERP原生门户	单一记录系统，价格与信用天然一致，接口更少	前端与移动端受ERP自身能力限制；门户跟着ERP发版周期走	ERP较现代、其门户模块覆盖第1阶段大部分功能，且内部IT能运维
商务平台 + ERP连接器	熟悉的管理后台、强前端与移动端体验、目录工作上手快	多一套要同步的系统；连接器维护；两条升级路线	买入体验与数据同样重要，且有人长期负责集成
定制门户	与商业规则严丝合缝，包括定义你这门生意的那些特殊规则	全责：安全、性能、升级、整个生命周期	流程真正构成差异化、而没有平台承载它——检验办法是：一个标准功能加流程改动能不能顶用

多数出口商第一次会选择中间路线，要避免的错误是把它当成便宜的一条：连接器是需要维护的产品，成本是经常性的。这个问题——配置、购买还是自建——的决策框架，自研与成品ERP对比页有长篇讨论；本页补充的是门户特有的检验：无论选什么，分账户价目表和进ERP的订单都必须可证明地正确，你选的路线应当是以最低经常性成本让这件事可证明的那条。

分阶段上线与验收测试

当"能用"意味着"演示能用"时，门户上线就是悄无声息地失败。每个阶段都应带着书面验收测试，用真实账户和真实数据来跑：

按账户的目录可见性。 用两个不同的分销商登录；各自恰好只看到自己的产品集合，看不到对方的任何痕迹。要专门测试，不能假设。

价格准确性。 抽取一批账户和货号，门户价等于ERP价——包括背后的规则（价格组、层级、协议）。这是保护商业关系的测试；门户里的错价比报价单里的错价更糟，因为客户把它当成了既定协议。

订单完整性。 门户下的订单恰好变成一份ERP凭证，货号、数量、单位、价格都正确——而且对账报表要能显示出来。失败路径也要测：被规则拦下的订单应当明说，而不是无声失败。

状态与单据。 ERP里记录的发票和交货单，在约定的同步窗口内、以正确的状态出现在正确账户的门户视图里。

账期与限额。 各账户的信用与付款条件正确显示；规则要求拦截或标记的订单，确实被拦截或标记——要在边界上测，不是在舒适的中间地带测。

每天的习惯动作。 重复下单、按货号快速下单、搜索——用你两个真实分销商的产品清单来测，不是用演示目录。采用率就活在这三条路径上，而认真测试它们的成本只占开发成本的一小部分。

上线顺序和测试一样重要：先开一个试点市场或少数几个账户，把他们的反馈收进来，再扩大开放。另一种做法——同一天向所有分销商发上线公告——会把头几周不可避免的修复变成信誉成本；第一周发现错价的分销商，之后往往回到电话上好几个月。试点逻辑与IT外包页中为软件委托描述的那套一致，评估搭建门户团队的纪律见RFP清单。

常见问题

需要先有ERP系统吗？

不是要新的——但主数据得放在可信的地方：账户、产品、价目表和账期。如果这些只存在于表格里，门户会按账户把表格的错误自动化，那比留在电话上更糟。这种情况下，诚实的顺序是先把数据理顺（常常就在一套用得不足的现有ERP里），然后再上门户；Odoo贸易公司页从ERP一侧讨论这个决定。

客户可以有自己的价目表吗？

可以——分账户定价是这个产品类别的核心，不是附加项：价格组、分层定价或单独协议，都存ERP、按账户展示。要坚持的规则是：门户从不自己定价；它展示ERP持有的价格，分销商看到的每个价格都能追溯到你们团队签过的协议。

订单如何审批？

通常两层。在客户组织内部，审批是他们的：采购员提议、审批人放行，可选带限额——门户可以在第3阶段承载这些角色。在你自己组织内部，订单进ERP、走你平时的订单处理；门户不取代销售台的管控，它去掉的是围绕管控的重复录入和电话。

门户能处理多种语言吗？

能，而且应当——但要按阶段定范围。目录翻译、按账户语言偏好和单据翻译是三件不同的活；第1阶段先用活跃市场在订单中使用的语言上线，其余随真实需求补。治理要点——翻译归一个负责人、一条更新路径——见上文多语种一节。

数据归谁所有？

归你——账户、价格、订单、单据和历史始终是公司的记录，住在ERP里。这一点值得写进与门户承建方的合同：托管访问、源代码或配置、退出时的数据导出，逐项点名。IT外包页在更广的开发合同语境下覆盖知识产权与退出条款。

分销商怎么上线？

从下单最多的账户开始，亲自邀请，第一条消息给他们三样东西：登录方式、屏幕上能看到的价目表、一个可以打电话的人。然后盯着真正要紧的采用信号——不是登录数，而是经门户到达的重复下单量占比。并行工作（门户下单、电话确认）持续几周很正常；当门户在价格和单据上被证明是对的，它就结束——上面的验收测试就是为此准备的。

资料来源与标准

这里描述的典型功能集合（账户、分账户价目表、重复下单、发票与贷项通知单、按账户可见性、带限额的角色、净账期、支付网关）沿用厂商为B2B订购门户描述的能力清单；本页不宣称任何性能结果、成本或工期。
部署模式（ERP原生门户；经中间件或连接器与ERP同步的Shopify一类商务平台）被描述为两条反复出现的路线；本页不宣称与任何平台厂商存在合作。
流程与治理表述沿用本站页面：自研与成品ERP、供应商RFP清单、Odoo贸易公司，以及土耳其IT外包（数据保护义务、知识产权与退出条款、试点设计）。
本页不出现任何客户案例、门户预算或项目工期；范围、阶段划分和商务条款在报价中按项目确定。