您的订单到收款(计费与开票)数据模板
您的订单到收款(计费与开票)数据模板
- 建议收集的属性
- 需要追踪的关键活动
- Oracle Fusion Financials 数据提取指南
从订单到收款 — 开票与发票管理属性
| 名称 | 描述 | ||
|---|---|---|---|
|
发票编号
InvoiceNumber
|
每张计费发票的唯一标识符,作为跟踪所有相关活动的主要 Case ID。 | ||
|
描述
“发票号码”是计费流程分析的基石。它作为 Case ID,将从发票创建到最终付款及关闭的所有事件关联起来,从而实现对单张账单文档生命周期的完整端到端查看。 在流程挖掘中,按发票号码分析可以实现流程变体可视化、计算单张发票的周期时间,并识别影响特定交易的瓶颈或重复循环。这对于“发票端到端周期时间”等 Dashboard 以及计算每张发票的 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
|
在发票生命周期内特定时间点发生的业务事件或任务的名称。 | ||
|
描述
“活动名称”描述了计费流程中的具体步骤,例如“发票已创建”、“发票已批准”或“已收到客户付款”。这些事件构成了每张发票处理的动作序列。 该属性是流程发现的基础,允许挖掘工具构建发票实际处理方式的可视化地图。它用于分析流程变体、识别重复循环(如多次审批步骤),并衡量每个阶段的频率和持续时间。所有 Dashboard 和 KPI 都依赖此属性来理解流程走向。
为何重要
此属性定义了流程图中的各个步骤,使得可视化、分析和识别发票工作流中的低效环节成为可能。
获取方式
此信息派生自 Oracle Fusion Financials 中的各种表和状态更改,例如工作流历史表(例如与审批相关的表)和交易状态字段。
示例
发票已创建发票已审批已收到客户付款发票已结案
|
|||
|
业务单元
BusinessUnit
|
组织内开具发票的特定业务单位。 | ||
|
描述
“业务单位”代表负责该交易的组织实体。这是大型企业进行财务细分和报告的关键数据元素。 通过此属性,您可以比较公司不同部门的流程绩效。例如,您可以分析不同业务单位之间的 DSO 是否存在显著差异,或者某个单位的计费重复率是否过高。这有助于将改进措施精准对接到最需要的部门。
为何重要
支持不同组织单元间的绩效对比,有助于在细粒度层面识别最佳实践和需改进的领域。
获取方式
存在于 RA_CUSTOMER_TRX_ALL 等交易表中,通常体现为 ORG_ID,用于关联业务单元定义。
示例
US ConsultingEMEA ManufacturingAPAC Services
|
|||
|
到期日期
DueDate
|
发票款项应付的截止日期。 | ||
|
描述
“到期日”是一个关键的日期属性,它根据付款条款定义了发票的付款截止期限。 该属性对于监控回款和财务健康状况至关重要。它是计算“准时付款率”KPI 和创建账龄报告的基准。在 Dashboard 中,它用于通过展示预期付款时间来预测现金流,并识别需要催收的逾期发票。
为何重要
这是衡量付款及时性、计算 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 趋势 Dashboard 以及针对特定客户行为制定催收策略至关重要。
为何重要
允许按客户对流程进行细分,揭示影响现金流的不同行为、付款模式及潜在的协作关系问题。
获取方式
通过将交易表 (RA_CUSTOMER_TRX_ALL) 与客户主数据表 (如 HZ_PARTIES) 关联得出。
示例
Global Tech Inc.Innovate Solutions LLCApex Manufacturing
|
|||
|
DSO(应收账款周转天数)
DaysSalesOutstanding
|
发票日期与收到付款日期之间的天数。 | ||
|
描述
销售变现天数 (DSO) 是衡量发票开具后平均回款时间的财务关键指标。此属性为每张发票独立计算 DSO。 虽然整体 DSO 是核心 KPI,但在单张发票层面进行计算可实现更深层的分析。它可用于创建趋势仪表板,识别高 DSO 发票的特征,并衡量流程延迟对财务的影响。这种细粒度的计算为理解整体 DSO KPI 背后的驱动因素提供了必要数据。
为何重要
在单张发票层面计算关键现金流指标,以便详细分析影响收款时间和财务业绩的因素。
获取方式
这是通过计算“收到客户付款”活动的时间戳与“发票日期”属性之间的时间差得出的。
示例
356228
|
|||
|
争议原因
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 天2% 10,净30
|
|||
|
最后数据更新
LastDataUpdate
|
指示该事件对应数据上次在源系统中被刷新或抽取的时间戳。 | ||
|
描述
此属性提供最近一次数据提取的时间戳。它是一个元数据字段,对于了解所分析数据的时效性至关重要。 分析人员使用此信息来确认他们是在处理最新信息,并了解数据的时新程度。对于宣称“实时”或准实时的 Dashboard 来说,这尤为重要,因为它提供了关于潜在数据延迟的透明度。
为何重要
告知用户数据的时效性,确保分析和结论基于已知且可接受的最新信息。
获取方式
这是在数据提取、转换和加载 (ETL) 过程中生成的元数据字段。它通常对应于数据管道的执行时间。
示例
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
区域
Region
|
与客户或交易相关的地理区域。 | ||
|
描述
“地区”提供了发票的地理背景,通常基于客户所在地,支持对流程绩效进行空间维度分析。 按地区分析可以揭示由当地法规、市场状况或区域团队绩效引起的差异。您可以在 DSO 趋势和发票端到端周期时间等 Dashboard 中按地区进行细分,查看特定区域在结清发票方面是否面临独特挑战。
为何重要
允许按地理区域对流程进行细分,从而突出显示绩效、客户行为或合规性方面的区域差异。
获取方式
这通常派生自存储在 TCA(HZ_LOCATIONS, HZ_PARTY_SITES)中的客户地址信息。它不是发票本身直接显示的字段。
示例
北美欧洲亚太地区
|
|||
|
发票处理周期
InvoiceCycleTime
|
从发票首次创建到关闭的总耗时。 | ||
|
描述
此属性衡量单个案例整个发票生命周期的端到端时长。它的计算方法是第一个活动(通常是“发票已创建”)与最后一个活动(“发票已关闭”)之间的时间差。 该指标提供了整体流程效率的宏观视角。它是“端到端发票周期时间”Dashboard 的主要衡量标准。通过在客户或业务单位等不同维度上分析此属性,企业可以识别哪类发票的处理时间最长,并调查根本原因。
为何重要
提供衡量整体流程速度的核心指标,帮助快速识别哪些发票从开始到结束的处理耗时最长。
获取方式
这是一个计算指标,通过计算每个唯一发票号码的最大和最小事件时间戳之差得出。
示例
45 天 8 小时32 天 2 小时90 天 12 小时
|
|||
|
发票日期
InvoiceDate
|
发票正式开具的日期。 | ||
|
描述
“发票日期”也称为交易日期,是记录在发票凭证上的日期。它是计算付款条款的起点。 该日期是计算应收账款周转天数 (DSO) 的关键组件,因为 DSO 衡量的是从发票日期到付款日期的时长。它与系统中的创建日期不同,代表了从客户角度看付款周期的正式开始。
为何重要
作为发票生命周期的官方起始日期,也是计算应收账款周转天数 (DSO) KPI 的基准。
获取方式
位于 RA_CUSTOMER_TRX_ALL 表中,为 TRX_DATE 字段。
示例
2023-04-142023-05-182023-06-25
|
|||
|
是否按时付款
IsPaidOnTime
|
布尔标志,指示发票是否在到期日或之前支付。 | ||
|
描述
此计算属性提供了一个简单的布尔指标(真或假)来衡量付款及时性。它是通过比较“收到客户付款”活动的日期与发票的“到期日”属性得出的。 此标志简化了“准时付款率”KPI 的分析和报告。它支持轻松的过滤和细分,以了解哪些因素(如客户、地区或发票金额)与逾期付款相关,是评估催收成效的关键指标。
为何重要
简化了回款绩效的衡量,并支持轻松分析导致准时付款与逾期付款的各类因素。
获取方式
通过将最终付款活动的时间戳与 DueDate 属性进行对比得出。逻辑为:
示例
truefalse
|
|||
|
是否返工
IsRework
|
布尔标志,指示活动是否被视为返工,例如重复审批或更正。 | ||
|
描述
此计算属性标记了代表不必要或冗余工作的活动。例如,发票被拒绝后重新提交审批,或者在最初创建后进行更正。 通过标记重复工作,可以轻松量化其对流程的影响。“计费重复率”KPI 直接根据此属性计算。Dashboard 可以直观展示重复工作的频率并衡量其增加的额外周期时间,从而帮助精确定位低效和错误的来源。
为何重要
通过标记不必要或重复的工作,直接量化流程的低效程度,从而轻松衡量质量问题对成本和时间的影响。
获取方式
这是在数据转换期间根据活动序列计算得出的。例如,如果同一案例的“发票已批准”活动之前是“发票已拒绝”活动,则将其标记为重复工作。
示例
truefalse
|
|||
|
源系统
SourceSystem
|
提取事件数据的记录系统。 | ||
|
描述
此属性识别数据的来源应用程序。对于此流程,通常是 Oracle Fusion Financials,但也可以指定其中的特定模块,如 Oracle Receivables (AR)。 在具有多个集成系统的环境中,此字段有助于区分数据源,对于数据验证和治理至关重要。它确保分析是基于正确且预期的数据集进行的。
为何重要
识别数据来源,这对于数据治理、故障排查以及确保分析基于正确的记录系统至关重要。
获取方式
这通常是在数据提取和转换过程中添加的静态值(“Oracle Fusion Financials”)。
示例
Oracle Fusion FinancialsOracle 应收账款云Fusion 应用
|
|||
|
用户
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
|
|||
|
财务部
BillingDepartment
|
负责创建和管理发票的内部部门或团队。 | ||
|
描述
此属性识别组织内处理计费流程的具体团队或部门。它为分析提供了另一层组织背景。 通过按“计费部门”细分流程,公司可以比较不同团队的效率和准确性。它可以帮助识别哪些部门的重复率更高、审批周期更长或对高 DSO 的影响更大,从而突出针对性培训或流程标准化的机会。
为何重要
支持内部团队间的绩效对比,有助于识别最佳实践、资源需求或需流程改进的领域。
获取方式
此信息可能通过将用户与 HR 系统中分配的部门关联(例如通过 PER_ALL_ASSIGNMENTS_F),从创建发票的用户处派生。
示例
企业计费服务开票团队产品销售计费
|
|||
从订单到收款 — 开票与发票管理活动
| 活动 | 描述 | ||
|---|---|---|---|
|
付款已应用于发票
|
收到的客户付款已成功匹配并分摊到特定发票上,减少了其未付余额。这是一条独立的交易记录。 | ||
|
为何重要
此活动确认现金已正确分摊,这对于准确的账龄报告和财务报表至关重要。这是针对应收账款确认现金的最后一步。
获取方式
在 AR_RECEIVABLE_APPLICATIONS_ALL 表中明确记录。apply_date 和 gl_date 字段指示核销发生的时间。
捕获
使用 AR_RECEIVABLE_APPLICATIONS_ALL 表中将现金收据与发票关联的 apply_date。
事件类型
explicit
|
|||
|
发票已创建
|
发票交易在系统中的最初创建,通常处于草稿或未完成状态。当用户在应收账款模块中首次保存新发票记录时,系统会明确记录此事件。 | ||
|
为何重要
这是计费流程的正式起点。分析从创建到完成的时间有助于识别前端数据录入延迟或系统性能问题。
获取方式
此事件从 RA_CUSTOMER_TRX_ALL 表中交易记录的创建日期捕获。初始状态通常为“未完成”。
捕获
使用特定发票号码的 RA_CUSTOMER_TRX_ALL 表中的 creation_date。
事件类型
explicit
|
|||
|
发票已发送给客户
|
发票已通过客户首选的方式(如电子邮件或打印)送达。系统通常会记录执行送达操作的时间戳。 | ||
|
为何重要
此活动标志着付款期限正式开始。衡量从审批到送达的时间是了解发票分发流程效率的关键。
获取方式
这可以从 RA_CUSTOMER_TRX_ALL 中的 'last_printed_date' 字段推断,或者如果使用电子送达,则从 Oracle Business Intelligence Publisher 的日志中推断。
捕获
使用与发票关联的相关送达或打印日志中的时间戳。
事件类型
inferred
|
|||
|
发票已审批
|
发票已获得所有必要审批,准备发送给客户。当审批工作流成功结束并更新发票状态时,将捕获此事件。 | ||
|
为何重要
这是一个关键里程碑,决定了发票何时送达客户。此处的延迟将直接影响付款计时的开始,从而影响 DSO。
获取方式
根据发票交易记录中的最终审批状态更新或相关 BPM 工作流任务的完成时间戳推导得出。
捕获
捕获发票审批状态设为“已批准”时的时间戳。
事件类型
inferred
|
|||
|
发票已结案
|
发票已全额支付并对账,其生命周期结束。当发票的未付余额变为零且状态更新时,通常会推断出此事件。 | ||
|
为何重要
这是发票的最终结算,标志着流程的结束。到达此状态的总时间即为端到端周期时间,是计费流程的核心 KPI。
获取方式
当 AR_PAYMENT_SCHEDULES_ALL 表中的状态更新为“已关闭”且待支付金额为零时推导得出。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
|
|||
|
付款提醒已发出
|
已针对逾期发票向客户发送催款函或提醒通知。这是由催收模块记录的明确操作。 | ||
|
为何重要
跟踪提醒有助于衡量催收流程的有效性,并分析哪种提醒策略能促成更快的付款。
获取方式
在 Oracle Advanced Collections 模块中明确记录。IEX_DUNNINGS 等催款历史表会记录发送提醒的日期和级别。
捕获
从催款历史记录表中获取,将催款交易关联至对应发票。
事件类型
explicit
|
|||
|
到达付款截止日期
|
合同规定的发票付款到期日已过。这并非交易事件,而是根据发票条款和当前日期计算得出的。 | ||
|
为何重要
此计算事件是账龄分析和计算 DSO 的基础。它将准时发票与逾期发票区分开来,支持开展有针对性的催收活动。
获取方式
这是一个计算事件。当当前日期晚于 AR_PAYMENT_SCHEDULES_ALL 表中给定发票的 due_date 字段时,就会发生该事件。
捕获
通过将当前日期与 AR_PAYMENT_SCHEDULES_ALL 中的 due_date 字段进行比较得出。
事件类型
calculated
|
|||
|
发票已完成
|
代表发票数据录入完成、交易准备好进行验证和核算的节点。这通常通过观察发票状态从“未完成”到“已完成”的变化来获取。 | ||
|
为何重要
此里程碑标志着数据录入阶段的结束。从创建到完成的时间可以反映计费部门数据录入和审核流程的效率。
获取方式
根据 RA_CUSTOMER_TRX_ALL 表中发票交易记录的状态更改推导得出。查找与状态更新为“完成”相关联的时间戳。
捕获
跟踪 RA_CUSTOMER_TRX_ALL 或相关工作流表中的交易状态历史记录。
事件类型
inferred
|
|||
|
发票已拒绝
|
审批人拒绝了发票,通常是因为价格或数量等数据错误。此事件会导致发票返回更正,从而产生返工循环。 | ||
|
为何重要
跟踪拒绝情况可以突出计费准确性和内部控制方面的问题。分析拒绝的频率和原因可以精确定位流程改进和培训的领域。
获取方式
根据发票交易记录的状态更新或 BPM 工作流任务中的“已拒绝”结果推导得出。
捕获
捕获发票审批状态设为“已拒绝”时的时间戳。
事件类型
inferred
|
|||
|
发票已提交审批
|
发票被正式提交到审批工作流中(如果已配置)。当发票状态更新为待审批状态并触发对指定审批者的通知时,将捕获此事件。 | ||
|
为何重要
标志着审批周期的开始。追踪此活动对于衡量和分析后续审批时间至关重要,而审批时间是整体发票周期的核心组成部分。
获取方式
根据发票交易的状态更改推导得出,或从记录审批任务发起的 Oracle 业务流程管理 (BPM) 工作流表中获取。
捕获
识别发票审批状态变为“待定”或类似状态时的时间戳。
事件类型
inferred
|
|||
|
发票已调整
|
已对发票金额进行修改,例如核销或冲减。这是更改发票未结余额的明确交易。 | ||
|
为何重要
调整通常意味着争议、折让或更正。分析调整的频率和金额可以揭示“从订单到收款”流程中的深层问题。
获取方式
在 AR_ADJUSTMENTS_ALL 表中明确记录。调整记录的 creation_date 即为该事件的时间点。
捕获
使用相关发票的 AR_ADJUSTMENTS_ALL 表中的 creation_date。
事件类型
explicit
|
|||