您的运输管理数据模板
您的运输管理数据模板
- 全面分析所需的建议属性
- 流程发现需要跟踪的关键活动
- Blue Yonder TMS详细数据提取指南
运输管理属性
| 名称 | 说明 | ||
|---|---|---|---|
| 开始时间 EventTime | 表示特定活动或事件发生时间的时间戳。 | ||
| 说明 事件时间记录货件流程中每项活动发生的准确日期和时间,是事件日志的时间顺序基础,可用于排列活动并计算活动间的持续时间。 在分析中,此时间戳对于计算各类基于时间的KPI至关重要,例如货件端到端周期时间、清关时长和按时交付绩效。它有助于确定延误发生的时间,以及流程各阶段分别耗时多久。 重要性 此时间戳对于排列事件、计算周期时间以及分析流程绩效随时间的变化至关重要。 获取途径 通常可在Blue Yonder TMS交易日志中的状态或事件记录旁找到此字段。每项事件或状态变更都应有对应的时间戳。 示例 2023-04-15T09:00:00Z2023-04-16T14:30:00Z2023-04-25T11:15:00Z | |||
| 活动 ActivityName | 货件在某一时间点发生的具体业务事件或活动名称。 | ||
| 说明 此属性描述运输流程中的单个步骤,例如“货件已计划”“已向承运商发出承运邀约”或“货物已送达”。这些活动构成发现的流程图中的节点,其顺序定义了每个货件的流程。 分析这些活动的顺序和频率是流程挖掘的核心。此类分析有助于识别最常见的流程路径(变体)、发现活动延迟的瓶颈,以及找出“承运邀约被拒绝”等活动重复发生的返工循环。 重要性 此属性定义流程步骤,可用于展示货件运输历程并发现流程效率问题。 获取途径 此属性源自Blue Yonder TMS各模块的事件日志、状态变更记录或交易代码。通常需要将系统事件映射为便于业务理解的活动名称。 示例 货件已计划已向承运商发出承运邀约货物已送达付款已处理 | |||
| 货件 ShipmentId | 单个货件的唯一标识符,也是运输流程的案例ID。 | ||
| 说明 货件ID是关联货物从始发地到目的地运输过程中所有活动和事件的核心标识。每个唯一ID代表一个完整的运输案例,涵盖从初始请求到最终付款的全过程。 在流程挖掘分析中,此属性是还原每个货件端到端运输历程的基础。它可将“货件已计划”“货物已提取”和“货物已送达”等事件归入连贯的流程,从而计算周期时间,并识别单个货件的流程变体。 重要性 这是关联所有相关运输事件的关键案例ID,可用于分析货件的完整生命周期。 获取途径 这是Blue Yonder TMS货件或货载管理模块中的主键。具体表名请参阅系统文档,可能位于货件主表中。 示例 SHP-0012845SHP-0012991SHP-0013054 | |||
| 数据上次更新时间 LastDataUpdate | 此记录的数据上次从源系统刷新或提取时的时间戳。 | ||
| 说明 此属性用于说明数据的新旧程度,记录事件日志上次从Blue Yonder TMS更新的日期和时间。 分析时,此属性有助于了解仪表板和KPI数据的时效性。用户可据此判断查看的是实时信息还是上一时段的数据,从而为运营决策提供重要依据。 重要性 此属性可告知用户数据的更新时间,这对于确保分析结果相关且准确至关重要。 获取途径 这是通常在数据提取(ETL)过程中生成并添加的元数据字段。 示例 2023-05-20T02:00:00Z2023-05-21T02:00:00Z | |||
| 源系统 SourceSystem | 标识数据提取自哪个系统。 | ||
| 说明 此属性指定事件数据的来源,本例中为Blue Yonder TMS。在需要整合多个系统的数据以全面了解流程的环境中,此属性尤其有用。 分析时,可利用此属性筛选数据并了解数据背景。保留此信息有助于追踪数据来源,也是良好的数据治理实践。 重要性 此属性提供重要的数据来源信息,确保数据可追溯,并有助于管理来自多个来源的数据。 获取途径 这通常是在数据提取、转换和加载(ETL)过程中添加的静态值。 示例 Blue Yonder TMSBY_TMS_NABY_TMS_EMEA | |||
| 始发国家/地区 OriginCountry | 货件的始发国家/地区。 | ||
| 说明 此属性指定货件运输的起始国家/地区,根据发货方地址或提货地点详情确定。 在分析中,始发国家/地区是重要的数据细分维度,有助于了解不同地区在流程绩效、承运商运力和周期时间方面的差异。例如,分析国际货件的清关时长时,此属性尤为重要。 重要性 此属性支持按地理区域分析流程绩效,帮助发现区域性瓶颈或效率差异。 获取途径 存储在Blue Yonder TMS货件详情中的始发地信息或发货方地址数据中。 示例 USA德国中国 | |||
| 实际交付时间 ActualDeliveryTime | “货物已送达”事件实际发生时的时间戳。 | ||
| 说明 此属性专门记录最终交付活动对应的时间戳,精确记录货件抵达目的地并确认送达的时刻。 这是衡量绩效的重要数据点。“按时交付率”KPI通过将此时间戳与“RequestedDeliveryDate”进行比较计算。此外,此时间戳也是计算“交付整体吞吐时间”KPI的终点。 重要性 此时间戳对于计算按时交付率和衡量货件总运输时间至关重要。 获取途径 这是“货物已送达”状态更新的时间戳,通常通过承运商发送的EDI消息接收,也可能由用户在Blue Yonder TMS中手动录入。 示例 2023-04-25T11:15:00Z2023-05-11T09:30:00Z | |||
| 承运商名称 CarrierName | 负责运输货件的运输公司或物流服务商名称。 | ||
| 说明 承运商名称用于标识负责运输货物的第三方公司,例如卡车运输公司、航空公司、船运公司或货运代理。 此属性对于绩效分析至关重要,尤其适用于“承运商绩效对比”仪表板。您可以据此筛选和细分数据,比较承运商的按时交付率、提货准时率和平均延误时长等指标,从而优化承运商选择和合作关系管理。 重要性 此属性支持比较和分析不同承运商的绩效,帮助优化承运商选择并提升服务质量。 获取途径 可在Blue Yonder TMS的货件或货载详情中找到,通常关联到承运商主数据表。 示例 Global Shipping Inc.FastLane LogisticsAirExpress Cargo | |||
| 目的地国家/地区 DestinationCountry | 货件送达的国家/地区。 | ||
| 说明 此属性指定货件的最终目的地国家/地区,根据收货方地址或交付地点确定。 与始发国家/地区类似,此属性用于按地理区域细分数据。分析人员可据此比较不同贸易路线(例如美国至加拿大与美国至墨西哥)的绩效,分析特定国家/地区的交付难点,并评估跨境复杂性对周期时间的影响。 重要性 此属性支持按目的地分析绩效,对于了解贸易路线的复杂性和区域交付难点至关重要。 获取途径 存储在Blue Yonder TMS货件详情中的目的地信息或收货方地址数据中。 示例 加拿大墨西哥英国 | |||
| 要求交付日期 RequestedDeliveryDate | 客户要求或销售订单规定的交付日期。 | ||
| 说明 此属性记录物流流程需要达到的目标交付日期,代表客户期望或货件适用的内部服务级别协议(SLA)。 此日期是计算“按时交付率”KPI的基准。通过比较“ActualDeliveryTime”和“RequestedDeliveryDate”,分析可判断货件是提前、按时还是延迟送达。这也是“按时提货与交付绩效”仪表板的基础。 重要性 此属性是衡量按时交付绩效和客户满意度的主要基准。 获取途径 此信息通常来自ERP或订单管理系统等上游系统,并存储在Blue Yonder TMS的货件请求详情中。 示例 2023-04-25T23:59:59Z2023-05-10T17:00:00Z | |||
| 货件状态 ShipmentStatus | 货件当前或最近一次已知的状态。 | ||
| 说明 货件状态表示货件生命周期中的当前状态,例如“已计划”“运输途中”“已送达”或“已取消”,可概览货件在流程中的进度。 在流程挖掘中,分析案例的最终状态有助于了解流程结果。例如,比较“已送达”与“已取消”货件的流程,可以发现导致不理想结果的模式。筛选尚未完成的货件,还可用于监控当前工作量。 重要性 此属性可快速概览货件当前状态,并区分已完成、进行中和已取消的货件。 获取途径 这是Blue Yonder TMS货件主表或主要状态跟踪表中的关键字段。 示例 已计划运输途中已送达已取消 | |||
| 运输方式 ModeOfTransport | 货件采用的运输方式,例如公路、航空、海运或铁路。 | ||
| 说明 此属性指定运输方式。常见值包括零担运输(LTL)、整车运输(FTL)、空运、海运和铁路运输。 在流程分析中,运输方式是重要的筛选和对比维度。不同运输方式的流程、周期时间和成本可能存在显著差异。例如,“清关瓶颈分析”与空运和海运货件密切相关,但对国内公路运输货件的参考价值较低。按运输方式分析绩效,有助于根据具体物流场景制定改进措施。 重要性 不同运输方式的流程、成本和典型周期时间各不相同,因此此属性可支持分组分析。 获取途径 这是Blue Yonder TMS货件计划和费率计算模块中的标准字段。 示例 LTLFTL空运海运 | |||
| 实际提货时间 ActualPickupTime | “货物已提取”事件实际发生时的时间戳。 | ||
| 说明 此属性记录承运商从始发地实际提取货件的准确时间,标志着货件正式进入在途阶段。 此数据点对于衡量承运商绩效至关重要。将其与“ScheduledPickupTime”进行比较,可计算“按时提货率”和“平均提货延误时长”KPI。分析偏差有助于发现特定承运商或提货地点的问题。 重要性 此时间戳用于准确衡量提货绩效,并发现运输流程初期的延误。 获取途径 这是“货物已提取”状态更新的时间戳,通常由承运商通过EDI发送,或由用户在Blue Yonder TMS中手动录入。 示例 2023-04-16T14:30:00Z2023-05-02T10:15:00Z | |||
| 延误原因 DelayReason | 说明提货或交付延误原因的代码或文本。 | ||
| 说明 此属性记录货件未能按时达到里程碑的原因,例如“天气延误”“海关扣留”或“承运商运力不足”。此信息通常由承运商提供。 此属性对于“按时提货与交付绩效”仪表板至关重要。它不仅能显示货件延误,还能说明延误原因。分析最常见的延误原因,有助于物流团队主动降低风险,并与承运商合作解决反复出现的问题。 重要性 此属性说明延误的根本原因,有助于主动管理风险并与承运商合作开展有针对性的改进。 获取途径 此数据通常记录在Blue Yonder TMS的事件或异常管理部分,且经常由承运商EDI更新填充,例如EDI 214。 示例 天气海关扣留司机延误设施拥堵 | |||
| 是否按时交付 IsOnTimeDelivery | 用于标记货件是否在要求的交付日期当天或之前送达的计算字段。 | ||
| 说明 此布尔属性通过比较“ActualDeliveryTime”和“RequestedDeliveryDate”得出。实际交付时间不晚于要求的交付日期时,值为true;否则为false。 作为计算指标,它简化了“按时交付率”KPI的分析与可视化。您可以轻松筛选和汇总数据,创建仪表板,按时间、承运商或运输方式查看按时交付率,直接支持“按时提货与交付绩效”仪表板。 重要性 此属性可简化按时绩效分析,便于在仪表板和KPI中快速筛选与汇总数据。 获取途径 此属性不在源系统中,而是在数据转换过程中按以下公式计算:ActualDeliveryTime <= RequestedDeliveryDate。 示例 truefalse | |||
| 用户 User | 执行该活动的人员的用户ID或姓名。 | ||
| 说明 此属性用于标识在TMS中负责执行特定事件或状态变更的物流计划员、协调员或系统用户。对于自动化事件,此属性可能是系统或服务账户ID。 按用户分析有助于了解工作量分配、个人绩效和培训需求。分析可发现某些用户是否更常遇到返工或延误,也可比较不同团队的效率,为资源管理和有针对性的流程改进提供依据。 重要性 此属性支持按用户或团队分析绩效和工作量,帮助发现培训机会和资源限制。 获取途径 此信息应可在交易日志或事件日志中找到,通常以“Changed By”或“User ID”字段的形式与每条记录关联。 示例 j.doea.smithTMS_AUTOMATION_USER | |||
| 计划提货时间 ScheduledPickupTime | 计划由承运商从始发地提取货物的日期和时间。 | ||
| 说明 此属性记录与承运商约定的货件提取预约时间,是货件计划中的重要里程碑。 此时间戳是计算“按时提货率”和“平均提货延误时长”KPI的基准。将其与“ActualPickupTime”进行比较,有助于发现货件运输初期的延误,而这类延误往往会影响后续里程碑。 重要性 此属性是衡量按时提货绩效的基准,也是评估承运商可靠性和计划准确性的重要指标。 获取途径 位于Blue Yonder TMS的预约安排或货载计划模块中。 示例 2023-04-16T14:00:00Z2023-05-02T10:00:00Z | |||
| 运费账单差异 FreightBillDiscrepancyReason | 说明运费账单未通过审核原因的代码或描述。 | ||
| 说明 运费账单审核发现差异时,此属性用于说明原因,例如“费率错误”“重复发票”或“缺少交付证明”。 此属性是“交付证明与账单准确性”仪表板和“运费账单返工率”KPI的关键数据。分析各类差异原因的出现频率,有助于找出账单错误的根本原因,包括承运商操作失误、合同不一致或内部流程问题,从而采取有针对性的措施,减少发票返工。 重要性 此属性揭示账单错误的根本原因,有助于采取有针对性的改进措施,减少运费账单返工和付款延误。 获取途径 位于Blue Yonder TMS的运费审核和付款模块中,与异常或拒绝日志相关联。 示例 费率应用错误重复发票附加费用争议 | |||
运输管理活动
| 活动 | 说明 | ||
|---|---|---|---|
| 付款已处理 | 这是货件生命周期中的最后一项活动,表示承运商已收到运输服务款项。此事件通常来自外部财务系统(ERP),随后更新回TMS。 | ||
| 重要性 此活动标志着货件财务流程结束。分析从送达或审核到付款的周期时间,有助于管理营运资金并维护良好的承运商关系。 获取途径 应付账款系统或ERP发送的接口消息更新TMS中运费账单的付款状态时,通常会记录此显式事件。 采集 使用财务系统发送的付款确认消息中的时间。 事件类型 explicit | |||
| 已完成清关 | 对于国际货件,此活动表示货物已在边境或港口顺利通过海关。收到报关行或承运商的通知后,系统会触发此事件。 | ||
| 重要性 海关是国际物流中常见的重大延误来源。衡量清关所需时间,对于发现瓶颈和缩短跨境运输时间至关重要。 获取途径 通常根据承运商消息(例如EDI 214)或手动更新记录此显式事件,并将货件的海关状态改为“已清关”。 采集 记录货件的海关状态更新为“已清关”时的时间。 事件类型 explicit | |||
| 已收到货运请求 | 此活动表示在Blue Yonder TMS中创建运输需求,通常由ERP等上游系统传入订单后触发。这标志着货件生命周期正式开始:系统创建新的货件记录,并将初始状态设为“未计划”或“新建”。 | ||
| 重要性 这是端到端运输流程的主要开始事件。分析此事件到后续计划活动之间的时间,有助于发现初始处理延迟并衡量整体吞吐量。 获取途径 通常可根据核心货件表或订单表中货件记录的创建时间推断此事件。也可以将处理ERP接口消息时记录的显式事件作为依据。 采集 使用货件记录的创建时间。 事件类型 inferred | |||
| 货件已订舱 | 此里程碑表示承运商已接受承运邀约,并承诺负责运输。货件状态会更新为“已订舱”或“已承运”,从而确定承运商和运输费率。 | ||
| 重要性 这是完成计划阶段并进入运输执行阶段的关键里程碑。衡量到达此节点的周期时间,有助于评估订舱效率和响应速度。 获取途径 收到并处理承运商的接受响应(例如EDI 990)后,TMS会明确更新货件记录的状态,并记录此事件。 采集 记录状态变为“已订舱”或“已承运”时的时间。 事件类型 explicit | |||
| 货物已提取 | 此活动标志着货件运输的实际开始,即承运商从始发地接收货物。Blue Yonder TMS通常根据承运商发送的状态更新消息记录此事件,例如EDI 214交易。 | ||
| 重要性 这是确认货件已开始运输的关键执行里程碑,可作为计算在途时间以及衡量是否按计划提货的基准。 获取途径 此显式事件根据承运商的状态更新记录。系统处理提货确认消息时会记录时间,例如状态为“AF”或“X3”的EDI 214消息。 采集 使用已处理的EDI 214消息或其他承运商提货确认消息中的时间。 事件类型 explicit | |||
| 货物已送达 | 此里程碑表示货件已实际抵达收货方所在地。承运商通常通过EDI 214消息确认送达,并据此更新TMS中的货件状态。 | ||
| 重要性 这是标志实际运输结束的关键成功里程碑,也是衡量按时交付绩效的依据。按时交付绩效是客户满意度和承运商可靠性的重要指标。 获取途径 此显式事件根据承运商的送达确认消息记录。TMS处理状态为“D1”的EDI 214消息或同等消息时,会记录相应时间。 采集 使用已处理的承运商送达确认消息中的时间。 事件类型 explicit | |||
| 已向承运商发出承运邀约 | 当系统正式向特定承运商发出货件承运邀约时,会发生此活动。这是TMS中的独立操作,通常会通过EDI 204交易、电子邮件或门户通知联系承运商。 | ||
| 重要性 此事件是衡量承运商响应速度和承运邀约接受率的起点。分析发出邀约到承运商响应之间的时间,是了解承运商合作效率的关键。 获取途径 用户或系统执行承运邀约操作时,Blue Yonder TMS通常会在货件历史记录表或承运邀约历史记录表中记录此显式事件。 采集 执行承运邀约操作时,系统会将其记录在货件事件历史记录中。 事件类型 explicit | |||
| 已收到交付证明 | 此活动表示已收到确认交付的正式文件,例如已签署的提单。这通常是实际送达后的独立步骤,也是支付运费的前提。 | ||
| 重要性 及时收到交付证明(POD)对于加快开票和付款周期至关重要。此步骤延误会直接影响现金流,也可能引发承运商付款争议。 获取途径 用户手动标记已收到POD,或将文件附加到TMS中的货件记录时,通常会触发状态变更并记录此事件。 采集 记录货件上的“已收到POD”标记或状态设置时间。 事件类型 inferred | |||
| 已收到在途更新 | 表示货件在运输途中收到承运商发送的位置或状态更新。这些更新通常来自EDI 214消息,可用于了解货件进度和潜在延误。 | ||
| 重要性 这些事件对于跟踪货件进度和发现运输途中延误至关重要。缺少更新可能意味着可视性不足,而频繁收到延误更新则可能反映承运商绩效问题。 获取途径 每次收到并处理承运商的在途消息(例如状态为“X1”或“AG”的EDI 214消息)时,系统都会在货件跟踪表或事件历史记录表中记录显式事件。 采集 每处理一条承运商在途消息,事件日志中都会新增一条记录。 事件类型 explicit | |||
| 承运邀约被拒绝 | 此事件表示承运商拒绝承运该货件。通常通过EDI 990交易以电子方式收到拒绝信息,也可能由用户在承运商门户中手动更新,随后触发寻找替代承运商的工作流。 | ||
| 重要性 跟踪承运邀约被拒情况对于发现承运商选择中的返工循环至关重要。拒绝率偏高可能意味着定价、承运商运力或货载信息准确性存在问题,进而导致延误和成本增加。 获取途径 TMS处理承运商的拒绝响应并更新货件的承运邀约状态时,通常会记录此显式事件。 采集 收到承运商拒绝消息(例如EDI 990)时,系统会将其记录为事件。 事件类型 explicit | |||
| 货件已取消 | 表示货件在提货前终止。客户取消订单或计划变更等原因都可能导致货件取消;这是流程未成功完成的最终状态。 | ||
| 重要性 跟踪取消情况有助于了解需求波动和流程浪费。分析货件取消原因,可以发现订单管理或计划流程中的问题。 获取途径 用户或自动化流程将货件的主要状态改为“已取消”时,系统会记录此显式事件。 采集 记录状态变为“已取消”时的时间。 事件类型 explicit | |||
| 货件已计划 | 表示初始计划阶段已完成,期间系统为货件确定路线、运输方式和潜在承运商。计划引擎生成方案后,系统会更新货件状态,表明计划已就绪。 | ||
| 重要性 跟踪此活动有助于衡量计划与优化引擎的效率。此步骤出现延迟或返工循环,可能意味着主数据、承运商运力或系统配置存在问题。 获取途径 通常可根据货件实体的状态变化推断此事件,例如从“未计划”变为“已计划”。状态变更的时间即为事件时间。 采集 记录货件状态变为“已计划”时的时间。 事件类型 inferred | |||
| 运费账单已审核 | 承运商发票(即运费账单)已通过系统或人工审核,并与合同费率、附加费用及交付证明进行核对。此步骤用于在批准付款前核实费用。 | ||
| 重要性 这是重要的财务控制节点。分析审核流程有助于发现频繁出现的账单差异;此阶段的返工则可能表明存在增加管理负担的问题。 获取途径 与货件关联的运费账单在TMS运费审核模块中变更为“已审核”“已批准付款”或类似状态时,系统会记录此事件。 采集 记录与货件关联的运费账单实体发生状态变更时的时间。 事件类型 inferred | |||
数据提取指南
此流程的提取方法目前正在验证中。请稍后再查看,或 联系我们 获取帮助。
立即提升运输管理效率
找出低效环节、跟踪绩效,并将周期时间缩短30%。
无需信用卡,几分钟即可激活。