> 持续流程改进 > 从订单到收款计费与开票 > Microsoft Dynamics 365 > 数据模板

您的 O2C 计费与开票数据模板

Microsoft Dynamics 365

← 返回改进指南

从订单到收款 - 计费与开票属性 (18) 从订单到收款 - 计费与开票活动 (12) 提取指南 (2)

您的 O2C 计费与开票数据模板

本模板为收集分析 O2C 计费与开票流程所需的核心数据提供了清晰的路线图。您将找到建议包含在事件日志中的属性、需追踪的关键活动，以及提取这些信息的实操指南。它旨在帮助您快速配置数据，开启深入的流程挖掘。

建议收集的属性
需要追踪的关键活动
Microsoft Dynamics 365 提取指南

不熟悉事件日志？了解如何创建流程挖掘事件日志.

下载模板

从订单到收款 - 计费与开票属性

这些是推荐包含在事件日志中的数据字段，用于全面的 O2C 计费与开票分析。

3 必填 6 推荐 9 可选

	名称	描述
	发票编号 InvoiceNumber	每张客户发票的唯一标识符，作为计费流程的主要案例标识符。
描述发票编号是将单个计费单据相关的所有活动关联在一起的核心键值。它支持对发票生命周期进行完整的端到端分析，涵盖从生成、审批到客户付款及最终结项。通过将其作为 Case ID（案例 ID），事件日志中的每个条目都对应一个特定发票，从而实现对每笔交易的详细变体分析、周期时间计算和绩效监控。为何重要该属性对于跟踪发票的整个生命周期至关重要，支持对每个独立计费单据的流程效率、瓶颈和偏差进行分析。获取方式这通常位于销售和营销模块中，见于 CustInvoiceJour（InvoiceId 字段）等表，或通过 SalesInvoiceHeaderV2 等数据实体公开。示例 CIV-001254INV-2023-9876US-004321
	Event 时间 EventTime	指示特定活动或事件发生的精确时间戳。
描述事件时间（也称为时间戳）记录了流程中每个活动发生的确切日期和时间。此数据对于所有基于时间的流程挖掘分析都至关重要。它用于计算活动间的周期时间、测量个案的总时长，并了解流程性能随时间的变化情况。准确可靠的时间戳是计算 DSO 和发票生成时间等关键 KPI 的基础。为何重要这是所有绩效和时间相关分析的基础属性，支持计算周期时间、持续时长和处理量，从而衡量流程效率。获取方式时间戳源自 Dynamics 365 不同表中的各种日期和时间字段，例如用于发票生成的 CustInvoiceJour 表中的 CreatedDateTime，或特定的工作流历史时间戳。示例 2023-04-15T10:22:15Z2023-05-01T14:05:00Z2023-05-10T09:00:30Z
	活动名称 ActivityName	在发票生命周期特定时间点发生的业务活动名称。
描述此属性描述了计费流程中的特定步骤或里程碑，例如“发票已生成”、“发票已审批”或“收到客户付款”。这些活动的顺序构成了流程流。分析活动是流程挖掘的基础，因为它支持发现流程模型、识别变体并衡量不同步骤间的绩效。为何重要它定义了流程中的各个步骤，支持流程图的可视化、流程变体分析，以及识别瓶颈或偏离标准程序的情况。获取方式该属性通常源自多个渠道，例如状态变更字段（如 DocumentState）、已填充的特定日期字段，或 Microsoft Dynamics 365 中的工作流历史日志。示例已生成发票发票已审批已收到客户付款已开具贷项通知单
	付款到期日 PaymentDueDate	客户应支付发票的日期。
描述付款截止日期是根据发票日期和客户支付条款计算得出的关键日期字段。它是衡量的基准。该属性对于“支付条款执行分析”仪表板以及计算“准时付款率”和“销售变现天数 (DSO)”等 KPI 至关重要。将此日期与实际付款日期进行对比，可以揭示客户的支付行为以及催收流程的有效性。为何重要这是衡量支付绩效的基准。对于计算准时付款率和分析对客户支付条款的执行情况至关重要。获取方式这通常位于 CustInvoiceJour 表中类似 DueDate 的字段内。示例 2023-05-152023-06-302023-07-01
	发票状态 InvoiceStatus	发票在其生命周期中的当前状态（如待付、已付、已取消）。
描述此属性提供了发票当前状态的快照。它指示发票是仍在等待付款、已全额支付、已逾期，还是已通过贷项通知单取消。这对于筛选案例以仅分析未结发票或确认已结发票的最终结果非常有用，有助于了解当前工作量和应收账款的财务状况。为何重要提供发票当前状态的快速概览，有助于筛选案例并了解不同流程变体的结果。获取方式这可以根据发票的付款状态推断得出，通常通过检查相关 CustTrans 记录的余额是否为零。并不总是存在单一的“状态”字段。示例未结已付款逾期已取消
	发票金额 InvoiceAmount	发票的总货币价值。
描述该属性代表发票的应付总额。它是财务分析的关键指标，支持按金额对发票进行细分。例如，分析师可以重点关注高价值发票以了解其支付行为，或识别大额发票是否面临更长的审批时间。它也是计算未结发票总价值和 DSO 的基础。为何重要它支持财务影响分析，允许您按金额对流程进行筛选和细分，从而优先处理高价值发票并了解其特定的流程行为。获取方式可在 CustInvoiceJour 表中找到，通常在 InvoiceAmount 类似的字段中。也可在相关的交易表中获取。示例 5430.5012500.00750.25
	客户名称 CustomerName	接收发票的客户名称。
描述客户名称为被计费的企业或个人提供了易于识别的标识。在流程挖掘分析中，这支持按客户对计费流程进行细分。它可以揭示哪些客户习惯准时付款，哪些经常逾期，或者特定的客户群是否经历了独特的流程变体或延误。这对于客户支付行为和 DSO 分析相关的仪表板至关重要。为何重要这支持按客户对流程分析进行细分，有助于识别特定客户的行为、支付模式或流程问题。获取方式该信息通过根据客户账号将发票数据与客户主数据表（通常为 CustTable）进行联接来检索。示例 Contoso Ltd.飞利康公司 (Fabrikam, Inc.)Northwind Traders
	责任人 UserResponsible	负责执行特定活动的用户或员工。
