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