> 持续流程改进 > 订单到收款：开票与发票处理 > Microsoft Dynamics 365 > 数据模板

订单到收款中账单与开票流程的数据模板

Microsoft Dynamics 365

← 返回改进指南

订单到收款中账单与开票流程的属性(18) 订单到收款中账单与开票流程的活动(12) 数据提取指南(2)

订单到收款中账单与开票流程的数据模板

此模板为收集分析订单到收款中账单与开票流程所需的关键数据提供清晰指引。您可以查看建议纳入事件日志的属性、需要跟踪的关键活动，以及提取这些数据的实用指南。借助此模板，您可以快速准备数据，开展流程挖掘分析。

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

刚接触事件日志？了解如何创建流程挖掘事件日志.

下载模板

订单到收款中账单与开票流程的属性

为全面分析订单到收款中的账单与开票流程，建议在事件日志中纳入以下数据字段。

3 必填 6 建议填写 9 选填

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

必填建议填写选填

订单到收款中账单与开票流程的活动

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

7 建议填写 5 选填

	活动	说明
	付款到期日已到	当发票到期但尚未全额核销付款时触发的计算事件。此活动并非系统中的实际交易，而是根据现有数据推导得出。
重要性此事件对于分析按时付款率和发现即将逾期的发票至关重要，也是启动催收活动的触发点。获取途径系统不会将其记录为事件。此事件根据CustInvoiceJour表中的DueDate字段计算，事件时间戳即为到期日。采集创建一个事件，其时间戳取自CustInvoiceJour.DueDate字段。事件类型 calculated
	发票已批准	标志内部审核流程完成，发票已正式获批。Dynamics 365工作流系统会记录此事件，表示发票已准备好发送给客户。
重要性这是衡量审批周期时间的重要节点。此阶段的延迟会直接延长客户付款所需的总时间。获取途径在WorkflowTrackingStatusTable等工作流历史记录表中，记录为特定发票工作流实例的完成或审批步骤。采集提取状态为“已批准”或“已完成”的工作流事件日志。事件类型 explicit
	发票已生成	表示系统中销售发票单据的创建和过账。这是Dynamics 365中的一笔明确交易，会生成法律单据，并在应收账款子分类账中创建财务分录。
重要性这是发票开具周期的正式起点，也是跟踪应收账款周转天数（DSO）和整体流程时长的关键事件。获取途径从CustInvoiceJour表中已过账销售发票记录的创建时间戳获取。过账时，系统会在GeneralJournalEntry和LedgerEntry表中创建相应的财务交易。采集使用CustInvoiceJour表中已过账发票的CreatedDateTime字段。事件类型 explicit
	发票已结清	此活动标志发票的最终状态：发票已全额付款或通过贷项通知单结算，余额为零。这并非直接交易，而是根据发票的财务状态推断得出。
重要性此事件表示单张发票的订单到收款周期已成功完成。达到此状态所需的时间是衡量整体流程效率的主要指标。获取途径检查CustTrans表中的发票交易是否余额为零来推断。具体方法是将发票金额与已结算总额进行比较。采集根据CustTrans记录推导，其中AmountCur等于SettleAmountCur。时间戳为最后一次结算日期。事件类型 inferred
	已向客户发送发票	此活动表示发票通过电子或纸质方式发送给客户的时间。在Dynamics 365中，如果通过系统邮件发送，可以记录为明确事件；如果未启用专门的跟踪功能，则可推断为发票过账时间。
重要性用于衡量发票发送流程的效率。审批完成后若未及时发送发票，会无谓地延长收款周期。获取途径如果使用D365的邮件功能，可从SysOutgoingEmailTable等邮件日志中明确获取。否则，通常将其推断为CustInvoiceJour中的发票过账时间。采集如有邮件日志，则使用其中的时间戳；否则使用发票过账时间戳。事件类型 inferred
	收到客户付款	此活动表示创建日记账分录，以记录收到的客户付款。这意味着款项已到账，但尚未核销到具体发票。
重要性这是衡量收款核销周期的起点，可区分收到款项与将款项实际核销到未结发票这两个环节。获取途径从客户付款日记账的创建或过账记录获取。相关记录可见于LedgerJournalTrans等表；过账后，系统会在CustTrans中创建客户交易。采集使用LedgerJournalTable中客户付款日记账的过账时间戳。事件类型 explicit
	收款已核销到发票	表示将客户付款结算到具体发票，从而减少发票未结余额。这是Dynamics 365中的独立步骤，用于关联付款交易和发票交易。
重要性这是准确计算DSO并了解收款核销团队效率的关键节点，标志着付款已与开票金额完成核对。获取途径记录在CustSettlement表中。该表的结算日期字段提供具体付款核销到具体发票交易的时间戳。采集使用CustSettlement表中的TransDate或CreatedDateTime。事件类型 explicit
	付款已冲销	此活动表示冲销此前已过账的客户付款。发生原因可能包括过账错误、资金不足或其他付款失败。
重要性付款冲销可能反映运营错误或客户付款问题。分析其发生频率有助于找出根本原因并提高收款核销流程的准确性。获取途径作为总账中的交易冲销记录。可在GeneralJournalEntry中识别已冲销的日记账，通常依据特定标记或其与原始交易的关联关系。采集找出带有冲销标记或引用已冲销交易的日记账分录。事件类型 explicit
	发票已提交审批	此活动表示已生成的发票已提交至正式审批工作流。要求管理层在发票发送给客户前进行审核的企业通常会采用此流程。D365工作流引擎会将其记录为一个具体步骤。
