Expensify/App中未报告每日津贴费用的处理流程优化分析

问题背景

在Expensify/App的9.1.51-0版本中，测试团队发现了一个关于每日津贴(per diem)费用处理流程的异常行为。当用户尝试提交未报告的每日津贴费用时，系统出现了几个关键问题：允许将费用提交给非工作区用户、确认页面返回按钮行为异常等。这些问题影响了用户体验和流程的完整性。

核心问题分析

1. 用户选择权限问题

系统错误地允许用户将未报告的每日津贴费用提交给个人用户而非工作区。从技术实现角度看，这违反了每日津贴费用必须与特定工作区关联的业务规则。

2. 导航流程异常

确认页面存在两个主要导航问题：

• 当选择个人用户后点击返回按钮，系统错误地显示"未找到"页面
• 在确认页面点击返回按钮时，系统错误地返回到每日津贴创建流程而非预期的报告详情页

技术解决方案

权限控制优化

在提交流程中增加了严格的验证逻辑，确保每日津贴费用只能提交到工作区。具体实现是通过检查费用类型和目标接收方类型来强制执行这一规则。

导航流程修复

针对确认页面的返回行为，开发团队重构了导航逻辑：

1. 对于每日津贴请求，增加了是否为移动未报告交易的判断：

if (isPerDiemRequest) {
    if (isMovingTransactionFromTrackExpense) {
        Navigation.goBack();
        return;
    }
    Navigation.goBack(ROUTES.MONEY_REQUEST_STEP_SUBRATE.getRoute(action, iouType, initialTransactionID, reportID));
    return;
}

2. 统一了所有移动交易行为的导航处理，确保一致的返回体验

技术实现考量

在解决这些问题时，开发团队考虑了以下技术因素：

1. 状态管理：需要准确判断当前费用状态(是否已报告)和操作类型(提交/分类等)
2. 导航栈处理：确保返回操作能正确回退到预期页面，避免出现中间状态
3. 业务规则验证：在用户选择接收方时即时验证是否符合每日津贴的业务规则

经验总结

这个案例展示了在复杂财务应用中处理特定类型费用时需要注意的几个关键点：

1. 严格的业务规则验证：特定类型的费用(如每日津贴)通常有特殊的处理规则，需要在UI层就进行严格限制
2. 导航状态管理：在多步骤流程中，必须仔细设计导航栈以确保一致的返回行为
3. 边缘情况处理：特别是对于"移动未报告交易"这类特殊操作，需要单独考虑其导航逻辑

通过这次修复，Expensify/App的每日津贴处理流程变得更加健壮和用户友好，为后续类似功能的开发提供了有价值的参考。