数据分发

  • 8 分钟

Commerce 中的数据分发基于 Commerce Data Exchange，后者可在 Commerce Headquarters 和不同渠道之间传输数据。

存储渠道数据的数据库与 Commerce 数据库不同。 渠道数据库中仅存储进行交易所需的数据。 例如，在 Headquarters 中设置主数据，然后分发到各个渠道；在交易的另一端，在 Store Commerce 或在线商店中创建交易数据，然后上传到 Headquarters。

有助于在源和目标系统之间分发数据的不同组件包括：

  • 异步服务 – 对源 (Headquarters) 数据打包即为准备数据分发的流程。 本流程与将数据发送到不同渠道并将更改应用于其数据库的流程分开进行。 异步服务可使用 Commerce 计划程序，通过上传和下载作业来计划数据分发。

    • 针对 Commerce 数据库的 Microsoft SQL Server 更改跟踪 – 用于确定应发送到渠道的数据更改。

    • Commerce 计划程序 – 一种机制，用于通过已计划的批处理作业在各个位置之间交换数据。

  • 实时服务 – 提供渠道与 Dynamics 365 Commerce 之间的实时通信，适用于必须实时提供数据的应用场景，例如库存查找、发放和兑现礼品卡、创建和更新客户记录等。

跨零售渠道实现付款管理的一致性

零售商希望在所有平台上为客户提供同等质量的服务，同时确保后台员工在处理零售订单方面拥有娴熟的经验。 任何零售订单处理界面都必须能够以一致的方式查看、修改和处理与销售订单相关的付款交易。

Store Commerce 和电子商务订单付款的后端管理使用 MCRCustPaym* 表。 通过使用一致的方式管理零售订单付款数据，可以为呼叫中心用户实现真正的全渠道零售订单付款管理。

存档信用卡交易记录数据

信用卡响应数据可能会占用数据库中的大量空间。 由于这类数据主要用于执行关联退款，因此在交易的业务退款政策到期后，数据的有用性将显著降低。 当根据业务政策，信用卡数据不能再用于关联退款时，存档作业会自动存档该数据，从而确保仅保留日常运营的关键数据。

存档作业可以配置为存档超过一定年限的信用卡 XML 授权响应数据。 当信用卡数据达到指定年限时，该作业会将其压缩为 .zip 文件并通过文档管理导出。 数据在导出后无法以编程方式还原。 由于需要导出的授权数据是用于关联退款，因此只有早于公司退货政策中规定的关联退款期限的数据才应导出。

显示超过一定年限的信用卡数据的存档过程的示意图。

重要提示

已存档的数据无法轻松还原。 因此，不应存档涉及关联退款的交易记录。 例如，如果商家的退货政策允许退回两年内的交易并退款到同一信用卡，则作业的最短交易时间（天）字段应设置为 730 天（两年）。 在这种情况下，如果交易在 730 天后被退回，则无法找到进行关联退款所需的 XML。 因此，客户必须通过独立退款 向信用卡或其他付款方式（例如贷记单或礼品卡）退款。

有关如何设置可存档作业的详细信息，请参阅：存档信用卡交易记录数据