订单到收款:销售订单处理数据模板
订单到收款:销售订单处理数据模板
- 建议收集的属性
- 需要跟踪的关键活动
- Salesforce Sales Cloud数据提取指南
订单到收款:销售订单处理属性
| 名称 | 说明 | ||
|---|---|---|---|
| 事件时间 EventTime | 活动发生的准确日期和时间。 | ||
| 说明 事件时间(即时间戳)记录活动发生的准确时刻。此数据对于正确排列事件顺序和计算活动间隔时长至关重要,也是所有基于时间的流程挖掘分析的基础。 此属性用于排列每个案例中的活动顺序、计算周期时间、识别等待时间,并分析不同时段的流程表现。时间戳不准确或缺失,会严重影响分析的实用性。 重要性 时间戳对于按时间顺序排列事件以及计算周期时间、瓶颈等各项绩效指标至关重要。 获取途径 对应“Order”对象或相关记录中的“CreatedDate”或“LastModifiedDate”等字段。对于特定事件,时间也可能来自“Task”记录的完成日期。 示例 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:00:00Z | |||
| 活动名称 ActivityName | 销售订单生命周期中发生的具体业务事件或任务的名称。 | ||
| 说明 活动名称用于描述销售订单流程中的步骤,例如“订单已创建”“已完成信用检查”或“发票已发送”。这些活动构成流程图的基本要素,来源于系统事件、状态变化或任务完成记录。 分析这些活动有助于呈现流程、识别常见路径(变体),并衡量每个步骤的发生频率和持续时间。这是了解流程实际运行情况的基础。 重要性 此属性定义流程图中的步骤。没有它,您就无法呈现流程,也无法分析销售订单的实际处理方式。 获取途径 通常根据“Order.Status”字段的状态变化、相关记录(例如发票)的创建,或与订单相关的已完成“Task”或“Event”记录生成。 示例 订单已创建订单已批准货物已发出已收到付款 | |||
| 销售订单 SalesOrderId | 每张销售订单的唯一标识符,也是跟踪整个订单到收款流程的主要案例标识。 | ||
| 说明 销售订单ID是流程分析的核心,可唯一标识客户订单在整个生命周期中的流转过程。它将从创建、审批到履约和付款的所有相关活动关联起来。 在流程挖掘中,与特定订单相关的每个事件都会关联到此ID。这样便可端到端还原订单的流转过程,并详细分析每张订单的周期时间、流程差异和瓶颈。 重要性 此属性对于将所有相关事件归入同一案例至关重要,从而可以呈现并分析每张销售订单的端到端流程。 获取途径 这是Salesforce标准“Order”对象中的“Id”字段。 示例 8018d000000XwPBAA08018d000000Y1qCAAS8018d000000Z3kDAB1 | |||
| 数据最近更新时间 LastDataUpdate | 表示数据最近一次提取或刷新的时间戳。 | ||
| 说明 此属性记录最近一次从源系统提取数据的日期和时间,为分析数据的新鲜度提供重要背景信息。 分析人员可据此了解当前查看的数据是否为最新数据,并判断分析结果是否仍然适用。这是任何流程挖掘项目的重要元数据。 重要性 向用户说明数据的时效性,帮助他们了解分析所依据的数据有多新。 获取途径 此时间戳在数据提取、转换和加载(ETL)过程中生成并添加。 示例 2023-11-01T05:00:00Z | |||
| 源系统 SourceSystem | 标识数据提取自哪个系统。 | ||
| 说明 此属性用于标明流程数据的来源。本次分析中的值始终为“Salesforce Sales Cloud”。 在涉及多个系统的环境中,此字段对于追踪数据来源和排查问题至关重要。即使只有一个系统,它也能提供有关数据来源的重要元数据。 重要性 此属性提供数据来源的重要背景信息,有助于数据治理以及整合多个源系统的数据。 获取途径 通常在数据提取过程中添加固定值,用于标记数据集。 示例 Salesforce Sales Cloud | |||
| 客户名称 AccountName | 提交销售订单的客户或公司的名称。 | ||
| 说明 客户名称用于标识与销售订单关联的客户,便于从客户视角分析流程。 分析人员可使用此属性筛选特定客户、比较不同客户群体的流程表现,或识别哪些客户经常遇到流程问题。该属性有助于将流程表现与客户体验直接关联起来。 重要性 将流程表现与具体客户关联,支持按客户分析和细分,以识别规律或问题。 获取途径 “Order”对象包含一个名为“AccountId”的查找字段。需将此ID与“Account”对象关联,才能获取“Account.Name”字段。 示例 Global Tech Inc.Innovate Solutions LLCVenture Dynamics | |||
| 客户要求的交付日期 RequestedDeliveryDate | 客户要求的订单交付日期。 | ||
| 说明 此属性记录客户期望收到货物的日期,是衡量交付表现和客户满意度的重要基准。 “交付日期遵守情况跟踪”仪表板和“按时交付率”KPI会直接使用此日期。系统会将其与实际交付日期(“货物已交付”时间戳)进行比较,以判断订单是按时、提前还是延迟交付。 重要性 这是衡量按时交付表现的主要基准,也是反映客户满意度和运营成效的重要指标。 获取途径 这通常是“Order”对象中的自定义日期字段,具体名称可能有所不同。请查阅Salesforce Sales Cloud文档或架构。 示例 2023-11-152023-12-012024-01-10 | |||
| 总周期时间 CycleTime | 从创建销售订单到最终关闭所经过的总时间。 | ||
| 说明 总周期时间是衡量销售订单端到端处理时长的关键绩效指标,计算方式为第一个事件(例如“订单已创建”)与最后一个事件(例如“订单已关闭”)之间的时间差。 “销售订单端到端周期时间”仪表板重点关注此指标。分析周期时间有助于发现整体流程低效,并衡量改进措施的影响。还可结合国家/地区或产品系列等其他属性细分数据,进一步分析周期时间差异。 重要性 这是衡量整体流程效率、识别可能反映系统性问题的长周期订单的基础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 | 事件发生时销售订单的状态。 | ||
| 说明 此属性记录销售订单的状态,例如“草稿”“已激活”“已发货”或“已关闭”。状态变化通常是生成流程日志中活动的依据。 分析订单状态可以为每个事件提供背景信息,对于跟踪订单进度至关重要。它还有助于了解案例结果,例如区分“已取消”的订单和成功“已关闭”的订单。 重要性 为每个事件提供重要背景信息,通常也是定义活动的依据;对于分析取消等案例结果也至关重要。 获取途径 这是Salesforce标准“Order”对象中的“Status”选项列表字段。 示例 草稿已激活已发货已关闭已取消 | |||
| 事件结束时间 EventEndTime | 活动完成的准确日期和时间。 | ||
| 说明 事件结束时间标记活动完成的时刻。许多流程挖掘工具会根据下一活动的开始时间推断结束时间,但明确记录结束时间可以更准确地计算活动时长,尤其适用于持续时间较长的任务。 此属性用于精确计算活动的处理时间。对于“已完成信用检查”或“库存已分配”等耗时较长的任务,它尤其有用,可帮助区分实际处理时间和空闲等待时间。 重要性 此属性可精确计算各项活动的处理时间,对于识别瓶颈和资源密集型步骤至关重要。 获取途径 对于特定案例,可根据顺序中的下一事件的“StartTime”推导。对于某些活动,也可以使用“Task.CompletedDateTime”等特定字段。 示例 2023-10-26T10:05:12Z2023-10-26T15:00:00Z2023-10-27T11:20:30Z | |||
| 产品系列 ProductFamily | 订单中产品所属的类别或系列。 | ||
| 说明 产品系列为销售订单中的商品提供高层级分类,便于按所售产品类型分析流程。 此属性可用于细分流程,判断不同产品系列是否对应不同的流程路径、更长的周期时间或更高的返工率。例如,复杂的可配置产品可能需要比标准现货产品更繁复的审批和履约流程。 重要性 支持按产品类别细分流程分析,揭示不同类型的产品是否会导致流程效率差异。 获取途径 从“Product2”对象获取。该对象通过“OrderItem”关联对象与“Order”关联,需依次关联Order、OrderItem、PricebookEntry和Product2。 示例 硬件软件许可证专业服务支持合同 | |||
| 信用审核状态 CreditCheckStatus | 订单信用审核的结果。 | ||
| 说明 此属性表示客户信用评估的结果,通常是订单流程中的关键关口。常见值包括“已批准”“已拒绝”或“待处理”。 此属性是“信用审核瓶颈分析”仪表板的重要数据。通过跟踪订单进入和离开信用审核阶段的时间及最终状态,企业可以衡量该环节的耗时和结果,并判断它是否造成延误。 重要性 直接支持信用审核环节分析,帮助衡量其耗时、通过率及对整体周期时间的影响。 获取途径 这可能是“Order”或“Account”对象中的自定义字段。请查阅Salesforce Sales Cloud文档或架构。 示例 已批准已拒绝待审核无需审核 | |||
| 发票ID InvoiceId | 与销售订单关联的发票唯一标识。 | ||
| 说明 发票ID将销售订单与对应的财务发票关联起来。创建并发送发票是订单到收款流程后半段的重要节点。 此属性对于跟踪从订单履约到收款的流程至关重要。它支持准确衡量“发票已创建”和“发票已发送给客户”活动,这些数据是计算“收款周期”的基础。 重要性 将销售订单与开票子流程关联,支持准确跟踪财务活动和付款周期时间。 获取途径 这通常是“Order”对象中的自定义查找字段,指向标准或自定义的“Invoice”对象。具体实现方式可能有所不同。 示例 INV-001234INV-001235INV-001236 | |||
| 收款周期 PaymentCollectionDuration | 从向客户发送发票到收到付款所经过的时间。 | ||
| 说明 此计算指标用于衡量订单到收款周期最后一个关键阶段的效率,即收款效率。它表示“发票已发送给客户”活动与“已收到付款”活动之间的时长。 此属性直接支持“收款周期”仪表板和“回款时间”KPI。分析该时长有助于财务部门发现收款瓶颈、评估付款条款的效果,并寻找加快现金流的机会。 重要性 衡量应收账款流程的效率,直接影响公司的现金流。 获取途径 在数据转换过程中,按每个案例计算“已收到付款”事件与“发票已发送给客户”事件的时间戳之差。 示例 30天15天8小时45天 | |||
| 收货国家/地区 ShippingCountry | 销售订单货物的目的地国家/地区。 | ||
| 说明 此属性指定订单的发货目的地国家/地区,是从地理维度分析订单到收款流程的重要依据。 按收货国家/地区分析,可以发现不同地区的流程表现差异,例如国际订单交付时间较长,或回款周期存在差异。通过细分流程,企业可以了解并解决特定地区面临的问题。 重要性 支持按地理区域细分流程,帮助发现地区间的表现差异、合规问题或物流挑战。 获取途径 这是Salesforce标准“Order”对象中的“ShippingCountry”字段。 示例 USA德国日本巴西 | |||
| 是否按时交付 IsOnTimeDelivery | 用于标记货物是否在客户要求的交付日期当天或之前送达。 | ||
| 说明 此布尔属性直接衡量交付表现是否符合客户预期,计算方式是比较“货物已交付”活动的时间戳与“RequestedDeliveryDate”。 此属性是计算“按时交付率”KPI的核心依据。分析此标记有助于企业了解履约可靠性和承诺达成情况,这些因素对客户满意度影响显著。结合其他属性分析,还可以发现某些运输方式或地区的按时交付率是否较低。 重要性 以明确的二元指标衡量是否履行客户承诺,直接支持按时交付率KPI。 获取途径 在数据转换过程中计算。逻辑为:IF(“Goods Delivered”事件时间≤“RequestedDeliveryDate”)THEN true ELSE false。 示例 truefalse | |||
| 是否自动化 IsAutomated | 用于标记活动由系统流程还是人工用户执行。 | ||
| 说明 此布尔属性用于区分系统自动触发的事件(例如自动更新状态)和用户手动执行的事件,是了解流程自动化程度的重要依据。 分析此属性有助于量化自动化对效率和一致性的影响,并比较自动化与人工处理路径。分析结果还可揭示进一步自动化的机会,以减少人工工作和潜在错误。 重要性 帮助区分系统操作和用户操作,是开展自动化分析、发现减少人工工作的机会的重要依据。 获取途径 在数据转换过程中,根据“UserPerformingAction”是否为指定的系统用户,或依据活动类型规则推导得出。 示例 truefalse | |||
| 是否返工 IsRework | 用于标记销售订单是否发生返工,例如重复执行某项活动或流程出现循环。 | ||
| 说明 此计算属性用于识别未按线性顺序向前推进的案例。当活动重复执行,或流程返回到较早阶段时,就会发生返工,通常是由错误、信息缺失或审批未通过导致的。 此标记用于计算“销售订单返工率”KPI,并支持“销售订单返工与错误率”仪表板。它有助于量化低效情况的频率和影响,并指出需要加强质量控制或明确流程的环节。 重要性 通过标记需要额外计划外工作的订单,量化流程低效情况及其对成本和周期时间的直接影响。 获取途径 由流程挖掘软件计算,或在数据转换过程中通过检测同一案例中的重复活动名称或流程回退来计算。 示例 truefalse | |||
| 订单负责人 OrderOwner | 负责管理销售订单的主要用户。 | ||
| 说明 订单负责人是对订单负主要责任的销售代表或客户经理。与执行某项具体操作的用户不同,订单负责人负责推动整个案例进展。 按负责人分析,有助于评估团队或个人的工作量,以及其订单组合的管理表现。分析结果可以显示哪些负责人经手的订单经常停滞或需要返工,从而发现辅导和支持的机会。 重要性 识别对订单成效负有责任的人员,支持从负责人维度分析工作量和表现。 获取途径 这是“Order”对象中的“OwnerId”字段。可将此ID与“User”对象关联,以获取负责人的姓名。 示例 Jane DoeJohn Smith东区销售团队 | |||
| 运输方式 ShippingMethod | 订单货物的运输方式,例如“标准陆运”“特快”或“国际运输”。 | ||
| 说明 此属性表示订单交付所选的物流服务等级,会直接影响交付时间和成本。 在“运输方式效率分析”中,可用此属性比较不同运输选项的表现,判断特快运输是否达到时效承诺,以及不同运输方式对“货物已发运”至“货物已交付”时长的影响。 重要性 支持分析物流表现,帮助评估不同运输选项的成本和效率。 获取途径 这可能是“Order”对象中的自定义字段,也可能位于关联的自定义“Shipment”对象中。请查阅Salesforce Sales Cloud文档或架构。 示例 标准陆运两日特快次日航空国际优先 | |||
| 销售渠道 SalesChannel | 销售订单的提交渠道,例如“网络”“直销”或“合作伙伴”。 | ||
| 说明 销售渠道属性根据订单来源对订单进行分类,便于比较不同渠道的流程表现。 此属性是“销售渠道表现对比”仪表板的关键数据。按渠道筛选或比较后,企业可以识别哪些渠道效率较高、哪些渠道返工较多,以及哪些环节需要统一标准以改善表现。 重要性 支持比较不同业务渠道的表现,帮助识别最佳实践和流程统一方面的改进空间。 获取途径 这通常是“Order”或“Opportunity”对象中的自定义选项列表字段。请查阅Salesforce Sales Cloud文档或架构。 示例 直销网络门户合作伙伴网络内部销售 | |||
订单到收款:销售订单处理活动
| 活动 | 说明 | ||
|---|---|---|---|
| 发票已创建 | 表示为销售订单生成财务发票。可通过创建关联的“Invoice”对象记录此活动,既可以使用Salesforce Billing原生功能,也可以通过集成实现。 | ||
| 重要性 此里程碑标志着流程进入财务收款阶段。交付到开票之间的时间可以揭示影响现金流的行政瓶颈。 获取途径 根据关联到“Order”对象的“Invoice”对象(标准或自定义)的创建日期推断。 采集 使用关联Invoice记录的“CreatedDate”。 事件类型 inferred | |||
| 已收到付款 | 表示已确认收到客户付款并完成核销。此信息通常通过状态变化从财务系统更新至Salesforce。 | ||
| 重要性 这是销售回款的最后一步。分析从“发票已发送”到此时的时间,对于管理现金流和应收账款周转天数(DSO)至关重要。 获取途径 根据“Invoice”对象的状态变更为“Paid”或“Closed”推断。此更新由与会计或支付处理系统的集成触发。 采集 跟踪外部财务系统集成对“Invoice”对象状态的更改。 事件类型 inferred | |||
| 订单已关闭 | 表示销售订单已在系统中成功完成并最终关闭。可根据订单的最终状态更新推断,表明无需进一步处理。 | ||
| 重要性 这是流程中理想路径的主要结束事件。衡量到此活动的总时长,可得出“订单平均关闭时间”KPI。 获取途径 可根据“Order”对象的“Status”字段变为“已关闭”“已完成”或“已履约”等最终值推断。时间戳可通过字段历史记录获取。 采集 监控“Order”对象的字段历史记录,查看状态是否变为最终完成状态。 事件类型 inferred | |||
| 订单已创建 | 表示系统中创建了销售订单记录。当Salesforce中首次保存新的“Order”对象实例时,系统会明确记录此事件。 | ||
| 重要性 这是订单到收款流程的主要开始事件。分析从此时到后续活动的时间,对于了解整体周期时间至关重要。 获取途径 “Order”对象的创建事件。时间戳取自Order记录中的标准“CreatedDate”字段。 采集 直接取自“Order”对象的“CreatedDate”时间戳。 事件类型 explicit | |||
| 订单已激活 | 这是Salesforce标准事件,表示订单已最终确认,可以进入履约和开票阶段。激活后,订单的大多数内容将被锁定,系统会通过特定的状态变化记录此事件。 | ||
| 重要性 激活是一个关键且不可逆的里程碑,确认订单有效。它标志着销售部门正式将订单交接给运营部门,也是跟踪销售周期时间的重要环节。 获取途径 可根据“Order”对象的标准“Status”字段变为“已激活”推断。时间戳记录在“Order”字段历史记录中。 采集 监控“Order”对象的字段历史记录,查看状态是否变为“已激活”。 事件类型 inferred | |||
| 货物已发出 | 表示订单已从仓库实际发出并运往客户。此事件几乎总是由外部运输或ERP系统更新至Salesforce。 | ||
| 重要性 这是衡量“准时发货率”和整体履约效率的关键里程碑,也标志着客户旅程进入配送阶段。 获取途径 可根据“Order”对象或关联自定义“Shipment”对象中的“Shipped Date”或“Tracking Number”字段填充值推断。数据来自履约系统。 采集 使用首次填入发货日期或跟踪编号字段时的时间戳。 事件类型 inferred | |||
| 货物已送达 | 表示货物已成功送达客户。此信息来自承运商系统,并更新回Salesforce。 | ||
| 重要性 此事件对于计算“准时交付率”KPI和衡量面向客户的实际周期时间至关重要,也确认履约流程已完成。 获取途径 可根据“Order”或自定义“Shipment”对象中的“Delivery Date”字段填充值推断。此数据通常通过与物流服务商的集成提供。 采集 使用填入交付日期字段时的时间戳。 事件类型 inferred | |||
| 发票已发送给客户 | 表示发票已发送给客户以供付款。通常通过发票记录的状态变化来捕获此事件。 | ||
| 重要性 这是“回款时间”KPI的触发事件。从发票创建到发送之间的任何延误,都会直接推迟付款期限的起算时间。 获取途径 根据“Invoice”对象的状态变更为“Sent”或类似值推断。也可以使用已发送电子邮件的活动日志条目。 采集 监控关联“Invoice”对象的“Status”字段,或查找电子邮件日志活动。 事件类型 inferred | |||
| 已完成信用检查 | 表示已完成对订单关联客户的信用评估。通常可根据自定义字段推断此事件,例如“Credit Check Status”更新为“Passed”或“Completed”。 | ||
| 重要性 此活动往往会造成明显延误。衡量其处理时长和等待时间,是解决“信用检查瓶颈分析”仪表板所关注问题、改善现金流的关键。 获取途径 可根据“Order”或关联“Account”对象中自定义字段的时间戳或状态变化推断,例如“Credit_Check_Date__c”或“Credit_Status__c”。 采集 跟踪表示信用检查完成的自定义字段更新。 事件类型 inferred | |||
| 库存已分配 | 表示订单中的产品已在库存系统中预留。此事件通常来自外部ERP或库存系统,并通过字段变化更新到Salesforce。 | ||
| 重要性 此活动对于分析“库存分配提前期”KPI至关重要。此处的延误会直接影响订单能否按时发货。 获取途径 需要分析系统数据。通常可根据“Order”或“OrderItem”对象的状态更新,或由集成流程填充的自定义字段“Allocation_Date__c”推断。 采集 跟踪ERP集成更新的Order或OrderItem对象中的状态或日期字段变化。 事件类型 inferred | |||
| 订单已发送至履约 | 表示已将激活的订单交接给仓库或履约系统,以便拣货和包装。通常由集成流程触发订单状态变化来记录此事件。 | ||
| 重要性 此事件划分了流程中的商务和物流环节。跟踪从激活到此时的时间,有助于区分行政延误和仓库处理延误。 获取途径 可根据“Order”状态变为“已发送至履约”或“等待发货”等值推断。此状态变化通常由ERP/WMS集成触发。 采集 监控“Order”对象的“Status”字段,查找表示已交接至履约环节的特定值。 事件类型 inferred | |||
| 订单已取消 | 表示订单在履约完成前已取消。可通过订单记录的终止状态变化捕获此事件。 | ||
| 重要性 这是一个关键的异常结束事件。分析订单取消的原因和时间,有助于发现销售流程、产品供应或客户信用方面的问题。 获取途径 可根据“Order”对象的“Status”字段变为“已取消”推断。时间戳可在“Status”字段的历史记录中查找。 采集 监控“Order”对象的字段历史记录,查看状态是否变为“已取消”。 事件类型 inferred | |||
| 订单已批准 | 表示所有必要审批方已正式批准销售订单,订单可以进入下一阶段。可通过观察工作流中的最终审批步骤或相应的状态更新来记录此事件。 | ||
| 重要性 这是启动履约流程的关键里程碑。审批延误可能显著拉长订单到收款的整体周期时间。 获取途径 可根据“Order”对象的状态字段变为“已批准”等值推断,也可根据关联“ProcessInstance”记录的完成日期推断。 采集 监控“Order”对象的“Status”字段,或审批流程历史记录的完成情况。 事件类型 inferred | |||
| 订单已提交审批 | 表示草稿订单正式进入审批工作流。通常可根据订单状态变化,或Salesforce审批流程历史记录中新增的记录推断此事件。 | ||
| 重要性 跟踪提交时间有助于衡量订单等待审批的时长和审核流程的效率,并发现审批前的瓶颈。 获取途径 可根据“Order”对象的状态变化推断,例如从“草稿”变为“已提交审批”;也可跟踪与订单关联的“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"。
- 创建主“事件”报表:前往Reports选项卡并点击New Report。选择"Orders with History"报表类型。此报表将记录由字段变更产生的所有活动。
- 配置事件报表列:添加以下列: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的替代字段)。
- 筛选事件报表:将Show Me筛选条件设为All orders,并将Date Field设为Created Date,再选择所需时间范围(例如Last 3 Months)。为Field/Event列添加筛选条件,仅包含与活动对应的特定字段变更(例如Status、Credit_Check_Status__c)。
- 创建“订单已创建”报表:使用标准Orders报表类型创建第二份较简单的报表,仅用于记录订单创建事件。添加Order Number、Created Date、Created By、Status、Total Amount和Account Name列,并按所需时间范围筛选Created Date。
- 导出两份报表:运行两份报表并选择Export。格式请选择Details Only和Comma Delimited .csv。
- 合并并转换数据:使用Microsoft Excel等电子表格程序打开导出的CSV文件,或使用Python等脚本语言处理。
- 对于“事件”报表,新增ActivityName列。使用公式或脚本将字段变更数据映射为所需的活动名称。例如,若Field/Event为'Status'且New Value为'Activated',则将ActivityName设为'Order Activated'。
- 对于“订单已创建”报表,新增ActivityName列,并将所有行的值设为'Order Created'。将列名改为符合事件日志架构的名称(例如,Order Number改为SalesOrderId,Created Date改为EventTime)。
- 合并为单个事件日志:将转换后的“订单已创建”数据行追加到转换后的“事件”数据中,生成包含所有活动的统一列表。
- 完成上传准备:添加其余必需列:SourceSystem(统一填写'Salesforce Sales Cloud')和LastDataUpdate(填写当前时间戳)。保存最终CSV文件前,请检查所有列标题和数据格式。
配置
- 报表类型:必须创建关联Orders和Order History的自定义报表类型,才能将状态变更及其他字段更新作为独立事件记录。
- 字段历史跟踪:此方法依赖Order对象的字段历史跟踪,必须在提取数据前启用。请跟踪Status等关键字段,以及代表流程步骤的自定义字段。
- 日期范围筛选:使用Order对象中的Created Date作为主要筛选条件,确保分析的订单群组一致。建议初次分析选取3至6个月的数据。
- 数据导出服务:对于数据量较大的环境,可安排数据导出服务每周或每月导出指定对象(Order、OrderHistory、Account)的全部数据。导出的原始数据需要更多外部处理和关联,但可避免交互式报表生成器的超时和行数限制。
- 权限:执行数据提取的用户需要具备运行报表、导出报表,以及查看Order和Account对象所有数据的权限。配置数据导出服务需要系统管理员权限。
- 报表结构:为便于导出和处理,请将报表设为表格格式。避免使用汇总或矩阵格式。
查询示例 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%,加快资金回笼。
无需信用卡 • 几分钟即可开始