描述此属性标识了在计费流程中执行特定任务的个人，例如审批发票或核销现金。这对于工作负载分析、绩效对比和识别培训需求至关重要。例如，“计费部门活动负载”仪表板依赖此属性来观察工作分配是否均匀，或者某些用户是否成为瓶颈。它还有助于了解资源分配和效率。为何重要它支持资源层面的分析，有助于识别瓶颈、评估个人或团队绩效，并分析计费部门的工作负载分配。获取方式这可以源自工作流历史日志（如 WorkflowTrackingStatusTable），或者相关表中的所有权字段（如 Owner 或 ModifiedBy）。示例约翰·史密斯Alicia Baker系统管理员
	部门 Department	与用户或活动关联的业务部门。
描述该属性将活动或用户分配到特定的组织部门，如“应收账款”或“销售”。相比个人层面，它提供了更高维度的流程绩效视角。按部门分析有助于理解跨职能移交、比较团队间的效率，并识别部门层面的瓶颈，这也是“计费部门活动负载”仪表板的要求。为何重要支持在组织层面进行性能分析，通过比较不同团队的效率，了解跨部门交接对流程的影响。获取方式这通常不是发票交易上的直接字段。它是通过将“责任人 ID”与包含部门信息的员工或用户目录进行联接而得出的。示例应收账款财务账单运营
	DSO（应收账款周转天数） DaysSalesOutstanding	从发票生成到收到客户付款之间的天数。
描述应收账款周转天数 (DSO) 是衡量企业在销售后收回货款平均所需天数的关键财务指标。此计算属性会计算每张发票的这一时长。它是“应收账款周转天数趋势分析”仪表板和“DSO”KPI 的核心指标。分析 DSO 有助于管理现金流，并评估信贷和催收部门的运作效率。为何重要这是衡量公司现金流健康状况和催收流程效率的关键 KPI。它量化了收入转化为现金的速度。获取方式此属性不在源系统中。它是通过计算“发票已生成”活动与“收到客户付款”活动之间的时间间隔得出的。示例 284592
	付款条款 PaymentTerms	约定的发票付款条件（如 Net 30、Net 60）。
描述支付条款定义了客户应何时支付发票的规则。该属性用于计算付款截止日期，是分析支付行为的关键维度。“支付条款执行分析”仪表板利用此属性对客户和发票进行分组，以查看特定的支付条款是否更有效，或者是否与更高的逾期率相关。为何重要它提供了发票截止日期的背景信息，并允许进行细分分析，以查看特定的支付条款是否与逾期付款存在相关性。获取方式这通常存储在客户主记录中，但会复制到发票标头。请在 CustInvoiceJour 表中查找 Payment 或 PaymTermId 字段。示例净 30 天净 60 天见票即付
	最后数据更新 LastDataUpdate	用于标识该事件数据最近一次从源系统刷新的时间戳。
描述此属性记录了数据最近从 Microsoft Dynamics 365 提取或更新的时间。这是一个元数据字段，对于了解所分析数据的时效性至关重要。它能帮助分析师和业务用户确认所看信息是否为最新，对于管理数据刷新计划和确保分析的可靠性也必不可少。为何重要它确保用户了解数据的时效性，这对于数据治理、仪表板刷新管理以及确保洞察的及时性和可信度至关重要。获取方式该属性是在数据提取、转换和加载 (ETL) 过程中生成并标记到数据集中的。示例 2023-06-20T05:00:00Z2023-06-21T05:00:00Z
	是否准时付款 IsOnTimePayment	一个标记，指示客户付款是否在到期日或之前收到。
描述此计算布尔属性将“收到客户付款”的时间戳与“付款截止日期”进行对比。它将每张发票标记为准时付款或逾期付款。这是计算“准时付款率”KPI 的核心组件，在“支付条款执行分析”仪表板中被大量使用。它为支付绩效提供了清晰的二元结果，简化了分析和报告工作。为何重要直接衡量客户对付款条件的遵循情况，是“按时付款率”KPI 的基础，简化了对催收效果的分析。获取方式此属性不在源系统中。它是在数据转换过程中通过比较付款日期与付款截止日期计算得出的。示例 truefalse
	是否返工 IsRework	一个标记，指示发票处理过程中是否涉及返工活动，例如多次审批。
描述这是一个计算得出的布尔属性，用于标记经历过返工的发票。返工可定义为具有多次“发票已审批”事件或付款冲销。该属性专为支持“发票返工分析”仪表板和“发票返工率”KPI 而设计。通过隔离这些案例，分析师可以调查返工的根本原因，这通常指向流程低效、数据质量问题或培训缺口。为何重要该标记通过识别具有重复性或修正性动作的案例，直接量化了流程的低效，有助于精准定位浪费和延误的根本原因。获取方式此属性在源系统中不可用。它是在数据转换层通过检查案例中的重复活动或特定的返工模式计算得出的。示例 truefalse
	源系统 SourceSystem	数据提取来源系统。
描述此属性标识了流程数据的来源。在此上下文中，它指明数据来自 Microsoft Dynamics 365。在多系统环境中，这对于区分数据源并确保数据血缘清晰非常重要，有助于数据验证和故障排查。为何重要它提供了关于数据来源的关键背景信息，这对于数据治理、验证以及整合来自多个企业系统的数据至关重要。获取方式这是在数据提取和转换过程中添加的静态值，用于标记数据集的来源。示例 Microsoft Dynamics 365 FinanceD365 F&O
	货币 Currency	发票金额的货币代码（例如：USD, EUR）。
