BigCommerce 对接 Business Central：ERP 不管你准备好没有，都会更新。

关于 Business Central 支持期限的错误说法，几乎都源于用一种部署方式去回答另一种。两者是真的不一样，所以先说清楚你在哪一边。

Business Central 在线版没有公布支持终止日期。它在微软生命周期页面上只有一个开始日期和一个退役日期，而那个退役日期写的是"In Support"。那张表里根本没有主流支持结束和扩展支持结束这两栏，而这正是它与 NAV、GP 页面的结构性差别，因为在那两页里这两栏就是全部内容。它适用 Modern Lifecycle Policy：只要你保持更新、保有授权，且微软仍在提供，它就一直受支持。

Business Central 本地版则是逐版本设定日期的。这一点是合作伙伴的摘要文章最常写错的地方。目前只有三个本地版本仍在支持内：

• v26.x 到 2026 年 10 月 13 日结束。距今约七周，是本页上最近的一个有效日期。
• v27.x 到 2027 年 4 月 5 日结束。
• v28.x，也就是当前版本，到 2027 年 10 月 12 日结束。

比这更早的都已经出局了。已有十三个本地版本过了终止日期，包括 v15 到 v25 一整段，以及固定策略下列出的更早的 v13 和 v14。

这个分野的原因值得理解，而不只是背下来。微软能够自己更新在线服务，所以不必给它定日期。本地部署它做不到，因为安装时机由你掌握。于是它改为给每个版本定日期。

以上都可以在微软的产品生命周期页面上核对。如果有人报给你另一个数字，那里就是判定的地方。

Business Central 在线版在每年四月和十月各有一次大版本更新，其余大部分月份还有小更新。当前版本是 28.x，2026 年 4 月 1 日发布。

你可以推迟，但只能在一个窗口之内，而这个窗口的形状，恰恰是大多数集成没有为之设计的：

• 一个为期五个月的更新期，管理员可以在其中改到任意日期。
• 之后是一个月的宽限期，每年九月和三月各一次，在这期间你已经不能再把日期往后推了。
• 再之后是强制更新期。用微软自己的话说，导致更新失败的扩展"可能会被自动从环境中卸载，以便更新能够成功"。这些扩展的数据不会被删除，安装兼容版本后会回来，但扩展本身会被移除以清出通路。

请以集成方而不是管理员的角度读最后这一条。如果你的店面依赖某个按租户扩展，而这个扩展没能及时对下一个大版本完成编译，平台的处理方式是移除你的扩展，而不是让整个租户等你。没有哪个版本可以一直待着，也没有任何支持合同能把你买出来。

于是问题不再是你什么时候必须动，而是你的集成能不能年复一年地扛过一个四月和一个十月。这是一个关于测试和归属的问题，也是真正决定在 Business Central 上运营一家店面成本的那个问题。

在 NAV、AX 和 GP 上，捷径永远是同一条：直接读表。我们写那三个平台的页面，大半篇幅都在劝人别这么干。在 Business Central 在线版上，这场争论结束了，因为那扇门不存在。

微软在这件事上罕见地直白：对 Business Central 在线版而言，读取数据唯一受支持的方式就是通过 API。直接访问数据库根本不是一个选项，而且微软明确警告，如果你在本地部署上构建一个依赖它的集成，将来会挡住你迁往在线版的路。

这一下就悄悄淘汰了很多东西。所有 ODBC 抽取。所有针对只读副本的报表作业。所有店面逐渐依赖上的夜间 SELECT。以及，如果你是从 GP 过来的，所有 eConnect 形态的存储过程。

从集成的角度看，我们认为这是这个平台最好的一点，而且值得说清楚，因为它听起来像是限制。被强制走一份公开的契约，恰恰是另外三个页面要费力说服客户接受的设计。在这里，你想不想要都会得到它，而且"升级悄悄改动了某张表，把一个原本能跑的集成弄坏"这一类故障，根本不会发生。

