Sana Commerce 跑在 Business Central 上，越过宣传册之后。

你读过的每一个页面都以同一句话开场：实时、无同步、无中间件。对订单侧而言这话准确，对商品目录而言它不是全貌，而你会在 Sana 自己的管理指南里发现这一点。

Sana 公布了一张 ERP 数据的默认缓存表。被缓存的数据，用 Sana 的原话说是"product details, prices and stock"。商品详情、商品列表、批量商品数据、购物车和订单历史的默认值都是二十分钟，站点菜单是六十分钟。

另外，商城的商品目录根本不是从 ERP 读的。它由一个按计划运行的商品导入任务构建成索引，而 Sana 写明："Webstore search functionality, sorting and filtering of products, phonetic search and product sets configuration depends on the product information that is indexed."

所以准确的模型是这样的。客户专属价格、税金、费用、信用额度和订单校验，是在购物车和结账时于 Business Central 中实时计算的。而你浏览、搜索和筛选的一切，是一份按计划刷新的索引。两半都要紧，但只有一半印在宣传册上。

Sana 对原因很坦率，这段值得完整引用，因为它告诉你正在做的是哪一类决定："Performance of your application will drop when the duration is set less. This is because the amount of calls to your ERP system will increase, which is much slower then retrieving the cache."拼写是他们原文如此。

这就把你项目里的问题换了一个提法。问题不是这套集成是不是实时的，而是你的库存和价格展示到底需要多新，因为那是一个旋钮，另一头挂着有据可查的性能代价。如果你卖的是稀缺库存，二十分钟前的库存数字会造成真实麻烦，那这是一场应该在签约前而不是验收测试时进行的对话。

Sana Commerce Cloud 一边被描述成会自动更新的 SaaS，一边又被描述成可定制。Sana 自己的文档说这两者是二选一，而不是可以兼得："Customizing Sana Commerce Cloud using the SDK means abandoning SaaS and thus no automatic upgrades."

这条线画在"改动发生在哪里"。Sana 写明："custom projects cannot be automatically updated to a newer Sana version because customizations are done in the Sana core code"，以及"If all customizations can be done using the extension points of Sana, you can still receive updates automatically."

于是有一个问题成了任何 Sana 需求评估中最要命的一个，而且要对清单上的每一条需求都问一遍：

• 你会转到一条长期支持分支上，不再接收自动更新。
• 一个支持倒计时开始了。Sana 对某个框架版本自发布起主动支持三年，之后被动支持两年，而被动支持仅限严重问题的热修复，并且用 Sana 的原话说是"always on time and material"。
• 你失去自助管理。在定制项目上，用户要安装一个标准客户自己在 Sana Admin 里就能装的应用，得"need to contact their Sana Commerce representative"。

Sana 没有记录任何从定制项目回到标准轨道的路径。我们也不知道有这样的路径，而且我们会希望在有人签字之前把这一点写进书面。

两个发布日历你一个都做不了主，而且它们比多数项目预想的要多。

• Sana 框架大约每两周发一次，发布日之后还要最多两周才铺完。这不是你排期的。
• Sana 的 ERP 连接器走自己那班车，大约每季度一次。
• Sana 的各类应用又是单独版本。
• 微软每年四月和十月各发一次 Business Central 大版本，并强制推进已安装的扩展。没有任何设置能让一个 AppSource 应用在大版本浪潮中固定不动。

Sana 在 Business Central 里专门提供了一个 Compatibility Level 设置，用来吸收它的连接器与底下微软版本之间的落差，这本身就说明落差是预期之内而非例外情况。

还有一条通常不会在商务阶段被提起的合同义务，值得完整读一遍："All standard Sana Commerce Cloud customers have the obligation in their license agreement to update the Sana ERP connector at least every two years."我们没能在任何地方找到 Sana 对违反此项后果的说明，所以我们不会去编造一个。但这是你签下的一项义务，而它存在的原因正是：不受支持的方向是旧连接器配上更新的框架。

