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

您的Order-to-Cash流程：开票与发票处理数据模板

Microsoft Dynamics 365

← 返回改进指南

订单到收款－开票与发票处理属性 (18) 订单到收款－开票与发票处理活动 (12) 提取指南 (2)

您的Order-to-Cash流程：开票与发票处理数据模板

此模板为收集Order-to-Cash流程开票与发票处理分析所需的关键数据提供清晰指引。您将看到建议纳入事件日志的属性、需要跟踪的关键活动，以及提取这些信息的实用指导。借助此模板，您可以快速准备数据，开展有价值的流程挖掘。

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

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

下载模板

订单到收款－开票与发票处理属性

以下是建议纳入事件日志的数据字段，可用于全面分析订单到收款－开票与发票处理流程。

3 必需 6 建议 9 可选

	名称	说明
	发票编号 InvoiceNumber	每张客户发票的唯一标识符，是Billing流程的主要案例标识。
说明 Invoice Number是汇总单张Billing单据所有相关活动的核心键。它支持对发票生命周期进行完整的端到端分析，涵盖生成、审批、客户付款和最终关闭。将其用作Case ID后，每条事件日志记录都对应一张具体发票，从而可以详细分析流程变体、计算周期时间，并监控每笔Billing交易的绩效。为什么重要此属性对于跟踪发票完整生命周期至关重要，可支持按单张Billing单据分析流程效率、瓶颈和偏差。获取位置通常位于Sales and marketing模块中，例如CustInvoiceJour表的InvoiceId字段，或通过SalesInvoiceHeaderV2等数据实体提供。示例 CIV-001254INV-2023-9876US-004321
	事件时间 EventTime	表示特定活动或事件发生时间的精确时间戳。
说明 Event Time也称时间戳，用于记录流程中每项活动的准确日期和时间。该数据是所有基于时间的流程挖掘分析的关键。它用于计算活动之间的周期时间、衡量案例总时长，以及了解流程绩效随时间的变化。准确可靠的时间戳是应收账款周转天数和发票生成时间等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	与用户或活动关联的业务部门。
说明此属性将活动或用户归入特定组织部门，例如“应收账款”或“销售”。相比个人用户层级，它能够提供更高层级的流程绩效视图。按部门分析有助于了解跨职能交接、比较团队效率，并识别部门级瓶颈，这也是“开票部门活动负载”仪表板所需的分析维度。为什么重要支持在组织层面分析绩效、比较不同团队的效率，并了解部门间交接如何影响流程。获取位置它通常不是发票交易中的直接字段，而是将UserResponsibleID与包含部门信息的员工或用户目录连接后派生得到。示例应收账款财务开票运营
	付款条件 PaymentTerms	双方约定的发票付款条件，例如Net30、Net60。
说明付款条件规定客户应在何时支付发票。此属性用于计算付款到期日，也是分析付款行为的重要维度。“付款条件遵循分析”仪表板利用此属性对客户和发票分组，以判断某些付款条件是否更有效，或是否与更高的逾期付款率相关。为什么重要它说明发票为何在特定日期到期，并支持细分分析，以判断某些付款条件是否与逾期付款相关。获取位置它通常存储在客户主记录中，同时复制到发票抬头。请在CustInvoiceJour表中查找Payment或PaymTermId字段。示例开票后30天付款开票后60天付款收到即付
	币种 Currency	发票金额对应的币种代码，例如USD、EUR。
说明此属性指定发票金额所使用的币种。对于涉及多种货币的跨国组织而言，这一信息必不可少。缺少该背景信息，汇总或比较发票金额将失去意义。它支持正确的货币换算，以及跨地区的准确财务报告和分析。为什么重要它为Invoice Amount等财务指标提供必要背景，避免错误汇总，并支持多币种环境下的准确分析。获取位置位于CustInvoiceJour表中，通常对应CurrencyCode等字段。示例 USDEURGBP
	数据最后更新时间 LastDataUpdate	表示该事件数据最近一次从源系统刷新时间的时间戳。
