财务报销示例方案
本方案沿用快速开始的顺序:先建工作台与数据基座,再装配报销助理,最后验证两种入口共享同一业务记录。 它是需按企业制度配置和验证的示例,不代表已部署的财务系统。
员工在工作台查看自己的报销单、补充材料和跟踪状态,也可以在与报销助理的对话中上传发票并说明用途。助理将信息整理为待确认的草稿,财务或审批人继续在获授权的流程中复核。
先确认业务范围
第一版可以只做报销草稿整理和人工复核,不接银行付款、自动记账或自动审批。开始前准备企业费用分类、必填字段、凭证要求、审批角色和可用于测试的发票样例。
发票识别只是提取资料,不等同于税务查验、真伪认证、审批通过或实际付款。需要这些能力时应另行确认接口、权限、业务规则和验收范围。
用 WorkBuddy 或 Codex 构建应用
先完成AI 工具连接,加载官方 workbench-app-development Skill。向开发助手说明目标 Team 和业务流程:
确认结构和操作范围后,再让助手按 Skill 实施。业务数据选择 arcubase;若需读取成员、对话或文件等平台资源,再按实际功能选择 octopus。审批待办确实需要项目和任务时再选 taskboard,不能把任务状态直接当作完整财务审批制度。
建议的数据结构
字段、关系和状态由企业确认后实现。例如可设计“草稿 → 待复核 → 退回补充 / 已复核”,但这不是平台预置的报销状态机。复用已有财务数据应用时,以既有结构和规则为准。
应用用户、报销助理、财务和审批人的权限分别配置。普通员工不能读取他人报销,助理不因有录入权限就拥有批准或付款权限。附件本身也必须按业务范围控制访问。
工作台先通过本地验收
让 AI 实施真实列表、详情、草稿编辑和当前范围内的复核操作,使用生成的 Arcubase 强类型客户端。按脚手架开发登录流程进入本地应用,检查真实记录或真实空状态。
经授权使用测试记录验证新增、修改、附件打开、状态流转和错误反馈;保存后回读实际数据。记录 App ID、表标识、字段 key、状态、关系与权限,下一步交给助理复用。先在本地验证,不以页面完成为由提前发布。
配置报销助理
可以让开发助手先准备岗位、Skill 和授权方案,再由已支持的 CLI 配置能力或管理员 Portal 完成装配:
发票为图片时,确认员工启用并获准使用图像识别;PDF、扫描件或其他附件,应按当前环境实际支持的读取能力单独验证。文件上传成功并不代表已能读取其内容。所需能力包括 Arcubase 使用类工具及适用的文件/图像读取能力,参见内容与资料工具。
CRIDO:从上传到报销草稿
验证应用与助理的协作
使用已授权的测试发票,在报销助理会话中发送:
- 对照原票核对日期、商户、金额和币种;模糊字段应明确待核对。
- 人确认后,工作台能找到同一报销单,金额与明细一致,附件可由获授权人员打开。
- 在工作台按权限补充用途或退回原因,助理再次查询时能读到最新结果。
- 测试重复上传、无法读取的附件、缺失用途、取消确认和其他员工越权访问。
- 如果纳入审批流程,单独验证各角色允许的状态迁移和记录;草稿保存不代表审批通过。
本地联合验收通过并明确批准发布后,按Workbench 开发流程发布应用,再用最终地址复验。交付保留数据标识、员工与 Skill、角色权限、样例证据、业务规则版本和维护责任人。