BigCommerce 与 Dynamics GP：为你已经知道会到来的那次迁移而建。

这一点值得直说，因为 GP 社区里流传的各种归纳彼此矛盾，而且至少有一个被广泛引用的日期已经被修订过。

如果你在 GP 18.x，即 Modern Lifecycle Policy 下的当前版本：

• 2029 年 12 月 31 日。产品增强、法规与税务更新、Service Pack 以及技术支持全部结束。该日期由最初公布的 2029 年 9 月 30 日往后推迟，以便客户能完整走完一个薪资与税务年度。
• 2031 年 4 月 30 日。安全更新结束，订阅计费与 SPLA 使用也在此终止。

如果你在更老的版本上，即 Fixed Lifecycle Policy 之下，日期要近得多，而且其中两个已经过去：

• GP 2016 与 2016 R2：延长支持已于 2026 年 7 月 14 日结束。这已经是过去时。如果这就是你，那你现在已经处于无支持状态。
• GP 2018 与 2018 R2：延长支持于 2028 年 1 月 11 日结束。
• GP 2015 及更早版本：早已越过终止支持。

一个容易让人措手不及的细节：在 GP 2018 上安装任何当前的税务发布或修补程序，都会把你带到 18.5 或更高版本，从而进入 Modern Lifecycle，拿到 2029 与 2031 这两个日期。并不存在既装这些更新、又留在固定生命周期上的受支持做法。

来源：微软自己的 Dynamics GP 生命周期文档。如果某个合作伙伴给你的是另一个日期，请以那里为准核对。

在这个行业里，三年以上是很长的时间。一套跑在 GP 上、运转良好、持续创收、且业务形态没有改变的商城，不需要被人推着做任何事；我们也不会为了卖一个项目而假装相反。

但商城这个问题，与 ERP 那个问题，是真正不同的两件事，而人们恰恰在这里判断失误。如果你按 2016 年那种做法，把 BigCommerce 与 GP 紧紧绑在一起，那么当 GP 被替换时，你要迁移的就不只是一套 ERP：你要迁移一套 ERP，外加重建一套你等于付了两次钱的商城集成。

所以现在真正要紧的决定，不是何时离开 GP，而是这道接缝怎么建。建得好，将来迁到 Business Central 或你选择的任何系统，只触及一个适配器和一轮测试。按通常的做法建，它就会变成一个没人列进预算的第二个项目。

这就是本页的全部论点。它对你的价值大于对我们的价值，因为它让工作量变小。

BigCommerce 是简单的那一端：有文档的 REST 与 GraphQL API、Webhook、价格表与客户组，B2B Edition 还增加企业账户与层级。

GP 提供的路径比 SAP 多，而它们在「能否扛过一次迁移」上差别极大：

• eConnect。向 GP 写入数据的正解。事务化、带校验，并且尊重 GP 的业务逻辑而不是绕开它。如果订单要写进 GP，通常就走这里。
• 直接 SQL 读取。快、简单，用于读取库存、价格与客户数据是正当的。正当到很方便，于是有人也开始用它写入，而那一刻它就不再正当了。
• 直接 SQL 写入。不要。绕过 GP 的业务逻辑会产生「看着对、行为错」的记录，而损害通常在月末结账时才浮现，而不是在你造成它的那一刻。
• Web Services for Dynamics GP。SOAP 时代的产物，现场仍能见到，但对新项目很少是正确选择。
• SmartConnect 及同类工具。eOne 的工具在 GP 世界确实很普及，能替你完成大量映射与调度工作。是合理的选择，有真实的运维成本，也要知道它将来同样是需要迁移的一样东西。

从迁移视角看：eConnect 与直接 SQL 都是「GP 形状」的，而这两个概念在 Business Central 中都不存在，后者用的是 OData 与 AL 扩展。所以无论你选哪一个，目标都是把这个选择收拢在一处，别让它蔓延进商城。

每一个 B2B 商城向它的 ERP 索取的都是同样六件事。用你自己的语言、而不是 GP 的语言把它们写下来，是你今天能做的、让将来那次迁移变得平淡无奇的最便宜的一件事。

