济南市住宅问题投诉处理平台产品系统

立项原因

济南市住宅领域质量问题来源分散：12345 热线、信访渠道、现场巡查等工单各自流转，存在入库标准不统一、派发靠人工、处理进度难追踪、空间位置与具体户室难以关联等问题。主管部门需要一套统一的数字化平台，把「问题受理—分派—处置—考核—申诉」全链路管起来，并支撑「问题落图」精准定位到社区、小区、单体楼乃至户室。

解决的产品问题





多渠道工单分散登记、状态不一致，无法在统一台账中按办理阶段查看；



派发与科室权责不清，管理员与业务科室数据视野混乱；



处理过程缺乏留痕，回退、审核、不满意申诉等场景缺少闭环；



质量问题与地理空间、楼盘表（户室）脱节，难以「落到具体房屋」；



科室考核依赖手工统计，缺少基于派发量、办结量等的自动汇总。

行业场景与业务背景

系统面向住建领域住宅质量投诉与热线工单治理场景，覆盖信访线与热线线两条业务链。典型流程为：问题入库 → 待分派台账 → 派发至责任科室（或区县） → 问题处理与落图 →（热线）回退与回退审核 → 不满意工单申诉 → 月度/年度考核评价。业务数据以 gdxt_xinfang（信访）、gdxt_rexian（热线）为主表，通过办理状态 blzt 驱动各台账视图；楼盘表 t_house 与地图质心编码关联，实现「图上选楼、表中选户」。

系统包含以下核心功能模块：





信访/热线问题入库：支持手工录入、Excel 批量导入，自动写入入库时间与待分派状态。



问题派发台账：按「待分派」状态展示待办，支持是否区县处理、派发科室、派发时间记录。



问题处理台账：已分派工单的办理、处理结果登记、附件与过程留痕。



问题落图：集成天地图与济南 GIS 专题层（社区、小区、住宅单体、在建工程），左键选区域、右键住宅面调楼盘表选户室，回写工单空间关联字段。



热线回退与回退审核：处理单位申请回退，审核通过后回到处理链路。



不满意工单申诉：独立申诉台账，关联工单编号，支持文书与附件打包。



监督维护处理过程：按工单编号记录处理过程，供申诉与归档引用。



考核评价 / 年度考核：按科室统计派发量、办结量等考核指标。



楼盘表查询：按地图质心编码 centroid_code 查询单元、楼层、户室及建筑面积。



组织权限与工作流：基于 XjrSoft 平台的菜单权限、科室数据范围及 Flowable 审批扩展能力。

技术栈与架构





前后端分离：Vue 单页应用（端口 7778） + Spring Boot REST API（端口 2830），通过 env.js 配置 baseUrl 对接。



多台账同表设计：信访/热线各一张主表，多个业务模块（入库、派发、处理、回退等）共用数据，Service 层硬编码 blzt 过滤形成不同台账视图，降低重复建表成本。



动态数据源：平台业务库（gdxt_db）与楼盘表库（zjjworkdata）分离，@DS 注解切换；入库/工单与 t_house 分库查询。



低代码表单：Avue + 表单配置（Config.js）驱动列表、搜索、字段权限，快速搭建 GDXT 各业务页面。



GIS 集成：maplocation.vue 封装地图初始化、图层加载、hitTest 交互，与 /getlpb、updateMapPlot 等接口联动。

项目亮点





全链路状态机清晰：待分派 → 已分派 →（回退待审核）→ 办结，台账自动分流，业务人员按角色只看本阶段工单。



空间与属性双关联：地图质心/层内码 + 楼盘表户室 ID，实现投诉问题精确到「哪栋楼、哪一户」。



管理员全局视野：派发/处理等台账对系统管理员取消科室 pfks 过滤，调度与监管一体化。



考核数据自动汇聚：从主表读取派发科室、派发时间、处理结果等字段，支撑科室绩效评价。

架构与实现难点





多台账 blzt + pfks 双维过滤：前端 List 注入科室条件、后端 Service 固定状态，需保证入库、派发、处理状态与科室写入一致，否则会出现「入库有数据、派发台账为空」类问题。



分库楼盘表与 NDB 存储：落图右键查楼盘表依赖 zjjworkdata.t_house，与业务库分离；若表为 MySQL NDB Cluster 引擎，集群故障会直接导致 /getlpb 不可用，需 DBA 保障或 InnoDB 备用源。



地图字段异名映射：不同图层使用不同属性名（如社区 质心、小区 CentroidCode、单体 CENTROIDCO），需在落图组件中分层处理。



JDK 与平台兼容：后端需 JDK 8 编译运行，与默认 JDK 17 环境存在差异，部署需注意 JAVA_HOME 配置。