rcx
|
ab7219e600
|
feat(wms):上架管理PC上传页默认填充指定上架库位(维他奶仓→2层冷凍A區A01),仅回显不落库
|
2026-08-22 14:06:56 +08:00 |
|
王奎兴
|
1b3b1a6394
|
Merge branch 'dev' into dev-ty1.2
# Conflicts:
# mhd_wms/src/main/resources/bootstrap.yml
|
2026-08-22 13:59:22 +08:00 |
|
王奎兴
|
072a4f7d1f
|
退货验证发票号是否重复;维他奶导入单号添加校验;
|
2026-08-22 11:17:42 +08:00 |
|
王奎兴
|
63a19fbbcd
|
退货入库单编辑后才显示数量;
|
2026-08-22 10:26:54 +08:00 |
|
rcx
|
5fc491f612
|
fix(oms,wms):执行单重复下发致WMS收货明细翻倍修复,executeAndIssue获取仓库信息失败修复
一、收货明细翻倍(executionStockInOrderApi/issueOrder下发后,WMS收货管理详情明细×2):
根因:执行单下发接口无防重 + WMS接收端无幂等。executeAndIssue已自动下发过的执行单
仍可被手动再次下发(issueTime已置但无校验),重复推送使WMS插入同号入库主单+第二份
in_material_detail,再生成第二张同号收货单(收货单号"RV-"+入库单号确定性生成),
收货管理详情按单号查明细即双倍。四层防御:
1. OMS执行单issueOrder补防重:issueTime非空拒绝下发(与executeAndIssue对齐),
inOrderIds去重防同请求重复推送
2. WMS omsOrderAdd主单幂等:同单号有效单(del_flag=1)已存在则跳过插入
3. WMS omsOrderAddDetail明细幂等:按oms_in_material_detail判重,已存在行不再插入;
未传ID的行保持原插入行为
4. WMS autoAuditOmsInOrder取单补orderByAsc(in_order_id)消除同号取单随机性;
auditApprove生成收货单前按收货单号查重过滤,已生成过的单不再重复生成
二、executeAndIssue报"获取仓库信息失败":
1. 明细行warehouseId=0时兜底改用主表仓库(与下发issueOrder兜底逻辑对齐),
不再拿无效仓库ID调system服务
2. executeAndIssue/issueOrder两处报错增强为带仓库ID与错误信息,便于定位
存量已翻倍数据(重复入库单/明细/收货单)需另行软删清理,本次仅防新增
|
2026-08-21 18:21:03 +08:00 |
|
rcx
|
b209d8cb6d
|
fix(oms):出库明细materialBaseInfoId自动纠正,杜绝脏物料ID落库
问题:客户端推单把materialInventoryId传进materialBaseInfoId字段(或漏传为0),
出库明细存脏ID,编辑/保存报"物料基础信息不存在"(如DCCK034存了库存ID477/444,
真实物料ID应为233/231)。预约端校验原先静默跳过,脏数据持续入库(7-15起200+行)。
一、新增MaterialBaseInfoResolveService三级解析:
baseId直查 → 库存ID反查纠正 → 物料编码+组织兜底,全部失败返回null
二、三处setMaterialDetailInfo改为纠正+回填(预约/业务/执行出库单):
查不到抛错带定位信息(baseId/库存ID/物料编码/单号);
纠正后的ID随保存落库,旧脏单重新保存即自愈;
预约端由静默跳过改为抛错
三、两处pushOutOrderDetail推送入口(预约/业务)加纠正,
反查不到拒绝保存,脏数据不再入库
注:存量脏数据修复SQL另行手动执行;下发复制链(预约→业务→执行)不走校验,
|
2026-08-21 18:20:22 +08:00 |
|
rcx
|
06aae196c7
|
发测试
|
2026-08-21 16:59:56 +08:00 |
|
rcx
|
e91c5801eb
|
发测试
|
2026-08-21 15:54:46 +08:00 |
|
rcx
|
8704df738c
|
Merge remote-tracking branch 'origin/dev' into dev-ty1.2
|
2026-08-21 15:47:44 +08:00 |
|
rcx
|
000092952f
|
feat(oms,wms):出库/运输单据增加线路车次字段,线路管理支持车次清单维护
1. OMS四张表(business_document_order/execute_order/
reservation_stock_out_order/execution_stock_out_order)加
LINE_CODE/LINE_NAME/SHUTTLE_NO三列,entity/DO/DTO/PO同步加字段,
出库两链路Mapper XML补列与resultMap。
线路编码/名称冗余存line_management的route_code/route_name
(两库不互通无法join);SHUTTLE_NO为字符串(如4或31-4),
前端拼"编码-车次"显示(31-4车次);不复用route(存tms_route.id)
和train_no(入库链路占用)。
下发链路(预约单->执行单,业务单->执行单)同名拷贝自动透传。
2. WMS line_management加SHUTTLE_JSON列(车次序号JSON数组),
四层加字段+XML;DTO加反序列化器兼容前端传数组,
PO加序列化器返回原样输出数组。
3. LineManagementImpl.update组织/仓库名称空串兜底,
修复编辑线路后组织名称被刷成空串、列表查不到的问题。
4. 新增建表脚本sql/20260820_oms_outbound_transport_add_line_shuttle.sql(达梦语法)。
|
2026-08-21 15:28:50 +08:00 |
|
rcx
|
22f2b66ffa
|
feat(oms,wms):库存导出按到期日分组排序并合并同物料同到期日库存(仅wlExpiry查询生效)
需求:库存查询导出按商品到期日分组归类、相同到期日相邻显示,相同物料相同
到期日合并库存。仅在 queryRule=wlExpiry(物料+到期日汇总查询)导出时生效,
列表显示不变;同时回退 8fedb6d6 对列表默认排序的改动。
一、列表默认查询还原(回退 8fedb6d6):OMS queryList 恢复 order by a.update_time desc,
Api 恢复 update_time 内存重排(空值最后),两侧列表排序与改动前一致。
二、导出排序(OMS/WMS queryListByWlExpiry):/list 新增可选参数 orderByExpiryDate,
仅 queryRule=wlExpiry 时生效:
1. wlExpiry + orderByExpiryDate=true(导出):到期日倒序(日期近的在前)、空值最后、
0库存靠后、同到期日按更新时间倒序;排序在SQL层,跨页/全量导出分组不被打散;
OMS Api 传参时跳过 update_time 内存重排,避免覆盖SQL排序
2. 仅 wlExpiry 不带参数:排序保持原样(sort_order+更新时间倒序)
3. 其他查询方式:不受影响,参数被忽略
三、合并:wlExpiry 查询 GROUP BY 物料+到期日+货主(货主隔离),相同物料相同到期日
合并一行,库存/可用/冻结数量及净重/毛重/体积/面积 SUM 汇总(复用现成查询,未改)
四、前端导出:/list + queryRule=wlExpiry + orderByExpiryDate=true + 当前查询条件(不分页)
|
2026-08-21 15:13:28 +08:00 |
|
rcx
|
3aec384ba0
|
fix(wms):出库委托单导入出仓日期丢失、升列与单价回填修复
- HeaderListener:parseDate升级为parseDateSmart,兼容Excel日期序列号(20000~60000≈1954~2064年,
POI DateUtil.getJavaDate转换)及yyyy/M/d、yyyy.M.d、yyyy年M月d日等多格式文本;
出仓日期/完成时间/下单日期三处调用点同步切换;解析失败记入dateParseErrors不再静默
- ExcelParseService:导入校验汇总dateParseErrors,日期单元格有值但格式不识别时阻断导入并
明确提示(为空仍放行,与原行为一致);单价回填从料号分支移至料号/SKU/名称三分支统一回填块,
补齐SKU、商品名称匹配场景
- ItemListener:升列新增normalizeNumeric归一化,去千分位逗号、空值统一存null、纯数字去尾零,
落库值恒为"纯数字或null",前端合计不再产生NaN/拼接
|
2026-08-21 14:56:12 +08:00 |
|
rcx
|
27f3fceb6e
|
feat(wms):出入库导入增加料号与规格型号/SKU码一致性校验
- 料号命中物料档案后:规格型号/SKU码必须与档案一致,Excel留空且档案有值同样报错(提示Excel:空);档案值为空则跳过该项
- SKU以档案条码(bar_code)为基准;错误行一次性汇总提示,拒绝导入
- 出库料号已填写但货主下查不到时直接报错,不再被SKU码/商品名称静默兜底(与入库行为对齐)
|
2026-08-21 14:42:25 +08:00 |
|
王奎兴
|
3e5ed28d69
|
发30
|
2026-08-20 18:14:37 +08:00 |
|
王奎兴
|
78d40d35be
|
发31
|
2026-08-20 18:13:30 +08:00 |
|
rcx
|
8fedb6d6ed
|
feat(oms):库存查询/导出按商品到期日分组排序
|
2026-08-20 17:54:23 +08:00 |
|
王奎兴
|
b8de1c00eb
|
发31
|
2026-08-20 17:41:09 +08:00 |
|
王奎兴
|
bf080609fe
|
发30
|
2026-08-20 17:39:44 +08:00 |
|
王奎兴
|
b415ed6fa0
|
出库预约业务类型查询;
|
2026-08-20 17:34:43 +08:00 |
|
王奎兴
|
694ed699ec
|
单号生成规则包含已删除;
|
2026-08-20 17:26:56 +08:00 |
|
王奎兴
|
0b26692a34
|
发31
|
2026-08-20 15:35:31 +08:00 |
|
王奎兴
|
c2af421c7f
|
发30
|
2026-08-20 15:31:40 +08:00 |
|
王奎兴
|
57f87baf85
|
发30
|
2026-08-20 15:30:59 +08:00 |
|
王奎兴
|
e23edadde6
|
发30
|
2026-08-20 14:59:53 +08:00 |
|
王奎兴
|
530254e000
|
发31
|
2026-08-20 14:57:14 +08:00 |
|
rcx
|
33d085f9b9
|
fix(oms):入库链路计划数量翻倍修复
明细batchUpdate软删条件缺陷(入/出库共6个明细实现类):软删旧明细要求本次提交
至少一行走更新分支,"删光旧物料全部换新物料"时提交列表全为新增行,旧行漏软删
(del_flag仍=1),下发后执行单计划数量=旧+新叠加。改为库内有明细即对账软删
|
2026-08-20 14:45:13 +08:00 |
|
王奎兴
|
21fcc24e2e
|
发31
|
2026-08-20 14:20:07 +08:00 |
|
王奎兴
|
64350f565b
|
列表查询id不对;
|
2026-08-20 14:16:23 +08:00 |
|
rcx
|
ff2b1965f7
|
fix(oms):入库业务单单号重复与入库链路计划数量翻倍修复
一、单号重复:业务单与客户预约两套取号计数器互不可见致撞号。
取号统一为跨两表MAX+1+存在性校验,保存前校验预取号占用,下发不再换号,Mapper新增existsByOrderNumber。
二、计划数量翻倍:编辑明细为软删(del_flag=2留存),下发查明细未过滤del_flag,
软删行被复制进下游单据并计入头表数量(执行单数量≈业务单×2+修改差值)。
1. 预约→业务单下发、执行单推WMS:明细查询补del_flag=1过滤
2. executeAndIssue(执行并下发):补防重复下发校验(issueTime非空拒绝)
3. pushInOrder/pushInOrderDetail:加幂等,防Feign重试插重复单
|
2026-08-20 14:06:50 +08:00 |
|
王奎兴
|
7a769071e4
|
发30
|
2026-08-20 10:48:34 +08:00 |
|
王奎兴
|
b05f994e74
|
发31
|
2026-08-20 10:35:34 +08:00 |
|
rcx
|
ef13d890be
|
fix(oms):入库执行单列表单号搜索查不到,businessNumber死条件改单号模糊互查;库存查询货主过滤移回主表并修正委托方误判
- 入库执行单列表:businessNumber条件原为BUSINESS_NUMBER精确等值,该列无写入恒空致全条件查询0条,改为业务单号/入库单号OR模糊互查
- 入库执行单列表:inOrderNumber精确等值改模糊like;删除重复的createByName条件;补businessInOrderNumber过滤(业务单号/入库单号互查)
- 库存查询:货主过滤(shipperId/Code/Name/shipperInfo)从物料表b移回库存主表a,避免LEFT JOIN退化INNER JOIN丢行
- 库存查询:委托方判定由组织层级改为UserPo.shipperEnterpriseName,避免二级组织运营人员(2841/2842)被误判强制按本人userId过滤
|
2026-08-20 10:17:16 +08:00 |
|
rcx
|
cc943d164b
|
fix(wms):入库单导入表头字段错位、备注丢失
- 取值向右查找时误把下一个标签/选项说明当值(承运方←Tel:、生产商←客户名称:、监管方式←送货地址:、送货地址←查验选项),现遇疑似标签即停止查找
- 备注:xxx同格书写为全角冒号,原仅按半角:拆分导致备注丢失,现全角/半角兼容
- 表头列遍历上界改用getLastCellNum,防空单元格漏扫尾部列"
|
2026-08-20 10:06:50 +08:00 |
|
王奎兴
|
624b7d7d6e
|
发测试;
|
2026-08-20 09:05:10 +08:00 |
|
王奎兴
|
0b61b813a5
|
Merge branch 'dev' into dev_820
|
2026-08-20 09:03:05 +08:00 |
|
rcx
|
77420e9617
|
feat(sys):合同附件增加原始文件名存储字段,配合上传v2回显原名称
需求背景:合同管理-上传的文件需显示原始文件名(原显示 LOCAL:D:\upload\{uuid}.pdf 之类存储键)。
附件此前仅存 fileKey,原始文件名在上传落盘时已被 UUID 重命名丢失,回显无原名可用。
改动内容:
1. contract_manage 表新增 4 个附件原始文件名字段(见 sql/20260818_contract_attachment_original_name.sql):
contract_original_name 合同正本附件原始文件名
integrity_agreement_name 廉政协议附件原始文件名
security_protocol_name 安全协议附件原始文件名
other_attachments_name 其他附件原始文件名(多文件与 other_attachments_url 同分隔符、同顺序)
2. ContractManage / ContractManagePO / ContractManageDO / ContractManageDTO
四个对象同步新增对应 4 个 name 字段,保存、详情、列表全链路透传。
Assembler 与 ContractManageImpl 为 BeanUtils 同名拷贝、Mapper XML 为 SELECT a.*,均无需改动。"
"配套依赖:
- mhd-product 新增 /menu/upload/v2 返回 { fileKey, originalName }(另一提交)
- 前端上传后成对保存 fileKey 与 originalName,回显显示 name 字段
兼容说明:
- 存量合同 name 字段为空,前端回退显示 fileKey 末段(uuid 名),属预期兼容行为
- 纯新增字段,旧代码不读写,不影响既有接口
|
2026-08-19 18:08:59 +08:00 |
|
rcx
|
fa51580985
|
feat(product):附件上传v2返回原始文件名,下载接口支持inline预览与中文文件名
|
2026-08-19 18:04:57 +08:00 |
|
rcx
|
362f1b5e2f
|
fix(bms):科目编码重复致新增账单失败,税率查询按编码+名称取唯一;复制账单改生成新计费流水
- getTaxRate 增加 SUBJECT_NAME 匹配,费用科目编码重复(如1003同时有运输处理费/报关费3)时不再抛 TooManyResultsException,查不到税率兜底0
- addBill、开票/NC推送共4处调用点同步调整;计费流水号为空时只处理自身明细,防空指针
- copyBill 明细清空计费流水id并按原流水映射生成新JFLS流水号,防止复制提交后把原账单的流水改挂到新账单(原账单明细丢失)
- insertAndReturnId 币种空值兜底CNY(与addCost对齐)
|
2026-08-19 18:02:23 +08:00 |
|
rcx
|
b859aa99d3
|
fix(oms):入库业务单导入件数未回显计划数量
- 导入模版去掉Qty(cases)列(5列布局),饮用日期列位前移
- 明细计划数量由Qty箱数改为"件数"取值,件数同步落库PIECE_COUNT用于列表回显
- 物料在当前登录组织下不存在时返回明确提示,替代货主列表取值越界导致的500
|
2026-08-19 17:59:19 +08:00 |
|
rcx
|
83f05dd11d
|
feat(bms):新增费用统计分析报表,科目按模板类别归并、仓储拆散租/固定出租两行、行级占营收比,含34列导出与智能分析归因
|
2026-08-19 15:36:53 +08:00 |
|
zhaoqing
|
6252866f7c
|
fix(oms):明细表保额货物类型
|
2026-08-19 15:29:09 +08:00 |
|
rcx
|
dd0bf32c35
|
feat(gateway):登录验证码改为纯数字,字符源限定0-9
需要将网关yml文件中 math 改成 char
security:
captcha:
enabled: true
type: char # math=算术题,char=纯数字
|
2026-08-19 14:28:45 +08:00 |
|
rcx
|
7ed12c9405
|
feat(bms):应收账单添加费用币种空值兜底CNY、费用明细增加流水备注保存与显示
|
2026-08-19 11:02:52 +08:00 |
|
zhaoqing
|
15c8a2b6e6
|
fix(wms):明细表入库时间
|
2026-08-19 09:14:44 +08:00 |
|
rcx
|
72e445ea16
|
fix(oms):出库添加货物查询不到商品,库存查询改租户+货主维度并出库列表补货主旁路
1.ReservationMaterialInventoryApplicationService.queryList原对非南光组织用户强制organization_id=用户组织且top=2827,委托方(如仓码2841货主)库存被滤空;改为按一级组织(租户)过滤,委托方自动叠加登录货主shipperId查自己的货,库存数据已核实在库
2.ReserveStockOutOrderApplicationService.queryList/detailsList增加货主直查旁路(与入库queryList对齐),委托方按shipperId查询不被组织过滤拦截
|
2026-08-18 18:09:53 +08:00 |
|
rcx
|
f50a3e690a
|
fix(oms):出库预约落库回填仓库/组织/货主,状态默认已创建
与入库侧同款修复:insert按仓库档案回填组织/一级组织/仓库编码名称(兜底2841),委托方回填shipperId/customerId,status默认1已创建(配合App订单状态只读);补fastjson import
|
2026-08-18 18:09:41 +08:00 |
|
rcx
|
8692b38671
|
fix(oms):入库预约App提交后各端不显示,落库回填仓库/组织/货主并支持货主维度查询
根因:App提交的预约单organization_id/shipper_id落库为空、warehouse_code全空,列表按组织与仓码过滤必然查不到
1.ReserveStockInOrderDomainService.insert:
-新增明细非空校验,App不传明细时返回'请添加货物明细'而非NPE
-按warehouseId查仓库档案回填组织(仓码2841/谷丰2842按仓库归属)/一级组织(2827)/仓库编码名称,仓库缺失时兜底登录人一级组织+2841
-委托方(有货主档案)未传shipper时回填登录人userId至shipperId/customerId
-订单状态默认'新增'/status默认1(配合App端订单状态改只读)
2.ReserveStockInOrderApplicationService:
-detailsList增加货主直查旁路(对齐queryList既有逻辑),委托方按shipperId查询不再被组织过滤拦截
-inAndOutList原无任何数据权限,委托方登录强制注入本人shipperId,防止传错组织(如通宇2830)导致列表滤空并防越权
|
2026-08-18 18:09:34 +08:00 |
|
rcx
|
f77d89fa7f
|
fix(thirdParty):短信验证码发送失败误包成成功响应,失败原因取result并返回error
SmsApi.sms发送失败分支原返回AjaxResult.success(发送失败)且getMessage()取的是默认文案,现改为AjaxResult.error并携带乐信通返回的失败原因,App端可感知发送失败原因
注:收不到验证码的主因(网关白名单/租户域名映射)为Nacos与DB配置项,不在代码仓库
|
2026-08-18 18:09:25 +08:00 |
|
rcx
|
0ff327a071
|
fix(auth):App注册接口空实现,补全手机号+短信验证码注册链路
1.AppTokenController.register改为透传完整LoginDTO
2.TokenLoginApplicationService.register原为TODO空壳(仅格式校验直接返回成功),现补全:注册短信验证码校验(SMS_REGISTER redis)→域名解析一级组织→按手机号查重→复用registerAddUser创建用户(含默认角色/YMS同步)→注册成功清验证码并记录日志
3.配套网关白名单(/auth/app/register,/auth/app/getOrganizationByPath/**)需在Nacos发布,不入库
|
2026-08-18 18:09:18 +08:00 |
|
rcx
|
6661c016e8
|
fix(auth):密码登录账号/密码错误无提示,登录配置读取与全局异常兜底
1.SysPasswordService.validate登录重试配置(login/maxRetryCount,lockTime)读取增加try/catch与空值保护,三方服务异常或配置缺失时降级默认值(错5次锁30分钟)并warn日志,不再NPE/NumberFormatException导致msg为空
2.GlobalExceptionHandler的RuntimeException/Exception分支对e.getMessage()为空兜底为'系统繁忙,请稍后重试',保证App端始终能拿到可展示的错误信息
|
2026-08-18 18:08:49 +08:00 |
|