1. 这是谁。登录账号背后的 GP 客户编号，以及送货地址；后者在 GP 里是一个独立概念，人们经常忘了做映射。
2. 他付多少。他的价格级别；如果启用了该模块，则是他的 Extended Pricing 价格表。下面会细说，因为在这一点上 GP 确实比 SAP 容易。
3. 他能拿到多少。按站点的可用数量，而不只是现有库存；而「已分配」与「现有」的区别，在两张订单相撞的那一刻就会变得重要。
4. 下单。通过 eConnect 写入 Sales Order Processing，并返回真实的 GP 单据号，而不是「稍后会同步」的承诺。
5. 货到哪了。拣配与发运状态；承运商有回传时，还要带上运单跟踪。
6. 他欠多少。来自 Receivables Management 的发票历史、未清应收与信用额度。这才是 B2B 买家真正登录进来要看的部分，也一贯是最后才有人纳入范围的部分。

如果你读过我们的 BigCommerce 与 SAP 页面，那边的定价一节是一则警告。这里则更接近一句安心话，而且这个差别是真实的，不是修辞。

GP 的标准定价是价格级别：给客户分配一个级别，商品按级别、按计量单位持有价格。这是一次查表，而不是一次计算；而查表结果可以放心地同步到 BigCommerce 的价格表与客户组。对很多用 GP 的企业来说，故事到此为止，集成成本也因此明显低于 SAP 那一侧。

它不再简单，是在启用 Extended Pricing 之后。它带来价格表单、按日期生效的价格、数量阶梯与促销，于是开始更像一次计算而不是一次查表。它仍然比 SAP 的条件技术简单得多，但已经足以让「导出一份扁平价格文件」在例外情形上出错。

我们遵循的规则：

• 只有标准价格级别？那就同步。让同步保持高频且由事件驱动，并按计划做对账，好让偏差被我们发现，而不是被客户发现。
• 启用了 Extended Pricing、合同价或按客户的价格覆盖？那就在购物车环节向 GP 询价并缓存结果，也就是 SAP 那页所讲的同一套纪律。
• 无论哪种情况，没有价格就不允许加入购物车。如果 GP 对该客户与该商品没有价格，就禁用它，而不是接受一张注定会在下游失败的订单。

为将来记一笔：Business Central 的定价模型更接近 GP 而不是 SAP，因此一套围绕「取这个客户、这个商品的价格」干净构建的 GP 集成，迁过去时无需重新构思。

即使你不雇任何人，这一节也值得照做。

• 在中间放一层集成层。商城只和你的这层说话，这层再去和 GP 说话。当 ERP 在底下更换时，你重写的是一个适配器，而不是一家商城。
• 用你自己的语言定义那六项契约。「取这个客户、这个商品的价格」是一个能活得比 GP 更久的稳定概念；「调用 eConnect 的这个存储过程」不是。
• 别让 GP 的词汇进入商城。不要有 GP 形状的客户编号、单据类型代码或站点 ID 渗进你的前端代码。在边界处做映射。现在几乎免费，之后再补则很贵。
• 记录 ERP 返回了什么，而不只是你发送了什么。十八个月后有人来争一个价格时（一定会有），问题是当他查看的那一刻 GP 说了什么。
• 把集成测试写在契约之上。它们随后就成为你迁移到 Business Central 时的验收套件，而那是那个项目上最大的一笔成本节省。

这些都不高深，在建设当下也都不贵；但每一条事后补都很贵。这也正是它值得在任何人写方案书之前就先摆出来的原因。

• 有人用 SQL 往 GP 里写数据。这一类里最常见的严重问题。测试时一切正常，产出的记录却会让报表和月末结账悄悄对不上。
• 订单重复。提交时没有幂等键，于是一次重试或一次双击就在 Sales Order Processing 里生成两张单据，而没人发现，直到拣配环节发现。
• 库存承诺了发不出去的货。同步的是现有库存而不是按站点的可用量，于是分配情况对商城完全不可见。
• 价格漂移。价格级别在夜里同步，GP 里上午十点改了价，而商城一直按昨天的数字卖到下一次同步。
• 集成其实是某个人电脑上的一个计划任务。在 GP 世界里，这比大家愿意承认的更常见；而它会在那台机器被换掉的那天停止工作。
• 商城代码里藏着「GP 形状」的假设。在迁移当天之前都看不见，一旦到那天，它会把「换一个适配器」变成「重建」。