您的订单到收款流程:销售订单处理数据模板
您的订单到收款流程:销售订单处理数据模板
- 全面分析所需的推荐属性
- 需要跟踪的关键流程活动
- Microsoft Dynamics 365专用数据提取指南
订单到收款-销售订单处理属性
| 名称 | 说明 | ||
|---|---|---|---|
|
开始时间
EventTime
|
具体活动或事件发生的准确日期和时间。 | ||
|
说明
Event Time或时间戳记录活动发生的准确时刻。事件日志中的每项活动都有对应的时间戳,为每个Case建立流程的时间顺序记录。 该属性是流程挖掘中所有基于时间的分析的关键。它用于计算活动之间的周期时间、衡量Case总持续时间、分析等待时间,并识别流程延迟的瓶颈。它还支持按时间监控绩效,例如跟踪日、周或月度吞吐量。
为什么重要
该时间戳对于计算周期时间和瓶颈等所有基于持续时间的指标,以及按时间顺序排列事件都至关重要。
获取位置
该属性源自与具体交易相关的各种日期和时间字段,例如用于记录订单创建时间的“SalesTable.CreatedDateTime”,或用于记录付款的付款日记账过账日期。
示例
2023-04-15T09:02:11Z2023-04-18T14:30:00Z2023-04-25T11:21:45Z
|
|||
|
活动
ActivityName
|
销售订单流程中某个时间点发生的具体业务事件或任务的名称。 | ||
|
说明
此属性代表销售订单生命周期中的一个独立步骤或事件,例如“销售订单已创建”“货物已发运”或“已收到付款”。特定销售订单的活动顺序构成其流程顺序流。 分析活动之间的顺序、频率和转换关系,是流程挖掘的核心。它有助于可视化流程图、识别常见和罕见的流程变体、发现瓶颈,并定位返工或不符合规范的环节。此属性是理解流程实际运行情况的基础。
为什么重要
它定义流程步骤,使您能够构建并可视化流程顺序流,这是流程挖掘的主要目标。
获取位置
该属性通过将“SalesTable”等表以及相关物流或财务表中的具体系统事件或状态变化映射为标准化活动名称而形成。
示例
销售订单已创建商品已发运发票已创建已收到付款
|
|||
|
销售订单
SalesOrderNumber
|
每个销售订单的唯一标识符,也是该流程的主要案例标识。 | ||
|
说明
Sales Order Number是Microsoft Dynamics 365中分配给每个客户订单的唯一字母数字代码。它作为核心Case ID,将从创建到关闭的所有相关活动和事件关联起来。 在流程挖掘中,该属性对于还原每个销售订单的端到端历程至关重要。它支持分析人员追踪完整的活动序列、衡量Case持续时间,并分析每个订单的流程差异,是整个流程分析的基础。
为什么重要
该标识符对于关联所有相关事件至关重要,可支持对每个销售订单生命周期进行完整的端到端分析。
获取位置
位于“SalesTable”表的“SalesId”字段。
示例
SO-00102345SO-00102346SO-00102347
|
|||
|
最近数据更新时间
LastDataUpdate
|
表示数据最近一次从源系统刷新或提取时间的时间戳。 | ||
|
说明
该属性记录最近一次从Microsoft Dynamics 365提取数据的日期和时间,帮助了解所分析数据的新鲜度。 对于任何流程分析,了解数据的时效性都是做出明智决策的关键。该时间戳明确显示数据最近更新时间,帮助用户建立对数据的信任,确保分析结论基于当前信息。
为什么重要
它确保用户了解数据的新鲜度,这对于流程挖掘分析的相关性和准确性至关重要。
获取位置
该值在数据提取时生成,并在数据摄取过程中附加到每条记录。
示例
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
源系统
SourceSystem
|
标识数据来源的信息系统。 | ||
|
说明
该属性指定记录事件数据的源应用程序。在此场景中,通常为“Microsoft Dynamics 365”。 在单系统分析中,它可能看似多余;但在合并多个系统的数据时,例如独立的CRM或仓库管理系统,它就十分重要。该属性可确保数据血缘清晰,并通过定位记录来源,帮助排查数据提取问题。
为什么重要
它提供有关数据来源的重要背景信息,尤其适用于多系统数据集成,可确保数据血缘清晰。
获取位置
这是一个静态值,通常在数据转换过程中添加,用于标记数据集来源。
示例
Microsoft Dynamics 365 F&OMicrosoft Dynamics 365 Sales
|
|||
|
客户名称
CustomerName
|
提交销售订单的客户名称。 | ||
|
说明
该属性包含与销售订单关联的客户法定名称。它通过将销售订单中的客户账号与客户主数据连接获得。 按客户分析流程是了解客户特定行为和服务水平的基础。它有助于识别哪些客户经历的延迟最多、返工率最高,或采用非标准流程路径。这对于提升客户满意度和有效管理重点客户至关重要。
为什么重要
支持以客户为中心的分析,识别特定客户的模式、延迟或问题,直接帮助提升客户满意度。
获取位置
使用“SalesTable”中的“CustAccount”字段从“CustTable”查询获得。
示例
Contoso LtdAdatum CorporationFabrikam Inc.
|
|||
|
客户要求交付日期
RequestedDeliveryDate
|
客户要求订单交付的日期。 | ||
|
说明
该属性存储客户最初要求收货的日期。该日期在创建订单时记录,是从客户角度衡量交付绩效的基准。 该日期是“Delivery Date Adherence”仪表板的重要输入。将“RequestedDeliveryDate”与“ConfirmedDeliveryDate”和实际“Goods Delivered”日期进行比较,可以了解企业满足客户期望的程度。较大差距可能表明计划、库存或物流存在问题。
为什么重要
它代表客户对交付时间的期望,是衡量客户满意度和准时交付绩效的重要基准。
获取位置
位于“SalesTable”表中,通常命名为“DeliveryDate”或类似名称。
示例
2023-05-102023-06-012023-05-25
|
|||
|
确认交付日期
ConfirmedDeliveryDate
|
公司向客户确认并承诺的交付日期。 | ||
|
说明
Confirmed Delivery Date是销售组织向客户承诺交付商品的日期。该日期在完成库存可用性、生产计划等内部检查后确定。 该属性对于从运营承诺角度计算“Delivery Date Adherence Rate”KPI至关重要。与客户最初提出的日期相比,它提供了更现实的内部准时交付基准。分析与该日期的偏差,有助于识别物流和履约中的内部流程问题。
为什么重要
它代表公司对客户的承诺,是衡量履约可靠性和运营绩效的重要内部基准。
获取位置
位于销售订单行数据中,通常在“SalesLine”表中,字段名类似“ConfirmedDlv”。
示例
2023-05-122023-06-012023-05-28
|
|||
|
订单金额
OrderValue
|
销售订单的货币总价值。 | ||
|
说明
该属性表示销售订单的财务总额,包括所有商品、税费和费用,是与每个Case相关的关键财务指标。 Order Value对于基于价值的流程分析至关重要。它支持按价值划分流程,了解高价值订单是否采用不同处理方式,或是否比低价值订单经历更多延迟。这有助于优先改进财务影响最大的Case,并支持“Sales Order Value by Segment”等仪表板。
为什么重要
支持按财务价值划分流程,帮助优先改进高价值订单,并了解流程偏差带来的成本影响。
获取位置
位于销售订单抬头数据中。具体表和字段请参阅Microsoft Dynamics 365文档,通常根据销售行金额计算。
示例
5250.7512300.00899.50
|
|||
|
销售渠道
SalesChannel
|
接收销售订单的渠道,例如Web、直销或合作伙伴渠道。 | ||
|
说明
Sales Channel表示客户订单的来源,可能是电子商务网站、直销团队、零售店、呼叫中心或合作伙伴网络。该维度通常根据业务需求在Dynamics 365中配置。 按销售渠道分析流程,有助于发现不同渠道之间的绩效差异。例如,Web订单可能比电话接收的订单处理更快、自动化程度更高。这些洞察支持针对不同渠道优化流程和分配资源,并支持“Sales Order Value by Segment”等仪表板。
为什么重要
支持比较不同销售渠道的绩效,发现与订单发起方式相关的特定低效环节或最佳实践。
获取位置
该信息通常存储在销售订单抬头或相关履约记录中。具体字段请参阅Microsoft Dynamics 365文档。
示例
Web直销合作伙伴零售
|
|||
|
付款到期日
PaymentDueDate
|
客户必须支付发票款项的截止日期。 | ||
|
说明
Payment Due Date根据发票日期和与客户约定的付款条件计算,并记录在客户发票中。 该属性是“Payment Due Date Compliance”分析和“On-Time Payment Rate”KPI的基础。将“PaymentDueDate”与实际“Payment Received”日期进行比较,企业可以识别逾期付款、分析不同客户群体的付款行为,并采取主动措施改善现金流、缩短应收账款周转天数(DSO)。
为什么重要
这是衡量付款绩效的基准,对于分析现金流和有效管理应收账款至关重要。
获取位置
位于“CustInvoiceJour”表的“DueDate”字段。
示例
2023-05-302023-06-152023-06-30
|
|||
|
准时交付
OnTimeDelivery
|
用于标识商品是否在确认交付日期当天或之前交付的布尔标记。 | ||
|
说明
该计算属性将每个销售订单中“Goods Delivered”活动的时间戳与“ConfirmedDeliveryDate”进行比较。如果按时或提前交付,则设为“true”;如果延迟,则设为“false”。 该标记是计算“Delivery Date Adherence Rate”KPI的基础。它支持轻松筛选和汇总准时与延迟订单,帮助快速识别与延迟交付相关的因素,例如特定产品、客户、地区或运输方式。
为什么重要
它直接衡量履约绩效是否达到承诺,对于监控客户满意度和供应链可靠性至关重要。
获取位置
通过比较“Goods Delivered”活动的“EventTime”与“ConfirmedDeliveryDate”属性计算。公式:(“Goods Delivered”时间戳 <= ConfirmedDeliveryDate)。
示例
truefalse
|
|||
|
准时付款
OnTimePayment
|
用于标识是否在付款到期日当天或之前收到付款的布尔标记。 | ||
|
说明
该计算属性将“Payment Received”活动的时间戳与“PaymentDueDate”进行比较。如果按时付款,则设为“true”;如果逾期,则设为“false”。 该标记是“On-Time Payment Rate”KPI的核心组成部分。它支持快速将客户划分为“on-time”和“late”付款客户。该分析可为信用政策、催收策略和客户关系管理提供依据,帮助识别长期逾期付款的客户。
为什么重要
它根据约定条款衡量客户付款行为,是管理现金流和评估信用风险的基础。
获取位置
通过比较“Payment Received”活动的“EventTime”与“PaymentDueDate”属性计算。公式:(“Payment Received”时间戳 <= PaymentDueDate)。
示例
truefalse
|
|||
|
商品编号
ItemNumber
|
销售订单中产品或服务的唯一标识符。 | ||
|
说明
Item Number用于标识所售具体产品。由于一个销售订单可能包含多个产品,该属性通常与行项目级别的事件数据关联。 按产品分析流程有助于发现产品特定问题。例如,某些产品可能对应更长的履约时间、更高的返工率或更频繁的信用冻结。这支持针对特定商品改进库存管理、产品数据配置或履约流程。
为什么重要
支持产品级分析,揭示特定商品是否与流程延迟、返工或其他低效问题相关。
获取位置
位于“SalesLine”表的“ItemId”字段。
示例
PROD-00123PROD-00548SVC-00045
|
|||
|
国家/地区
CountryRegion
|
客户收货地址所在的国家/地区。 | ||
|
说明
该属性表示销售订单发货的目的地国家/地区,源自Dynamics 365中存储的客户交付地址信息。 按国家/地区分析流程绩效,有助于识别区域差异。国际运输可能包含清关等额外步骤,从而延长周期时间。该分析有助于了解并优化不同地理市场的物流流程。
为什么重要
支持地理维度分析,帮助识别供应链中的区域瓶颈、合规问题或绩效差异。
获取位置
源自与销售订单关联的客户交付地址。国家/地区信息通常位于“LogisticsPostalAddress”表中,并通过“SalesTable”中的交付地址链接进行连接。
示例
USADEUCANGBR
|
|||
|
是否返工
IsRework
|
用于标识销售订单是否经历返工(例如重复活动)的布尔标记。 | ||
|
说明
该计算属性用于识别偏离直接“happy path”流程的Case。通过识别表明某个步骤被重复执行的活动序列来检测返工,例如订单取消确认后再次确认,或商品拣选后退回库存。 标记返工Case对于“Sales Order Rework Rate”KPI至关重要。它支持分析人员快速筛选并调查低效流程,了解返工的根本原因,可能包括数据录入错误、信用问题或库存问题。减少返工是许多流程改进项目的主要目标。
为什么重要
通过标记需要重复步骤的Case,量化流程低效程度,支持针对性分析以减少浪费和延迟。
获取位置
流程挖掘工具通过分析每个Case的活动序列计算该属性。例如,检测到(A -> B -> C -> B)这样的模式时,就会将该Case标记为返工。
示例
truefalse
|
|||
|
用户名
UserName
|
执行活动的用户名称。 | ||
|
说明
该属性标识负责执行特定任务的员工或系统用户,例如确认订单或创建发票的人员。它通常关联Microsoft Dynamics 365中的用户ID。 按用户分析绩效有助于识别培训需求、发现优秀员工并确保工作量合理分配。它对于合规和审计也十分重要,可明确流程中每项操作的责任归属。
为什么重要
它支持按个人或团队分析流程绩效,帮助识别培训机会、工作量失衡和资源相关瓶颈。
获取位置
该属性源自各交易表中的“CreatedBy”或“ModifiedBy”等用户ID字段,再与主用户表(例如“UserInfo”)连接以获取完整姓名。
示例
Alice JohnsonRobert Brown系统管理员
|
|||
|
结束时间
EndTime
|
活动完成的准确日期和时间。 | ||
|
说明
End Time时间戳记录活动结束的时刻。在数据可用时,相比根据下一项活动的开始时间推断活动时长,它能提供更准确的活动持续时间。 同时拥有开始时间和结束时间后,便可准确计算每项活动的“Processing Time”,并将其与活动之间的“Waiting Time”区分开来。这对于识别耗时任务和存在长时间延迟的流程步骤非常有价值。
为什么重要
支持准确计算单项活动的处理时间,并区分实际工作时间与空闲等待时间。
获取位置
与Start Time类似,该属性源自各种日期和时间字段,可能来自“ModifiedDateTime”字段,或“SalesTable”“WHSLoadTable”等表中的具体状态更新时间戳。
示例
2023-04-15T09:12:30Z2023-04-18T14:35:00Z2023-04-25T11:21:55Z
|
|||
|
运输方式
ShippingMethod
|
用于向客户运输商品的方式或承运商。 | ||
|
说明
该属性指定交付所使用的运输服务,例如“Ground Shipping”“Air Freight”或具体承运商名称。通常在订单处理期间,根据客户偏好、成本和交付速度进行选择。 对于“Shipping Method Performance”仪表板,该维度十分重要。按运输方式分析从“Goods Packed”到“Goods Delivered”的周期时间,有助于识别速度更快、更可靠或更容易延迟的承运商。这些洞察支持更合理的物流规划和承运商选择。
为什么重要
支持分析不同承运商和运输选项的绩效,帮助从成本、速度和可靠性等方面优化物流。
获取位置
该信息通常存储在销售订单抬头或相关履约记录中。请参阅Microsoft Dynamics 365文档。
示例
FedEx GroundUPS Next Day AirDHL Express
|
|||
|
销售订单状态
SalesOrderStatus
|
数据提取时销售订单的当前状态。 | ||
|
说明
该属性反映销售订单的整体状态,例如“Open order”“Invoiced”“Canceled”或“Delivered”。这是销售订单抬头中维护的汇总状态。 活动日志提供流程的动态视图,而最终状态适合用于筛选和分组。分析人员可以轻松筛选所有未结订单,以了解当前工作量,也可以将成功完成的订单与取消订单分开,分析取消原因。
为什么重要
它提供订单状态的快照,支持按未结、已关闭或已取消订单筛选分析,便于工作量管理和结果分析。
获取位置
位于“SalesTable”表的“SalesStatus”字段。
示例
延期交货已交付已开票已取消
|
|||
订单到收款-销售订单处理活动
| 活动 | 说明 | ||
|---|---|---|---|
|
发票已创建
|
表示已生成并过账已发运货物或服务的销售发票。这是一项核心财务交易,用于正式记录客户应付款项。 | ||
|
为什么重要
该活动标志财务结算阶段开始。从发运到创建发票的时间是“Invoice Generation Cycle Time”KPI的关键指标,并会影响现金流。
获取位置
这是一项明确的财务交易。事件从Sales Invoice日志(CustInvoiceJour)的过账日期和时间中捕获。
采集
捕获Sales Invoice日志的过账时间戳。
事件类型
explicit
|
|||
|
商品已发运
|
该事件表示订单中的已包装货物已发出并离开仓库。在Dynamics 365中,这通常通过装箱单过账正式确认。 | ||
|
为什么重要
这是标志内部履行流程结束、交付阶段开始的关键里程碑,也是计算按时发运绩效的重要时间戳。
获取位置
这是从装箱单日志(CustPackingSlipJour)的过账日期和时间中明确捕获的事件。
采集
捕获装箱单日志的过账时间戳。
事件类型
explicit
|
|||
|
已收到付款
|
该活动表示已收到并核销客户针对发票支付的款项。事件发生在Accounts Receivable模块中,并关联回原始发票。 | ||
|
为什么重要
这是分析现金转换周期的关键里程碑,对于衡量“On-Time Payment Rate”KPI和识别收款延误至关重要。
获取位置
这是Accounts Receivable模块中的明确事件,从客户付款结算的交易日期(CustSettlement)中捕获,该结算会关闭发票交易(CustTrans)。
采集
从CustSettlement表中捕获结算日期,并将其关联回发票和销售订单。
事件类型
explicit
|
|||
|
订单已关闭
|
表示销售订单已成功处理完成,货物已全部发运、发票已开具,且预计不会再有后续交易。这标志着流程成功结束。 | ||
|
为什么重要
该活动是成功完成案例的主要终点,对于计算端到端周期时间和吞吐量至关重要。
获取位置
根据SalesTable中的状态字段推断。当“Sales status”为“Invoiced”,且订单行状态也为“Invoiced”时,即可视为订单已关闭。
采集
根据SalesTable状态字段变为“Invoiced”推断。时间戳通常取最后一笔相关交易的日期,例如开票或收款日期。
事件类型
inferred
|
|||
|
订单已确认
|
该活动表示销售订单已正式确认,承诺交付指定的货物或服务。在Dynamics 365中,这是由用户明确执行的操作,并会生成确认日志。 | ||
|
为什么重要
确认是正式启动履行流程的关键里程碑。衡量从创建到确认的时间,可以了解前台处理效率。
获取位置
这是从Sales Order Confirmation日志(SalesConfirmJour)的过账日期明确捕获的事件。时间戳可关联回SalesTable。
采集
捕获Sales Order Confirmation日志的过账时间戳。
事件类型
explicit
|
|||
|
销售订单已创建
|
该事件表示销售代表或自动化渠道在系统中初始创建销售订单。当主销售订单表中新记录创建并保存时,系统会明确记录此事件。 | ||
|
为什么重要
该活动是所有销售订单案例的通用起点,提供计算销售订单整体周期时间和分析吞吐量所需的初始时间戳。
获取位置
这是从Microsoft Dynamics 365中SalesTable抬头记录的“Created date and time”字段明确捕获的事件。
采集
从SalesTable实体读取创建时间戳。
事件类型
explicit
|
|||
|
商品已交付
|
表示货物已成功送达客户指定地址。该信息通常由外部承运商系统更新,或通过人工确认录入。 | ||
|
为什么重要
该活动对于衡量“Delivery Date Adherence”KPI、了解面向客户的实际周期时间至关重要,也有助于评估承运商绩效。
获取位置
标准D365不会原生将其作为明确事件进行跟踪。通常需要接收承运商集成系统的更新,或通过销售订单或发运记录中的人工状态更新进行推断。
采集
根据集成承运商数据流或人工状态字段更新推断。
事件类型
inferred
|
|||
|
商品已包装
|
该活动标志包装流程完成,已拣选物料完成汇总并准备发运。在D365中,这可能与生成装箱单同时发生。 | ||
|
为什么重要
拣选与包装之间的时间可以揭示包装工位的瓶颈,也是整体履行周期中的关键子流程。
获取位置
该事件可以从WMS模块中容器包装作业完成记录明确获取,也可以根据装箱单日志(CustPackingSlipJour)的生成进行推断,因为后者通常表示包装结束。
采集
根据包装作业完成时间或装箱单日志的创建日期推断。
事件类型
inferred
|
|||
|
商品已拣选
|
表示已从仓库库位完成订单全部物料的实物拣选。通常在WMS模块中,拣选员完成拣选清单或工作单时记录该事件。 | ||
|
为什么重要
跟踪拣选完成时间对于分析仓库效率至关重要。该阶段的延误会直接影响整体发运时间。
获取位置
这是Warehouse Management模块中明确记录的事件,从与销售订单拣选相关的仓库作业(WHSWorkTable)完成时间戳中捕获。
采集
捕获拣选“Work”状态更新为“Closed”的时间戳。
事件类型
explicit
|
|||
|
已执行信用检查
|
表示已完成对销售订单关联客户的信用检查。该检查可能由系统自动执行,也可能由人工审核完成,通常会导致订单信用状态发生变化。 | ||
|
为什么重要
分析信用检查的持续时间和结果,有助于识别订单审批流程中的瓶颈。频繁挂起或审批时间过长,可能严重延误订单履行。
获取位置
通常根据SalesTable中与信用管理相关的状态变化推断,例如订单从带有信用原因的“On hold”变为“Open”。如果使用高级模块,也可能记录在信用管理表中。
采集
根据SalesTable或相关信用挂起表中的状态变更历史推断。
事件类型
inferred
|
|||
|
已释放至仓库
|
标志销售订单正式释放至仓库,进入拣选和发运作业阶段。在使用Warehouse Management(WMS)模块的环境中,这是一个独立步骤。 | ||
|
为什么重要
该活动将订单处理与实物履行区分开来。分析订单等待释放的时间,有助于发现资源规划或系统集成问题。
获取位置
这是从与销售订单关联的仓库释放记录(WHSLoadTable、WHSShipmentTable)中明确捕获的事件。
采集
捕获对应仓库装载或发运记录的创建时间戳。
事件类型
explicit
|
|||
|
库存已预留
|
该事件表示销售订单行所需库存已在系统中完成实物或自动预留,确保相关物料可供拣选和履行。 | ||
|
为什么重要
跟踪库存预留情况,有助于分析订单确认与仓库作业开始之间的延误。这是“Inventory Allocation Lead Time”KPI的重要依据。
获取位置
可根据与销售订单行关联的库存交易记录(InventTrans)的创建或更新进行推断,其中状态表示库存预留,例如“On order”“Reserved physical”。
采集
根据订单库存交易记录(InventTrans)标记为已预留的时间戳推断。
事件类型
inferred
|
|||
|
订单已取消
|
该事件表示销售订单在全部发运和开票完成前被取消,是流程未成功结束的一种替代结果。 | ||
|
为什么重要
跟踪取消情况有助于识别销售流失或流程失败的原因。分析订单在何时、为何被取消,可以推动流程改进。
获取位置
根据SalesTable中的“Sales status”字段变为“Canceled”推断。时间戳应取记录该状态变更的时间。
采集
根据SalesTable状态字段变为“Canceled”推断。
事件类型
inferred
|
|||
提取指南
立即优化订单到收款流程:销售订单处理
精准定位低效环节,将周期时间缩短30%,加快履约。
无需信用卡,几分钟即可完成设置。