当 ERP 已经有了继任者：BigCommerce 对接 Dynamics NAV 或 AX。

下面这些是逐条从微软自己的生命周期页面取来的，因为各版本之间只差几个月，而合作伙伴圈子里流传的汇总常常是错的。

• Dynamics NAV 2016：扩展支持已于 2026 年 4 月 14 日结束，已经过去了。
• Dynamics NAV 2017：扩展支持于 2027 年 1 月 11 日结束。这是本页上最近的一个仍然有效的日期。
• Dynamics NAV 2018，NAV 的最后一个版本：扩展支持于 2028 年 1 月 11 日结束。
• Dynamics AX 2012 R3，AX 最后一个本地部署版本：扩展支持已于 2023 年 1 月 10 日结束。

其中两条值得单独拿出来说。

如果你在 NAV 2017 上，剩下的是几个月而不是几年。这算不上紧急，但已经近到足以让今年计划的任何集成工作都应该把迁移一起考虑进去，而不是放在迁移之后。

如果你在 AX 上，无论哪个版本，今天都已经没有支持了。AX 2012 R3 是最后一个仍叫 AX 的版本，2023 年 1 月退出支持。继任者 Dynamics 365 Finance and Operations 其实是同一条代码线换了名字，而且微软确实支持从 AX 2012 R2 或 R3 升级过去：通过代码升级服务把自定义 X++ 带过去，通过数据升级把完整的交易历史带过去。你缺的是一个还受支持、可以一边待着一边规划的 AX，这一点也值得直说：没有任何东西停止运行，但也没有任何东西还在被修复。

以上都可以在微软的产品生命周期页面上核对。如果某家合作伙伴报给你另一个日期，那里就是判定的地方。

ERP 一旦有了终止日期，本能反应往往是把周边的一切都冻结起来，等迁移做完再说。这通常是更贵的选择，因为迁移会拖期，而店面在这两年里挣不到它本该挣的钱。

店面和 ERP 是两个独立的决定。终止日期真正改变的只有一件事：你的集成有多少部分被允许知道自己是在跟 NAV 或 AX 说话。

把它建成这样：店面只跟你自己的集成层说话，集成层再跟 ERP 说话。等 NAV 变成 Business Central、AX 变成 Finance and Operations 时，你重写一个适配器，跑一遍测试。要是按大多数项目当年的做法去建，把 ERP 的字段名和单据类型散落在店面代码各处，那么 ERP 迁移会连带拖出一次完整的店面重建。

这就是全部论点。它让项目变小而不是变大，考虑到是谁在提这个论点，这一点值得说明。

两者之中，NAV 更好对接，之后也更好迁移，因为 Business Central 确实是同一血统，而不是另一个产品借用了家族姓氏。

可用的入口：

• 页面与代码单元 Web 服务。正确答案。NAV 可以把页面和代码单元发布为 SOAP，从 NAV 2013 起还可以把页面和查询发布为 OData。在 NAV 上代码单元只能走 SOAP；通过 OData 调用代码单元是 Business Central 才有的能力，NAV 没有。为此专门写一个代码单元并发布，远好过直接暴露一个标准页面然后指望它的结构不变。
• 用 OData 做读取。直接、可缓存，也是 NAV 最接近现代接口的东西。读取商品目录、价格和可用量时优先用它。
• 直接读 SQL。可行，但要有一贯的警惕：NAV 的表结构不是公开契约，版本之间会变。
• 直接写 SQL。不行。NAV 的业务逻辑在代码里而不在数据库里，绕过它写入会产生过账错误或根本无法过账的记录。

为什么这条路上的迁移更温和：Business Central 保留了同一套数据模型和同一套过账逻辑，主要变化是从 C/AL 转到 AL 扩展。一个建立在已发布 Web 服务之上、而不是建立在表内部结构之上的 NAV 集成，迁到 Business Central 时只需重写适配器，契约保持不变。AX 那条路上就不是这样。

AX 是更难的一种情况，两头都难：集成接口更旧，目的地也更远。

可用的入口：

• AIF，即 Application Integration Framework。AX 2012 里官方认可的路径，提供单据服务和自定义服务，可走多种传输方式。用起来很啰嗦，但它确实尊重 AX 的业务逻辑，这比使用手感更重要。
• 自定义服务。通常是务实的选择：直接写一个服务来回答店面真正要问的那个问题，而不是把一个单据服务硬掰成那个形状。
• .NET Business Connector。在不少老集成里还能见到，已经废弃，不应作为新工作的基础。
• 直接读 SQL。很常见，而且比在 NAV 上更危险，因为 AX 的表布局对外来者相当不友好，代理键和按公司分隔的数据都很容易在细微处弄错。

