您的订单到收款流程:开票与发票处理数据模板
您的订单到收款流程:开票与发票处理数据模板
- 建议收集的属性
- 需要跟踪的关键活动
- Oracle Fusion Financials数据提取指南
订单到收款-开票与发票处理属性
| 名称 | 说明 | ||
|---|---|---|---|
|
发票编号
InvoiceNumber
|
每张开票发票的唯一标识符,用作跟踪所有相关活动的主要案例ID。 | ||
|
说明
发票编号是开票流程分析的基础。它充当案例ID,将从创建发票到最终付款和关闭的所有事件归入同一案例,从而完整呈现单张开票单据的端到端生命周期。 在流程挖掘中,按发票编号分析可以可视化流程变体,计算单张发票的周期时间,并识别影响特定交易的瓶颈或返工循环。它也是“发票端到端周期时间”等仪表板的基础,可用于按发票计算未偿销售天数(DSO)等核心KPI。
为什么重要
此属性至关重要,它将所有相关开票和付款活动连接到同一案例,从而支持对发票生命周期进行完整、准确的分析。
获取位置
通常是Oracle Fusion Financials中RA_CUSTOMER_TRX_ALL表的Transaction Number(TRX_NUMBER)。
示例
INV-1002345983451CM-55432
|
|||
|
开始时间
EventTimestamp
|
具体活动或事件发生的准确日期和时间。 | ||
|
说明
事件时间戳记录活动发生的准确时刻。它为每张发票提供事件的时间顺序,是构建流程顺序和执行时间分析的基础。 该属性是所有时长和绩效计算的基础,可用于衡量活动之间的耗时、计算端到端周期时间、判断付款是否按时完成以及分析时间趋势。“平均发票审批时间”和“端到端发票周期时间”等KPI都直接根据这些时间戳计算。
为什么重要
时间戳是计算所有绩效指标的基础,包括周期时间、延迟和截止期限遵循情况,也是量化流程分析的依据。
获取位置
数据来自Oracle Fusion Financials各表中的不同日期字段,例如RA_CUSTOMER_TRX_ALL中的CREATION_DATE,或工作流表中的状态更新时间戳。
示例
2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-05-20T11:25:10Z
|
|||
|
活动名称
ActivityName
|
发票生命周期中某一时点发生的具体业务事件或任务的名称。 | ||
|
说明
活动名称用于描述开票流程中的步骤,例如“发票已创建”“发票已批准”或“已收到客户付款”。这些事件构成每张发票流程顺序中的操作序列。 该属性是流程发现的基础,可帮助挖掘工具构建发票实际处理方式的可视化流程图。它用于分析流程变体、识别多次审批等返工循环,并衡量每个阶段的频率和持续时间。所有仪表板和KPI都依赖该属性来了解流程顺序。
为什么重要
此属性定义流程地图中的步骤,使发票工作流能够被可视化、分析并识别低效环节。
获取位置
该信息来自Oracle Fusion Financials中的多个表和状态变更,例如工作流历史表(如审批相关表)及交易状态字段。
示例
发票已创建发票已批准已收到客户付款发票已关闭
|
|||
|
业务单元
BusinessUnit
|
组织内开具发票的具体业务单元。 | ||
|
说明
业务单元代表负责该交易的组织实体,是大型企业进行财务分段和报告的关键数据元素。 此属性支持比较公司不同部门的流程绩效。例如,可以分析不同业务单元的DSO是否存在显著差异,或某个单元的开票返工率是否明显更高,从而将改进措施集中于最需要的领域。
为什么重要
支持比较不同组织单元的绩效,帮助在细粒度层面识别最佳实践和需要改进的领域。
获取位置
可在RA_CUSTOMER_TRX_ALL等交易表中找到,通常为ORG_ID,并与业务单元定义关联。
示例
美国咨询EMEA制造APAC服务
|
|||
|
到期日
DueDate
|
发票付款到期的日期。 | ||
|
说明
到期日是关键日期属性,由付款条款确定发票的付款截止时间。 该属性对催收和财务健康监控至关重要,是计算按时付款率KPI和生成付款账龄报告的基准。在仪表板中,它用于显示预期付款时间以预测现金流,并识别需要催收的逾期发票。
为什么重要
这是衡量付款及时性、计算DSO和管理应收账款账龄的主要基准。
获取位置
位于AR_PAYMENT_SCHEDULES_ALL表中,通常为DUE_DATE字段。
示例
2023-05-302023-06-152023-07-01
|
|||
|
发票状态
InvoiceStatus
|
发票生命周期中的当前状态,例如“未结”“已关闭”或“存在争议”。 | ||
|
说明
发票状态反映发票在流程中的当前位置。常见状态包括未结(未付款)、已关闭(已付款)、存在争议或已作废。 此属性适用于高层监控和筛选。例如,实时现金流预测仪表板使用该状态对未结金额进行分类,帮助快速识别逾期、存在争议或已完全结清的发票。
为什么重要
快速概览发票当前状态,支持财务报告和运营管理中的高效筛选与分类。
获取位置
根据RA_CUSTOMER_TRX_ALL或AR_PAYMENT_SCHEDULES_ALL等表中的状态字段得出,例如STATUS字段。
示例
未结已关闭有争议待审批
|
|||
|
发票金额
InvoiceAmount
|
发票的货币总金额。 | ||
|
说明
此属性表示发票应付总额,是了解开票流程中资金价值的重要财务指标。 在分析中,发票金额可用于优先处理高价值交易,计算未结应收账款总额,并为未偿销售天数(DSO)等KPI设置权重。它支持按财务影响对流程分段,例如分析高价值发票是否遵循不同的审批路径,或是否需要更长时间才能收款。
为什么重要
为每个案例提供财务背景,支持基于价值的分析、高价值发票优先级排序以及关键财务KPI计算。
获取位置
位于RA_CUSTOMER_TRX_ALL表中,可能是INVOICE_AMOUNT或表示交易总额的相关字段。
示例
5000.001250.75250000.00
|
|||
|
客户名称
CustomerName
|
被开票客户或实体的名称。 | ||
|
说明
此属性标识与发票关联的客户,是流程数据分段和筛选的主要维度。 按客户名称分析流程,有助于识别付款周期最长、最可能提出发票争议以及持续按时付款的客户。这对DSO趋势仪表板至关重要,也有助于针对不同客户行为制定催收策略。
为什么重要
支持按客户对流程进行分段,揭示不同的行为、付款模式以及可能影响现金流的关系问题。
获取位置
通过将交易表(RA_CUSTOMER_TRX_ALL)与HZ_PARTIES等客户主数据表连接得出。
示例
Global Tech Inc.Innovate Solutions LLCApex Manufacturing
|
|||
|
争议原因
DisputeReason
|
客户提出发票争议的原因。 | ||
|
说明
客户对发票提出争议时,系统会记录争议原因,可能涉及价格、数量、服务质量或其他问题。 分析争议原因是开展根因分析的有效方式。了解最常见的争议原因后,企业可以解决定价、订单履行或数据质量方面的潜在问题,从而缩短平均发票争议解决时间并提升客户满意度。
为什么重要
直接揭示付款延迟和客户不满的根本原因,帮助企业解决系统性问题。
获取位置
该信息可能存储在Oracle Collections或相关争议管理模块中,也可能位于专用争议表,或作为交易本身的原因代码保存。
示例
定价错误数量不符货物损坏重复发票
|
|||
|
付款方式
PaymentMethod
|
客户采用的付款方式,例如银行转账或信用卡。 | ||
|
说明
此属性说明客户如何支付发票,有助于分析付款趋势和成本。 不同付款方式的处理时间和交易成本可能不同。按付款方式分析,可以了解哪些方式更容易出现对账错误或延迟,也可为引导客户使用更高效的付款渠道提供依据。
为什么重要
帮助分析不同付款渠道的处理效率、交易成本和对账错误率。
获取位置
位于AR_CASH_RECEIPTS_ALL等现金收款表中,其中包含表示付款方式的字段。
示例
ACH电汇信用卡支票
|
|||
|
付款条款
PaymentTerms
|
约定的发票付款条件,例如“Net 30”或“2% 10,Net 30”。 | ||
|
说明
付款条款定义发票付款时间和方式的规则,包括提前付款可能享受的折扣。这些信息对管理应收账款和现金流至关重要。 该属性对于计算准确到期日和识别提前付款折扣机会不可或缺。提前付款折扣获取率KPI直接依赖此数据,以确定哪些发票符合折扣条件。
为什么重要
定义发票付款规则,直接影响到期日计算以及提前付款折扣获取情况的跟踪和优化。
获取位置
位于RA_TERMS表中,并通过RA_CUSTOMER_TRX_ALL中的term_id与交易关联。
示例
开票后30天付款开票后60天付款10天内付款享受2%折扣,30天内付清
|
|||
|
最后数据更新时间
LastDataUpdate
|
表示该事件数据上次从源系统刷新或提取时间的时间戳。 | ||
|
说明
此属性提供最近一次数据提取的时间戳,是了解所分析数据新鲜度的重要元数据字段。 分析人员可利用该信息确认使用的是最新数据,并了解数据的时效性。对于标称“实时”或近实时的仪表板,这一点尤其重要,因为它能够透明呈现潜在的数据延迟。
为什么重要
告知用户数据的新鲜度,确保分析和结论基于时效性明确且可接受的数据。
获取位置
这是在数据提取、转换和加载(ETL)过程中生成的元数据字段,通常对应数据管道的执行时间。
示例
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
区域
Region
|
与客户或交易关联的地理区域。 | ||
|
说明
区域为发票提供地理背景,通常根据客户所在地确定,从而支持流程绩效的空间分析。 按区域分析可以发现由当地法规、市场条件或区域团队绩效造成的差异。DSO趋势和发票端到端周期时间等仪表板可以按区域细分,以判断某些地区是否在发票收款方面面临独特挑战。
为什么重要
支持按地理区域对流程进行分段,突出不同地区在绩效、客户行为或合规方面的差异。
获取位置
通常根据TCA中的客户地址信息得出(HZ_LOCATIONS、HZ_PARTY_SITES),并非发票本身的直接字段。
示例
北美欧洲亚太地区
|
|||
|
发票周期时间
InvoiceCycleTime
|
从发票首次创建到关闭所需的总时间。 | ||
|
说明
此属性衡量单个案例完整发票生命周期的端到端时长,计算方式是首次活动(通常为“已创建发票”)与最终活动(“发票已关闭”)之间的时间差。 该指标提供流程整体效率的高层视图,是“发票端到端周期时间”仪表板的主要衡量指标。按客户或业务单元等不同维度分析此属性,可以识别处理时间最长的发票类型并调查根本原因。
为什么重要
提供衡量整体流程速度的关键指标,帮助快速识别从开始到完成耗时最长的发票。
获取位置
这是一个计算指标,通过计算每个唯一InvoiceNumber的最大EventTimestamp与最小EventTimestamp之差得出。
示例
45天8小时32天2小时90天12小时
|
|||
|
发票日期
InvoiceDate
|
发票正式开具的日期。 | ||
|
说明
发票日期也称交易日期,是发票单据上记录的日期,用作付款条款计算的起点。 该日期是计算未偿销售天数(DSO)的关键要素,因为DSO衡量从发票日期到付款日期的时间。它不同于系统中的创建日期,代表从客户角度看付款周期的正式起点。
为什么重要
作为发票生命周期的正式开始日期,也是计算未偿销售天数(DSO)KPI的基准。
获取位置
位于RA_CUSTOMER_TRX_ALL表的TRX_DATE字段中。
示例
2023-04-142023-05-182023-06-25
|
|||
|
开票部门
BillingDepartment
|
负责创建和管理发票的内部部门或团队。 | ||
|
说明
此属性标识组织内负责开票流程的具体团队或部门,为分析提供另一层组织背景。 按开票部门对流程进行分段,企业可以比较不同团队的效率和准确性,识别返工率较高、审批周期较长或导致DSO偏高的部门,从而明确培训或流程标准化机会。
为什么重要
支持比较内部团队的绩效,帮助识别最佳实践、资源需求或需要改进流程的领域。
获取位置
可能根据创建发票的用户得出,再将用户与其在人力资源系统中所属的部门关联,例如通过PER_ALL_ASSIGNMENTS_F关联。
示例
企业开票服务开票团队产品销售开票
|
|||
|
是否按时付款
IsPaidOnTime
|
表示发票是否在到期日当天或之前付清的布尔标志。 | ||
|
说明
此计算属性以真或假表示付款是否及时,根据“已收到客户付款”活动的日期与发票“到期日”属性进行比较得出。 该标志简化了按时付款率KPI的分析和报告,支持轻松筛选和分段,以了解客户、区域或发票金额等因素与逾期付款的关联,是评估催收有效性的关键指标。
为什么重要
简化催收绩效衡量,并支持轻松分析影响按时付款和逾期付款的因素。
获取位置
通过比较最终付款活动的时间戳与DueDate属性计算。逻辑为:
示例
truefalse
|
|||
|
是否返工
IsRework
|
表示某项活动是否属于返工的布尔标志,例如重复审批或更正。 | ||
|
说明
此计算属性用于标记不必要或重复的工作,例如发票被拒绝后重新提交审批,或初次创建后再次更正。 标记返工后,可以轻松量化其对流程的影响。开票返工率KPI直接根据此属性计算。仪表板可以展示返工频率及其增加的额外周期时间,帮助定位低效和错误的来源。
为什么重要
通过标记不必要或重复的工作,直接量化流程低效程度,便于衡量质量问题造成的时间和成本影响。
获取位置
在数据转换过程中根据活动顺序计算。例如,同一案例中“发票已批准”活动之前出现“发票已拒绝”活动时,将其标记为返工。
示例
truefalse
|
|||
|
未偿销售天数
DaysSalesOutstanding
|
从发票日期到收到付款日期之间的天数。 | ||
|
说明
未偿销售天数(DSO)是重要的财务指标,用于衡量发票开具后平均需要多长时间收回款项。此属性按单张发票计算DSO。 总体DSO是重要KPI,而按单张发票计算可以开展更深入的分析。它可用于创建趋势仪表板,识别DSO较高发票的特征,并衡量流程延迟造成的财务影响。这种细粒度计算为理解总体DSO KPI背后的驱动因素提供所需数据。
为什么重要
在单张发票层面计算关键现金流指标,支持深入分析收款周期和财务绩效的驱动因素。
获取位置
通过计算“已收到客户付款”活动的时间戳与“发票日期”属性之间的差值得出。
示例
356228
|
|||
|
源系统
SourceSystem
|
提取事件数据的记录系统。 | ||
|
说明
此属性标识数据来源的源应用。对于此流程,通常是Oracle Fusion Financials,也可能具体到其中的某个模块,例如Oracle Receivables(AR)。 在包含多个集成系统的环境中,该字段有助于区分数据来源,对数据验证和治理至关重要,可确保分析基于正确且预期的数据集。
为什么重要
标识数据来源,对数据治理、问题排查以及确保分析基于正确的记录系统至关重要。
获取位置
通常是在数据提取和转换过程中添加的静态值(“Oracle Fusion Financials”)。
示例
Oracle Fusion FinancialsOracle AR CloudFusion Apps
|
|||
|
用户
User
|
执行特定活动的员工或系统用户。 | ||
|
说明
用户属性标识负责执行流程步骤的人员或自动化代理。这可能是创建发票的用户、批准发票的经理,或发出提醒的催收人员。 按用户分析有助于发现培训机会、优化工作量分配,并比较个人或团队之间的绩效差异。它还可以揭示哪些用户的错误率较高,或哪些审批人持续成为瓶颈。
为什么重要
明确流程步骤的责任归属,支持用户绩效、工作量平衡和培训需求分析。
获取位置
来源于各交易和工作流表中的CREATED_BY或LAST_UPDATED_BY等用户ID字段。随后将该ID与用户目录表(如PER_ALL_PEOPLE_F)连接,以获取用户姓名。
示例
john.smithjane.doeCollectionsBot
|
|||
|
结束时间
EventEndTime
|
具体活动或事件完成的准确日期和时间。 | ||
|
说明
事件结束时间记录活动完成的时刻。虽然许多事件是瞬时发生的,但“发票审批”等活动可能持续一段时间,从提交审批开始,到作出决定结束。 结束时间支持精确计算活动处理时长,有助于分析用户处理特定任务所需的时间,并通过区分等待时间和实际处理时间,提高瓶颈分析的准确性。
为什么重要
支持精确计算活动处理时长,区分主动工作时间和空闲等待时间,是深入开展瓶颈分析的关键。
获取位置
通常通过取流程中后续活动的开始时间得出。对于部分活动,工作流日志中可能存在专用的结束时间字段。
示例
2023-04-15T09:05:12Z2023-04-18T15:00:00Z2023-05-20T11:25:45Z
|
|||
订单到收款-开票与发票处理活动
| 活动 | 说明 | ||
|---|---|---|---|
|
付款已应用到发票
|
收到的客户付款已成功匹配并应用到具体发票,从而减少未结余额。这是一条独立的交易记录。 | ||
|
为什么重要
此活动确认现金已正确分配,这对准确生成账龄报告和财务报表至关重要,也是确认应收账款已收到现金的最后一步。
获取位置
在AR_RECEIVABLE_APPLICATIONS_ALL表中明确记录。apply_date和gl_date字段表示应用发生的时间。
采集
使用AR_RECEIVABLE_APPLICATIONS_ALL表中的apply_date,并将现金收款关联到发票。
事件类型
explicit
|
|||
|
发票已关闭
|
发票已全额支付并完成对账,其生命周期结束。通常当发票未结余额变为零且状态更新时推断该事件。 | ||
|
为什么重要
这是发票的最终结清状态,标志着流程结束。达到该状态所需的总时长就是端到端周期时间,也是开票流程的核心KPI。
获取位置
当AR_PAYMENT_SCHEDULES_ALL表中的状态更新为'CLOSED'且amount_due_remaining为零时推断。'gl_date_closed'字段表示关闭日期。
采集
针对具体发票,使用AR_PAYMENT_SCHEDULES_ALL中的gl_date_closed。
事件类型
inferred
|
|||
|
发票已创建
|
指系统中创建发票交易的初始时点,通常处于草稿或未完成状态。当用户在应收账款模块中首次保存新的发票记录时,系统会明确记录此事件。 | ||
|
为什么重要
这是账单流程的明确起点。分析从创建到完成所需的时间,有助于识别前端数据录入延迟或系统性能问题。
获取位置
此事件取自RA_CUSTOMER_TRX_ALL表中的交易记录创建日期。初始状态通常为“Incomplete”。
采集
针对具体发票编号,使用RA_CUSTOMER_TRX_ALL表中的creation_date。
事件类型
explicit
|
|||
|
发票已发送给客户
|
发票已通过客户偏好的方式送达,例如电子邮件或打印件。系统通常会记录执行交付操作的时间戳。 | ||
|
为什么重要
此活动正式开启付款条款期限。衡量从审批到交付所需的时间,是了解发票分发流程效率的关键。
获取位置
如果采用电子交付,可根据RA_CUSTOMER_TRX_ALL中的“last_printed_date”字段,或Oracle Business Intelligence Publisher中的日志推断。
采集
使用与发票关联的相关交付或打印日志中的时间戳。
事件类型
inferred
|
|||
|
发票已批准
|
发票已获得所有必要审批,可以发送给客户。当审批工作流成功结束并更新发票状态时,记录此事件。 | ||
|
为什么重要
这是决定发票能否交付客户的关键里程碑。此处的延迟会直接影响付款计时开始的时间,进而影响DSO。
获取位置
根据发票交易记录中的最终审批状态更新时间,或关联BPM工作流任务的完成时间戳推断。
采集
记录发票审批状态设为“Approved”时的时间戳。
事件类型
inferred
|
|||
|
已收到客户付款
|
客户付款已作为现金收款录入系统。在此阶段,付款可能尚未应用到具体发票。 | ||
|
为什么重要
这是代表现金流入的关键里程碑。收到付款与将其应用到发票之间的时间差,是衡量现金管理效率的重要指标。
获取位置
在AR_CASH_RECEIPTS_ALL表创建记录时明确记录。receipt_date表示付款处理日期。
采集
使用AR_CASH_RECEIPTS_ALL表中的creation_date或receipt_date。
事件类型
explicit
|
|||
|
发票已完成
|
表示发票数据录入已完成,交易已准备好进行验证和会计处理。通常通过观察发票状态从“Incomplete”变为“Complete”来记录此事件。 | ||
|
为什么重要
这一里程碑标志着数据录入阶段结束。创建到完成之间的时间,可以反映账单部门数据录入和审核流程的效率。
获取位置
根据RA_CUSTOMER_TRX_ALL表中发票交易记录的状态变化推断。查找状态更新为“Complete”时对应的时间戳。
采集
跟踪RA_CUSTOMER_TRX_ALL或相关工作流表中的交易状态历史。
事件类型
inferred
|
|||
|
发票已拒绝
|
审批人拒绝了发票,通常是因为价格或数量等数据存在错误。此事件会将发票退回更正,并形成返工循环。 | ||
|
为什么重要
跟踪拒绝情况有助于发现账单准确性和内部控制方面的问题。分析拒绝频率及原因,可以定位流程改进和培训的重点。
获取位置
根据发票交易记录中的状态更新,或BPM工作流任务中的“Rejected”结果推断。
采集
记录发票审批状态设为“Rejected”时的时间戳。
事件类型
inferred
|
|||
|
发票已提交审批
|
如果配置了审批工作流,发票会正式提交至该工作流。当发票状态更新为待审批状态并向指定审批人触发通知时,记录此事件。 | ||
|
为什么重要
标志着审批周期开始。跟踪此活动对于衡量和分析后续审批时间至关重要,而审批时间是发票整体周期时间的重要组成部分。
获取位置
根据发票交易的状态变化推断,或从记录审批任务启动情况的Oracle Business Process Management(BPM)工作流表中获取。
采集
识别发票审批状态变为“Pending”或类似状态时的时间戳。
事件类型
inferred
|
|||
|
发票已调整
|
发票金额已发生修改,例如核销或贷项。这是用于更改发票未结余额的明确交易。 | ||
|
为什么重要
调整通常表示争议、让步或更正。分析调整的频率和金额,有助于发现订单到收款流程中的潜在问题。
获取位置
在AR_ADJUSTMENTS_ALL表中明确记录。调整记录的creation_date标记该事件。
采集
针对相关发票,使用AR_ADJUSTMENTS_ALL表中的creation_date。
事件类型
explicit
|
|||
|
已到付款到期日
|
发票合同约定的付款日期已经过去。这不是交易事件,而是根据发票条款和当前日期计算得出。 | ||
|
为什么重要
这一计算事件是账龄分析和DSO计算的基础。它区分按时付款的发票和逾期发票,支持有针对性的催收活动。
获取位置
这是一个计算事件。当给定发票在AR_PAYMENT_SCHEDULES_ALL表中的due_date字段早于当前日期时,该事件发生。
采集
通过比较当前日期与AR_PAYMENT_SCHEDULES_ALL中的due_date字段计算得出。
事件类型
calculated
|
|||
|
已发出付款提醒
|
系统已向客户发送逾期发票的催款函或提醒通知。这是由催收模块记录的明确操作。 | ||
|
为什么重要
跟踪提醒有助于衡量催收流程的有效性,并分析哪些提醒策略能够加快付款。
获取位置
在Oracle Advanced Collections模块中明确记录。IEX_DUNNINGS等催款历史表会记录所发送提醒的日期和级别。
采集
从催款历史表中提取,并将催款交易关联到发票。
事件类型
explicit
|
|||
|
已发起争议
|
客户已正式对发票提出争议,系统中也已创建争议案件。通常通过更改发票付款计划中的状态标志来记录。 | ||
|
为什么重要
争议会冻结付款流程,并需要人工处理。分析争议频率和解决时长,有助于识别定价或运输错误等根本原因。
获取位置
可根据AR_PAYMENT_SCHEDULES_ALL表中的状态字段是否设置为争议状态推断,也可根据AR_DISPUTE_HISTORY中的创建记录推断。
采集
识别发票付款计划中的争议标志或状态何时启用。
事件类型
inferred
|
|||
提取指南
立即优化Oracle开票与发票处理
借助我们的解决方案,将开票周期时间缩短30%,提升现金流。
无需信用卡,几分钟即可完成设置。