您的订单到收款 - 开票数据模板
您的订单到收款 - 开票数据模板
- 建议收集的属性
- 建议跟踪的关键活动
- SAP S/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 | |||
| 发票日期 InvoiceDate | 发票正式开具给客户的日期。 | ||
| 说明 发票日期在SAP中也称为账单日期,是许多财务计算的起点。付款条款、到期日和应收账款账龄均以此日期为依据。 此日期是财务分析中的关键案例级属性,也是计算应收账款周转天数(DSO)KPI和生成未结发票账龄报告的基准。这些报告对于管理现金流和催收工作至关重要。 重要性 此日期是财务计算的主要依据,也是计算DSO、付款到期日和发票账龄分析的起点。 获取途径 SAP表:VBRK,字段:FKDAT 示例 2023-03-202023-04-012023-05-18 | |||
| 发票金额 InvoiceAmount | 发票的净总额。 | ||
| 说明 此属性表示所开具商品或服务的货币总额,不含税,是每个发票案例的基础财务数据。 发票金额可用于多种分析。例如,按金额对流程进行细分,查看高金额发票的处理方式是否不同或是否更容易延误。它也是财务报告和计算未结应收账款总额的依据。 重要性 此属性量化每张发票的财务金额,支持按金额分析、确定催收优先级和评估财务影响。 获取途径 SAP表:VBRK,字段:NETWR 示例 1500.0025000.50125.75 | |||
| 地区 Region | 客户所在的地理区域。 | ||
| 说明 地区属性表示与客户地址关联的地理区域,例如州或省。此数据通常属于客户主记录的一部分。 此属性是区域账单绩效仪表板的关键维度,可用于比较不同地区的周期时间、错误率和DSO等指标。比较结果有助于发现各地区在流程执行、合规或效率方面的差异,为有针对性的改进和最佳实践标准化提供依据。 重要性 此属性支持比较不同地理区域的账单绩效,帮助发现地区差异并规范流程。 获取途径 从客户主数据表KNA1(字段:REGIO)获取,并通过发票抬头中的付款方ID(VBRK-KUNRG)关联。 示例 CANYTXBA | |||
| 客户名称 CustomerName | 发票开具对象的客户名称。 | ||
| 说明 此属性标识账单客户的法定名称,数据来自SAP中的客户主数据。 按客户分析流程有助于发现特定客户的行为模式。例如,可以识别哪些客户经常延迟付款、提出争议最多,或账单流程效率最低。借助这些信息,您可以有针对性地管理客户关系并制定相应的催收策略。 重要性 此属性支持以客户为中心的分析,帮助识别特定客户的付款行为、争议频率和流程低效问题。 获取途径 从客户主数据表KNA1(字段:NAME1)获取,并通过发票抬头中的付款方ID(VBRK-KUNRG)关联。 示例 斯普林菲尔德发电厂快客便利店赛博迪恩系统公司 | |||
| 用户名 UserName | 执行该活动的员工用户ID。 | ||
| 说明 此属性记录负责某项事件的SAP用户ID,例如创建发票、过账凭证或核销付款。它将流程步骤与执行工作的个人或团队关联起来。 按用户名分析有助于识别表现突出的员工、培训需求或工作量分配不均等问题。此属性也有助于开展合规分析,了解谁执行了关键活动,以及不同用户执行同一流程时存在何种差异。 重要性 此属性将流程活动与具体用户关联起来,支持在个人或团队层面分析工作量、绩效和合规情况。 获取途径 对于创建事件,用户信息位于VBRK-ERNAM。后续更改的用户信息可在CDHDR-USERNAME等更改历史表或工作流日志中找到。 示例 CBURNSHSIMPSONLLEONARD | |||
| 结束时间 EndTime | 表示活动或事件完成时刻的精确时间戳。 | ||
| 说明 结束时间标记活动完成的时刻。在流程挖掘中,通常根据同一案例中后续活动的开始时间推算;如果系统同时记录开始和结束事件,也可以直接获取。 这项属性是计算各项活动处理时间的基础。用结束时间减去开始时间,即可测量每个步骤的耗时,为瓶颈分析提供依据,例如识别发票审批环节的延误。 重要性 它可精确计算每项活动的耗时(处理时间),是开展瓶颈分析的基础。 获取途径 这是流程挖掘中的派生属性,通常取同一案例顺序中下一事件的StartTime计算。在某些情况下,特定数据表也会记录完成时间。 示例 2023-04-15T11:00:00Z2023-04-20T14:05:00Z2023-05-10T09:45:00Z | |||
| 争议原因 CustomerDisputeReason | 客户提出发票争议时说明的原因。 | ||
| 说明 客户对发票提出异议时,通常会记录争议原因,例如价格错误、数量不符或货物损坏。相关信息可能存储在SAP争议管理模块中,也可能以文本备注的形式记录。 分析争议原因是计算开票错误率KPI及开展相关错误分析的基础。这有助于找出开票不准确的根本原因,让企业能够解决上游流程中的系统性问题、提高发票质量并改善客户满意度。 重要性 它说明发票为何引发争议,直接揭示开票错误和客户不满的根本原因。 获取途径 如果使用SAP争议管理,可在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 | |||
| 币种 Currency | 发票金额所用的币种代码。 | ||
| 说明 此属性指定发票金额的币种,例如USD、EUR或JPY,为所有货币金额提供必要背景。 对于跨国组织,币种信息是准确开展财务分析和报告的基础。通过将所有金额换算为统一的报告币种,可以正确汇总财务数据,并比较不同地区使用本地币种时的账单绩效。 重要性 此属性为所有货币金额提供必要背景,确保财务分析和报告准确,尤其适用于跨国运营。 获取途径 SAP表:VBRK,字段:WAERK 示例 USDEURGBP | |||
| 开票凭证类型 BillingDocumentType | 用于对开票凭证分类的代码,例如发票、贷项凭证或取消凭证。 | ||
| 说明 开票凭证类型是开票流程中的关键字段,用于对交易分类。它决定凭证的处理方式,包括编号范围和会计过账规则。 借助这项属性,您可以筛选流程并分析特定交易类型。例如,单独查看贷项凭证的流程,有助于了解财务更正的原因和流转情况;将标准发票与取消凭证分开分析,则能更清晰地了解主要开票流程。 重要性 它对交易进行分类,便于针对标准发票、贷项凭证或取消凭证等特定单据流转开展分析。 获取途径 SAP表:VBRK,字段:FKART 示例 F2G2S1L2 | |||
| 数据上次更新时间 LastDataUpdate | 表示此事件的数据上次提取或刷新的时间戳。 | ||
| 说明 此属性记录上次从源系统提取数据的日期和时间,是用于了解分析数据新鲜度的重要元数据字段。 此信息可用于验证分析数据的时效性并管理数据刷新计划,确保相关人员在依据流程挖掘仪表板和洞察做出决策时,了解数据的及时程度。 重要性 此属性反映数据的新鲜度,这对于信任分析结果并了解其是否适用于当前运营状态至关重要。 获取途径 此时间戳在数据提取和加载(ETL)过程中生成,并写入每条记录。 示例 2023-06-01T02:00:00Z2023-06-02T02:00:00Z | |||
| 是否按时付款 IsPaidOnTime | 用于标记发票是否在到期日当天或之前付清的布尔值。 | ||
| 说明 这是一个计算属性,用于比较实际付款日期与计划付款到期日。按时付款时结果为“true”,逾期付款时结果为“false”。 该标记简化了按时付款率KPI的计算和可视化。您可以轻松筛选和细分数据,分析逾期发票与按时付款发票的特征,从而发现与特定客户、地区或付款条件相关的逾期模式。 重要性 它通过明确标记每张发票是“按时”还是“逾期”,简化绩效衡量,并直接支持按时付款率KPI。 获取途径 这是一个计算字段。其逻辑会将“收到客户付款”活动的时间戳与“PaymentDueDate”属性的值进行比较。 示例 truefalse | |||
| 源系统 SourceSystem | 标识数据提取自哪个源系统。 | ||
| 说明 此属性指定数据来源,在包含多个SAP实例或其他集成系统的环境中特别有用。通常包括系统ID和客户端编号。 分析时,它有助于区分不同系统或组织实体中的流程和绩效,确保数据沿袭清晰,并在整合多个来源的数据以全面了解流程时提供必要背景。 重要性 此属性提供有关数据来源的重要背景信息,确保多系统环境中的信息清晰,并支持数据治理。 获取途径 这通常是在数据提取时定义的静态值,常由系统ID(SY-SYSID)和客户端(SY-MANDT)组成。 示例 S4H_PROD_100S4H_QAS_200ECC_PROD_300 | |||
| 贷项凭证原因 CreditMemoReason | 说明开具贷项凭证原因的代码。 | ||
| 说明 发票有误、需要冲减时,通常会为贷项凭证分配原因代码,以便按类别记录开票错误来源。 这项属性直接支持开票错误率KPI。汇总并分析贷项凭证原因后,企业可以找出最常见的错误类型,例如价格错误或产品退货。分析结果可用于改进流程,减少财务更正和返工。 重要性 它对开具贷项的原因进行分类,帮助找出最常见的开票错误来源并推动质量改进。 获取途径 SAP表:VBRK,字段:AUGRU(订单原因)。该字段用于后续开票的贷项或借项凭证请求。 示例 001 - 价格差异002 - 质量不佳005 - 客户退货 | |||
| 销售订单编号 SalesOrderNumber | 生成该发票的原始销售订单标识。 | ||
| 说明 销售订单编号可将开票凭证关联回此前的销售活动。一个销售订单可能对应一张或多张发票,这一关联可呈现完整的单据流转关系。 要真正端到端地分析订单到收款流程,这项属性不可或缺。它可以将流程视图向上游延伸,把开票问题与销售订单创建或履约阶段的潜在根因联系起来。例如,从订单履约时点开始计算完整的发票生成周期时间。 重要性 它将发票关联到原始销售订单,让您能够从开票环节扩展视角,端到端分析订单到收款流程。 获取途径 SAP表:VBRP(开票凭证项目数据),字段:AUBEL 示例 100001231000045610000789 | |||
订单到收款 - 开票活动
| 活动 | 说明 | ||
|---|---|---|---|
| 发票已生成 | 此活动表示系统已创建账单凭证。用户执行VF01等事务,或后台作业创建发票时,系统会记录这一明确事件,并在账单凭证抬头表中新增记录。 | ||
| 重要性 这是账单流程的主要开始事件。分析订单履行到此活动所需的时间,对于衡量发票生成周期时间和识别流程初期延误至关重要。 获取途径 创建时记录在SAP S/4HANA的VBRK表(账单凭证:抬头数据)中。创建日期(VBRK-ERDAT)和时间(VBRK-ERZET)用作时间戳。 采集 根据VBRK表中账单凭证记录的创建时间戳捕获此事件。 事件类型 explicit | |||
| 发票已结清 | 此活动表示发票已成功付款并进入最终状态。其功能与“款项已分配/核销”相同,表示该发票的流程已完成。 | ||
| 重要性 这是流程理想路径的主要结束事件。衡量截至此节点的总周期时间,可以完整了解端到端账单与开票周期。 获取途径 根据会计凭证中客户行项目的状态推断。清账日期(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 | |||
| 款项已分配/核销 | 表示客户来款已与应收账款子账中的未结发票项目匹配并用于清账的时点。从财务角度看,此活动标志着交易完成。 | ||
| 重要性 此指标衡量收款分配流程的效率。延误会导致客户账户的实际状态无法准确反映,并给催收团队带来不必要的工作。 获取途径 根据原发票会计凭证行项目上的清账日期(BSEG-AUGDT)捕获此事件。清账凭证清账该项目时,系统会填入此日期。 采集 根据发票行项目在BSEG/ACDOCA表中的清账日期(AUGDT)字段捕获此事件。 事件类型 explicit | |||
| 发票已发送给客户 | 此活动表示发票已发送给客户,例如通过打印、电子邮件或EDI发送。具体捕获方式取决于SAP中的输出管理配置。 | ||
| 重要性 从客户角度看,这是付款期限开始计算的正式起点。发票发送延迟会直接影响应收账款周转天数(DSO)和现金流。 获取途径 可在输出控制表中明确记录,例如旧版方法使用的NAST表或S/4HANA对应表。如果没有明确记录,通常会推断该事件与“发票已过账至会计”同时发生。 采集 检查输出管理表中的处理日志,查找与发票输出类型关联的时间戳。 事件类型 explicit | |||
| 发票已取消 | 取消先前创建的发票时会发生此事件,通常需要创建相应的取消凭证。这会冲销原发票及其会计影响。 | ||
| 重要性 此事件表示发生了返工、更正或账单错误。取消频繁发生,通常说明销售订单录入或账单配置等上游环节存在严重问题。 获取途径 创建取消账单凭证时捕获此事件,例如凭证类型为“S1”的凭证。VBRK中的新凭证会通过VBRK-SFAKN字段引用原发票编号。 采集 根据VBRK中引用原发票的取消凭证创建日期捕获此事件。 事件类型 explicit | |||
| 发票过账受阻 | 如果发票已创建,但因信用检查或数据不一致等原因而被系统自动阻止过账至财务会计模块,就会发生此事件。此状态根据账单凭证中的过账状态字段推断。 | ||
| 重要性 此事件可识别发票已创建但未立即释放至财务部门的瓶颈,这会延误整个收款周期。它也是数据质量问题或信用管理问题的重要指标。 获取途径 根据账单凭证抬头表中的过账状态字段(VBRK-RFBSK)推断。例如,状态“A”(账单凭证被阻止传送至FI)表示存在阻止。 采集 发票生成后,检查过账状态字段(VBRK-RFBSK)的值即可推断此事件。 事件类型 inferred | |||
| 客户已提出争议 | 客户对发票提出争议并在系统中正式登记时,会发生此活动。此功能需要使用SAP争议管理模块。 | ||
| 重要性 此事件可揭示账单准确性、产品质量或服务交付方面的问题,这些问题可能导致付款延迟。分析争议原因有助于解决根本问题并提升客户满意度。 获取途径 在争议管理表(例如UDM_CASE)中创建争议案例时记录,并关联至会计凭证行项目。 采集 根据与发票关联的争议案例记录的创建时间戳捕获此事件。 事件类型 explicit | |||
| 已创建贷项凭证 | 此活动表示已创建贷项凭证,用于更正多收款项,或为退货提供抵扣。贷项凭证通常与原发票关联。 | ||
| 重要性 此事件可揭示开票后发生财务调整的问题。分析贷项凭证有助于发现定价错误、产品问题或收入流失的其他根本原因。 获取途径 系统会在VBRK中明确创建新的账单凭证,并指定贷项凭证的账单类型(例如“G2”)。该凭证通常引用原销售订单或发票。 采集 根据VBRK中创建贷项凭证类型账单凭证的记录捕获此事件。 事件类型 explicit | |||
| 已到付款到期日 | 此计算事件表示根据约定的付款条款,发票正式到期应付的日期。它不是交易事件,而是根据发票数据推导得出。 | ||
| 重要性 此事件为衡量按时付款表现和分析客户付款行为提供关键基准,有助于区分按时付款和逾期付款。 获取途径 根据付款基准日期(BSEG-ZFBDT)和会计凭证客户行项目中存储的付款条款计算得出。 采集 将付款条款规定的天数加到会计凭证行项目(BSEG)中的付款基准日期,即可推导出此日期。 事件类型 calculated | |||
| 已发现账单返工 | 此计算事件用于识别返工循环:发票取消后,又为同一销售订单生成了新发票。它不是单笔交易,而是一组事件构成的模式。 | ||
| 重要性 此事件直接用于计算账单返工率KPI,量化更正情况,帮助定位低效环节并衡量账单流程中的质量损失成本。 获取途径 通过识别“发票已取消”事件及其后续的“发票已生成”事件来计算此模式;这两个事件都可追溯至同一源凭证,例如同一销售订单编号。 采集 通过检测同一销售订单引用下依次发生的“发票已取消”和“发票已生成”事件推导得出。 事件类型 calculated | |||
| 已发送付款提醒 | 表示已向逾期发票的客户发送付款提醒或催款通知。这是自动催款程序生成的明确事件。 | ||
| 重要性 此事件可用于分析催款流程的效果,帮助判断提醒是否能加快付款,以及哪些催款级别最有效。 获取途径 针对发票未结项目执行催款运行(事务代码F150)时,系统会在催款历史表(MAHNV、MHND)中记录此事件。 采集 根据催款历史表中记录的催款通知运行日期捕获此事件。 事件类型 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查询:将本文档“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安全团队分配相应角色和授权。此外,若要提取“客户争议已发起”或“已发送付款提醒”等活动,系统必须启用并实际使用相应的SAP模块:SAP争议管理和SAP财务催款。
- 性能:查询使用多个联接和联合操作。对于数年数据等大型数据集,建议在非高峰时段执行,或使用更严格的筛选条件限制首次提取的数据量。
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 HANA架构。向系统负责人获取架构名称、连接信息、授权日期范围、公司代码范围、开票凭证类型,以及客户或区域筛选条件。仅替换查询中的连接和筛选占位符。
- 确认目标系统中相关SAP S/4HANA数据源及其字段映射。查询使用VBRK和VBRP获取开票数据,并要求配置会计、输出管理、争议管理、催款、收款、清账和凭证关系等数据源。请先根据系统数据字典验证,再替换方括号中的数据源和字段占位符。
- 使用包含开始时间、不包含结束时间的时间戳设置提取周期。首次运行建议提取三至六个月的数据。按公司代码筛选,并在适当情况下按开票类型筛选,以控制数据量,避免混入无关的开票流程。
- 使用只读HANA数据库用户执行查询。查询会为每项明确提取的活动生成一条事件记录,不会依赖ProcessMind推断事件。付款到期日已到和已识别开票返工等计算活动由SQL逻辑生成,并以记录形式返回。
- 验证返回的架构。事件日志必须包含InvoiceNumber、ActivityName、EventTime、UserName、InvoiceDate、PaymentDueDate、InvoiceAmount、CustomerName、Region和EndTime。确认每条记录的InvoiceNumber、ActivityName和EventTime均已填写。
- 验证事件含义及关联关系。将“发票已生成”记录与开票抬头创建数据进行比对,将“发票已过账至会计”记录与会计过账状态比对,将“发票已发送给客户”记录与输出记录比对,将付款记录与会计凭证比对,并将清账记录与已清账的发票项目比对。正式使用前,请检查所有依赖占位符的部分。
- 规范ProcessMind所需的结果格式。每个事件保留一行,统一时间戳数据类型和时区,将InvoiceNumber保留为文本以保留前导零,并确保ActivityName值与要求的活动名称完全一致。按InvoiceNumber和EventTime排序;若多个事件时间戳相同,请设置确定性的次级排序规则。
- 将结果导出为UTF-8编码的CSV文件或其他ProcessMind支持的表格格式。将InvoiceNumber映射为案例标识,将ActivityName映射为活动列,将EventTime映射为事件时间戳。尽可能包含建议的属性,然后通过已配置的ProcessMind导入流程上传文件,并最终检查行数和活动数量。
配置
- 日期范围:首次提取建议选择三至六个月。开始时间戳包含在范围内,结束时间戳不包含在范围内,以避免增量运行时重复提取事件。
- 案例标识:使用开票凭证抬头中的InvoiceNumber。由于SAP凭证编号可能包含前导零,请将其保留为字符串。
- 必需活动:提取结果必须包含以下活动的明确记录:发票已生成、发票过账受阻、发票已过账至会计、发票已发送给客户、付款到期日已到、客户争议已发起、已发送付款提醒、已收到客户付款、现金已核销/对账、发票已关闭、发票已取消、已创建贷项凭证和已识别开票返工。
- 筛选条件:只有在确认目标系统中的对应字段和业务范围后,才应用公司代码、开票凭证类型、销售组织、客户、区域和日期筛选条件。不要假设所有开票凭证类型都遵循相同的会计或输出流程。
- 数据源配置:VBRK和VBRP是主要开票数据源。会计、输出、争议、催款、付款、清账和凭证流数据源必须根据已部署的SAP S/4HANA版本及启用的模块进行配置。请将方括号中的数据源引用替换为已验证的对象和字段。
- 计算事件:付款到期日已到根据付款条件和到期日数据计算。已识别开票返工根据取消记录及后续开票模式计算。这些是由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%。
无需信用卡,几分钟即可开始使用。