描述该属性指定了发票金额的币种。对于处理不同货币的跨国组织来说，这是必不可少的。如果没有这一背景信息，汇总或比较发票金额将毫无意义。它支持进行正确的货币换算，以及跨不同地区的准确财务报告和分析。为何重要它为发票金额等财务指标提供了必要的背景，防止错误的汇总，并在多货币环境中实现准确的分析。获取方式可在 CustInvoiceJour 表中找到，通常在 CurrencyCode 类似的字段中。示例美元EURGBP
	销售订单编号 SalesOrderNumber	产生该发票的销售订单标识符。
描述销售订单编号将计费流程与其前置的销售流程联系起来。这种关联对于更广泛的端到端 O2C 分析极具价值。它允许分析师调查销售和履行环节的问题（如订单变更或发货延误）如何影响计费周期。例如，它可以帮助回答“复杂销售订单产生的发票是否需要更长时间才能收到回款？”等问题。为何重要该属性将计费流程与上游销售流程相连，从而实现更全面的端到端 O2C 分析，以识别计费问题的根本原因。获取方式可在发票抬头或行明细中找到，链接回销售订单。在 CustInvoiceJour 表中查找 SalesId 类似的字段。示例 SO-009876SO-010234US-SO-00543
	需要人工干预 RequiresManualIntervention	一个标记，指示在现金核销过程中该笔付款是否需要手动调整。
描述该布尔属性标记了在现金核销过程中需要人工干预或修正的付款。这是“现金核销差异率”KPI 的核心，有助于量化付款过账的准确性和自动化程度。识别需要人工干预的原因（如缺失付款通知信息或金额不符），可以引导流程改进，从而提高直通处理率 (STP)。为何重要该属性有助于识别现金核销环节中的流程摩擦和偏差，这对于提高自动化程度和减少人工干预至关重要。获取方式该信息可能推断自过账付款的用户（如果不是系统用户），或者源自对账过程中使用的特定原因代码。请咨询 Microsoft Dynamics 365 文档。示例 truefalse

必填推荐可选

从订单到收款 - 计费与开票活动

为确保流程发现与分析准确，建议在事件日志中记录以下关键步骤与里程碑。

7 推荐 5 可选

	活动	描述
	到达付款截止日期	这是一个计算得出的事件，当发票到达付款截止日期且款项未被全额核销时触发。此活动不对应于系统中的具体交易记录，而是根据现有数据推导出来的。
为何重要该事件对于分析准时付款率和识别即将逾期的发票至关重要。它是触发催收和催款活动的切入点。获取方式这不作为一个事件记录。它是利用 CustInvoiceJour 表中的 DueDate 字段计算得出的。事件时间戳即为截止日期本身。捕获创建一个事件，其时间戳为 CustInvoiceJour.DueDate 字段的值。事件类型 calculated
	发票已发送给客户	此活动表示发票通过电子或纸质方式发送给客户的时刻。在 Dynamics 365 中，如果是通过系统邮件发送，则这可能是一个明确的事件；如果未启用特定跟踪，则推断发生在过账之时。
为何重要衡量发票交付流程的效率。审批与发票发出之间的延迟会不必要地延长回款周期。获取方式如果使用 D365 的电子邮件功能，可以从 SysOutgoingEmailTable 等邮件日志中明确捕获。否则，通常推断其与 CustInvoiceJour 中的发票过账时间相同。捕获如果可用，请使用邮件日志时间戳；否则，请使用发票过账时间戳。事件类型 inferred
	发票已审批	标志着内部审核流程的结束，即发票获得正式批准。该事件由 Dynamics 365 工作流系统记录，表示发票已准备好发送给客户。
为何重要这是衡量审批周期时间的关键里程碑。此阶段的延误会直接增加从客户处收到付款所需的总时长。获取方式记录在工作流历史表（如 WorkflowTrackingStatusTable）中，作为特定发票工作流实例的完成或审批步骤。捕获提取状态为“Approved”（已批准）或“Completed”（已完成）的工作流事件日志。事件类型 explicit
	发票已结案	此活动标志着发票的最终状态，即由于已全额支付或通过贷项通知单结算，其余额为零。这不是一项直接交易，而是基于发票财务状况推断出的状态。
为何重要该事件标志着单张发票 O2C 周期的成功结束。到达此状态所需的时间是衡量流程整体效率的首要指标。获取方式通过检查 CustTrans 表中的发票交易余额是否为零来推断。这是通过比较发票金额与针对该发票的已结算总额来确定的。捕获从 AmountCur 等于 SettleAmountCur 的 CustTrans 记录中推导。时间戳为最后一次核销的日期。事件类型 inferred
	已收到客户付款	此活动标志着记录客户付款的日记账分录的创建。它表示现金已收到，但尚未核销至具体发票。
为何重要这是衡量现金核销前置时间的起点。它将“收到钱款”与“实际针对待付发票进行对账”这两个动作区分开来。获取方式从客户付款日记账的创建或过账中捕获。记录在 LedgerJournalTrans 等表中，过账后会在 CustTrans 中创建客户交易。捕获使用 LedgerJournalTable 中客户付款日记账的过账时间戳。事件类型 explicit
	已生成发票	表示系统中销售发票单据的创建和过账。这是 Dynamics 365 中的一项明确交易，会生成法律单据并在应收账款明细账中创建财务分录。
为何重要这是发票计费生命周期的正式开始。它是追踪销售变现天数 (DSO) 和整体流程时长的关键事件。获取方式从 CustInvoiceJour 表中已过账销售发票记录的创建时间戳捕获。过账后，相应的财务交易将在 GeneralJournalEntry 和 LedgerEntry 表中创建。捕获使用 CustInvoiceJour 表中已过账发票的 CreatedDateTime 字段。事件类型 explicit
	现金已分摊至发票	表示客户付款与特定发票的结算，从而减少发票的待付余额。这是 Dynamics 365 中将付款交易与发票交易关联起来的一个独立步骤。
