BigCommerce，深度对接您的 ERP。
ProjectThunder 通过中间件与 iPaaS，将 BigCommerce 与 SAP、Microsoft Dynamics 365、NetSuite 和 Acumatica 相连接，再对店面进行工程化打造，让价格、库存和订单呈现出实时的体验，即便平台采用的是同步而非实时读取 ERP 的方式。下面介绍这套机制的真实运作原理，以及衔接处的关键所在。
真正需要同步的内容。
ERP 集成绝不是一条单一的管道。它是一组数据流，每一条都有各自的方向、延迟目标和失败处理方式。把每一条的契约做对，店面就能如实反映真相；做错了，买家就会看到过时的价格、超卖，或是永远到不了 ERP 的订单。这是我们在任何编码之前首先梳理的内容。如果您的价格确实必须实时读取而非同步，那是另一种架构，我们的 Sana Commerce vs BigCommerce 对比文章介绍了何时该做出这一选择。
商品目录与产品数据
- 方向：由 ERP 至 BigCommerce，ERP 物料主数据是唯一真实来源
- 产品、SKU、变体、计量单位和分类层级，映射到 BigCommerce 的
Catalog对象 - 物料属性、规格和规格表在导入过程中得到丰富，通常借助 AI 协助完成
- 生命周期标记：新品、停产、替代品，以及各店面的渠道可见性
- 由物料主数据变更事件触发同步，并以每晚一次的对账作为安全网
客户专属价格
- 方向：由 ERP 至 BigCommerce，是最难做对的数据流
- 合同价格、客户组、批量折扣和区域条款，映射到 BigCommerce 价格列表
- 通过 GraphQL Storefront API，使用客户模拟令牌为每位买家呈现专属价格
- 妥善处理促销以及标价与净价的关系，确保显示的价格等于下单的价格
- 注意平台限制：GraphQL 无法按价格列表中的价格排序，因此我们围绕这一点设计搜索与排序
库存与可承诺量
- 方向：由 ERP 或 WMS 至 BigCommerce，是对延迟最敏感的数据流
- 在库存变更事件发生时推送近乎实时的库存更新，而非缓慢轮询
- 在目录支持的前提下，提供多仓库和按位置感知的可用性
- 让可承诺量逻辑如实反映：缺货补单规则、安全库存和交货周期都体现在产品详情页
- 在同步滞后时防止超卖的保护机制，包括加入购物车时的软预留
客户与账户
- 方向：双向，ERP 客户主数据与 BigCommerce 公司账户保持一致
- B2B 公司账户、子采购人和收货地址，映射到 ERP 的售达方与送达方记录
- 客户组分配同时驱动价格和目录可见性
- 新账户创建走审批流程，而非未经核查就自动推送到 ERP
- 从 ERP 读取账期、信用额度和应收账款冻结，使结账环节予以遵循
订单
- 方向：由 BigCommerce 至 ERP，状态再回传
- 网店订单以正确的单据类型和记账流程，作为 ERP 销售订单提交
- 使用幂等键，确保重试绝不会在 ERP 中生成重复订单
- 将 B2B Edition 的报价转订单和采购单上传流程，干净利落地映射进 ERP
- 订单、发货和物流跟踪状态回传至买家的账户视图
发票与信用
- 方向：由 ERP 至 BigCommerce，只读地进入买家门户
- 在账户区域呈现未结发票、余额和单据附件
- 赊账结账受实时信用状态约束，被冻结的账户无法超额下单
- 付款和结算状态与 ERP 应收账款总账进行对账
- 店面不进行任何财务写入，ERP 始终是应收账款的记录系统
经得起生产考验的集成模式。
平台采用的是同步而非实时读取 ERP，因此工程上的任务，就是让一个同步的店面表现得像实时的一样，并在 ERP 无法访问时优雅降级。这些就是我们常用的模式。
中间件与 iPaaS
- 使用 iPaaS 连接器（
Celigo、Boomi、Jitterbit、MuleSoft）处理标准的目录、价格、客户和订单数据流 - 在已有且开箱即合数据模型的情况下，采用打包式 ERP 连接器
- 对于连接器无法建模的数据流，使用
.NET 9编写定制服务：特殊价格、多实体、严格延迟 - 通常采用混合方案：以 iPaaS 作为通用实体的主干，针对例外情形编写定制代码
- BigCommerce 一侧通过
REST Admin、GraphQL Storefront和 webhook 进行对接
实时与批处理
- 对延迟敏感的库存、订单和信用，采用事件驱动（webhook 和 ERP 变更事件）
- 对完整目录和分类树等变动缓慢的数据，采用计划批处理
- 每晚一次的对账，用以捕捉因遗漏事件而未同步的任何内容
- 各数据流的延迟预算事先约定，而非对所有内容采用单一的同步频率
- 与相关方坦诚说明：BigCommerce 上是近乎实时，而非 Sana 所提供的实时读取
Webhook 与幂等性
- BigCommerce 的 webhook 处理订单和客户事件，ERP 事件处理库存和价格
- 每次写入都带幂等键，确保重试和重复投递绝不会重复提交
- 在两个平台之间设置持久化队列（例如
RabbitMQ或托管消息总线），而非直接调用 - 有序、可重放的处理方式，使一波突发事件无法扰乱状态
- 对反复失败的事件进行死信处理，上报给运维而非直接丢弃
用于呈现实时价格的缓存
- 客户专属价格预先解析为价格列表，而非每次请求都重新计算
- 对高读取量数据设置短 TTL 缓存，并在 ERP 变更时进行事件驱动的失效处理
- GraphQL Storefront 查询限定于客户令牌范围，使每位买家只看到自己的价格
- 对目录元数据采用边缘缓存，与按买家的价格分开存放，确保不会泄露
- 最终在买家看来如同实时，同时让 ERP 免受店面级别流量的冲击
ERP 无法访问时的错误处理
- 店面继续以最近一次良好的同步状态提供服务，绝不会陷入瘫痪
- 订单带幂等键排队，待 ERP 恢复后提交，绝不会悄然丢失
- 设置熔断器和退避机制，使缓慢的 ERP 不会蔓延成缓慢的店面
- 当实时检查无法完成时，信用和可承诺量回退至保守规则
- 清晰的运维告警，使停滞的桥接成为一次报警，而非一通客户投诉
可观测性与运维
- 从店面到中间件再到 ERP 共享关联 ID，实现端到端的链路追踪
- 集中式同步监控：队列深度、各数据流的延迟，以及最近一次成功同步的时间戳
- 针对价格、库存、结账和订单回传，在预演环境上进行合成检查
- 为桥接准备运行手册和告警，使商务运营绝不会悄然劣化
- 对账报告在买家之前发现 BigCommerce 与 ERP 之间的偏差
我们与 BigCommerce 集成的 ERP。
每一种 ERP 暴露数据的方式各不相同，因此即便 BigCommerce 一侧保持不变，集成设计也会随之改变。下面介绍我们对最常见的几种系统的处理方式。
SAP S/4HANA 与 Business One
- 将 S/4HANA 的定价条件类型、销售范围分配和可承诺量，映射进 BigCommerce 的价格列表和库存
- 面向中端市场分销商的 Business One，含物料主数据与业务伙伴定价流程
- 读取信用管理，使被冻结的订单绝不会进入结账环节
- 通过
Avalara或Vertex处理感知 SAP 的税务，而非在店面中重建
Microsoft Dynamics 365
- 面向中端市场的 Business Central：客户定价组、维度，以及销售订单回传
- 面向企业级的 Finance and Operations：贸易协议、法人实体，以及感知仓库的可承诺量
- 在尚未完成升级的场景下，支持旧版
NAV和GP - 多公司租户可呈现为一个或多个 BigCommerce 店面
NetSuite
- 通过 SuiteTalk 和 RESTlet 集成物料、客户、价格和销售订单
- 将客户专属和按数量的定价映射到 BigCommerce 价格列表
- 按店面处理多子公司和多币种
- 库存和履约状态回传至买家的账户视图
Acumatica
- 基于合同的 REST API，集成物料、库存、客户和订单
- 将客户价格类别和特殊定价映射进价格列表和客户组
- 在相关场景下，在产品详情页体现仓库及批次/序列号感知
- 按需在各店面之间建模分支机构和实体的划分
BigCommerce ERP 集成，为您解答。
BigCommerce 能显示实时的 ERP 价格吗？
BigCommerce 不会像 Sana Commerce 那样实时读取您的 ERP。平台从自身的目录和价格列表提供价格，因此诚实的回答是近乎实时，而非实时。您可以通过将客户专属合同价格映射进 BigCommerce 价格列表和客户组、借助客户令牌经由 GraphQL Storefront API 呈现，并以事件驱动的同步和较短的缓存窗口保持其新鲜，从而获得实时般的体验。若要在浏览的那一刻真正实时读取每一个价格，Sana Commerce Cloud 正是为此而生的架构。
BigCommerce 如何连接 SAP、Dynamics 或 NetSuite？
通过中间件。BigCommerce 经由其 REST Admin 和 GraphQL API 以及 webhook，暴露目录、价格、客户和订单，再由一个集成层将其映射到您的 ERP。该层可以是 Celigo、Boomi、Jitterbit 或 MuleSoft 之类的 iPaaS 连接器，也可以是面向 SAP S/4HANA 和 Business One、Dynamics 365 Business Central 和 Finance and Operations、NetSuite 或 Acumatica 的打包式连接器。目录和价格由 ERP 流入 BigCommerce，而订单、客户和付款状态则回流。我们负责设计字段映射、同步触发和失败处理。
我们应该用中间件还是定制集成？
这取决于您的数据有多标准。当您的目录、价格和订单流程符合连接器的假设时，预制的 iPaaS 连接器更快也更省钱。而当您有特殊的定价逻辑、多 ERP 或多实体架构、严格的延迟目标，或连接器无法建模的后台工作流时，定制集成才值得其成本。我们常常两者并用：以 iPaaS 作为通用实体的主干，再用有针对性的定制服务处理那些不适配的部分。
这与 Sana 的实时 ERP 读取有何不同？
Sana Commerce Cloud 让店面成为 ERP 的客户端，因此价格、库存、信用和订单状态都在浏览的那一刻直接从 SAP 或 Dynamics 读取，没有单独的副本。BigCommerce 则保有自身的目录，并将 ERP 同步进来，因此您要自行掌控同步及其边缘情况，但换来店面的灵活性、庞大的应用生态，以及 B2B 与 B2C 融合的模式。两者都不是放之四海而皆准。我们两者都做，并按项目给出建议。请阅读完整的 Sana Commerce vs BigCommerce 解析。
准备好把 BigCommerce 接入您的 ERP 了吗？
告诉我们您的 ERP、您的定价模式，以及您的库存需要多实时。我们会梳理数据流，并给您一份清晰的方案，包括平台的近乎实时模式何时足够、何时不够。
877.609.9029