重要性跟踪审批提交时间，有助于区分发票创建耗时和等待审批耗时，也是分析内部审核与控制流程效率的第一步。获取途径从工作流历史记录表（如WorkflowTrackingStatusTable）中筛选与发票单据相关的提交事件。采集提取状态为“已提交”的工作流事件日志。事件类型 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。
**设置实体筛选条件：**为限定数据范围，请为实体设置筛选条件。至少应按InvoiceDate筛选Sales invoice headers V2，指定时间段，例如最近6个月。此外，还应筛选您要分析的特定法人实体（公司）。
**运行导出作业：**添加所有实体并设置筛选条件后，点击操作窗格中的Export按钮。系统将创建作业包，并在后台开始提取数据。
**监控并下载数据：**您可以在Job history部分查看作业进度。作业成功完成后，即可下载导出的数据包。数据包为ZIP文件，其中包含每个数据实体对应的CSV文件。
**解压数据包：**将下载的ZIP文件解压到本地文件夹。解压后，您会看到多个CSV文件，每个实体对应一个文件。
**转换并合并数据：**需要将原始文件转换为单个事件日志。您可以使用Power Query、Python或数据库暂存区等数据准备工具。对于每个源文件，请创建所需列：InvoiceNumber（案例ID）、ActivityName（表示事件的固定值，例如“发票已生成”）和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作为目标数据格式，以便与各类数据转换工具兼容。
**日期范围筛选：**务必为主要实体设置日期范围筛选，尤其要按InvoiceDate字段筛选Sales invoice headers V2。建议选择3至6个月的数据，在保证分析所需数据量的同时控制导出规模。
**公司筛选：**请按要分析的特定法人实体或公司代码筛选导出数据，以确保数据相关性并减小导出文件的体积。
**数据暂存与转换：**需要在Dynamics 365之外进行后处理。必须将导出的文件合并并转换为单个事件日志格式。通常可使用Power BI（Power Query）、Python或SQL等工具。
**前提条件：**执行导出的用户必须在Dynamics 365中拥有适当的安全角色，通常需要具备Data management工作空间权限及所需数据实体的访问权限。

查询示例 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中，前往System administration > Setup > Azure Active Directory applications，添加此应用程序ID，并为其分配读取所需数据实体的相应用户权限。
**配置脚本：**打开提供的Python脚本。填写脚本顶部的配置变量，包括d365_url、tenant_id、client_id、client_secret、company、start_date和end_date。d365_url应为Dynamics 365环境的基础URL，例如https://your-d365-instance.operations.dynamics.com。
**身份验证：**脚本中的get_access_token函数会自动使用您的凭据，从Microsoft身份平台请求OAuth2访问令牌。后续API调用需要使用此令牌进行授权。
**提取数据：**在终端中运行python your_script_name.py执行脚本。脚本首先会获取指定日期范围内所有已过账的销售发票（CustInvoiceJour）。随后，它会针对每张发票发起其他API调用，获取付款、结算、贷项通知单和工作流历史等相关活动的数据。
**生成活动：**脚本会处理来自多个API端点的原始数据，并为所需的12项活动分别生成一行数据。例如，它会使用CustInvoiceJour实体记录“发票已生成”事件，并查询CustSettlement实体生成“已核销发票款项”事件。
**计算事件：**请注意，“付款到期日已到”和“发票已结清”等事件并非Dynamics 365中的直接交易。脚本会根据发票的到期日、状态和结算历史推导这些事件，并在事件日志中创建相应记录。
**处理分页：**辅助函数fetch_all_data可自动处理分页。Dynamics 365 OData API每页返回的记录数量有限，因此该函数会根据API响应中的@odata.nextLink继续获取完整数据集。
**转换并输出数据：**收集所有事件后，脚本会将其汇总为一个列表，转换为pandas DataFrame，并将列名统一为InvoiceNumber、ActivityName、EventTime及其他所需属性。
**导出为CSV：**最后，脚本会将生成的DataFrame保存为d365_billing_event_log.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调用，提取较长时间段或大型公司的数据可能耗时较长。建议在业务低峰时段运行脚本，并先从较短的日期范围开始，以估算总运行时间。

查询示例 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()

准备好开始了吗？

使用此模板，开启优化账单与开票流程的工作。为团队提供所需洞察，提升效率并改善现金流。

返回改进指南

下载模板

告别账单延迟：立即优化订单到收款与开票流程

将账单周期时间缩短30%，更快掌握清晰的财务状况。

开始免费试用

无需信用卡。免费试用14天。

订单到收款中账单与开票流程的数据模板

订单到收款中账单与开票流程的数据模板

订单到收款中账单与开票流程的属性

订单到收款中账单与开票流程的活动

数据提取指南

Microsoft Dynamics 365数据实体导出

步骤

配置

查询示例 config

使用Dynamics 365 OData Web API的Python脚本

步骤

配置

查询示例 python

准备好开始了吗？

告别账单延迟：立即优化订单到收款与开票流程