为何重要这是准确计算 DSO 和了解现金核销团队效率的关键里程碑。它标志着付款已与开票金额完全对账。获取方式记录在 CustSettlement 表中。该表中的结算日期字段提供了特定付款核销至特定发票交易的时间戳。捕获使用 CustSettlement 表中的 TransDate 或 CreatedDateTime。事件类型 explicit
	付款已冲销	此活动表示对先前已过账的客户付款进行冲销。发生这种情况通常是由于过账错误、余额不足或其他付款失败原因。
为何重要付款冲销反映了操作错误或客户付款问题。分析其发生频率有助于识别根本原因并提高现金核销过程的准确性。获取方式在总账中捕获为交易冲销。可以在 GeneralJournalEntry 中识别冲销凭证，通常带有特定标记或通过其与原始交易的关系来识别。捕获识别带有冲销标记或引用了已冲销交易的日记账分录。事件类型 explicit
	发票已提交审批	此活动表示生成的发票已提交至正式的审批工作流。这在要求管理层在发票发出前进行审核的企业中非常普遍，它作为 D365 工作流引擎中的一个特定步骤被记录。
为何重要追踪“提交审批”有助于将发票创建时间与审批等待时间区分开。这是分析内部审核和控制流程效率的第一步。获取方式通过筛选与发票单据相关的提交事件，从 WorkflowTrackingStatusTable 等工作流历史记录表中捕获。捕获提取状态为“Submitted”（已提交）的工作流事件日志。事件类型 explicit
	已发布付款提醒	表示针对逾期发票向客户发送催款单或催收通知。Dynamics 365 拥有正式的催收流程来生成并记录这些沟通信息。
为何重要追踪提醒有助于评估催款流程的有效性，并分析在收到付款前通常需要多少次提醒。获取方式这是一个明确的事件，捕捉自 CustCollectionLetterJour 表中催款单日记账的创建日期，该表与逾期发票交易相关联。捕获使用 CustCollectionLetterJour 表中的创建时间戳。事件类型 explicit
	已开具贷项通知单	表示贷项通知单（红字发票）的创建，通常用于纠正计费错误、给予价格调整或处理退货。贷项通知单本质上是一张负数发票。
为何重要频繁开具贷记单可能预示着订单履约或账单流程中存在系统性问题。分析贷记单开具的原因是改进流程和减少收入流失的关键。获取方式这是一项明确交易，作为一张金额为负的新过账发票记录在 CustInvoiceJour 表中。通常通过参考字段链接到原始发票。捕获识别 CustInvoiceJour 中总额为负的记录，并将其关联至原始发票。事件类型 explicit
	销售订单已履行	此活动标志着销售订单的货物已发货或服务已提供，从而触发计费流程。通常根据 Microsoft Dynamics 365 中装箱单或送货单的过账情况来推断，这会改变相关销售订单行的状态。
为何重要该事件是衡量发票生成周期时间的起点。了解订单履行与开票之间的延误，有助于识别可能影响现金流的行政瓶颈。获取方式根据与销售订单关联的装箱单日记账条目的创建日期推断。这涉及 CustPackingSlipJour 和 CustPackingSlipTrans 等表，这些表与发票所属的销售订单相关联。捕获识别与该发票关联的销售订单的最后一次装箱单过账日期。事件类型 inferred

推荐可选

提取指南

如何从 Microsoft Dynamics 365 获取您的数据

步骤

导航至数据管理工作区： 登录 Microsoft Dynamics 365 Finance and Operations。使用搜索栏找到并进入 Data management 工作区。这是所有数据导入和导出操作的中心枢纽。
创建一个新的导出项目： 在 Data management 工作区中，点击 Export 磁贴以创建新的数据导出项目。为项目起一个有意义的名称，例如 ProcessMind_O2C_Billing_Export，并添加描述。
选择目标数据格式： 在项目配置中，指定 Target data format。为了兼容大多数数据转换工具，请选择 CSV。根据需要配置格式选项，确保使用通用的分隔符和文本限定符。
添加所需的数据实体： 这是最关键的一步。您将向项目中添加多个标准数据实体，以捕获所有必需的活动。对于每个实体，点击 Add entity 并搜索“查询/脚本”部分列出的实体名称。将以下每个实体添加到您的项目中：Sales invoice headers V2、Sales packing slip headers、Workflow tracking status table、CustPaymentJournalLineEntity、Customer settlement 和 Dunning history letters。
应用实体筛选： 为了将数据限制在相关范围内，请对实体应用筛选器。至少应针对 Sales invoice headers V2 按 InvoiceDate 筛选特定时期（例如最近 6 个月）。同时，按您希望分析的特定法律实体（公司）进行筛选。
运行导出作业： 添加完所有实体并应用筛选器后，点击操作面板中的 Export 按钮。系统将创建一个作业包并在后台开始处理数据提取。
监控并下载数据： 您可以在 Job history 部分监控作业进度。作业成功完成后，您可以下载导出的数据包。该包是一个 ZIP 文件，其中包含每个数据实体的独立 CSV 文件。
解压数据包： 将下载的 ZIP 文件内容解压到本地文件夹。您现在将拥有多个 CSV 文件，每个文件对应一个实体。
转换并合并数据： 原始文件必须转换为单一的事件日志格式。可以使用 Power Query、Python 或数据库暂存区等数据准备工具。为每个源文件创建所需的列：InvoiceNumber (Case ID)、ActivityName（代表事件的固定值，如“Invoice Generated”）以及 EventTime（源文件中的相关日期字段）。同时映射其他属性，如 InvoiceAmount 和 CustomerName。
合并所有转换后的数据： 使用合并或追加操作将所有源文件中转换后的数据整合到一个表中。这将创建最终的统一事件日志，其中每一行代表发票生命周期中的一个活动。
上传前的最终格式化： 确保最终的 CSV 文件具有正确的列标题（InvoiceNumber、ActivityName、EventTime 等），且 EventTime 列采用一致的时间戳格式（例如 YYYY-MM-DD HH:MI:SS）。该文件现在可以上传至 ProcessMind 了。

