您的订单到收款,销售订单处理数据模板
您的订单到收款,销售订单处理数据模板
- 建议收集的属性
- 需要跟踪的关键活动
- Salesforce Sales Cloud数据提取指南
订单到收款-销售订单处理属性
| 名称 | 说明 | ||
|---|---|---|---|
| 事件时间 EventTime | 活动发生的准确日期和时间。 | ||
| 说明 Event Time或时间戳记录活动发生的准确时刻。该数据对于正确排列事件顺序和计算活动间时长至关重要,也是所有基于时间的流程挖掘分析的基础。 该属性用于排列每个案例中的活动、计算周期时间、识别等待时间,以及分析不同时段的流程绩效。时间戳不准确或缺失,会严重限制分析价值。 为什么重要 时间戳对于按时间顺序排列事件,以及计算周期时间和瓶颈等所有绩效指标至关重要。 获取位置 对应“Order”对象或关联记录中的“CreatedDate”或“LastModifiedDate”等字段。对于特定事件,也可能来自“Task”记录的完成日期。 示例 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:00:00Z | |||
| 活动名称 ActivityName | 销售订单生命周期中发生的具体业务事件或任务的名称。 | ||
| 说明 活动名称描述销售订单流程中的一个步骤,例如“订单已创建”“已执行信用检查”或“发票已发送”。这些活动是流程图的基本组成部分,来源于系统事件、状态变更或任务完成记录。 分析这些活动,可以直观呈现顺序流,识别常见路径(变体),并衡量每个步骤的频率和持续时间。这是了解流程实际运行情况的基础。 为什么重要 此属性定义流程图中的步骤。没有它,您无法呈现顺序流,也无法分析销售订单的实际处理方式。 获取位置 通常来源于“Order.Status”字段的状态变更、关联记录(例如Invoice)的创建,或与Order相关的已完成“Task”或“Event”记录。 示例 订单已创建订单已批准货物已发运已收到付款 | |||
| 销售订单 SalesOrderId | 每个销售订单的唯一标识符,作为跟踪整个订单到收款流程的主案例。 | ||
| 说明 Sales Order ID是流程分析的基础,用于在订单生命周期中唯一标识每个客户订单。它关联从创建、审批到履约和付款的所有相关活动。 在流程挖掘中,与特定订单相关的每个事件都关联至该ID。这样即可端到端还原订单旅程,并详细分析单个订单的周期时间、流程变体和瓶颈。 为什么重要 此属性对于将所有相关事件归入同一案例至关重要,从而支持按销售订单可视化和分析端到端流程顺序流。 获取位置 这是标准Salesforce“Order”对象中的“Id”字段。 示例 8018d000000XwPBAA08018d000000Y1qCAAS8018d000000Z3kDAB1 | |||
| 最近数据更新时间 LastDataUpdate | 表示数据最近一次提取或刷新的时间戳。 | ||
| 说明 该属性记录最近一次从源系统提取数据的日期和时间,为所分析数据的新鲜度提供重要背景信息。 分析人员利用该信息判断当前查看的是否为最新流程数据,并评估分析结论的时效性。这是任何流程挖掘项目的重要元数据。 为什么重要 告知用户数据的时效性,确保用户了解分析所依据的数据有多新。 获取位置 这是在数据提取、转换和加载(ETL)过程中生成并添加的时间戳。 示例 2023-11-01T05:00:00Z | |||
| 源系统 SourceSystem | 标识数据提取自哪个系统。 | ||
| 说明 该属性指定流程数据的来源。在本次分析中,其值始终为“Salesforce Sales Cloud”。 在多系统环境中,该字段对于数据血缘和问题排查至关重要。即使在单一系统环境中,它也能提供有关数据来源的重要元数据。 为什么重要 提供有关数据来源的必要背景信息,对于数据治理以及整合多个源系统的数据十分重要。 获取位置 通常是在数据提取过程中添加的静态值,用于标记数据集。 示例 Salesforce Sales Cloud | |||
| 客户名称 AccountName | 下达销售订单的客户或公司的名称。 | ||
| 说明 Account Name标识与销售订单关联的客户,从而支持以客户为中心的流程分析。 借助该属性,分析人员可以筛选特定客户的流程,比较不同客户群体的流程绩效,或识别某些客户是否持续遇到流程问题。它是将流程绩效直接关联到客户体验的关键。 为什么重要 将流程绩效关联至具体客户,支持按客户分析和分组,以识别模式或问题。 获取位置 “Order”对象包含查找字段“AccountId”。该ID必须与“Account”对象关联,才能获取“Account.Name”字段。 示例 Global Tech Inc.Innovate Solutions LLCVenture Dynamics | |||
| 客户要求的交付日期 RequestedDeliveryDate | 客户要求订单交付的日期。 | ||
| 说明 该属性记录客户期望收到货物的日期,是衡量交付绩效和客户满意度的重要基准。 该日期直接用于“交付日期遵循情况跟踪”仪表板和“准时交付率”KPI,并与实际交付日期(“Goods Delivered”时间戳)进行比较,以判断订单是否按时、提前或延迟交付。 为什么重要 这是衡量准时交付绩效的主要基准,也是客户满意度和运营有效性的关键指标。 获取位置 通常是“Order”对象中的自定义日期字段。具体名称可能有所不同,请查阅Salesforce Sales Cloud文档或架构。 示例 2023-11-152023-12-012024-01-10 | |||
| 总周期时间 CycleTime | 从销售订单创建到最终关闭所经过的总时间。 | ||
| 说明 Total Cycle Time是衡量销售订单端到端流程时长的关键绩效指标,计算方式为第一个事件(例如“Order Created”)与最后一个事件(例如“Order Closed”)之间的时间差。 该指标是“销售订单端到端周期时间”仪表板的重点。分析周期时间有助于识别整体流程低效,并衡量改进措施的影响。还可以结合国家或产品系列等其他属性切分数据,调查周期时间差异。 为什么重要 这是衡量整体流程效率、识别可能反映系统性问题的长期订单的基础KPI。 获取位置 在数据转换过程中,针对每个“SalesOrderId”,用最后一个事件的时间戳减去第一个事件的时间戳计算得出。 示例 10天4小时25天11小时5天2小时 | |||
| 操作执行人 UserPerformingAction | 执行该活动的用户或系统代理的名称。 | ||
| 说明 该属性标识负责完成流程步骤的个人。执行者可能是销售代表、信用分析师或自动化系统用户。 基于该用户的分析对于了解工作负载分布、个人绩效和自动化程度至关重要。它有助于回答“哪些用户处理的返工最多?”或“哪些团队的审批速度更快?”等问题,也可用于社会网络分析,了解工作如何在不同人员之间交接。 为什么重要 支持按用户、团队或角色分析绩效,并帮助识别自动化机会或培训需求。 获取位置 可在“Order”对象的“LastModifiedById”或“Task”记录的“OwnerId”等字段中找到。这些ID需要与“User”对象关联,才能获取用户姓名。 示例 Alice SmithBob Johnson系统自动化信用团队 | |||
| 订单总金额 TotalOrderAmount | 销售订单的货币总价值。 | ||
| 说明 该属性表示客户订单的财务总金额,是了解流程效率或低效所产生业务影响的关键指标。 在分析中,订单总金额可用于划分案例,例如比较高价值订单与低价值订单的处理方式和延迟情况。它也是计算财务KPI、了解流程中资金流转价值的基础。 为什么重要 支持流程财务分析,可以按订单价值进行分组,并量化延迟或返工造成的金额影响。 获取位置 这是标准Salesforce“Order”对象中的“TotalAmount”字段。 示例 5400.50125000.00950.75 | |||
| 订单状态 OrderStatus | 事件发生时销售订单的状态。 | ||
| 说明 该属性记录销售订单的状态,例如“Draft”“Activated”“Shipped”或“Closed”。状态变更通常是生成流程日志活动的来源。 分析订单状态可以为每个事件提供背景信息,对于跟踪订单进度至关重要。它有助于了解案例结果,例如区分已“Cancelled”的订单和成功“Closed”的订单。 为什么重要 为每个事件提供关键背景信息,通常也是定义活动的依据。它对于分析取消等案例结果同样重要。 获取位置 这是标准Salesforce“Order”对象中的“Status”下拉选项字段。 示例 草稿已激活已发运已关闭已取消 | |||
| 事件结束时间 EventEndTime | 活动完成的准确日期和时间。 | ||
| 说明 Event End Time标志着活动的完成。许多流程挖掘工具会根据下一活动的开始时间推断该时间,但明确记录结束时间可以更准确地计算活动时长,尤其适用于持续时间较长的任务。 该属性用于精确计算活动的处理时间。对于“Credit Check Performed”或“Inventory Allocated”等持续时间较长的任务,它尤其有价值,有助于区分实际处理时间和空闲等待时间。 为什么重要 支持精确计算单个活动的处理时间,对于识别瓶颈和资源密集型步骤至关重要。 获取位置 对于给定案例,可根据序列中后续事件的“StartTime”推导。对于某些活动,也可能使用“Task.CompletedDateTime”等特定字段。 示例 2023-10-26T10:05:12Z2023-10-26T15:00:00Z2023-10-27T11:20:30Z | |||
| 产品系列 ProductFamily | 订单中产品所属的类别或系列。 | ||
| 说明 Product Family提供销售订单中所含商品的高层分类,从而支持按销售产品类型进行流程分析。 该属性可用于划分流程,判断不同产品系列是否具有不同的流程路径、更长的周期时间或更高的返工率。例如,复杂的可配置产品可能比标准现货产品经历更复杂的审批和履约流程。 为什么重要 支持按产品类别进行流程分析,揭示不同产品类型是否会导致流程效率差异。 获取位置 从“Product2”对象获取。该对象通过“OrderItem”连接对象与“Order”关联,需要连接Order→OrderItem→PricebookEntry→Product2。 示例 硬件软件许可证专业服务支持合同 | |||
| 付款收款时长 PaymentCollectionDuration | 从向客户发送发票到收到付款之间经过的时间。 | ||
| 说明 该计算指标衡量订单到收款周期最后一个关键阶段的效率,即收款效率。它表示“Invoice Sent to Customer”活动与“Payment Received”活动之间的时长。 该属性直接支持“付款收款时长”仪表板和“付款实现时间”KPI。分析该时长有助于财务部门识别收款瓶颈、评估付款条款的有效性,并寻找加快现金流的机会。 为什么重要 衡量应收账款流程的效率,直接影响公司的现金流。 获取位置 在数据转换过程中,针对每个案例,用“Payment Received”事件的时间戳减去“Invoice Sent to Customer”事件的时间戳计算得出。 示例 30天15天8小时45天 | |||
| 信用检查状态 CreditCheckStatus | 订单信用检查流程的结果。 | ||
| 说明 该属性表示客户信用评估的结果,通常是订单流程中的关键关口。常见值包括“Approved”“Rejected”或“Pending”。 该属性对于“信用检查瓶颈分析”仪表板至关重要。通过跟踪订单进入和离开信用检查阶段的时间及最终状态,企业可以衡量该步骤的持续时间和结果,并识别其是否可能造成延迟。 为什么重要 直接支持信用检查步骤分析,帮助衡量其持续时间、成功率及其对整体周期时间的影响。 获取位置 可能是“Order”或“Account”对象中的自定义字段。请查阅Salesforce Sales Cloud文档或架构。 示例 已批准已拒绝待审核无需处理 | |||
| 发票ID InvoiceId | 与销售订单关联的发票唯一标识符。 | ||
| 说明 Invoice ID将销售订单关联至对应的财务发票。发票创建和发送是订单到收款流程后半段的关键里程碑。 该属性对于跟踪从订单履约到付款的流程至关重要。它支持精确衡量“Invoice Created”和“Invoice Sent to Customer”活动,这些数据用于计算“付款收款时长”。 为什么重要 将销售订单关联至开票子流程,支持准确跟踪财务活动和付款周期时间。 获取位置 通常是“Order”对象中的自定义查找字段,指向标准或自定义“Invoice”对象。具体实现方式可能有所不同。 示例 INV-001234INV-001235INV-001236 | |||
| 是否准时交付 IsOnTimeDelivery | 用于标识货物是否在客户要求的交付日期当天或之前送达。 | ||
| 说明 该布尔属性直接衡量交付绩效是否符合客户预期,计算方式是比较“Goods Delivered”活动的时间戳与“RequestedDeliveryDate”。 它是计算“准时交付率”KPI的核心。分析该标志有助于企业了解交付可靠性和承诺履行情况,而这正是客户满意度的重要驱动因素。结合其他属性后,还可以发现某些运输方式或地区的准时交付率是否较低。 为什么重要 提供衡量客户承诺履行情况的清晰二元指标,直接支持“准时交付率”KPI。 获取位置 在数据转换过程中计算。逻辑为:IF(“Goods Delivered”EventTime<=“RequestedDeliveryDate”)THEN true ELSE false。 示例 truefalse | |||
| 是否自动执行 IsAutomated | 用于标识该活动由系统流程还是人工用户执行的标志。 | ||
| 说明 该布尔属性用于区分系统自动化触发的事件(例如自动状态更新)和用户手动执行的事件,是了解流程自动化程度的关键。 分析该属性有助于量化自动化对效率和一致性的影响,比较自动化路径与人工路径,并发现进一步自动化的机会,从而减少人工工作量和潜在错误。 为什么重要 帮助区分系统操作和用户操作,对于自动化分析以及识别减少人工工作的机会至关重要。 获取位置 在数据转换过程中推导:检查“UserPerformingAction”是否为指定的系统用户,或根据活动类型应用相应规则。 示例 truefalse | |||
| 是否返工 IsRework | 用于标识销售订单是否经历返工的标志,例如活动重复执行或流程出现循环。 | ||
| 说明 该计算属性用于识别偏离线性向前推进的案例。当活动重复执行,或流程因错误、信息缺失或审批被拒而返回较早阶段时,即会发生返工。 该标志用于计算“销售订单返工率”KPI,并驱动“销售订单返工与错误率”仪表板。它有助于量化低效的发生频率和影响,指出需要加强质量控制或明确流程的环节。 为什么重要 通过标记需要额外计划外工作的订单,量化流程低效,而这会直接影响成本和周期时间。 获取位置 由流程挖掘软件或数据转换过程计算,方法是检测特定案例中的重复活动名称或流程回退。 示例 truefalse | |||
| 订单负责人 OrderOwner | 负责管理销售订单的主要用户。 | ||
| 说明 Order Owner是对订单负主要责任的销售代表或客户经理。它不同于执行具体操作的用户,因为订单负责人负责整个案例的推进。 按负责人分析,有助于评估团队或个人管理订单组合时的工作负载和绩效。该分析可以发现哪些负责人的订单经常停滞或需要返工,从而提示潜在的辅导机会。 为什么重要 标识对订单成功负责的人员,支持在负责人层面分析工作负载和绩效。 获取位置 这是“Order”对象中的“OwnerId”字段。该ID可以与“User”对象关联,以获取负责人的姓名。 示例 Jane DoeJohn Smith东区销售团队 | |||
| 运输国家/地区 ShippingCountry | 销售订单货件的目的地国家或地区。 | ||
| 说明 该属性指定订单的运输目的地国家或地区,是订单到收款流程地理分析的重要维度。 按运输国家或地区分析,可以揭示不同地区的流程绩效差异,例如国际订单交付时间更长,或收款周期存在差异。通过流程分组,企业可以了解并解决特定地区的挑战。 为什么重要 支持按地理区域划分流程,有助于发现地区绩效差异、合规问题或物流挑战。 获取位置 这是标准Salesforce“Order”对象中的“ShippingCountry”字段。 示例 USA德国日本巴西 | |||
| 运输方式 ShippingMethod | 为货物运输选择的方式,例如“Standard Ground”“Express”或“International”。 | ||
| 说明 该属性表示为订单交付选择的物流服务等级,直接影响交付时效和成本。 在“运输方式效率分析”中,该属性用于比较不同运输选项的绩效,帮助判断加急运输是否达到时效承诺,以及不同方式如何影响从“Goods Shipped”到“Goods Delivered”的整体时长。 为什么重要 支持物流绩效分析,帮助评估不同运输选项的成本和效率。 获取位置 可能是“Order”对象或关联自定义“Shipment”对象中的自定义字段。请查阅Salesforce Sales Cloud文档或架构。 示例 标准陆运两日快递空运次日达国际优先 | |||
| 销售渠道 SalesChannel | 下达销售订单的渠道,例如“Web”“Direct Sales”或“Partner”。 | ||
| 说明 Sales Channel属性根据订单来源对订单进行分类,从而支持比较不同渠道的流程绩效。 该属性对于“销售渠道绩效对比”仪表板至关重要。按渠道筛选或比较后,企业可以识别效率最高、返工最多的渠道,以及需要标准化以统一绩效的环节。 为什么重要 支持比较不同业务渠道的绩效,帮助识别最佳实践和流程统一机会。 获取位置 通常是“Order”或“Opportunity”对象中的自定义下拉选项字段。请查阅Salesforce Sales Cloud文档或架构。 示例 直销Web门户合作伙伴网络内部销售 | |||
订单到收款-销售订单处理活动
| 活动 | 说明 | ||
|---|---|---|---|
| 发票已创建 | 表示为销售订单生成财务发票。该事件可通过创建关联的“Invoice”对象捕获,既可以使用Salesforce Billing原生功能,也可以通过集成实现。 | ||
| 为什么重要 该里程碑标志着财务收款环节的开始。交付与开票之间的时间可以揭示影响现金流的行政瓶颈。 获取位置 根据与“Order”对象关联的“Invoice”对象(标准或自定义)的创建日期推断。 采集 使用关联Invoice记录的“CreatedDate”。 事件类型 inferred | |||
| 已收到付款 | 标志着客户付款已收到并完成对账。该信息通常以状态变更的形式从财务系统更新至Salesforce。 | ||
| 为什么重要 该事件是销售收入实现现金回收的最后一步。分析从“Invoice Sent”到此事件的时间,对于管理现金流和应收账款周转天数(DSO)至关重要。 获取位置 根据“Invoice”对象的状态变更为“Paid”或“Closed”推断。该更新由与会计或支付处理系统的集成驱动。 采集 跟踪外部财务系统集成对“Invoice”对象状态的变更。 事件类型 inferred | |||
| 订单已关闭 | 表示销售订单已在系统中成功完成并最终关闭。根据订单的最终状态更新推断,说明无需进一步操作。 | ||
| 为什么重要 这是流程主要“理想路径”的结束事件。测量到该活动的总耗时,可得出“订单到关闭平均时间”KPI。 获取位置 根据“Order”对象的“Status”字段变更为“Closed”“Completed”或“Fulfilled”等最终值推断。时间戳可通过字段历史跟踪获取。 采集 监控“Order”对象的字段历史,查找其状态变更为最终完成状态的记录。 事件类型 inferred | |||
| 订单已创建 | 表示系统中销售订单记录的初始创建。当Salesforce中新的“Order”对象实例首次保存时,系统会明确记录此事件。 | ||
| 为什么重要 这是Order to Cash流程的主要开始事件。分析从这一时点到后续活动的耗时,对于了解整体周期时间至关重要。 获取位置 “Order”对象的创建事件。时间戳取自Order记录标准的“CreatedDate”字段。 采集 直接取自“Order”对象的“CreatedDate”时间戳。 事件类型 explicit | |||
| 订单已激活 | 表示订单已完成最终确认,可以进入履约和开票阶段的标准Salesforce事件。激活后,订单将无法进行大多数更改,系统会通过特定状态变化记录此事件。 | ||
| 为什么重要 激活是确认订单有效性的关键且不可逆里程碑,标志着订单正式从销售交接至运营,也是跟踪销售周期时间的核心环节。 获取位置 可根据“Order”对象的标准“Status”字段变为“Activated”推断。时间戳记录在“Order”字段历史跟踪中。 采集 监控“Order”对象的字段历史,跟踪状态是否变为“Activated”。 事件类型 inferred | |||
| 货物已交付 | 表示货件已成功送达客户。该信息来自承运商系统,并回写至Salesforce。 | ||
| 为什么重要 该事件对于计算“准时交付率”KPI和衡量面向客户的实际周期时间至关重要。它确认履约流程已完成。 获取位置 根据“Order”或自定义“Shipment”对象中“Delivery Date”字段已填充这一情况推断。该数据通常通过与运输物流服务商的集成获取。 采集 使用交付日期字段被填充时的时间戳。 事件类型 inferred | |||
| 货物已发运 | 表示订单已从仓库实际发出并运往客户的时点。此事件几乎总是由外部运输或ERP系统更新至Salesforce。 | ||
| 为什么重要 这是衡量“On-Time Shipping Rate”和整体履约效率的关键里程碑,标志着客户旅程进入交付阶段。 获取位置 可根据“Order”对象或相关自定义“Shipment”对象中填充“Shipped Date”或“Tracking Number”字段来推断。数据源自履约系统。 采集 使用首次填充发运日期或跟踪号码字段时的时间戳。 事件类型 inferred | |||
| 发票已发送给客户 | 表示发票已发送给客户以便付款。该事件通常通过发票记录的状态变更捕获。 | ||
| 为什么重要 这是“付款实现时间”KPI的触发事件。发票创建到发送之间的任何延迟,都会直接推迟付款期限的起算时间。 获取位置 根据“Invoice”对象的状态变更为“Sent”或类似值推断。已发送邮件的活动日志记录也可用于识别该事件。 采集 监控关联“Invoice”对象的“Status”字段,或查找邮件日志活动。 事件类型 inferred | |||
| 已完成信用检查 | 表示已完成对订单关联客户的信用状况检查。这通常是一个推断事件,当自定义字段(例如“Credit Check Status”)更新为“Passed”或“Completed”时记录。 | ||
| 为什么重要 这一活动通常是造成显著延迟的来源。衡量其处理时间和等待时间,对于分析“Credit Check Bottleneck Analysis”仪表板和改善现金流至关重要。 获取位置 可根据“Order”或相关“Account”对象中自定义字段的时间戳或状态变化推断,例如“Credit_Check_Date__c”或“Credit_Status__c”。 采集 跟踪表示信用检查完成的自定义字段更新。 事件类型 inferred | |||
| 库存已分配 | 表示订单中的产品已在库存系统中完成预留。此事件通常源自外部ERP或库存系统,并通过字段变化更新至Salesforce。 | ||
| 为什么重要 这一活动对于分析“Inventory Allocation Lead Time”KPI至关重要。此处的延迟会直接影响订单能否按时发运。 获取位置 需要进行系统分析。通常可根据“Order”或“OrderItem”对象的状态更新,或由集成流程填充自定义“Allocation_Date__c”字段来推断。 采集 跟踪ERP集成对Order或OrderItem对象的状态字段或日期字段所做的更新。 事件类型 inferred | |||
| 订单已发送至履约 | 表示已激活订单已交接至仓库或履约系统,进入拣货和包装环节。通常由集成触发订单状态变化来记录。 | ||
| 为什么重要 此事件将流程的商业环节与物流环节分开。跟踪从激活到此时点的耗时,有助于区分管理延迟和仓库处理延迟。 获取位置 可根据“Order”状态变为“Sent to Fulfillment”或“Awaiting Shipment”等值推断。此状态变化通常由与ERP或WMS的集成触发。 采集 监控“Order”对象的“Status”字段,识别表示履约交接的特定值。 事件类型 inferred | |||
| 订单已取消 | 表示订单在履约完成前已被取消。该事件通过订单记录的终止状态变更捕获。 | ||
| 为什么重要 这是一个关键的异常结束事件。分析订单取消的原因和时间,可以揭示销售流程、产品供应或客户信用方面的问题。 获取位置 根据“Order”对象的“Status”字段变更为“Cancelled”推断。时间戳可在“Status”字段的历史记录中找到。 采集 监控“Order”对象的字段历史,查找其状态变更为“Cancelled”的记录。 事件类型 inferred | |||
| 订单已批准 | 表示销售订单已获得所有必要人员的正式批准,可以进入下一阶段。可通过观察工作流中的最终审批步骤或相应的状态更新来记录。 | ||
| 为什么重要 这是解锁履约流程的关键里程碑。审批延迟可能显著影响整体订单到收款周期时间。 获取位置 可根据“Order”对象的状态字段变为“Approved”等值推断,也可根据相关“ProcessInstance”记录的完成日期得出。 采集 监控“Order”对象的“Status”字段,或跟踪审批流程历史是否完成。 事件类型 inferred | |||
| 订单已提交审批 | 表示草稿订单提交至正式审批工作流的时点。通常可根据订单状态变化,或Salesforce审批流程历史中创建的记录推断。 | ||
| 为什么重要 跟踪提交事件有助于衡量订单等待审批的时间和审核流程本身的效率,并突出审批前的瓶颈。 获取位置 可根据“Order”对象的状态变化推断,例如从“Draft”变为“Submitted for Approval”,也可跟踪与订单相关的“ProcessInstance”对象中的提交日期。 采集 跟踪状态字段变化,或查询“ProcessInstance”对象。 事件类型 inferred | |||
提取指南
步骤
- 前提条件:配置字段历史跟踪:创建报告前,Salesforce管理员必须确保已为Order对象启用字段历史跟踪。具体来说,应跟踪Status字段,以及用于表示事件的自定义字段,例如Credit_Check_Status__c或Fulfillment_Status__c。配置路径:Setup>Object Manager>Order>Fields & Relationships>Set History Tracking。
- 创建自定义报告类型:如需同时访问字段变更数据和订单详情,请创建自定义报告类型。进入Setup>Report Types。创建新的报告类型,将Orders设为主对象,再将Order History设为次要对象。确保关系设置为“'A' records may or may not have related 'B' records.”这样即使订单尚无历史记录,也能报告所有订单。将报告类型保存为“Orders with History”。
- 创建主“Events”报告:进入Reports选项卡并点击New Report。选择“Orders with History”报告类型。此报告将捕获基于字段变更的所有活动。
- 配置Events报告列:添加以下列:Order: Order Number(对应SalesOrderId)、Edit Date(对应EventTime)、User(对应UserPerformingAction)、Field/Event(发生变更的字段)、Original Value和New Value。还可从父级Order对象添加其他列,例如Order: Total Amount、Account: Account Name,以及Order: Company Authorized By Date(如适用,可作为RequestedDeliveryDate的替代字段)。
- 筛选Events报告:将Show Me筛选器设为All orders,将Date Field设为Created Date,并选择所需时间范围,例如Last 3 Months。为Field/Event列添加筛选条件,仅包含与活动对应的特定字段变更,例如Status、Credit_Check_Status__c。
- 创建“Order Created”报告:使用标准Orders报告类型创建第二个更简单的报告,仅用于捕获创建事件。添加Order Number、Created Date、Created By、Status、Total Amount和Account Name列。按所需时间范围筛选Created Date。
- 导出两份报告:运行两份报告并使用Export选项。选择Details Only和Comma Delimited .csv格式。
- 合并并转换数据:在Microsoft Excel等电子表格程序中打开导出的CSV文件,或使用Python等脚本语言处理。
- 对于“Events”报告,创建新的ActivityName列。使用公式或脚本,将字段变更数据映射到所需的活动名称。例如,如果Field/Event为“Status”,且New Value为“Activated”,则将ActivityName设为“Order Activated”。
- 对于“Order Created”报告,添加名为ActivityName的新列,并将所有行的值设为“Order Created”。将列名重命名为符合事件日志架构的名称,例如Order Number→SalesOrderId、Created Date→EventTime。
- 合并为单一事件日志:将转换后的“Order Created”数据追加到转换后的“Events”数据中,形成包含所有活动的统一列表。
- 完成上传准备:添加其余必需列:SourceSystem(固定值为“Salesforce Sales Cloud”)和LastDataUpdate(使用当前时间戳)。保存最终CSV文件前,检查所有列标题和数据格式,确保文件可直接上传。
配置
- 报告类型:连接Orders和Order History的自定义报告类型对于将状态变更及其他字段更新作为独立事件捕获至关重要。
- 字段历史跟踪:整个方法都依赖于在开始提取数据前为Order对象启用字段历史跟踪。必须跟踪Status等关键字段,以及表示流程步骤的自定义字段。
- 日期范围筛选:使用Order对象中的Created Date作为主要筛选条件,确保分析的是一致的订单群组。建议初次分析使用3至6个月的时间范围。
- 数据导出服务:对于大数据量环境,也可以按周或按月安排Data Export Service,导出指定对象(Order、OrderHistory、Account)的全部数据。该方式提供原始数据,需要在外部进行更多处理和关联,但可避免交互式Report Builder的超时和行数限制。
- 权限:执行提取的用户需要拥有Run Reports、Export Reports,以及查看Order和Account对象全部数据的权限。配置Data Export Service需要System Administrator权限。
- 报告结构:报告应设为Tabular Format,以便导出和处理。避免使用汇总或矩阵格式。
a 示例查询 sql
/*
Salesforce Reports are configured through the user interface. This section describes the configuration of the necessary reports and the logic for post-processing. It is not an executable script.
*/
// ======== REPORT 1: Order Creation Events ========
{
"ReportName": "O2C - Order Created",
"ReportType": "Orders",
"Format": "Tabular",
"Filters": [
{
"Field": "Created Date",
"Operator": "equals",
"Value": "[Specify Date Range, e.g., LAST 90 DAYS]"
}
],
"Columns": [
{"SourceField": "Order Number", "OutputAs": "SalesOrderId"},
{"StaticValue": "Order Created", "OutputAs": "ActivityName"},
{"SourceField": 'Created Date', "OutputAs": "EventTime"},
{"SourceField": "Last Modified By: Full Name", "OutputAs": "UserPerformingAction"},
{"SourceField": "Status", "OutputAs": "OrderStatus"},
{"SourceField": "Total Amount", "OutputAs": "TotalOrderAmount"},
{"SourceField": "Account: Account Name", "OutputAs": "AccountName"},
{"SourceField": "[Your Requested Delivery Date Field]", "OutputAs": "RequestedDeliveryDate"}
]
}
// ======== REPORT 2: Order Field Change Events ========
{
"ReportName": "O2C - Order History Events",
"ReportType": "Orders with History (Custom)",
"Format": "Tabular",
"Filters": [
{
"Field": "Order: Created Date",
"Operator": "equals",
"Value": "[Specify Date Range, e.g., LAST 90 DAYS]"
},
{
"Field": "Field/Event",
"Operator": "in",
"Value": ["Status", "[Credit Check Status Field]", "[Inventory Status Field]", "[Fulfillment Status Field]", "[Shipping Status Field]", "[Delivery Status Field]", "[Invoice Status Field]", "[Payment Status Field]"]
}
],
"Columns": [
{"SourceField": "Order: Order Number", "OutputAs": "SalesOrderId"},
{"SourceField": "Edit Date", "OutputAs": "EventTime"},
{"SourceField": "User", "OutputAs": "UserPerformingAction"},
{"SourceField": "Field/Event", "OutputAs": "SourceFieldForActivity"},
{"SourceField": "New Value", "OutputAs": "SourceValueForActivity"},
{"SourceField": "Order: Total Amount", "OutputAs": "TotalOrderAmount"},
{"SourceField": "Account: Account Name", "OutputAs": "AccountName"}
]
}
// ======== EXTERNAL TRANSFORMATION LOGIC (to be applied after export) ========
/*
- Combine the two exported files.
- For the 'Order History Events' data, create the 'ActivityName' and 'OrderStatus' columns based on the following mapping logic:
CASE
WHEN SourceFieldForActivity = 'Status' AND SourceValueForActivity = 'Submitted' THEN 'Order Submitted for Approval'
WHEN SourceFieldForActivity = 'Status' AND SourceValueForActivity = 'Approved' THEN 'Order Approved'
WHEN SourceFieldForActivity = 'Status' AND SourceValueForActivity = 'Activated' THEN 'Order Activated'
WHEN SourceFieldForActivity = '[Fulfillment Status Field]' AND SourceValueForActivity = 'Sent to Fulfillment' THEN 'Order Sent to Fulfillment'
WHEN SourceFieldForActivity = '[Shipping Status Field]' AND SourceValueForActivity = 'Shipped' THEN 'Goods Shipped'
WHEN SourceFieldForActivity = '[Delivery Status Field]' AND SourceValueForActivity = 'Delivered' THEN 'Goods Delivered'
WHEN SourceFieldForActivity = 'Status' AND SourceValueForActivity = 'Closed' THEN 'Order Closed'
WHEN SourceFieldForActivity = 'Status' AND SourceValueForActivity = 'Cancelled' THEN 'Order Cancelled'
WHEN SourceFieldForActivity = '[Credit Check Status Field]' AND SourceValueForActivity = 'Passed' THEN 'Credit Check Performed'
WHEN SourceFieldForActivity = '[Inventory Status Field]' AND SourceValueForActivity = 'Allocated' THEN 'Inventory Allocated'
WHEN SourceFieldForActivity = '[Invoice Status Field]' AND SourceValueForActivity = 'Created' THEN 'Invoice Created'
WHEN SourceFieldForActivity = '[Invoice Status Field]' AND SourceValueForActivity = 'Sent' THEN 'Invoice Sent to Customer'
WHEN SourceFieldForActivity = '[Payment Status Field]' AND SourceValueForActivity = 'Received' THEN 'Payment Received'
ELSE 'Unknown'
END AS ActivityName
- The OrderStatus attribute should be populated with the 'New Value' when the changed field was 'Status'. For other events, you may need to look up the order's status at that point in time, which is a limitation of this method.
- Add 'SourceSystem' and 'LastDataUpdate' columns to the final combined dataset.
*/ 提升现金流:立即优化订单到收款销售处理
精准定位低效环节,将周期时间缩短30%,加快现金流周转。
无需信用卡•几分钟即可开始