说明此属性记录数据最近一次从Microsoft Dynamics 365提取或更新的时间。它是一个元数据字段，对于了解待分析数据的新鲜度至关重要。它可以帮助分析人员和业务用户确认查看的是否为最新信息，对于管理数据刷新计划和确保分析可靠性也十分重要。为什么重要它确保用户了解数据的时效性，这对于数据治理、仪表板刷新管理以及信任洞察的及时性至关重要。获取位置此属性在数据提取、转换和加载（ETL）过程中生成并写入数据集。示例 2023-06-20T05:00:00Z2023-06-21T05:00:00Z
	是否按时付款 IsOnTimePayment	用于标识客户是否在到期日当天或之前完成付款。
说明此计算得出的布尔属性将“客户付款已收取”时间戳与“付款到期日”进行比较，并将每张发票标记为按时付款或逾期付款。它是计算“按时付款率”KPI的核心，也广泛用于“付款条件遵循分析”仪表板。它以清晰的二元结果呈现付款绩效，简化分析和报告。为什么重要它直接衡量客户对付款条件的遵循情况，是“按时付款率”KPI的基础，并简化催收效果分析。获取位置源系统不提供此属性。它在数据转换过程中通过比较付款日期与PaymentDueDate计算得出。示例 truefalse
	是否返工 IsRework	用于标识发票流程是否包含返工活动，例如多次审批。
说明这是一个计算得出的布尔属性，用于标记经历过返工的发票。返工可以定义为出现多次“发票已审批”事件或付款冲销。此属性专门用于支持“发票返工分析”仪表板和“发票返工率”KPI。通过隔离这些案例，分析人员可以调查返工的根本原因，这些原因通常指向流程低效、数据质量问题或培训不足。为什么重要此标记通过识别包含重复或纠正操作的案例，直接量化流程低效程度，帮助定位浪费和延迟的根本原因。获取位置源系统不提供此属性。它在数据转换层计算，通过检查案例中的重复活动或特定返工模式得出。示例 truefalse
	未收账款天数 DaysSalesOutstanding	从生成发票到收到客户付款之间的天数。
说明未收账款天数（DSO）是重要的财务指标，用于衡量企业完成销售后收回款项所需的平均天数。此计算属性为每张发票计算该时长。它是“未收账款天数趋势分析”仪表板和“DSO”KPI的主要指标。分析DSO有助于管理现金流，并评估信用管理和催收职能的效率。为什么重要这是衡量企业现金流健康状况和催收流程效率的关键KPI，用于量化收入转化为现金的速度。获取位置源系统不提供此属性。它根据“发票已生成”活动与“客户付款已收取”活动之间的时长计算得出。示例 284592
	源系统 SourceSystem	提取数据的系统。
说明此属性用于标识流程数据的来源。在此场景中，它表示数据来自Microsoft Dynamics 365。在多系统环境中，这有助于区分数据源、确保数据血缘清晰，并支持数据验证和问题排查。为什么重要它提供有关数据来源的重要背景信息，对于数据治理、验证以及合并多个企业系统的数据至关重要。获取位置这是在数据提取和转换过程中添加的静态值，用于标记数据集来源。示例 Microsoft Dynamics 365 FinanceD365 F&O
	销售订单号 SalesOrderNumber	生成该发票的销售订单标识。
说明销售订单号将开票流程与前置销售流程关联起来，对于开展端到端Order-to-Cash分析非常有价值。分析人员可以调查销售和履约流程中的问题，例如订单变更或发货延迟，如何影响开票周期。例如，它可以帮助回答：“复杂销售订单生成的发票是否需要更长时间才能收款？” 为什么重要此属性将开票流程与上游销售流程连接起来，支持更全面的端到端Order-to-Cash分析，从而识别开票问题的根本原因。获取位置可在发票抬头或行明细中找到，并关联回销售订单。请在CustInvoiceJour表中查找SalesId等字段。示例 SO-009876SO-010234US-SO-00543
	需要人工干预 RequiresManualIntervention	用于标识收款核销过程中是否需要人工调整。
