您的订单到收款流程:账单与发票数据模板
您的订单到收款流程:账单与发票数据模板
- 建议收集的属性
- 需要跟踪的关键活动
- Oracle Fusion Financials数据提取指南
订单到收款流程:账单与发票属性
| 名称 | 说明 | ||
|---|---|---|---|
|
发票编号
InvoiceNumber
|
每张开票发票的唯一标识符,也是跟踪所有相关活动的主要案例ID。 | ||
|
说明
发票编号是开票流程分析的核心标识。它作为案例ID,将从创建发票到最终付款和关闭的所有事件归为同一案例。借此可以完整查看单张开票单据的生命周期。 在流程挖掘中,按发票编号分析可视化流程变体、计算单张发票的周期时间,并识别影响特定交易的瓶颈或返工循环。它也是“发票端到端周期时间”等仪表板的基础,并可用于按发票计算应收账款周转天数(DSO)等核心KPI。
重要性
此属性至关重要,可将相关开票和付款活动关联到同一案例,从而完整、准确地分析发票生命周期。
获取途径
通常是Oracle Fusion Financials中RA_CUSTOMER_TRX_ALL表的交易编号(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,并关联到业务单元定义。
示例
US ConsultingEMEA ManufacturingAPAC Services
|
|||
|
到期日
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与交易关联。
示例
Net 30Net 602% 10, Net 30
|
|||
|
发票周期时间
InvoiceCycleTime
|
从首次创建发票到发票关闭的总时长。 | ||
|
说明
此属性衡量单个案例中整个发票生命周期的端到端时长,计算方式是首次活动(通常为“创建发票”)与最终活动(“关闭发票”)之间的时间差。 此指标从整体上反映流程效率,是“发票端到端周期时间”仪表板的主要衡量指标。按客户或业务单元等维度分析此属性,企业可以识别哪些类型的发票处理时间最长,并进一步调查根本原因。
重要性
以一个关键指标概括整体流程速度,帮助快速识别从开始到完成耗时最长的发票。
获取途径
这是一个计算指标,按每个唯一InvoiceNumber计算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
|
|||
|
地区
Region
|
与客户或交易相关的地理区域。 | ||
|
说明
地区为发票提供地理背景,通常根据客户所在地确定,可用于分析流程绩效的地域差异。 按地区分析有助于发现当地法规、市场状况或区域团队绩效造成的差异。DSO趋势和发票端到端周期时间等仪表板可按地区细分,以了解某些地区在收款方面是否面临特殊挑战。
重要性
支持按地理区域划分流程,帮助发现各地区在绩效、客户行为或合规方面的差异。
获取途径
通常根据TCA中的客户地址信息得出(HZ_LOCATIONS、HZ_PARTY_SITES)。这不是发票上的直接字段。
示例
北美欧洲亚太地区
|
|||
|
应收账款周转天数
DaysSalesOutstanding
|
从发票日期到收到付款日期之间的天数。 | ||
|
说明
应收账款周转天数(DSO)是一项重要的财务指标,用于衡量开具发票后平均需要多长时间才能收款。此属性按单张发票计算DSO。 整体DSO是重要的KPI,而按单张发票计算则能支持更深入的分析。您可以据此创建趋势仪表板、识别DSO较高的发票特征,并衡量流程延迟造成的财务影响。细粒度的计算结果有助于了解整体DSO KPI背后的驱动因素。
重要性
按单张发票计算重要的现金流指标,支持深入分析影响收款周期和财务绩效的因素。
获取途径
通过计算“收到客户付款”活动的时间戳与“发票日期”属性之间的差值得出。
示例
356228
|
|||
|
开票部门
BillingDepartment
|
负责创建和管理发票的内部部门或团队。 | ||
|
说明
此属性用于标识组织内负责开票流程的具体团队或部门,为分析提供更多组织背景。 按开票部门划分流程,企业可以比较不同团队的效率和准确性,识别哪些部门返工率较高、审批周期较长,或对DSO偏高的影响较大,从而有针对性地开展培训或流程标准化。
重要性
支持比较内部团队的绩效,帮助识别最佳实践、资源需求和需要改进流程的领域。
获取途径
这些信息可能根据发票创建者得出:将用户与其在人力资源系统中所属的部门关联,例如通过PER_ALL_ASSIGNMENTS_F关联。
示例
企业开票部服务开票团队产品销售开票部
|
|||
|
数据最近更新时间
LastDataUpdate
|
表示此事件数据最近一次从源系统刷新或提取时间的时间戳。 | ||
|
说明
此属性提供最近一次数据提取的时间戳,是用于了解分析数据新鲜度的关键元数据。 分析人员可据此确认使用的是最新信息,并了解数据的时效性。对于标称“实时”或近实时的仪表板,这一点尤为重要,因为它能让用户了解可能存在的数据延迟。
重要性
让用户了解数据的新鲜度,确保分析和结论基于时效性明确且可接受的信息。
获取途径
这是在数据提取、转换和加载(ETL)过程中生成的元数据字段,通常对应数据管道的执行时间。
示例
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
是否按时付款
IsPaidOnTime
|
用于标记发票是否在到期日当天或之前付清的布尔值。 | ||
|
说明
此计算属性以简单的真或假标记付款是否及时。系统通过比较“收到客户付款”活动的日期与发票的“到期日”属性得出结果。 此标记简化了按时付款率KPI的分析和报告。您可以轻松筛选和细分数据,了解客户、地区或发票金额等因素与逾期付款的关联,是评估催收成效的重要指标。
重要性
简化催收绩效衡量,并便于分析影响按时付款或逾期付款的因素。
获取途径
将最终付款活动的时间戳与DueDate属性进行比较得出。逻辑为:
示例
truefalse
|
|||
|
是否返工
IsRework
|
用于标记某项活动是否属于返工的布尔值,例如重复审批或更正。 | ||
|
说明
此计算属性用于标记不必要或重复的工作,例如发票被拒后重新提交审批,或初次创建后又进行更正。 标记返工后,便于量化其对流程的影响。开票返工率KPI直接根据此属性计算。仪表板可呈现返工频率并衡量其增加的周期时间,帮助定位低效和错误的来源。
重要性
通过标记不必要或重复的工作,直接量化流程低效,便于衡量质量问题造成的成本和时间影响。
获取途径
在数据转换过程中,根据活动顺序计算此属性。例如,同一案例中的“发票批准”活动若发生在“发票被拒绝”之后,就会被标记为返工。
示例
truefalse
|
|||
|
源系统
SourceSystem
|
提取事件数据的记录系统。 | ||
|
说明
此属性用于标识数据来源应用。对于此流程,通常是Oracle Fusion Financials,也可能具体到其中的某个模块,例如Oracle Receivables(AR)。 在集成多个系统的环境中,此字段有助于区分数据来源,对数据验证和治理至关重要。它可确保分析使用的是正确且预期的数据集。
重要性
标识数据来源,对数据治理、问题排查以及确保分析基于正确的记录系统至关重要。
获取途径
通常是在数据提取和转换过程中添加的固定值('Oracle Fusion Financials')。
示例
Oracle Fusion FinancialsOracle AR CloudFusion Apps
|
|||
|
用户
User
|
执行某项活动的员工或系统用户。 | ||
|
说明
用户属性用于标识负责执行某个流程步骤的人员或自动化代理,例如创建发票的用户、批准发票的经理,或发送提醒的催收专员。 按用户分析有助于发现培训机会、了解工作量分布,以及比较个人或团队的绩效。分析还可揭示哪些用户的操作错误率较高,或哪些审批人经常成为瓶颈。
重要性
明确流程步骤的责任归属,支持分析用户绩效、平衡工作量并识别培训需求。
获取途径
数据来自各类交易表和工作流表中的用户ID字段,例如CREATED_BY或LAST_UPDATED_BY。随后将该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
|
|||
|
发票已创建
|
系统中首次创建发票交易记录,通常处于草稿或未完成状态。用户在应收账款模块中首次保存新发票记录时,系统会明确记录此事件。 | ||
|
重要性
这是开票流程的明确起点。分析从创建到完成的耗时,有助于发现前端数据录入延误或系统性能问题。
获取途径
此事件根据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
|
|||
|
发票已结清
|
发票已全额付清并完成对账,生命周期也已结束。通常可根据发票未结余额归零且状态更新来推断此事件。 | ||
|
重要性
这是发票的最终处理结果,标志着流程结束。从开始到达到此状态的总时长即端到端周期时间,是开票流程的一项核心KPI。
获取途径
当AR_PAYMENT_SCHEDULES_ALL表中的状态更新为'CLOSED'且amount_due_remaining为零时,可推断此事件。'gl_date_closed'字段表示关闭日期。
采集
针对具体发票,使用AR_PAYMENT_SCHEDULES_ALL中的gl_date_closed。
事件类型
inferred
|
|||
|
已收到客户付款
|
客户付款已作为现金收款录入系统。此时,款项可能尚未核销到具体发票。 | ||
|
重要性
这是代表现金流入的重要里程碑。从收到付款到将其核销到发票之间的时间差,是衡量现金管理效率的重要指标。
获取途径
AR_CASH_RECEIPTS_ALL表中创建记录时会明确记录此事件。receipt_date表示付款处理日期。
采集
使用AR_CASH_RECEIPTS_ALL表中的creation_date或receipt_date。
事件类型
explicit
|
|||
|
争议已发起
|
客户正式对发票提出异议,系统中已创建争议案例。通常通过更改发票付款计划中的状态标记来记录。 | ||
|
重要性
争议会暂停付款流程,并需要人工处理。分析争议频率和解决时间,有助于找出定价或运输错误等根本原因。
获取途径
可根据AR_PAYMENT_SCHEDULES_ALL表中的状态字段是否设为争议状态推断,也可从AR_DISPUTE_HISTORY中的创建记录获取。
采集
确定发票付款计划中的争议标记或状态何时启用。
事件类型
inferred
|
|||
|
付款到期日已到
|
发票合同约定的付款到期日已过。这不是交易事件,而是根据发票条款和当前日期计算得出的事件。 | ||
|
重要性
此计算事件是账龄分析和计算DSO的基础。它可区分按时付款的发票和逾期发票,便于有针对性地开展催收。
获取途径
这是一个计算事件。当当前日期晚于AR_PAYMENT_SCHEDULES_ALL表中对应发票的due_date字段时,此事件发生。
采集
将当前日期与AR_PAYMENT_SCHEDULES_ALL表中的due_date字段进行比较后计算得出。
事件类型
calculated
|
|||
|
发票已完成
|
表示发票数据录入已完成,交易可进入验证和会计处理阶段。通常通过观察发票状态从“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
|
|||
|
已发送付款提醒
|
已向客户发送逾期发票的催款函或提醒通知。这是催收模块明确记录的操作。 | ||
|
重要性
跟踪提醒有助于衡量催收流程的效果,并分析哪些提醒策略能促使客户更快付款。
获取途径
此事件会在Oracle Advanced Collections模块中明确记录。IEX_DUNNINGS等催款历史表会记录提醒的发送日期和级别。
采集
从催款历史表中获取记录,并将催款交易与发票关联。
事件类型
explicit
|
|||
数据提取指南
立即开始优化Oracle账单与发票流程
借助我们的解决方案,将账单周期时间缩短30%,改善现金流。
无需信用卡,几分钟即可完成设置。