您的退货与退款处理数据模板
您的退货与退款处理数据模板
- 建议收集的属性
- 流程分析的关键跟踪活动
- Oracle Fusion SCM 的分步提取指南
退货与退款处理属性
| 名称 | 描述 | ||
|---|---|---|---|
|
Event 时间
EventTime
|
指示特定活动或事件发生时间的时间戳。 | ||
|
描述
事件时间(或开始时间)是活动在源系统中记录的精确日期和时间。它为流程中的每一步提供了时间顺序上下文。 该时间戳对于所有基于时间的分析至关重要。它用于正确排列事件顺序、计算活动间的周期时间、测量案例的总持续时间,以及根据服务水平协议 (SLA) 评估绩效。没有准确的时间戳,就无法分析流程效率、识别延迟或理解流程动态。
为何重要
此属性提供事件的时间顺序,这对于计算所有基于持续时间的指标和发现流程瓶颈至关重要。
获取方式
此信息通常作为与 Oracle Fusion SCM 中的交易或状态记录相关的“创建日期”、“时间戳”或“最后更新日期”字段存在。
示例
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:00:00Z
|
|||
|
活动
ActivityName
|
退货与退款流程中发生的特定业务步骤或事件的名称。 | ||
|
描述
此属性描述了退货生命周期中的单个步骤或里程碑,例如“已创建 RMA”、“物品已检验”或“退款已处理”。每个活动代表系统事件日志中捕获的一个独特时间点。 分析这些活动的顺序和持续时间是流程挖掘的核心。它支持流程图的可视化、识别步骤间的瓶颈以及计算特定活动的交付周期。此数据对于理解流程流向、返工循环以及标准操作程序的合规性至关重要。
为何重要
活动构成了流程图的骨架,能够实现流程流动、变体和瓶颈的可视化与分析。
获取方式
源自 Oracle Fusion SCM 模块(如订单管理和库存管理)中的事件日志、状态更改或特定的事务记录。
示例
已创建 RMA项目已接收贷项通知单已创建退款已处理
|
|||
|
退货案例 ID
ReturnCaseId
|
链接与特定客户退货或退款请求相关的所有活动的主标识符。 | ||
|
描述
退货案例 ID 是整个退货与退款流程的唯一案例标识符。它连接了从最初的退货授权(RMA)创建到最终退款处理和案例关闭的每一个事件。 在流程挖掘分析中,此属性是重建每个退货端到端路径的基础。它允许分析师跟踪完整的生命周期,衡量总周期时间,并了解不同退货处理方式的差异。所有其他事件级数据都按此 ID 分组,以形成完整的流程视图。
为何重要
这是将所有相关事件串联到单个流程实例中,从而实现端到端分析的关键。
获取方式
当启动退货请求时,此标识符通常在 Oracle Order Management 或 Service 模块中生成。
示例
RMA-2023-00123RMA-2023-00456RMA-2023-00789
|
|||
|
最后数据更新
LastDataUpdate
|
从源系统最后一次刷新或提取数据的时间戳。 | ||
|
描述
此属性指示数据集最后一次更新的时间。它提供整个数据集的“新鲜度”日期,而非单个事件的日期。 了解最后一次数据更新时间对于用户理解分析的时效性至关重要。它能帮助用户正确解读仪表板和 KPI,了解看到的是实时信息还是数小时或数天前的数据,是任何流程挖掘项目的关键元数据。
为何重要
向用户告知数据的最新状态,确保他们了解分析的背景和时效性。
获取方式
此时间戳在数据提取、转换与加载(ETL)过程中生成并添加。
示例
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
源系统
SourceSystem
|
数据提取来源系统。 | ||
|
描述
此属性标识记录事件数据的源信息系统。对于此流程,通常为“Oracle Fusion SCM”。 在具有多个集成系统的环境中,此字段对于数据血缘和故障排除至关重要。它有助于确认数据的来源,并可用于筛选特定系统的事件分析,确保数据质量和上下文的准确。
为何重要
它提供了有关数据来源的关键背景信息,这对于多系统环境中的数据验证和分析至关重要。
获取方式
这通常是在数据提取、转换和加载 (ETL) 过程中添加的静态值,用于标记数据集的来源。
示例
Oracle Fusion SCMOracle SCM Cloud
|
|||
|
处理员
ProcessingAgent
|
负责在退货流程中执行特定活动的经办人或代理人。 | ||
|
描述
此属性标识执行特定任务(如批准 RMA 或处理退款)的员工或系统用户。如果不跟踪个人分配,它也可以指代团队或部门。 按经办人分析绩效对于运营管理至关重要。此属性支持“退货处理经办人绩效”仪表板,允许比较不同经办人之间的工作量、活动时长和返工率。这些见解可以突出培训需求、识别优秀员工并为资源分配提供依据。
为何重要
支持按用户或团队进行绩效分析,有助于识别高绩效者、培训机会及工作量不平衡问题。
获取方式
通常可以在 Oracle Fusion SCM 的交易日志中找到,例如 “USER_ID”、“PROCESSED_BY” 或 “AGENT_NAME” 等字段。
示例
j.doea.smithm.jones
|
|||
|
实际退款金额
ActualRefundAmount
|
最终处理并退还给客户的具体金额。 | ||
|
描述
此属性表示在应用所有检验、调整和费用后退还给客户的最终确认金额,反映了退货案例的真实财务结果。 这是一个关键的财务数据点,用于“申请退款金额 vs 实际退款金额”仪表板。将其与申请金额进行对比,是计算“退款金额差异率”KPI 以及了解退货政策、物品状况和处理调整对财务影响的关键。
为何重要
代表退货的真实财务结果,支持差异分析和财务报表。
获取方式
此信息可能来自与 Oracle Fusion Financials 中退货案例链接的红字发票或应付账款交易记录。
示例
129.9940.000.00
|
|||
|
申请退款金额
RequestedRefundAmount
|
客户最初申请退货的金额。 | ||
|
描述
此属性记录了客户在流程开始时申请的退款价值,作为与最终退款对比的基准金额。 该数据点对于“申请退款金额 vs 实际退款金额”仪表板和“退款金额差异率”KPI 至关重要。分析申请金额与实际金额间的差异可以发现诸如退回物品错误、重新上架费或政策调整等问题,从而为财务准确性和客户满意度提供宝贵洞察。
为何重要
作为财务分析的基准,能够计算退款差异并突出潜在问题。
获取方式
此值应存储在 Oracle Fusion SCM 的 RMA 或退货请求标题中,通常位于 Order Management 模块内。
示例
129.9945.501200.00
|
|||
|
结束时间
EndTime
|
指示活动完成时的时间戳。 | ||
|
描述
结束时间标志着活动的完成。虽然 StartTime 指示事件开始的时间,但仍需结束时间来计算该特定事件的实际处理时间。对于瞬时事件,StartTime 和结束时间可以相同。 在分析中,结束时间与 StartTime 之间的差值即为该活动的“处理时间”。这对于识别哪些具体步骤耗时较长(相对于步骤间的等待时间)至关重要。这在详细的瓶颈分析和资源效率计算中必不可少。
为何重要
此属性对于计算单个活动的真实处理时间必不可少,有助于将实际工作时间与等待时间区分开来。
获取方式
这可能是源系统日志中的一个单独字段,也可以从后续活动的 StartTime 推导得出。
示例
2023-10-26T10:05:00Z2023-10-26T15:00:10Z2023-10-27T11:30:00Z
|
|||
|
退款 SLA 目标日期
RefundSlaTargetDate
|
根据服务水平协议(SLA)预计完成退款的日期。 | ||
|
描述
此属性定义了完成特定案例退款流程的截止日期。SLA 目标通常由公司政策、客户层级或退货原因决定。 该日期是衡量及时性和合规性的基准。它直接用于“退款政策 SLA 合规性”仪表板,对于计算“退款 SLA 达成率”KPI 至关重要。将实际退款完成日期与此目标进行对比,可以识别 SLA 违规行为,并帮助优先处理有延迟风险的案例。
为何重要
为衡量准时性绩效提供基准,对于计算 SLA 合规 KPI 至关重要。
获取方式
这可能是退货案例上的一个特定日期字段,也可能需要通过在退货启动日期上增加预定义的时间段(例如 14 天)来计算。
示例
2023-11-10T23:59:59Z2023-11-15T23:59:59Z2023-11-20T23:59:59Z
|
|||
|
退货原因
ReturnReason
|
客户提供的退货原因。 | ||
|
描述
此属性包含退货原因,通常由客户从预定义列表中选择(如“物品缺陷”、“尺寸错误”或“不再需要”)。 分析退货原因可以深入洞察产品质量、销售流程准确性和客户行为。此数据可用于识别缺陷率高的产品、改进产品说明以减少错误订单,并了解退货的根本原因,进而驱动旨在减少退货总量的战略性改进。
为何重要
提供关于退货原因的关键洞察,可用于推动产品和销售流程的改进。
获取方式
通常作为 Oracle Order Management 中 RMA 行项目上的代码或文本字段存储。
示例
有缺陷错发商品送达过晚有更优价格
|
|||
|
退货状态
ReturnStatus
|
退货案例的当前或最终状态。 | ||
|
描述
此属性指示退货案例在特定时间点的整体状态或最终结果,例如“已关闭 - 已退款”、“已关闭 - 已拒绝”或“进行中”。 退货状态是结果分析和监控的关键,支持根据结果筛选案例,比较已批准与已拒绝退货的流程流向,并驱动“当前退货案例状态仪表板”。了解结果分布对于衡量流程有效性至关重要。
为何重要
提供案例结果,这对于筛选、对比分析以及了解流程成功率至关重要。
获取方式
通常作为 Oracle Order Management 中主退货或 RMA 标题记录上的状态字段提供。
示例
等待收货检查完成已关闭 - 已退款已关闭 - 已拒绝
|
|||
|
RMA 编号
RmaNumber
|
退货授权交易的唯一标识符。 | ||
|
描述
RMA 编号是客户退回产品的正式授权。虽然它通常与退货案例 ID 相同,但在某些系统中,它可能是一个独立的、前置的标识符。 此属性作为内部用户和客户都熟悉的业务参考编号,可用于搜索和筛选案例,通常也是退货沟通中使用的主要编号。
为何重要
作为主要的业务参考编号,对于运营跟踪和客户沟通至关重要。
获取方式
这是 Oracle Order Management 中退货授权对象上的主标识符。
示例
789001789002789003
|
|||
|
产品 ID
ProductId
|
退回产品的唯一标识符。 | ||
|
描述
此属性是涉及退货的特定产品的唯一标识符(如 SKU 或项目编号),将退货流程链接到产品目录。 产品级分析对于识别有问题的商品至关重要。通过按产品 ID 筛选或维度化流程分析,公司可以精确定位退货率高、检验时间长或具有特定缺陷模式的产品。此信息对于质量控制、供应链管理和产品开发至关重要。
为何重要
将退货流程与特定产品关联,支持产品质量和退货模式分析。
获取方式
这将是 Oracle Order Management 或 Inventory 模块中 RMA 行项目上的 “INVENTORY_ITEM_ID” 或类似字段。
示例
PROD-5540-ASKU-98765ITEM-001-B
|
|||
|
仓库 ID
WarehouseId
|
接收退货物品的仓库或设施的标识符。 | ||
|
描述
此属性指示接收和处理客户退回物品的具体物理位置,如配送中心或仓库。 按仓库分析流程对于识别特定地点的绩效问题非常重要。它能够比较不同设施之间的检验时间、处置结果和整体周期时间,从而突出特定站点的运营低效、人员配备问题或培训需求。
为何重要
支持按地点进行绩效分析,有助于识别特定区域或设施的瓶颈与低效环节。
获取方式
此字段通常称为 “ORGANIZATION_ID”,与 Oracle Inventory Management 中的接收交易相关。
示例
WH-US-WESTWH-EU-CENTRALDC-01
|
|||
|
安置代码
DispositionCode
|
指示退回实物最终处理方式的代码。 | ||
|
描述
处置代码指定了退回产品在检验后的去向,例如是否返回库存、报废、送去翻新或退回供应商。 这些信息对于分析退货的财务和运营影响非常有价值。通过分析处置代码,企业可以了解不可转售商品相关的成本,并识别改进翻新流程的机会。它将退货流程与库存及财务结果联系起来。
为何重要
将退货流程与其在库存中的物理结果联系起来,提供有关回收率和成本的见解。
获取方式
这些信息在检验活动完成后,在 Oracle Inventory Management 或 Warehouse Management 模块中捕获。
示例
重新入库报废翻新退回供应商
|
|||
|
客户ID
CustomerId
|
发起退货客户的唯一标识符。 | ||
|
描述
此属性是标识与退货案例相关的客户唯一 ID,将退货流程链接到客户数据库。 从以客户为中心的视角分析退货可以揭示重要的模式。例如,它可以帮助识别退货频率异常高的客户,这可能表明存在满意度问题或潜在欺诈。它还支持基于客户细分的分析,帮助了解不同群体是否具有不同的退货行为。
为何重要
实现以客户为中心的分析,有助于识别重复退货者、细分行为并发现潜在欺诈。
获取方式
在 Oracle 订单管理模块中,作为原始销售订单头或退货请求中的客户或参与方 ID。
示例
CUST-100589743ACC-54321
|
|||
|
是否符合SLA
IsSlaCompliant
|
布尔标志,指示退款是否在定义的 SLA 目标时间内处理。 | ||
|
描述
此计算属性为每个退货案例提供了一个简单的 SLA 达成情况(“是”或“否”)。它是通过比较实际退款完成时间戳与 “RefundSlaTargetDate” 得出的。 该标志对于轻松衡量和可视化合规率至关重要。它支持“退款政策 SLA 合规性”仪表板,并简化了“退款 SLA 达成率”KPI 的计算,支持进行快速筛选和根因分析,以了解某些案例未能达到 SLA 的原因。
为何重要
通过将日期对比转换为简单的布尔指标,简化了 SLA 监控和报告。
获取方式
计算字段。如果“退款已处理”时间戳早于或等于“RefundSlaTargetDate”,则为 true,否则为 false。
示例
truefalse
|
|||
|
是否返工
IsRework
|
一个布尔值标志,指示活动是否属于返工循环的一部分。 | ||
|
描述
此标志标识属于同一案例中早期步骤重复的活动,指示流程循环或返工。例如,如果物品检验未通过并必须重新检验,则第二个检验事件将被标记为返工。 此属性是量化流程效率低下的基础。它用于“退货处理返工率”仪表板,并用于计算“退货返工事件频率”KPI。识别返工的数量和原因是流程挖掘的主要目标,因为它直接指向了精力的浪费、延迟和成本的增加。
为何重要
直接标记流程低效环节和循环,便于量化并分析返工原因。
获取方式
这是一个由流程挖掘软件算法识别的计算属性,用于检测单个案例中的重复活动。
示例
truefalse
|
|||
|
端到端退款时间
EndToEndRefundTime
|
从启动退货请求到最终处理退款所经过的总时长。 | ||
|
描述
该指标衡量从客户角度看退款流程的完整持续时间。计算方式为第一个事件(如“已创建 RMA”)的时间戳与退款完成事件(如“退款已处理”)的时间戳之差。 作为核心 KPI,此计算对于“整体退款处理周期时间”仪表板和监控客户体验至关重要。较高的平均时长表示需要解决系统性的效率问题。分析此值的分布有助于识别异常值并从宏观层面理解流程性能。
为何重要
这是一个关键绩效指标,直接衡量整个流程的效率及其对客户满意度的影响。
获取方式
通过为每个退货案例 ID 用“退款已处理”活动的开始时间减去第一个活动的开始时间计算得出。
示例
10天4小时21 天 8 小时5 天 0 小时
|
|||
|
退款金额差异
RefundAmountDiscrepancy
|
申请退款金额与实际退款金额之间的计算差值。 | ||
|
描述
该指标量化了客户申请金额与实际收到金额间的货币差值。它是通过从“申请退款金额”中减去“实际退款金额”来计算的。 此计算值是“退款金额差异率”KPI 的基础。非零值表示在流程中进行了调整。分析差异原因(如重新上架费或损坏扣减)可以深入洞察政策有效性和客户沟通情况。
为何重要
量化退款流程中的财务调整,有助于分析政策和检验结果的影响。
获取方式
计算字段:“RequestedRefundAmount” - “ActualRefundAmount”。
示例
0.005.50-10.00
|
|||
|
退货类型
ReturnType
|
根据预期结果(如退款、换货或维修)对退货进行分类。 | ||
|
描述
此属性对正在处理的退货类型进行分类。流程流向和所需步骤会因客户收到的是货币退款、换货产品还是维修物品而产生显著差异。 按退货类型分析流程对于了解流程变体至关重要。它允许为退款和换货创建单独的流程图,帮助识别每条路径的独特瓶颈和性能特征,这种细分是针对性流程改进工作的关键。
为何重要
允许基于不同的流程路径进行细分分析,因为换货和退款通常遵循不同的步骤。
获取方式
这通常是 Oracle Order Management 中 RMA 标题或行上的类别或类型字段。
示例
退款换货维修
|
|||
退货与退款处理活动
| 活动 | 描述 | ||
|---|---|---|---|
|
RMA 已批准
|
这一关键里程碑表示退货请求已根据业务规则通过验证和批准。这通常是根据 RMA 的状态变化推断出来的,从而解锁后续的流程步骤(如客户发货)。 | ||
|
为何重要
审批是流程中的关键关卡。此处的延误会直接影响总退货周期和客户满意度。该活动对于分析审批瓶颈至关重要。
获取方式
根据 RMA 订单头或行状态更改为“已批准”或“等待收货”时的时间戳推导得出。
捕获
获取 RMA 状态更新为已批准状态时的时间戳。
事件类型
inferred
|
|||
|
已创建 RMA
|
此活动标志着退货流程的正式开始,即在 Oracle Fusion SCM 中创建退货授权(RMA)。当用户或自动化流程生成新的 RMA 销售订单记录时,通常会捕获此显性事件。 | ||
|
为何重要
这是整个退货流程的主要开始事件。分析从此活动到其他活动的时间,可以揭示整体流程持续时间并帮助识别初始延迟。
获取方式
这是从 Oracle Fusion Order Management 中退货单标题记录的创建时间戳捕获的。该事件对应于 RMA 文档的初始保存。
捕获
跟踪退货单标题记录的创建日期。
事件类型
explicit
|
|||
|
物料已检验
|
此活动标志着物品检验流程的完成及质量评估的记录。这通常是 Oracle Inventory Management 或 Quality Management 中更新 RMA 状态的显性交易。 | ||
|
为何重要
检验结果直接影响接下来的步骤(如退款批准或拒绝)。检验活动本身的持续时间是衡量仓库效率的关键绩效指标。
获取方式
在 Oracle 库存或质量管理模块中,检验员完成针对 RMA 入库单的检验任务时的事务时间戳。
捕获
使用检验交易的完成时间戳。
事件类型
explicit
|
|||
|
贷项通知单已创建
|
这是在 Accounts Receivable 中生成红字发票以授权向客户退款的财务活动。这是由 Order Management 中的退货流程触发的显性事件。 | ||
|
为何重要
创建红字发票(贷记通知单)是一个明确的里程碑,表明公司已承诺向客户退款。它是整个财务结算流程的触发点。
获取方式
这是 Oracle Accounts Receivable 中的显性交易。该事件可以通过红字发票上的销售订单参考链接回原始 RMA。
捕获
使用 AR 中红字发票交易的创建日期。
事件类型
explicit
|
|||
|
退款已处理
|
此活动标志着向客户支付退款的完成。这是在 Oracle Financials 中记录付款结算交易时捕获的显性事件。 | ||
|
为何重要
这是从客户角度衡量总退款周期时间的关键节点,它确认了公司已履行对客户的财务义务。
获取方式
此事件是从 Oracle Accounts Payable 或 Treasury 中结算红字发票的支付交易的会计或清算日期中捕获的。
捕获
使用结算红字发票的支付交易的清算日期。
事件类型
explicit
|
|||
|
退货案例已关闭
|
这是最后的活动,表示与 RMA 相关的所有操作(包括收货、处置和财务结算)均已完成。这是根据 RMA 订单的最终“已关闭”状态推断得出的。 | ||
|
为何重要
此事件作为流程的正式结束,对于计算端到端周期时间和确保没有案例无限期处于开启状态至关重要。
获取方式
根据 Oracle 订单管理模块中 RMA 订单头及其所有行达到最终“已关闭”状态时的时间戳推导得出。
捕获
获取 RMA 头或行状态更改为“已关闭”时的最后时间戳。
事件类型
inferred
|
|||
|
项目已接收
|
此活动标志着在仓库或处理中心物理收到退回物品。当在 Oracle Fusion Inventory Management 中扫描货物并记录为针对 RMA 收货时,会捕获此显性事件。 | ||
|
为何重要
收到货物是一个关键里程碑,它会触发后续的检验和处理步骤。测量从“RMA 已批准”到“收到货物”的时间有助于分析物流和运输绩效。
获取方式
这是 Oracle Inventory Management 中记录的显性交易。该事件对应于 RMA 收货的交易日期。
捕获
使用 Inventory 中 RMA 收货的交易时间戳。
事件类型
explicit
|
|||
|
RMA 审批已提交
|
这代表创建的 RMA 提交内部审查和审批的时间点。通常根据 RMA 的状态变化推断得出,表示其已从草稿状态变为待审批状态。 | ||
|
为何重要
跟踪此项有助于衡量预审批阶段的持续时间,从而将数据录入时间与实际等待审批人采取行动的时间区分开来。
获取方式
根据订单管理审批工作流中 RMA 订单头或行状态更改为“待审批”或等效状态时的时间戳推导得出。
捕获
识别状态更改为“待审批”时的时间戳。
事件类型
inferred
|
|||
|
RMA 已拒绝
|
代表拒绝客户退货请求的最终决策。通常根据审批阶段 RMA 状态更改为“已拒绝”或“已取消”推导得出。 | ||
|
为何重要
这是一个关键的异常路径。分析拒绝的频率和原因可以揭示退货政策、客户预期或欺诈企图方面的问题。
获取方式
根据 RMA 订单头或行状态更改为“已拒绝”或等效终止状态时的时间戳推导得出。
捕获
识别状态更改为“已拒绝”或“已取消”时的时间戳。
事件类型
inferred
|
|||
|
客户已发出货物
|
代表客户将退货物品寄回公司的行为。该事件通常不会直接记录在 Oracle SCM 中,但可以从承运商集成数据或手动更新中推导得出。 | ||
|
为何重要
此活动提供了对客户行为和货物运输时间的洞察,有助于区分内部处理延迟和由于物流造成的延迟。
获取方式
这可能是基于链接到 RMA 的承运商运输数据的推断事件,或者是 Oracle SCM 中的手动状态更新。如果不存在集成,此事件可能不可用。
捕获
来自集成承运商 API 或手动数据录入字段的时间戳。
事件类型
inferred
|
|||
|
已通知客户
|
这表示发送给客户以确认其退货案例解决情况的沟通(例如退款已处理或换货已发货),通常是从沟通日志或案例的状态更新中捕获的。 | ||
|
为何重要
及时的客户沟通对于满意度至关重要。分析这一点有助于确保符合沟通相关的服务水平协议(SLA)。
获取方式
需要系统分析。这可能由集成的 CRM 或沟通平台记录,也可能是 RMA 或相关服务请求上的手动状态更新。
捕获
来自外部沟通系统的时间戳或手动更新。
事件类型
inferred
|
|||
|
换货单已创建
|
此活动发生在客户要求换货而非退款的场景中。这是一个显性事件,会生成新的销售订单,且通常链接到原始 RMA。 | ||
|
为何重要
此活动识别了一个重要的流程变体。将换货流程与退款流程分开是准确分析每条路径周期时间的关键。
获取方式
这是一个显性事件,即在 Order Management 中创建新的销售订单文档,需要通过参考字段链接回 RMA。
捕获
使用链接到 RMA 的新销售订单的创建日期。
事件类型
explicit
|
|||
|
货物检验已开始
|
指示开始对退回物品进行实物检验以评估其状况。这可以从仓库管理模块中物品位置或状态的更改中推导出来,也可以是明确的扫描操作。 | ||
|
为何重要
测量从货物收讫到开始检验之间的时间,可以突出显示检验站的排队延迟,这是一个常见的瓶颈。
获取方式
这可能通过收货行上的状态更改或物品移动到 Oracle Inventory Management 中的检验地点来捕获。可能需要自定义配置才能显式捕获。
捕获
状态更改或库存转移到检验区域的时间戳。
事件类型
inferred
|
|||
|
退款已发起
|
此活动标志着退款的支付流程已经开始。通常根据红字发票的状态变化推断得出,即从待处理状态变为正在处理支付的状态。 | ||
|
为何重要
此活动有助于将红字发票的批准和创建与实际的付款处理分开,后者可能由不同的团队或系统处理,且可能是产生延迟的根源。
获取方式
根据应收账款中贷项通知单的状态更改,或应付账款中引用该贷项通知单生成的付款记录推导得出。
捕获
识别贷项通知单状态更改为“待付款”或类似状态时的时间戳。
事件类型
inferred
|
|||
|
退货处置已确定
|
检验之后,此活动代表对退回物品处理方式的决策,例如“重新入库”或“报废”。这是通过将物品移动到最终目的地的显式库存事务记录的。 | ||
|
为何重要
此步骤对于库存准确性和财务对账至关重要。分析处置情况有助于了解退货原因和产品质量问题。
获取方式
检验后,记录为 Oracle 库存管理模块中的一项事务,例如子库存转移或物品状态更新。
捕获
跟踪执行处置的库存交易的时间戳。
事件类型
explicit
|
|||