说明此布尔属性用于标记在收款核销过程中需要人工干预或纠正的付款。它是“收款核销差异率”KPI的关键依据，有助于量化过账的准确性和自动化水平。识别人工干预的原因，例如缺少汇款信息或付款差异，可以推动流程改进，提高直通式处理率。为什么重要此属性有助于识别收款核销环节中的流程阻力和错误，对于提升自动化水平、减少人工工作至关重要。获取位置可以根据过账付款的用户推断此信息（如果该用户不是系统用户），也可以根据付款对账过程中使用的特定原因代码推断。请参阅Microsoft Dynamics 365文档。示例 truefalse

必需建议可选

订单到收款－开票与发票处理活动

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

7 建议 5 可选

	活动	说明
	发票已关闭	此活动表示发票已达到最终状态，余额为零，原因是款项已全额支付或已通过贷项通知单结算。这不是直接交易，而是根据发票财务状态推断出的状态。
为什么重要此事件表示单张发票的Order to Cash周期已成功完成。达到该状态所需的时间，是衡量流程整体效率的主要指标。获取位置通过检查CustTrans表中的发票交易余额是否为零来推断。具体方法是比较发票金额与针对该发票的累计结算金额。采集从AmountCur等于SettleAmountCur的CustTrans记录推导。时间戳取最后一次结算日期。事件类型 inferred
	发票已发送给客户	此活动表示发票已通过电子或纸质方式传送给客户。在Dynamics 365中，如果通过系统邮件发送，这可以是一个明确事件；如果未启用具体跟踪，则通常可推断为发票过账时间。
为什么重要用于衡量发票交付流程的效率。审批与发票发送之间的延迟会不必要地延长付款周期。获取位置如果使用D365的邮件功能，可以从SysOutgoingEmailTable等邮件日志中明确获取。否则，通常推断其时间与CustInvoiceJour中的发票过账时间相同。采集如有可用邮件日志，则使用其时间戳；否则使用发票过账时间戳。事件类型 inferred
	发票已审批	表示内部审核流程完成，发票已正式获批。该事件由Dynamics 365工作流系统记录，表明发票已准备好发送给客户。
为什么重要这是衡量审批周期时间的重要里程碑。此阶段的延迟会直接延长客户付款所需的整体时间。获取位置记录在工作流历史表中，例如WorkflowTrackingStatusTable，作为特定发票工作流实例的完成或审批步骤。采集提取状态为“Approved”或“Completed”的工作流事件日志。事件类型 explicit
	发票已生成	表示系统中销售发票单据的创建和过账。这是Dynamics 365中的明确交易，会生成法律单据及应收账款明细账中的财务分录。
为什么重要这是发票Billing生命周期的正式起点，也是跟踪应收账款周转天数（DSO）和整体流程时长的关键事件。获取位置从CustInvoiceJour表中已过账销售发票记录的创建时间戳获取。过账时，GeneralJournalEntry和LedgerEntry表会生成相应的财务交易。采集对已过账发票使用CustInvoiceJour表中的CreatedDateTime字段。事件类型 explicit
	已到付款到期日	当发票达到到期日且付款尚未全额核销时，会发生此计算事件。该活动不对应系统中的实际交易，而是根据现有数据推导得出。
为什么重要此事件对于分析按时付款率和识别即将逾期的发票至关重要，也是触发催收活动的节点。获取位置系统不会记录此事件，而是使用CustInvoiceJour表中的DueDate字段进行计算。事件时间戳就是到期日。采集创建一个事件，其时间戳取CustInvoiceJour.DueDate字段的值。事件类型 calculated
	已收到客户付款	此活动表示创建日记账分录，用于记录收到的客户付款。这意味着已收到现金，但尚未将其核销到具体发票。