为什么迁移更难：微软确实为这条路提供了工具：代码升级服务会转换现有的 X++，数据升级会带走完整的交易历史。但它仍然是一个升级项目而不是一次版本更替，微软自己也这么说：它把这套工具描述为一个框架而非完整方案；虚拟公司和数据分区会直接让升级无法进行；AX 2012 RTM 甚至不是受支持的起点。数据模型经过大幅重做，AIF 也被 OData 和 Data Management Framework 取代，所以你当初对接的那层集成接口并不会跟着过去。因此 AX 集成的有用寿命比 NAV 集成更短，这更说明应该把与 ERP 相关的那部分做得尽可能小、尽可能隔离。

如果这听起来和我们对遗留 .NET 应用的一贯说法一样，那确实是同一个说法。我们把它写在了遗留 .NET 现代化里，而用 AX 的企业往往还同时背着那篇里描述的其他几套系统。

每个 B2B 店面向 ERP 要的都是这六样。用你自己的词汇而不是 NAV 或 AX 的词汇把它们写下来，就是上面全部内容的具体做法，而且今天这样做不花什么成本。

1. 这是谁。登录背后对应的客户账户，以及收货地址。在 AX 上还要包括是哪个法人实体，否则按公司分隔的数据迟早会咬你一口。
2. 他付多少钱。NAV 的销售价格与行折扣，或者 AX 的贸易协议。下文详述。
3. 他能买到什么。按地点或仓库的可用量，要扣除预留，而不只是账面在手数量。
4. 下单。返回 ERP 真正的订单号，而不是先给一个店面 id、承诺以后再对账。
5. 货到哪了。发货与过账状态，承运商提供时附上追踪号。
6. 他欠多少。已过账发票、未清项和信用额度状况。这仍然是 B2B 买家登录的理由，也仍然是最后才被纳入范围的东西。

这一组三篇页面里，真正决定集成成本的是价格，而 NAV 和 AX 落在中间。

NAV 用的是销售价格和销售行折扣，而且两者并不按同一组维度解析。价格按客户、客户价格组、营销活动、全体客户和日期解析；行折扣则按客户、客户折扣组、营销活动和日期解析，并且针对的是单个物料或一个物料折扣组。客户价格组和客户折扣组是客户卡上两个不同的字段，把它们当成一个，是我们在 NAV 上最常遇到的定价配置错误。数量阶梯、计量单位和币种也都在其中，NAV 取的是最低价格配上允许的最高行折扣。这比一次平铺的查表要多，又远比一次完整计算要少。对于设置简单的情况，同步到 BigCommerce 价目表是可行的。一旦营销活动和相互重叠的折扣参与进来，就去问 NAV。

AX 用的是贸易协议，这是两者中能力更强的一套：价格、行折扣、多行折扣和总折扣四类日记账，可以挂在某个客户、某个客户价格组或折扣组上，也可以挂在全体客户上，并带有日期区间和数量阶梯。但这些组合并不可互换，而估算出错就出在这里：价格必须指向具体的单个物料，因为价格是一个绝对值而不是一条规则；多行折扣只能做在组一级；行折扣与多行折扣能不能叠加，取决于应收账款折扣参数的设置。对 AX 的价格，更应该按我们对待 SAP 的方式来处理：在加入购物车时向 ERP 询价，并缓存结果。

对两者以及对 GP 都成立的规则：

• 目录页和搜索页可以显示缓存价或参考价。没有人是按列表页开票的。
• 购物车、报价和结账必须是 ERP 的实时数字，因为那才是最终过账的数字。
• 没有解析出价格就不允许加入购物车。NAV 和 AX 都不会因为找不到客户专属价格就拒绝订单：NAV 会回退到物料卡上的单位售价，AX 会回退到已发布产品的基准价，或者在从未设置时回退到零。这类订单能正常过账，几个月后才以毛利问题的形式浮现。所以应该由店面把它拦住，而不是让 ERP 去猜。

• 集成是照着表内部结构做的。在升级之前一切正常，升级之后就悄悄地错了。它也是唯一能把一次 Business Central 或 F&O 迁移从重写适配器变成整体重建的因素。
• AX 的公司上下文是隐含的。有人默认只有一个法人实体，于是第二个实体会非常自信地给出错误的价格和库存。
• 可用量忽略了预留。同步的是在手量而不是可用量，于是店面把别处已经占用的货又承诺了一遍。
• 订单重复。没有幂等键，一次重试就会创建第二张订单，而这是在仓库里被发现的，不是在日志里。
• 一切都跑在一个老化的中间件作业上，只有一个人看得懂，而它的调度自设好以来没人复查过。
• 没有人记录 ERP 返回了什么。几个月后价格产生争议时，没人答得上来当时 NAV 或 AX 到底说了什么。