配置

数据实体： 提取过程依赖于一组标准的 D365 数据实体。关键实体包括 Sales invoice headers V2（用于发票和贷记单）、Sales packing slip headers（用于订单履约）、CustPaymentJournalLineEntity（用于付款）、Customer settlement（用于现金核销）以及 Workflow tracking status table（用于审批）。
导出格式： 建议的目标数据格式为 CSV，因为它与各类数据转换工具具有广泛的兼容性。
日期范围筛选： 对主要实体应用日期范围筛选至关重要，特别是针对 Sales invoice headers V2 的 InvoiceDate 字段。建议选择 3 到 6 个月的时间范围，以便在提供充足分析数据的同时，确保导出量可控。
公司筛选： 导出任务应根据您正在分析的特定法律实体或公司代码进行筛选，以确保数据相关性并减小导出文件的大小。
数据暂存与转换： 需要在 Dynamics 365 之外进行后期处理。导出的文件必须经过合并和重组，形成统一的事件日志格式。这通常涉及使用 Power BI (Power Query)、Python 或 SQL 等工具。
前提条件： 执行导出的用户必须在 Dynamics 365 中分配了适当的安全角色，通常包括拥有 Data management 工作区权限以及访问所需数据实体权限的角色。

a 查询示例 config

The following configuration outlines the data entities and field mappings required for the export project within the Dynamics 365 Data Management Framework. A post-processing script or tool is required to union these outputs into a single event log.

**1. Activity: Sales Order Fulfilled**
*   **Entity Name:** `Sales packing slip headers`
*   **Mapping:**
    *   `InvoiceNumber`: Use `SalesOrderNumber` as a key to later join to the invoice data and find the corresponding `InvoiceNumber`.
    *   `ActivityName`: 'Sales Order Fulfilled' (Hardcoded Value)
    *   `EventTime`: `DeliveryDate`
    *   `UserResponsible`: `CreatedBy`

**2. Activity: Invoice Generated**
*   **Entity Name:** `Sales invoice headers V2`
*   **Filter:** `InvoiceType` is not 'CreditNote'.
*   **Mapping:**
    *   `InvoiceNumber`: `InvoiceNumber`
    *   `ActivityName`: 'Invoice Generated' (Hardcoded Value)
    *   `EventTime`: `InvoiceDate` and `CreatedTime`
    *   `InvoiceAmount`: `TotalInvoiceAmount`
    *   `CustomerName`: `InvoiceCustomerName`
    *   `UserResponsible`: `CreatedBy`
    *   `PaymentDueDate`: `DueDate`
    *   `InvoiceStatus`: `DocumentState`

**3. Activities: Invoice Submitted for Approval & Invoice Approved**
*   **Entity Name:** `Workflow tracking status table`
*   **Filter:** `ContextTableName` is 'CustInvoiceJour'.
*   **Mapping:**
    *   `InvoiceNumber`: Join `ContextRecId` to `RecId` from `Sales invoice headers V2` to get the `InvoiceNumber`.
    *   `ActivityName`: Use a conditional rule, if `TrackingStatus` is 'Submitted', set to 'Invoice Submitted for Approval'; if 'Approved', set to 'Invoice Approved'.
    *   `EventTime`: `CreatedDateTime`
    *   `UserResponsible`: `User`

**4. Activity: Invoice Sent to Customer**
*   **Note:** This is an inferred event. The posting date is used as a proxy.
*   **Entity Name:** `Sales invoice headers V2`
*   **Mapping:**
    *   `InvoiceNumber`: `InvoiceNumber`
    *   `ActivityName`: 'Invoice Sent to Customer' (Hardcoded Value)
    *   `EventTime`: `PostedDateTime` (or equivalent posting timestamp)

**5. Activity: Payment Due Date Reached**
*   **Note:** This is a calculated event generated during post-processing.
*   **Source Entity:** `Sales invoice headers V2`
*   **Logic:** For each invoice where the `DueDate` has passed and the invoice is not fully settled.
*   **Mapping:**
    *   `InvoiceNumber`: `InvoiceNumber`
    *   `ActivityName`: 'Payment Due Date Reached' (Hardcoded Value)
    *   `EventTime`: `DueDate`

**6. Activity: Payment Reminder Issued**
*   **Entity Name:** `Dunning history letters`
*   **Mapping:**
    *   `InvoiceNumber`: Join from the dunning history to the customer transactions to find the related `InvoiceNumber`.
    *   `ActivityName`: 'Payment Reminder Issued' (Hardcoded Value)
    *   `EventTime`: `DunningLetterDate`
    *   `UserResponsible`: `CreatedBy`

**7. Activity: Customer Payment Received**
*   **Entity Name:** `CustPaymentJournalLineEntity`
*   **Mapping:**
    *   `InvoiceNumber`: The `Invoice` field may be populated, but often settlements are needed to link payments to invoices. This might require staging the payment data first.
    *   `ActivityName`: 'Customer Payment Received' (Hardcoded Value)
    *   `EventTime`: `ReceivedDate` or `DocumentDate`
    *   `UserResponsible`: `CreatedBy`

**8. Activity: Cash Applied to Invoice**
*   **Entity Name:** `Customer settlement`
*   **Mapping:**
    *   `InvoiceNumber`: `OffsetInvoice`
    *   `ActivityName`: 'Cash Applied to Invoice' (Hardcoded Value)
    *   `EventTime`: `TransDate`
    *   `UserResponsible`: `CreatedBy`

**9. Activity: Payment Reversed**
*   **Source Entity:** `Customer settlement`
*   **Logic:** Filter for transactions where a settlement was later reversed. This may require looking for cancellation markers.
*   **Mapping:**
    *   `InvoiceNumber`: `OffsetInvoice`
    *   `ActivityName`: 'Payment Reversed' (Hardcoded Value)
    *   `EventTime`: Reversal transaction timestamp.

