如果你正在为某个 B2B 项目评估 BigCommerce，决定大部分构建方向的问题就是：你是否使用 B2B Edition。正是这一层，把 BigCommerce 从一个带 B2B 附加功能的 B2C 平台，变成真正能进入 B2B 讨论范畴的产品。在做过多个 B2B Edition 项目之后，下面是实战视角。
定制目录、阶梯定价与按客户定制的结账
简短的答案（这通常是第一个问题）：可以，B2B Edition 三样都能做到。每一项都来自几个相互配合的功能，而不是某一个开关。
- 定制目录。 每家公司都属于一个客户组，由客户组决定其买家能看到哪些类目：全部、指定的一部分或全都不显示。这样每个客户在同一个店面上就有自己的目录。可见性按类目控制，而不是按单个商品。
- 阶梯定价。 分配给客户组的价格表为该客户设定任意变体在每种货币下的价格，并可按数量设置阶梯：百分比折扣、每件减免固定金额，或固定单价。
- 按客户定制的结账。 你可以为每家公司选择可用的支付方式，包括在信用额度内使用采购订单（Purchase Order）。买家角色决定谁可以下单、谁只能建立 Shopping List 或申请报价；你还可以把收货地址限定为公司已保存的地址。报价中谈定的价格会一直带到结账。
每一项的局限，以及哪些需要定制开发，见下文的B2B Edition 做不到的事。
B2B Edition 开箱即用的能力
公司账户与买家层级
B2B 最根本的特征在于：“客户”不是一个人，而是一家公司，公司内部有多名成员，各自拥有不同权限。B2B Edition 原生地为此建模：
- Company（公司）就是账户本身（通常映射到你的 ERP 客户）。公司之间还可以建立父子层级，最多嵌套五层，适合连锁企业、加盟体系以及拥有多个网点的客户。
- 公司内部是 Buyers（买家），每人对应一个角色。内置角色有三种。初级买家（Junior Buyer）可以请求报价、创建 Shopping Lists，但不能下单。高级买家（Senior Buyer）可以下单、审批 Shopping Lists，并查看公司的订单历史。管理员（Admin）可以做以上所有事情，还能管理地址和用户、支付发票。没有内置的仅查看角色，但你可以把它建成一个自定义角色。
- 同一公司内的所有买家共用公司的地址簿，地址权限作用于整个公司，而不是单个买家。如果负责 Cleveland 仓库的买家绝不能发货到 Dallas，就把每个网点设为一个子公司，各自拥有自己的地址和买家，并在结账时关闭新增地址，让买家只能选择已保存的地址。
如果你的业务是把公司当作客户来销售，而非面向消费者，仅凭这一点，B2B Edition 的授权费就值了。
报价转订单流程
买家可以针对购物车请求报价，销售代表可以修改价格并审批，报价随后转换为带有约定价格的订单。这一流程是内置的。你要定制的是：谁会收到报价请求、允许哪些覆盖项，以及审批如何流转进 ERP。
价格表
每家公司都归入一个客户组，价格表则分配给这个客户组。价格表可以为任意变体设置完全不同的价格，每种货币各有一套单独的价格。公司能看到哪些商品是另外设置的，通过客户组的品类访问权限来控制。价格表加上客户组的品类访问权限，就是实现“客户 A 看到的目录与客户 B 不同”的主力工具，无需单独建一个站点。
Shopping Lists（采购清单）
经常重复下单的人（仓库、MRO 采购员、任何每月都订购相同 SKU 的人）可以保存 Shopping Lists，与同事共享，点几下就能把其中的商品加入购物车。初级买家创建的清单要先交给高级买家或管理员审批。买家也可以从过往订单再次下单，或者在 Quick Order（快速下单）中从自己以前购买过的商品里再次下单。在我们的用户测试中，这是最受欢迎的单项功能：当日常工作流程变短时，买家是真的会为此点赞。
Buyer Portal（买家门户）
有权限的买家可以查看全公司的订单历史，并按下单人筛选。发票视图会显示未结与逾期余额，并支持在线付款。订单详情会列出每一批发货及其物流单号。功能很标准，但确实管用。没有面向销售代表的通用联系表单：买家通过报价请求以及每份报价中的消息对话与销售代表沟通。
B2B Edition 做不到的事
同样重要的是诚实地界定范围：
- 来自 ERP 的实时 ATP。 与 BigCommerce 的其余部分一样，B2B Edition 使用的是缓存库存。如果你的 B2B 模式要求在请求时从 ERP 获取实时可承诺量（available-to-promise），你就需要做定制集成（或者你真正该考虑的是 Sana Commerce，而不是 BigCommerce）。
- 复杂的定价公式。 价格表为每个变体、每种货币各存一个设定好的价格，并可选设置数量阶梯（按百分比折扣、每件减免固定金额，或固定单价）。价格表不支持相对于标价计算的规则。如果你的定价规则是“在标价基础上打 95 折，数量 ≥ 100 再打 98 折，然后再叠加客户专属覆盖价”，数量折扣可以放进阶梯，但标价折扣和覆盖价都要提前算成价格表上的最终价格。
- 针对单个客户的逐商品可见性。 可见性来自公司所属的客户组，而不是价格表，并且按品类生效：每个客户组可以看到全部品类、选定的部分品类，或者一个都看不到。商品只要位于该客户组可访问的任一品类中就仍然可见，所以要对某个客户隐藏一个 SKU，就必须让它不出现在该客户所属客户组能看到的任何品类里。
- 单一公司的多币种信用额度。 公司本身并没有自己的货币。买家从你的交易货币中选择，价格表也为每种货币单独设价，所以同一家公司可以用 EUR 和 USD 购买。问题出在公司信用额度上：它只以一种货币设定，买家如果用另一种货币结账，就无法使用采购订单（Purchase Order）付款方式。如果客户需要在两种货币下都使用 PO 账期，那仍然意味着要建两家公司。
经得起考验的集成模式
ERP → BigCommerce 同步
大多数 B2B Edition 项目会按计划从 ERP 拉取客户与价格表数据（通常每小时一次，高风险数据则实时同步）。我们推荐的集成方式是：
- 一个小型中间件服务（.NET 或 Node 任你选，我们通常选 .NET，因为其余技术栈都是 .NET），由它来掌管同步逻辑，而不是交给 ERP，也不是交给 BigCommerce。
- 幂等同步，以稳定的客户/SKU 标识符为键，绝不要用名称或地址作键。
- 为每一次同步动作记录审计日志，这样当客户说“我的价格昨天变了却没人通知我”时，你能给出答案。
报价转订单 → 回流 ERP
当报价转换成订单时，你需要让这笔订单落到 ERP 里。这笔订单来自基于报价发起的结账，所以带有约定的价格，ERP 应当用这些价格创建销售订单，并跳过它自己的定价引擎。要检查整份报价上的固定金额折扣是怎样传过来的，因为 B2B Edition 不会把它折算进报价的行价格里。这是少数几个我们会例行做定制的地方：每家 ERP 的销售订单 API 都有自己的怪脾气。
买家 SSO
对于中型企业市场及以上，买家希望通过企业身份提供方登录。B2B Edition 支持买家 SSO，但并没有内置的 SAML 开关。由你自己的服务（或应用市场中的 SSO 应用）接收来自客户身份提供方（例如 Okta 或 OneLogin）的登录，再通过 BigCommerce 的 Customer Login API 或 B2B 店面令牌让买家登录。要做到生产可用的集成是相当有分量的工作。请为此预留 1 到 2 周，外加在客户 IdP 中的配置，而那部分并不在你掌控之内。
Stencil 与 Catalyst 搭配 B2B Edition
我们已在更宏观地对比过 Stencil 与 Catalyst。具体到 B2B Edition：Stencil 对 B2B Edition 的开箱即用 UI 集成更为完善。Catalyst 可以运行同一套 Buyer Portal，所以报价管理和代客操作都随之而来，但 BigCommerce 仍把 Catalyst 集成标为实验性，其 B2B 入门模板也标为 alpha。你的团队需要在 Catalyst 代码库中接好登录交接、门户启动，以及“Add to quote”（加入报价）这类商品页按钮。如果 B2B Edition 是你上线的核心，而团队规模又小，那就更偏向 Stencil。如果你有一支前端平台团队，并且 Catalyst 对你所需屏幕的 B2B Edition 支持已经“够用”，那么 Catalyst 能给你无头架构的自由。
结论
B2B Edition 确实是好东西。但如果你的业务更接近“带批量下单的 B2C”，而非多买家的企业账户，那它也是一层你并不需要的复杂度。对自己究竟属于哪一类要诚实。购买 B2B Edition 的错误理由是“我们做 B2B，所以就该买”。正确的理由是“我们的客户是以团队为单位采购的，店面必须能为此建模，否则我们的销售代表只能继续手工去做这些事”。
正在为某个 B2B Edition 项目做预估？联系我们：我们做过好几个，会告诉你哪些功能真正能为你的买家带来价值。