UniApp企业办公：把审批、客户和项目装进手机，能做些什么？

UniApp企业办公把审批、客户和项目装进手机能做些什么一张合同等着盖章负责人却不在电脑前。销售刚结束拜访想补一句跟进记录还得等回公司打开后台。项目会上问到计划日期大家开始翻群里的旧截图。这些事都不复杂却很容易卡在“等我回去查一下”。移动办公值得做的是让人离开工位以后仍能接上正在进行的业务。看清单据、查到记录、知道下一步该谁处理比在手机上塞进多少菜单更重要。RuoYi Office 的移动端采用 UniAppVue3围绕审批、客户、项目等业务组织独立页面。下面先看手机上的实际效果再拆开它背后的设计哪些内容适合随身处理哪些规则应该继续由业务系统负责。离开电脑也要看清这张单据手机收到“有一条待办”还不足以让人做决定。用什么章、盖在哪份文件上、由谁保管、之前有没有人审核这些信息必须跟着单据一起出现。图中为独立移动 H5 的完整视口单据 OA103-2026101800011 已审批通过。本文的运行画面来自 H5 浏览器不代表原生 APP 或小程序实机测试。这张页面没有把 PC 表格缩小后塞进手机。上方先交代流程名称、申请人和状态下方按字段展示业务内容。文件标题、印章、使用方式与申请事由处于同一阅读路径读者不用横向拖动才能拼出一条记录。这样的取舍看似只是排版实际影响的是审批质量。一个醒目的“同意”按钮不能替代判断依据关键资料如果藏得太深移动端就容易变成只处理通知、不理解业务的入口。对于用印优先展示文件与用途对于费用申请应优先交代金额和费用构成对于项目立项则要先看计划和范围。审批框架可以共用业务信息的重点不能一律相同。选型时也可以直接拿一张自己的单据来观察不放大页面能否看清关键字段长文本能否正常展开阅读附件入口是否容易找到这些问题比“支持移动审批”四个字具体得多。进度要让人看懂而不是只显示一个状态再看一张仍在流转的用印演示单。这张为另一条历史演示单 OA103-2026101800002当前停留在审批人节点。它与上图不是同一单据不是本次操作前后的对比。“审批中”只能回答事情尚未结束。轨迹进一步回答已经走过谁、现在停在哪、后面还有什么环节。页面把已完成、待处理与后续节点区分开申请人就有了理解进度的依据。回到前面那张已通过的单据向下滚动可以看到实际处理时间和审批意见。与第一张详情图为同一单据展示页面下方的流转记录截图保留完整视口没有截取局部拼装界面。这两种状态体现的是同一类产品设计让人既能看业务也能看处理过程。审批意见挂在具体节点上后续人员可以沿着记录理解决定而不是只得到一个绿色的结果。源码中流程信息、业务表单、审批轨迹和评论被拆成不同区域。业务表单接收流程定义、流程实例、字段权限及可编辑状态轨迹组件负责展示活动节点。这使不同业务可以保留自己的字段而不必各自重新写一套进度页。以下是移动审批页面向业务表单传递上下文的实际代码节选FormDetail refformDetailRef :process-definitionprocessDefinition :process-instanceprocessInstance :fields-permissionformFieldsPermission :editableisFormEditable :todo-tasktodoTask :view-typeprops.viewType /这段代码的价值在于把“当前是什么流程、什么节点、以什么身份查看”带进表单。字段能不能改、操作能不能做需要结合业务与后端校验处理不能靠手机上是否出现按钮来决定。本次只读取了已有单据和轨迹没有重新提交、撤回或执行审批。因此图片证明的是这些记录在当前 H5 中可读完整交付仍需要按角色验证操作结果。客户放进手机重点是保留下一次沟通的上下文审批之外另一个适合移动处理的场景是客户跟进。销售在外面需要的往往不是一张几十列的客户表而是几个连续问题上次谈到哪里有哪些关联商机合同处于什么阶段这次沟通应该记到哪个客户名下移动工作台的实际入口布局。入口数量展示业务组织方式不代表图中所有功能均已逐项实测。RuoYi Office 的客户详情实现采用标签分区基本信息、跟进记录、联系人、商机、合同、回款计划、回款、团队成员和操作日志。读者进入同一个客户切换的是关联信息而不是重新寻找另一份档案。这是从“通讯录”走向业务工具的关键。手机里已有客户电话号码并不等于拥有客户上下文。跟进记录和业务资料能够围绕同一个客户组织外出沟通才有机会接上办公室里的工作。页面底部也按当前标签调整动作基本信息区提供相应维护操作跟进区提供“写跟进”关联模块按照其权限配置显示新增入口。不是把编辑、转移、删除、写跟进等按钮始终堆在屏幕底部。编辑权限的源码判断同时考虑菜单权限与客户团队的读写权限constvalidateWritecomputed(()teamRef.value?.validateWrite??false,)constcanEditcomputed(()hasAccessByCodes([crm:customer:update])validateWrite.value,)这解释了一个常见需求同样能进入客户模块的人对某个客户可能拥有不同操作范围。功能入口与业务归属是两层判断不能只做一个“是否登录”的开关。这里介绍的是已核对的页面与源码设计本次没有写入客户跟进也没有展示含联系方式的客户档案。若用于实际交付还应选择负责人、团队成员等不同身份验证读取与写入边界而不能只用管理员账号演示。项目装进手机不必把整张甘特图也搬进去项目协作的移动入口适合从“查一件事”开始项目是否仍在立项审批计划何时开始当前记录是什么状态移动端项目详情实现已经包含项目类型、优先级、状态、进度、计划日期和附件等信息项目列表点击后的去向则由它是否关联流程实例决定。functionhandleDetail(item:ProjectInfo){if(item.processInstanceId){uni.navigateTo({url:/pages-bpm/processInstance/detail/index?id${item.processInstanceId}viewTypemyfrom${encodeURIComponent(/pages-project/info/index)},})}else{uni.navigateTo({url:/pages-project/info/detail/index?id${item.id}})}}有审批实例的记录进入流程详情没有的进入业务详情。它让“项目资料”与“项目怎么批下来”有了衔接点避免用户看完一条记录后还得自己去流程列表重新搜索。但这里也有不能省略的边界本次核验发现部分历史项目关联的流程已不存在任务页面还存在日期显示问题因此没有把项目移动闭环列为已通过实测的成果。当前可讨论的是页面实现与设计方向正式使用前需要修复并回归对应场景。对项目系统而言手机端的优先级可以是清楚呈现当前事项、补充少量信息、查看处理记录。复杂任务拆分、批量排期、长表格比较则更适合保留在 PC。把每个桌面功能都搬到手机上往往会让简单操作也变得费劲。UniApp复用开发基础业务接口维持同一份事实前面这些页面有一个共同点移动端可以换布局业务对象不应该随之变成另一份。客户就是一个直接例子。PC 端使用自己的请求客户端移动端使用http封装但查询客户详情的接口路径都指向/crm/customer/get?id...。项目详情也能在两端找到/project/info/get的调用。共用业务接口为两端读取同一业务对象提供了基础。它不等于前端组件完全相同更不等于所有字段、权限或消息刷新都已经自动保持一致。接口升级以后两端的数据类型和展示仍需一起检查。可以把二开的工作分成三个层次层次适合复用什么移动端需要额外考虑什么业务对象客户、单据、项目的标识与业务关系入口能否准确回到对应记录业务规则状态校验、授权、审批与业务约束操作前后是否正确刷新与反馈页面交互字段含义与必要信息阅读顺序、触控空间、键盘遮挡与长内容比如PC 可以并排展示业务信息与轨迹手机更适合纵向阅读PC 的关联数据可以铺成多张表手机可以通过标签切换。这些差异值得保留不必为了“一套体验”把两端做成完全一样。还有一个容易忽略的地方审批通过不一定等于现实业务已经完成。用印审批通过后是否已经实际盖章项目立项通过后是否已经开工都需要业务自己的状态与记录说明。移动界面应把两者说清楚不能只用流程上的绿色标记替代业务结果。真正值得带走的是工作不是整套后台如果准备给企业系统增加移动端可以先选一条完整工作链拿到待办读清业务查看历史完成被授权的动作再回到列表确认结果。一次把这条链做好比同时铺开许多只能点进去的页面更有价值。对审批关注判断依据与处理过程对客户关注沟通记录与业务关联对项目关注当前事项与计划信息。这三类工作共同要求的是操作可以短业务上下文不能断。UniApp 提供了组织移动页面的开发基础现有企业平台提供业务对象和服务。两者结合以后手机不需要承担整套桌面后台的复杂度也可以成为认真工作的入口。当人离开电脑后仍然知道这张单是谁的、停在哪一步、接下来该做什么移动办公才有了具体的价值。