**10. Activity: Credit Note Issued**
*   **Entity Name:** `Sales invoice headers V2`
*   **Filter:** `InvoiceType` is 'CreditNote'.
*   **Mapping:**
    *   `InvoiceNumber`: `InvoiceNumber`
    *   `ActivityName`: 'Credit Note Issued' (Hardcoded Value)
    *   `EventTime`: `InvoiceDate`
    *   `InvoiceAmount`: `TotalInvoiceAmount` (will be negative)
    *   `CustomerName`: `InvoiceCustomerName`
    *   `UserResponsible`: `CreatedBy`

**11. Activity: Invoice Closed**
*   **Note:** This is an inferred event based on settlement data.
*   **Source Entity:** `Customer settlement`
*   **Logic:** Use the latest `TransDate` for an invoice from the settlement data where the invoice balance becomes zero.
*   **Mapping:**
    *   `InvoiceNumber`: `OffsetInvoice`
    *   `ActivityName`: 'Invoice Closed' (Hardcoded Value)
    *   `EventTime`: The latest `TransDate` that resulted in the invoice being fully settled.

步骤

前提条件：确保已安装 Python 3.6+ 以及 requests 和 pandas 库。您还需要在 Azure Active Directory 中注册一个已获准访问 Dynamics 365 Finance & Operations 环境的服务主体（应用注册）凭据。
应用注册：在 Azure AD 中注册一个新应用。创建客户端机密，并记录应用（客户端）ID、目录（租户）ID 和客户端机密。在 Dynamics 365 中，通过“系统管理 > 设置 > Azure Active Directory 应用程序”添加此应用 ID，并分配读取所需数据实体的相应权限。
配置脚本：打开提供的 Python 脚本。填写脚本顶部的配置变量，包括 d365_url、tenant_id、client_id、client_secret、company、start_date 和 end_date。d365_url 应为您环境的基础 URL，例如 https://your-d365-instance.operations.dynamics.com。
身份验证：脚本包含一个 get_access_token 函数，它会自动使用您的凭据从微软身份平台请求 OAuth2 访问令牌。此令牌用于后续所有 API 调用的授权。
数据提取：在终端运行 python your_script_name.py。脚本首先获取指定日期范围内的所有已过账销售发票（CustInvoiceJour）。针对每张发票，它会进一步调用 API 以获取相关的付款、核销、贷记单和工作流历史等活动数据。
活动生成：脚本处理来自多个 API 端点的原始数据。它会明确地为 12 个所需活动中的每一个生成一行。例如，它使用 CustInvoiceJour 实体生成“发票已生成”事件，查询 CustSettlement 实体生成“发票现金已核销”事件。
计算得出的事件：请注意，“付款到期日已到”和“发票已关闭”等事件在 Dynamics 365 中并不是直接的交易记录。脚本根据发票的到期日、状态和核销历史推导这些事件，并在事件日志中创建相应条目。
分页处理：fetch_all_data 辅助函数旨在自动处理分页。Dynamics 365 OData API 每页返回的记录数有限，因此该函数会根据响应中的 @odata.nextLink 递归获取完整的数据集。
数据转换与输出：收集完所有事件后，脚本将其汇总至列表中，转换为 pandas DataFrame，并标准化列名，包括 InvoiceNumber、ActivityName、EventTime 以及其他必要属性。
导出 CSV：最后，脚本将 DataFrame 保存为名为 d365_billing_event_log.csv 的 CSV 文件。该文件格式已调整完毕，可直接上传至 ProcessMind 或其他流程挖掘工具。

配置

D365 URL：Dynamics 365 Finance & Operations 实例的基准 URL。这是所有 API 调用的主要端点。
Azure AD 凭据：身份验证需要 client_id、client_secret 和 tenant_id。这些凭据应属于对相关 D365 实体具有读取权限的应用程序。
公司：指定 DataAreaId，对应于 Dynamics 365 中要从中提取数据的法律实体（例如 “USMF”）。
日期范围：定义 start_date 和 end_date 以限制提取范围。对于初步分析，建议选择 3 到 6 个月的时间段，以确保在捕获足够的流程变体的同时，保持数据集大小在可控范围内。
关键 OData 实体：该脚本主要查询以下实体：CustInvoiceJours、CustSettlements、CustTrans、CustCollectionLetterJours 和 WorkflowTrackingStatusTables。请确保配置的用户具有读取所有这些实体的权限。
性能：由于需要进行多次顺序 API 调用，提取长期数据或超大型公司的数据可能会较慢。建议在非高峰时段运行脚本，并先从较小的日期范围开始，以预估总执行时间。

a 查询示例 python

import requests
import pandas as pd
from datetime import datetime, timezone

class=class="hl-string">"hl-comment"># --- Configuration ---
d365_url = class="hl-string">"https://[your-d365-instance].operations.dynamics.com" class=class="hl-string">"hl-comment"># Your D365 F&O URL
tenant_id = class="hl-string">"[Your Tenant ID]"
client_id = class="hl-string">"[Your Client ID]"
client_secret = class="hl-string">"[Your Client Secret]"
company = class="hl-string">"[Your Company DataAreaId, e.g., USMF]"
start_date = class="hl-string">"2023-01-01"
end_date = class="hl-string">"2023-12-31"

class=class="hl-string">"hl-comment"># --- Authentication ---
def get_access_token():
    url = fclass="hl-string">"https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/token"
    payload = {
        class="hl-string">'grant_type': class="hl-string">'client_credentials',
        class="hl-string">'client_id': client_id,
        class="hl-string">'client_secret': client_secret,
        class="hl-string">'scope': fclass="hl-string">"{d365_url}/.default"
    }
    response = requests.post(url, data=payload)
    response.raise_for_status()
    return response.json()[class="hl-string">'access_token']

