成本在很大程度上取決於您如何將 SFCC 的目錄結構與 NetSuite 同步 — 尤其是在使用 Business Manager 的複雜價目表和促銷活動時，這些通常無法乾淨地對應到 NetSuite 的定價規則。真正的複雜性來自於 SFCC 的 OCAPI 速率限制（例如庫存匯入時每 10 秒 2 個請求）與大量訂單流程的衝突，這促使大多數團隊使用 Celigo 的預先建立範本，該範本將 FTP 用於大量資料與選擇性 API 呼叫相結合。您將面臨 SFCC 多站點架構帶來的獨特挑戰，其中每個店面可能需要在 NetSuite 中進行不同的倉庫對應，此外也沒有 Einstein recommendations 或自訂 cartridges 的直接同步路徑。預留額外時間來處理 SFCC 的靈活目錄模型 — 具有無限屬性和複雜變體關係的產品，這對於 NetSuite 更為僵化的項目結構來說很難容納。

只要數量變更，庫存更新就會從 NetSuite 推送到 SFCC - 通常在履行、收貨或調整後的幾分鐘內完成。這不是每晚批次處理。如果倉庫在下午 2 點收到庫存，SFCC 會在之後不久反映新的可用性。

是的。每個 SFCC 網站均對應至一個 NetSuite 子公司，擁有其專屬的幣別、稅務配置及會計科目表。來自各網站的訂單會自動路由至正確的子公司。產品目錄可視 SFCC 實例的配置方式，在網站間共用或保持獨立。

這取決於您的 SFCC 設定。OCAPI (Open Commerce API) 是較舊的標準，至今仍被廣泛使用。較新的 Commerce API（基於 SCAPI）提供不同的端點與驗證模式。我們將在範圍界定階段確認您的實例支援哪種 API，並以此為基礎進行開發。部分實施方案會針對不同的資料類型同時使用這兩者。

可以，但 B2B Commerce 的資料結構與 B2C 店面不同。帳戶層級、協商定價和採購單付款方式都需要特定的處理。整合將 B2B 買家帳戶對應至 NetSuite 客戶記錄，並配置正確的付款條款和定價級別。

大多數專案從啟動到上線需要 8 到 12 週。前兩到三週涵蓋範圍界定：將 SFCC 網站對應至 NetSuite 子公司、定義訂單欄位對應，以及記錄任何影響結帳資料的自訂 cartridges。建置和測試需要四到六週，隨後進行平行運行，其中訂單同時透過舊的手動流程和整合流動。