您的Order-to-Cash:销售订单处理数据模板
您的Order-to-Cash:销售订单处理数据模板
- 详细分析所需的推荐属性
- 流程中需要跟踪的关键活动
- NetSuite数据提取实用指南
订单到收款-销售订单处理属性
| 名称 | 说明 | ||
|---|---|---|---|
|
事件时间
EventTime
|
表示活动发生时间的时间戳。 | ||
|
说明
此属性提供流程中每项活动的准确日期和时间,是事件日志的时间顺序基础,可用于计算不同步骤之间的周期时间、持续时间和等待时间。 准确的时间戳对于绩效分析至关重要,例如衡量从创建订单到发运所需的时间,或识别信用审批流程中的延误。它支持对流程效率和服务级别协议执行情况进行详细分析。
为什么重要
时间戳对于计算所有基于时间的指标至关重要,包括周期时间和持续时间。这些指标是识别流程瓶颈的基础。
获取位置
对应NetSuite交易记录中的日期字段,例如销售订单的“Date Created”、Item Fulfillment的“Actual Ship Date”,以及发票和付款记录中的“Date”。
示例
2023-04-15T10:00:00Z2023-04-15T14:30:00Z2023-04-16T09:00:00Z
|
|||
|
活动名称
ActivityName
|
在特定时间发生的业务事件或活动名称。 | ||
|
说明
此属性描述销售订单生命周期中的具体步骤或状态变更,例如“Sales Order Created”“Goods Shipped”或“Payment Received”。这些活动的顺序构成流程图的基础。 分析活动流有助于识别常见流程路径、偏差和瓶颈。了解活动的发生频率和顺序,对于发现简化运营、减少人工操作的机会至关重要。
为什么重要
它定义流程步骤,从而支持流程顺序流的可视化和分析。
获取位置
通常根据NetSuite中的系统状态变更、交易类型或特定事件日志得出。一般需要将状态字段或交易创建事件映射为标准化的活动名称。
示例
销售订单已创建销售订单已批准货物已发运发票已创建已收到付款
|
|||
|
销售订单
SalesOrder
|
每份销售订单文档的唯一标识符。 | ||
|
说明
销售订单是主要的案例标识符,将从客户下单、货物交付到最终付款的所有后续活动连接起来。每份销售订单代表端到端流程中的一个独立实例。 在流程挖掘中,该属性是重建每份订单流程的基础。它支持按订单分析流程变体、周期时间和瓶颈,完整呈现每个客户需求的生命周期。
为什么重要
这是连接所有相关事件并形成单一流程实例的核心标识符,使端到端分析成为可能。
获取位置
这是NetSuite中销售订单交易记录的内部ID。通常可以在销售订单表单或搜索结果中找到标为“Internal ID”的字段。
示例
SO-100521SO-100522SO-100523
|
|||
|
产品类别
ProductCategory
|
销售订单中主要产品或服务的类别。 | ||
|
说明
此属性将销售订单中的商品划分为更广泛的类别,例如“Hardware”“Software”或“Services”。如果订单包含多个类别,可以根据金额或商品数量指定主要类别。 按产品类别分析流程,可以发现不同的履约路径。例如,服务的履约流程可能远比需要拣选、打包和发运的实体硬件简单。这种细分对于设计针对不同类别的流程改进方案至关重要。
为什么重要
按产品类别细分流程,有助于揭示不同的履约路径并识别特定类别的瓶颈。
获取位置
此信息来自与销售订单行关联的“Item”记录。可能需要与Item主数据连接,以获取产品类别。
示例
电子产品软件许可证咨询服务
|
|||
|
付款条件
PaymentTerms
|
双方约定的发票付款条件。 | ||
|
说明
此属性定义客户支付商品或服务费用的条件,例如“Net 30”或“Due on Receipt”。这些条件用于计算发票付款到期日。 按付款条件分析,有助于识别与逾期付款相关的条件,并评估信用政策的财务影响。这是分析“Payment Terms Adherence Rate”仪表板和了解现金流动态的基础。
为什么重要
它为计算付款到期日、分析客户付款行为和付款条件遵循率提供依据。
获取位置
这是NetSuite销售订单或发票交易记录中的“Terms”字段。
示例
30天账期60天账期收到即付款
|
|||
|
发票编号
InvoiceNumber
|
客户发票的唯一标识符。 | ||
|
说明
此属性是根据销售订单生成的发票单据参考编号,将销售履行流程与应收账款流程连接起来。 跟踪发票编号对于财务对账以及覆盖从订单到最终付款全过程的分析非常重要。它为发货等运营活动与收款等财务活动之间提供了明确关联。
为什么重要
它将销售订单与用于开票的具体财务交易关联起来,从而支持真正端到端的Order-to-Cash分析。
获取位置
这是根据Sales Order创建的Invoice记录中的“Invoice #”或“Transaction ID”。
示例
INV-2001INV-2002INV-2003
|
|||
|
客户名称
CustomerName
|
下达销售订单的客户名称。 | ||
|
说明
此属性包含购买商品或服务的法人实体或个人名称,并将销售订单流程关联到具体客户账户。 按客户筛选或分维度分析,对于了解客户特有行为、识别影响重点客户的问题和评估服务水平至关重要。它支持以客户为中心查看流程,突出显示哪些客户经历了最多延误或返工。
为什么重要
支持按客户细分流程,这对于分析客户满意度、识别重点客户问题和定制服务至关重要。
获取位置
这是NetSuite销售订单交易记录中的“Customer”或“Entity”字段。
示例
Global Corp Inc.Innovate Solutions Ltd.Dynamic Tech
|
|||
|
用户
User
|
执行该活动的用户或员工。 | ||
|
说明
此属性标识负责执行特定流程步骤的人员,例如创建订单的销售代表或打包货物的仓库操作员。它可以是用户名或唯一ID。 按用户分析有助于了解工作量分配、识别培训需求,并比较个人或团队的绩效。在调查与特定用户操作相关的偏差或延误时,它也是根因分析的重要依据。
为什么重要
支持按员工或角色分析绩效,帮助识别高绩效人员、自动化候选环节和培训机会。
获取位置
这些信息可以在NetSuite各类交易记录的“Created By”“Modified By”或“Owner”等字段中找到。
示例
John SmithJane Doe仓库用户1
|
|||
|
要求交付日期
RequestedDeliveryDate
|
客户要求的交付日期。 | ||
|
说明
此属性记录客户要求收到货物的日期,是衡量按时交付表现的关键基准。 系统会将该日期与实际交付日期(“Goods Shipped”时间戳)进行比较,以计算“On-Time Delivery Rate”KPI。分析要求交付日期与实际交付日期之间的差距,有助于识别预测、库存管理或物流方面的系统性问题,了解这些问题为何导致企业无法满足客户预期。
为什么重要
这是衡量按时交付表现和客户满意度的基准。
获取位置
这可能对应销售订单记录中的标准字段或自定义字段,通常命名为“Requested Delivery Date”或类似名称。
示例
2023-05-202023-06-012023-06-15
|
|||
|
订单总金额
TotalOrderAmount
|
销售订单的货币总价值。 | ||
|
说明
此属性表示销售订单的总财务价值,包括所有商品、税费和运输费用,是衡量每个流程实例经济价值的重要指标。 按订单金额分析流程可以发现重要模式。例如,高价值订单可能采用更复杂、人工参与更多的审批流程,而低价值订单可能高度自动化。此类分析有助于优先改进影响最大的订单流程。
为什么重要
支持基于价值的分析,帮助优先处理高价值订单,并了解流程效率对收入的影响。
获取位置
这是NetSuite销售订单交易记录中的“Total”字段。
示例
1500.00250.5012500.75
|
|||
|
销售订单状态
SalesOrderStatus
|
销售订单在生命周期中的当前状态。 | ||
|
说明
此属性表示销售订单的当前状态,例如“Pending Approval”“Pending Fulfillment”或“Billed”,用于展示订单在整体流程中的位置。 活动日志展示历史流转,而当前状态适合用于筛选和关注当前卡住或正在处理的订单。按终止状态分析案例,有助于了解流程结果,例如订单是否成功关闭、已取消或仍在进行中。
为什么重要
支持按当前状态筛选案例,这对于分析未关闭订单、识别受阻或延误订单至关重要。
获取位置
这是NetSuite销售订单交易记录中的“Status”字段。
示例
待履行待开票已开票已关闭
|
|||
|
付款到期日
PaymentDueDate
|
发票付款的到期日期。 | ||
|
说明
此属性是根据发票日期和付款条款计算出的客户应付款日期。例如,发票日期为4月1日且付款条款为“Net 30”时,到期日为5月1日。 该日期对财务分析至关重要。系统会将其与“Payment Received”日期直接比较,以判断付款是否按时完成。它也是计算“On-Time Payment Rate”KPI和管理应收账款的重要依据。
为什么重要
这是衡量按时付款表现的基准,对现金流和应收账款管理至关重要。
获取位置
这是Invoice交易记录中的“Due Date”字段。NetSuite会根据发票日期和付款条款自动计算该字段。
示例
2023-05-302023-06-152023-07-01
|
|||
|
信用状态
CreditStatus
|
表示销售订单的信用冻结状态。 | ||
|
说明
此属性反映订单处理时客户的信用状态,例如“On Hold”或“Released”。它是订单生命周期早期阶段的重要因素。 分析此属性有助于了解信用检查对整体订单周期时间的影响。“Credit Check Cycle Time Analysis”仪表板利用这些数据,识别有多少订单被置于冻结状态,以及解除冻结需要多长时间,从而突出信用管理流程中的瓶颈。
为什么重要
它直接影响“Credit Check Cycle Time”KPI,并有助于解释订单流程早期阶段的延迟。
获取位置
这可能是Sales Order记录中的标准状态字段或自定义复选框,例如“Credit Hold”。也可以根据是否存在“Credit Hold Applied”和“Credit Hold Released”活动进行推断。
示例
良好暂挂已释放
|
|||
|
最近数据更新时间
LastDataUpdate
|
源系统最近一次刷新或提取数据的时间戳。 | ||
|
说明
此属性表示数据集最近一次更新的时间。它向业务用户清晰说明所分析数据的新鲜度,帮助其了解流程挖掘仪表板和分析所覆盖的时间范围。 它不用于流程顺序流分析,但对于数据治理和建立用户信任这一元数据要素至关重要。它帮助用户评估洞察的时效性,并了解何时可以看到新数据。
为什么重要
告知用户数据的时效性,这对于基于分析结果进行决策至关重要。
获取位置
该时间戳在从NetSuite提取数据时生成并写入数据集。
示例
2023-10-27T02:00:00Z
|
|||
|
发货国家/地区
ShippingCountry
|
货物的发运目的地国家/地区。 | ||
|
说明
此属性包含订单货物的发运国家/地区,取自与销售订单关联的发货地址。 基于发货国家/地区开展地理分析,可以发现物流、海关或区域办公室效率造成的流程表现差异。您可以比较不同国家或地区的发货时间、交付准确率和流程成本。
为什么重要
支持地理分析,帮助识别区域瓶颈、比较物流表现并了解跨国流程的复杂性。
获取位置
这是Sales Order交易记录中“Shipping Address”的一部分。
示例
USA德国日本
|
|||
|
是否按时交付
IsOnTimeDelivery
|
表示订单是否在客户要求日期当天或之前交付的标记。 | ||
|
说明
此计算得出的布尔属性会将“Goods Shipped”或实际交付时间戳与“RequestedDeliveryDate”进行比较。交付按时或提前时为true,延迟时为false。 该标记对于计算“On-Time Delivery Rate”KPI以及驱动“Delivery Promise vs. Reality Gap”仪表板至关重要。它简化了交付表现分析,便于筛选和汇总,从而找出延迟发货的原因,例如特定产品、地区或流程瓶颈。
为什么重要
为交付表现提供清晰的二元结果,简化KPI计算和延迟订单的根因分析。
获取位置
该指标在数据转换过程中计算,方法是比较“Goods Shipped”活动的时间戳与“RequestedDeliveryDate”属性。
示例
truefalse
|
|||
|
是否按时付款
IsOnTimePayment
|
表示发票是否在到期日当天或之前完成付款的标记。 | ||
|
说明
此计算得出的布尔属性会将“Payment Received”时间戳与“PaymentDueDate”进行比较。付款在到期日当天或之前完成时为true,否则为false。 此属性是“On-Time Payment Rate”KPI和“Payment Terms Adherence Rate”仪表板的基础。它清晰衡量客户付款行为,支持分析哪些客户、地区或付款条款最容易出现逾期付款。
为什么重要
直接衡量客户的付款纪律,对现金流管理和信用风险评估至关重要。
获取位置
该指标在数据转换过程中计算,方法是比较“Payment Received”活动的时间戳与“PaymentDueDate”属性。
示例
truefalse
|
|||
|
源系统
SourceSystem
|
标识数据来源的系统。 | ||
|
说明
此属性指定生成事件数据的源应用。对于此流程,通常为“NetSuite”。在更复杂的环境中,它还可以区分来自不同集成系统的数据,例如独立的CRM或WMS。 在分析中,它有助于确认数据血缘。当需要融合多个来源的数据以创建统一的流程视图时,这一属性尤为重要。它确保数据正确归属于来源系统,并有助于数据治理和问题排查。
为什么重要
它提供了有关数据来源的重要背景信息,尤其适用于集成多个系统的环境。
获取位置
这是在从NetSuite提取和转换数据时添加的静态值(“NetSuite”)。
示例
NetSuite
|
|||
|
销售团队
SalesTeam
|
负责该销售订单并计入业绩的销售团队或小组。 | ||
|
说明
此属性用于识别负责销售的团队或部门,可用于组织销售代表以及管理销售区域或产品线。 在流程挖掘中,按销售团队分析表现,可以发现高绩效团队的最佳实践,或识别影响特定团队的系统性问题。分析还可以揭示数据录入质量、折扣审批或其他上游因素的差异,以及这些因素如何影响下游履行流程。
为什么重要
支持比较不同销售团队的表现,帮助识别最佳实践或需要支持的领域。
获取位置
这可能是Sales Order记录中的标准字段或自定义字段,通常与Sales Rep的员工记录关联。
示例
北美销售EMEA企业业务APAC渠道
|
|||
|
销售订单变更次数
SalesOrderChangeCount
|
销售订单初次创建后被修改的次数。 | ||
|
说明
此计算指标统计每个案例中“Sales Order Changed”活动的发生次数。变更次数较高通常表示存在返工,原因可能包括客户请求、数据录入错误或价格调整。 此属性是“Sales Order Rework Rate”KPI和“Sales Order Rework Variants”仪表板的直接输入。分析高变更次数订单的特征,有助于识别返工根因,例如特定产品、客户或销售代表相关的问题。
为什么重要
直接量化返工,帮助定位效率低下、数据质量问题和流程不稳定的来源。
获取位置
该指标在数据转换过程中计算,方法是统计每个“SalesOrder”案例ID对应的“Sales Order Changed”事件。
示例
013
|
|||
|
销售订单类型
SalesOrderType
|
销售订单的分类,例如标准订单、加急订单或特殊订单。 | ||
|
说明
此属性根据销售订单类型进行分类,而订单类型通常决定流程路径和优先级。例如,与“Standard Order”相比,“Rush Order”可能跳过某些步骤,或适用更严格的SLA。 按订单类型分析流程,对于判断不同流程变体是否有意设计且有效至关重要。它有助于评估针对特定订单类型的特殊处理是否真正带来了更快或更好的结果,以及相应成本。
为什么重要
支持比较标准订单与加急订单等不同预期流程路径,判断其表现是否符合预期。
获取位置
这通常是Sales Order表单中的自定义“Order Type”字段,因为NetSuite默认使用不同的交易表单,例如“Standard Sales Order”和“Standard Sales Order - Cash Sale”,而不是单一的类型字段。
示例
标准订单加急订单项目订单
|
|||
订单到收款-销售订单处理活动
| 活动 | 说明 | ||
|---|---|---|---|
|
发票已创建
|
表示为已发运的商品或服务创建财务发票。当创建与销售订单关联的“Invoice”交易时,该显式事件便会触发。 | ||
|
为什么重要
此活动是收入确认的关键里程碑,也标志着付款周期开始。发运与开票之间的时间会直接影响现金流。
获取位置
这是从发票交易记录的“Date Created”字段中捕获的显式事件(Transaction表,Type='CustInvc'),并与销售订单关联。
采集
使用关联Invoice的交易创建日期。
事件类型
explicit
|
|||
|
已创建订单履约记录
|
此活动标志着仓库实物履约流程开始。当系统根据销售订单生成“Item Fulfillment”交易时,该活动便会发生。 | ||
|
为什么重要
这是连接销售流程与仓库运营的关键里程碑。订单获批到创建履约记录之间的时间,是衡量运营准备度的重要指标。
获取位置
这是一个显式事件。时间戳为“Item Fulfillment”记录的创建日期,该记录与源销售订单相关联。
采集
使用关联Item Fulfillment记录的交易创建日期。
事件类型
explicit
|
|||
|
已收到付款
|
此活动标志着收到客户针对发票支付的款项。当创建“Customer Payment”交易并将其应用于与销售订单关联的发票时,即可捕获该活动。 | ||
|
为什么重要
作为关键的终止事件,此活动对于分析现金转换周期和按时付款表现至关重要。它表示销售交易已完成财务结算。
获取位置
这是一个显式事件。时间戳为应用于相关发票的“Customer Payment”交易创建日期(Transaction表,Type='CustPymt')。
采集
使用应用于Invoice的Customer Payment记录中的交易日期。
事件类型
explicit
|
|||
|
货物已发运
|
此里程碑标志着商品已离开仓库并运往客户。通常可根据“Item Fulfillment”记录的状态更新为“Shipped”进行推断。 | ||
|
为什么重要
发运是交接给承运商和客户的关键节点。该事件对于跟踪按时交付表现、衡量订单履约总周期至关重要。
获取位置
根据关联“Item Fulfillment”交易的“Status”字段变更为“Shipped”进行推断。该事件的时间戳为状态变更日期。
采集
Item Fulfillment记录状态变更为“Shipped”的时间戳。
事件类型
inferred
|
|||
|
销售订单已关闭
|
这是最后一个活动,表示销售订单已完成履约和开票,并被视为已完成。可根据销售订单状态变更为“Closed”进行推断。 | ||
|
为什么重要
此事件表示订单生命周期在运营层面结束。从创建到关闭的时间,可以完整反映端到端流程时长。
获取位置
根据销售订单交易的“Status”字段变更为“Closed”进行推断。时间戳取自该最终状态变更的系统备注。
采集
销售订单系统备注中状态变更为“Closed”的时间戳。
事件类型
inferred
|
|||
|
销售订单已创建
|
此活动标志着销售订单流程正式开始。当NetSuite中首次保存新的销售订单交易时,该活动便会发生,并记录客户最初的需求。 | ||
|
为什么重要
这是Order to Cash流程的主要开始事件。分析从该事件到后续活动所需的时间,对于衡量整体订单处理效率和周期时间至关重要。
获取位置
这是从销售订单交易记录的“Date Created”字段中捕获的显式事件(Transaction表,Type='SalesOrd')。
采集
使用销售订单的交易创建日期。
事件类型
explicit
|
|||
|
销售订单已批准
|
此里程碑表示销售订单已通过信用、库存等所有内部检查,可以进入履约环节。通常可根据订单状态变更为“Pending Fulfillment”进行推断。 | ||
|
为什么重要
审批是流程中的关键关口。衡量审批所需时间,有助于发现内部审核和决策中的延误。
获取位置
根据销售订单记录中的状态变更推断。当“Order Status”字段更新为“Pending Fulfillment”或类似的自定义已批准状态时,捕获该时间戳。
采集
销售订单系统备注中状态变更为“Pending Fulfillment”的时间戳。
事件类型
inferred
|
|||
|
已应用信用冻结
|
当销售订单被自动或手动设置为信用冻结时,该事件便会发生,履约流程也会暂停。通常可根据订单状态变更为“Pending Approval”或特定的“Credit Hold”状态进行推断。 | ||
|
为什么重要
识别订单何时以及为何被暂停,是了解履约周期延误的关键。此活动可以突出显示与客户信用问题相关的瓶颈。
获取位置
根据销售订单记录中的系统备注或审计轨迹推断,重点查找“Order Status”字段变更为冻结状态的记录。
采集
识别订单状态变更为信用冻结状态的时间戳。
事件类型
inferred
|
|||
|
已解除信用冻结
|
表示销售订单解除信用冻结并可以继续履约的时点。可通过观察订单状态从冻结状态变更为开放或已批准状态来捕获。 | ||
|
为什么重要
信用冻结持续时间是关键KPI。该事件可用于衡量解决信用问题所需的时间及其对整体Order-to-Cash周期的影响。
获取位置
根据销售订单记录中的系统备注或审计轨迹推断,捕获“Order Status”从冻结状态变更时的时间戳。
采集
识别订单状态从信用冻结状态变更为有效状态的时间戳。
事件类型
inferred
|
|||
|
库存已承诺
|
此事件标志着库存已正式为销售订单预留,确保可用于履约。可通过观察销售订单行中的“Committed Quantity”变更进行推断。 | ||
|
为什么重要
此活动对于分析库存分配效率至关重要。订单获批与库存承诺之间的延误可能导致缺货,并影响交付承诺。
获取位置
根据销售订单行项目的系统备注推断。时间戳对应“Quantity Committed”字段从零更新为正数的时间。
采集
订单行中“Quantity Committed”字段变更的时间戳。
事件类型
inferred
|
|||
|
货物已打包
|
表示已拣选的商品完成打包,可以发运。通过跟踪“Item Fulfillment”记录的状态变更为“Packed”来捕获。 | ||
|
为什么重要
此活动有助于衡量包装工位的效率。拣选与打包之间的时长可以揭示产能限制或流程低效。
获取位置
根据关联“Item Fulfillment”交易的“Status”字段变更为“Packed”进行推断。该更新的时间戳记录在系统备注中。
采集
Item Fulfillment记录状态变更为“Packed”的时间戳。
事件类型
inferred
|
|||
|
货物已拣选
|
表示订单商品已从仓库库位拣出。这是根据关联“Item Fulfillment”记录的状态变更推断出的事件。 | ||
|
为什么重要
分析货物拣选所需时间,对于优化仓库效率至关重要。此活动有助于衡量并识别拣选流程中的瓶颈。
获取位置
根据关联“Item Fulfillment”交易的“Status”字段变更为“Picked”进行推断。时间戳取自该状态变更的系统备注。
采集
Item Fulfillment记录状态变更为“Picked”的时间戳。
事件类型
inferred
|
|||
|
贷项通知单已创建
|
当针对销售订单或发票开具贷项通知单时,该事件便会发生,通常用于退货、价格调整或其他让利。创建“Credit Memo”交易时即可捕获。 | ||
|
为什么重要
贷项通知单通常反映发运错误或产品缺陷等流程问题。分析其发生频率和时间,有助于识别根本原因并提升整体质量。
获取位置
这是基于创建“Credit Memo”交易的显式事件(Transaction表,Type='CredMemo'),并可与原始发票或销售订单关联。
采集
使用关联Credit Memo的交易创建日期。
事件类型
explicit
|
|||
|
销售订单已变更
|
此活动记录销售订单创建后的重要修改,例如数量、商品或价格变更。可通过跟踪系统备注或审计轨迹中的更新来捕获。 | ||
|
为什么重要
频繁变更可能表明数据录入错误或客户需求不稳定,进而导致返工和流程低效。跟踪这些变更有助于识别订单修改的根本原因。
获取位置
根据与销售订单交易相关的系统备注或审计轨迹得出。相关字段的每次记录变更都可以视为一次该活动。
采集
识别销售订单初次创建后系统备注中的字段变更。
事件类型
inferred
|
|||
提取指南
加快现金回笼:立即优化销售订单处理
加入将Order-to-Cash周期时间缩短30%的企业行列。
无需信用卡,几分钟即可完成设置。