场景痛点：领用这件小事，为什么总在月底对不上
办公用品领用的典型现场是这样的：员工在微信里@行政"打印纸没了"，或者走到前台口头说一句"再拿两支笔"；行政在纸上画一道，或者干脆不记。到了月底，仓库里剩下多少卷纸、这个月打印纸到底用了多少、哪个部门用得快——没人说得清。
事情不大，但它有三个持续的小成本：
- 重复申领与囤积：不知道别人领没领，员工习惯一次多拿，抽屉里堆着三盒笔芯。
- 审批靠人情：金额小的时候不好意思走流程，金额大的时候又没有依据，标准全在行政一个人的判断里。
- 对账靠回忆：采购进货和发放出库两条线各记各的，账实差异只能靠盘点发现。
这套方案要解决的，不是"把领用管严"，而是把领用变成一条看得见的流水：谁在什么时候申请了什么、批没批、发没发、还剩多少，随时能查。用品本身的单价通常很低，把管理成本压到"手机30秒填完一张单"的水平，流程才有人愿意用。
建什么样的数据：四张表把"东西"和"人"管起来
在这个场景里，AI 构建器要生成的其实是一套很小的主数据结构。可以按下面四块来跟构建器描述需求。
第一张：用品目录（主数据）
这是所有动作的起点。每一条大约包含这些字段：
- 用品编码、用品名称
- 用品分类（办公文具、纸张耗材、清洁用品、劳保用品、茶水间用料……）
- 规格型号、计量单位（本、盒、包、卷、瓶）
- 默认单价、供应商
- 安全库存（低于这个数就该提醒补货）
- 状态（在用 / 停用）
分类、单位这类需要统一口径的下拉选项，交给平台的数据字典管理，不要在每个表单里各写一套，否则"盒"和"箱子"会同时出现在报表里。做法见 数据字典：管好下拉选项的统一口径。
目录数据的初始化不用手工敲。如果行政手上已经有一份 Excel 台账，用 用 Excel 一步建模块 的路子直接导入，改完再导入一次即可。
第二张：领用申请单（主表）
一张申请单对应一次领用行为，核心字段：
- 单号（自动生成）、申请人、所属部门、申请日期
- 用途说明（可填可不填）
- 申请状态（草稿 / 待审批 / 已通过 / 已驳回 / 已发放 / 已撤回）
- 合计金额（由明细汇总）
第三张：领用申请明细（子表）
一张申请单可以带多条明细，每条明细一行：
- 关联的用品（从用品目录里选，而不是手打文字）
- 申请数量、发放数量
- 单价、小计
把明细做成子表而不是在主表里塞一个"用品名称"文本框，这一步很关键——后面要按用品汇总用量、按部门统计消耗，都依赖明细这一层。申请表与明细表的联动写法，可以参考 审批流落地：请假、报销与通用申请怎么在线化 里"一单多行"的组织方式。
第四张：库存与出入库流水
库存不要只留一个"剩余数量"字段。正确做法是留流水：每一次采购入库、每一次发放出库、每一次盘盈盘亏，都写一条记录，当前库存由流水累加得出。这样月底发现账实不符时，能沿着流水倒查是哪一笔对不上，而不是只看到一个错误的数字。这套出入库流水的通用做法，与 通用库存管理：入库、出库与盘点的一本账 是同一套逻辑，只是把物料换成了办公用品。
页面怎么用：从申领到发放的四步
数据建好之后，行政每天真正打交道的是页面。按业务动作切分，只需要四张页面。
第一步：员工提交申请
员工打开"用品领用申请"页面，新建一张单：选用品（下拉直接搜目录）、填数量、写用途、提交。系统自动带上申请人和部门，员工不用自己填。
这里有个体验细节值得在需求里说清楚：领用明细的"可选用品"要带出当前库存余量。员工看到"打印纸 还剩 3 包"，就不会一次申请 5 包然后等三天。余量的展示可以通过页面数据源从库存表取值，不需要人工维护。
第二步：审批人在待办里处理
申请提交后进入审批环节，审批人的工作台上出现待办。审批页面上要能看到的关键信息是：谁申请、什么部门、要什么、要多少、当前库存多少。审批动作就是通过或驳回，驳回时填一句理由。
审批路径怎么走，由平台的工作流定义，可以在可视化编辑器里拖节点，不需要写代码。常见的三种配法：
- 按金额分流：小额（比如几支笔）由直属主管直接批；超过一定金额再加一级行政经理。
- 按品类分流：常规耗材走快速通道；单价较高的设备类物品（比如显示器、碎纸机）单独走一条更严格的分支。
- 按部门分流：谁的部门预算谁批，行政只做发放执行。
工作流的节点、条件与分支写法，见 工作流可视化编辑器：节点详解与操作手册；如果你只想先跑通最简的"申请-审批-归档"三步，审批流落地 那篇里的最小配置可以直接照搬。
第三步：行政发放并登记
审批通过后，申请单流转到"待发放"。行政在发放页面上核对实物，填发放数量（允许部分发放，比如申请 5 包只发 3 包），确认发放。这一步同时生成一条出库流水，扣减库存。
第四步：查台账与统计
月底要看两件事：
- 按部门看消耗：哪个部门这个月领了多少、折多少钱，用于费用分摊或预算复核。
- 按用品看消耗：哪几样东西用得最快，为下一次采购提供依据。
这两张表都可以用平台的统计页面搭出来，或者挂到管理仪表盘上，让行政打开首页就能看到本月领用金额和库存预警数。待发放清单和低库存清单是最值得放在首页的两个小卡片——前者提醒行政别漏发，后者提醒该补货了。
移动端怎么配合：员工在工位上就申领
办公用品领用是典型的"移动端决定使用率"的场景。员工不会为了领一支笔走到电脑前登录系统，但会顺手在手机上填一下。
平台的做法是：PC 上构建的模块会自动适配到移动端，员工在同一套权限和同一份数据上操作，不是另做一个 App。移动端在这个场景里承担三件事：
- 提交申请：手机上选用品、填数量、提交，三十秒完成。
- 审批待办：主管在手机上直接批，不用回工位。审批这类需要随时响应的动作，放在移动端最有效。
- 拍照留痕：员工垫付采购后拍发票上传，行政发错东西时拍照说明，附件跟着单据走。上传的图片由平台的文件能力存储，不占用业务表本身。
移动端的入口、工作台与模块页的组织方式，见 移动端使用指南：工作台、模块页与手机上的 AI 构建。
库存联动与预警：什么时候自动扣减，什么时候提醒补货
扣减时机：库存扣减应该发生在"发放确认"这一步，而不是"申请提交"或"审批通过"这一步。原因很实际——审批通过的申请有可能被撤回，也有可能部分发放；如果审批一通过就扣库存，账上数字会先虚减，月底盘点时对不上。
想把"发放确认"这个动作和"生成出库流水、扣减库存"接起来，可以用平台的数据流规则：满足条件（发放状态变为已发放）时自动执行一段数据变换。它的定位是条件触发的数据变换，不是万能的自动化脚本，但覆盖"审批/状态变化后更新另一张表"这类联动是够用的。
补货提醒：把用品目录里的"安全库存"字段和定时任务配合起来——每天定点扫描一次库存，凡低于安全库存的用品，向行政推一条提醒（站内信或企业微信/钉钉类的消息通道，取决于当前接入的渠道）。定时任务的配置方式见 工作流与定时任务：让重复性工作自动跑。
异常提醒：如果同一个部门本月领用金额明显超出往常，或者同一个人短期内重复申领同一用品，可以设一条提醒规则推给行政。这类"异常看板"不做强管控，只是让行政提前知道。具体阈值由企业自己定，不要在系统里写死。
盘点：每季度或半年做一次盘点，把系统库存和实物对一遍，差异记成盘盈盘亏流水，调整后库存回到正确值。办公用品的盘点不需要像设备那样严肃，但留一条差异记录比"改个数字了事"更有价值，它能暴露是哪几个月累计的误差。
上线前查什么
系统搭完，别急着全员推广。按下面的清单自查一遍，能挡掉大部分上线后的尴尬。
1. 用品目录是否干净
- 分类下拉是否统一（有无"文具"和"办公文具"两个分类并存）
- 计量单位是否口径一致（"盒"和"箱"的比例关系是否清楚）
- 停用品是否标记为停用，而不是直接删除（历史单据还在引用它）
2. 审批路径是否覆盖所有分支
- 小额、大额、常规耗材、贵重物品，四种情况各提交一单试试，看是否走到预期的审批人
- 没有审批人的情况怎么处理（申请人直接主管离职了，单子会不会卡住）
- 撤回与驳回后单据停在哪一步，能不能重新提交
3. 库存数字是否能对上
- 手工建一条期初库存或导入一张盘点表，做一次完整的"申请-审批-发放"，检查库存是否只扣了一次
- 部分发放时，库存扣的是发放数量而不是申请数量
- 驳回或撤回的单据，不会产生任何库存变动
4. 权限是否分层
- 普通员工只能看到自己的申请单，看不到别人的
- 行政能看全部单据和库存，但看不到无关的财务数据
- 审批人只能批到自己权限范围内的单子
角色的划分与自定义授权方式，见 角色与权限配置：从内置角色到自定义授权。权限这块最容易图省事——先按角色分好，再谈推广，否则上线第一周就会有人看到不该看的单子。
5. 发布前跑一遍预检
模块挂载菜单、移动端同步、页面预检的执行流程，见 模块的测试与发布：预检、挂载菜单与移动端同步。建议先在行政部内部小范围试用两周，把审批路径和目录数据磨顺了，再开给全员。
之后怎么延伸
办公用品领用是一块很轻的模块，但它的结构（目录 + 申请 + 审批 + 出入库流水）是可以复用的。跑顺之后，同样一套骨架能接着覆盖几件相邻的事：
- 固定资产领用：把"用品目录"换成资产台账，加一个"归还"动作，就能管显示器、笔记本这类需要跟踪去向的物品。参考 固定资产台账与盘点：谁在用、在哪、还值多少。
- 劳保用品发放：和岗位绑定，规定哪些岗位按周期发放哪几样，到期自动生成待发放清单，不让安全用品靠人记。
- 采购与领用打通：领用的消耗趋势直接作为采购申请的依据，用 采购管理：请购、订单、入库、对账一条线 里的请购单接上，行政不用凭印象下单。
- 费用分摊：把按部门汇总的领用金额导出给财务，作为部门费用的一个来源，口径统一之后再也不用对表。
这类模块的搭建顺序建议是：先把目录和申请跑通，再加审批分支，最后接库存与提醒。一次全上，反而容易在上线阶段被数据问题拖住节奏。