退货与退款处理数据模板
退货与退款处理数据模板
- 建议收集的数据字段
- 建议跟踪的关键流程步骤
- 数据提取指南
退货与退款处理属性
| 名称 | 说明 | ||
|---|---|---|---|
| 事件时间 EventTime | 表示特定活动或事件发生时间的时间戳。 | ||
| 说明 事件时间即时间戳,记录活动发生的准确日期和时间。事件日志中的每项活动都有对应的时间戳,用于确定事件的先后顺序。 此属性对于所有基于时间的流程挖掘分析都至关重要。它可用于计算活动之间的周期时间、识别等待时间和瓶颈、衡量案例总时长,以及检查是否符合服务级别协议(SLA)。时间戳的准确性会直接影响绩效分析的可靠性。 重要性 此时间戳对于计算周期时间和等待时间等各类时长指标至关重要,而这些指标是绩效分析的基础。 获取途径 对应于各类表中的创建或修改日期字段,例如订单创建时间对应'SalesTable.createdDateTime',仓库日记账对应'WMSJournalTrans.createdDateTime'。 示例 2023-10-26T10:00:00Z2023-10-26T14:30:15Z2023-10-27T09:05:42Z | |||
| 退货案例ID ReturnCaseId | 客户退货与退款案例的唯一标识符,用于关联所有相关活动。 | ||
| 说明 退货案例ID是每个独立退货流程实例的主要标识符。它将特定客户退货或退款申请的所有活动关联起来,从创建退货订单到最终关闭。 在流程分析中,此ID是还原每笔退货端到端旅程的基础。借助它,您可以跟踪完整生命周期、衡量总周期时间,并分析不同案例之间的差异。所有事件、数据和指标都通过此标识符汇总并关联。 重要性 这是连接所有流程步骤的关键案例标识符,可用于追踪和分析每笔退货从开始到结束的全过程。 获取途径 通常是退货物料授权(RMA)编号,或“销售和营销”模块中类型为'Returned Order'的销售订单编号。可在'SalesTable'等表中找到,其中'SalesType'为'Returned Order'。 示例 RMA-001234RMA-001235RMA-001236 | |||
| 活动名称 ActivityName | 退货与退款流程中发生的具体业务事件或任务的名称。 | ||
| 说明 此属性描述退货与退款生命周期中的具体步骤或事件,例如“已创建退货订单”“已收到商品”或“贷项通知单已过账”。每项活动都代表系统记录的一个独立流程节点。 分析这些活动的顺序和频率是流程挖掘的核心。借此可以绘制流程图、识别步骤之间的瓶颈,并发现常见和少见的流程变体。活动集合决定了所分析流程的范围。 重要性 它定义流程步骤,便于呈现流程走向,并识别瓶颈、返工和偏差。 获取途径 这是根据系统事件推导出的概念属性。可通过映射'SalesTable'和'WMSJournalTable'等表中的状态变更,或映射特定事件日志,生成便于用户理解的名称。 示例 已创建退货订单已收到商品已应用处置代码已过账贷项通知单 | |||
| 产品ID ProductId | 退货商品的唯一标识符。 | ||
| 说明 产品ID通常指库存单位(SKU),用于标识客户退回的具体商品。每条退货订单行都关联一个产品ID。 按产品分析退货情况,有助于发现退货率较高的商品。这可能反映出质量控制问题、商品描述不准确或制造缺陷。此类分析有助于优先调查和改进相关产品。 重要性 支持按产品分析退货情况,帮助发现存在质量问题或退货量较大的商品。 获取途径 对应退货订单“SalesLine”表中的“ItemId”字段。 示例 SKU-A-123SKU-B-456SKU-C-789 | |||
| 处置代码 DispositionCode | 用于表示商品检验结果及后续处理方式的代码。 | ||
| 说明 退货商品接受质量检验时会分配处置代码。该代码决定后续步骤,例如'Credit'、'Replace'、'Scrap'或'Return to Customer'。 此属性是退货流程中的关键决策点。按处置代码分析,有助于企业了解退货处理结果、跟踪报废商品的财务影响,并评估不同处理路径(如换货与退款)的效率。 重要性 此代码决定退货案例在检验后进入的处理路径,对于分析流程变体及其业务结果至关重要。 获取途径 这是质量管理模块中的关键字段,与质量订单或检验订单处理相关。 示例 CRDTREPL-DSCRAPRTV | |||
| 负责人 ResponsibleUser | 执行或负责特定活动的用户或员工。 | ||
| 说明 此属性用于识别负责执行某个流程步骤的个人,例如接收商品的仓库员工、质量检验员,或过账贷项通知单的财务文员。 按用户分析流程,有助于了解工作量分配、识别表现突出的员工,并发现潜在的培训需求。还可用于调查由特定个人或团队处理的案例,并确保职责分离得当。 重要性 它可用于分析工作量分配、个人或团队绩效,并发现培训或资源配置方面的机会。 获取途径 可在交易记录的'created by'或'modified by'字段中找到,例如'SalesTable.createdBy',或日记账表中关联的用户ID。 示例 Alice.WBob.JChris.P | |||
| 退货原因代码 ReturnReasonCode | 客户提供的退货原因。 | ||
| 说明 退货原因代码记录客户说明的退货原因,例如“商品有缺陷”“尺码不合适”“与描述不符”或“不再需要”。通常在发起退货时收集此信息。 分析退货原因有助于查明根本原因,帮助企业发现产品质量、商品描述或物流方面的问题。根据这些数据得出的洞察可用于改进产品设计、营销和供应链运营,从而减少后续退货。 重要性 帮助深入了解退货原因,支持根因分析,以降低退货率并提升客户满意度。 获取途径 此信息通常存储在退货订单行级别。可在退货订单的“SalesLine”表中查找原因代码字段。 示例 DEFECTWRONG_ITEMNO_LONGER_WANTEDDAMAGED_IN_TRANSIT | |||
| 退货渠道 ReturnChannel | 客户发起退货所使用的方式或渠道。 | ||
| 说明 此属性表示客户发起退货所使用的渠道,例如“在线门户”“门店”“客户服务电话”或“邮寄”。 按退货渠道细分流程分析,有助于评估各渠道的绩效和效率。企业可以比较不同渠道的周期时间、成本和客户满意度,找出最佳实践以及需要投入或改进的领域。这是“退货渠道使用绩效”仪表板的关键数据。 重要性 便于比较不同退货渠道的绩效,帮助优化效率更高、成本更低的渠道。 获取途径 此信息可能存储在退货订单抬头(“SalesTable”)中,也可能根据创建订单的用户推导得出。可能需要自定义逻辑或专用字段。 示例 网络门户店内自助终端客户支持 | |||
| SLA状态 SlaStatus | 表示案例是否在服务级别协议规定的时限内解决。 | ||
| 说明 此计算属性以简单状态表示SLA达成情况,通常为“按时”或“逾期”。系统将最后一项活动(例如“退货订单已关闭”)的时间戳与“RefundSlaTargetDate”进行比较后得出结果。 此属性简化了“退款处理SLA绩效”等仪表板中的绩效报告。用户无需自行比较日期,即可直接查看清晰易懂的状态,快速筛选和汇总数据,计算整体“解决时限SLA达成率”。 重要性 直观显示SLA达成情况,便于筛选逾期案例并分析延误的根本原因。 获取途径 这是一个推导属性,通过将最终处理活动的时间戳与“RefundSlaTargetDate”属性进行比较计算得出。 示例 按时逾期 | |||
| 仓库ID WarehouseId | 接收退货商品的仓库或地点标识符。 | ||
| 说明 此属性用于标识处理退货商品的具体仓库或退货中心。不同地点的流程、资源或绩效水平可能各不相同。 按仓库分析流程,可对比不同地点的绩效,找出处理退货效率最高的设施,发现区域瓶颈,并为物流网络中的资源分配和流程标准化提供依据。 重要性 支持比较不同仓库或退货中心的绩效,帮助发现区域瓶颈和最佳实践。 获取途径 此信息存储在库存相关交易的“InventLocationId”字段中,例如到货日记账(“WMSJournalTable”)或“SalesLine”。 示例 WH-EASTWH-WESTCENTRAL-DC | |||
| 实际退款金额 ActualRefundAmount | 实际退还给客户的最终金额。 | ||
| 说明 此属性表示最终确认的退款金额,在贷项通知单创建并过账时记录。 这是财务分析的关键属性,直接用于“退款金额差异分析”仪表板和“退款金额准确率”KPI。分析这些数据有助于了解退货造成的财务影响,以及流程中的各项调整。 重要性 此金额反映退货造成的实际财务影响,对于计算退款准确率和了解财务结果至关重要。 获取途径 此金额可在已过账的贷项通知单交易明细中查找,与贷项通知单对应的“CustTrans”和“CustInvoiceJour”表相关。 示例 99.99135.000.00 | |||
| 客户ID CustomerId | 发起退货的客户的唯一标识符。 | ||
| 说明 客户ID是与退货关联的客户账户的唯一标识符,可将退货交易关联到CRM或客户数据库中的具体客户。 按客户分析退货情况,可以发现退货频率异常高的客户,这可能意味着存在欺诈行为或长期不满。还可用于客户细分,例如为高价值客户提供优质退货服务。 重要性 将退货流程关联到具体客户,支持客户级分析,并帮助识别退货模式或潜在欺诈。 获取途径 这是退货订单“SalesTable”中的“CustAccount”字段。 示例 CUST-00045CUST-00192CUST-00315 | |||
| 数据最近更新时间 LastDataUpdate | 表示流程数据最近一次刷新的时间戳。 | ||
| 说明 此属性记录数据最近一次从源系统提取并更新至流程挖掘工具的日期和时间,可用于了解所分析数据的新鲜度。 了解数据最近更新时间,有助于判断分析结果的时效性。用户可以据此正确解读仪表板和KPI,了解查看的是实时数据,还是某个时间点的数据快照。这对于运营监控尤为重要。 重要性 用于标明数据的新鲜度,让分析人员了解流程洞察反映的是哪个时间点的情况。 获取途径 这是在数据导入管道中生成并存储的元数据属性,通常表示ETL作业完成时的时间戳。 示例 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| 是否符合政策 IsPolicyAdherent | 用于标记退货审批是否符合既定退货政策。 | ||
| 说明 这是一个计算得出的布尔属性,用于表示退货是否满足公司退货政策中的所有条件。判断依据可能包括退货期限、商品状况或退货原因等。 此属性直接支持“退货审批合规概览”仪表板和“合规退货审批率”KPI。企业可据此量化政策执行情况,识别例外审批案例,并分析例外审批的原因和频率。这对于治理和成本控制至关重要。 重要性 直接衡量业务规则的执行情况,帮助识别并减少不符合规定的退货审批,避免由此造成收入损失。 获取途径 这是一个推导属性,需要将退货相关属性(例如退货日期与购买日期、退货原因)与预定义业务规则进行比较来计算。 示例 truefalse | |||
| 源系统 SourceSystem | 提取事件数据的业务信息系统。 | ||
| 说明 此属性用于标识数据来源的业务信息系统。在此场景中,主要来源是'Microsoft Dynamics 365'。 在大型企业中,一个流程可能涉及多个系统。为每个事件注明源系统,对于数据治理、排查数据提取问题以及了解流程涉及的技术环境都至关重要。它还能确认所分析数据的来源。 重要性 它提供有关数据来源的重要背景信息,有助于开展数据治理和验证,并了解流程涉及的系统环境。 获取途径 这通常是在数据提取、转换和加载(ETL)过程中添加的静态值,用于标记数据集的来源。 示例 Microsoft Dynamics 365 F&OD365-PROD | |||
| 申请退款金额 RequestedRefundAmount | 客户申请退款的总金额。 | ||
| 说明 此属性表示退货流程开始时申请或预计的初始退款金额,通常根据退回商品的原始购买价格确定。 该金额是“退款金额差异分析”的基准。将申请金额与实际退款金额进行比较,企业可以发现补货费、损坏商品部分退款或其他调整造成的差异,从而监控财务准确性和政策执行情况。 重要性 作为基准与实际退款金额进行比较,以衡量财务准确性。 获取途径 通常为退货商品对应的原始销售订单行金额或总金额,可在“SalesLine.LineAmount”中查找。 示例 99.99150.0024.50 | |||
| 结束时间 EndTime | 表示特定活动完成时间的时间戳。 | ||
| 说明 结束时间是活动完成时的时间戳。开始时间标记活动的起点,结束时间标记活动的终点,两者可用于计算该任务的处理时间。 此属性对于详细的绩效分析至关重要,尤其适用于“商品检验”等持续时间可衡量的任务。通过比较开始时间和结束时间,分析人员可以准确衡量任务的实际处理时间,并将其与任务之间的等待时间区分开来。这有助于定位具体活动内部的低效环节,而不仅是活动之间的问题。 重要性 它可用于计算各项活动的实际处理时间,帮助区分等待时间与实际工作时间。 获取途径 此值通常需要推导。例如,可以使用结束某项活动的状态变更时间'modifiedDateTime',也可以使用后续活动的开始时间。 示例 2023-10-26T10:15:00Z2023-10-26T14:45:20Z2023-10-27T09:55:12Z | |||
| 贷项通知单ID CreditNoteId | 退款所创建贷项通知单的唯一标识符。 | ||
| 说明 处理退款时,系统会生成称为贷项通知单或贷项凭证的财务单据。此属性存储该单据的唯一ID。 此ID可将退货运营流程直接关联到会计系统中的财务记录,便于审计和深入调查财务差异。分析人员可以据此追踪退货案例,直至结算该案例的具体财务交易。 重要性 将退货运营流程关联到对应的财务交易,对于审计和财务对账至关重要。 获取途径 贷项通知单编号通常位于“CustInvoiceJour”表的“InvoiceId”字段中,交易类型为“Credit note”。此编号可关联回退货订单。 示例 CN-10056CN-10057CN-10058 | |||
| 退款SLA目标日期 RefundSlaTargetDate | 退货和退款案例应完成处理的目标日期。 | ||
| 说明 此属性定义了解决退货案例的服务级别协议(SLA)期限,即客户应获得最终处理结果的日期,例如退款已过账或替换商品已发货。 此目标日期对于监控服务承诺的履行情况至关重要,可用于计算“解决时限SLA达成率”KPI,并支持“退款处理SLA绩效”仪表板。将目标日期与流程实际完成日期进行比较,企业可以发现SLA超时情况,并主动跟进积压案例。 重要性 作为衡量流程绩效的基准,可用于跟踪SLA达成情况并识别逾期案例。 获取途径 这可能不是标准字段。通常根据退货创建日期加上预设的SLA期限(例如14天)计算,也可能存储在自定义字段中。 示例 2023-11-10T23:59:59Z2023-11-15T23:59:59Z | |||
| 退货类型 ReturnType | 根据预期处理结果对退货进行分类,例如退款或换货。 | ||
| 说明 此属性根据客户希望获得或企业提供的处理方式对退货案例进行分类。常见类型包括退款、换货或维修。 此分类有助于分析不同的流程路径。退款流程与替换商品发货流程有明显差异。按退货类型细分,可以更准确地分析各类处理路径的周期时间和瓶颈。 重要性 支持按预期处理结果细分分析,因为退款和换货流程的步骤及周期时间各不相同。 获取途径 这可能是退货订单抬头中的自定义字段,也可能根据处置代码或后续交易(例如创建替换商品销售订单)推导得出。 示例 退款换货商店余额 | |||
| 退货订单状态 ReturnOrderStatus | 事件发生时退货订单的整体状态。 | ||
| 说明 此属性表示退货订单抬头的当前状态,例如“未结”“已开票”或“已取消”,概括显示案例所处的生命周期阶段。 活动记录了具体的流程步骤,而整体状态则便于筛选和细分案例。例如,分析人员可以只查看“未结”案例以了解当前工作量,也可以分析最终“已取消”案例的流程路径。 重要性 概括显示案例状态,便于筛选案例并了解取消等处理结果。 获取途径 此信息位于“SalesTable”的“SalesStatus”或“DocumentStatus”字段中。 示例 未结订单已交付已开票已取消 | |||
退货与退款处理活动
| 活动 | 说明 | ||
|---|---|---|---|
| 已关闭退货订单 | 退货订单已到达最终状态,表示所有实物和财务交易均已完成。通常在贷项通知单过账或替换商品寄出后完成。 | ||
| 重要性 这是成功完成退货流程的主要结束事件。从创建到此节点的时长即为案例总周期时间。 获取途径 可根据ReturnOrder状态字段变为最终值推断,例如'Invoiced'或'Closed'。这表示无需进一步处理。 采集 SalesTable.Status或SalesTable.DocumentStatus字段变更为最终状态。 事件类型 inferred | |||
| 已创建退货订单 | 此活动标志着退货流程启动,即在系统中创建退货物料授权(RMA)或退货订单。Dynamics 365中新建ReturnOrder记录时会记录这一明确事件。 | ||
| 重要性 这是整个退货流程的主要开始事件。分析此活动与其他活动之间的时间,可了解整体流程周期,并帮助识别早期瓶颈。 获取途径 此事件根据ReturnOrder表头的创建时间戳记录。通常可在SalesTable中找到,其中SalesType为'Returned Order'。 采集 创建SalesType = 'Returned Order'的SalesTable记录时触发的事件。 事件类型 explicit | |||
| 已应用处置代码 | 此活动表示检验完成,并已决定如何处理退货商品。系统会为退货订单行分配处置代码,例如'Credit'、'Scrap'或'Replace'。 | ||
| 重要性 这是决定后续流程走向的关键节点,后续可能是退款、换货或拒绝退货。此处延误会显著影响整体处理时间。 获取途径 退货订单行的库存交易或相关日记账中填入DispositionCode字段时,会记录此事件。 采集 为退货订单行设置DispositionCode时触发的更新事件。 事件类型 explicit | |||
| 已收到商品 | 表示退货商品已实际送达仓库或指定退货中心。与退货订单关联的到货日记账过账时会记录此事件。 | ||
| 重要性 这是将流程从客户操作转入内部处理的关键节点,也是计算检验和处置等内部处理时间的起点。 获取途径 与ReturnOrder行关联的WMS Journal或Item Arrival Journal的过账时间戳。此操作会将库存交易更新为'Registered'或'Received'状态。 采集 与退货订单行关联的Item Arrival Journal过账事件。 事件类型 explicit | |||
| 已过账贷项通知单 | 贷项通知单正式过账至财务分类账,客户即可使用相应贷项。从公司角度看,这标志着退款操作完成。 | ||
| 重要性 这是重要的财务节点,确认退款已在系统中处理。它通常是衡量退款SLA达成情况的关键活动。 获取途径 退货订单发票日记账的过账时间戳,用于完成贷项通知单。退货订单状态会变为'Invoiced'。 采集 过账退货订单的发票日记账。 事件类型 explicit | |||
| 已创建到货日记账 | 此活动表示仓库已预期退货商品即将到达。系统创建到货日记账,为实物收货做好准备。 | ||
| 重要性 此步骤将物流准备与实际收货区分开来,有助于分析仓库准备情况并规划退货入库。 获取途径 在WMSJournalTable中创建JournalType为'Arrival'的记录。该日记账与退货订单行关联。 采集 退货对应的WMSJournalTable记录创建时间戳。 事件类型 explicit | |||
| 已创建换货订单 | 系统创建新的销售订单,向客户寄送替换商品。处置操作为'Replace and Credit'或'Replace and Scrap'时会发生此活动。 | ||
| 重要性 此活动启动换货流程分支。将此路径与退款路径分开跟踪,对于了解换货的复杂程度和成本至关重要。 获取途径 为替换商品创建新的SalesTable记录,通常由系统自动生成并与原退货订单关联。 采集 通过处置操作创建与退货订单关联的新销售订单。 事件类型 explicit | |||
| 已创建贷项通知单 | 处置结果为'Credit'时,系统会生成贷项通知单,授权向客户退款。这标志着流程进入财务结算阶段。 | ||
| 重要性 此活动标志着财务退款获批。从处置到创建贷项通知单之间的时间,可反映启动退款时的行政处理延误。 获取途径 可根据新建的负金额SalesTable记录推断此事件,该记录与原退货订单关联;也可通过运行'Create credit note'批处理作业识别。 采集 创建贷项通知单,通常通过过账退货订单发票完成。 事件类型 explicit | |||
| 已取消退货订单 | 退货订单在完成前被取消,可能是应客户要求取消,也可能是商品从未退回。 | ||
| 重要性 这代表流程以另一种未成功的方式结束。分析退货取消原因,有助于了解客户行为或流程故障。 获取途径 可根据ReturnOrder状态字段变为'Cancelled'推断。与成功关闭的订单相比,这是另一种明确的最终状态。 采集 SalesTable.Status字段变更为'Cancelled'。 事件类型 inferred | |||
| 已寄出替换商品 | 替换商品的装箱单已过账,表示商品已寄给客户。这标志着换货履约流程完成。 | ||
| 重要性 这是换货流程分支中的关键节点,表示公司已履行对客户的义务。跟踪换货周期时间时,此节点尤为重要。 获取途径 替换商品销售订单的装箱单日记账过账日期。此操作会将订单状态更新为'Delivered'。 采集 过账替换商品销售订单的装箱单。 事件类型 explicit | |||
| 已生成质量订单 | 系统创建正式质量订单,表示退货商品需要经过结构化检验。对于需要详细测试或按质量标准检查的退货,这种情况很常见。 | ||
| 重要性 此活动表示正式检验流程开始。跟踪从此时起的耗时,有助于衡量质量保证工作流的效率和持续时间。 获取途径 与退货订单关联的InventQualityOrderTable记录创建时间戳。 采集 创建InventQualityOrderTable记录。 事件类型 explicit | |||
| 已确认退货订单 | 表示系统正式确认退货订单,通常会触发后续逻辑。通常通过ReturnOrder表头上的明确操作或状态变更记录。 | ||
| 重要性 确认是物流环节开始前的关键步骤。创建到确认之间的延误可能表明存在行政处理积压或系统相关积压。 获取途径 可通过退货订单的'Confirmation'日记账过账记录,或SalesTable中DocumentStatus字段的变更来识别。 采集 对退货订单执行'Confirm sales order'功能。 事件类型 explicit | |||
数据提取指南
步骤
- **前提条件:在Azure Active Directory中注册应用程序。**连接Dynamics 365 API前,您必须在Azure AD环境中注册应用程序。授予该应用程序访问Dynamics 365 Finance & Operations的委派权限,例如
Financials.ReadWrite.All或自定义权限。 - **在Dynamics 365中配置应用程序ID。**在Dynamics 365中,依次进入“系统管理”>“设置”>“Azure Active Directory应用程序”。添加Azure AD应用注册中的应用程序(客户端)ID,并将其关联到具有必要安全角色、可读取所需数据实体的用户帐户。
- **获取OAuth 2.0访问令牌。**使用PowerShell或Python等编写脚本,通过Microsoft身份验证平台端点进行身份验证。使用应用程序凭据(客户端ID和密钥)为Dynamics 365资源URL请求访问令牌。
- **查找Dynamics 365环境URL。**找到Dynamics 365环境的基础URL。Web API端点通常如下所示:
https://[YourD365FinanceAndOpsURL].dynamics.com/data。 - **构建并执行OData API请求。**针对12项必需活动分别构建OData GET请求URL。使用
$select仅获取所需列,并通过$filter指定日期范围和状态条件。每个请求的授权标头中都必须包含第3步获取的身份验证令牌,并将其设为Bearer令牌。 - **编写提取脚本。**创建脚本,依次处理OData请求列表。脚本应负责身份验证、执行每个GET请求并保存返回的JSON数据。请留意API限制,必要时加入暂停逻辑。
- **处理API分页。**Dynamics 365会对大量结果分页。脚本必须检查响应中是否包含
@odata.nextLink属性。如果存在,则向该URL发起后续请求以获取下一页数据,直到不再返回nextLink。 - **转换并合并数据。**处理12次API调用各自返回的JSON响应。针对每项活动,创建包含
ReturnCaseId、ActivityName、EventTime及其他属性的标准化记录。例如,对于“退货订单已创建”事件,将ReturnOrderNumber映射到ReturnCaseId,将ActivityName设为“退货订单已创建”,并将createdDateTime映射到EventTime。将所有调用转换后的记录合并为一个列表或表格。 - **清理并统一时间戳格式。**确保所有
EventTime值格式一致,建议使用UTC格式,例如YYYY-MM-DDTHH:MM:SSZ。根据需要处理缺失或无效的时间戳。 - **导出最终事件日志。**收集并转换所有数据,形成统一数据集后,将其导出为CSV文件。确保列标题符合ProcessMind的要求,例如:
ReturnCaseId、ActivityName、EventTime、ResponsibleUser、DispositionCode等。现在即可上传该文件。
配置
- API端点URL:Dynamics 365 Finance & Operations实例的基础URL,格式为
https://[YourEnvironmentName].dynamics.com/data。 - Azure AD应用程序:必须在Azure AD中注册应用程序,并配置客户端ID和密钥。该应用程序需要具备访问Dynamics 365数据实体的API权限。
- 日期范围筛选:每次API调用都必须使用OData的
$filter参数,根据相关日期字段(如createdDateTime或modifiedDateTime)筛选日期范围。通常可先提取最近3到6个月的数据,以控制数据量。 - 公司筛选:如需提取特定法人实体的数据,请添加
cross-company=true查询参数,再通过$filter筛选dataAreaId字段。例如:?cross-company=true&$filter=dataAreaId eq '[YourCompanyCode]'。 - 分页设置:在请求中使用
Prefer: odata.maxpagesize=[value]标头,控制每页返回的记录数。常用值为1000到5000,有助于避免大型实体的API请求超时。 - API限流:请留意Dynamics 365 API的服务保护限制。提取脚本应能处理
429 (Too Many Requests)响应,通常可采用指数退避或暂停后重试机制。
查询示例 graphql
/*
This is a conceptual guide representing multiple, distinct OData API calls.
You will need a script (e.g., Python, PowerShell) to execute these calls sequentially,
authenticate with a bearer token, handle pagination, and union the results into a single file.
Replace [YourD365URL], [StartDate], [EndDate], and [YourCompanyCode] with your specific values.
*/
// Base URL for all requests
const string BaseUrl = "https://[YourD365URL].dynamics.com/data";
const string CompanyFilter = "?cross-company=true&$filter=dataAreaId eq '[YourCompanyCode]' and ";
const string DateFilterCreated = "createdDateTime ge [StartDate]T00:00:00Z and createdDateTime le [EndDate]T23:59:59Z";
const string DateFilterModified = "modifiedDateTime ge [StartDate]T00:00:00Z and modifiedDateTime le [EndDate]T23:59:59Z";
// 1. Return Order Created
GET {BaseUrl}/ReturnOrderHeaders{CompanyFilter}{DateFilterCreated}&$select=ReturnOrderNumber,createdDateTime,createdby,ReturnReasonCodeId
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Return Order Created' -> ActivityName, createdDateTime -> EventTime, createdby -> ResponsibleUser, ReturnReasonCodeId -> ReturnReasonCode
// 2. Return Order Confirmed
// This often updates the header status. We look for a modification time on confirmed orders.
GET {BaseUrl}/ReturnOrderHeaders{CompanyFilter}ReturnOrderStatus eq 'Confirmed' and {DateFilterModified}&$select=ReturnOrderNumber,modifiedDateTime,modifiedby,ReturnReasonCodeId
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Return Order Confirmed' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser
// 3. Arrival Journal Created
GET {BaseUrl}/WarehouseArrivalJournalHeaders{CompanyFilter}{DateFilterCreated}&$expand=WarehouseArrivalJournalLines($select=InventTransactionId)&$select=JournalNumber,createdDateTime,createdby
// Note: This requires post-processing to link JournalNumber to a ReturnCaseId via InventTransactionId.
// Mapping: Link via InventTrans -> ReturnCaseId, 'Arrival Journal Created' -> ActivityName, createdDateTime -> EventTime, createdby -> ResponsibleUser
// 4. Item Received (Arrival Journal Posted)
GET {BaseUrl}/WarehouseArrivalJournalHeaders{CompanyFilter}JournalPosted eq 'Yes' and {DateFilterModified}&$expand=WarehouseArrivalJournalLines($select=InventTransactionId)&$select=JournalNumber,modifiedDateTime,modifiedby
// Mapping: Link via InventTrans -> ReturnCaseId, 'Item Received' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser
// 5. Quality Order Generated
GET {BaseUrl}/InventQualityOrders{CompanyFilter}{DateFilterCreated}&$select=QualityOrderId,InventTransId,createdDateTime,CreatedByUserId,ItemId
// Mapping: Link via InventTransId -> ReturnCaseId, 'Quality Order Generated' -> ActivityName, createdDateTime -> EventTime, CreatedByUserId -> ResponsibleUser, ItemId -> ProductId
// 6. Disposition Code Applied
// This is a status change on the return line.
GET {BaseUrl}/ReturnOrderLines{CompanyFilter}ReturnDispositionCodeId ne '' and {DateFilterModified}&$select=ReturnOrderNumber,modifiedDateTime,modifiedby,ReturnDispositionCodeId,ItemId
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Disposition Code Applied' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser, ReturnDispositionCodeId -> DispositionCode, ItemId -> ProductId
// 7. Credit Note Created
// Look for sales orders with type 'Returned Order' that are not yet invoiced.
GET {BaseUrl}/SalesOrderHeadersV2{CompanyFilter}SalesOrderProcessingStatus eq 'Open' and SalesOrderType eq 'ReturnedOrder' and {DateFilterCreated}&$select=SalesOrderNumber,createdDateTime,createdby
// Mapping: SalesOrderNumber -> ReturnCaseId, 'Credit Note Created' -> ActivityName, createdDateTime -> EventTime, createdby -> ResponsibleUser
// 8. Credit Note Posted
// Look for posted invoice journals linked to a return order.
GET {BaseUrl}/SalesInvoiceJournalHeaders{CompanyFilter}SalesOrderType eq 'ReturnedOrder' and {DateFilterCreated}&$select=SalesOrderNumber,InvoiceDate,createdby
// Mapping: SalesOrderNumber -> ReturnCaseId, 'Credit Note Posted' -> ActivityName, InvoiceDate -> EventTime, createdby -> ResponsibleUser
// 9. Replacement Order Created
// Disposition code on the return line triggers a replacement order.
GET {BaseUrl}/SalesOrderHeadersV2{CompanyFilter}SalesOrderOriginType eq 'ReturnOrder' and {DateFilterCreated}&$select=SalesOrderNumber,createdDateTime,createdby,ReturnOrderNumber
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Replacement Order Created' -> ActivityName, createdDateTime -> EventTime, createdby -> ResponsibleUser
// 10. Replacement Item Shipped
// Check for posted packing slips related to the replacement sales order.
GET {BaseUrl}/SalesPackingSlipJournals{CompanyFilter}{DateFilterCreated}&$select=SalesOrderNumber,DeliveryDate,createdby
// Note: This requires linking SalesOrderNumber back to the original ReturnOrderNumber for the ReturnCaseId.
// Mapping: Link SalesOrderNumber -> ReturnCaseId, 'Replacement Item Shipped' -> ActivityName, DeliveryDate -> EventTime, createdby -> ResponsibleUser
// 11. Return Order Closed
GET {BaseUrl}/ReturnOrderHeaders{CompanyFilter}ReturnOrderStatus eq 'Closed' and {DateFilterModified}&$select=ReturnOrderNumber,modifiedDateTime,modifiedby
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Return Order Closed' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser
// 12. Return Order Cancelled
GET {BaseUrl}/ReturnOrderHeaders{CompanyFilter}ReturnOrderStatus eq 'Canceled' and {DateFilterModified}&$select=ReturnOrderNumber,modifiedDateTime,modifiedby
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Return Order Cancelled' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser 步骤
- 启用TDS端点:确保已为Dynamics 365 Dataverse环境启用表格数据流(TDS)端点。系统管理员可在Power Platform管理中心的“环境”>“设置”>“功能”中启用该端点。
- 查找环境URL:找到环境URL,通常格式为
yourorg.crm.dynamics.com。TDS端点服务器名称是在此URL后加端口号5558,例如yourorg.crm.dynamics.com,5558。 - 使用SQL客户端连接:使用支持TDS的SQL客户端,例如SQL Server Management Studio(SSMS)或Azure Data Studio。
- 进行身份验证:使用具有相应权限的Azure Active Directory帐户连接服务器。该帐户通常需要在Dataverse环境中拥有系统管理员或系统自定义者角色。
- 准备查询:将本文档
query部分提供的完整SQL查询复制到SQL客户端的新查询窗口中。 - 设置参数:找到查询中的占位符,将
'{StartDate}'和'{EndDate}'替换为所需的提取日期范围,例如'2023-01-01'和'2023-12-31'。同时,根据您的Dynamics 365配置更新状态代码或处理结果代码等占位值。 - 执行查询:在Dataverse数据库中运行修改后的查询。执行时间取决于数据量和所选日期范围。
- 检查结果:查询完成后,检查返回的数据集是否包含预期列:
ReturnCaseId、ActivityName、EventTime及建议的属性。 - 导出事件日志:将查询结果导出为CSV文件。大多数SQL客户端都提供内置功能,可将结果直接保存到文件。请确保文件采用UTF-8编码。
- 上传到ProcessMind:导出的CSV文件现已准备就绪,可作为新的事件日志上传到ProcessMind进行流程挖掘分析。
配置
- 前提条件:您必须拥有至少可读取相关Dataverse表(如SalesTable、SalesLine、CustInvoiceJour)的用户帐户。权限通常通过系统管理员等安全角色管理,也可使用具有足够表权限的自定义角色。
- TDS端点:必须为环境启用Dataverse TDS端点。此功能支持直接对Dataverse数据库执行只读SQL查询。
- 日期范围:查询中包含
'{StartDate}'和'{EndDate}'占位符。初次分析建议使用3到6个月的日期范围,以获得有代表性的数据集,同时避免影响性能。 - 公司筛选:按当前写法,查询会涵盖用户有权访问的所有法人实体(公司)。如需分析单个公司,请取消注释,并在每个
UNION ALL语句部分添加按DATAAREAID字段筛选的WHERE子句,例如AND st.DATAAREAID = '[YourCompanyID]'。 - 自定义逻辑占位符:查询包含
[YourReplaceCode1]等处理结果代码占位符,以及有关关联替换订单的说明。您必须根据具体业务流程和Dynamics 365设置进行配置。 - 性能:通过TDS端点直接查询大型数据集可能较慢。该连接针对分析查询进行了优化,但涉及数百万行的复杂联接可能会超时。建议使用严格的日期筛选条件。
查询示例 sql
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Return Order Created' AS ActivityName,
st.CREATEDDATETIME AS EventTime,
st.CREATEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Return Order Confirmed' AS ActivityName,
st.MODIFIEDDATETIME AS EventTime,
st.MODIFIEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.DOCUMENTSTATUS = 1 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Arrival Journal Created' AS ActivityName,
wjt.CREATEDDATETIME AS EventTime,
wjt.CREATEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN WMSJOURNALTABLE wjt ON st.SALESID = wjt.ORDERID AND st.DATAAREAID = wjt.DATAAREAID
WHERE st.SALESTYPE = 3 AND wjt.JOURNALTYPE = 4 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Item Received' AS ActivityName,
wjt.POSTEDDATETIME AS EventTime,
wjt.POSTEDUSERID AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN WMSJOURNALTABLE wjt ON st.SALESID = wjt.ORDERID AND st.DATAAREAID = wjt.DATAAREAID
WHERE st.SALESTYPE = 3 AND wjt.JOURNALTYPE = 4 AND wjt.POSTEDDATETIME IS NOT NULL AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Quality Order Generated' AS ActivityName,
iqot.CREATEDDATETIME AS EventTime,
iqot.CREATEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
iqot.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN INVENTQUALITYORDERTABLE iqot ON sl.INVENTTRANSID = iqot.INVENTTRANSID AND sl.DATAAREAID = iqot.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Disposition Code Applied' AS ActivityName,
iqot.VALIDATEDDATETIME AS EventTime,
iqot.VALIDATEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
iqot.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN INVENTQUALITYORDERTABLE iqot ON sl.INVENTTRANSID = iqot.INVENTTRANSID AND sl.DATAAREAID = iqot.DATAAREAID
WHERE st.SALESTYPE = 3 AND iqot.VALIDATEDDATETIME IS NOT NULL AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Credit Note Created' AS ActivityName,
st.MODIFIEDDATETIME AS EventTime,
st.MODIFIEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.SALESSTATUS = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Credit Note Posted' AS ActivityName,
cij.CREATEDDATETIME AS EventTime,
cij.CREATEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN CUSTINVOICEJOUR cij ON st.SALESID = cij.SALESID AND st.DATAAREAID = cij.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
ro.RETURNITEMNUM AS ReturnCaseId,
'Replacement Order Created' AS ActivityName,
replacement_so.CREATEDDATETIME AS EventTime,
replacement_so.CREATEDBY AS ResponsibleUser,
NULL AS DispositionCode,
NULL AS ReturnReasonCode,
replacement_so.SALESORIGINID AS ReturnChannel,
replacement_sl.ITEMID AS ProductId
FROM SALESTABLE ro
JOIN SALESLINE rol ON ro.SALESID = rol.SALESID AND ro.DATAAREAID = rol.DATAAREAID
JOIN SALESTABLE replacement_so ON ro.CUSTACCOUNT = replacement_so.CUSTACCOUNT AND ro.DATAAREAID = replacement_so.DATAAREAID
JOIN SALESLINE replacement_sl ON replacement_so.SALESID = replacement_sl.SALESID AND replacement_so.DATAAREAID = replacement_sl.DATAAREAID
WHERE ro.SALESTYPE = 3
AND rol.RETURNDISPOSITIONCODEID IN ('[YourReplaceCode1]', '[YourReplaceCode2]')
AND replacement_so.SALESTYPE = 1
AND replacement_so.CREATEDDATETIME > ro.CREATEDDATETIME
-- The join above is a basic example and must be replaced with your system's specific logic for linking returns to replacements.
AND ro.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
ro.RETURNITEMNUM AS ReturnCaseId,
'Replacement Item Shipped' AS ActivityName,
cpsj.CREATEDDATETIME AS EventTime,
cpsj.CREATEDBY AS ResponsibleUser,
NULL AS DispositionCode,
NULL AS ReturnReasonCode,
replacement_so.SALESORIGINID AS ReturnChannel,
cpsl.ITEMID AS ProductId
FROM SALESTABLE ro
JOIN SALESLINE rol ON ro.SALESID = rol.SALESID AND ro.DATAAREAID = rol.DATAAREAID
JOIN SALESTABLE replacement_so ON ro.CUSTACCOUNT = replacement_so.CUSTACCOUNT AND ro.DATAAREAID = replacement_so.DATAAREAID
JOIN CUSTPACKINGSLIPJOUR cpsj ON replacement_so.SALESID = cpsj.SALESID AND replacement_so.DATAAREAID = cpsj.DATAAREAID
JOIN CUSTPACKINGSLIPTRANS cpsl ON cpsj.PACKINGSLIPID = cpsl.PACKINGSLIPID AND cpsj.SALESID = cpsl.SALESID AND cpsj.DATAAREAID = cpsl.DATAAREAID
WHERE ro.SALESTYPE = 3
AND rol.RETURNDISPOSITIONCODEID IN ('[YourReplaceCode1]', '[YourReplaceCode2]')
AND replacement_so.SALESTYPE = 1
AND replacement_so.CREATEDDATETIME > ro.CREATEDDATETIME
-- The join above is a basic example and must be replaced with your system's specific logic for linking returns to replacements.
AND ro.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Return Order Closed' AS ActivityName,
st.MODIFIEDDATETIME AS EventTime,
st.MODIFIEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.SALESSTATUS = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Return Order Cancelled' AS ActivityName,
st.MODIFIEDDATETIME AS EventTime,
st.MODIFIEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.SALESSTATUS = 4 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'; 告别退货与退款延误:立即优化流程
缩短30%的周期时间,提升客户满意度。
无需信用卡,几分钟即可完成设置。