# 2026-07-17 工作日志 ## 门店订单管理页改造(src/pages/store/orders/index.tsx) ### 1. 删除订单改为关闭订单 - 原"删除订单"按钮调用 `removeShopOrder`(物理删除),改为"关闭订单"调用 `updateShopOrder({ orderId, orderStatus: 2 })`(逻辑关闭) - 确认弹窗文案从"删除后无法恢复"改为"关闭后无法恢复" - 移除 `removeShopOrder` 导入,新增 `confirmOfflinePayment` 导入 ### 2. 待付款订单加确认收款按钮 - **背景**:线下付款(payType=9)且未付款的订单,门店需要"确认收款"功能,与后台管理(guilixu-admin)对齐 - **后端接口**:`PUT /shop/shop-order/confirm-offline-payment/{id}?remarks=xxx&paymentVoucher=xxx` - 后端 `ShopOrderController.confirmOfflinePayment()` → `ShopOrderServiceImpl.confirmOfflinePayment()` - 校验:payType必须为9(线下付款)、orderStatus不能为2(已关闭)、不能重复确认 - 确认后设置 payStatus=true、payTime=now(),可选保存 remarks(merchantRemarks) 和 paymentVoucher - **前端API**:在 `src/api/shop/shopOrder/index.ts` 新增 `confirmOfflinePayment(id, remarks?, paymentVoucher?)` 函数 - 注意:Taro 的 `request.put` 不支持 `params` 参数,需手动拼接 query string - **ShopOrder Model**:新增 `paymentVoucher?: string` 字段 - **页面改动**: - OpType 从 `'pay'|'complete'|'editPrice'` 改为 `'confirmPay'|'complete'|'editPrice'` - `getOrderActions` 新增条件:`!payStatus && payType===9 && orderStatus===0` → 显示"确认收款"按钮 - 弹窗新增备注 Textarea(仅 confirmPay 显示),凭证图片限制1张(confirmPay),必填校验 - `submitOperation` 新增 confirmPay 分支,调用 `confirmOfflinePayment` API - 新增 `payRemarks` state ### 3. 订单详情页金额明细0隐藏(src/pages/order/detail.tsx) - **Bug**:React 经典陷阱 `{order.reducePrice && Number(order.reducePrice) > 0 && (...)}`,当 reducePrice 为数字 0 时,`0 && ...` 短路求值为 0,React 渲染文本"0" - **修复**:改为 `{Number(order.reducePrice || 0) > 0 && (...)}`,始终返回 boolean ### 验证 - `npx taro build --type weapp` 构建成功 ## 地址/购物车问题修复 ### 5. 地图选择首次打开列表不显示(src/pages/user/address-edit.tsx) - **问题**:鸿蒙手机首次打开 `Taro.chooseLocation` 时地图 POI 列表不显示,需拖动才出现 - **根因**:未传入经纬度时地图默认定位到北京,鸿蒙系统不会自动获取用户位置 - **修复**:调 `chooseLocation` 前先 `Taro.getLocation({ type: 'gcj02' })` 获取当前位置,将 latitude/longitude 传给地图,确保首次打开就在用户位置附近,POI 列表立即加载 ### 6. 收货地址编辑不加载旧数据 - **Bug 1(API 路径不匹配)**:前端 `updateShopUserAddress` 调 `PUT /shop/shop-user-address/{id}`,但后端 `@PutMapping()` 无 `/{id}` 路径 → 404 - 修复:改为 `PUT /shop/shop-user-address`(去掉 `/{id}`,id 通过 body 传递) - **Bug 2(加载防御)**:`setFormData(addr)` 直接替换 state,若后端返回 null 字段会覆盖初始 `''` - 修复:改为 `setFormData(prev => ({...prev, ...addr, name: addr.name || '', ...}))` 保证字段非 null ### 7. 新用户注册后首次加购购物车不刷新 - **根因**:注册页 `register.tsx` 和登录页 `login.tsx` 只调 `saveStorageByLoginUser()` 存 storage,未调 `UserContext.loginUser()` 更新 React 状态 → `isLoggedIn` 仍为 `false` → 购物车页 `useDidShow` 中 `if (isLoggedIn) refresh()` 不执行 - **修复**: 1. `register.tsx` 和 `login.tsx`:`saveStorageByLoginUser` 后加 `loginUser(token, user)` 同步 UserContext 2. `sms-login.tsx`:`loginBySms` 后加 `syncFromStorage()` 同步状态 3. 防御性措施:`cart.tsx`、`product-detail.tsx`、`index/index.tsx` 的 `useDidShow` 加 `syncFromStorage()` 确保页面显示时从 storage 同步用户状态 ## 门店订单页 Tab 改造(src/pages/store/orders/index.tsx) - **需求**:原「全部 / 已完成 / 已关闭」Tab 改为「待处理 / 已完成 / 已关闭」 - 待处理 = 待付款(0) + 待发货(1) + 待核销(2) + 待收货(3),按用户确认把待核销(2)也并入 - 已完成 = statusFilter 5(不变);已关闭 = statusFilter 8(不变) - **TabKey 类型**:`'all' | 'pending' | 'completed'` → `'pending' | 'completed' | 'closed'` - **TABS 配置**:删除原「全部」无筛选 Tab;待处理用 params 数组 `[{statusFilter:0},{1},{2},{3}]` 并行请求合并去重(loadOrders 已支持) - **默认选中**:`useState('all')` → `'pending'` - **新订单角标**:`tab.key === 'all'` → `tab.key === 'pending'`(移到待处理 Tab) - **statusFilter 后端映射参考**(ShopOrderMapper.xml 第240-282行):0待支付=未付款、1待发货=pay1&delivery10&order0、2待核销=pay1&order0、3待收货=delivery20&order!=1、5已完成=order1、8已取消=order2 - **验证**:tsc 仅剩预存 `@tarojs/taro` 类型缺失环境报错,本文件无新错误 - ⚠️ 注意:原「全部」Tab 显示的「待评价(statusFilter=4)」订单在改版后无 Tab 承接(用户确认不含待评价),如需可见后续可并入待处理 ## 门店订单页「收货信息」一键导航(src/pages/store/orders/index.tsx) - **需求**:订单卡片里的收货信息区域点击可一键导航 - **实现**:`renderOrderCard` 的「收货信息」整块 View 加 `onClick={() => handleNavigate(order)}`,右侧加绿色「› 导航」标识提示可点 - **新增 `handleNavigate(order)`**:读取 `order.addressLat`/`order.addressLng`(模型里为 string)→ `parseFloat` 转 number;坐标有效则 `Taro.openLocation({ latitude, longitude, name: realName, address, scale: 16 })`(微信内置地图,自带导航选 App);坐标缺失/非法则 toast「该订单未记录定位信息,无法导航」兜底 - **注意**:`Taro.openLocation` 是地图展示类 API,不在微信 `requiredPrivateInfos` 受限清单内,无需在小程序后台声明、无需 `ensurePrivacyAuthorized` 预检(与 chooseImage/getPhoneNumber 不同) - **验证**:tsc 仅剩预存 `@tarojs/taro` 类型缺失环境报错,本文件无新错误 ## 订单详情页「过期时间」→「送达时间」(src/pages/order/detail.tsx) - **需求**:订单信息区原「过期时间」(order.expirationTime) 行改为「送达时间」 - **字段确认**:用户选择「送达时间」用 `order.deliveryTime`,且**保留**现有「发货时间」行 → `deliveryTime` 在两行各显示一次(用户明知并接受) - **改动**:第408-413行 `{order.expirationTime && ...过期时间}` 改为 `{order.deliveryTime && ...送达时间}`,数据用 `formatTime(order.deliveryTime)` ## 门店订单页「发货」按钮 + 选发货人员写 shopOrderDelivery(解决物流页发货信息为空) - **根因**:物流页 `pages/order/logistics.tsx` 的「发货信息」卡片依赖 `shopOrderDelivery` 发货单;门店「确认完成」只改订单状态、不建发货单 → `delivery` 为 null → 卡片不渲染(空白) - **方案**:在「确认收款」之后加「发货」按钮,选门店店员作为发货人,写入 `shopOrderDelivery`,从源头让物流页有数据 - **后端可行性(已确认)**:`POST /shop/shop-order-delivery`(save) 已存在,实体字段全可空最少传 orderId;`listShopStoreUser({storeId})` 已存在;请求层自动注入 `TenantId` 请求头(无需手动传租户);`ShopOrderDelivery` 实体有 orderId/deliveryMethod/sendName/sendPhone/sendAddress - **前端改动**: - 新增 `src/api/shop/shopOrderDelivery/index.ts`:`saveShopOrderDelivery(data)` 封装 `POST /shop/shop-order-delivery` - 补全 `src/api/shop/shopStoreUser/model` 的 `ShopStoreUser` 类型缺的 `name`/`phone`/`roleType`/`storeName`/`image`(前端模型此前不完整,后端实体有) - `src/pages/store/orders/index.tsx`: - `OpType` 增加 `'ship'`;`OP_LABEL`/`OP_DESC` 补 ship - `getOrderActions`:已付款 且 `deliveryStatus<20`(或未发货)且 `orderStatus!==1` 时显示「发货」(紫色 `bg-purple-500`) - 新增状态 `showShipModal`/`clerkList`/`selectedClerkId`/`loadingClerks`/`shipping` - 新增 `openShipModal(order)`(拉 `listShopStoreUser({storeId: order.storeId})`)与 `handleConfirmShip()`(先 `saveShopOrderDelivery({orderId, deliveryMethod:20, sendName:clerk.name, sendPhone:clerk.phone, sendAddress:order.storeName})`,再 `updateShopOrder({orderId, deliveryStatus:20, deliveryTime})`) - 渲染「选择发货人员」底部弹层(店员列表可点选,确认发货按钮置灰直到选中) - **设计决策(用户确认)**:① 发货即把订单置「已发货」(deliveryStatus=20);② 发货人可选门店全部店员(经理+店员) - **物流页**:无需改动,`shopOrderDelivery` 存在即自动渲染发货人 - **验证**:tsc 仅剩预存 `@tarojs/taro` 类型缺失环境报错,本文件无新错误 - ⚠️ 行为说明:已付款未发货时「发货」与「确认完成」两个按钮同时显示;店员可跳过发货直接确认完成(该订单仍无发货单,物流页空白,与旧行为一致);如需强制「先发货才能确认完成」,可隐藏未发货订单的「确认完成」按钮(一行判断改动),待用户决定 ### 验证 - `npx taro build --type weapp` 构建成功 ## 门店中心右上角扫码登录 PC 后台(src/pages/store/center/index.tsx) - **需求**:门店中心顶部绿色渐变区右上角加一个二维码扫码图标,点击后调起微信扫码,扫码结果解析出 token 后调 `confirmWechatQRLogin` 确认 PC 端登录 - **参考**:`/Users/gxwebsoft/VUE/template-10584/src/pages/user/components/UserCard.tsx` 中的 `UnifiedQRButton` 组件 - **实现**: - 复用已有 API:`parseQRContent` + `confirmWechatQRLogin`(`@/api/passport/qr-login`),与 `src/components/QRLoginScanner.tsx` 同款 - 新增 `handleScanLogin` callback:`Taro.scanCode` → `parseQRContent` → 校验 token/userId → `confirmWechatQRLogin` → 成功弹窗 - 右上角按钮用 `absolute top-3 right-4 z-20` 定位,半透明白色圆形背景 + base64 SVG 图标 - 小程序不支持 `` 标签,用 `Image` 组件 + `data:image/svg+xml;base64,...` data URI 渲染图标 - 用户取消扫码(errMsg 含 'cancel')静默处理 ## 修复未付款已发货订单状态显示错误 - **问题**:订单列表卡片(OrderCard)和详情页(detail.tsx)状态判断时 `!payStatus`(待付款)优先于 `deliveryStatus` 判断,导致"未付款但已发货"(payStatus=false + deliveryStatus=20) 的订单显示"待付款"而非"待收货" - **修改文件**: - `src/components/common/OrderCard/index.tsx`:`getCardStatus` 把 `deliveryStatus===20/30` 判断提前到 `!payStatus` 之前 - `src/pages/order/detail.tsx`:`getOrderDisplayStatus` 和 `getOrderPhase` 两个函数都做同样调整,物流状态优先于付款状态 - **影响范围**:仅影响"未付款但已发货"的异常场景,正常流程不受影响 ### 状态描述对齐:已发货待收款(payType=9 + deliveryStatus=20 + 未付款) - **需求**:线下付款(payType=9)已发货但未确认收款的订单,用户端应与门店端一致显示"已发货待收款"(红色),而非"待收货"(蓝色) - **修改文件**: - `src/components/common/OrderCard/index.tsx`:`getCardStatus` 在 `deliveryStatus===20` 之前加 `!payStatus && payType===9 && deliveryStatus===20` → "已发货待收款"(红色) - `src/pages/order/detail.tsx`:`getOrderDisplayStatus` 在物流状态判断前加 `isOffline && !payStatus && (deliveryStatus===20||30)` → "已发货待收款"(红色,subtitle: 商品已发货,请尽快转账付款) - `src/pages/store/orders/index.tsx`:`getStatusText` 恢复 `payType===9 && deliveryStatus===20` → "已发货待收款";`getStatusColor` 对应红色 - **最终统一**:三端状态文案完全对齐 | 场景 | 用户端列表 | 用户端详情 | 门店端 | |------|-----------|-----------|--------| | 线下付款+已发货+未付款 | 已发货待收款(红) | 已发货待收款(红) | 已发货待收款(红) | | 其他已发货 | 待收货(蓝) | 待收货(蓝) | 待收货(蓝) | ### 门店端:拆分"确认完成"为"送达"和"确认完成"两个操作 - **新增操作类型** `deliver`(送达):deliveryStatus=20(已发货)且无 sendEndImg 时显示,上传送达照片后按钮自动隐藏(用 sendEndImg 判断,不改变 deliveryStatus) - **修改** `complete`(确认完成):仅已付款才可操作,只标记 orderStatus=1(已完成),不需要上传凭证 - ⚠️ `deliveryStatus=30` 是"部分发货"含义,不能用来表示"已送达",所有相关判断已清除 - **按钮显示逻辑**: | 场景 | 送达 | 确认完成 | 确认收款 | |------|:---:|:---:|:---:| | 线下付款+未付款+已发货(无送达照片) | ✅ | ❌ | ✅ | | 线下付款+未付款+已发货(有送达照片) | ❌ | ❌ | ✅ | | 已付款+已发货(无送达照片) | ✅ | ✅ | ❌ | | 已付款+已发货(有送达照片) | ❌ | ✅ | ❌ | - **deliveryStatus 含义**:10=待发货, 20=已发货, 30=部分发货(未使用) - **状态文案**:deliveryStatus=20+未付款+线下付款 → "已发货待收款"(红),deliveryStatus=20+已付款 → "待收货"(蓝) ### 门店端:改价功能合并到确认收款弹窗 - 去掉独立的"改价"按钮和修改金额弹窗(`editPrice` OpType、`showEditPriceModal`、`editReason` 等) - 在确认收款弹窗中增加"实付金额"输入框(预填当前值,可修改),改价不再需要单独输入原因(收款备注即可说明) - 提交时:如果金额有变化,先调 `updateShopOrder` 更新 `payPrice`+`merchantRemarks`,再调 `confirmOfflinePayment` 确认收款