您的订单到收款流程:开票与发票处理数据模板
您的订单到收款流程:开票与发票处理数据模板
- 建议收集的属性
- 需要跟踪的关键活动
- SAPS/4HANA数据提取指南
订单到收款-开票与发票处理属性
| 名称 | 说明 | ||
|---|---|---|---|
| 发票号 InvoiceNumber | 开票凭证的唯一标识符,也是开票流程的主要案件标识。 | ||
| 说明 发票号在SAP中称为开票凭证号,用于唯一标识每笔开票交易。它是连接所有相关活动的核心键,从发票创建、过账到收款和对账,均通过该字段关联。 在流程挖掘中,此属性对案件关联至关重要。所有发票号相同的事件都会归入同一个流程实例,从而能够完整、端到端地分析每张发票的开票生命周期。这有助于跟踪周期时间、识别偏差并分析每张发票的处理过程。 为什么重要 这是将所有相关开票活动连接到同一案件的基础标识,使端到端流程分析成为可能。 获取位置 SAP表:VBRK,字段:VBELN 示例 900012349000567890009012 | |||
| 事件时间 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,并按账龄报告对发票进行分组。分析到期日与实际付款日之间的偏差,有助于评估不同付款条件的有效性。 为什么重要 它设定客户付款的截止时间,对于计算按时付款率和管理应收账款至关重要。 获取位置 此日期不会直接存储,而是根据发票日期(VBRK-FKDAT)和付款条件键(VBRK-ZTERM),使用SAP标准日期确定函数计算得出。 示例 2023-04-192023-05-012023-06-17 | |||
| 区域 Region | 客户所在的地理区域。 | ||
| 说明 区域属性表示与客户地址相关的地理范围,例如州或省,通常属于客户主记录的一部分。 此属性是区域开票绩效仪表板的关键。它支持比较不同区域的周期时间、错误率和DSO等指标,从而发现流程执行、合规或效率方面的区域差异,并推动有针对性的改进和最佳实践标准化。 为什么重要 它支持比较不同地理区域的开票绩效,帮助识别区域差异并实现流程标准化。 获取位置 从客户主数据表KNA1(字段:REGIO)获取,并通过发票抬头中的付款方ID(VBRK-KUNRG)关联。 示例 CANYTXBA | |||
| 发票日期 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 | 表示活动或事件完成时间的精确时间戳。 | ||
| 说明 结束时间标志着活动完成。在流程挖掘中,它通常推断为案件中后续活动的开始时间;如果系统同时记录开始和结束事件,也可以直接获取。 此属性对于计算单项活动的处理时间至关重要。用结束时间减去开始时间,即可衡量每个步骤的持续时间,这对于瓶颈分析十分重要,例如识别发票审批阶段的延迟。 为什么重要 它支持计算每项活动的精确持续时间(处理时间),是瓶颈分析的基础。 获取位置 这是流程挖掘中的派生属性,通常计算为案件事件序列中下一事件的StartTime。在某些场景下,特定表也可能记录完成时间。 示例 2023-04-15T11:00:00Z2023-04-20T14:05:00Z2023-05-10T09:45:00Z | |||
| 上次数据更新 LastDataUpdate | 表示此事件数据上次提取或刷新的时间戳。 | ||
| 说明 此属性记录从源系统上次提取数据的日期和时间。它是一个元数据字段,对于了解所分析数据的新鲜度至关重要。 该信息用于验证分析数据的时效性并管理数据刷新计划,确保相关人员在依据流程挖掘仪表板和洞察做出决策时了解数据的及时性。 为什么重要 它表示数据的新鲜度,这对于信任分析结果并了解其与当前运营状态的相关性至关重要。 获取位置 此时间戳在数据提取和加载(ETL)过程中生成,并写入每条记录。 示例 2023-06-01T02:00:00Z2023-06-02T02:00:00Z | |||
| 争议原因 CustomerDisputeReason | 客户提出发票争议时提供的原因。 | ||
| 说明 客户对发票提出异议时,通常会记录争议原因,例如定价错误、数量不符或货物损坏。相关信息可能存储在SAP争议管理模块或文本备注中。 分析争议原因是开票错误率KPI及相关错误分析的基础。它有助于识别开票不准确的根因,使企业能够解决上游流程中的系统性问题、提高发票质量并改善客户满意度。 为什么重要 它说明客户提出发票争议的原因,直接揭示开票错误和客户不满的根本原因。 获取位置 如果使用SAP争议管理,相关信息可在UDM_DISPUTE等表中找到;否则,可能需要从相关凭证的原因代码或文本字段中推导。 示例 价格错误数量不匹配收到损坏商品 | |||
| 付款条件 PaymentTerms | 定义付款条件的代码,例如允许的付款期限。 | ||
| 说明 付款条件是与客户预先约定的条件,用于规定发票付款时间。例如,“Net 30”表示30天内付款;“2/10 Net 30”表示10天内付款可享受2%的折扣,否则应在30天内付款。 按付款条件分析有助于评估其有效性。将不同付款条件与实际收款所需时间关联,企业可以判断哪些条件最能促进及时付款,并据此优化条件以改善现金流。 为什么重要 它定义约定的付款计划,支持分析哪些条件最能确保客户及时付款。 获取位置 SAP表:VBRK,字段:ZTERM 示例 Z030Z060ZB60 | |||
| 付款状态 PaymentStatus | 发票付款的当前状态,例如未结、已付款或已逾期。 | ||
| 说明 付款状态反映发票在催收生命周期中的当前阶段。SAP中没有单独对应的字段,而是通过检查相关会计凭证的核销状态推导得出。 此属性是未结发票账龄仪表板的基础。它支持按状态和账龄对所有未结发票分组,帮助催收团队有效安排工作优先级。跟踪状态变化也有助于监控催收流程本身。 为什么重要 它以清晰直观的方式展示发票的催收状态,对于管理应收账款和安排催收优先级至关重要。 获取位置 通过检查财务表中会计凭证(VBRK-BELNR)的核销状态推导,例如BSID(未清项目)和BSAD(已核销项目)。 示例 未结已付款逾期部分付款 | |||
| 公司代码 CompanyCode | 记录财务交易的组织单位。 | ||
| 说明 公司代码是SAP财务中的基础组织实体,代表需要编制财务报表的独立法人。每个开票凭证都会分配至特定公司代码。 在多公司组织中,按公司代码分析对于比较不同法人实体的流程绩效、DSO等财务指标和合规情况至关重要。它为所有流程仪表板提供高层级的组织筛选维度。 为什么重要 它支持按法人实体划分流程分析,从而比较绩效并在整个组织内进行财务合并。 获取位置 SAP表:VBRK,字段:BUKRS 示例 10002000US01 | |||
| 开票凭证类型 BillingDocumentType | 用于对开票凭证进行分类的代码,例如发票、贷项通知单或取消凭证。 | ||
| 说明 开票凭证类型是对开票流程中交易进行分类的关键字段。它控制单据的处理方式,包括编号范围和会计过账规则。 该属性支持筛选流程,以分析特定类型的交易。例如,可以单独创建贷项通知单流程视图,了解财务更正的原因和流程;也可以将标准发票与取消单据分开分析,更清晰地了解主要开票流程。 为什么重要 它对交易进行分类,支持针对标准发票、贷项通知单或取消凭证等特定凭证流开展分析。 获取位置 SAP表:VBRK,字段:FKART 示例 F2G2S1L2 | |||
| 是否按时付款 IsPaidOnTime | 用于表示发票是否在到期日当天或之前付清的布尔标记。 | ||
| 说明 这是一个计算属性,用于比较实际付款日期与计划付款到期日。如果按时付款,结果为“true”;如果逾期付款,结果为“false”。 此标记简化了按时付款率KPI的计算和可视化。您可以轻松筛选并分组分析逾期付款和按时付款发票的特征,从而发现与特定客户、区域或付款条件相关的延迟付款模式。 为什么重要 它通过明确标记每张发票是“按时”还是“逾期”,简化绩效衡量,并直接支持按时付款率KPI。 获取位置 这是一个计算字段。其逻辑将“已收到客户付款”活动的时间戳与“PaymentDueDate”属性的值进行比较。 示例 truefalse | |||
| 源系统 SourceSystem | 标识提取数据的具体源系统。 | ||
| 说明 此属性指定数据来源,在包含多个SAP实例或其他集成系统的环境中特别有用。它通常包括系统ID和客户端编号。 在分析中,它有助于区分不同系统或组织实体中的流程和绩效。它确保数据血缘清晰,并在合并多个来源的数据以获得整体流程视图时提供必要背景。 为什么重要 它提供有关数据来源的重要背景,确保多系统环境中的信息清晰,并支持数据治理。 获取位置 通常是在数据提取期间定义的静态值,常由系统ID(SY-SYSID)和客户端(SY-MANDT)组合而成。 示例 S4H_PROD_100S4H_QAS_200ECC_PROD_300 | |||
| 货币 Currency | 发票金额使用的货币代码。 | ||
| 说明 此属性指定发票金额的计价货币,例如USD、EUR或JPY,为所有货币数值提供必要背景。 在全球化组织中,货币对于准确开展财务分析和报告至关重要。通过将所有金额换算为统一报告货币,它支持正确汇总财务数据,并可比较不同地区的开票绩效。 为什么重要 它为所有货币数值提供必要背景,确保财务分析和报告准确,尤其适用于跨国运营。 获取位置 SAP表:VBRK,字段:WAERK 示例 USDEURGBP | |||
| 贷项通知单原因 CreditMemoReason | 说明贷项通知单签发原因的原因代码。 | ||
| 说明 发票有误并需要贷项调整时,通常会为贷项通知单凭证指定原因。这为归类开票错误来源提供了结构化方式。 此属性直接支持开票错误率KPI。通过汇总和分析贷项通知单原因,企业可以识别最常见的错误类型,例如定价错误或产品退货,并据此推动流程改进,减少财务纠正和返工。 为什么重要 它对贷项原因进行分类,帮助定位最常见的开票错误来源并推动质量改进。 获取位置 SAP表:VBRK,字段:AUGRU(订单原因)。该字段用于贷项/借项通知单申请,之后会据此开票。 示例 001-价格差异002-质量不佳005-客户退货 | |||
| 销售订单号 SalesOrderNumber | 生成该发票的原始销售订单标识。 | ||
| 说明 销售订单号将开票凭证与前置销售活动关联起来。一个销售订单可以生成一张或多张发票,该关联提供完整的凭证流。 此属性对于真正的端到端订单到收款分析至关重要。它可以将流程视图向上游延伸,把开票问题与销售订单创建或履约阶段的潜在根因关联起来。例如,可从订单履约完成时开始计算整体发票生成周期时间。 为什么重要 它将发票与原始销售订单关联起来,使订单到收款流程的视图超越单纯开票环节,覆盖更广的端到端流程。 获取位置 SAP表:VBRP(开票凭证项目数据),字段:AUBEL 示例 100001231000045610000789 | |||
订单到收款-开票与发票处理活动
| 活动 | 说明 | ||
|---|---|---|---|
| 发票已关闭 | 此活动表示发票已成功付款后的最终状态。其功能上等同于“现金已核销/已对账”,表示该发票的流程已完成。 | ||
| 为什么重要 作为流程的主要“正常路径”结束事件。衡量截至此时点的总周期时间,可完整了解端到端开票与发票处理生命周期。 获取位置 根据会计凭证中客户行项目的状态推断。当核销日期(BSEG-AUGDT)和核销凭证(BSEG-AUGBL)字段已填充时,项目即被视为已关闭或“已核销”。 采集 根据BSEG/ACDOCA表中发票行项目的核销日期(AUGDT)是否已填充推断。 事件类型 inferred | |||
| 发票已生成 | 该活动表示系统中开票单据的创建。当用户执行VF01等事务,或后台作业创建发票时,系统会记录这一明确事件,并在开票单据抬头表中生成新记录。 | ||
| 为什么重要 这是开票流程的主要开始事件。分析从订单履行到该活动的耗时,对于衡量发票生成周期时间和识别流程初始延迟至关重要。 获取位置 创建时记录在SAP S/4HANA的VBRK表(Billing Document: Header Data)中。创建日期(VBRK-ERDAT)和时间(VBRK-ERZET)作为时间戳。 采集 从VBRK表中开票单据记录的创建时间戳获取该事件。 事件类型 explicit | |||
| 发票已过账至会计系统 | 表示开票单据已成功过账至财务会计模块。这是一个关键里程碑,意味着发票成为正式的应收账款项目,并在总账中生成记录。 | ||
| 为什么重要 该活动确认发票已成为合法财务单据。从生成到过账之间的时间是重要绩效指标,可反映内部处理效率。 获取位置 当对应的会计凭证创建时捕获该事件。开票单据(VBRK-VBELN)通过VBRK-BELNR与会计凭证(BKPF-BELNR)关联,过账日期为BKPF-BUDAT。 采集 从与开票单据关联的BKPF表中会计凭证的过账日期(BUDAT)获取。 事件类型 explicit | |||
| 已收到客户付款 | 该活动表示客户入账付款已过账至财务系统。此时付款可能尚未应用到具体发票,但资金已经完成记录。 | ||
| 为什么重要 这是计算应收账款周转天数(DSO)的关键里程碑,表示现金已经到账,即使对账仍在进行中。 获取位置 取自客户付款凭证的过账日期(BKPF-BUDAT),通常为BKPF表中凭证类型为“DZ”的凭证。 采集 事件基于BKPF/BSEG中付款凭证的创建。 事件类型 explicit | |||
| 现金已核销/已对账 | 表示收到的客户付款与未清发票项目匹配并用于核销应收账款明细账中未清项目的时点。从财务角度看,此活动标志着交易完成。 | ||
| 为什么重要 用于衡量现金应用流程的效率。此处的延迟可能掩盖客户账户的真实状态,并给催收团队带来不必要的工作。 获取位置 此事件通过原始发票会计凭证行项目中的核销日期(BSEG-AUGDT)捕获。清账凭证核销该项目后,系统会填充此日期。 采集 取自BSEG/ACDOCA表发票行项目中的核销日期(AUGDT)字段。 事件类型 explicit | |||
| 发票已发送给客户 | 该活动表示发票已发送给客户,例如通过打印、电子邮件或EDI发送。具体捕获方式取决于SAP中的输出管理配置。 | ||
| 为什么重要 这是从客户角度计算付款周期的正式起点。发票发送延迟会直接影响应收账款周转天数(DSO)和现金流。 获取位置 可以在输出控制表中明确记录,例如旧版方法使用NAST表,S/4HANA则使用其对应表。如果没有明确记录,通常推断该事件与“Invoice Posted To Accounting”同时发生。 采集 检查输出管理表中的处理日志,查找与发票输出类型关联的时间戳。 事件类型 explicit | |||
| 发票已取消 | 当此前创建的发票被取消时发生,通常需要创建相应的取消凭证。这实际上会冲销原始发票及其会计影响。 | ||
| 为什么重要 表示返工、纠正或开票错误。取消频率较高,通常说明销售订单录入或开票配置存在严重的上游问题。 获取位置 在创建取消开票凭证时捕获,例如凭证类型为“S1”。VBRK中的新凭证会在VBRK-SFAKN字段中引用原始发票号。 采集 事件取自VBRK中引用原始发票的取消凭证创建日期。 事件类型 explicit | |||
| 发票过账被阻止 | 如果发票已创建,但由于信用检查或数据不一致等原因被系统自动阻止过账至财务会计模块,就会发生此事件。该状态根据开票单据中的过账状态字段推断。 | ||
| 为什么重要 识别发票已创建但未立即释放至财务部门的瓶颈,这会延迟整个收款周期,也是数据质量问题或信用管理问题的重要指标。 获取位置 根据开票单据抬头表(VBRK-RFBSK)中的过账状态字段推断。例如,“A”(Billing document blocked for forwarding to FI)表示单据被阻止。 采集 检查发票生成后开票单据过账状态字段(VBRK-RFBSK)的值即可推断。 事件类型 inferred | |||
| 客户争议已发起 | 当客户针对发票提出争议,并在系统中正式登记时,就会发生此活动。这需要使用SAP Dispute Management模块。 | ||
| 为什么重要 突出显示导致付款延迟的开票准确性、产品质量或服务交付问题。分析争议原因有助于解决根因并提升客户满意度。 获取位置 在Dispute Management表(例如UDM_CASE)中创建争议案例时记录,并与会计凭证行项目关联。 采集 从与发票关联的争议案例记录创建时间戳中获取。 事件类型 explicit | |||
| 已到付款到期日 | 该计算事件表示根据约定付款条件,发票正式到期付款的日期。它不是交易事件,而是根据发票数据推导得出。 | ||
| 为什么重要 这是衡量按时付款绩效和分析客户付款行为的重要基准,有助于区分及时付款和逾期付款。 获取位置 根据付款基准日期(BSEG-ZFBDT)以及会计凭证客户行项目中存储的付款条件计算。 采集 将付款条件规定的天数加到会计凭证行项目(BSEG)中的付款基准日期上即可推导。 事件类型 calculated | |||
| 已发出付款提醒 | 表示向客户发送逾期发票的付款提醒或催款通知。这是由自动催款程序生成的明确事件。 | ||
| 为什么重要 支持分析催款流程的效果,帮助判断提醒是否能加快付款,以及哪些催款级别影响最大。 获取位置 当针对发票未结项目执行催款运行(事务F150)时,记录在催款历史表(MAHNV、MHND)中。 采集 从催款历史表中记录的催款通知运行日期获取。 事件类型 explicit | |||
| 已识别开票返工 | 用于识别返工循环的计算事件:发票被取消后,针对同一销售订单重新生成发票。它不是单笔交易,而是一组事件形成的模式。 | ||
| 为什么重要 直接支持“开票返工率”KPI,通过量化纠正次数,帮助定位低效环节并衡量开票流程的质量成本。 获取位置 通过识别“发票已取消”事件后紧接着出现的“发票已生成”事件来计算该模式,且两者都可追溯至同一源凭证,例如同一销售订单号。 采集 通过检测同一销售订单引用下“发票已取消”和“发票已生成”的事件序列推导。 事件类型 calculated | |||
| 贷项通知单已创建 | 此活动表示创建贷项通知单,用于纠正向客户多收的款项,或为退货提供贷项。它通常与原始发票关联。 | ||
| 为什么重要 突出显示开票后导致财务调整的问题。分析贷项通知单有助于发现定价错误、产品问题或其他收入流失的根本原因。 获取位置 作为新的开票凭证在VBRK中明确创建,并使用贷项通知单专用的开票类型,例如“G2”。它通常引用原始销售订单或发票。 采集 取自VBRK中创建贷项通知单开票类型的开票凭证。 事件类型 explicit | |||
提取指南
步骤
- 前提条件:确保您在SAPS/4HANA中拥有具备必要授权的用户账户,可查询CoreDataServices(CDS)视图。具体而言,您需要对I_BillingDocument、I_JournalEntryItem、I_Customer、I_Outgmgmtdocumentoutputreq、I_DisputeCase和I_DunningHistory等视图拥有读取权限。
- 访问数据提取工具:登录SAPS/4HANA系统。您可以使用多种工具对CDS视图执行SQL查询,例如SAPHANAStudio、通过SAPHANA客户端连接的DBeaver,或SAPAnalysisforMicrosoftExcel插件。本指南以标准SQL客户端为例。
- 确定系统参数:运行查询前,确定要分析的公司代码和日期范围。建议先限定范围,例如提取最近3至6个月的数据,以确保查询时间可控。
- 准备SQL查询:将本文档“query”部分提供的完整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安全团队分配相应角色和授权。此外,要捕获“CustomerDisputeOpened”或“PaymentReminderIssued”等活动,系统必须启用并实际使用SAPDisputeManagement和SAPFinancialsDunning模块。
- 性能:查询使用多个连接和联合操作。对于超大数据集,例如数年的数据,建议在业务低峰期执行,或使用更严格的筛选条件限制初始数据提取。
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; 步骤
- 确认可以直接读取包含Billing及相关财务表的SAP HANA架构。向系统负责人获取架构名称、连接信息、授权日期范围、公司代码范围、Billing文档类型以及客户或区域筛选条件。仅替换查询中的连接和筛选占位符。
- 确认目标系统中的相关SAP S/4HANA数据源及其字段映射。查询使用VBRK和VBRP获取Billing数据,并要求为会计、输出管理、争议管理、催收、收款、清账和文档关系配置相应数据源。只有根据系统数据字典完成验证后,才能替换方括号中的数据源和字段占位符。
- 使用包含起始时间戳、不包含结束时间戳的方式配置提取周期。初次运行建议选择3至6个月。按公司代码筛选,并在适用时按Billing类型筛选,以控制数据量,避免混入无关Billing流程。
- 使用只读HANA数据库用户执行查询。查询会为每项明确提取的活动创建一行事件记录,不依赖ProcessMind推断事件。包括Payment Due Date Reached和Billing Rework Identified在内的计算活动由SQL逻辑生成,并以记录形式返回。
- 验证返回架构。事件日志必须包含InvoiceNumber、ActivityName、EventTime、UserName、InvoiceDate、PaymentDueDate、InvoiceAmount、CustomerName、Region和EndTime。确认每一行都已填充InvoiceNumber、ActivityName和EventTime。
- 验证事件语义和关系。将Invoice Generated记录与Billing抬头创建数据进行比对,将Invoice Posted To Accounting记录与会计过账状态进行比对,将Invoice Sent To Customer记录与输出记录进行比对,将付款记录与会计凭证进行比对,并将清账记录与已清账发票项目进行比对。投入生产前,请检查所有依赖占位符的部分。
- 为ProcessMind标准化结果。每个事件保留一行,使用统一的时间戳数据类型和时区,将InvoiceNumber保留为文本以保留前导零,并确保ActivityName值与必需的活动名称完全一致。按InvoiceNumber和EventTime排序;如果多个事件共享同一时间戳,请使用确定性的次级排序。
- 将结果导出为UTF-8 CSV或ProcessMind支持的其他表格格式。将InvoiceNumber映射为案例标识,将ActivityName映射为活动列,将EventTime映射为事件时间戳。数据可用时包含建议属性,然后通过已配置的ProcessMind导入流程上传文件,并执行最终的行数和活动数量检查。
配置
- **日期范围:**从3至6个月开始。使用包含起始时间戳、不包含结束时间戳的方式,避免增量运行时产生重复事件。
- **案例标识:**使用开票凭证抬头中的InvoiceNumber。将其保留为字符串,因为SAP凭证编号可能包含前导零。
- **必需活动:**提取结果必须为以下活动返回明确的数据行:InvoiceGenerated、InvoicePostingBlocked、InvoicePostedToAccounting、InvoiceSentToCustomer、PaymentDueDateReached、CustomerDisputeOpened、PaymentReminderIssued、CustomerPaymentReceived、CashApplied/Reconciled、InvoiceClosed、InvoiceCancelled、CreditMemoCreated和BillingReworkIdentified。
- **筛选条件:**只有在确认目标系统中的对应字段和业务范围后,才能应用公司代码、开票凭证类型、销售组织、客户、区域和日期筛选。不要假设所有开票凭证类型都遵循相同的会计或输出流程。
- **数据源配置:**VBRK和VBRP是主要开票数据源。会计、输出、争议、催款、付款、清账和凭证流数据源必须根据已部署的SAP S/4HANA版本及启用的模块进行配置。将方括号中的数据源引用替换为已验证的对象和字段。
- **计算事件:**PaymentDueDateReached根据付款条件和到期日数据推导。BillingReworkIdentified根据取消发票及随后为同一销售订单生成新发票的模式推导。这些是由SQL生成的事件行,并非原生交易记录。
- **性能:**将日期、公司代码、开票类型和凭证编号筛选条件下推到每个数据源查询中。仅选择必需列,避免对大型会计表执行不受限连接,按月或按周分批处理,并使用数据库执行计划识别高成本连接。
- **增量提取:**使用基于源系统创建时间戳或过账时间戳的稳定水位线。重新处理一个较小的重叠时间窗口,以捕获延迟到达的输出、付款、争议和清账记录,然后使用InvoiceNumber、ActivityName、EventTime及相关源凭证键去重。
- **授权:**提取用户需要读取所选HANA架构对象和字段的权限。确认直接数据库访问符合组织安全策略,并满足个人数据或客户数据处理要求。
- **功能前提:**只有在系统中完成配置并实际使用时,才能获得输出管理、会计集成、争议管理、催款、收款和清账数据。模块或源记录缺失会导致活动缺失,不会生成推断事件。
- **时区:**将时间戳统一为ProcessMind要求的时区,并记录源时间戳存储于UTC、本地系统时间还是其他已配置时区。
a 示例查询 sql
WITH
billing_headers AS (
SELECT
h.VBELN AS InvoiceNumber,
h.FKDAT AS InvoiceDate,
h.NETWR AS InvoiceAmount,
h.KUNAG AS CustomerNumber,
h.ERDAT AS BillingCreatedDate,
h.ERZET AS BillingCreatedTime,
h.ERNAM AS BillingCreatedBy,
h.BUKRS AS CompanyCode,
h.FKART AS BillingType,
h.FKSTO AS CancellationIndicator,
h.RFBSK AS AccountingPostingStatus,
h.ZTERM AS PaymentTerms,
h.ZFBDT AS BaselineDate,
h.NETDT AS PaymentDueDate,
h.VBELV AS PrecedingDocument
FROM [Your HANA schema].VBRK h
WHERE h.ERDAT >= '[Start date, YYYY-MM-DD]'
AND h.ERDAT < '[End date, YYYY-MM-DD]'
AND h.BUKRS IN ([Company code filter])
AND h.FKART IN ([Billing document type filter])
),
customer_data AS (
SELECT
c.KUNNR AS CustomerNumber,
c.NAME1 AS CustomerName,
c.REGION AS Region
FROM [Your customer master source] c
),
invoice_base AS (
SELECT
b.InvoiceNumber,
b.InvoiceDate,
b.InvoiceAmount,
b.CustomerNumber,
c.CustomerName,
c.Region,
b.BillingCreatedDate,
b.BillingCreatedTime,
b.BillingCreatedBy,
b.CompanyCode,
b.BillingType,
b.CancellationIndicator,
b.AccountingPostingStatus,
b.PaymentTerms,
b.BaselineDate,
b.PaymentDueDate,
b.PrecedingDocument
FROM billing_headers b
LEFT JOIN customer_data c
ON c.CustomerNumber = b.CustomerNumber
),
events AS (
SELECT
i.InvoiceNumber,
'Invoice Generated' AS ActivityName,
TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime)) AS EventTime,
i.BillingCreatedBy AS UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime)) AS EndTime
FROM invoice_base i
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
COALESCE(a.StatusTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EventTime,
a.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
COALESCE(a.StatusTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EndTime
FROM invoice_base i
INNER JOIN [Your accounting status source] a
ON a.InvoiceNumber = i.InvoiceNumber
AND a.PostingStatus = '[Posting blocked status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
a.StatusTimestamp AS EventTime,
a.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
a.StatusTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounting status source] a
ON a.InvoiceNumber = i.InvoiceNumber
AND a.PostingStatus = '[Posted status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
o.SentTimestamp AS EventTime,
o.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
o.SentTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your output management source] o
ON o.InvoiceNumber = i.InvoiceNumber
AND o.OutputStatus = '[Successfully sent status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(i.PaymentDueDate AS TIMESTAMP) AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
CAST(i.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM invoice_base i
WHERE i.PaymentDueDate IS NOT NULL
UNION ALL
SELECT
i.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
d.OpenedTimestamp AS EventTime,
d.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
d.OpenedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your dispute management source] d
ON d.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
r.IssuedTimestamp AS EventTime,
r.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
r.IssuedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your dunning or payment reminder source] r
ON r.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Customer Payment Received' AS ActivityName,
p.ReceivedTimestamp AS EventTime,
p.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
p.ReceivedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your incoming payment source] p
ON p.CustomerNumber = i.CustomerNumber
AND p.CompanyCode = i.CompanyCode
AND p.ReceivedTimestamp >= TO_TIMESTAMP(TO_VARCHAR(i.InvoiceDate))
UNION ALL
SELECT
i.InvoiceNumber,
'Cash Applied/Reconciled' AS ActivityName,
cl.ClearedTimestamp AS EventTime,
cl.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
cl.ClearedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounts receivable clearing source] cl
ON cl.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Closed' AS ActivityName,
cl.ClearedTimestamp AS EventTime,
cl.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
cl.ClearedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounts receivable clearing source] cl
ON cl.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
COALESCE(x.CancellationTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EventTime,
x.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
COALESCE(x.CancellationTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EndTime
FROM invoice_base i
LEFT JOIN [Your billing cancellation or document flow source] x
ON x.InvoiceNumber = i.InvoiceNumber
WHERE i.CancellationIndicator = '[Cancellation indicator value]'
OR x.InvoiceNumber IS NOT NULL
UNION ALL
SELECT
cm.ReferenceInvoiceNumber AS InvoiceNumber,
'Credit Memo Created' AS ActivityName,
cm.CreatedTimestamp AS EventTime,
cm.UserName,
i.InvoiceDate,
i.PaymentDueDate,
cm.Amount AS InvoiceAmount,
i.CustomerName,
i.Region,
cm.CreatedTimestamp AS EndTime
FROM [Your credit memo source] cm
INNER JOIN invoice_base i
ON i.InvoiceNumber = cm.ReferenceInvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
r.ReworkTimestamp AS EventTime,
r.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
r.ReworkTimestamp AS EndTime
FROM invoice_base i
INNER JOIN (
SELECT
old_invoice.InvoiceNumber,
new_invoice.InvoiceNumber AS ReplacementInvoiceNumber,
new_invoice.BillingCreatedDate AS ReworkTimestamp,
new_invoice.BillingCreatedBy AS UserName
FROM invoice_base old_invoice
INNER JOIN invoice_base new_invoice
ON new_invoice.PrecedingDocument = old_invoice.InvoiceNumber
AND new_invoice.BillingCreatedDate > old_invoice.BillingCreatedDate
WHERE old_invoice.CancellationIndicator = '[Cancellation indicator value]'
) r
ON r.InvoiceNumber = i.InvoiceNumber
)
SELECT
InvoiceNumber,
ActivityName,
EventTime,
UserName,
InvoiceDate,
PaymentDueDate,
InvoiceAmount,
CustomerName,
Region,
EndTime
FROM events
WHERE EventTime IS NOT NULL
ORDER BY InvoiceNumber, EventTime, ActivityName; 优化订单到收款开票流程,让现金流提速30%
消除低效环节,从今天开始将开票周期缩短30%。
无需信用卡,几分钟即可开始。