成本在很大程度上取决于您如何将 SFCC 的目录结构与 NetSuite 同步——尤其是在使用 Business Manager 的复杂价格手册和促销活动时,这些内容无法干净地映射到 NetSuite 的定价规则。真正的复杂性来自于 SFCC 的 OCAPI 速率限制(例如库存导入每 10 秒 2 次请求)与高容量订单流的冲突,迫使大多数团队使用 Celigo 的预构建模板,该模板将 FTP 用于批量数据,同时进行选择性的 API 调用。您将面临独特的挑战,源于 SFCC 的多站点架构,其中每个店面可能需要在 NetSuite 中进行不同的仓库映射,而且没有直接的同步路径用于 Einstein 推荐或自定义 cartridges。为处理 SFCC 灵活的目录模型预留额外时间——该模型包含具有无限属性和复杂变体关系的产品,而 NetSuite 更严格的项目结构难以适应这些。

是的。每个 SFCC 站点对应一个 NetSuite 子公司，拥有独立的货币、税务配置和会计科目表。来自各站点的订单会自动路由至正确的子公司。产品目录可在站点间共享，也可保持独立，具体取决于您的 SFCC 实例配置。

这取决于您的 SFCC 配置。OCAPI (Open Commerce API) 是较旧的标准，目前仍被广泛使用。较新的 Commerce API（基于 SCAPI）提供了不同的端点和认证模式。我们将在范围界定阶段确定您的实例支持哪种 API，并据此进行构建。某些实施方案会针对不同的数据类型同时使用两者。

可以,但 B2B Commerce 的数据结构与 B2C 店面不同。账户层级、协商定价和采购订单付款方式都需要特殊处理。该集成将 B2B 买家账户映射到 NetSuite 客户记录,并应用相应的付款条件和定价级别。

大多数项目从启动到上线需要 8 到 12 周。前两到三周用于范围界定：将 SFCC 站点映射到 NetSuite 子公司、定义订单字段映射，以及记录任何影响结账数据的自定义 cartridges。构建和测试运行四到六周，随后是并行运行阶段，在此阶段订单同时通过旧的手动流程和集成流程进行处理。

每当数量发生变化时，库存更新会从 NetSuite 推送到 SFCC - 通常在履行、收货或调整后的几分钟内完成。这不是一个夜间批处理。如果仓库在下午 2 点收到库存，SFCC 会在不久之后反映新的可用性。