您的订单到收款 - 开票与发票处理数据模板
您的订单到收款 - 开票与发票处理数据模板
- 建议收集的属性
- 需要追踪的关键活动
- SAP S/4HANA 数据提取指南
订单到收款 - 计费与开票属性
| 名称 | 描述 | ||
|---|---|---|---|
| 发票编号 InvoiceNumber | 开票凭证的唯一标识符,作为发票处理流程的主要案例标识符。 | ||
| 描述 发票号码(在 SAP 中称为开票凭证号)唯一标识每笔开票交易。它是关联所有相关活动的中心键,从发票创建、过账到收款和核销。 在流程挖掘中,该属性对于案例关联至关重要。共享相同发票号码的所有事件都被归入单个流程实例,从而实现对每份发票开票生命周期的完整端到端分析。这使得追踪周期时间、识别偏差并分析每份发票的流转过程成为可能。 为何重要 它是将所有相关计费活动连接成单个案例的基础标识符,使端到端流程分析成为可能。 获取方式 SAP 表:VBRK,字段:VBELN 示例 900012349000567890009012 | |||
| Event 时间 EventTime | 指示活动或事件发生的确切时间戳。 | ||
| 描述 “事件时间”提供每个活动发生的日期和时间,构成了流程的时间顺序骨架。该时间戳对于计算计费流程中不同步骤之间的持续时间、周期时间和等待时间至关重要。 在分析中,事件时间用于按顺序排列活动,计算关键绩效指标(如应收账款周转天数和发票生成周期时间),并识别基于时间的瓶颈。它能够实现流程的动态视图,显示性能如何随时间变化,以及计费周期的每个阶段耗时多久。 为何重要 它提供事件的时间序列,这对于计算所有基于时间的指标(如周期时间和持续时间)至关重要。 获取方式 根据活动的不同,从各种日期和时间字段中提取,例如创建日期和时间 (VBRK-ERDAT, VBRK-ERZET)、更改时间戳 (CDHDR-UDATE, CDHDR-UTIME) 或过账日期 (BKPF-BUDAT)。 示例 2023-04-15T10:30:00Z2023-04-20T14:00:00Z2023-05-10T09:15:00Z | |||
| 活动名称 ActivityName | 开票流程中发生的业务活动或事件的名称,例如“发票已生成”或“收到付款”。 | ||
| 描述 活动名称描述了开票生命周期中的特定步骤或里程碑。这些活动源自 SAP 中的各种数据点(如事务代码、凭证状态更改或特定日志条目),用于创建顺序流程流。 分析这些活动的顺序和频率是流程挖掘的核心。它有助于可视化流程图,发现常见和罕见的流程变体,识别步骤间的瓶颈,并衡量返工或取消等非增值活动的频率。 为何重要 此属性定义了流程中的步骤,从而实现流程图的可视化,并能对流程流、变体和瓶颈进行分析。 获取方式 衍生自各种来源,包括交易代码 (SY-TCODE)、更改单据状态(表 CDHDR/CDPOS)或业务工作流日志(例如 SWW_WI2OBJ)。 示例 已生成发票发票已过账至财务已收到客户付款发票已取消 | |||
| 付款到期日 PaymentDueDate | 预计客户支付发票的日期。 | ||
| 描述 付款到期日是根据发票日期和约定的付款条件计算得出的。它代表了在发票逾期前收到款项的最后期限。 该属性对于监控催收有效性和现金流预测至关重要。它直接用于计算准时付款率 KPI,并在账龄报告中对发票进行分类。分析到期日与实际付款日期之间的偏差有助于评估不同付款条件的有效性。 为何重要 它设定了客户付款的截止日期,使其对于计算准时付款率和管理应收账款至关重要。 获取方式 此日期不是直接存储的,而是使用 SAP 标准日期确定功能根据发票日期 (VBRK-FKDAT) 和付款条件键 (VBRK-ZTERM) 计算得出的。 示例 2023-04-192023-05-012023-06-17 | |||
| 区域 Region | 客户所属的地理区域。 | ||
| 描述 “地区”属性指示与客户地址关联的地理区域,例如省或直辖市。此数据通常是客户主记录的一部分。 该属性是“区域开票绩效”仪表板的关键。它允许对不同区域的周期时间、错误率和 DSO 等关键指标进行标杆分析。这种比较可以突出流程执行、合规性或效率方面的地区差异,为针对性改进和最佳实践标准化铺平道路。 为何重要 它支持对不同地理区域的计费绩效进行比较,有助于识别地区差异并使流程标准化。 获取方式 从客户主数据表 KNA1(字段:REGIO)检索,通过开票抬头中的付款人 ID (VBRK-KUNRG) 进行关联。 示例 CA纽约TXBA | |||
| 发票日期 InvoiceDate | 向客户开具发票的正式日期。 | ||
| 描述 发票日期(在 SAP 中也称为开票日期)是许多财务计算的起点。它是确定付款条件、到期日和应收账款账龄的日期。 此日期是财务分析的关键案例级属性。它是计算应收账款周转天数 (DSO) KPI 和创建未结发票账龄报告的基准,这些是管理现金流和催收的重要工具。 为何重要 它是财务计算的主要日期,作为 DSO、付款到期日和发票账龄分析的起点。 获取方式 SAP 表:VBRK,字段:FKDAT 示例 2023-03-202023-04-012023-05-18 | |||
| 发票金额 InvoiceAmount | 发票的总净值。 | ||
| 描述 该属性代表所开票货物或服务的总货币价值(不含税)。它是每份发票案例的基本财务数据点。 发票金额被广泛用于各种分析。它允许按价值对流程进行分类,例如,查看高价值发票的处理方式是否不同或是否存在更多延迟。它也是财务报告和计算未结应收账款总额的基础。 为何重要 它量化了每张发票的财务价值,支持基于价值的分析、收款优先级排序和财务影响评估。 获取方式 SAP 表:VBRK,字段:NETWR 示例 1500.0025000.50125.75 | |||
| 客户名称 CustomerName | 收到发票的客户名称。 | ||
| 描述 该属性标识开票客户的法定名称。它源自 SAP 中的中央客户主数据。 按客户分析流程可以识别特定账户的模式。例如,它可以揭示哪些客户经常迟付、哪些客户提出的争议最多,或者对谁而言开票流程效率最低。这有助于实现针对性的客户关系管理和定制的催收策略。 为何重要 它实现了以客户为中心的分析,有助于识别特定账户的付款行为、争议频率和流程低效。 获取方式 从客户主数据表 KNA1(字段:NAME1)检索,通过开票抬头中的付款人 ID (VBRK-KUNRG) 进行关联。 示例 春田发电厂Kwik-E-MartCyberdyne Systems | |||
| 用户名称 UserName | 执行该活动的员工的用户 ID。 | ||
| 描述 此属性捕获负责特定事件(如创建发票、过账凭证或清账付款)的 SAP 用户 ID。它提供了流程步骤与执行人员或团队之间的链接。 按用户名分析有助于识别高绩效人员、培训需求或工作量分配不均。这对于合规性分析也至关重要,能显示谁执行了关键活动,并有助于了解不同用户在执行相同流程时的差异。 为何重要 它将流程活动链接到特定用户,从而能够分析个人或团队层面的工作量、绩效和合规性。 获取方式 对于创建事件,此信息位于 VBRK-ERNAM。对于后续更改,可在更改历史表(如 CDHDR-USERNAME)或工作流日志中找到。 示例 CBURNSHSIMPSONLLEONARD | |||
| 结束时间 EndTime | 指示活动或事件完成的确切时间戳。 | ||
| 描述 结束时间标志着活动的完成。在流程挖掘中,这通常被推断为案例中后续活动的开始时间,或者如果系统同时记录开始和结束事件,也可以直接获取。 该属性对于计算单个活动的处理时间至关重要。通过用结束时间减去开始时间,可以测量每个步骤的时长,这对于瓶颈分析(如识别发票审批阶段的延迟)非常关键。 为何重要 它支持计算每个活动的精确持续时间(处理时间),这是瓶颈分析的基础。 获取方式 这是用于流程挖掘的派生属性。通常计算为案例序列中下一个事件的开始时间。在某些情况下,特定表可能会记录完成时间。 示例 2023-04-15T11:00:00Z2023-04-20T14:05:00Z2023-05-10T09:45:00Z | |||
| 争议原因 CustomerDisputeReason | 客户对发票提出争议时提供的理由。 | ||
| 描述 当客户对发票提出异议时,通常会记录争议原因。这可能是由于定价错误、数量不正确或货物损坏。此类信息可能存储在 SAP 争议管理模块中或作为文本备注。 分析争议原因是“开票错误率”KPI 及相关错误分析的基础。它有助于识别开票不准确的根本原因,使企业能够解决上游流程中的系统性问题,提高发票质量并提升客户满意度。 为何重要 它解释了发票产生争议的原因,直接洞察计费错误和客户不满的根本原因。 获取方式 如果使用了 SAP Dispute Management,可以在 UDM_DISPUTE 等表中找到此信息。否则,可以从相关单据上的原因代码或文本字段派生。 示例 价格错误数量不符收到损毁货物 | |||
| 付款条款 PaymentTerms | 定义付款条件的代码,例如允许付款的期限。 | ||
| 描述 付款条件是与客户约定的预设条件,规定了发票付款的到期日。例如“Net 30”(30天内付款)或“2/10 Net 30”(10天内付款可享受2%折扣,否则30天内到期)。 通过付款条件进行分析有助于评估其有效性。将不同的付款条件与实际收到款项的时间挂钩,企业可以确定哪些条款能最有效地促进准时付款,并优化条款以改善现金流。 为何重要 它定义了约定的付款计划,从而可以分析哪些条款在确保客户按时付款方面最有效。 获取方式 SAP 表:VBRK,字段:ZTERM 示例 Z030Z060ZB60 | |||
| 付款状态 PaymentStatus | 发票付款的当前状态,例如未结、已付或逾期。 | ||
| 描述 支付状态反映了发票在催收周期中所处的阶段。在 SAP 中,这并非单一字段,而是通过检查相应会计凭证的清账状态导出的。 该属性对于“未结发票账龄分析”仪表板至关重要。它能根据状态和账龄对所有未结发票进行分类,协助催收团队有效地确定工作优先级。跟踪状态间的转换也是监控催收流程的一种方式。 为何重要 它提供了发票回款状态的清晰一瞥,这对于管理应收账款和优先安排收款工作至关重要。 获取方式 通过检查财务表(如 BSID(未清项)和 BSAD(已清项))中会计凭证 (VBRK-BELNR) 的清账状态得出。 示例 未结已付款逾期部分已付 | |||
| 公司代码 CompanyCode | 记录财务交易的组织单元。 | ||
| 描述 公司代码是 SAP 财务中基本的组织实体,代表创建财务报表的独立法人公司。每份开票凭证都分配给特定的公司代码。 在跨国或多公司组织中,按公司代码分析对于比较不同法人实体的流程绩效、财务指标(如 DSO)和合规性至关重要。它为所有流程仪表板提供了一个高层级的组织过滤器。 为何重要 它允许按法律实体对流程分析进行细分,从而在整个组织内进行绩效比较和财务合并。 获取方式 SAP 表:VBRK,字段:BUKRS 示例 10002000US01 | |||
| 最后数据更新 LastDataUpdate | 指示此事件数据上次提取或刷新的时间戳。 | ||
| 描述 该属性记录了从源系统上次拉取数据的时间。这是一个元数据字段,对于了解所分析数据的时效性至关重要。 此信息用于验证分析的最新性并管理数据刷新计划。它确保利益相关者在根据流程挖掘仪表板和见解做出决策时,清楚数据的时效性。 为何重要 它指示了数据的实时性,这对于信任分析结果并理解其与当前运营状态的相关性至关重要。 获取方式 此时间戳在数据提取和加载 (ETL) 过程中生成并标记到每个记录上。 示例 2023-06-01T02:00:00Z2023-06-02T02:00:00Z | |||
| 处理时间 ProcessingTime | 活动的持续时间,从其开始时间到结束时间计算。 | ||
| 描述 处理时间衡量的是实际执行任务所花费的时间,不包括任务间的等待时间。计算方法是活动的结束时间与开始时间之差。 这一计算指标是性能分析的基石。它被用于“发票审批瓶颈分析”等仪表板中,以量化特定步骤的耗时。某些活动的处理时间过长可能意味着效率低下、流程复杂或需要自动化。 为何重要 它衡量流程步骤的活动持续时间,有助于识别作为优化或自动化首选候选对象的低效活动。 获取方式 计算指标,在数据转换过程中通过“结束时间”减去“开始时间”得出。 示例 PT30MPT5MPT1H15M | |||
| 是否按时付款 IsPaidOnTime | 一个布尔标志,指示发票是否在到期日或之前支付。 | ||
| 描述 这是一个计算属性,用于比较实际付款日期与预定的付款到期日。如果付款准时,则结果为“true”,如果逾期,则为“false”。 该标志简化了“准时付款率”KPI 的计算和可视化。它允许轻松进行过滤和分类,以分析逾期支付发票与准时支付发票的特征。这有助于发现导致延迟付款的特定客户、区域或付款条件相关的模式。 为何重要 它通过将每张发票清晰地标记为“准时”或“逾期”来简化绩效衡量,直接支持准时付款率 KPI。 获取方式 这是一个计算字段。逻辑是将“收到客户付款”活动的时间戳与“PaymentDueDate”属性中的值进行比较。 示例 truefalse | |||
| 源系统 SourceSystem | 标识提取数据的特定源系统。 | ||
| 描述 该属性指定数据的来源,这在具有多个 SAP 实例或其他集成系统的环境中特别有用。它通常包括系统 ID 和集团编号。 在分析中,它有助于区分不同系统或组织实体的流程和绩效。它确保了数据血缘并提供了上下文,尤其是在合并来自多个来源的数据以获得整体流程视图时。 为何重要 它提供了有关数据来源的关键背景,确保了多系统环境下的清晰度并支持数据治理。 获取方式 这通常是在数据提取期间定义的静态值,通常结合了系统 ID (SY-SYSID) 和集团号 (SY-MANDT)。 示例 S4H_PROD_100S4H_QAS_200ECC_PROD_300 | |||
| 计费单据类型 BillingDocumentType | 对计费单据进行分类的代码,例如发票、贷记通知单或冲销单。 | ||
| 描述 开票凭证类型是开票流程中对交易进行分类的关键字段。它控制凭证的处理方式,包括编号范围和会计过账规则。 该属性允许过滤流程以分析特定类型的交易。例如,可以为贷项凭证创建单独的流程视图,以了解财务冲销的原因和流程流,或者将标准发票与取消凭证分开分析,以更清晰地了解主要的开票流程。 为何重要 它对交易进行分类,从而能够针对特定单据流(如标准发票、贷记通知单或冲销单)进行重点分析。 获取方式 SAP 表:VBRK,字段:FKART 示例 F2G2S1L2 | |||
| 货币 Currency | 发票金额的货币代码。 | ||
| 描述 该属性指定发票金额的货币单位(如 USD、EUR 或 JPY)。它为所有货币价值提供了必要的上下文。 在跨国组织中,货币对于正确的财务分析和报告至关重要。它允许通过将所有金额转换为统一的报告货币来进行财务数据的正确汇总,并能够比较不同本币地区的开票绩效。 为何重要 它为所有货币价值提供了必要的背景,确保了准确的财务分析和报告,尤其是在跨国运营中。 获取方式 SAP 表:VBRK,字段:WAERK 示例 美元EURGBP | |||
| 贷记通知单原因 CreditMemoReason | 指示开具贷项凭证原因的理由代码。 | ||
| 描述 当发票有误且需要冲销时,通常会为贷项凭证分配一个原因。这提供了一种结构化的方式来对开票错误的来源进行分类。 该属性直接支持“开票错误率”KPI。通过汇总和分析贷项凭证的原因,公司可以识别最常见的错误类型,如定价错误或退货。此类分析推动了旨在减少财务更正和返工需求的流程改进。 为何重要 它对发布贷记的原因进行分类,有助于精准定位最常见的计费错误来源并推动质量改进。 获取方式 SAP 表:VBRK,字段:AUGRU(订单原因)。此字段用于随后开票的贷项/借项凭证请求。 示例 001 - 价格差异002 - 质量问题005 - 客户退货 | |||
| 销售订单编号 SalesOrderNumber | 导致该发票生成的原始销售订单标识符。 | ||
| 描述 销售订单号将开票凭证链接回之前的销售活动。一个销售订单可能会产生一张或多张发票,此链接提供了完整的凭证流。 该属性对于真正的端到端订单到收款分析至关重要。它允许将流程视图向上游延伸,将开票问题与其在销售订单创建或履约阶段的潜在根本原因联系起来。例如,它有助于计算从订单履行开始的整体发票生成周期。 为何重要 它将发票链接到原始销售订单,从而实现超出计费范畴的更广泛的、端到端的订单到收款流程视图。 获取方式 SAP 表:VBRP(开票凭证行项目数据),字段:AUBEL 示例 100001231000045610000789 | |||
订单到收款 - 计费与开票活动
| 活动 | 描述 | ||
|---|---|---|---|
| 发票已结案 | 此活动表示成功支付发票的最终状态。它在功能上与“现金已应用/已核销”相同,表示该发票的流程已完成。 | ||
| 为何重要 作为流程主要的“理想路径”结束事件。衡量到此点为止的总周期时间,可提供端到端开票与发票处理生命周期的完整视图。 获取方式 从会计凭证中的客户行项目状态推断。当清账日期 (BSEG-AUGDT) 和清账凭证 (BSEG-AUGBL) 字段被填充时,该项目即为关闭或“已结清”。 捕获 通过发票行项目的 BSEG/ACDOCA 表中清账日期 (AUGDT) 的填充情况推断。 事件类型 inferred | |||
| 发票已过账至财务 | 代表开票凭证成功过账到财务会计模块。这是一个关键里程碑,标志着发票正式成为应收账款项目,并在总账中生成分录。 | ||
| 为何重要 此活动确认发票是合法的财务凭证。生成与过账之间的时间是一个关键绩效指标,突出了内部处理效率。 获取方式 此事件在创建相应会计凭证时捕获。开票凭证 (VBRK-VBELN) 通过 VBRK-BELNR 链接到会计凭证 (BKPF-BELNR),过账日期为 BKPF-BUDAT。 捕获 从与计费单据关联的 BKPF 表中的会计凭证过账日期 (BUDAT) 获取。 事件类型 explicit | |||
| 已收到客户付款 | 此活动标志着来自客户的入账付款已过账到财务系统。在此阶段,付款可能尚未应用到特定发票,但资金已被记录。 | ||
| 为何重要 计算应收账款周转天数 (DSO) 的关键里程碑。它表示已收到现金,即使对账仍在进行中。 获取方式 从客户付款凭证的过账日期 (BKPF-BUDAT) 中获取(在 BKPF 表中通常凭证类型为 'DZ')。 捕获 事件基于 BKPF/BSEG 中付款凭证的创建。 事件类型 explicit | |||
| 已生成发票 | 此活动标志着系统中开票凭证的创建。当用户执行 VF01 等事务或后台作业创建发票时,会捕获此明确事件,从而在开票凭证抬头表中生成新条目。 | ||
| 为何重要 这是开票流程的主要起始事件。分析从订单履行到此活动的时间,对于衡量发票生成周期时间及识别初始流程延迟至关重要。 获取方式 在创建时记录在 SAP S/4HANA VBRK 表(开票凭证:抬头数据)中。创建日期 (VBRK-ERDAT) 和时间 (VBRK-ERZET) 作为时间戳。 捕获 事件从表 VBRK 中计费单据记录的创建时间戳捕获。 事件类型 explicit | |||
| 收款已核销/对账 | 代表客户付款与发票匹配并用于结清应收账款明细分类账中未结发票项目的时刻。从财务角度来看,此活动标志着交易完成。 | ||
| 为何重要 衡量现金核销流程的效率。此处的延迟可能会误导客户账户的真实状态,并为催收团队带来不必要的工作。 获取方式 此事件由原始发票会计凭证行项目上的清账日期 (BSEG-AUGDT) 捕获。当清账凭证结清该项目时,将填充此日期。 捕获 从发票行项目的 BSEG/ACDOCA 表中的清账日期 (AUGDT) 字段获取。 事件类型 explicit | |||
| 发票已发送给客户 | 此活动标志着发票何时发送给客户(例如通过打印、电子邮件或 EDI)。捕获机制取决于 SAP 中的输出管理配置。 | ||
| 为何重要 从客户角度来看的正式付款起算点。发票发送延迟会直接影响应收账款周转天数 (DSO) 和现金流。 获取方式 可以在输出控制表(如旧方法的 NAST 或其 S/4HANA 等效表)中明确记录。如果没有明确记录,通常推断其与“发票已记入财务”同时发生。 捕获 检查输出管理表中的处理日志,获取与发票输出类型关联的时间戳。 事件类型 explicit | |||
| 发票已取消 | 当之前创建的发票被取消时发生,通常涉及创建一个相应的冲销单据。这有效地撤销了原始发票及其财务影响。 | ||
| 为何重要 表示存在返工、更正或计费错误。高频率的冲销指向销售订单录入或计费配置中存在的重大上游问题。 获取方式 在创建冲销计费单据(例如单据类型 'S1')时捕获。VBRK 中的这个新单据将引用 VBRK-SFAKN 字段中的原始发票号码。 捕获 事件从引用原始发票的 VBRK 中冲销单据的创建日期捕获。 事件类型 explicit | |||
| 发票过账已冻结 | 如果发票已创建,但由于信用检查或数据不一致等原因自动被阻止过账到财务会计,则会发生此事件。此状态是从开票凭证上的过账状态字段推断出来的。 | ||
| 为何重要 识别发票已创建但未立即释放到财务的瓶颈,这会延迟整个收款周期。它是数据质量问题或信用管理问题的关键指标。 获取方式 从计费单据抬头表 (VBRK-RFBSK) 中的过账状态字段推断。如 'A'(计费单据因转发至财务而冻结)等状态表示存在冻结。 捕获 通过在发票生成后立即检查过账状态字段 (VBRK-RFBSK) 的值来推断。 事件类型 inferred | |||
| 客户争议已开启 | 当客户对发票提出争议时会发生此活动,该争议随后会正式记录在系统中。这需要使用 SAP 争议管理模块。 | ||
| 为何重要 突出显示导致付款延迟的计费准确性、产品质量或服务交付问题。分析争议原因有助于解决根本原因并提高客户满意度。 获取方式 在争议管理表(如 UDM_CASE)中创建争议案例时记录,并链接到会计凭证行项目。 捕获 从与发票关联的争议案例记录的创建时间戳中获取。 事件类型 explicit | |||
| 已到付款截止日期 | 一个计算出的事件,代表根据约定的付款条件发票正式到期的日期。它不是一个交易事件,而是从发票数据中衍生出来的。 | ||
| 为何重要 这为衡量准时付款绩效和分析客户付款行为提供了关键基准,有助于区分准时付款和逾期付款。 获取方式 根据付款基准日期 (BSEG-ZFBDT) 和存储在会计凭证客户行项目中的付款条件计算得出。 捕获 通过将会计凭证行项目 (BSEG) 中的基准付款日期加上付款天数得出。 事件类型 calculated | |||
| 已发布付款催收 | 代表向客户发送逾期发票的付款提醒或催款通知。这是由自动催款程序生成的明确事件。 | ||
| 为何重要 支持对催收流程有效性的分析。它有助于确定催收提醒是否加速了回款,以及哪些催收级别最具影响力。 获取方式 当针对发票的未结项目执行催款运行(事务码 F150)时,记录在催款历史表(MAHNV、MHND)中。 捕获 从催收历史记录表中记录的催收通知运行日期获取。 事件类型 explicit | |||
| 已识别计费返工 | 一个计算出的事件,用于识别返工循环,即一张发票被取消,然后针对同一销售订单生成了新发票。这不是单次交易,而是一种事件模式。 | ||
| 为何重要 通过量化更正实例,直接支持“计费返工率”KPI。这有助于查明效率低下的环节,并衡量计费流程中因质量不佳而产生的成本。 获取方式 此模式是通过识别“发票已取消”事件,随后出现新的“发票已生成”事件,且两者都可追溯到同一个源单据(如销售订单号)来计算的。 捕获 通过检测同一销售订单引用下出现的“发票已取消”和“发票已生成”序列派生得出。 事件类型 calculated | |||
| 贷项通知单已创建 | 此活动代表贷项凭证的创建,开具给客户以纠正多收费或为退货提供退款。它通常与原始发票相关联。 | ||
| 为何重要 突出显示计费后导致财务调整的问题。通过分析贷记通知单,可以发现定价错误、产品问题或其他导致收入流失的根本原因。 获取方式 (在 VBRK 中)显式创建为具有特定贷记通知单计费类型(如 'G2')的新计费单据。它通常引用原始销售订单或发票。 捕获 从 VBRK 中创建的贷记通知单类型的计费单据中获取。 事件类型 explicit | |||
提取指南
步骤
- 前提条件:确保您在 SAP S/4HANA 中拥有具有查询核心数据服务 (CDS) 视图所需权限的用户账号。具体而言,您需要对 I_BillingDocument、I_JournalEntryItem、I_Customer、I_Outgmgmtdocumentoutputreq、I_DisputeCase 和 I_DunningHistory 等视图的读取权限。
- 访问数据提取工具:登录您的 SAP S/4HANA 系统。您可以使用各种工具对 CDS 视图执行 SQL 查询,例如 SAP HANA Studio、通过 SAP HANA 客户端连接的 DBeaver,或 SAP Analysis for Microsoft Excel 插件。在本指南中,我们假设使用标准 SQL 客户端。
- 确定系统参数:在运行查询之前,确定分析所需的特定公司代码和相关日期范围。建议从较小的范围开始,例如过去 3 到 6 个月的数据,以确保查询执行时间可控。
- 准备 SQL 查询:将本文档“查询”部分提供的完整 SQL 查询复制到您选择的 SQL 客户端中。
- 自定义占位符:修改查询中的占位符值。将
'YYYY-MM-DD'替换为您所需的开始和结束日期。将'XXXX'替换为您的目标公司代码。您可能还需要根据系统配置调整贷记通知单单据类型的占位符,例如'G2'。 - 执行查询:在 SAP S/4HANA 数据库上运行修改后的 SQL 查询。执行时间将取决于所选日期范围内的数据量。
- 检查结果:查询完成后,检查输出结果。结果集应为一个扁平表,其中每行代表计费流程中的一个活动。这就是您的事件日志。
- 数据转换(如果需要):该查询旨在生成整洁的事件日志格式。但是,请检查时间戳格式,确保其与您的流程挖掘工具兼容。查询使用
ABAP_SYSTEM_UTCL_TO_TIMESTAMP转换为标准 UTC 时间戳,这通常具有广泛的兼容性。 - 导出事件日志:将 SQL 客户端中的完整结果集导出为 CSV 文件。确保文件采用 UTF-8 编码,以防止字符显示问题。
- 上传到 ProcessMind:将生成的 CSV 文件上传到 ProcessMind 平台,将文件中的列(如 InvoiceNumber、ActivityName 和 EventTime)映射到工具中的对应字段。
配置
- 日期范围:在初始公用表表达式 (CTE) 的
WHERE子句中设置开始和结束日期。建议初次分析时选择 3 到 6 个月的时间范围,以平衡数据量和性能。过滤条件基于BillingDocumentDate。 - 公司代码:按一个或多个
CompanyCode值进行过滤,将提取范围限制在相关的法人实体内。这是管理数据范围的关键过滤条件。 - 单据类型:查询包含基于
BillingDocumentType识别贷记通知单的逻辑。您必须配置占位符,例如('G2', 'CR'),包含您组织中用于贷记通知单的特定单据类型。 - 前提条件:必须拥有底层 CDS 视图的访问权限。这需要您的 SAP 安全团队分配特定的角色和权限。此外,对于“已开启客户争议”或“已发布付款催收”等活动,系统中必须积极使用相应的 SAP 模块(SAP Dispute Management 和 SAP Financials Dunning)。
- 性能:查询使用了多个连接 (join) 和联合 (union)。对于极大数据集(例如数年的数据),请考虑在非高峰时段执行,或应用更严格的过滤条件来限制初始数据拉取。
a 查询示例 sql
WITH BaseInvoices AS (
SELECT
bd.BillingDocument AS InvoiceNumber,
bd.CreationDateTime,
bd.BillingDocumentDate AS InvoiceDate,
bd.NetDueDate AS PaymentDueDate,
bd.TotalNetAmount AS InvoiceAmount,
bd.CreatedByUser AS UserName,
bd.SDDocumentPostingStatus,
bd.AccountingDocument,
bd.IsCancelled,
bd.CancelledBillingDocument,
bd.PrecedingSDDocument,
bd.CompanyCode,
bd.BillingDocumentType,
cust.CustomerName,
reg.RegionName AS Region
FROM I_BillingDocument AS bd
LEFT JOIN I_Customer AS cust ON bd.SoldToParty = cust.Customer
LEFT JOIN I_Region AS reg ON cust.Region = reg.Region
WHERE
bd.BillingDocumentDate BETWEEN '2023-01-01' AND '2023-12-31' -- Placeholder: Set your date range
AND bd.CompanyCode = 'XXXX' -- Placeholder: Set your Company Code
AND bd.BillingCategory IN ('M', 'N', 'O', 'P', 'U', 'V', '5', '6') -- Filters for customer invoices/credit memos
)
-- 1. Invoice Generated
SELECT
bi.InvoiceNumber,
'Invoice Generated' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
UNION ALL
-- 2. Invoice Posting Blocked
SELECT
bi.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.SDDocumentPostingStatus = 'A' -- A = Billing document blocked for posting
UNION ALL
-- 3. Invoice Posted To Accounting
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EventTime,
je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntry AS je ON bi.AccountingDocument = je.AccountingDocument
WHERE bi.AccountingDocument IS NOT NULL AND bi.AccountingDocument <> ''
UNION ALL
-- 4. Invoice Sent To Customer
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EventTime,
om.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_Outgmgmtdocumentoutputreq AS om ON bi.InvoiceNumber = om.SenderBusinessObject
WHERE om.OutputRequestStatus = 'S' -- Status 'S' for 'Successfully Processed'
UNION ALL
-- 5. Payment Due Date Reached
SELECT
bi.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EventTime,
'System' AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.PaymentDueDate IS NOT NULL AND bi.PaymentDueDate <= CURRENT_DATE
UNION ALL
-- 6. Customer Dispute Opened
SELECT DISTINCT
bi.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EventTime,
dc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_DisputedItem AS di ON bi.InvoiceNumber = di.BillingDocument
JOIN I_DisputeCase AS dc ON di.DisputeCase = dc.DisputeCase
UNION ALL
-- 7. Payment Reminder Issued
SELECT DISTINCT
bi.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EventTime,
dh.DunningRunUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.CompanyCode = jei.CompanyCode
JOIN I_DunningHistory AS dh ON jei.CompanyCode = dh.CompanyCode AND jei.Customer = dh.Customer AND jei.AccountingDocument = dh.AccountingDocument
UNION ALL
-- 8, 9, 10. Payment Received, Cash Applied/Reconciled, Invoice Closed
SELECT
bi.InvoiceNumber,
ActivityName,
EventTime,
clearing_je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
EventTime AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.Customer IS NOT NULL
JOIN I_JournalEntry AS clearing_je ON jei.ClearingJournalEntry = clearing_je.AccountingDocument
CROSS JOIN (
VALUES ('Customer Payment Received'), ('Cash Applied/Reconciled'), ('Invoice Closed')
) AS Activities(ActivityName)
WHERE jei.ClearingDate IS NOT NULL AND jei.ClearingJournalEntry IS NOT NULL AND jei.ClearingJournalEntry <> ''
UNION ALL
-- 11. Invoice Cancelled
SELECT
bi.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EventTime,
cancellation_doc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X'
UNION ALL
-- 12. Credit Memo Created
SELECT
bi.InvoiceNumber,
'Credit Memo Created' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.BillingDocumentType IN ('G2') -- Placeholder: Adjust with your credit memo document types
UNION ALL
-- 13. Billing Rework Identified
WITH CancelledInvoices AS (
SELECT
bi.PrecedingSDDocument,
bi.CompanyCode,
cancellation_doc.CreationDateTime AS CancellationTime
FROM BaseInvoices bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X' AND bi.PrecedingSDDocument IS NOT NULL AND bi.PrecedingSDDocument <> ''
)
SELECT
rework.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EventTime,
rework.UserName,
rework.InvoiceDate,
rework.PaymentDueDate,
rework.InvoiceAmount,
rework.CustomerName,
rework.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EndTime
FROM BaseInvoices AS rework
JOIN CancelledInvoices AS cancelled ON rework.PrecedingSDDocument = cancelled.PrecedingSDDocument
AND rework.CompanyCode = cancelled.CompanyCode
WHERE rework.CreationDateTime > cancelled.CancellationTime AND rework.IsCancelled = ''
ORDER BY InvoiceNumber, EventTime; 步骤
- 前提条件:确保您在 SAP S/4HANA 中拥有具有查询核心数据服务 (CDS) 视图所需权限的用户账号。具体而言,您需要对 I_BillingDocument、I_JournalEntryItem、I_Customer、I_Outgmgmtdocumentoutputreq、I_DisputeCase 和 I_DunningHistory 等视图的读取权限。
- 访问数据提取工具:登录您的 SAP S/4HANA 系统。您可以使用各种工具对 CDS 视图执行 SQL 查询,例如 SAP HANA Studio、通过 SAP HANA 客户端连接的 DBeaver,或 SAP Analysis for Microsoft Excel 插件。在本指南中,我们假设使用标准 SQL 客户端。
- 确定系统参数:在运行查询之前,确定分析所需的特定公司代码和相关日期范围。建议从较小的范围开始,例如过去 3 到 6 个月的数据,以确保查询执行时间可控。
- 准备 SQL 查询:将本文档“查询”部分提供的完整 SQL 查询复制到您选择的 SQL 客户端中。
- 自定义占位符:修改查询中的占位符值。将
'YYYY-MM-DD'替换为您所需的开始和结束日期。将'XXXX'替换为您的目标公司代码。您可能还需要根据系统配置调整贷记通知单单据类型的占位符,例如'G2'。 - 执行查询:在 SAP S/4HANA 数据库上运行修改后的 SQL 查询。执行时间将取决于所选日期范围内的数据量。
- 检查结果:查询完成后,检查输出结果。结果集应为一个扁平表,其中每行代表计费流程中的一个活动。这就是您的事件日志。
- 数据转换(如果需要):该查询旨在生成整洁的事件日志格式。但是,请检查时间戳格式,确保其与您的流程挖掘工具兼容。查询使用
ABAP_SYSTEM_UTCL_TO_TIMESTAMP转换为标准 UTC 时间戳,这通常具有广泛的兼容性。 - 导出事件日志:将 SQL 客户端中的完整结果集导出为 CSV 文件。确保文件采用 UTF-8 编码,以防止字符显示问题。
- 上传到 ProcessMind:将生成的 CSV 文件上传到 ProcessMind 平台,将文件中的列(如 InvoiceNumber、ActivityName 和 EventTime)映射到工具中的对应字段。
配置
- 日期范围:在初始公用表表达式 (CTE) 的
WHERE子句中设置开始和结束日期。建议初次分析时选择 3 到 6 个月的时间范围,以平衡数据量和性能。过滤条件基于BillingDocumentDate。 - 公司代码:按一个或多个
CompanyCode值进行过滤,将提取范围限制在相关的法人实体内。这是管理数据范围的关键过滤条件。 - 单据类型:查询包含基于
BillingDocumentType识别贷记通知单的逻辑。您必须配置占位符,例如('G2', 'CR'),包含您组织中用于贷记通知单的特定单据类型。 - 前提条件:必须拥有底层 CDS 视图的访问权限。这需要您的 SAP 安全团队分配特定的角色和权限。此外,对于“已开启客户争议”或“已发布付款催收”等活动,系统中必须积极使用相应的 SAP 模块(SAP Dispute Management 和 SAP Financials Dunning)。
- 性能:查询使用了多个连接 (join) 和联合 (union)。对于极大数据集(例如数年的数据),请考虑在非高峰时段执行,或应用更严格的过滤条件来限制初始数据拉取。
a 查询示例 sql
WITH BaseInvoices AS (
SELECT
bd.BillingDocument AS InvoiceNumber,
bd.CreationDateTime,
bd.BillingDocumentDate AS InvoiceDate,
bd.NetDueDate AS PaymentDueDate,
bd.TotalNetAmount AS InvoiceAmount,
bd.CreatedByUser AS UserName,
bd.SDDocumentPostingStatus,
bd.AccountingDocument,
bd.IsCancelled,
bd.CancelledBillingDocument,
bd.PrecedingSDDocument,
bd.CompanyCode,
bd.BillingDocumentType,
cust.CustomerName,
reg.RegionName AS Region
FROM I_BillingDocument AS bd
LEFT JOIN I_Customer AS cust ON bd.SoldToParty = cust.Customer
LEFT JOIN I_Region AS reg ON cust.Region = reg.Region
WHERE
bd.BillingDocumentDate BETWEEN '2023-01-01' AND '2023-12-31' -- Placeholder: Set your date range
AND bd.CompanyCode = 'XXXX' -- Placeholder: Set your Company Code
AND bd.BillingCategory IN ('M', 'N', 'O', 'P', 'U', 'V', '5', '6') -- Filters for customer invoices/credit memos
)
-- 1. Invoice Generated
SELECT
bi.InvoiceNumber,
'Invoice Generated' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
UNION ALL
-- 2. Invoice Posting Blocked
SELECT
bi.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.SDDocumentPostingStatus = 'A' -- A = Billing document blocked for posting
UNION ALL
-- 3. Invoice Posted To Accounting
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EventTime,
je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntry AS je ON bi.AccountingDocument = je.AccountingDocument
WHERE bi.AccountingDocument IS NOT NULL AND bi.AccountingDocument <> ''
UNION ALL
-- 4. Invoice Sent To Customer
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EventTime,
om.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_Outgmgmtdocumentoutputreq AS om ON bi.InvoiceNumber = om.SenderBusinessObject
WHERE om.OutputRequestStatus = 'S' -- Status 'S' for 'Successfully Processed'
UNION ALL
-- 5. Payment Due Date Reached
SELECT
bi.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EventTime,
'System' AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.PaymentDueDate IS NOT NULL AND bi.PaymentDueDate <= CURRENT_DATE
UNION ALL
-- 6. Customer Dispute Opened
SELECT DISTINCT
bi.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EventTime,
dc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_DisputedItem AS di ON bi.InvoiceNumber = di.BillingDocument
JOIN I_DisputeCase AS dc ON di.DisputeCase = dc.DisputeCase
UNION ALL
-- 7. Payment Reminder Issued
SELECT DISTINCT
bi.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EventTime,
dh.DunningRunUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.CompanyCode = jei.CompanyCode
JOIN I_DunningHistory AS dh ON jei.CompanyCode = dh.CompanyCode AND jei.Customer = dh.Customer AND jei.AccountingDocument = dh.AccountingDocument
UNION ALL
-- 8, 9, 10. Payment Received, Cash Applied/Reconciled, Invoice Closed
SELECT
bi.InvoiceNumber,
ActivityName,
EventTime,
clearing_je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
EventTime AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.Customer IS NOT NULL
JOIN I_JournalEntry AS clearing_je ON jei.ClearingJournalEntry = clearing_je.AccountingDocument
CROSS JOIN (
VALUES ('Customer Payment Received'), ('Cash Applied/Reconciled'), ('Invoice Closed')
) AS Activities(ActivityName)
WHERE jei.ClearingDate IS NOT NULL AND jei.ClearingJournalEntry IS NOT NULL AND jei.ClearingJournalEntry <> ''
UNION ALL
-- 11. Invoice Cancelled
SELECT
bi.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EventTime,
cancellation_doc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X'
UNION ALL
-- 12. Credit Memo Created
SELECT
bi.InvoiceNumber,
'Credit Memo Created' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.BillingDocumentType IN ('G2') -- Placeholder: Adjust with your credit memo document types
UNION ALL
-- 13. Billing Rework Identified
WITH CancelledInvoices AS (
SELECT
bi.PrecedingSDDocument,
bi.CompanyCode,
cancellation_doc.CreationDateTime AS CancellationTime
FROM BaseInvoices bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X' AND bi.PrecedingSDDocument IS NOT NULL AND bi.PrecedingSDDocument <> ''
)
SELECT
rework.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EventTime,
rework.UserName,
rework.InvoiceDate,
rework.PaymentDueDate,
rework.InvoiceAmount,
rework.CustomerName,
rework.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EndTime
FROM BaseInvoices AS rework
JOIN CancelledInvoices AS cancelled ON rework.PrecedingSDDocument = cancelled.PrecedingSDDocument
AND rework.CompanyCode = cancelled.CompanyCode
WHERE rework.CreationDateTime > cancelled.CancellationTime AND rework.IsCancelled = ''
ORDER BY InvoiceNumber, EventTime;