Web 服务有三种类型，而且它们并不等价。其中两种，已经对一个很常见的做法挂上了移除日期。

• 标准 REST API，v2.0。仍然是当前版本，也没有任何 v3.0 的文档。用来处理常见实体很合适，而且不需要发布步骤。它并没有覆盖所有东西，其中一处缺口重要到下面要单开一节来讲。
• 用 AL 编写、随按租户扩展一起发布的自定义 API 页面。凡是标准 API 覆盖不到的，这就是正确答案。它们无法在界面中显示，而这正是要点：它们的存在是为了做一个稳定的集成接口，而不是一个谁都可能重新设计的屏幕。
• 在普通页面和查询上使用 OData v4。可行，但每个端点都要在"Web 服务"页面上手工注册并勾选为已发布，这就让你的集成依赖于一项租户配置，而那是别人可以关掉的。
• SOAP。已弃用。协议本身没有公布任何移除版本，所以谁给你一个版本号，谁就是在猜。

那两个日期。把微软发布的页面，也就是 Base Application 或第一方应用里的任何页面，暴露为端点这件事，即将走到头：

• 作为 SOAP 端点，在版本 29.0 移除，也就是 2026 年第二波。
• 作为 OData 端点，在版本 30.0 移除。

如果你的店面把 Business Central 的标准页面当作 Web 服务来读，那么这就是两个相隔约一年的硬期限，而且它们影响到你的可能性，远大于生命周期页面上的任何内容。两种情况的解法是同一个，也值得一次性做掉：改用你自己扩展里的自定义 API 页面。微软自己的建议也是同一件事，只是理由不同：一个标准界面页面会返回你不想要的东西，还会准备你从没要过的东西，而改动它的那位开发者，压根不知道你在读它。

Webhook 是存在的，在 API 页面上也能用。业务事件是更新、也更有意思的机制，但它至今仍以预览版形式记录在文档里，所以我们还不会把一家店面的订单流程放在上面。

每个 B2B 店面向 ERP 要的都是这六样。在 Business Central 上，平台已经把契约强加给你了，所以剩下的唯一问题是：这份契约说的是你的语言，还是微软的语言。

1. 这是谁。登录背后对应的客户账户，以及收货地址。注意：价格是针对付款方客户解析的，而那未必就是登录的人。
2. 他付多少钱。这个平台上最难的一块，见下文。
3. 他能买到什么。按地点的可用量，要扣除预留，而不只是账面在手数量。
4. 下单。返回 Business Central 真正的单据号，而不是先给一个店面 id、承诺以后再对账。
5. 货到哪了。发货与过账状态，承运商提供时附上追踪号。
6. 他欠多少。已过账发票、未清项和信用额度状况。这仍然是 B2B 买家登录的理由，也仍然是最后才被纳入范围的东西。

把这六样用你自己的词汇写下来，把 Business Central 的具体细节挡在它们后面。今天这样做不花什么成本，而它正是让半年一次的更新变成一次测试运行、而不是一个项目的关键。

这四篇页面里，真正决定集成成本的是价格。Business Central 看上去应该是最简单的那一个，其实不是。它更靠近 SAP，也就是必须由 ERP 来算，而不是靠近 GP，那边一个价格级别通常就能干净地同步过去。

有两个事实决定了这一点，而第二个是谁都没料到的。

标准 API 完全不暴露定价实体。API v2.0 里没有任何端点能交给你一个解析好的价格。要拿实时价格，就需要一个自定义 API 页面，或者一个直接调用价格计算的代码单元。

微软自己的电商连接器不导出价格，而是计算价格。面对为 Shopify 连接器所做的正是同一个抉择，微软选择了为该商品创建一张临时销售报价单，并在其上运行标准的价格计算逻辑。它对导出方案的局限也很坦率：那个连接器无法导出随数量变化的价格或折扣。当厂商自己的团队为一家真实店面权衡"导出还是计算"时，他们选了计算。

