wr: 하수재이용시설 등록 수요처 추가

apps/wr/app/store/ruseFcltMng/fcltReg/pbnstReg/type.tsx

@@ -259,9 +259,9 @@ const PrfSchema = z.object({
   farmUswtr: z.number(),
   ugwtChr: z.number(),
   indstUswtr: z.number(),
-  regDt: z.date().default(new Date()).nullish(),
+  regDt: zDateNullish,
   rgtr: z.string().nullish(),
-  mdfcnDt: z.date().default(new Date()).nullish(),
+  mdfcnDt: zDateNullish,
   mdfr: z.string().nullish(),
 });
 

apps/wr/docs/작업계획/수요처 사업자번호 수정 대응 계획_20260703.md

@@ -0,0 +1,485 @@
+# 수요처 사업자번호 수정 대응 계획
+
+작성일: 2026-07-03
+
+## 1. 배경
+
+현재 WR 수요처 구조는 `tb_wr_ruse_fclt_dmd_co.dmd_info_id`를 수요처의 표시용 사업자등록번호이면서 동시에 연관관계 키처럼 사용하고 있다.
+
+이 구조에서는 수요처의 사업자등록번호를 수정하려면 아래 연관 테이블의 `dmd_info_id`까지 함께 수정해야 한다.
+
+- `tb_wr_ruse_fclt_dmd_co` 재사용시설수요회사
+- `tb_wr_dmd_info_reg` 수요정보등록
+- `tb_wr_sply_cndt_spt` 공급후보지점
+- 이를 참조하는 조회 SQL 및 프런트 화면
+
+요청사항은 `tb_wr_ruse_fclt_dmd_co`에 `dmd_co_sn`(수요처일련번호)을 추가하고, 연관 테이블도 `dmd_co_sn`로 연결되도록 바꿔서 사업자등록번호 변경 시 다른 테이블 수정이 필요하지 않게 만드는 것이다.
+
+기준 SQL 초안은 아래 파일이다.
+
+- `G:\내 드라이브\07 유역하수도\208 공단 배포\sql\alter_tables_wr.sql`
+
+## 2. 목표
+
+이번 작업의 목표는 아래 3가지다.
+
+1. 수요처의 내부 식별키를 `dmd_info_id`에서 `dmd_co_sn`으로 전환
+2. 사업자등록번호(`dmd_info_id`)는 수정 가능한 업무값으로만 유지
+3. 사업자등록번호를 화면/API에 보여줄 때는 항상 `dmd_co_sn` 기준으로 원본 수요처 테이블을 join해서 조회
+
+정리하면:
+
+- 내부 연관키: `dmd_co_sn`
+- 표시/로그인/입력값: `dmd_info_id`
+
+## 3. 현재 구조 분석
+
+### 3.1 기준 테이블
+
+현재 수요처 마스터 역할은 `tb_wr_ruse_fclt_dmd_co`가 맡고 있다.
+
+주요 컬럼:
+
+- `dmd_info_id`: 사업자등록번호 + 종사업자번호 조합값
+- `dmd_co_nm`: 수요처명
+- `ctpv_cd`, `sgg_cd`, `daddr`, `telno` 등 기본정보
+
+현재 `alter_tables_wr.sql`은 이 테이블에 `dmd_co_sn`을 추가하고 PK를 `dmd_co_sn`으로 전환하는 1차 작업까지 포함하고 있다.
+
+### 3.2 연관 테이블
+
+`reuse-service` 분석 결과, 사업자번호 변경 영향이 직접 가는 주요 연관 테이블은 아래와 같다.
+
+1. `tb_wr_dmd_info_reg`
+- 수요정보 이력/상세
+- 현재 `dmd_info_id`를 보유하고 있고, 조회 시 `tb_wr_ruse_fclt_dmd_co`와 `dmd_info_id`로 join
+
+2. `tb_wr_sply_cndt_spt`
+- 공급후보지점/매칭 정보
+- 현재 `dmd_info_id`, `dmd_info_sn`을 함께 사용
+- 일부 조회는 `dmd_info_id`, 일부 조회는 `dmd_info_sn` 기반으로 섞여 있음
+
+3. 조회 전용 join 경로
+- `demand_mapper.xml`
+- `public_fc_select.xml`
+- 수요처 관련 화면/지도/팝업 API
+
+### 3.3 현재 SQL의 불일치
+
+`demand_mapper.xml`을 보면 수요처 조인이 일관되지 않다.
+
+- `getDemand`, `getDemandById`는 `twrfdc.dmd_info_id = twdir.dmd_info_id`
+- `tb_wr_sply_cndt_spt`도 `twrfdc.dmd_info_id = twscs.dmd_info_id`
+- 반면 `getDemandInfo`, `getDemandInfoListCnt`는 일부 구간에서 `twscs.dmd_info_sn = twdir.dmd_info_sn`
+
+즉 현재도 `dmd_info_id`와 `dmd_info_sn`이 혼용되고 있으며, 이번 변경에서 `dmd_co_sn` 기준을 명확히 세우지 않으면 추가 혼선이 생긴다.
+
+### 3.4 API 구조
+
+주요 수요처 API는 `DemandController` 아래에 있다.
+
+- `POST /reuseFc/request`
+- `PUT /reuseFc/request`
+- `POST /reuseFc/request/login`
+- `GET /reuseFc/request/{demandCd}`
+- `GET /reuseFc/request/{pageNo}/{pageCnt}/{sggCd}`
+- `GET /reuseFc/request/infoList/...`
+- `PUT /reuseFc/request/chgPassword/{dmdCd}`
+- `PUT /reuseFc/request/cst/{splyCd}/{dmdCd}`
+
+현재 path variable 이름은 `dmdCd`, `demandCd` 등이지만 실제 의미는 대부분 `dmd_info_id`다.
+
+### 3.5 WR 프런트 영향 범위
+
+WR에서 `dmdInfoId`를 직접 키로 쓰는 주요 영역은 아래와 같다.
+
+1. 수요처 현황/관리
+- `apps/wr/app/store/matDmd/coSttn/index.tsx`
+- `apps/wr/app/(with-layout)/matMng/coMng/coSttn/page.tsx`
+
+2. 지도/팝업
+- `apps/wr/app/store/map/coSttnMap/index.tsx`
+- `apps/wr/components/lib/func/mapUtil.ts`
+- `apps/wr/app/(popUp-layout)/splyPopup/page.tsx`
+- `apps/wr/app/(popUp-layout)/mapFeaturePopup/page.tsx`
+
+3. 공공하수처리시설 등록 폼 내 수요처 연결
+- `apps/wr/components/ui/form/fcltReg/pbnstReg/buseReg/bugRegForm.tsx`
+
+4. 공사비 검토/매칭
+- `apps/wr/components/ui/form/coMat/conCostForm/conCostForm.tsx`
+- `apps/wr/app/store/matDmd/coMatRvw/index.tsx`
+
+### 3.6 DM 프런트 영향 범위
+
+DM에서도 `dmdInfoId`를 내부키처럼 재사용하고 있다.
+
+1. 로그인/회원식별
+- `apps/dm/components/LoginModal.tsx`
+- `apps/dm/components/ui/sdmLoginForm/component.tsx`
+
+2. 수요처 등록/수정 공통 컴포넌트
+- `frontend/packages/common/business_components/src/ui/sdmInsertForm/*`
+
+3. 신청현황/수요정보 조회
+- `apps/dm/app/store/sdmMng/index.tsx`
+- `apps/dm/app/(with-layout)/apply/status/page.tsx`
+- `apps/dm/app/(with-layout)/apply/dmdinfo/page.tsx`
+- `apps/dm/app/(with-layout)/apply/dmdco/page.tsx`
+
+4. 지도 팝업
+- `apps/dm/app/(popup-layout)/map/popup/page.tsx`
+
+DM은 로그인 후 세션의 `dmdInfoId`를 그대로 조회키로 쓰는 흐름이 있으므로, 응답에 `dmdCoSn`을 함께 내려주고 세션에도 저장하도록 수정해야 한다.
+
+## 4. 목표 구조
+
+### 4.1 데이터 모델 원칙
+
+- `tb_wr_ruse_fclt_dmd_co.dmd_co_sn`: 수요처 마스터 PK
+- `tb_wr_ruse_fclt_dmd_co.dmd_info_id`: 수정 가능한 사업자등록번호
+- `tb_wr_dmd_info_reg.dmd_co_sn`: 수요처 FK
+- `tb_wr_sply_cndt_spt.dmd_co_sn`: 수요처 FK
+
+기존 `dmd_info_id` 컬럼은 즉시 제거하지 않는다.
+
+역할은 아래처럼 축소한다.
+
+- 입력/로그인 시 사업자번호 매칭
+- 화면 표시용 값
+- 과거 API 호환용 보조값
+
+### 4.2 조회 원칙
+
+사업자등록번호를 응답에 포함할 때는 `tb_wr_ruse_fclt_dmd_co`에서 가져온다.
+
+즉 아래 형태로 바꾸는 것이 원칙이다.
+
+- 기존: `twdir.dmd_info_id`, `twscs.dmd_info_id` 직접 사용
+- 변경: `twdir.dmd_co_sn = twrfdc.dmd_co_sn` 또는 `twscs.dmd_co_sn = twrfdc.dmd_co_sn` 후 `twrfdc.dmd_info_id` 선택
+
+## 5. DB 작업계획
+
+### 5.1 `tb_wr_ruse_fclt_dmd_co`
+
+`alter_tables_wr.sql` 기준으로 아래는 확정 방향이다.
+
+- `dmd_co_sn` 추가
+- sequence 생성
+- 기존 데이터 채번
+- `dmd_co_sn` PK 전환
+- `dmd_info_id` unique 유지
+
+추가 검토:
+
+- `dmd_info_id` nullable 허용 여부는 업무상 불필요하면 현행 유지
+- 사업자번호 변경 이력 관리가 필요하면 별도 이력 테이블은 후속 검토
+
+### 5.2 `tb_wr_dmd_info_reg`
+
+추가 필요 컬럼:
+
+- `dmd_co_sn integer not null`
+
+필요 작업:
+
+1. 기존 데이터 backfill
+- `update ... set dmd_co_sn = twrfdc.dmd_co_sn from tb_wr_ruse_fclt_dmd_co twrfdc where twdir.dmd_info_id = twrfdc.dmd_info_id`
+
+2. FK 추가
+- `fk_tb_wr_dmd_info_reg__dmd_co_sn -> tb_wr_ruse_fclt_dmd_co(dmd_co_sn)`
+
+3. 신규 insert/update 시 `dmd_info_id` 대신 `dmd_co_sn`을 기준값으로 사용하도록 mapper 수정
+
+주의:
+
+- `tb_wr_dmd_info_reg` 자체 PK인 `dmd_info_sn`은 그대로 유지
+- 수요정보 이력 식별과 수요처 마스터 식별은 분리
+
+### 5.3 `tb_wr_sply_cndt_spt`
+
+추가 필요 컬럼:
+
+- `dmd_co_sn integer not null`
+
+필요 작업:
+
+1. 기존 데이터 backfill
+- `dmd_info_id` 또는 `dmd_info_sn`을 통해 `tb_wr_ruse_fclt_dmd_co.dmd_co_sn` 채움
+
+2. FK 추가
+- `fk_tb_wr_sply_cndt_spt__dmd_co_sn -> tb_wr_ruse_fclt_dmd_co(dmd_co_sn)`
+
+3. unique / conflict key 재검토
+- 현재 `ON CONFLICT (dmd_info_id, pbnst_ruse_fclt_id, sply_fclt_flg, pbnst_ruse_fclt_biz_sn)`
+- 변경 후 후보: `(dmd_co_sn, pbnst_ruse_fclt_id, sply_fclt_flg, pbnst_ruse_fclt_biz_sn)`
+
+### 5.4 기타 테이블
+
+`tb_wr_cstrn_cst`는 현재 `dmd_info_sn` 기준이므로 직접적인 `dmd_co_sn` 추가 대상은 아니다.
+
+다만 공사비 화면에서 사업자번호를 표시할 때는:
+
+- `tb_wr_cstrn_cst -> tb_wr_dmd_info_reg(dmd_info_sn) -> tb_wr_ruse_fclt_dmd_co(dmd_co_sn)`
+
+경로를 사용해야 한다.
+
+## 6. 백엔드 작업계획
+
+### 6.1 도메인/DTO 수정
+
+대상:
+
+- `DemandCo`
+- `DemandInfo`
+- `DemandMatching`
+- `DemandMatchingInfo`
+
+추가/정리 방향:
+
+- `dmdCoSn` 필드 추가
+- `dmdInfoId`는 표시값으로 유지
+- path/body에서 내부 처리에 필요한 경우 `dmdCoSn` 우선 사용
+
+### 6.2 Mapper SQL 수정
+
+대상 파일:
+
+- `D:\iipbs\wr_back_out\src\main\resources\postgres\mapper\wr\demand_mapper.xml`
+- `D:\iipbs\wr_back_out\src\main\resources\postgres\mapper\wr\public_fc_select.xml`
+
+핵심 수정:
+
+1. `getDemand`, `getDemandById`
+- `tb_wr_dmd_info_reg`, `tb_wr_sply_cndt_spt` join을 `dmd_co_sn` 기준으로 변경
+- 응답의 사업자번호는 `twrfdc.dmd_info_id` 사용
+
+2. `insertDemand`
+- 신규 등록 후 `dmd_co_sn`까지 반환되도록 수정 검토
+
+3. `insertDemandInfo`, `updateDemandInfo`
+- `dmd_co_sn` 저장
+- 화면에서 `dmdInfoId`만 보내는 경우 backend에서 먼저 `dmd_co_sn` 조회 후 저장
+
+4. `insertMatching`, `updateMatching`, `getDemandMatching`
+- 조건식과 upsert key를 `dmd_co_sn` 중심으로 전환
+
+5. `getDemandInfo`, `getDemandInfoListCnt`
+- 사업자번호 표시 시 `twrfdc.dmd_info_id`
+- 수요처 연계는 `dmd_co_sn`
+
+6. `public_fc_select.xml`
+- 공공하수처리시설 상세의 수요처 목록 조인도 `twscs.dmd_co_sn = twrfdc.dmd_co_sn`로 전환
+
+### 6.3 Service / Controller 수정
+
+대상:
+
+- `DemandService`
+- `DemandController`
+
+수정 방향:
+
+1. 로그인
+- `loginDemand()`는 사업자번호(`dmdInfoId`)로 수요처 마스터를 조회하는 흐름 유지
+- 로그인 성공 응답에 `dmdCoSn` 포함
+
+2. 단건 조회
+- `GET /reuseFc/request/{demandCd}`는 기존 호환을 위해 사업자번호 기반 조회 유지 가능
+- 응답에는 반드시 `dmdCoSn` 포함
+
+3. 수정 API
+- `PUT /reuseFc/request`
+- 사업자번호 변경 시 `tb_wr_ruse_fclt_dmd_co`만 수정하도록 처리
+- 다른 연관 테이블은 수정하지 않음
+
+4. 비밀번호 초기화
+- 현재 `PUT /reuseFc/request/chgPassword/{dmdCd}`는 사업자번호 path 기반
+- 화면 호환을 위해 우선 유지하되, 내부에서는 `dmd_info_id`로 마스터 조회 후 처리
+
+5. 공사비/매칭
+- `PUT /reuseFc/request/cst/{splyCd}/{dmdCd}`는 후속적으로 `dmdCoSn` 기반 API로 정리 검토
+- 1차는 내부 변환으로 대응 가능
+
+## 7. WR 프런트 작업계획
+
+### 7.1 수요처 관리 화면
+
+대상:
+
+- `apps/wr/app/store/matDmd/coSttn/index.tsx`
+- `apps/wr/app/(with-layout)/matMng/coMng/coSttn/page.tsx`
+- `apps/wr/app/store/matDmd/coSttn/headList.tsx`
+
+수정 방향:
+
+- 목록/상세 응답 타입에 `dmdCoSn` 추가
+- 수정 시 내부 식별은 `dmdCoSn`, 화면 표시는 `dmdInfoId`
+- 사업자번호 중복 체크 로직은 신규 등록에서만 `dmdInfoId` 기준 사용
+- 수정 모드에서는 원본 `dmdCoSn` 기준으로 update 호출
+
+### 7.2 지도/팝업
+
+대상:
+
+- `apps/wr/app/store/map/coSttnMap/index.tsx`
+- `apps/wr/components/lib/func/mapUtil.ts`
+- `apps/wr/app/(popUp-layout)/splyPopup/page.tsx`
+
+수정 방향:
+
+- 지도 feature id가 현재 `dmdInfoId` 기반이면 유지 여부 검토 필요
+- 내부 상세조회 키는 `dmdCoSn`를 우선 사용
+- 화면/툴팁의 사업자번호 표시는 응답의 `dmdInfoId`
+
+주의:
+
+- 지도 레이어 원본 데이터 키가 당장 `dmdInfoId`라면, 1차는 지도 highlight 키는 유지하고 상세 API만 `dmdCoSn` 병행 처리하는 방식이 안전하다.
+
+### 7.3 공사비/매칭 화면
+
+대상:
+
+- `apps/wr/components/ui/form/coMat/conCostForm/conCostForm.tsx`
+- `apps/wr/app/store/matDmd/coMatRvw/index.tsx`
+
+수정 방향:
+
+- 공사비 저장 시 `dmdInfoId` 대신 `dmdCoSn`를 함께 전달하도록 타입 보강
+- popup open, 조회, 저장 시 내부키와 표시값을 분리
+
+### 7.4 공공하수처리시설 등록 화면 내 수요처 선택
+
+대상:
+
+- `apps/wr/components/ui/form/fcltReg/pbnstReg/buseReg/bugRegForm.tsx`
+
+수정 방향:
+
+- 검색 결과 항목은 `dmdInfoId`를 표시하되 선택값에는 `dmdCoSn` 포함
+- 재저장 시 연결 테이블에는 `dmd_co_sn` 기준으로 저장
+
+## 8. DM 프런트 작업계획
+
+### 8.1 로그인/세션
+
+대상:
+
+- `apps/dm/components/LoginModal.tsx`
+- `apps/dm/components/ui/sdmLoginForm/component.tsx`
+- `apps/dm/app/store/sdmMng/index.tsx`
+
+수정 방향:
+
+- 로그인 입력은 기존처럼 사업자번호(`dmdInfoId`) 사용
+- 로그인 성공 응답에 `dmdCoSn`를 포함하여 세션 저장
+- 이후 조회/수정 API는 가능한 범위에서 `dmdCoSn`를 함께 사용
+
+### 8.2 수요처 등록/수정 공통 폼
+
+대상:
+
+- `frontend/packages/common/business_components/src/ui/sdmInsertForm/*`
+
+수정 방향:
+
+- updateList / return type에 `dmdCoSn` 추가
+- 수정 화면에서는 사업자번호 필드를 수정 가능하게 바꾸되, 내부 원본키는 `dmdCoSn` 유지
+- 신규 등록과 수정의 검증 로직을 분리
+
+### 8.3 신청현황/상세/지도팝업
+
+대상:
+
+- `apps/dm/app/(with-layout)/apply/status/page.tsx`
+- `apps/dm/app/(with-layout)/apply/dmdinfo/page.tsx`
+- `apps/dm/app/(with-layout)/apply/dmdco/page.tsx`
+- `apps/dm/app/(popup-layout)/map/popup/page.tsx`
+
+수정 방향:
+
+- 세션의 `dmdInfoId`만 참조하는 흐름을 `dmdCoSn + dmdInfoId` 병행 구조로 수정
+- 사업자번호 표시 포맷은 그대로 유지
+- 단건 조회키는 backend 변경 폭에 맞춰 `dmdCoSn` 지원 여부를 우선 검토
+
+## 9. 구현 순서
+
+1. DB DDL 작성
+- `tb_wr_ruse_fclt_dmd_co`
+- `tb_wr_dmd_info_reg`
+- `tb_wr_sply_cndt_spt`
+- FK / unique / index 정리
+
+2. 백필 SQL 작성 및 검증
+- 기존 데이터의 `dmd_co_sn` 채우기
+
+3. reuse-service DTO / mapper / service 수정
+
+4. Swagger 기준 API 응답에 `dmdCoSn` 포함 확인
+
+5. WR 프런트 수정
+- 수요처 관리
+- 지도/팝업
+- 공사비/매칭
+
+6. DM 프런트 수정
+- 로그인/세션
+- 등록/수정
+- 신청현황/상세
+
+7. 수동 검증
+
+## 10. 검증 항목
+
+### 10.1 데이터 검증
+
+- 기존 수요처 데이터에 `dmd_co_sn`가 모두 채워졌는지
+- `tb_wr_dmd_info_reg`, `tb_wr_sply_cndt_spt`의 `dmd_co_sn`가 누락 없이 매핑됐는지
+- 사업자번호 변경 후 연관 테이블 update 없이 조회가 정상인지
+
+### 10.2 WR 검증
+
+- 수요처 현황 목록 조회 정상
+- 수요처 수정 후 목록/상세/지도 팝업에 변경 사업자번호 반영
+- 공사비/매칭 저장 정상
+- 공공하수처리시설 상세의 연결 수요처 표시 정상
+
+### 10.3 DM 검증
+
+- 기존 사업자번호로 로그인 정상
+- 로그인 후 세션 유지 정상
+- 수요정보 등록/수정 정상
+- 신청현황/지도팝업에서 사업자번호 표시 정상
+
+## 11. 리스크 및 확인 필요사항
+
+### 11.1 API path의 식별자 의미
+
+현재 `/reuseFc/request/{demandCd}`는 사실상 사업자번호 기반이다.
+
+이번 작업에서 바로 `dmdCoSn` 기반으로 path 계약을 바꾸면 WR/DM 프런트 영향이 커진다.
+
+권장 1차안:
+
+- 외부 API 계약은 최대한 유지
+- 응답 body에 `dmdCoSn` 추가
+- 내부 저장/join만 `dmdCoSn`로 전환
+
+### 11.2 지도 feature key
+
+지도 highlight나 feature id가 `dmdInfoId`에 묶여 있을 가능성이 있다.
+
+따라서 지도 레이어 원천 데이터까지 같이 바꾸는지, 아니면 상세조회 키만 분리할지 먼저 판단이 필요하다.
+
+### 11.3 공통 컴포넌트 영향
+
+`frontend/packages/common/business_components/src/ui/sdmInsertForm/*`는 WR/DM 양쪽이 함께 쓰므로, 이 부분 변경 시 두 앱을 같이 검증해야 한다.
+
+## 12. 결론
+
+이번 작업은 단순 컬럼 1개 추가가 아니라, 수요처 식별체계를 사업자번호 기반 자연키에서 일련번호 기반 대체키로 바꾸는 작업이다.
+
+핵심 원칙은 아래 2줄이다.
+
+1. 연관관계는 `dmd_co_sn`로 묶는다.
+2. 사업자등록번호는 `tb_wr_ruse_fclt_dmd_co`에서만 관리하고, 화면 표시도 항상 그 값을 join해서 사용한다.