您的订单到收款:开票与发票处理数据模板
您的订单到收款:开票与发票处理数据模板
- 建议收集的属性
- 需要跟踪的关键活动
- Oracle E-Business Suite数据提取指南
订单到收款:开票与发票处理属性
| 名称 | 说明 | ||
|---|---|---|---|
|
事件时间
EventTime
|
活动发生的确切日期和时间。 | ||
|
说明
事件时间是与每项活动关联的时间戳,用于确定案例中各事件的先后顺序,也是流程挖掘中所有时间分析所用的原始数据。 此属性对于计算周期时间、活动间隔时长和流程周期时间等关键绩效指标至关重要。例如,“发票已生成”与“发票已批准”的事件时间之差就是审批时长。准确且完整的时间戳是可靠分析流程的基础。
重要性
它为每个事件提供时间信息,使您能够计算时长、分析流程表现并发现瓶颈。
获取途径
数据来自Oracle EBS各表中的日期字段,例如RA_CUSTOMER_TRX_ALL和AR_CASH_RECEIPTS_ALL中的CREATION_DATE或LAST_UPDATE_DATE。
示例
2023-04-15T10:00:00Z2023-04-20T14:35:10Z2023-05-15T00:00:00Z
|
|||
|
发票编号
InvoiceNumber
|
每份发票单据的唯一标识符,也是开票流程的主要案例ID。 | ||
|
说明
发票编号是订单到收款开票分析的核心,可唯一标识每笔开票交易。它将生成、审批、发送、付款和结清等相关活动归入同一个流程实例,完整呈现发票的端到端生命周期。 在流程挖掘中,按发票编号分析流程,有助于衡量总周期时间、识别发票处理方式的差异,并找出导致付款延迟的瓶颈。要跟踪每张发票从创建到结清的完整过程,发票编号不可或缺。
重要性
这是关键的案例标识符,可关联所有相关事件,从而重建并分析每张发票的完整处理流程。
获取途径
通常是Oracle应收账款表RA_CUSTOMER_TRX_ALL中的交易编号。
示例
INV-9234501788144US-2023-001293
|
|||
|
活动名称
ActivityName
|
发票生命周期中某个时间点发生的具体业务事件名称。 | ||
|
说明
活动名称用于描述开票流程中的步骤或节点,例如“发票已生成”“发票已批准”或“已收到客户付款”。同一发票编号下这些活动按时间排列后,便构成流程路径。 此属性是流程挖掘的基础,用于构建流程图、分析流程变体,以及识别偏差或返工循环。活动名称清晰且一致,才能有效分析特定步骤之间的耗时或流程是否符合要求。
重要性
此属性是发现和呈现流程路径的基础,可用于分析流程变体、瓶颈和返工。
获取途径
通常通过将Oracle EBS各表中的状态变化、事件类型或记录创建/更新事件(如AR_PAYMENT_SCHEDULES_ALL、RA_CUSTOMER_TRX_ALL)映射为标准活动名称得出。
示例
发票已生成发票已批准已到付款到期日已收到客户付款
|
|||
|
到期日
DueDate
|
客户应支付发票的截止日期。 | ||
|
说明
到期日是重要的日期属性,根据付款条款确定发票的付款期限,也是衡量实际付款表现的基准。 此属性对于计算按时付款率等指标和生成发票账龄报告至关重要。在流程挖掘中,它可用于分析付款行为,例如识别经常逾期付款的客户,或评估流程延误对按时回款的影响。
重要性
这是衡量付款表现、计算发票账龄以及评估逾期付款或坏账风险的基准。
获取途径
位于AR_PAYMENT_SCHEDULES_ALL表的DUE_DATE列。
示例
2023-05-152023-06-302023-07-01
|
|||
|
发票总金额
TotalInvoiceAmount
|
发票的货币总额,包括所有行项目、税费和其他费用。 | ||
|
说明
此属性表示发送给客户的发票总金额,是开票流程财务分析的一项基础指标。 在流程挖掘中,发票总金额可用于划分和筛选案例。例如,分析人员可以比较高金额与低金额发票的流程路径,了解处理方式是否不同。该属性也适用于财务影响分析,例如计算滞留在审批环节的发票金额。
重要性
支持财务影响分析,帮助用户按金额确定问题的优先级,并了解不同发票金额对流程的影响。
获取途径
可能来自AR_PAYMENT_SCHEDULES_ALL表中的AMOUNT_DUE_ORIGINAL字段,也可能根据特定发票在RA_CUSTOMER_TRX_LINES_ALL中的数据计算得出。
示例
1500.0012550.75500.50
|
|||
|
发票状态
InvoiceStatus
|
发票生命周期中的当前状态。 | ||
|
说明
发票状态反映发票当前所处的状态,例如“未结”“已结清”或“存在争议”,可用于快速了解发票进度。 此属性对于创建“发票账龄与状态概览”等仪表板至关重要,用户可快速查看不同状态下的发票数量和金额。它有助于优先处理未结发票的催收工作,并概览应收账款组合的整体状况。
重要性
呈现发票当前状态,对于运营仪表板、工作量管理和催收活动优先级排序至关重要。
获取途径
位于AR_PAYMENT_SCHEDULES_ALL表的STATUS列(“OP”表示未结,“CL”表示已结清)。
示例
未结已结清存在争议
|
|||
|
客户ID
CustomerId
|
开具发票的客户的唯一标识符。 | ||
|
说明
客户ID将发票关联到主数据中的特定客户账户,便于汇总和比较不同客户的流程表现。 借助此属性,分析人员可以创建仪表板,呈现客户付款行为,识别争议或返工最多的客户,并比较不同客户群的发票处理时间。它是从单纯的流程视角转向以客户为中心分析的关键。
重要性
支持以客户为中心的分析,帮助识别付款模式、频繁发生的争议,以及特定客户相关的流程差异。
获取途径
位于RA_CUSTOMER_TRX_ALL表的SOLD_TO_CUSTOMER_ID或BILL_TO_CUSTOMER_ID字段。
示例
CUST-100239845ACME-US-01
|
|||
|
用户
User
|
执行活动人员的用户ID。 | ||
|
说明
此属性用于识别负责执行流程步骤的具体员工或系统用户,例如审批发票或核销收款。它对于了解流程中的人为因素至关重要。 按用户分析有助于发现培训机会、工作量分配不均和个人表现差异。例如,您可以找出返工最多或审批时间最长的用户,进而有针对性地改进流程。
重要性
支持个人层面的绩效分析,帮助识别表现突出的用户、培训需求和潜在的工作量分配不均。
获取途径
数据来自各交易表中的CREATED_BY或LAST_UPDATED_BY等用户ID字段。随后将此ID与FND_USER关联,以获取用户名。
示例
JSMITHBWILLIAMSCDAVIS
|
|||
|
部门
Department
|
执行活动的用户所属部门或职能团队。 | ||
|
说明
部门属性为执行活动的用户提供组织背景,例如“应收账款”或“销售运营”。您可以据此按团队或部门汇总分析结果。 这对于了解组织不同部门如何参与并影响开票流程至关重要。它有助于发现部门内部的系统性问题、比较团队表现并分析资源配置。例如,您可以在“发票审批周期时间”仪表板中按部门查看数据。
重要性
支持按组织架构分析流程表现,呈现团队间的差异,并帮助定位部门特有的瓶颈。
获取途径
通常通过将用户信息与组织的人力资源层级数据关联得出,数据常来自PER_ALL_ASSIGNMENTS_F或类似的人力资源表。
示例
应收账款财务运营开票服务
|
|||
|
业务单元
BusinessUnit
|
公司内开具发票的具体业务单元或运营单元。 | ||
|
说明
业务单元代表负责该交易的组织实体。在Oracle EBS中,通常以运营单元表示。 借助此属性,您可以比较企业不同部门的流程绩效,判断哪些业务单元效率更高、按时付款率更高或争议更多,从而推广最佳实践并采取有针对性的改进措施。
重要性
支持比较组织不同部门的绩效,帮助识别最佳实践和各部门面临的挑战。
获取途径
在RA_CUSTOMER_TRX_ALL等大多数交易表中,可通过ORG_ID隐式获取运营单元信息。
示例
美国业务部欧洲、中东和非洲服务部全球制造部
|
|||
|
付款条款
PaymentTerms
|
规定客户必须何时支付发票的约定条款。 | ||
|
说明
付款条件规定了付款要求,例如“Net 30”或“Net 60”,用于计算发票到期日。这是重要的主数据,会直接影响现金流。 按付款条件分析,有助于了解不同条款对付款行为和应收账款周转天数(DSO)的影响。例如,您可以判断付款期限较短的客户是否付款更快,并据此决定向不同客户群提供哪些付款条件。
重要性
付款条件会直接影响发票到期日和现金流预测。分析付款条件有助于评估不同信用政策的效果。
获取途径
数据来自RA_TERMS_B表,通过RA_CUSTOMER_TRX_ALL表中的TERM_ID关联。
示例
Net 30(30天内付款)Net 60(60天内付款)收到发票后立即付款
|
|||
|
客户名称
CustomerName
|
开具发票的客户的法定名称。 | ||
|
说明
客户名称为客户提供易于识别的名称。客户ID用于关联数据和唯一标识,客户名称则用于在报告和仪表板中显示。 这样可以让分析更直观,用户无需查询ID即可识别客户。它对于创建易用的可视化内容至关重要,例如按客户展示平均付款延迟的条形图。
重要性
提供易于识别的客户名称,便于在仪表板和报告中筛选、分组,让分析更易于理解。
获取途径
使用发票抬头中的客户ID关联HZ_PARTIES和HZ_CUST_ACCOUNTS表获取。
示例
环球公司创新解决方案有限公司测试公司
|
|||
|
客户所在国家/地区
Country
|
客户账单地址所在的国家/地区。 | ||
|
说明
此属性指定客户账单地址所在的国家/地区,为流程分析提供地理维度。 按国家/地区分析流程,可以发现付款行为、流程效率或当地法规合规情况的区域差异。例如,您可以在“客户付款行为洞察”仪表板中查看各国/地区的平均付款延迟是否存在显著差异。
重要性
支持从地理维度分析流程,揭示客户行为、法规影响和运营绩效方面的区域差异。
获取途径
通过客户账户表关联客户账单地址信息,数据来自HZ_LOCATIONS和FND_TERRITORIES。
示例
USA德国英国
|
|||
|
币种
Currency
|
发票金额所用的币种代码。 | ||
|
说明
此属性指定发票金额所用的币种,例如USD或EUR,为所有财务指标提供必要背景。 分析跨国业务数据时,币种属性对于正确解读和比较财务金额至关重要。仪表板可据此按币种筛选,或应用汇率生成合并报告。
重要性
为所有财务属性提供必要背景,确保在多币种环境中准确解读和分析数据。
获取途径
通常位于RA_CUSTOMER_TRX_ALL表的INVOICE_CURRENCY_CODE列。
示例
USDEURGBP
|
|||
|
应收账款周转天数
DaysSalesOutstanding
|
从生成发票到收到付款之间的天数。 | ||
|
说明
应收账款周转天数(DSO)是一项重要的财务指标,用于衡量发票生成后平均需要多少天才能收款。此属性按每张发票分别计算。 虽然整体KPI采用平均值,但保留每张发票的数值有助于开展深入分析。您可以据此查看分布、识别异常值,并分析收款效率随时间变化的趋势。“DSO趋势”仪表板会直接展示此属性的时间平均值。
重要性
衡量单张发票的收款效率,为趋势分析提供原始数据,并帮助识别与较高DSO相关的因素。
获取途径
在数据转换过程中计算。逻辑:Timestamp('Customer Payment Received') - Timestamp('Invoice Generated')。
示例
304592
|
|||
|
数据最后更新时间
LastDataUpdate
|
表示此事件数据最近一次从源系统刷新或提取时间的时间戳。 | ||
|
说明
此属性记录最近一次数据提取的时间戳,对于了解所分析数据的新旧程度至关重要。 用户可通过此字段判断仪表板和分析是否反映流程的最新状态。它有助于了解数据延迟情况,也是可靠数据模型的重要元数据。
重要性
让用户了解数据的时效性,明确流程分析反映的是哪个时间点的情况。
获取途径
这是在数据提取、转换和加载(ETL)过程中生成并写入每条记录的元数据字段。
示例
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
是否按时付款
IsPaidOnTime
|
计算得出的标记,用于指示发票是否在到期日当天或之前付清。 | ||
|
说明
这是一个布尔属性,通过比较“收到客户付款”时间戳与发票“到期日”得出。按时或提前付款时为true,逾期付款时为false。 此标记可简化付款绩效相关KPI和仪表板的创建,是计算“按时付款率”KPI的直接依据,也便于将发票筛选并划分为“按时”和“逾期”两类,以便进一步分析根因。
重要性
直接支持“按时付款率”KPI,并通过将发票划分为“按时”和“逾期”两类,简化分析。
获取途径
在数据转换过程中计算。逻辑:IF (Timestamp('Customer Payment Received') <= Date('DueDate')) THEN true ELSE false。
示例
truefalse
|
|||
|
是否返工
IsRework
|
计算得出的标记,用于指示发票是否经历过修改或重新审批等返工活动。 | ||
|
说明
如果发票流程包含表明发生返工的活动,例如“发票已修改”或第二次“发票已批准”事件,此布尔标记就设为true。借助此标记,您可以快速识别偏离标准高效路径的发票。 此属性对“发票错误率”和“人工返工率”等KPI至关重要。分析人员可以轻松统计返工频率,筛选出效率低下的案例并调查根因,例如找出最常参与返工活动的用户或部门。
重要性
标记需要额外非标准步骤的发票,量化流程效率损失,并支持分析返工的原因和影响。
获取途径
在数据转换过程中,通过检测案例中的特定活动顺序来计算,例如“发票已批准”后出现“发票已修改”。
示例
truefalse
|
|||
|
源系统
SourceSystem
|
提取数据的记录系统。 | ||
|
说明
此属性用于标识事件数据的来源应用程序。对于此流程,来源始终为Oracle E-Business Suite。 在包含多个系统的环境中,此字段对于数据溯源和故障排查至关重要。即使只有一个系统,它也是数据治理所需的字段,可确认数据来自预期来源。
重要性
确保数据可追溯并提供必要背景,这对于数据治理以及整合多个企业系统的数据至关重要。
获取途径
在数据提取过程中设置的静态值,用于标识来源ERP系统。
示例
Oracle E-Business SuiteOracle EBS R12
|
|||
|
销售订单编号
SalesOrderNumber
|
用于标识创建该发票的原始销售订单。 | ||
|
说明
销售订单编号可直接关联到订单到收款周期中前序的“订单管理”环节,将开票流程与最初的客户订单联系起来。 借助此属性,您可以开展跨流程分析。例如,分析人员可以调查某些类型的销售订单是否经常引发开票争议或付款延迟。单独分析开票流程时,这些重要背景往往会被忽略。
重要性
将开票流程与上游销售流程关联,支持更全面的订单到收款分析和根因调查。
获取途径
通常位于发票行表RA_CUSTOMER_TRX_LINES_ALL的参考字段或接口属性字段中,例如INTERFACE_LINE_ATTRIBUTE1或类似的描述性弹性字段。
示例
SO-54321601882ORD-2023-9910
|
|||
订单到收款:开票与发票处理活动
| 活动 | 说明 | ||
|---|---|---|---|
|
发票已发送给客户
|
表示发票已通过打印或电子方式正式发送给客户。此事件标志着客户付款期限开始计算。 | ||
|
重要性
这是衡量发票送达周期和后续付款延迟的重要节点,有助于区分内部处理延误与客户付款行为。
获取途径
Oracle EBS并不总是在标准字段中明确记录此事件。可根据“发票打印”并发程序的时间戳推断,也可使用电子送达时设置的自定义标记。
采集
根据发票打印程序的完成日期或电子发送的自定义逻辑推断。
事件类型
inferred
|
|||
|
发票已生成
|
表示系统中创建了一笔新的发票交易。通常由“自动发票导入程序”处理已履行的销售订单行后触发,也可能通过应收账款模块手动录入发票。 | ||
|
重要性
这是开票流程的起点。分析此事件与其他事件之间的时间间隔,可以了解发票的完整生命周期,并发现早期环节的瓶颈。
获取途径
记录为Oracle应收账款表RA_CUSTOMER_TRX_ALL中的交易创建日期。可使用TRX_DATE或CREATION_DATE作为事件时间戳。
采集
事件时间为RA_CUSTOMER_TRX_ALL表中记录的创建时间戳。
事件类型
explicit
|
|||
|
发票已结清
|
发票正式结清,表示其余额因付款、贷项通知单和/或调整而归零。这标志着发票生命周期顺利结束。 | ||
|
重要性
这是流程的主要终点。从“发票已生成”到“发票已结清”的总周期时间,是衡量订单到收款开票周期整体效率的重要指标。
获取途径
根据AR_PAYMENT_SCHEDULES_ALL表中的STATUS字段变为“CL”(已结清)推断。导致结清的最后一笔交易日期可用作时间戳。
采集
根据AR_PAYMENT_SCHEDULES_ALL中的状态变为“CL”推断,并以最后一笔相关核销的时间作为时间戳。
事件类型
inferred
|
|||
|
已收到客户付款
|
客户付款已作为现金收款录入系统。此时,付款可能尚未核销到具体发票。 | ||
|
重要性
这是计算应收账款周转天数(DSO)的重要节点。从生成发票到收到付款的时间,是衡量催收效率的主要指标。
获取途径
在AR_CASH_RECEIPTS_ALL表中创建记录时,系统会明确记录此事件及其时间戳。
采集
事件时间为AR_CASH_RECEIPTS_ALL表中记录的创建时间戳。
事件类型
explicit
|
|||
|
已核销收款/已对账
|
收到的客户付款已成功核销到一张或多张具体发票,从而减少未结余额。这表示付款已与欠款完成对账。 | ||
|
重要性
这是付款流程的最后一步,也是衡量收款核销周期时间的关键环节。此处延误可能导致客户账户余额失真,并影响信用管理。
获取途径
在AR_RECEIVABLE_APPLICATIONS_ALL中创建关联现金收款与交易的记录时,系统会明确记录此事件及其时间戳。
采集
事件时间为AR_RECEIVABLE_APPLICATIONS_ALL中记录的创建时间戳(GL_DATE或APPLY_DATE)。
事件类型
explicit
|
|||
|
付款已冲销
|
表示此前收到的客户付款已被冲销。通常是由于资金不足(NSF)或其他银行处理错误所致。 | ||
|
重要性
付款冲销会影响现金流预测,并增加管理工作。跟踪这些事件有助于发现存在问题的客户或付款方式。
获取途径
这是Oracle应收账款中的明确操作。冲销会在AR_CASH_RECEIPT_HISTORY_ALL中生成记录,状态会标记为“REVERSED”等。
采集
根据AR_CASH_RECEIPT_HISTORY_ALL表中的状态变为“REVERSED”识别。
事件类型
explicit
|
|||
|
发票已修改
|
表示现有的未完成发票已更新或更正,例如在发票完成或发送前修改行项目、金额或开票信息。 | ||
|
重要性
频繁修改可能表明流程效率低、数据质量存在问题或发生了用户操作错误。分析此活动有助于量化返工及其对周期时间的影响,并支持“发票错误率”等指标的分析。
获取途径
可通过比较RA_CUSTOMER_TRX_ALL表中未完成发票的CREATION_DATE和LAST_UPDATE_DATE推断。若启用了审计,也可以更明确地跟踪变更。
采集
通过跟踪RA_CUSTOMER_TRX_ALL表中的LAST_UPDATE_DATE推断更新情况。
事件类型
inferred
|
|||
|
发票已批准
|
表示手动录入或审核后的发票已完成正式内部审批,准备发送给客户。此活动可能属于已配置的Oracle工作流,也可能通过手动更改状态完成。 | ||
|
重要性
跟踪审批时间对于“发票审批周期时间”指标至关重要。审批延误会直接推迟客户开票,并延长整体现金转换周期。
获取途径
此事件通常取决于具体配置。可根据工作流表(如WF_ITEM_ACTIVITY_STATUSES)中的状态变化推断,也可能通过RA_CUSTOMER_TRX_ALL中发票交易的描述性弹性域推断。
采集
根据工作流表中的状态变化或自定义状态字段推断。
事件类型
inferred
|
|||
|
已创建核销
|
通过调整将剩余发票余额的全部或部分确认为坏账。通常在催收手段用尽后进行。 | ||
|
重要性
核销意味着直接收入损失。分析核销的频率和金额,有助于完善信用政策,并了解无法收回的欠款对财务的影响。
获取途径
此事件记录为针对发票的特定类型调整交易。可在AR_ADJUSTMENTS_ALL表中查找,并关联到为核销定义的应收款活动类型。
采集
事件是AR_ADJUSTMENTS_ALL中创建活动类型为“核销”的记录。
事件类型
explicit
|
|||
|
已创建贷项通知单
|
系统生成一笔贷项通知单交易,通常用于更正开票错误或处理退货,并应用于现有发票。这是应收账款中的一笔独立但相关的交易。 | ||
|
重要性
贷项通知单数量较多,可能说明订单履行、定价或初始开票准确性存在上游问题。分析这些事件有助于查明收入流失和客户不满的根因。
获取途径
在RA_CUSTOMER_TRX_ALL中记录为一笔新交易,其中CUST_TRX_TYPE_ID关联到类别为“CM”(贷项通知单)的类型。PREVIOUS_CUSTOMER_TRX_ID字段用于关联原始发票。
采集
事件是RA_CUSTOMER_TRX_ALL中创建贷项通知单交易类型记录。
事件类型
explicit
|
|||
|
已到付款到期日
|
根据付款条款计算出的发票到期日。此事件并非由用户或系统操作触发,但它是重要的时间节点。 | ||
|
重要性
此事件对于计算按时付款率和分析客户付款行为至关重要。它是判断付款提前、按时或逾期的基准。
获取途径
此事件不会作为事件记录,而是通过将系统日期与特定发票在AR_PAYMENT_SCHEDULES_ALL表中的TERM_DUE_DATE字段进行比较来计算。
采集
通过将当前时间戳与AR_PAYMENT_SCHEDULES_ALL.TERM_DUE_DATE进行比较得出。
事件类型
calculated
|
|||
|
已发送付款提醒
|
已向客户发送逾期发票的催款通知或提醒。这是催收流程中的一项重要活动。 | ||
|
重要性
跟踪此活动对于衡量催收策略的效果至关重要。您可以分析提醒发送前后的付款率。
获取途径
如果使用Oracle Advanced Collections,发送催款函会作为明确事件记录。若未使用此模块,该活动通常在系统外进行,可能无法可靠跟踪。
采集
记录为Oracle Advanced Collections模块中的催款函往来事件。
事件类型
explicit
|
|||
|
已提出争议
|
客户已正式对发票提出争议,在争议解决前暂停催收活动。通常通过Oracle Advanced Collections管理,也可能通过手动更新状态处理。 | ||
|
重要性
争议会延迟付款,直接影响现金流。跟踪争议发生频率和解决时间,有助于发现产品、服务或开票准确性方面的反复问题。
获取途径
如果使用Oracle Advanced Collections,此事件会作为明确的交易记录。否则,可根据应收账款中的特定“争议”状态或发票冻结状态推断。
采集
记录为Oracle Advanced Collections中的交易,或根据发票状态变化推断。
事件类型
explicit
|
|||
数据提取指南
立即加快订单到收款的开票与发票处理
将开票周期时间缩短30%,加快现金回笼。
无需信用卡,几分钟即可完成设置。