Row 32：新型储能并网资料目录缺失（实为默认按"风电光伏"模板取目录）

严重其他 · 待调整新型储能模块：并网资料信息 / 并网资料信息　处理人：冷柏烨　区域：五区

1基本信息

问题描述	新型储能并网资料目录缺失。
所属模块	并网资料信息 / 并网资料信息
严重程度	严重（阻断流程：是）
涉及类型	新型储能
提出人	刘向诚
处理人 / 状态	冷柏烨 / 其他（待调整）

2问题截图

并网资料目录 — 图1：新型储能项目的"并网资料信息"第一批目录列表——序号1-8均为主变、开关、CT/PT、风机、逆变器、SVG等风电/光伏通用设备资料，未见电池簇、PCS、BMS、消防等储能专属资料条目

3旧代码定位（backup730 / 730backup 分支）

后端目录（type 维度已经存在，共 4 种）：xnybw5b · src/main/java/cn/csg/so/oms/in/newenergy/constant/Const.java 第 54-57 行：

public static final String  FDGF = "fdgf"; //风电光伏
public static final String  DDDD = "dddd"; //独立调度模式储能电站
public static final String  LHDD = "lhdd"; //联合调度模式储能电站
public static final String  PJLH = "pjlh"; //新能源配建联合储能电站转独立储能电站

目录查询方法：xnybw5b · src/main/java/cn/csg/so/oms/in/newenergy/project/appservice/NewenergyProjectInformationAppService.java 第 419-423 行（getInfomationMenu()）：

NePjInfoVo paramVo = new NePjInfoVo();
if (StringUtils.isBlank(vo.getMenuType())) {
    vo.setMenuType(Const.FDGF);      // ← 前端从未传 menuType，这里被强制兜底成"风电光伏"
}
paramVo.setMenuType(vo.getMenuType());
for (String param : paramSet) {
    List<NePjImplMenuVO> menuList = menuService.getListByParam(param, paramVo);
    paramMenuMap.put(param, menuList);
}

目录过滤 SQL：xnybw5b · src/main/resources/.../dbconfig/NePjImplMenuSQL_mysql.xml（NePjImplMenuVO_getListByParam）：

FROM SO_IN_NE_PJ_IMPL_MENU WHERE is_start = 1
AND (information_type LIKE CONCAT('%', #{param}, '%') OR information_type = '-1')
<if test="vo.menuType != null and vo.menuType != ''">
    AND type LIKE CONCAT('%', #{vo.menuType}, '%')   -- 永远被 fdgf 命中，dddd/lhdd/pjlh 记录全部被过滤掉
</if>

前端调用侧：在 xnybw5f · src/views/projectNew/components/projectDataInfo/component/batchInfo.vue 及其余调用 getInfomationMenu 相关接口的页面全文检索 menuType 关键字，backup730 分支无任何命中——前端从未构造/传递过 menuType 参数。

根因说明：并网资料目录表 SO_IN_NE_PJ_IMPL_MENU 里的每条资料记录都通过 TYPE 字段标注适用的项目子类型（fdgf=风电光伏 / dddd=独立调度储能 / lhdd=联合调度储能 / pjlh=配建转独立储能），说明储能专属资料条目本来就存在于数据库中；但前端从未在请求参数里带上 menuType，导致后端 getInfomationMenu() 恒定兜底为 Const.FDGF（"fdgf"），SQL 里 type LIKE '%fdgf%' 把所有 dddd/lhdd/pjlh 类型的储能专属资料条目全部过滤掉——储能项目实际拿到的，是"风电光伏"模板目录，而不是"目录本身不存在"。

4问题链路示意

前端并网资料信息页

→

请求未携带 menuType

→

后端兜底 menuType=fdgf

→

SQL 过滤掉 dddd/lhdd/pjlh

→

储能项目看到"风电光伏"通用目录

5修复方案

第一步：前端在打开"新型储能"项目的并网资料信息页时，根据该场站的储能调度模式（storedEnergyType / dycType / dwcType，取值如"新能源配建独立储能电站""新能源配建联合储能电站"等）映射为后端 dddd/lhdd/pjlh 枚举值，并在调用目录查询接口时显式传入 menuType：

// batchInfo.vue 调用目录接口前
const MENU_TYPE_MAP = {
  '新能源配建独立储能电站': 'dddd',
  '独立共享储能电站': 'dddd',
  '新能源配建联合储能电站': 'lhdd',
  '电网租赁储能电站': 'lhdd',
  '火电联合调频储能电站': 'pjlh',
}
const menuType = this.impl.energyFlag
  ? (MENU_TYPE_MAP[this.item.storedEnergyType] || 'dddd')
  : 'fdgf'
// 请求参数中加入 menuType: menuType

第二步（后端兜底加固）：NewenergyProjectInformationAppService.getInfomationMenu() 不应在参数缺失时"沉默"兜底为 fdgf，应结合 NePjInfoVO.getType()（项目类型，已在同一批次的其它逻辑中判断"新型储能"，见同文件多处 "新型储能".equals(impl.getType())）自动推导正确的 menuType，避免依赖前端单点传参：

if (StringUtils.isBlank(vo.getMenuType())) {
    boolean isEnergy = filterInformationList.stream()
        .anyMatch(info -> "新型储能".equals(info.getType()));
    vo.setMenuType(isEnergy ? Const.DDDD : Const.FDGF); // 至少不再无差别落到 fdgf
}

效果：新型储能项目按其实际调度模式（独立/联合/配建转独立）取到对应的专属资料目录，不再被"风电光伏"通用模板覆盖；同时后端增加基于项目类型的兜底推导，降低对前端单点传参的依赖。