为什么重要这是衡量现金核销前置时间的起点，有助于区分收到款项与实际将款项核销到未结发票这两个环节。获取位置从客户付款日记账的创建或过账记录获取。该记录保存在LedgerJournalTrans等表中，过账后会在CustTrans中生成客户交易。采集使用LedgerJournalTable中客户付款日记账的过账时间戳。事件类型 explicit
	现金已核销至发票	表示将客户付款结算到具体发票，从而减少发票未结余额。这是Dynamics 365中的独立步骤，用于关联付款交易和发票交易。
为什么重要这是准确计算DSO并了解现金核销团队效率的关键里程碑，标志着付款已与开具的发票完成核对。获取位置记录在CustSettlement表中。该表的结算日期字段提供具体付款核销到具体发票交易时的时间戳。采集使用CustSettlement表中的TransDate或CreatedDateTime。事件类型 explicit
	付款已冲销	此活动表示此前已过账的客户付款被冲销。原因可能包括过账错误、资金不足或其他付款失败。
为什么重要付款冲销反映了运营错误或客户付款问题。分析其发生频率有助于识别根因，提升现金核销流程的准确性。获取位置作为总账中的交易冲销记录获取。可在GeneralJournalEntry中通过特定标记或与原始交易的关联关系识别冲销日记账。采集识别带有冲销标记或引用已冲销交易的日记账分录。事件类型 explicit
	发票已提交审批	此活动表示已生成的发票已提交至正式审批工作流。在发票发送给客户前需要管理层审核的组织中，这种做法十分常见。该步骤会作为特定步骤记录在D365工作流引擎中。
为什么重要跟踪审批提交时间，有助于区分发票创建时间和审批等待时间。这是分析内部审核与控制流程效率的第一步。获取位置从工作流历史表中获取，例如WorkflowTrackingStatusTable，并筛选与发票单据相关的提交事件。采集提取状态为“Submitted”的工作流事件日志。事件类型 explicit
	已发出付款提醒	表示就逾期发票向客户发送催收函或催款通知。Dynamics 365提供正式的催收流程，可生成并记录此类通信。
为什么重要跟踪提醒有助于评估催收流程的有效性，并分析收到付款前需要发送多少次提醒。获取位置这是一个明确事件，可从CustCollectionLetterJour表中催收函日记账的创建日期获取。该日记账与逾期发票交易相关联。采集使用CustCollectionLetterJour表中的创建时间戳。事件类型 explicit
	已开具贷项通知单	表示创建贷项通知单或贷项备忘录，通常用于更正Billing错误、进行价格调整或记录退货。贷项通知单本质上是一张负数发票。
为什么重要频繁开具贷项通知单可能表明订单履约或Billing流程存在系统性问题。分析贷项通知单的开具原因，是改进流程和减少收入流失的关键。获取位置这是一个明确交易，会在CustInvoiceJour表中记录为金额为负的新已过账发票，通常通过引用字段与原始发票关联。采集识别CustInvoiceJour中总金额为负的记录，并将其关联到原始发票。事件类型 explicit
	销售订单已履约	此活动表示销售订单中的货物已发运或服务已交付，并触发Billing流程。在Microsoft Dynamics 365中，通常可根据装箱单或交货单的过账记录推断该活动，该记录会改变相关销售订单行的状态。
为什么重要此事件是衡量发票生成周期时间的起点。了解履约与开票之间的延迟，有助于识别可能影响现金流的行政瓶颈。获取位置根据与销售订单关联的装箱单日记账分录创建日期推断。相关表包括CustPackingSlipJour和CustPackingSlipTrans，这些表与发票所依据的销售订单相关联。采集确定与发票关联的销售订单的最新装箱单过账日期。事件类型 inferred

建议可选

提取指南

如何从Microsoft Dynamics 365获取数据

