您的“从订单到现金 - 计费与开票”数据模板
您的“从订单到现金 - 计费与开票”数据模板
这是我们针对Order to Cash - 计费与开票的通用流程挖掘数据模板。使用我们针对特定系统的模板以获得更具体的指导。
选择特定系统- 适用于任意系统的通用起点。
- 用于深度分析的推荐属性。
- 映射您的计费和开票流向的关键活动。
Order to Cash - 计费与开票属性
| 名称 | 描述 | ||
|---|---|---|---|
| Event 时间 EventTime | 指示特定活动或事件发生的精确时间戳。 | ||
| 描述 事件时间(即 timestamp)记录了 activity 执行或状态变更发生的准确日期和时间。此类 temporal data 对于理解流程步骤的时机和持续时间至关重要。 在分析中,事件时间用于按时间顺序排列活动,计算步骤之间的耗时、活动持续时间以及每个 case 的端到端周期总时间。它是识别瓶颈、对照服务水平协议 (SLA) 衡量绩效以及分析长期趋势的基础。没有准确的 timestamp,就无法进行绩效和时长分析。 为何重要 此时间戳对于计算所有基于时间的指标(如周期时间和持续时间)至关重要,是识别瓶颈的基石。 获取方式 通常可在交易日志、变更单据或单据抬头及行项目表中的活动或状态字段旁找到。 示例 2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:12:05Z | |||
| 发票 ID InvoiceId | 每张客户发票的唯一标识符。此属性作为计费与开票流程的主要 case 标识符。 | ||
| 描述 发票 ID (Invoice ID) 是分配给每张生成发票的唯一字母数字代码。它是将从创建、审批到付款和关闭的所有相关活动连接成单个流程实例或 case 的核心键值。 在 Process Mining 分析中,发票 ID 对于重构每张发票的端到端路径至关重要。它使分析师能够可视化流程流向、识别变体并计算 case 级指标(如周期时间)。通过特定发票 ID 进行筛选还有助于深入研究问题 case,从而理解延迟或错误的根本原因。 为何重要 这是追踪发票整个生命周期的唯一密钥,也是进行任何计费流程分析的基本基石。 获取方式 通常位于源 ERP 或财务系统中计费或发票单据的抬头表内。 示例 INV-2023-00123910004587SI-58832 | |||
| 活动名称 ActivityName | 在发票生命周期特定时间点发生的业务活动名称。 | ||
| 描述 活动名称 (Activity Name) 描述了计费流程中的具体步骤或任务,例如“发票已生成”、“发票已发送给客户”或“付款已分摊到发票”。流程日志中的每个 event 都与一项活动相关联,形成了构成流程流向的步骤序列。 分析活动序列是 Process Mining 的核心。它揭示了发票流转的实际路径,突出显示了标准程序、偏差、重工循环和瓶颈。了解发生了哪些活动、发生的顺序以及频率,是进行流程发现、一致性检查以及识别改进机会的基础。 为何重要 它定义了流程中的步骤,实现了从创建到关闭的发票流转路径的可视化和分析。 获取方式 通常衍生自单据状态变更、交易代码或源系统内的特定 event 日志。 示例 发票已审批已收到付款争议已提出发票已发送给客户 | |||
| 最后数据更新 LastDataUpdate | 指示该事件对应数据上次在源系统中被刷新或抽取的时间戳。 | ||
| 描述 此属性记录最近一次数据提取或刷新的日期和时间,反映了分析数据的实时性。 在任何流程挖掘项目中,了解数据的时效性对于报告和分析都至关重要。此属性帮助用户了解分析所涵盖的时间范围,确保决策基于最新信息,同时对于监控数据管道和确保数据提取流程按预期运行也十分关键。 为何重要 它指示了 data 的及时性,确保分析和决策基于可获得的最新信息。 获取方式 此时间戳通常是在数据提取、转换和加载(ETL)过程中生成并添加到数据集中的。 示例 2024-03-10T02:00:00Z2024-03-09T02:00:00Z2024-03-08T02:00:00Z | |||
| 源系统 SourceSystem | 提取 data 的记录系统。 | ||
| 描述 此属性识别生成事件数据的原始业务应用程序或系统,如 ERP、CRM 或自定义计费平台。在多系统集成的环境中,此字段有助于区分数据来源。 了解源系统对于数据验证、治理和故障排除至关重要。当合并来自多个系统的数据时,此属性可提供上下文,帮助解释数据粒度或术语的潜在差异,并支持对不同系统触发的流程变体进行深入分析。 为何重要 它为 data 来源提供了关键背景,这对于 data 验证以及分析跨多个系统的流程至关重要。 获取方式 此信息可能作为源表中的字段存储,也可能在数据提取、转换和加载(ETL)过程中添加。 示例 SAP S/4HANAOracle NetSuiteSalesforceMicrosoft Dynamics 365 | |||
| 付款到期日 PaymentDueDate | 客户预计支付发票的日期。 | ||
| 描述 付款到期日 (Payment Due Date) 是根据发票日期和约定的付款条件计算出的关键日期。它设定了在发票变为逾期之前收到付款的截止期限。 此属性对于监控催收绩效和管理现金流至关重要。它用于计算应收账款周转天数 (DSO) 和及时付款率等关键指标。通过对比实际付款日期与到期日,企业可以识别迟延付款、分析不同客户的付款行为并评估催收策略的有效性。 为何重要 此日期是衡量付款绩效、计算 DSO 以及识别逾期发票的基础,直接影响现金流。 获取方式 存在于发票抬头 data 中。可以直接输入,也可以根据发票日期和付款条件计算得出。 示例 2023-11-302024-01-152024-02-28 | |||
| 发票状态 InvoiceStatus | 发票在生命周期中的当前状态,例如未结 (Open)、已付 (Paid) 或争议中 (Disputed)。 | ||
| 描述 发票状态 (Invoice Status) 指示了发票在整个流程中的当前阶段。它提供了发票在任何给定时间的快照,例如是待审批、等待付款、已全额付清还是已取消。 此属性有助于创建当前工作量和财务状况的高层级概览。dashboard 通常使用此字段来显示发票按状态的分布,例如未结或逾期发票的总价值。在 Process Mining 中,分析状态之间的转换可以提供流程流向的简化高层视图。 为何重要 它提供了发票在流程中所处位置的快速快照,对运营 dashboard 和高层级状态追踪非常有用。 获取方式 这是大多数发票或计费单据抬头表中的标准字段。 示例 未结已付款逾期争议中已取消 | |||
| 发票金额 InvoiceAmount | 发票的总货币价值,包括所有行项目、税费和费用。 | ||
| 描述 发票金额 (Invoice Amount) 代表了客户预计支付的财务总值。这是与每个发票 case 关联的关键财务指标。 此属性是 Process Mining 财务分析的基础。它允许将发票划分为不同的价值类别(如高价值 vs 低价值),以观察它们是否遵循不同的流程路径或具有不同的周期时间。它还用于计算应收账款周转天数 (DSO) 等关键绩效指标,并分析流程低效(如大额发票回款延迟)所带来的财务影响。 为何重要 它支持财务影响分析,让您能够根据货币价值确定问题的优先级,并理解不同发票金额对流程的影响。 获取方式 通常位于源财务系统中的发票或计费单据抬头表中。 示例 5000.001250.7525000.5099.99 | |||
| 客户名称 CustomerName | 发票开具对象的客户或实体名称。 | ||
| 描述 此属性包含被计费客户的法定名称或商号。它为交易涉及的业务合作伙伴提供可读的标识。 按“客户名称”分析流程有助于识别哪些客户与流程偏差、付款延迟或争议相关。这可以为客户关系管理策略提供依据,并针对特定账户进行定制化沟通或流程调整,同时还支持不同客户群体的绩效基准对比。 为何重要 它支持以客户为中心的分析,有助于识别特定客户或客户群的模式、延迟或问题。 获取方式 来源于客户主数据,通过客户 ID 关联到发票单据。 示例 Global Trade CorpInnovate Solutions Ltd.Standard Manufacturing Co.Tech Services Inc. | |||
| 用户 User | 负责执行特定活动的执行者、员工或系统 ID。 | ||
| 描述 此属性识别在流程中执行特定任务的人员或自动化系统代理。这可能是发票创建者、审批人或核销付款的人员。 按用户分析活动有助于了解工作负载分布、个人绩效和培训需求。它可以突出哪些用户或团队效率极高,哪些可能需要额外支持。此外,追踪流程中关键操作的执行者对于合规和审计也至关重要。 为何重要 它提供了对资源绩效和工作负载的可见性,支持分析团队效率并识别培训机会。 获取方式 通常存在于变更日志或单据历史表中,与每个记录的事件或交易相关联。 示例 j.doeAccountingBotm.smithe.jones | |||
| 货币 Currency | 发票上货币金额的货币代码,例如 USD 或 EUR。 | ||
| 描述 货币 (Currency) 属性指定了发票金额的货币单位。它为理解财务数值提供了必要的背景,对于涉及多种货币交易的跨国组织尤为重要。 在分析中,货币字段对于正确汇总和对比财务 data 至关重要。在计算总价值或对比不同区域的发票金额之前,所有数值必须转换为统一货币。此属性对于准确的财务报告以及按货币或区域细分流程绩效至关重要。 为何重要 它为所有财务数值提供了必要的背景,确保货币分析和报告的准确性,在跨国业务中尤为重要。 获取方式 位于发票或计费单据表的抬头部分,通常与金额字段并列。 示例 美元EURGBPJPY | |||
| 付款条款 PaymentTerms | 约定的发票付款条件,例如净 30 天 (Net 30) 或收票即付。 | ||
| 描述 付款条件 (Payment Terms) 定义了买卖双方就发票付款达成的协议规则。这包括允许付款的时间期限以及提前付款的任何折扣。 按付款条件分析流程可以揭示某些条件是否与较长的付款周期或较高的迟延付款率相关。这些信息可以帮助企业优化其付款条件策略,以改善现金流。在调查发票逾期的原因时,它也提供了重要的背景信息。 为何重要 此属性影响付款截止日期和客户的付款行为,是理解和提高按时付款率的关键。 获取方式 通常同时存储在客户主数据和单张发票单据的抬头中。 示例 净 30 天净 60 天见票即付2% 10,净30 | |||
| 客户地区 CustomerRegion | 与客户关联的地理区域、领土或国家。 | ||
| 描述 客户区域 (Customer Region) 指定了客户的地理位置。这可以定义在不同级别,如国家/地区、省/州或自定义销售区域。 这是一个强大的属性维度。按区域分析计费流程可以突出绩效的地域差异,例如付款时间、争议率或流程合规性的差异。这些洞察可以为特定区域的催收和客户服务策略提供参考,并帮助识别高绩效区域的最佳实践,以便在其他地方推广。 为何重要 它支持地域分析,揭示不同地区在付款行为、流程效率和合规性方面的差异。 获取方式 衍生自客户主数据,通常基于客户地址。 示例 北美欧洲、中东和非洲德国亚太 | |||
| 是否返工 IsRework | 用于标识发票流程是否涉及重工活动(如纠错或多次审批循环)的标记。 | ||
| 描述 IsRework 是一个布尔值标记,如果发票经历过一次或多次重工循环,则为 true。重工包括纠错活动或重复执行本应只需一次的步骤,例如发票被拒绝后重新提交审批。 此属性直接衡量流程效率。通过筛选 IsRework 为 true 的 case,分析师可以立即隔离有问题的发票并调查重工的根本原因。计算重工率(即发生重工的 case 所占百分比)是衡量流程质量、识别精简运营机会及减少浪费的关键 KPI。 为何重要 它直接标记了流程的低效,便于对需要额外非增值工作的 case 进行识别和分析。 获取方式 此属性通常在源系统中不可直接获取,必须在数据转换过程中通过识别指示返工的一系列活动序列衍生得出。 示例 truefalse | |||
| 组织单位 OrganizationalUnit | 负责发票的业务部门、公司代码或销售组织。 | ||
| 描述 此属性识别公司内部开出发票或负责该交易的具体实体。例如公司代码、业务单元或销售组织。 按“组织单位”分析流程可以进行内部基准测试,对比业务不同部门的绩效。它有助于识别哪些业务单元最高效,哪些返工率最高,或者哪些在逾期付款方面最吃力。这对于落实责任制和在全企业范围内实现流程标准化至关重要。 为何重要 它支持不同业务部门之间的内部绩效对比,有助于识别最佳实践和待改进领域。 获取方式 这是 ERP 系统中几乎所有财务单据抬头中都能找到的基础组织数据字段。 示例 1000US01全球服务Manufacturing EU | |||
| 销售订单编号 SalesOrderNumber | 产生该发票的销售订单标识符。 | ||
| 描述 销售订单号是指向“从订单到现金”链条中触发发票生成的上游单据。它将开票流程与销售流程关联起来。 此属性对于实现“从订单到现金”流程的端到端真实视图至关重要。通过将发票链接回销售订单,企业可以分析从客户下单到最终收款的全生命周期。这种全局分析有助于识别销售或履行过程中的问题如何影响开票和催收。 为何重要 它将计费流程与上游销售流程相连,从而实现完整的端到端 Order-to-Cash 分析。 获取方式 此参考号通常存储在发票单据抬头或行项目中,将其链接到销售单据表。 示例 SO-10582490000123ORD-2023-987 | |||
Order to Cash - 计费与开票活动
| 活动 | 描述 | ||
|---|---|---|---|
| 发票已发送给客户 | 已批准的发票已通过指定方式(如电子邮件、纸质打印或在线门户)正式交付给客户。此操作开启了客户付款条件的计时。 | ||
| 为何重要 此事件是催收周期的正式开始,对于计算应收账款周转天数(DSO)和按时付款率至关重要。 获取方式 记录在输出管理日志、沟通记录或发票上特定的“发送日期”字段中。 捕获 使用记录发票通过电子邮件发送、打印或通过 EDI 发送的时间戳系统日志。 事件类型 explicit | |||
| 发票已结案 | 发票已正式关闭,标志着其生命周期结束。当未付余额通过付款、贷记单或其他调整归零时,即达到此状态。 | ||
| 为何重要 作为流程的主要成功终点,此活动对于计算整体周期时间和衡量流程完成率至关重要。 获取方式 这通常是基于发票余额归零而推断出的状态,或者是系统中明确的状态变更。 捕获 确定导致发票余额归零的最后一笔交易(如付款分摊)的 timestamp。 事件类型 inferred | |||
| 已到达付款到期日 | 这是一个计算得出的事件,发生在发票付款截止日期过后。它不是一项交易活动,而是基于发票开具日期和付款条件的时间里程碑。 | ||
| 为何重要 此里程碑对于将发票分类为逾期以及分析按时付款绩效至关重要。它也是启动催收活动的触发点。 获取方式 此事件不直接记录,而是根据发票日期和付款条件字段计算得出。 捕获 计算方式为“发票发送日期”+“付款期限天数”。 事件类型 calculated | |||
| 已收到客户付款 | 已收到客户付款并记入财务系统。在此阶段,资金已确认,但可能尚未具体分摊到对应发票上。 | ||
| 为何重要 这是一个关键的现金流事件。从收到付款到完成核销之间的时间是衡量现金核销效率的核心指标。 获取方式 记录在现金收款日记账、付款交易表或银行对账单处理表中。 捕获 识别客户付款或现金收款记录的创建。 事件类型 explicit | |||
| 已生成发票 | 此活动标志着系统中发票记录的生成。这是计费流程的正式起点,通常由已履行的销售订单自动触发或手动录入。 | ||
| 为何重要 作为起点,此 event 对于计算端到端发票周期时间以及识别流程初期的延迟至关重要。 获取方式 从主发票或计费单据表的创建 timestamp 中获取。 捕获 识别新发票记录的创建 event 或初始保存 timestamp。 事件类型 explicit | |||
| 款项已核销至发票 | 收到客户付款并已成功与特定发票匹配和核销。此对账步骤会减少或消除发票的待支付余额。 | ||
| 为何重要 此活动对于了解现金核销周期至关重要。此环节的延迟可能导致应收账款账龄失实,并影响信用管理。 获取方式 存在于将付款单据与发票单据关联的应收账款明细账表中,通常被称为清账单据。 捕获 获取付款记录与发票记录关联以清账时的 timestamp。 事件类型 explicit | |||
| 争议已提出 | 客户已正式对全部或部分发票提出异议,理由包括价格或数量错误等。这通常会暂停催收活动,直到争议解决。 | ||
| 为何重要 分析争议有助于找出客户不满和计费不准的根本原因,这些因素直接影响 DSO 和客户关系。 获取方式 通常记录为状态变更、发票上的标记,或创建与发票关联的独立争议 case 记录。 捕获 获取争议 case 的创建日期或状态变更为“争议中”的时间。 事件类型 explicit | |||
| 付款提醒已发出 | 已就逾期发票向客户发送催款函或电子邮件等沟通信息。这是催收过程中促成付款的关键活动。 | ||
| 为何重要 追踪催款记录有助于衡量催收策略的有效性,并识别经常需要跟进的客户。 获取方式 从催款运行日志、催收系统或与客户或发票关联的沟通活动日志中获取。 捕获 使用来自催款历史表或催收活动日志的时间戳。 事件类型 explicit | |||
| 发票已修正 | 发票在初始创建后进行了修改,通常是由于被拒绝或发现了错误。这可能涉及更新金额、行项目或客户信息。 | ||
| 为何重要 修正频率过高表明主数据或初始订单履行流程可能存在问题,从而导致重工和延迟。 获取方式 从变更日志、审计轨迹或通过识别针对同一订单先取消发票后重新创建的模式中推断。 捕获 检测发票记录在初始创建后关键财务字段的变更。 事件类型 inferred | |||
| 发票已取消 | 现有发票已作废或取消,撤销了其财务影响。这通常是为了在收到付款前纠正重大错误(例如向错误的客户计费)。 | ||
| 为何重要 取消发票反映了需要重工的操作错误,并会延迟正确的计费。高取消率预示着流程或 data 质量存在问题。 获取方式 从冲销单据或发票记录中特定的“已取消”或“作废”状态获取。 捕获 查找与原始发票关联的冲销单据的创建,或状态向“作废”的变更。 事件类型 explicit | |||
| 发票已审批 | 发票已成功通过所有内部审核并获得正式批准。此 event 标志着发票已被确认准确无误,可以发送给客户。 | ||
| 为何重要 这是一个关键里程碑,区分了内部处理时间与客户付款期限。分析到审批为止所需的时间可以揭示内部效率。 获取方式 从 workflow 系统日志或发票单据状态从“待处理”变为“已批准”的变更中获取。 捕获 从 workflow 日志或状态变更中获取最终审批 event 的 timestamp。 事件类型 explicit | |||
| 发票已拒绝 | 审批人在内部审核过程中拒绝了发票。此操作通常需要修正发票并重新提交,从而产生了重工循环。 | ||
| 为何重要 此活动突显了内部流程低效、数据质量问题以及导致发票周期延长和付款延迟的返工环节。 获取方式 通常捕获为发票记录上的状态变更,相关表中通常附有拒绝说明。 捕获 记录发票状态更新为“已拒绝”或类似状态时的 event。 事件类型 explicit | |||
| 发票已提交审批 | 代表将生成的发票提交至正式的内部审核 workflow。这在设有控制措施、要求在发票定稿前进行管理层审查的组织中非常常见。 | ||
| 为何重要 追踪提交和审批情况有助于发现内部流程中导致发票发送延迟的瓶颈,这会直接影响现金流。 获取方式 通常记录为状态变更或来自工作流管理系统的日志条目。 捕获 获取发票状态变更为“待审批”或类似状态时的 timestamp。 事件类型 explicit | |||
| 发票已核销 | 发票剩余金额被注销并归类为坏账。这通常是在穷尽所有催收手段后采取的行动。 | ||
| 为何重要 这代表催收流程的失败以及直接的财务损失。分析坏账注销有助于识别高风险客户并优化信用政策。 获取方式 记录为特定的调整或日记账分录,将发票余额与坏账账户冲抵。 捕获 识别使用“呆账冲销”原因代码调整发票余额或过账到坏账账户的交易。 事件类型 explicit | |||
| 已开具贷项通知单 | 已创建贷记单或红字发票并通常应用于现有发票。这通常是为了纠正计费错误、进行价格调整或处理退货。 | ||
| 为何重要 频繁的贷记单可能预示着销售或履行环节中存在导致收入流失或客户不满的潜在问题。 获取方式 从贷记单或红字发票单据的创建中获取,此类单据通常会关联回原始发票。 捕获 记录贷记单交易类型的创建 timestamp。 事件类型 explicit | |||