全文约1629 字；

阅读时间：约3分钟；

听完时间：约6分钟；

通过昨天的一系列设计，我们创建了一个基于多维表格的收集表单，并设置了三个自动生成的字段：报工日期、员工姓名以及扫码时间，这些字段的设计减少了员工在报工过程中的手动输入，确保了数据的一致性和准确性。对于需要报告具体产品的环节，我们选择了提供下拉选择框的方案，而非使用额外的二维码，因为工厂规模较小且产品种类有限，选择框方案能更高效地完成任务。为进一步优化流程，我们将PMC的生产计划与多维表格关联起来，实现了数据的实时同步，使PMC部门能够集中管理生产计划，而其他部门仅拥有查看权限，确保了数据的安全性和一致性。

完成了PMC部门的MPS生产计划同步后，接下来需要在收集表单中创建与此表的关联。在多维表格中，关联方案有“单向关联”和“双向关联”两种。基于当前的业务模式，我们选择了“单向关联”的方案。这意味着收集表单只能从MPS排程表中选择相关的产品工单信息。

如果采用“双向关联”方案，则会影响到MPS排程表。双向关联的功能是两边数据联动，即如果收集表发生变化，排程表也会随之改变，反之亦然。显然，这种方案在此情境下并不适用。

回到收集表中的收集结果视图界面，继续新增第四个字段：

字段属性：单向关联

来源：排程表中的全部数据

关联方式：手动选择（员工自己选择报工工单号）

关闭允许关联多条记录（确保一次只报一张工单）

效果如下图所示：

设计好单向关联字段后，接下来需要继续设计引用字段以自动带出生产产品信息和产品数量。为此，我们将新增两个字段，其属性为“查找与引用”：

需要引用的字段是“关联：工单号”这个单向关联字段。

对应引用的分别是排程表中的产品名称和数量。效果如下图所示：

为了测试关联与引用是否成功，我们手动选择关联字段中的一条记录，在弹出的对话框中关联一张生产工单号“WK-O1”，确定后，可以发现产品信息和排程数量信息被自动带出，这证明关联成功。至此，自动报工收集单的第一个员工下拉操作设计已完成。

在PC端的收集视图基本模型设计完成后，我们需要设计员工扫码移动端的界面。设计原则是将需要员工操作的字段放在前面，而自动生成的字段（如创建人、创建时间、引用信息等）则选择性地放在后面。

初步方案中，我们只设计两个字段显示在手机扫码界面上：

日期字段：由创建记录时自动填充，用于记录报工日期。

工单号字段：由单向关联字段创建，需要员工选择，并设计为必填字段。在该字段下方提供填写提示：“点击选择工单号，也可向上快速搜索”。

设计完成后，我们通过此视图的分享模式生成二维码并进行手机扫码测试。结果显示，从扫码到完成报工的时间大约控制在5秒内，基本达到了设计目标。

后台PC电脑端的数据已经通过收集表自动收集好了，是一个标准的一维数据表。有了这个一维数据表，接下就是设计公式与仪表盘数据展示的框架模型。

通过昨天的一系列设计，我们成功创建了一个基于多维表格的收集表单，并设置了三个自动生成的字段：报工日期、员工姓名以及扫码时间。这些字段的设计减少了员工在报工过程中的手动输入，确保了数据的一致性和准确性。对于需要报告具体产品的环节，我们选择了提供下拉选择框的方案，而非使用额外的二维码，这在工厂规模较小且产品种类有限的情况下，能更高效地完成任务。

为进一步优化流程，我们将PMC的生产计划与多维表格关联起来，实现了数据的实时同步，使PMC部门能够集中管理生产计划，而其他部门仅拥有查看权限，确保了数据的安全性和一致性。我们还完成了单向关联字段的设计，并通过测试验证了其有效性。

在移动端扫码界面的设计上，我们遵循了将需要员工操作的字段前置的原则，设计了日期字段和工单号字段，并通过测试验证了从扫码到完成报工的时间控制在5秒内，基本达到了设计目标。

至此，PC端的数据已通过收集表自动收集完成，形成了一个标准的一维数据表。下一步，我们将设计公式与仪表盘数据展示的框架模型，进一步提升数据的可视化和分析能力。