CSO 시스템 설계 및 기능 검토
2026년 6월 17일 공유
CSO·CP 관리 화면 설계 회의 정리
개요
콘텐츠 유형: 회의
CSO 관리 및 CP 관리 기능의 상세 요구사항을 검토하고, 피그마 시안을 기준으로 화면 구조·데이터 항목·검증 로직·권한 체계·전자계약 연동 방향을 구체화했다.
핵심 논의는 다음과 같다.
- 재위탁 통보관리 구조와 조회 기준 정리
- 교육 이수, 경제적 이익 보고, CP 점검 기능의 입력/검증 방식 확정
- 회원가입/계정/권한 구조 재정의
- 전자계약(모두사인) 및 계약서 버전 관리 방향 검토
- 일부 항목은 추가 자료 또는 내부 검토 후 재논의 필요
참여자 및 역할
- 기획/개발 측
- 피그마 시안 설명
- 데이터 구조 및 구현 가능 범위 검토
- 검증 로직, UX, 연동 방식 제안
- 업무 운영 측
- CSO/CP 실제 운영 프로세스 설명
- 필수 필드, 예외 케이스, 승인/반려 흐름 정의
- 계약/재위탁/교육/지출보고 관련 업무 기준 제시
결정 사항
1. 재위탁 통보관리 화면 구조
- 초기에는 제약사별 드롭다운 선택 후 하위 CSO 조회 방식으로 구상했으나, 실제 운영상 계약 관계와 무관한 제약사 데이터도 발생할 수 있어 변경이 필요함.
- 따라서 재위탁 통보관리에서는 제약사 필터 중심 구조를 제거하고:
- 전체 수탁사 리스트를 노출
- 각 건에 제약사 정보가 함께 표시되도록 설계
- 화면에서는:
- 간략 보기와 상세 보기
- 검색, 다운로드
- 최신 정보 조회
- 이력 조회기능이 필요함.
2. 관계구조도 / 상하위 구조 표현
- CSO 기준으로 상위/하위 관계를 조회하는 화면은 유지하되, 용어는 정정 필요:
- 수탁사 = 위탁을 받은 쪽
- 위탁사 = 위탁을 준 쪽
- 구조도는 현재 CSO를 기준으로 위/아래 단계를 조회하는 방식으로 구성.
- 다만, 제약사 기준 집계 화면은 CSO 기준 화면과 목적이 다르므로 별도 CP 메뉴로 분리하는 방향이 적절함.
3. 재위탁 통보 리스트 항목
재위탁 통보 관련 리스트에는 기본적으로 다음 항목을 모두 포함해야 함.
- 신고번호
- 업체명
- 사업자번호
- 대표자
- 소재지
- 통보일자
- 계약 체결일
- 품목 및 수수료
- 계약기간
- 기타
- 통보 대상 사업자
- 제약사
추가로 필요 기능:
- 간략 보기 / 전체 보기
- 검색
- 엑셀 다운로드
- 하위 재위탁처 수 집계 표시
4. 재위탁처 등록·검증 프로세스
- CSO 또는 비직거래처도 재위탁처를 등록할 수 있어야 함.
- 등록 데이터는 즉시 본DB에 반영하지 않고:
- 접수
- 검증
- 승인 또는 반려/수정 요청
- 최종 DB 반영순서로 처리
검증 관련 결정:
- 반려 버튼, 수정 요청 버튼 필요
- 사이트 내 알림만으로는 부족하므로 이메일 알림 병행 필요
- 수신자는 회원가입 시 등록하는 CP 담당자 이메일 기준으로 처리
- CP 담당자 정보는 회원가입 시 필수 등록
5. OCR 활용 방향
- 사업자등록증, 신고증, 교육 수료증 등은 OCR 적용 후보
- 다만 OCR은 보조 수단으로 사용:
- 업로드 시 OCR로 필드 자동 입력
- 사용자가 수정 가능
- 운영 담당자가 최종 검증
- OCR만으로 자동 확정하지 않고, 형식 검증과 사람 검토를 반드시 거침
- 비용 효율을 고려해 모든 서류에 과도하게 OCR 적용하지는 않음
- 정확도가 중요한 영역은 추후 우선순위 재검토
6. 중복 통보 판단 기준
재위탁 통보 중복 여부는 아래 기준으로 검토:
- 위탁측 사업자번호
- 수탁측 사업자번호
- 통보일자
동일 건으로 판단되더라도:
- 무조건 차단하지 않고
- 중복 가능성 안내 후 등록 허용
- 최신 통보일자를 기준으로 현재 값 표시
- 이전 건은 이력 관리
7. 일괄등록 필요
- 재위탁 통보는 현업상 엑셀 일괄 업로드가 많음.
- 따라서 엑셀 업로드 기능이 필요함.
- 과거 자료 제출 요구가 있으므로 최신본만이 아니라 이력 조회도 필수
8. 교육 이수 관리
교육 수료증에서 필요한 주요 필드:
- 발급번호
- 이름
- 생년월일
- 아이디
- 상호명
- 이수일자
- 교육 유형
- 신규교육
- 보수교육
- 유사교육
- 대표자/직원 구분
운영 기준:
- 업로드 가능한 양식은 정해진 수료증 형식만 허용
- 양식이 맞지 않으면 업로드 단계에서 차단 또는 재업로드 요청
- 대표자 수료 여부는 필수 판단 요소
- 직원만 이수하고 대표자가 없으면 해당 연도 미이수 처리
- OCR로 자동 추출하더라도 최종 검증은 담당자가 수행
9. 경제적 이익 보고
견본품 / 영업활동 보고
- 화면 양식은 기존 포털 기준이 아니라 심평원 지출보고서 양식 기준으로 재정렬 필요
- 병의원은 포털에서:
- 병의원명 검색
- 심평원 기준 요양기관번호 선택방식으로 정확도 확보
주요 검증 로직
- 견본품
- 동일 요양기관 + 표준코드 기준 중복 제공 방지 필요
- 제품설명회/영업활동
- 같은 요양기관에 월 4회 초과 불가
- 개별 제공의 경우 1인당 10만원 초과 불가
- 복수 제공 관련 기준은 별도 정리 필요
입력 방식 관련 정리
- 의료인 1명당 1행 입력
- 이름 여러 명을 한 칸에 입력하는 것은 지양
- 영수증은 여러 건 첨부 가능
- 실제 등록 시 같은 영수증을 여러 명에게 복사 적용할 수 있는 방식 검토
개별/복수 구분
- 개별: 하나의 요양기관 기준
- 복수: 여러 기관 대상 설명회
- 현재는 복수 케이스 활성화가 제한적이지만, 향후 대비해 구조는 고려
10. CP 점검 이력 분리
기존에는 하나의 점검 항목처럼 봤지만 실제로는 성격이 다름.
- 월간 교육
- 교육 내용을 확인했는지 여부 중심
- 사실상 확인 여부 기록
- 분기 모니터링
- 항목별 Yes/No 체크
- 내부 검토 의견 메모 필요
- 문항 변경 가능성 및 문항 이력 관리 필요
따라서 화면도 분리:
- 월간 교육
- 분기 모니터링
11. 면담 이력
- 면담 이력 메뉴는 유지 여부 미확정
- 기존 면담 항목 중 일부는 기본정보로 이동하는 것이 적절
- 대표자 연령/성향
- 제약사 경력
- CSO 경력
- 주거래 제약사/병의원 등
- 면담 이력 메뉴 자체는 삭제 또는 축소 가능성이 있으며, 추후 셀트리온 협의 후 재확정
12. 회원가입 및 계정 체계
회원가입 시 필수 정보
- CP 담당자 정보 필수
- 기본 연락처 정보 필수
- 필요 시 여러 역할을 한 사람이 겸할 수 있음
계정 구조
- 기본 원칙:
- 메인 계정 1개
- 서브 계정 여러 개 가능
- 메인 계정:
- 전체 권한
- 서브 계정:
- 제한 권한
- 예: 공지, CP 관련 제출 기능 등
- 수수료/매출 등 민감 정보는 제한
역할 처리
- 한 사용자가 정산/CP/영업 역할을 동시에 가질 수 있음
- 따라서 구조는:
- 사람(이메일) 기준 등록
- 그 위에 복수 역할 부여방식이 적절
13. 비회원/비직거래처 처리
- 직거래처가 아닌 업체도 재위탁 관련 업무 때문에 시스템 접근 필요
- 이 경우에도:
- 사업자번호 기반 식별
- 제한된 권한으로 로그인
- 재위탁 통보, 교육자료 제출, 공지 확인정도는 가능해야 함
14. 계약 만료/해지 기준
- 본계약은 일반적인 의미의 정기 만료 개념이 약함
- 별도 해지 통보가 없으면 사실상 유지
- 대신 운영상 중요한 것은:
- 자료 미제출/거래 미발생 업체 식별
- 기준:
- 6개월간 EDI 등 자료 미발생 시 종료 대상
- 따라서 대시보드의 “계약 만료 임박”보다는:
- 해지 대상처
- 자료 미제출 장기 업체같은 개념이 더 적합
15. 신규 계약처 기준
- “신규 계약처” 판단 기준은 시스템 등록일이 아니라 실제 계약 완료일
- 계약서 상 기재일보다,
- 모두사인 서명 완료일기준이 적절함
16. 계약서·부속계약서·버전 관리
- 계약 구조:
- 본계약서
- 제약사별 부속합의서
- 제약사별 부속합의서는:
- 최초 계약 시 본계약서와 함께 발송될 수 있고
- 이후 특정 제약사 추가 시 해당 부속합의서만 별도 발송 가능
운영상 중요한 사항:
- 계약서 조합과 버전이 매우 많아짐
- 현재는 문서명 규칙과 엑셀로 관리 중
- 시스템화 필요는 있으나, 이번 범위에서 어디까지 구현할지는 추가 검토 필요
우선 방향:
- 당장은 문서명 보관 및 노출
- 계약 상세에서 부속합의서 리스트 확인 가능
- 장기적으로는 템플릿/조합/버전 관리 체계 필요
17. 모두사인 연동 방향
연동 대상은 주로:
- 본계약서
- 제약사별 부속합의서
통보서는 모두사인 대상이 아니라:
- 계약 정보 기반으로 자동 생성되는 문서
연동 시 기대 흐름:
- 시스템 데이터로 템플릿 변수 채움
- 계약서 발송
- 서명 완료 값 회수
- 제약사별 계약 데이터 반영
- 통보서 자동 생성에 활용
다만 실제 구현 범위는 복잡도가 높아 추가 설계 필요
18. 은행 정보
- 은행명은 드롭다운 제공 가능
- 다만 은행/증권사 종류가 매우 많아:
- 우선 일반적으로 많이 쓰는 은행 중심 제공
- 필요 시 추가 요청으로 확장
- 기존 데이터 마이그레이션 시 표기 통일 필요
19. 가등록
가등록은 다음 상황을 위한 기능으로 이해함.
- 국세청/심평원 조회가 안 되는 신규 사업자
- 매출자료 업로드 시 거래처 유형이 아직 불명확한 경우
가등록 최소 필드:
- 명칭
- 주소
- 사업자번호
임시저장과는 다른 개념이며, 필수 기능은 아니지만 있으면 유용함.
20. 담당자 보기 기본값
- 기본 조회는 내 담당만 보기
- 다만 임원/부서장 등 담당 개념이 없는 사용자는 불편 가능
- 마스터 권한이 제거된 상황이므로, 계정 설정 차원에서:
- 특정 사용자는 전체 보기 기본값으로 저장하는 방식 검토
21. CSO-도매-신성 코드 연결
- 도매와 CSO를 연결하는 구조 외에,
- 도매 측에는 신성 코드와의 연결도 필요
- 문제는:
- 유통관리 기준 코드
- 매출자료 처리 기준 코드 가 다를 수 있다는 점
- 당장 명확한 자동화 규칙은 없으므로:
- 우선 사업자번호 기준 매칭
- 필요 시 신성 코드 연결 테이블에서 수동 관리
- 정보 동기화 방식은 추가 검토 필요
액션 아이템
업무 측
- 심평원 지출보고서 양식 전달
- 교육 수료증 샘플 및 교육 유형별 양식 재공유
- 재위탁 통보서 법정 양식 전달
- 면담 이력 유지 여부 및 기본정보 이동 항목 확정
- 복수 설명회 기준/금액 제한 추가 정리
- 계약서/부속합의서 버전 관리 방식 내부 검토 후 추가 설명
- 신성 코드 연계 및 정보 동기화 규칙 추가 정리
기획/개발 측
- 재위탁 통보관리 화면을 제약사 필터 중심 구조에서 전체 리스트 구조로 수정
- 월간 교육 / 분기 모니터링 화면 분리안 반영
- 반려/수정 요청 프로세스 UI 설계
- OCR 적용 범위와 검증 방식 초안 정리
- 계정/권한 구조를 메인·서브 계정 기준으로 재정리
- 대시보드 항목명을 만료 중심에서 해지 대상 중심으로 재검토
- 계약/통보/교육 관련 추가 질문은 슬랙으로 후속 정리
논의 포인트
재위탁 통보관리에서 남은 쟁점
- 제약사 기준 집계 화면과 CSO 기준 운영 화면의 최종 분리 방식
- 하위 업체 수 집계의 표시 위치
- 최신 데이터와 이력 데이터의 노출 방식
계약서 관리에서 남은 쟁점
- 부속합의서 조합/버전의 시스템화 범위
- 모두사인 연동 후 자동 분리/저장 범위
- 문서명만으로 우선 운영할지, 별도 관리 테이블을 도입할지
OCR 관련 남은 쟁점
- 실제 적용 문서 범위
- 비용 대비 효과
- 입력 자동화 수준과 검증 강도
사용자 경험(UX) 관련
- 월간 교육은 길게 노출하면 잘 읽지 않으므로
- 섹션 분리
- 단계별 확인
- 최종 확인 차단 방식 검토
- 다만 기록 저장은 최종 확인 여부 중심으로 단순화 가능
이번 회의의 핵심은 CSO/CP 운영 로직을 화면 중심이 아니라 실제 업무 흐름 중심으로 다시 정리한 것이다. 특히 재위탁 통보, 교육 이수, 지출보고, 계약 연동은 단순 리스트 구현이 아니라 검증·이력·권한·예외 처리까지 함께 설계해야 한다는 점이 확인됐다.