对你可能读到过的一种说法的更正，包括我们自己早前的一版判断在内。微软的强制更新不会把一个 Cloud 客户推进不受支持的状态。Business Central 云版有豁免，而每两年更新连接器这项义务，恰恰就是防止大家所担心的那种故障的机制。真正需要规划的事实要窄得多，但依然值得规划：成功应用的大版本无法回滚；阻碍强制更新的扩展可能被自动卸载；而针对你自己数据的真实演练要到正式发布才能开始，除非你的合作伙伴持有 Partner Sandbox 许可，那确实能提前拿到。

上架 AppSource 读起来像是自助服务。扩展本身什么也做不了：一套能跑的系统需要另行签约的 Sana 环境，而在 Business Central 本地版上，没有 Sana 合作伙伴根本拿不到这个扩展。

真正落进你租户里的东西，值得在 Business Central 管理员从工单里得知之前先知道。

• 权限集必须发给那些永远不碰商城的人。Sana 会往物料表上加自定义字段，而没有对应权限集的话，这些字段会让财务和仓库同事无法编辑物料。这是一次落在你 BC 管理员头上的全租户铺开，而不是电商项目内部的事。
• 商品可能从站点上消失，而任何地方都不报错。包含 Sana 不允许字符的物料和客户会被静默排除。它们只出现在 Business Central 的两个概览窗口里，而除非你知道要去看，否则没人会看。
• 而这项检测本身是有性能代价的。Sana 的自动可索引性检查"can significantly impact performance, especially when there is a large number of items"，频繁的物料主数据更新"may cause session locks"。Sana 自己给出的对策是关掉这些检查，也就是让你在"ERP 性能问题"和"失去对静默排除商品的发现能力"之间二选一。
• Sana 不认识的订单行会被忽略，而不是被拦下。其中包括总账科目行，而那在 Business Central 里是处理运费和附加费的常规做法。如果站点上的金额必须和 BC 里的金额对得上、且不能靠人工对账，那就在签约前先验证这一点。

这些都不是缺陷，全都写在文档里。只不过它们所在的那一页，和做出采购决定的那一页不是同一页。

有两件事会以"评估阶段看不出、项目中段才冒出来"的方式限制功能。

版本档位。Sana 自己的 Business Central 文档把一串能力标为入门档不可用：B2B 客户注册、代表客户下单（销售代表以客户名义下单）、退货单、一揽子销售订单、潜在客户，以及在商城中显示库存。订单处理策略下的销售代表相关设置只在更高档位提供。完全可能出现的情况是：报给你的套餐，做不了你买这套 B2B 商城本来要做的那件事。所以在商务谈判收口之前，把你的需求清单和档位逐条对一遍。

我们不在这里发布价格或套餐对比，因为 Sana 只公布套餐名称而不公布价目，而那张套餐表是一个由脚本渲染的营销页面，我们无法可靠到足以引用的程度读到它。请向 Sana 索要书面的功能可用性对照表。

订单处理策略。有一个专为多行购物车设计的模式，而它通常正是分销商需要的那个。在该模式下，Sana 不支持销售协议、报价转订单、订单编辑（编辑按钮会消失）、混搭折扣、订单行扩展文本、物料清单展开，以及 Business Central 上的优惠券。

这是一个真正的分岔，而不是一个调优选项。如果你的流程既需要大额购物车，又需要上面清单里的任何一项，平台会逼你二选一，而在需求阶段发现这件事，远比在验收测试阶段发现便宜得多。

"你的 ERP 是唯一事实来源"是当作优点来卖的，它也确实是。但它同时是一条治理约束，而 Sana 在最扎手的那个话题上说得很直白："All taxes must be configured in ERP. Sana Commerce Cloud has no influence on tax calculation as it all done by ERP."Sana 能改的只是税在购物车里怎么呈现，别的都不能。

把这一点推广开，你就得到了 Sana 加 Business Central 项目里最可靠的范围失控预测指标：

同一条线也贯穿了支持。Sana 的服务协议以一个工作日修复严重问题为目标，同时写明："Sana Commerce cannot guarantee a 1 business day fix time for show stoppers caused by 3rd parties (ERP, PSP, etc.)"。在一套以"ERP 直接服务商城"为定义特征的架构上，最可能发生的那一类严重事故，恰恰就是没有保证修复时限的那一类。这不是在批评 SLA，而是一个理由：把 Business Central 合作伙伴的预算和电商预算一起排进去，而不是排在后面。

