[leejongyoung]

AdministCodeRecptnDAO와 InsttCodeRecptnDAO가 각각 모든 벤더 매퍼에 없는 목록/개수 statement id 2건씩을 호출하고 있었습니다. 네 호출을 이미 있는 selectAdministCodeRecptnList/ListTotCnt, selectInsttCodeRecptnList/ListTotCnt statement에 연결하고, 하위 호출자를 위한 public DAO·서비스 시그니처는 모두 그대로 둡니다.

receipt 컨트롤러는 Recptn 이름 연산을 사용합니다. 영향받는 기존 연산은 서비스 인터페이스와 전달 구현을 통해 외부에 열려 있지만, 이 저장소 안에는 호출하는 컨트롤러가 없습니다. 이번 변경은 API를 그대로 둔 채 비어 있는 매핑만 채우며, SQL은 추가하지 않습니다.

upstream main fd9062b8dae0838375272961234946899c2f74a4 검증:

• src/main/java에서 리터럴 select/selectList/selectOne/insert/update/delete id를 추출하고 Python ElementTree로 각 벤더 매퍼의 직접 CRUD 자식을 파싱했습니다.
• altibase·cubrid·goldilocks·maria·mysql·oracle·postgres·tibero 각각 매퍼 파일 153건·statement id 1,245건을 확인했습니다. 전후 비교에서 정확히 영향받는 누락 id 4건이 모든 벤더에서 해소되고 새로운 누락 id는 없습니다.
• 벤더 합집합 누락 id는 11건에서 7건으로 줄었습니다(#1392의 별도 Cnslt 정정과 동적 LoginUsr 접두사 포함).
• git diff --check 통과. 테스트 파일은 추가하지 않았습니다.
• 실제 MyBatis 로딩과 SQL 실행은 수행하지 못했습니다. 이 환경에 Java runtime과 Maven이 없습니다.

이 PR은 #1392 (별도 Cnslt statement 정정)와 독립적입니다. Bndt 개수와 Kno 쓰기 statement는 후속 blocker로 이 범위 밖에 둡니다. 브랜치 간·도구 버전 간 의존성을 만들지 않습니다.

관련: #1315
추적: leejongyoung#11

[jei007]

표준프레임워크에 대한 지속적인 참여에
대단히 감사드립니다.