class=class="hl-string">"hl-comment"># --- OData Helper ---
def fetch_all_data(access_token, resource_path):
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}',
        class="hl-string">'Content-Type': class="hl-string">'application/json'
    }
    full_url = fclass="hl-string">"{d365_url}/data/{resource_path}"
    results = []
    while full_url:
        response = requests.get(full_url, headers=headers)
        response.raise_for_status()
        data = response.json()
        results.extend(data[class="hl-string">'value'])
        full_url = data.get(class="hl-string">'@odata.nextLink')
    return results

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---
def main():
    print(class="hl-string">"Acquiring access token...")
    token = get_access_token()
    event_log = []
    today = datetime.now(timezone.utc).date()

    print(class="hl-string">"Fetching Invoices and Credit Notes...")
    invoice_filter = fclass="hl-string">"$filter=InvoiceDate ge {start_date} and InvoiceDate le {end_date}"
    invoice_fields = class="hl-string">"$select=InvoiceNumber,InvoiceDate,SalesOrderNumber,InvoiceAmount,CustomerAccount,Due_Date,WorkerSalespersonName,createdDateTime,RecId,SalesInvoiceHeader_SalesStatus"
    invoices = fetch_all_data(token, fclass="hl-string">"CustInvoiceJours?cross-company=true&{invoice_filter}&{invoice_fields}")

    class=class="hl-string">"hl-comment"># Create a lookup for invoice RecIds for workflow queries
    invoice_recid_map = {inv[class="hl-string">'RecId']: inv[class="hl-string">'InvoiceNumber'] for inv in invoices}

    for inv in invoices:
        case_id = inv[class="hl-string">'InvoiceNumber']
        invoice_amount = inv[class="hl-string">'InvoiceAmount']
        customer_name = inv.get(class="hl-string">'CustomerAccount', class="hl-string">'') class=class="hl-string">"hl-comment"># Placeholder, join to CustTable for name
        user_responsible = inv.get(class="hl-string">'WorkerSalespersonName', class="hl-string">'System')
        due_date = inv.get(class="hl-string">'Due_Date')
        invoice_status = inv.get(class="hl-string">'SalesInvoiceHeader_SalesStatus', class="hl-string">'Open')

        class=class="hl-string">"hl-comment"># Activity: Invoice Generated / Credit Note Issued
        activity_name = class="hl-string">'Credit Note Issued' if invoice_amount < 0 else class="hl-string">'Invoice Generated'
        event_log.append({
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'ActivityName': activity_name,
            class="hl-string">'EventTime': inv[class="hl-string">'createdDateTime'],
            class="hl-string">'InvoiceAmount': invoice_amount,
            class="hl-string">'CustomerName': customer_name,
            class="hl-string">'UserResponsible': user_responsible,
            class="hl-string">'Department': class="hl-string">'[Configure based on your system]',
            class="hl-string">'PaymentDueDate': due_date,
            class="hl-string">'InvoiceStatus': invoice_status
        })

        class=class="hl-string">"hl-comment"># Activity: Invoice Sent to Customer (proxy)
        event_log.append({
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Invoice Sent to Customer',
            class="hl-string">'EventTime': inv[class="hl-string">'InvoiceDate'],
            class="hl-string">'InvoiceAmount': invoice_amount,
            class="hl-string">'CustomerName': customer_name,
            class="hl-string">'UserResponsible': user_responsible,
            class="hl-string">'Department': class="hl-string">'[Configure based on your system]',
            class="hl-string">'PaymentDueDate': due_date,
            class="hl-string">'InvoiceStatus': invoice_status
        })
        
        class=class="hl-string">"hl-comment"># Activity: Sales Order Fulfilled (proxy via invoice date, complex to get actual packing slip date)
        class=class="hl-string">"hl-comment"># A more accurate query would trace SalesInvoiceLinesV2 -> SalesOrderLines -> CustPackingSlipJour
        event_log.append({
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Sales Order Fulfilled',
            class="hl-string">'EventTime': inv[class="hl-string">'InvoiceDate'], class=class="hl-string">"hl-comment"># Using InvoiceDate as a proxy
            class="hl-string">'InvoiceAmount': invoice_amount,
            class="hl-string">'CustomerName': customer_name,
            class="hl-string">'UserResponsible': user_responsible,
            class="hl-string">'Department': class="hl-string">'[Configure based on your system]',
            class="hl-string">'PaymentDueDate': due_date,
            class="hl-string">'InvoiceStatus': invoice_status
        })

        class=class="hl-string">"hl-comment"># Activity: Payment Due Date Reached (calculated)
        if due_date and pd.to_datetime(due_date).date() < today and invoice_status != class="hl-string">'Paid':
            event_log.append({
                class="hl-string">'InvoiceNumber': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Payment Due Date Reached',
                class="hl-string">'EventTime': due_date,
                class="hl-string">'InvoiceAmount': invoice_amount,
                class="hl-string">'CustomerName': customer_name,
                class="hl-string">'UserResponsible': class="hl-string">'System',
                class="hl-string">'Department': class="hl-string">'Finance',
                class="hl-string">'PaymentDueDate': due_date,
                class="hl-string">'InvoiceStatus': invoice_status
            })

    print(class="hl-string">"Fetching Settlements for Cash Applied and Invoice Closed events...")
    settlement_filter = fclass="hl-string">"$filter=InvoiceDate ge {start_date} and InvoiceDate le {end_date}"
    settlement_fields = class="hl-string">"$select=InvoiceNumber,SettlementDate,OffsetTransactionVoucher,OffsetRecId,CanBeReversed"
    settlements = fetch_all_data(token, fclass="hl-string">"CustSettlements?cross-company=true&{settlement_filter}&{settlement_fields}")

    class=class="hl-string">"hl-comment"># Group settlements by invoice
    settlements_by_invoice = pd.DataFrame(settlements).groupby(class="hl-string">'InvoiceNumber')

    for case_id, group in settlements_by_invoice:
        last_settlement = group.sort_values(class="hl-string">'SettlementDate').iloc[-1]

        for _, settlement in group.iterrows():
            class=class="hl-string">"hl-comment"># Activity: Cash Applied to Invoice
            event_log.append({
                class="hl-string">'InvoiceNumber': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Cash Applied to Invoice',
                class="hl-string">'EventTime': settlement[class="hl-string">'SettlementDate'],
                class="hl-string">'UserResponsible': class="hl-string">'System',
                class=class="hl-string">"hl-comment"># Add other attributes from original invoice if needed
            })

            class=class="hl-string">"hl-comment"># Activity: Customer Payment Received (date of original payment)
            class=class="hl-string">"hl-comment"># This requires a second hop to CustTrans using OffsetRecId
            class=class="hl-string">"hl-comment"># For simplicity, we use settlement date as a proxy. A full implementation would query CustTrans.
            event_log.append({
                class="hl-string">'InvoiceNumber': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Customer Payment Received',
                class="hl-string">'EventTime': settlement[class="hl-string">'SettlementDate'], class=class="hl-string">"hl-comment"># Proxy timestamp
                class="hl-string">'UserResponsible': class="hl-string">'System',
            })

            class=class="hl-string">"hl-comment"># Activity: Payment Reversed (if applicable)
            if settlement[class="hl-string">'CanBeReversed']: class=class="hl-string">"hl-comment"># A simplistic check, real logic is more complex
                 event_log.append({
                    class="hl-string">'InvoiceNumber': case_id,
                    class="hl-string">'ActivityName': class="hl-string">'Payment Reversed',
                    class="hl-string">'EventTime': settlement[class="hl-string">'SettlementDate'], class=class="hl-string">"hl-comment"># Reversal date would be different in reality
                    class="hl-string">'UserResponsible': class="hl-string">'System',
                 })
        
        class=class="hl-string">"hl-comment"># Activity: Invoice Closed (inferred from last settlement)
        class=class="hl-string">"hl-comment"># This logic assumes the invoice is fully paid by the last settlement. A robust check would sum amounts.
        event_log.append({
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Invoice Closed',
            class="hl-string">'EventTime': last_settlement[class="hl-string">'SettlementDate'],
            class="hl-string">'UserResponsible': class="hl-string">'System',
        })

    print(class="hl-string">"Fetching Payment Reminders...")
    reminder_filter = fclass="hl-string">"$filter=CollectionLetterDate ge {start_date} and CollectionLetterDate le {end_date}"
    reminders = fetch_all_data(token, fclass="hl-string">"CustCollectionLetterJours?cross-company=true&{reminder_filter}")
    for rem in reminders:
        class=class="hl-string">"hl-comment"># Linking reminders to invoices can be complex. This is a simplified approach.
        if rem.get(class="hl-string">'InvoiceNum'):
            event_log.append({
                class="hl-string">'InvoiceNumber': rem[class="hl-string">'InvoiceNum'],
                class="hl-string">'ActivityName': class="hl-string">'Payment Reminder Issued',
                class="hl-string">'EventTime': rem[class="hl-string">'CollectionLetterDate'],
                class="hl-string">'UserResponsible': rem.get(class="hl-string">'UserId', class="hl-string">'System'),
            })

    print(class="hl-string">"Fetching Workflow History...")
    class=class="hl-string">"hl-comment"># This is a complex query. It requires knowing the TableId for CustInvoiceJour (e.g., 523)
    class=class="hl-string">"hl-comment"># The filter below is illustrative and needs to be adapted for your specific workflow setup.
    workflow_filter = fclass="hl-string">"$filter=createdDateTime ge {start_date}T00:00:00Z"
    wf_history = fetch_all_data(token, fclass="hl-string">"WorkflowTrackingStatusTables?cross-company=true&{workflow_filter}")
    for item in wf_history:
        if item.get(class="hl-string">'ContextRecId') in invoice_recid_map:
            case_id = invoice_recid_map[item[class="hl-string">'ContextRecId']]
            activity_name = None
            if item[class="hl-string">'TrackingStatus'] == class="hl-string">'Submitted':
                activity_name = class="hl-string">'Invoice Submitted for Approval'
            elif item[class="hl-string">'TrackingStatus'] == class="hl-string">'Approved':
                activity_name = class="hl-string">'Invoice Approved'
            
            if activity_name:
                event_log.append({
                    class="hl-string">'InvoiceNumber': case_id,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventTime': item[class="hl-string">'createdDateTime'],
                    class="hl-string">'UserResponsible': item.get(class="hl-string">'User', class="hl-string">'System'),
                })

    print(fclass="hl-string">"Total events extracted: {len(event_log)}")
    if not event_log:
        print(class="hl-string">"No events found for the given criteria.")
        return

    df = pd.DataFrame(event_log)
    df = df.sort_values(by=[class="hl-string">'InvoiceNumber', class="hl-string">'EventTime'])
    df.to_csv(class="hl-string">'d365_billing_event_log.csv', index=False)
    print(class="hl-string">"Event log saved to d365_billing_event_log.csv")

if __name__ == class="hl-string">"__main__":
    main()

您的 O2C 计费与开票数据模板

您的 O2C 计费与开票数据模板

从订单到收款 - 计费与开票属性

从订单到收款 - 计费与开票活动

提取指南

Microsoft Dynamics 365 数据实体导出

步骤

配置

a 查询示例 config

使用 Dynamics 365 OData Web API 的 Python 脚本

步骤

配置

a 查询示例 python

准备好开始了吗？

告别账单延迟：立即优化销售到收款及开票流程

您的 O2C 计费与开票数据模板

您的 O2C 计费与开票数据模板

从订单到收款 - 计费与开票属性

从订单到收款 - 计费与开票活动

提取指南

Microsoft Dynamics 365 数据实体导出

步骤

配置

a 查询示例 config

使用 Dynamics 365 OData Web API 的 Python 脚本

步骤

配置

a 查询示例 python

我们重视您的隐私

准备好开始了吗？

告别账单延迟：立即优化销售到收款及开票流程