如果你的 ERP 数据或价格配置本身就是乱的，站点会原样继承，而修复它是一个 Business Central 项目。我们另外写过在换平台之前先清理客户主数据，而在这套架构上，那项工作不是可选的前期准备，它就是商城本身。

这是我们被问得最多的一部分，因为这正是设计需求撞上产品边界的地方。我们是做商城的，所以宁愿一开始就把预期讲清楚，而不是等到设计确认时才发现。

主题编辑器是按令牌工作的：logo、favicon、背景、页眉页脚颜色、元素颜色、字体、占位图。再往前就进入 HTML 注入，而 Sana 不支持它、也声明不为其负责，并且在服务端渲染被关闭时限制更多，而那个开关标准项目并不掌握。商品详情页提供两种布局，选了变体矩阵那一种就会失去"写评价"这个元素。

如果视觉需求只是表层的，主题编辑器确实够用而且很快。如果是结构性的，你面对的就是 SDK 那条路，而上面那节关于分岔口的内容才是要紧的。

关于 headless，Sana 自己的架构说明对你要承担什么异常直接：Sana"will not be able to provide support for your custom storefront (web store)"，它"might be very expensive in terms of money and time"，"your project becomes custom"，而且你"may miss out on the benefits of the standard Sana Commerce Cloud product, including regular updates"。另外也没有可供你在承诺之前评估的、第一方公开的商城 API 参考文档，所以请直接向 Sana 索要，而不要假定它一定在那里。

还有一条来自清点 Sana 公开文档的观察，作为观察提出，而不是作为 Sana 的表述：Sana 为 SAP Business One、Dynamics GP、AX Retail 和 D365 Commerce 都发布了汇总的"限制"页面，也为若干 ERP 发布了"支持版本"页面。而 Business Central 两者都没有。这个缺席，正是这一页值得写出来的大部分理由。

下面每一条都能追溯到 Sana 记录在案的内容。其中大多数换一个套餐、换一个范围或换一个推进顺序就能解决，所以请把它们读作适配条件，而不是不买的理由。我们自己就做 Sana，而我们仍然更希望你现在就发现这些。

• 你需要 B2B 的基本能力，而报给你的是入门档。见上文。入门档包含的东西，和一个 B2B 买家默认认为"这就是产品"的东西之间的落差，是最常见的商务意外。
• 你既需要大额购物车，又需要订单编辑、报价或促销。大额订单模式和那一组功能互斥。
• 你的商业规则在线上必须与 Business Central 表现不同。税是有文档的那个案例，一般规则由此推出。
• 你的商品目录依赖 ERP 装不下的营销内容。丰富描述、图片、视频、营销属性。那意味着架构里要多一套主数据系统，而产品信息管理是一个套餐或附加组件的决定，并非默认包含。我们写过什么时候你才真的需要 PIM。
• 你需要一个由设计驱动的商城。如果需求是结构性的而非表层的，请把 SDK 那条路一起报价，并先读分岔口那一节。
• 你想要 headless 前端。如果这是硬性要求而不是偏好，那这不是应该在其上购买它的平台。
• 你有托管、数据驻留或网络隔离方面的要求。自托管、虚拟私有云和 Sana 的升级工具包，在转向 Sana Commerce Cloud 时都被取消了。
• 你的变更控制无法接受由厂商排期的更新。没有设置能让 AppSource 应用在大版本浪潮中固定不动，成功应用的大版本无法回滚，而演练时机取决于你合作伙伴的许可。
• 你运营的是一个庞大的历史商品目录，物料主数据变动频繁。上文的可索引性检查和会话锁，让这成为一个真实的取舍，而不是一次调优练习。
• 你的销售订单经常带有来自其他附加组件的运费、手续费或附加费行。不受支持的行类型会被忽略而不是被拦下。
• 你在 Business Central 本地版上，并且想自己掌控采购。该扩展只有注册的 Sana 合作伙伴才能下载，靠手工 PowerShell 部署，兼容性信息藏在你无法审计的合作伙伴登录后面。
• 你还在 Sana 9.3 上。没有迁往 Sana Commerce Cloud 的升级工具包，所以那是一次重新实施而不是一次升级。这和你以为自己正在谈的那次续约，是两回事，支持这一侧我们写在Sana 9.3 支持里。