步骤

**进入Data Management工作区：**登录Microsoft Dynamics 365 Finance and Operations。使用搜索栏查找并进入Data management工作区。这里是所有数据导入和导出操作的中心。
**创建新的导出项目：**在Data management工作区中，点击Export磁贴创建新的数据导出项目。为项目设置有意义的名称，例如ProcessMind_O2C_Billing_Export，并填写描述。
**选择目标数据格式：**在项目配置中指定Target data format。为兼容大多数数据转换工具，请选择CSV。根据需要配置格式选项，确保使用通用分隔符和文本限定符。
**添加必需的数据实体：**这是最关键的一步。您需要向项目中添加多个标准数据实体，以捕获所有必需活动。对于每个实体，点击Add entity并搜索Query/Script部分列出的实体名称。将以下实体全部添加到项目中：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（表示事件的硬编码值，例如“Invoice Generated”）和EventTime（源文件中的相关日期字段）。映射InvoiceAmount和CustomerName等其他属性。
**合并所有转换后的数据：**使用union或追加操作，将所有源文件中的转换后数据合并到一张表中。这样即可生成统一的最终事件日志，每行代表发票生命周期中的一项活动。
**上传前的最终格式处理：**确保最终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工作区权限以及所需数据实体访问权限的角色。

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中创建服务主体（App Registration）的凭据，并授予其访问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实体生成“Invoice Generated”事件，并查询CustSettlement实体创建“Cash Applied to Invoice”事件。
计算事件：请注意，“Payment Due Date Reached”和“Invoice Closed”等事件并非Dynamics 365中的直接交易。脚本根据发票到期日、状态和结算历史派生这些事件，并在事件日志中创建相应记录。
处理分页：fetch_all_data辅助函数用于自动处理分页。Dynamics 365 OData API每页返回的记录数量有限，因此该函数会根据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 Credentials：身份验证需要client_id、client_secret和tenant_id。这些凭据应属于一个对相关D365实体具有读取权限的应用程序。
Company：指定DataAreaId，即您希望从中提取数据的Dynamics 365法人实体，例如“USMF”。
Date Range：设置start_date和end_date以限定提取范围。首次分析建议选择3至6个月的数据，既便于控制数据集规模，也能覆盖足够的流程变化。
Key OData Entities：脚本主要查询以下实体：CustInvoiceJours、CustSettlements、CustTrans、CustCollectionLetterJours和WorkflowTrackingStatusTables。请确保配置的用户拥有读取所有这些实体的权限。
Performance：由于需要依次发起多次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()

准备好开始了吗？

借助此模板，开启优化开票与发票处理的旅程。用所需洞察赋能团队，提升效率并改善现金流。

返回改进指南下载模板

终结开票延迟：立即优化Order-to-Cash流程与发票处理

将开票周期缩短30%，更快实现清晰的财务洞察。

开始免费试用

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

您的Order-to-Cash流程：开票与发票处理数据模板

您的Order-to-Cash流程：开票与发票处理数据模板

订单到收款－开票与发票处理属性

订单到收款－开票与发票处理活动

提取指南

Microsoft Dynamics 365数据实体导出

步骤

配置

a 示例查询 config

使用Dynamics 365 OData Web API的Python脚本

步骤

配置

a 示例查询 python

准备好开始了吗？

终结开票延迟：立即优化Order-to-Cash流程与发票处理

您的Order-to-Cash流程：开票与发票处理数据模板

您的Order-to-Cash流程：开票与发票处理数据模板

订单到收款－开票与发票处理属性

订单到收款－开票与发票处理活动

提取指南

Microsoft Dynamics 365数据实体导出

步骤

配置

a 示例查询 config

使用Dynamics 365 OData Web API的Python脚本

步骤

配置

a 示例查询 python

准备好开始了吗？

终结开票延迟：立即优化Order-to-Cash流程与发票处理

我们重视您的隐私