底层规则单看都很小，合在一起足以击败想当然的代码。最低价是按币种界定的，而不是全局的。一个价格组可以压过商品卡上更低的价格。计量单位的匹配是包含式的，所以一行留空单位的记录会作为通配符参与竞争。协议是针对付款方客户判定的，而不是购买人。订单按订单日期解析，发票按过账日期解析。而一行胜出的价格记录如果关掉了"允许行折扣"，就会正当地把你购物车正要施加的折扣取消掉，而这恰恰是店面分别计算最优价格和最优折扣时会犯的错误。

所以实务规则是：

• 你可以同步一份解析后的投影，每个定价档一份目录，但前提是没有数量阶梯或阶梯可枚举、没有促销活动参与，并且在构建时就知道付款方账户和单据日期。请按币种以及价格是否含税来切分，否则含税店面一定会算错价。
• 购物车和结账应该去问 Business Central，因为上述任一条件一旦不成立，而单是数量阶梯就足以让它不成立，投影出来的价格就只是猜测。
• 没有价格就不允许加入购物车。把按钮禁用掉，而不是接下一个注定过账失败的订单。

还有一件事要留意。新版销售定价体验目前仍然是可选的，但微软已经把它标示为将转为强制过一次，随后又推迟了日期。请把它当作路线图上的活跃风险，而不是已经定论的事情，并且在任何人给这份工作报价之前，先弄清楚你的租户实际跑的是哪一套体验。

在 NAV 和 GP 上，店面可以表现得像数据库的对等方。在 Business Central 在线版上，它是一个有公开限额的 API 客户端，而这些限额比多数人以为的要低，因为它们是按用户而不是按环境计量的。

• 每用户每五分钟滑动窗口 6,000 次请求。超出会收到 HTTP 429。如果你见过"每分钟 600 次"的说法，那是旧的按环境计量的数字，已经作废。
• 每用户五个并发请求，另有 95 个排队，最多 100 个连接。

真正咬人的是并发这个数。一家在每次商品页浏览时都实时调用 Business Central 的店面，早在接近请求上限之前就撞上了五并发这堵墙，而且故障并不表现为一个干净的 429，而是表现为请求堵在队列里、页面渲染卡住，最后返回 503。它发生在流量高峰期间，也就是商业上最要紧的那几分钟。

有两条后果值得围绕它来设计。第一，微软对限流给出的建议是把请求入队、稍后重试，这对夜间作业可行，对页面渲染不可行，所以店面要做的是缓存而不是重试。第二，如果你确实需要余量，微软自己面向电商门户的扩展建议是把负载分散到多个应用标识上，因为限额是按用户算的。

顺带纠正一条流传很广的建议：微软在 502 和 503 响应上记录了 retry-after 头，而对 429 刻意没有记录。不要在没有对着你自己的租户验证过的情况下，就假定它存在并据此写退避逻辑。

而这就是我们到处都在推荐的那个划分的全部理由：目录页和搜索页由缓存数据提供，购物车和结账去问 ERP。

• 集成把微软的标准页面当作 Web 服务来读。今天能用，而且已经有了移除日期：SOAP 是版本 29.0，OData 是 30.0。这是我们预计在现有项目上最常见到的一种。
• 价格是导出来的，不是算出来的。在出现数量阶梯、促销活动，或者付款方与购买人不一致之前都很好，之后就会非常自信地给出错误结果，而且没人会发现，直到有人对某张发票提出异议。
• 店面在每次页面浏览时都调用 ERP。低流量下测试通过，促销上线那天开始排队并超时。
• 一个没人负责的按租户扩展。今天能编译，对下一个大版本就编译不过，而平台的处理办法是把它卸载，而不是让租户延后。
• 可用量忽略了预留。同步的是在手量而不是可用量，于是店面把别处已经占用的货又承诺了一遍。
• 订单重复。没有幂等键，一次针对被限流端点的重试就会创建第二张单据，而这是在仓库里被发现的，不是在日志里。
• 没有人记录 ERP 返回了什么。几个月后价格产生争议时，没人答得上来当时 Business Central 到底说了什么。