--- title: "Shopify B2B 订单审批：原生、应用与定制门户" canonical: https://wavect.io/zh/blog/shopify-b2b-order-approval-workflow/ language: zh description: "比较 Shopify B2B 原生草稿审核、买方审批应用和定制门户。明确员工与主管权限、支出限额、多级审批及 ERP 交接，避免把客户注册审核误当采购授权。" image: "https://wavect.io/img/blog/headers/header_shopify-b2b-order-approval-workflow.png" --- [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 12 分钟 阅读 · 2026年9月29日 最近审核 2026年9月29日 [**下一篇**](/zh/blog/odoo-erp-api-integration-limits-2026/) # Shopify B2B 订单审批：原生功能、应用还是定制买方门户？ 要点速览 Shopify B2B 订单审批可能指客户准入、商家审核或买方主管批准。Basic、Grow、Advanced 和 Plus 的原生结账转草稿支持商家审核，但不是完整的员工向主管申请采购流程。先测试文档明确支持买方团队的应用；只有它无法可靠执行企业权限、共享预算、版本化批准或 ERP 交接时，才考虑定制审批层。选型还必须核实套餐与具体 API 限制，并测试所有可能绕过审批的结账入口。 **“Shopify B2B 订单审批”实际上可能指三种不同需求。**商家可以审核企业客户的注册申请、审核收到的订单，也可以让客户公司的员工向自己的采购主管申请购买授权。只有第三种属于买方内部采购审批。选型首先要明确：谁审批、审批什么，以及批准之前必须阻止哪个业务动作。 一位商家在 [Shopify Community 提出的需求](https://community.shopify.com/t/b2b-purchase-order-approval-flow-employee-admin-in-shopify-grow-plan/614684) 就明确要求：员工提交采购申请，由客户公司的主管批准，之后供应商才能看到。“提交审批”按钮本身也不能说明审批权属于正确的组织。 核查日期：2026 年 9 月 29 日。平台事实依据 Shopify 官方文档；应用功能依据供应商文档，不代表经过实际安装验证。架构方案和验收条件是 Wavect 的建议。 ## 您需要哪一种 Shopify 审批流程？ | 决定 | 审批人 | 授予的权限 | | --- | --- | --- | | 批发客户账户审核 | 商家 | 允许一家企业进入 B2B 采购渠道。 | | 商家订单审核 | 商家的销售或运营团队 | 供应商接受提交的采购订单。 | | 买方内部采购审批 | 客户公司的主管或预算负责人 | 允许员工动用公司预算购买指定商品。 | **商家审核优先使用原生功能；员工向主管申请采购，优先测试支持买方团队的应用；只有应用无法可靠执行关键规则时，才确定定制开发范围。**多位审批人或 ERP 对接意味着需要更严格的验证，不意味着必须更换整个商城。 把需求写成一句可以验收的话：“A 分支机构的员工可以申请商品，但只有负责 A 的指定主管才能放行这份具体申请；放行前不能创建 Shopify 订单，也不能创建 ERP 销售订单。”再根据实际政策调整条件。是否允许提前存在 Shopify *草稿订单*，必须另行明确，不能默认等同于正式订单。 ## Shopify 原生支持什么？Grow 套餐也能用吗？ [Shopify 按套餐列出的 B2B 功能表](https://help.shopify.com/en/manual/b2b/getting-started/plan-features) 将企业、地点权限、结账转草稿和采购订单编号列为 Basic、Grow、Advanced 与 Plus 均支持的功能。“所有原生 B2B 或草稿审核都需要 Plus”已经不是准确的概括。不过，具体功能仍可能有单独的套餐限制。 ### 账户审核决定准入，不决定每一笔采购 [通过 Shopify Forms 提交的企业账户申请](https://help.shopify.com/en/manual/b2b/companies-and-customers/company-account-requests) 允许商家批准企业使用 B2B 采购。这属于客户准入。不要因为某个应用支持注册审批，就认定它能把员工的每一个购物车交给客户公司的采购主管。 ### 原生草稿审核由商家处理 英文管理界面的路径是 **Customers → Companies → company → location → Checkout → Order submission**，选择 **Submit all orders as drafts for review**。Shopify 在 [结账设置文档](https://help.shopify.com/en/manual/b2b/checkout-and-orders/checkout-settings) 中说明了这一配置。提交时不在结账环节付款，申请进入商家的草稿队列。 如果您的团队需要先确认库存、运费、协议价格或信用状况，再接受销售订单，这种方式很合适。但它本身不能证明客户主管授权了员工的支出。它也不满足“客户批准之前，商家什么都看不到”：商家已经能看到草稿。 ### 地点管理员不是文档中定义的采购审批角色 Shopify 文档列出两种 [企业地点的客户权限](https://help.shopify.com/en/manual/b2b/companies-and-customers/adding-customers) ：Ordering only 可以查看自己的订单记录；Location admin 可以查看该地点的全部订单并修改地址。这些定义没有建立主管签批链。客户权限与商家后台员工权限也不能混为一谈。 价格与授权同样需要分开。Shopify 说明， [通过 B2B 结账提交的草稿](https://help.shopify.com/en/manual/b2b/checkout-and-orders/draft-orders) 默认锁定价格。但锁价不等于记录主管同意，不会自动预占部门预算，也没有定义更改收货地址后是否需要重新审批。这些规则需要独立设计。 采购订单编号是业务参考信息，不是预算负责人已批准订单内容的证据。“尚未付款”和“尚未授权”也是不同状态。流程设计必须分别说明，不能把延后付款直接当成采购审批控制。 ## Shopify Flow 或 Functions 能处理买方审批吗？ **Flow 适合协调动作，但通知不等于强制执行采购规则。** [Shopify Flow](https://help.shopify.com/en/manual/shopify-flow) 支持 Basic、Grow、Advanced 和 Plus；Send HTTP Request 动作需要 Grow、Advanced 或 Plus，可用于连接外部审批服务。 还有一个容易忽略的限制： [Send internal email 动作](https://help.shopify.com/en/manual/shopify-flow/reference/actions/send-email) 不支持通过变量指定收件人地址。如果每家客户公司的采购主管不同，就需要合适的事务通知集成。固定的内部员工邮箱并不能实现按客户动态分配审批通知。 先明确在哪个环节阻止未授权采购，再设计自动通知。订单创建后才触发的流程，无法满足“主管批准前不得创建订单”。邮件里的批准链接也需要服务器检查：当前登录用户是否有权审批这家公司、这个地点、这个申请版本。 [Shopify Functions 的可用性说明](https://shopify.dev/docs/apps/build/functions) 区分了两种情况：使用 Functions 的公开应用可在各套餐使用，但仍受具体 API 限制；包含 Functions 的定制应用需要 Plus。因此，不能默认认为开发团队可以在 Grow 商店部署任意定制结账 Function。 具体操作的限制更窄：本次核查的 2026-07 版 [Payment Customization Function API](https://shopify.dev/docs/api/functions/latest/payment-customization) 将 `orderReviewAdd`限定为 B2B Plus，并说明其用途是商家审核。这与各套餐都支持按企业地点设置结账转草稿并不矛盾。它们是不同控制方式，也都不等于完整的买方主管审批门户。 实际选型时，要一起确认商店套餐、应用分发方式、具体 API 操作及支持的结账路径。“使用了 Shopify Functions”不足以证明兼容性。 ## 选择原生功能、审批应用，还是定制买方门户？ | 需求 | 建议起点 | 决定性测试 | | --- | --- | --- | | 您的团队审核每一笔收到的 B2B 订单 | 原生草稿审核 | 允许商家在接受订单前看到申请。 | | 员工需要客户账户所有者批准 | 试用买方团队应用 | 由正确的人批准，员工不能绕过限制直接购买。 | | 分支限额、多位审批人或成本中心 | 先验证应用，再评估明确的功能缺口 | 真正支持角色范围和规则，而不只是增加邮件收件人。 | | 实时共享预算、特殊授权委托或跨系统审批 | 定制扩展层或可扩展采购产品 | 授权、并发控制与数据核对能端到端运行。 | 保留最小但可靠的方案。一个适合的应用加上范围有限的 ERP 连接器，可能比脆弱的自动化拼接或整套自建采购平台更合理。反过来，多个低价应用也未必便宜：如果没有任何一个系统对最终审批决定负责，运营成本仍会很高。 ## 哪些订单审批应用值得评估？ ### SparkLayer：文档明确描述买方内部审批 [SparkLayer 的 Company Users 文档](https://docs.sparklayer.io/company-users) 描述了 Limited 角色，其采购申请交由企业账户所有者处理。等待批准的申请对商家不可见，账户所有者可以完成或取消。因此，它确实涉及买方审批，而不只是供应商审核。 应将其视为试用候选，而不是所有情况的通用答案。要求演示现有客户账户配置、价格、付款方式和其他结账入口。重点确认分支机构审批人、金额阈值、累计预算和提交后的变更。不能未经验证，就把一个账户所有者的批准机制描述成任意多级审批规则引擎。 ### Approovly：核实审批主体与当前运行情况 [Approovly 的 Shopify App Store 页面](https://apps.shopify.com/approovly-app) 宣传内部和外部审批申请。但应用商店介绍不能证明其支持您的企业层级，也不能证明它能在订单创建之前实施采购拦截。选择前需要验证维护情况、客服响应和完整流程是否能实际运行。 对于这两类候选，让供应商同时展示员工、审批人和商家视角下的同一份申请。观察草稿、正式订单、付款请求和 ERP 消息分别在什么时候出现。然后更改金额、切换到另一家公司，并尝试旧审批链接。这些演示比长篇功能清单更能说明问题。 评估还应包含数据导出、审批历史保留、卸载后的行为、权限范围以及集成失败的责任归属。要求书面说明适用套餐，以及应用是替代、补充还是绕过现有 B2B 账户模型。这里的比较依据文档，不是对两款应用的安装实测结论。 ## 什么情况下值得开发定制 B2B 买方门户？ **当现有配置无法可靠执行或证明一条重要业务规则时，定制开发才有明确价值。**开发对象应该是缺失的审批层，而不是重写 Shopify。 也不一定需要另建商城。Shopify 支持 [客户账户全页扩展](https://shopify.dev/docs/apps/build/customer-accounts/full-page-extensions) ，包括不依附于既有订单的页面。在引入第二套购物体验之前，应先评估嵌入式申请与审批页面，并确认账户设置及所需扩展能力兼容。 在服务器保存具有权威性的申请记录，包含客户企业、地点、申请人、合格审批人、规则版本、币种和审批金额计算依据。每次决定应绑定到一个不可混淆的申请版本，其中记录商品编号、数量、定价基础、税务处理、运费与收货地址。不能信任用户可修改的购物车属性，也不能把客户传来的“approved”标签视作授权证明。 如果批准前不得向商家暴露采购信息，采购申请应留在审批应用的存储中，放行后才创建 Shopify 草稿或订单。如果允许商家提前看到草稿，草稿可以成为流程的一部分，但必须防止通过完成草稿或发票链接绕过审批。库存保留和报价有效期也需要明确政策。 将 `pending_approval`、`approved`、`rejected` 和 `expired` 等申请状态，与 Shopify 创建状态、付款状态及 ERP 传输状态分开。一份申请可能已批准，但 ERP 提交仍然失败。把两者都叫“已完成”，会掩盖运营团队真正需要处理的异常。 ### 支出限额和多位审批人需要精确定义 单笔金额阈值不等于月度预算。需要定义金额是否含税和运费、以哪种币种为准、待批申请是否预占预算，以及拒绝或取消后何时释放。共享预算必须以原子方式检查并预留额度，避免两个并发申请分别消耗同一笔余额。 **以下为说明性政策，不是 Shopify 默认能力：**一家有八个分支机构的公司允许员工自行放行不超过 €500 的采购，但前提是本分支月度预算仍足够。超过 €500 需要分支主管批准；超过 €5,000 还需要财务批准。其他分支的主管没有审批权。实质性修改产生新版本，并使原有批准失效。 还要明确多位审批人是顺序签批、并行且全体同意，还是满足指定人数即可。代理审批需要有效期和审计记录。主管休假不能导致系统默认批准；被撤销权限的人员不能继续利用旧链接操作。这些也是采购现成应用时的验收条件，不只是定制系统的开发细节。 ## 已批准采购应如何进入 Shopify 和 ERP？ 写集成代码之前，先确定交接责任。Shopify 是否是订单主系统，还是 ERP 必须先确认信用、库存与客户映射？谁有权释放履约任务？买方批准只是允许继续处理，并不意味着后续检查全部通过。 Shopify 的 [draftOrderComplete mutation](https://shopify.dev/docs/api/admin-graphql/latest/mutations/draftOrderComplete) 将草稿转换为订单，并提供与付款相关的选项。调用它本身不代表已经收款。绝不能因为主管批准就把订单标记为已支付；仍须遵循约定的发票或账期流程。 定制集成应持续保存采购申请 ID 与版本、Shopify 草稿或订单 ID、ERP 参考号之间的映射。在保存批准决定时，一并可靠记录待执行的放行任务，再通过支持重试的队列处理。使用应用层幂等控制，以及适合目标 ERP 的唯一业务参考或唯一性约束，防止重复创建。 创建请求超时意味着结果未知，不一定是失败。重试前应核对 Shopify 或 ERP 中是否已有对应记录。Shopify 明确提醒， [Webhook 的顺序与送达都不保证](https://shopify.dev/docs/apps/build/webhooks) 。需要验证消息来源、去重，并定期核对状态，不能只依赖一次通知。 ERP 不可用时，显示“已批准，等待 ERP”，并在业务规则要求时继续阻止履约。不要发送成功邮件来掩盖失败。运营人员需要能够沿用同一个业务参考重试，而不是点击一个可能再建一张订单的按钮。 如果后台使用 Odoo，可参考单独的 [Odoo API 集成限制指南](/zh/blog/odoo-erp-api-integration-limits-2026/) 。审批流程决定采购*何时*获得授权，连接器决定这笔已授权采购*如何*可靠进入 ERP，两者不应混为一谈。 ## 购买应用或上线之前，应该测试什么？ 要求应用供应商或实施团队在非生产环境中，使用真实角色配置与有代表性的订单运行以下测试。“审批邮件已送达”只能证明通知环节有效。 | 测试场景 | 必须得到的结果 | | --- | --- | | 员工使用直接结账、保存的发票链接或其他已启用入口 | 不能通过其他路径放行未经批准的采购。 | | 另一家公司或分支机构的主管打开申请 | 拒绝权限范围之外的查看与审批。 | | 已批准的商品、金额或收货地址发生变化 | 实质性变化必须由审批人对新版本重新决定。 | | 两份申请同时使用剩余共享预算 | 只允许有效预留成功，预算不能重复支出。 | | 审批人被移除、委托他人或重复使用链接 | 检查当前权限，重复请求不能再次放行。 | | 申请被拒绝，或按测试政策在 48 小时后过期 | 不得放行，按政策处理已预占预算。 | | 等待审批期间价格或库存变化 | 明确执行有效期、预留与重新审批规则。 | | ERP 已创建订单，但响应丢失 | 核对找到既有记录，重试不产生重复订单。 | | ERP 拒绝客户信息或收货地址 | 显示可处理的异常，后续放行遵循业务规则。 | 验收证据应包括申请版本、审批决定、人员身份和下游系统参考号。既演示一次成功采购，也演示故障恢复。系统需要回答：谁依据哪版规则批准了哪些内容，最终生成了哪些 Shopify 与 ERP 记录？ ## 流程评估和实施报价应该交付什么？ 准备 Shopify 套餐与客户账户配置、一个现有下单流程、企业及分支角色、审批额度、付款规则、ERP 信息，以及一个失败或需要人工处理的案例。分享样例记录前，应先删除或遮盖个人信息与敏感商业信息。 有价值的评估应交付现状与目标流程图、原生/应用/定制的选择依据、权限与状态模型、集成边界，以及验收测试清单。实施报价应明确前提假设、配置与编程分别包含什么、第三方许可、数据迁移、运维责任和不包含的范围。 比较总运营成本，而不是只比较应用订阅费和开发报价。应计入配置、集成、支持、规则变更、回归测试和异常处理。用自己的单份申请处理时间及月度申请量建立基线，再单独加入实测返工成本。不要默认系统一定能带来某个通用的审批提速或收入增长比例。 Wavect 的 [MyMerch 案例](/zh/case-studies/mymerch/) 介绍的是有针对性的 Shopify 流程自动化，而不是平台重建。这是相关交付经验，不代表 MyMerch 采用了本文描述的审批架构。 更广泛的选型可阅读 [定制软件与现成软件比较指南](/zh/software-development-guide/custom-software-vs-off-the-shelf/) 。如果存在具体实施缺口，可进一步了解我们的 [定制软件开发服务](/zh/services/software-development/) 。 [与 Wavect 讨论 Shopify B2B 审批流程评估](/zh/contact/) ，根据真正需要执行的控制措施，确定边界清晰的实施方案与报价。 ## Shopify B2B 订单审批常见问题 ### Shopify 原生支持 B2B 订单审批吗？ Shopify 可通过结账转草稿提供商家审核，但这不等于客户公司的员工获得自己主管的批准。选型前先明确审批主体。参见 [原生能力及其边界](#native-features) 。 ### Shopify Grow 可以要求订单审批吗？ Grow 与 Basic、Advanced、Plus 一样，支持按企业地点设置结账转草稿，属于商家审核。已核查的 API 文档则将 orderReviewAdd Function 操作限定为 B2B Plus。参见 [套餐与 Functions 限制](#flow-functions) 。 ### 批发客户审核与采购审批是一回事吗？ 不是。客户审核授予 B2B 访问权，采购审批授权某一份具体申请。买方流程必须确定审批人和被批准的申请版本。参见 [三种审批类型](#approval-types) 。 ### Shopify 地点管理员能审批员工订单吗？ 文档中的 Location admin 权限包括地点订单与地址编辑，没有建立买方主管签批链。应验证明确的工作流或应用，而不是默认角色自带审批。参见 [Shopify 角色定义](#source-roles) 。 ### Shopify Flow 能给每家客户的采购主管发审批邮件吗？ Send internal email 使用固定收件人，不支持变量地址。动态外部通知需要合适的集成，审批本身还需要身份验证与服务器权限检查。参见 [Flow 的适用范围](#flow-functions) 。 ### 填写采购订单编号就代表批准 Shopify 订单了吗？ 不是。编号是采购参考，不能证明谁授权了具体内容。审批人、申请版本、决定时间和适用规则应独立记录。参见 [审批记录设计](#custom-portal) 。 ### 多位审批人或支出限额一定需要定制门户吗？ 不一定。先测试买方团队或采购产品能否执行实际层级、预算政策和批准后的变更规则。只有关键控制存在缺口，定制开发才有明确理由。参见 [选型矩阵](#native-app-custom) 。 ### 主管批准后，是否应该自动标记已付款或提交 ERP？ 批准、付款和 ERP 接受是不同事件。流程可以在批准后启动 ERP 提交，但拒绝、重试与去重需要独立处理。不能仅因批准就标记已付款。参见 [ERP 交接设计](#erp-handoff) 。 ## 最终思考 先确定审批必须控制哪个业务边界，再选择技术。原生草稿适合商家审核；经过验证的买方团队应用可能无需定制就能处理客户主管批准。只开发缺失的控制，分开管理付款与 ERP 接收，并把绕过测试和故障恢复纳入验收。 ## 你可能也喜欢.. [**Odoo API 集成限制：审批后的 ERP 交接** 采购获批后，确认接收方 ERP 的 API 和事务约束。](/zh/blog/odoo-erp-api-integration-limits-2026/) [**定制软件与现成软件如何选择** 从更广的角度判断现有平台周边的功能应该配置、购买还是开发。](/zh/software-development-guide/custom-software-vs-off-the-shelf/) 架构与平台 ## 继续浏览此集群 对长期交付产生影响的框架、平台与系统设计选择。 [从核心文章开始**智慧城市软件架构：MQTT、LoRaWAN、Kubernetes 与 Terraform**](/zh/blog/smart-city-architecture-best-practices-2026/) - [Shopify–ERP 退货与退款：标准连接器何时不够用？](/zh/blog/shopify-erp-returns-refunds-integration/) - [ERP 没有 API，如何集成？文件交换、数据库读取、RPA 还是替换系统](/zh/blog/legacy-erp-integration-without-api/) - [管理多个 Shopify 店铺：报表应用还是定制运营看板？](/zh/blog/shopify-multi-store-operations-dashboard/) - [Apple Container 与 Docker：Compose、网络及迁移指南](/zh/blog/apple-container-vs-docker-compose-migration/) - [Pake 网页转桌面应用：体积、PWA 对比与登录限制](/zh/blog/pake-website-to-desktop-app/) [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 12 分钟 阅读 · 2026年9月29日 最近审核 2026年9月29日 [**下一篇**](/zh/blog/odoo-erp-api-integration-limits-2026/) ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/zh/blog/shopify-b2b-order-approval-workflow/#webpage", "@type": "WebPage", "dateModified": "2026-09-29", "inLanguage": "zh", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-09-29", "url": "https://wavect.io/zh/blog/shopify-b2b-order-approval-workflow/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Shopify B2B 订单审批可能指客户准入、商家审核或买方主管批准。Basic、Grow、Advanced 和 Plus 的原生结账转草稿支持商家审核，但不是完整的员工向主管申请采购流程。先测试文档明确支持买方团队的应用；只有它无法可靠执行企业权限、共享预算、版本化批准或 ERP 交接时，才考虑定制审批层。选型还必须核实套餐与具体 API 限制，并测试所有可能绕过审批的结账入口。", "articleBody": " 博客概览/交付与 QA/架构与平台 Shopify B2B 订单审批：原生功能、应用还是定制买方门户？ 要点速览 Shopify B2B 订单审批可能指客户准入、商家审核或买方主管批准。Basic、Grow、Advanced 和 Plus 的原生结账转草稿支持商家审核，但不是完整的员工向主管申请采购流程。先测试文档明确支持买方团队的应用；只有它无法可靠执行企业权限、共享预算、版本化批准或 ERP 交接时，才考虑定制审批层。选型还必须核实套餐与具体 API 限制，并测试所有可能绕过审批的结账入口。 “Shopify B2B 订单审批”实际上可能指三种不同需求。商家可以审核企业客户的注册申请、审核收到的订单，也可以让客户公司的员工向自己的采购主管申请购买授权。只有第三种属于买方内部采购审批。选型首先要明确：谁审批、审批什么，以及批准之前必须阻止哪个业务动作。 一位商家在 Shopify Community 提出的需求就明确要求：员工提交采购申请，由客户公司的主管批准，之后供应商才能看到。“提交审批”按钮本身也不能说明审批权属于正确的组织。 核查日期：2026 年 9 月 29 日。平台事实依据 Shopify 官方文档；应用功能依据供应商文档，不代表经过实际安装验证。架构方案和验收条件是 Wavect 的建议。 您需要哪一种 Shopify 审批流程？ 三种不同决定，不应共用一个含糊的“已批准”状态。决定审批人授予的权限 批发客户账户审核商家允许一家企业进入 B2B 采购渠道。 商家订单审核商家的销售或运营团队供应商接受提交的采购订单。 买方内部采购审批客户公司的主管或预算负责人允许员工动用公司预算购买指定商品。 商家审核优先使用原生功能；员工向主管申请采购，优先测试支持买方团队的应用；只有应用无法可靠执行关键规则时，才确定定制开发范围。多位审批人或 ERP 对接意味着需要更严格的验证，不意味着必须更换整个商城。 把需求写成一句可以验收的话：“A 分支机构的员工可以申请商品，但只有负责 A 的指定主管才能放行这份具体申请；放行前不能创建 Shopify 订单，也不能创建 ERP 销售订单。”再根据实际政策调整条件。是否允许提前存在 Shopify 草稿订单，必须另行明确，不能默认等同于正式订单。 Shopify 原生支持什么？Grow 套餐也能用吗？ Shopify 按套餐列出的 B2B 功能表将企业、地点权限、结账转草稿和采购订单编号列为 Basic、Grow、Advanced 与 Plus 均支持的功能。“所有原生 B2B 或草稿审核都需要 Plus”已经不是准确的概括。不过，具体功能仍可能有单独的套餐限制。 账户审核决定准入，不决定每一笔采购 通过 Shopify Forms 提交的企业账户申请允许商家批准企业使用 B2B 采购。这属于客户准入。不要因为某个应用支持注册审批，就认定它能把员工的每一个购物车交给客户公司的采购主管。 原生草稿审核由商家处理 英文管理界面的路径是 Customers → Companies → company → location → Checkout → Order submission，选择 Submit all orders as drafts for review。Shopify 在结账设置文档中说明了这一配置。提交时不在结账环节付款，申请进入商家的草稿队列。 如果您的团队需要先确认库存、运费、协议价格或信用状况，再接受销售订单，这种方式很合适。但它本身不能证明客户主管授权了员工的支出。它也不满足“客户批准之前，商家什么都看不到”：商家已经能看到草稿。 地点管理员不是文档中定义的采购审批角色 Shopify 文档列出两种企业地点的客户权限：Ordering only 可以查看自己的订单记录；Location admin 可以查看该地点的全部订单并修改地址。这些定义没有建立主管签批链。客户权限与商家后台员工权限也不能混为一谈。 价格与授权同样需要分开。Shopify 说明，通过 B2B 结账提交的草稿默认锁定价格。但锁价不等于记录主管同意，不会自动预占部门预算，也没有定义更改收货地址后是否需要重新审批。这些规则需要独立设计。 采购订单编号是业务参考信息，不是预算负责人已批准订单内容的证据。“尚未付款”和“尚未授权”也是不同状态。流程设计必须分别说明，不能把延后付款直接当成采购审批控制。 Shopify Flow 或 Functions 能处理买方审批吗？ Flow 适合协调动作，但通知不等于强制执行采购规则。Shopify Flow支持 Basic、Grow、Advanced 和 Plus；Send HTTP Request 动作需要 Grow、Advanced 或 Plus，可用于连接外部审批服务。 还有一个容易忽略的限制：Send internal email 动作不支持通过变量指定收件人地址。如果每家客户公司的采购主管不同，就需要合适的事务通知集成。固定的内部员工邮箱并不能实现按客户动态分配审批通知。 先明确在哪个环节阻止未授权采购，再设计自动通知。订单创建后才触发的流程，无法满足“主管批准前不得创建订单”。邮件里的批准链接也需要服务器检查：当前登录用户是否有权审批这家公司、这个地点、这个申请版本。 Shopify Functions 的可用性说明区分了两种情况：使用 Functions 的公开应用可在各套餐使用，但仍受具体 API 限制；包含 Functions 的定制应用需要 Plus。因此，不能默认认为开发团队可以在 Grow 商店部署任意定制结账 Function。 具体操作的限制更窄：本次核查的 2026-07 版 Payment Customization Function API将 orderReviewAdd限定为 B2B Plus，并说明其用途是商家审核。这与各套餐都支持按企业地点设置结账转草稿并不矛盾。它们是不同控制方式，也都不等于完整的买方主管审批门户。 实际选型时，要一起确认商店套餐、应用分发方式、具体 API 操作及支持的结账路径。“使用了 Shopify Functions”不足以证明兼容性。 选择原生功能、审批应用，还是定制买方门户？ Wavect 的选型框架。应用必须通过实际规则测试，才能确认适用。需求建议起点决定性测试 您的团队审核每一笔收到的 B2B 订单原生草稿审核允许商家在接受订单前看到申请。 员工需要客户账户所有者批准试用买方团队应用由正确的人批准，员工不能绕过限制直接购买。 分支限额、多位审批人或成本中心先验证应用，再评估明确的功能缺口真正支持角色范围和规则，而不只是增加邮件收件人。 实时共享预算、特殊授权委托或跨系统审批定制扩展层或可扩展采购产品授权、并发控制与数据核对能端到端运行。 保留最小但可靠的方案。一个适合的应用加上范围有限的 ERP 连接器，可能比脆弱的自动化拼接或整套自建采购平台更合理。反过来，多个低价应用也未必便宜：如果没有任何一个系统对最终审批决定负责，运营成本仍会很高。 哪些订单审批应用值得评估？ SparkLayer：文档明确描述买方内部审批 SparkLayer 的 Company Users 文档描述了 Limited 角色，其采购申请交由企业账户所有者处理。等待批准的申请对商家不可见，账户所有者可以完成或取消。因此，它确实涉及买方审批，而不只是供应商审核。 应将其视为试用候选，而不是所有情况的通用答案。要求演示现有客户账户配置、价格、付款方式和其他结账入口。重点确认分支机构审批人、金额阈值、累计预算和提交后的变更。不能未经验证，就把一个账户所有者的批准机制描述成任意多级审批规则引擎。 Approovly：核实审批主体与当前运行情况 Approovly 的 Shopify App Store 页面宣传内部和外部审批申请。但应用商店介绍不能证明其支持您的企业层级，也不能证明它能在订单创建之前实施采购拦截。选择前需要验证维护情况、客服响应和完整流程是否能实际运行。 对于这两类候选，让供应商同时展示员工、审批人和商家视角下的同一份申请。观察草稿、正式订单、付款请求和 ERP 消息分别在什么时候出现。然后更改金额、切换到另一家公司，并尝试旧审批链接。这些演示比长篇功能清单更能说明问题。 评估还应包含数据导出、审批历史保留、卸载后的行为、权限范围以及集成失败的责任归属。要求书面说明适用套餐，以及应用是替代、补充还是绕过现有 B2B 账户模型。这里的比较依据文档，不是对两款应用的安装实测结论。 什么情况下值得开发定制 B2B 买方门户？ 当现有配置无法可靠执行或证明一条重要业务规则时，定制开发才有明确价值。开发对象应该是缺失的审批层，而不是重写 Shopify。 也不一定需要另建商城。Shopify 支持客户账户全页扩展，包括不依附于既有订单的页面。在引入第二套购物体验之前，应先评估嵌入式申请与审批页面，并确认账户设置及所需扩展能力兼容。 在服务器保存具有权威性的申请记录，包含客户企业、地点、申请人、合格审批人、规则版本、币种和审批金额计算依据。每次决定应绑定到一个不可混淆的申请版本，其中记录商品编号、数量、定价基础、税务处理、运费与收货地址。不能信任用户可修改的购物车属性，也不能把客户传来的“approved”标签视作授权证明。 如果批准前不得向商家暴露采购信息，采购申请应留在审批应用的存储中，放行后才创建 Shopify 草稿或订单。如果允许商家提前看到草稿，草稿可以成为流程的一部分，但必须防止通过完成草稿或发票链接绕过审批。库存保留和报价有效期也需要明确政策。 将 pending_approval、approved、rejected 和 expired 等申请状态，与 Shopify 创建状态、付款状态及 ERP 传输状态分开。一份申请可能已批准，但 ERP 提交仍然失败。把两者都叫“已完成”，会掩盖运营团队真正需要处理的异常。 支出限额和多位审批人需要精确定义 单笔金额阈值不等于月度预算。需要定义金额是否含税和运费、以哪种币种为准、待批申请是否预占预算，以及拒绝或取消后何时释放。共享预算必须以原子方式检查并预留额度，避免两个并发申请分别消耗同一笔余额。 以下为说明性政策，不是 Shopify 默认能力：一家有八个分支机构的公司允许员工自行放行不超过 €500 的采购，但前提是本分支月度预算仍足够。超过 €500 需要分支主管批准；超过 €5,000 还需要财务批准。其他分支的主管没有审批权。实质性修改产生新版本，并使原有批准失效。 还要明确多位审批人是顺序签批、并行且全体同意，还是满足指定人数即可。代理审批需要有效期和审计记录。主管休假不能导致系统默认批准；被撤销权限的人员不能继续利用旧链接操作。这些也是采购现成应用时的验收条件，不只是定制系统的开发细节。 已批准采购应如何进入 Shopify 和 ERP？ 写集成代码之前，先确定交接责任。Shopify 是否是订单主系统，还是 ERP 必须先确认信用、库存与客户映射？谁有权释放履约任务？买方批准只是允许继续处理，并不意味着后续检查全部通过。 Shopify 的 draftOrderComplete mutation将草稿转换为订单，并提供与付款相关的选项。调用它本身不代表已经收款。绝不能因为主管批准就把订单标记为已支付；仍须遵循约定的发票或账期流程。 定制集成应持续保存采购申请 ID 与版本、Shopify 草稿或订单 ID、ERP 参考号之间的映射。在保存批准决定时，一并可靠记录待执行的放行任务，再通过支持重试的队列处理。使用应用层幂等控制，以及适合目标 ERP 的唯一业务参考或唯一性约束，防止重复创建。 创建请求超时意味着结果未知，不一定是失败。重试前应核对 Shopify 或 ERP 中是否已有对应记录。Shopify 明确提醒，Webhook 的顺序与送达都不保证。需要验证消息来源、去重，并定期核对状态，不能只依赖一次通知。 ERP 不可用时", "articleSection": "B2B 商务", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "Shopify Community 提出的需求", "url": "https://community.shopify.com/t/b2b-purchase-order-approval-flow-employee-admin-in-shopify-grow-plan/614684" }, { "@type": "WebPage", "name": "Shopify 按套餐列出的 B2B 功能表", "url": "https://help.shopify.com/en/manual/b2b/getting-started/plan-features" }, { "@type": "WebPage", "name": "通过 Shopify Forms 提交的企业账户申请", "url": "https://help.shopify.com/en/manual/b2b/companies-and-customers/company-account-requests" }, { "@type": "WebPage", "name": "结账设置文档", "url": "https://help.shopify.com/en/manual/b2b/checkout-and-orders/checkout-settings" }, { "@type": "WebPage", "name": "企业地点的客户权限", "url": "https://help.shopify.com/en/manual/b2b/companies-and-customers/adding-customers" }, { "@type": "WebPage", "name": "通过 B2B 结账提交的草稿", "url": "https://help.shopify.com/en/manual/b2b/checkout-and-orders/draft-orders" }, { "@type": "WebPage", "name": "Shopify Flow", "url": "https://help.shopify.com/en/manual/shopify-flow" }, { "@type": "WebPage", "name": "Send internal email 动作", "url": "https://help.shopify.com/en/manual/shopify-flow/reference/actions/send-email" }, { "@type": "WebPage", "name": "Shopify Functions 的可用性说明", "url": "https://shopify.dev/docs/apps/build/functions" }, { "@type": "WebPage", "name": "Payment Customization Function API", "url": "https://shopify.dev/docs/api/functions/latest/payment-customization" }, { "@type": "WebPage", "name": "SparkLayer 的 Company Users 文档", "url": "https://docs.sparklayer.io/company-users" }, { "@type": "WebPage", "name": "Approovly 的 Shopify App Store 页面", "url": "https://apps.shopify.com/approovly-app" }, { "@type": "WebPage", "name": "客户账户全页扩展", "url": "https://shopify.dev/docs/apps/build/customer-accounts/full-page-extensions" }, { "@type": "WebPage", "name": "draftOrderComplete mutation", "url": "https://shopify.dev/docs/api/admin-graphql/latest/mutations/draftOrderComplete" }, { "@type": "WebPage", "name": "Webhook 的顺序与送达都不保证", "url": "https://shopify.dev/docs/apps/build/webhooks" } ], "dateModified": "2026-09-29", "datePublished": "2026-09-29", "description": "Shopify B2B 订单审批可能指客户准入、商家审核或买方主管批准。Basic、Grow、Advanced 和 Plus 的原生结账转草稿支持商家审核，但不是完整的员工向主管申请采购流程。先测试文档明确支持买方团队的应用；只有它无法可靠执行企业权限、共享预算、版本化批准或 ERP 交接时，才考虑定制审批层。选型还必须核实套餐与具体 API 限制，并测试所有可能绕过审批的结账入口。", "headline": "Shopify B2B 订单审批：原生功能、应用还是定制买方门户？", "image": "https://wavect.io/img/blog/headers/header_shopify-b2b-order-approval-workflow.svg", "inLanguage": "zh", "keywords": "Shopify B2B, 订单审批, ERP 集成", "mainEntityOfPage": { "@id": "https://wavect.io/zh/blog/shopify-b2b-order-approval-workflow/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/zh/blog/shopify-b2b-order-approval-workflow/", "wordCount": 442 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/zh/", "name": "首页", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/overview/", "name": "博客概览", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/topics/delivery-qa/", "name": "交付与 QA", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/clusters/architecture-platforms/", "name": "架构与平台", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/shopify-b2b-order-approval-workflow/", "name": "Shopify B2B 订单审批：原生、应用与定制门户", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Shopify 可通过结账转草稿提供商家审核，但这不等于客户公司的员工获得自己主管的批准。选型前先明确审批主体。参见原生能力及其边界。" }, "name": "Shopify 原生支持 B2B 订单审批吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Grow 与 Basic、Advanced、Plus 一样，支持按企业地点设置结账转草稿，属于商家审核。已核查的 API 文档则将 orderReviewAdd Function 操作限定为 B2B Plus。参见套餐与 Functions 限制。" }, "name": "Shopify Grow 可以要求订单审批吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "不是。客户审核授予 B2B 访问权，采购审批授权某一份具体申请。买方流程必须确定审批人和被批准的申请版本。参见三种审批类型。" }, "name": "批发客户审核与采购审批是一回事吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "文档中的 Location admin 权限包括地点订单与地址编辑，没有建立买方主管签批链。应验证明确的工作流或应用，而不是默认角色自带审批。参见Shopify 角色定义。" }, "name": "Shopify 地点管理员能审批员工订单吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Send internal email 使用固定收件人，不支持变量地址。动态外部通知需要合适的集成，审批本身还需要身份验证与服务器权限检查。参见Flow 的适用范围。" }, "name": "Shopify Flow 能给每家客户的采购主管发审批邮件吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "不是。编号是采购参考，不能证明谁授权了具体内容。审批人、申请版本、决定时间和适用规则应独立记录。参见审批记录设计。" }, "name": "填写采购订单编号就代表批准 Shopify 订单了吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "不一定。先测试买方团队或采购产品能否执行实际层级、预算政策和批准后的变更规则。只有关键控制存在缺口，定制开发才有明确理由。参见选型矩阵。" }, "name": "多位审批人或支出限额一定需要定制门户吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "批准、付款和 ERP 接受是不同事件。流程可以在批准后启动 ERP 提交，但拒绝、重试与去重需要独立处理。不能仅因批准就标记已付款。参见ERP 交接设计。" }, "name": "主管批准后，是否应该自动标记已付款或提交 ERP？" } ] } ```