载荷总重量里为何还有容器：D365文档怎样界定计算对象

一份运输软件记录写着load的总重量，读者容易把它理解成订单货品重量的合计。微软的《Include container weight and volume on load》却明确把容器也纳入计算对象。这篇Dynamics 365 Supply Chain Management文档所解释的，是软件里的载荷记录如何呈现组成，而非现场车辆已经完成的称重或配载。

先看记录怎样相连。一个load可以包含一个或多个shipment，这些装运中的货品又可以属于一个或多个销售订单。货品可以放在容器内，容器随后归入load；同时，没有放在容器内的货品也可以成为load的一部分。容器内货品与容器外货品并存，意味着不能把load简单理解成只装着若干相同箱子的清单。

在这个对象范围下，系统计算重量和体积时考虑容器与货品两者。容器不是订单货品的另一个名字，它自身也参与所述总量。货品放进容器，改变的是它在软件关系中的归属；并不使容器本身的记录消失。阅读一条汇总值时，需要连着这段组成说明，才知道总量概括了哪些对象。

文档随后把这些值联系到运输管理页面。它说，Rate route workbench等位置会使用载荷重量和体积；创建load时，还可以看到它相对于所选load template的容量使用情况。Load template assignment对话框分别有Details、Weight和Volume页签，依次显示总数量、总重量和总体积。三种汇总在同一个窗口里，但不因并列显示就具有相同单位或含义。

Weight与Volume还分别与模板中定义的最大重量、最大体积比较。原文说，超过任意一个软件上限时系统会发出通知。因此，一项未超出的记录，并不能替另一项作答；重量与体积是两次不同的比较。这里的“最大”带着所选模板这一明确背景，本篇没有把它改写成某辆真实车辆或某批货物的安全结论。

容器数量的考虑也并非只看一个箱数。微软将重量、体积和容器使用百分比列为相关依据，并说明所用重量、体积单位来自具体legal entity配置的系统单位。这给资料转述留下两项必要背景：原页面采用了什么对象范围，以及数字采用什么单位。没有这些背景，只抄一个总数，读者仍难以判断它代表哪一层汇总。

该页标示2025年6月17日更新，首次发表时间未确认。本文采用对象关系、页签含义和比较口径，不转写配置路径，也未在真实系统创建或调整载荷。它为运输软件资料提供的具体认识是：货品总量、容器与货品共同形成的载荷总量，以及模板上限，分别处在不同的位置。