업종 선택지는 FRCS_TPBIZ_CD(2자리)만 — 4자리 FRCS_CD는 업종+업태를 이어 붙인 표시용이라 저장값이
아니다. 연락처는 BizPlay 행처럼 숫자만 보낸다. 백엔드가 BizPlay 위임을 끊고 TB_COM_VOUCHER에
직접 넣게 된 것과 수정 VO에 frcsNo가 빠진 결함을 문서에 적는다.
Co-Authored-By: Claude Fable 5.1
가맹몰 관리 — [등록] 버튼과 수정 모달을 활성화해 백엔드 VO(MngrVocInsertReqVo/UpdateReqVo)
대로 JSON으로 보낸다. 예금주·입금은행(COM_BANK_CD)·계좌·업태(FRCS_BZSTAT_CD)·구분(FRCS_DV_CD)
항목을 더하고 주소·우편번호도 직접 고칠 수 있다. 백엔드는 아직 BizPlay(웹캐시) 위임이고
우리 DB 저장으로 바뀔 예정(사용자 공지)이라 응답의 가맹점 코드는 어느 모양이든 읽고, 없으면
목록에서 이름·연락처로 찾는다.
가맹몰 상세 — 업체명·연락처·우편번호([주소 검색])·주소·상세주소를 읽기 전용에서 입력으로
바꾼다(사용자 확정). 저장하면 가맹점을 만들거나(코드 없음) 바뀐 값만 고친(코드 있음) 뒤 상세를
붙인다. 가맹점 선택 화면은 빈 등록 폼으로 바뀐다. 우편번호 검색 도우미는 두 화면이 쓰므로
app/_components/postcode.ts로 옮긴다.
Co-Authored-By: Claude Fable 5.1
백엔드 1c7b0e0 — GET /common/file/image/list/{atchFileId}가 생겨 이미지 존재를 더듬던 코드
(HEAD 401·fetch 취소 멈춤·빈 200을 거치며 세 번 고친 것)를 전부 걷어낸다. 상세 목록·단건이
메뉴 건수(productCnt)를 주고 카테고리 코드표 INNER JOIN이 빠졌으며, 가맹점 목록은 등록일
(frstRegDtStr)을 준다.
Co-Authored-By: Claude Fable 5.1
업종 값은 BizPlay FRCS_TPBIZ_CD(CHAR라 뒤 공백 제거)이고 그동안 구분코드(FRCS_DV_CD)를 읽어
하드코딩 목록과 맞추고 있었다. 공통코드 FRCS_TPBIZ_CD를 받아 목록 열·상세 모달 선택지·엑셀이
같은 표로 이름을 찾는다(사용자 확정).
Co-Authored-By: Claude Opus 5
백엔드가 카테고리 이름(frcsTypeCdNm)을 붙여 주므로 목록·메뉴 폼이 그것을 먼저 쓰고 코드표
매핑은 뒤로 물린다. 추가 이미지 장수를 알아내는 HEAD 더듬기는 차례가 아니라 한꺼번에 보내
왕복을 한 번으로 줄인다. 가맹점 목록이 useYn을 주기 시작한 것을 문서에 반영한다.
Co-Authored-By: Claude Opus 5
가맹점: 조회 SQL이 USE_YN을 select하지 않고 MngrVocVo에도 필드가 없어 값이 오지 않는데
`!== 'N'`으로 읽어 늘 「노출」이었다. 「미노출」로 걸러 낸 행까지 전부 「노출」로 보였다.
값이 없으면 판단하지 않고(null) 목록·모달 모두 고르지 않은 상태로 둔다 — 브랜드명·메모·
등록일과 같은 처리다(사용자 확정). 신규 등록만 「노출」로 시작한다.
회원: 학생·관리자 모두 상태를 바꿀 수는 있는데 목록에 그 열이 없어 확인할 자리가 없었다.
학생은 사용여부(useYn), 관리자는 잠김여부(acctLockYn의 반대)를 열로 넣는다. 값이 없는 행은
`-`다.
Co-Authored-By: Claude Opus 5
백엔드가 등록을 자체 저장에서 BizPlay 외부 가맹점 등록 API 위임으로 바꿨다
(edupay-backend 5fa9d34). `POST /api/v1/mngr/voc`가 form에서 @RequestBody(JSON)가 되고
bizPlayVocApiService.insertVoc를 부르며, 예금주명·입금은행코드·입금계좌번호·업태코드가
새로 필수가 됐다. 지금 등록 폼은 그 값을 받지 않아 계약이 맞지 않는다.
- 목록의 [등록] 버튼을 비활성화한다(엑셀등록과 같은 방식). 시안의 자리는 그대로 둔다.
- 모달을 여는 상태·렌더를 걷어내 폼에 닿을 수 없게 한다.
- saveMerchantAction도 저장 직전에서 끊는다 — Server Action은 UI를 거치지 않고도 호출되므로
버튼만 비활성화하면 막은 것이 아니다. 세션 확인과 입력 검증은 그대로 두어 다시 열 때
createMerchant 호출만 되살리면 되게 했다.
다시 열 때: createMerchant를 새 계약(JSON, MngrVocInsertReqVo)으로 바꾸고 폼에 정산 계좌
항목을 추가한 뒤, _actions.ts의 마지막 return을 try/catch + createMerchant로 되돌린다.
Co-Authored-By: Claude Opus 5
기획 시안과 틀어져 지우면 안 되는 항목이었다(사용자 확정). 브랜드명·메모·등록일·
최종수정일을 목록·팝업·엑셀에 되살리고, 값이 없을 때 '-'가 나오게 한다.
등록 시 브랜드명·메모도 함께 보낸다 — 요청 VO에 없어 지금은 버려지지만 컬럼이
생기면 프론트 수정 없이 저장된다.
Co-Authored-By: Claude Opus 5
mock을 걷어내고 TB_COM_VOUCHER를 보는 실제 API에 붙였다. 필드 이름이 화면 용어와
달라 Repository가 옮긴다 — frcsNo=코드, frcsNm=가맹점명, brno=사업자번호,
rprsvNm/rprsvTelno=대표자/전화, frcsPostAddr/frcsDaddr/frcsPostZip=주소 3종.
백엔드에 자리가 없는 것은 화면에서 뺐다 — 브랜드명·메모·등록일 컬럼이 없고,
수정·삭제·단건조회 API가 없다(목록과 등록 둘뿐). 행의 수정·삭제 버튼은 시안 자리를
두되 누르면 준비 중임을 알린다.
우편번호(frcsPostZip)를 새로 싣는다 — 주소 검색이 함께 채우는 값이다.
Co-Authored-By: Claude Opus 5
기획 MCH_001 목록 / MCH_002_p 등록 / MCH_003_p 수정. 관리자용 가맹점 API가 없어
(mngr 도메인에 컨트롤러가 없고 common/qrauth의 결제 조회용 VO는 5개 필드뿐)
Repository를 mock으로 둔다 — 화면·검증·액션은 실제 구조다.
목록은 업종·사용여부 필터와 가맹점명/사업자번호/주소 검색, 최근등록순 정렬,
엑셀다운로드(CSV)까지. 가맹점코드는 저장 시 서버가 만들고 수정에서는 읽기 전용이다.
시안에 있으나 정할 것이 남은 두 가지는 자리를 두고 표시해 둔다 — 주소 검색은 연동할
서비스가 없어 직접 입력으로 받고, 엑셀등록은 양식·검증 규칙이 없어 비활성이다.
Co-Authored-By: Claude Opus 5