企业官网建设流程全解析

InvenTree 可追踪部件（Trackable Parts）解析：序列号规则与生产订单中的追踪机制

【免费下载链接】InvenTreeOpen Source Inventory Management System项目地址: https://gitcode.com/GitHub_Trending/in/InvenTree

本篇技术指南围绕 InvenTree 中的“可追踪部件（Trackable Parts）”机制展开：它如何改变库存项在数据库中的处理方式和约束规则，以及序列号（SN）的多种快捷输入语法如何在采购订单、生产订单等流程中落地。读完本文，你将能够正确配置 trackable 部件、使用~、-、+等标记批量生成序列号，并理解 BOM 中含可追踪子部件时生产分配的特殊要求及其源码实现。

什么是可追踪部件：库存处理方式的变化

将某个部件标记为Trackable，会直接改变与之关联的库存项（stock items）在数据库中的处理方式，并且数据库约束层面会施加更多限制。

对数据库中的大多数部件而言，只追踪当前库存数量（以及存放位置）就足够了。但有些部件需要比“知道库存水平”更深入的追踪——例如需要能定位到每一个具体单元。此时应把该部件标记为 trackable。

一般而言，关联到可追踪部件的库存项应当具备**批次号（batch number）或序列号（serial number）**之一。这适用于通过任何渠道创建的库存，包括手动创建，或经由内部流程（如 采购订单 或 生产订单）产生的库存。

需要注意的一个例外：在创建 生产输出 时，这一要求并不被严格强制——详见下文生产订单小节。

源码佐证：trackable 字段与向父级部件的自动传播

从源码结构看，Part模型的字段说明中明确定义了该属性的语义（见 part/models.py）：

• assembly：该部件能否由其他部件装配而来？
• component：该部件能否用于制造其他部件？
• purchaseable：能否从供应商处采购？
• trackable：可追踪部件可以被分配唯一序列号等
• testable：能否对其库存项记录测试结果？
• 以及active、virtual（虚拟部件，如软件产品）、consumable（消耗品，如胶水或紧固件）等标志位。

更值得注意的是ensure_trackable()方法（见 part/models.py）：当一个部件被设为 trackable 时，InvenTree 会沿着 BOM 向上游遍历，把所有“使用它的父级部件”也强制设为 trackable：

def ensure_trackable(self): """Ensure that trackable is set correctly downstream.""" if self.trackable: for part in self.get_used_in(): if not part.trackable: part.trackable = True part.clean() part.save()

其设计动机在clean()的注释中有明确说明（见 part/models.py）：如果某部件是 trackable 的，且被用于某个本身不可追踪的父部件的 BOM 中，则强制把父部件也标记为 trackable。这与文档中“BOM 含可追踪子部件时对构建输出有额外要求”的说明一脉相承——追踪性在装配层级上是自下而上“传染”的。该方法在部件保存时被调用（新建部件时于保存后触发，已存在的部件在clean()中触发），保证数据库中该不变式始终成立。

序列号快捷输入规则

对于标记为 trackable 的部件，其序列号在 InvenTree 的多个流程和表单中以多种形态使用。为了加快录入，InvenTree 支持用以下标记定义想要的序列号（SN）：

这些规则可以自由混搭，各段之间用空格或逗号分隔。例如：

• 1 3-5 9+2或1,3-5,9+2都得到[1, 3, 4, 5, 9, 10, 11]；
• ~+2（下一个可用 SN 为 14）得到[14, 15, 16]；
• ~+（下一个可用 SN 为 14，需要 2 个编号）得到[14, 15]。

使用这类语法的两个实际含义值得注意：

1. ~依赖数据库当前状态——“下一个 SN”由现有序列号计算得出，因此批量补录序列号时无需手工核对当前最大值；
2. +的语义取决于“需要多少个”——4+的长度由目标数量决定，而2+2则显式指定长度。两种写法适合不同场景：前者用于“凑齐所需数量”，后者用于精确控制序列号窗口。

生产订单中的追踪要求

当构建一个 trackable 部件，或者 BOM 中本身就包含 trackable 部件时，生产订单有一些额外要求。

不指定序列号的生产输出

在为可追踪部件 创建生产输出 时，序列号并非创建时刻的必填项。这一设计允许先批量创建一批生产输出，之后再补录序列化——例如在 外部生产订单 收到一批尚未序列化的成品后进行。

如果没有提供序列号，系统会创建一个数量为指定值的单一生产输出，而不是为每个单元各建一个输出。该输出随后可以在完成之前被：

• 分配序列号（语法见上文序列号快捷输入规则）；或
• 拆分为逐个序列化的单元。

含可追踪子部件的 BOM

注意（Tracked BOM Items）：如果被构建部件的 BOM 中包含tracked（可追踪）子部件，那么无论装配出来的部件本身是否 trackable，创建生产输出时仍然需要提供序列号。这是为了确保每个被追踪的子部件都能被精确地分配（allocate）到某一个具体的生产输出上。更多细节参见 生产分配文档。

从源码结构看，这一规则由Build模型中的追踪/非追踪双轨逻辑支撑（见 build/models.py）：

ALL = 'all' # 所有 BOM 项（含追踪与非追踪） TRACKED = 'tracked' # 可追踪的 BOM 项 UNTRACKED = 'untracked' # 不可追踪的 BOM 项

构建流程据此区分处理两类库存：tracked_line_items()与untracked_line_items()分别返回两类 BOM 行的集合（build/models.py）；完成条件检查is_fully_allocated()也只要求untracked部分被完全分配（“Untracked parts must be allocated”），而 tracked 部分则依赖“子部件 → 具体输出”的逐项分配关系，由auto_allocate_tracked_output()等方法完成（build/models.py）。这正是文档中“每个被追踪的子部件必须能分配到一个具体输出”这一约束的底层原因：只有先有具体的（带序列号的）输出，tracked 子部件的分配才有落点。相应地，BuildItemAPI 也提供了tracked布尔过滤器，用于按是否追踪筛选已分配项（见 build/api.py）。

实践要点小结

1. 先判断是否需要 trackable：只需库存水位管理的部件不必开启；需要定位到单个单元（保修、召回、测试记录关联）的部件应开启，并意识到该标记会沿 BOM 向上游传播（ensure_trackable()）。
2. 库存项尽量携带 batch/serial：手动录入、采购收货、生产入库都适用；唯一不强制的环节是创建生产输出，且事后仍应补齐序列化或拆分为单件输出。
3. 善用序列号语法：大批量序列化时优先使用~+与<start>-<end>区间，避免逐条输入；~的“下一可用值”语义可确保与已有序列号不冲突。
4. BOM 含 tracked 子部件时：规划生产输出数量时就要一并规划序列号，因为缺少序列号将阻塞输出创建与后续分配。

【免费下载链接】InvenTreeOpen Source Inventory Management System项目地址: https://gitcode.com/GitHub_Trending/in/InvenTree