260617 메딕스 내부 제약사 관리 디자인 리뷰
2026년 6월 17일 공유
제약사 정보 관리: 제약사명(내부 명칭 우선 표시, 없을 시 정식 명칭 사용 - 정식 명칭 입력 시 내부 명칭 자동 생성/입력 로직 포함, 필요 시 별도 수정 가능 - 단, 자동 생성된 내부 명칭을 사용자가 직접 수정할 수 있는 기능 포함), 사업자 번호(중복 확인 및 코넷을 통한 진위 확인 포함), 대표자명, 연락처(데이터가 비어있을 경우 타입으로 표시, 수정 모드 시 입력란 제공), 주소, 코드(수정 시 비활성화), 소유기 중, 소액 기준(내부 메모용, 제약사마다 기준이 상이하여 필터링이나 검색 조건에서는 제외), 상태(활성/비활성), 담당자 번호, 용품 정보 (수정 모드 시 코드 등 주요 정보 비활성화 통일), 공통내용 포함. 라벨링은 '내부 명칭'으로 통일하며, 이는 약국 등 타 항목에도 동일하게 적용. 명칭 관련하여 내부 명칭, 정식 명칭, 디스플레이 네임 등 세 가지 명칭 필드 처리에 대한 검토가 필요함. 디스플레이 네임은 평균적으로 사용되며, 내부 명칭과 정식 명칭을 포함한 3가지 명칭 필드를 모두 제공하는 방향으로 논의됨. 명칭 필드 사용 시 별도의 복잡한 로직 없이, 필요에 따라 내부 명칭이나 정식 명칭 필드를 선택하여 노출하는 방식으로 구현하기로 함. 제약사 등록 시 정식 명칭과 내부 명칭을 함께 입력하도록 구성함.
메뉴 담당자: 제약사 직원 (CP 담당자 1명 필수 지정, 주담당/부담당 영업팀 관리자 지정), 거래처 직원 정보 포함, 계정 생성 및 중복 확인 기능 필요. 제약사 직원 역할은 CSO와 동일하게 통일(대표자, 영업, 정관시, 피해 등 4개 역할 정의 및 드롭다운 선택 방식). 한 사람이 2개 이상의 역할을 수행할 수 있도록 구현하며, 이에 따라 정산 및 지급 관리 업무가 가능하도록 함. 거래처 직원 또한 CSO와 동일한 역할 체계를 적용함. 이메일 수정 기능은 비활성화. 담당자 변경 이력 관리를 위해 수정 모드에서 비고 입력란 필요. 내부 담당자 필터링 기능을 통해 특정 담당자가 관리하는 실수원(거래처)을 조회할 수 있도록 구현할 예정. 검색 결과 리스트에서 CP 담당자가 한 명으로만 표시되는 현상에 대해, CP 담당자 정보가 누락 없이 모두 포함되도록 개선 논의함. CP 담당자와 주담당/부담당(EDI 담당자)은 목적이 다르므로 구분하여 관리할 필요가 있음. CP 담당자는 CP 업무만 수행하며, 주담당/부담당(EDI 담당자)은 ECSO가 EDI에 올린 건에 대해 정산 및 지급을 관리하는 역할을 수행함. 이러한 구분은 EDI부터 지급 관리까지의 업무 목적을 위해 필요함. 담당자 지정 수에 대해서는 제한을 두지 않는 방향으로 논의됨. CP 담당자의 경우 별도 등록 없이 사용하며, 향후 CP 담당자가 2명 이상으로 늘어날 가능성을 고려하여 제너럴하게 구현할 예정임. 계정 관리와 관련하여 한 사람에게 메인 계정을 지정할 수 있으며, 메인은 업체당 1명만 가능하고 나머지는 서브 계정으로 처리함. 메인/서브 계정 여부에 따라 향후 기능 접근 권한이나 화면 구성이 달라질 수 있으므로, 계정 구분 정보를 관리할 필요가 있음. 내부 담당자 역할과 관련하여, 주담당은 영업팀이, 부담당(서브)은 관리팀이 수행하며, 연결 업체는 도매업체만 연결하고 약국은 연결하지 않기로 함.
(참고: 기능 구현 방식 및 고객 확인 절차에 대해 추가 논의 필요. 리스트 항목 구성은 우선 기본안으로 진행하되, 추후 고객 요청에 따라 필요 항목을 추가하는 방식으로 유연하게 대응하기로 함. 또한, 고객사 요구사항에 따라 리스트 표시 항목이 변경될 수 있음을 인지하고 유연하게 대응할 예정임. 신선(신선) 항목의 리스트 추가 및 연결 여부에 대한 확인이 필요함. 엑셀 다운로드 기능은 현재 구현하지 않기로 함. 제약사 관련 통보 사항 구현은 현업 요구사항 검토 결과 제외하기로 함. 향후 품목 관리 기능에 대한 논의가 필요함. 이번 주 목표로 거래처 관리, 품목, 마스터 데이터(마스터 룩) 구축을 우선 완료하기로 함. 개발 우선순위와 관련하여, 병영업보다 제약사 관리를 우선적으로 개발하기로 함. 현재 기획서 작성이 시급한 상황으로, 기획서가 조속히 준비되어야 함. 상세 페이지 내 등록 기능과 관련하여, 상세 페이지 진입 시 등록된 정보가 표시되도록 구현할 예정임. 데이터 등록 시 필요한 8개 필드는 고정 항목으로 구성하며, 등록 화면에서 해당 필드들을 각각 입력할 수 있도록 구현할 예정임. 필드명 등 세부 구성은 등록 시 함께 작성하도록 하는 방안을 검토 중임. 매출 자료 업무 시에도 등록 화면에서 필드명을 함께 작성하는 방식을 적용하기로 함. 대학선(대학선) 기능은 별도 로직 없이 내부 확인 및 관리용으로, 등록, 업로드, 삭제 기능만 구현하기로 함. 도매업체 위성코드 관련해서는 아직 논의된 바 없으므로 추후 검토가 필요함. 조매(조매) 관련 기능은 논의된 바 없으며, 향후에도 구현하지 않기로 함. 조매 기능은 필요성이 낮아 구현하지 않기로 최종 확인됨. SRS 내 도매업자 관련 내용 부재 확인 필요. CSO 약국 폐업 관련하여 이전 코드로 반대 처리 가능 여부 검토 필요.)
기능 구현 우선순위: 제약사 통화 검색 기능부터 개발 시작. 제약사 리스트 화면에 '코드' 및 '웹코드(세상코드)' 항목 추가 필요. 상세 검색 필터에 '상태(활성/비활성/미스트)' 항목을 포함하고, 검색어 입력란과 필터 화면을 구성할 예정. 리스트 항목 및 구성에 대한 구체적인 정의를 진행할 예정임. 리스트 항목은 기존에 정의된 데이터 필드들을 기반으로 구성할 것. 추가로 CSO, 약국, 제약사를 아우르는 통합 검색 기능 구현을 논의함. 통합 검색 대상 항목으로 코드, 제약사명(정식 명칭 및 내부 명칭 포함), 사업자번호, 대표자명을 포함할 예정임. 검색 필터에서도 동일하게 코드, 제약사명(정식 명칭 및 내부 명칭 포함), 사업자번호, 대표자명, 연락처, 담당자, 지역, 구형구정 정보를 모두 검색할 수 있도록 구성할 예정임. 통합 검색(인풋 기반)과 하단 필터는 별도 기능으로 구분하여 구현할 예정이며, 필터는 인풋으로 담기 어려운 다중 조건 검색 등을 위해 별도로 구성함. 또한, 필터 내 다중 선택 기능 구현이 필요함. 제약사명 검색 시 정식 명칭과 내부 명칭을 함께 고려하여 검색되도록 구현할 예정임. 추가로 CS(고객 서비스) 관련 필드 처리 및 표시 방식에 대한 검토가 필요하며, 특히 CS 이력 파악을 위한 검색 ID 체계 및 디스플레이 네임 처리 방안을 구체화해야 함. CSO 관리 필터 항목으로 담당자, 상태(운영 상태), 담당자 블랙리스트, 지역을 포함하기로 함. 리스트는 17개씩 불러오는 방식으로 구현 예정. 담당자 검색 기능과 관련하여, 담당자 이름 입력 시 해당 담당자가 관리하는 리스트를 조회하는 방식에 대해 논의 중이며, 이는 단순 초성 검색이나 필터 연계와는 다른 방식으로 구현될 필요가 있음. 통합 검색과 필터는 사실상 같은 기능으로 간주하며, 필터는 특정 필드에 대한 다중 조건 검색 등을 위해 별도로 구성함. 통합 검색 기능은 더 디테일하게 조회할 수 있도록 고도화가 필요하며, 필터는 다중 조건 검색을 지원하는 방향으로 구성할 예정임. UI 구성과 관련하여, 통합 검색 탭을 상시 노출하기 어려운 공간적 제약을 고려하여, 검색 영역을 접고 펼칠 수 있는 형태로 구현할 필요가 있음. 필터 항목에는 상태, 코드, CSO 정보 등이 포함될 예정임. 검색 항목 구성 시 CS5 필드를 제외하고 정식 명칭과 내부 명칭을 모두 포함하기로 함. 거래처 블랙리스트 여부는 별도 필드로 존재하므로 CSO 관리 필터 항목에서 제외함. (참고: '-땐' 항목은 제외하기로 함, 코어넷 정보는 참고하지 않음) 모바일 환경(폰)에서는 리스트 항목이 모두 노출되도록 구현할 예정임. 엑셀 기능과 관련하여 리스트 엑셀 다운로드와 엑셀 업로드를 위한 템플릿 다운로드를 구분하여 구현할 예정이며, 검색 영역을 접었을 때 엑셀 다운로드와 등록 기능을 우선적으로 노출하기로 함. 검색 영역 UI와 관련하여, 기본적으로는 검색 영역을 접었을 때 한 줄만 노출하는 것을 고려 중이나, 필요에 따라 전체 항목을 보여주는 등 유연하게 대응할 수 있도록 구현할 예정임. 일별 시정(필터링) 기능은 '상태' 항목으로만 제한적으로 구현하기로 함. 통합 검색 및 필터 검색 대상 항목으로 코드, 제약사명(정식/내부), 사업자번호, 대표자명, 상태를 포함하여 구성함. 도매업체 검색 시에도 동일하게 코드, 정식 명칭, 내부 명칭, 대표자명, 사업자 번호를 포함하여 구성할 예정임. 외부코드 항목에는 CSO 정보를 포함하여 관리하며, 다오바이오, 도매업체, 나우메리컬, CSO 등을 통합하여 외부코드 필드에 CSO 정보를 매핑하여 관리하기로 함.
도매 매출 자료 업로드 기능과 관련하여, 현업에서는 도매 매출 자료를 업로드하는 방식을 원하고 있으며, 단순히 등록 여부만 확인하는 것이 아니라 실제 자료 업로드가 이루어지도록 구현할 예정임. 이와 관련하여 매출 자료 항목에 '매출일자', '약국명', '사업자 등록번호', '주소', '표준 코드', '제품명', '주겨방울', '수량', '해설종원'을 포함하기로 함. (금액 항목은 제외). 또한, 도매 매출 자료 등록 시 '상태', '코드', '도매업체명' 대신 '정식명칭', '내부명칭'을 사용하고, '사업자 번호', '대표자명', '연락처' 항목을 필수적으로 포함하기로 함. 한편, 도매 매출 자료에 대한 인정법(인정 방식) 적용 여부를 논의하였으나, 현 단계에서는 필요 없는 것으로 결론 내림.
CSO 관리: 리스트 항목으로 사업자명, 대표자명, 코드, 상태, 담당자, 관련 지역, 블랙리스트 여부, 등록일, 연락처, 주소를 포함함. CSO 리스트에도 등록일 항목을 추가하여 관리하기로 함. CSO 기초 정보 항목으로 대표자, 연령, 제약사 경력, CSO 경력, 주요 경력 등을 추가하기로 함. CSO 기초 정보 테이블은 한 줄에 두 개씩 필드를 배치하는 구성으로 구현할 예정임. 금일(회의 당일) CSO 관련 개발 착수를 위한 논의를 진행함. CS1 관련 논의가 이어짐. 또한, EDI 자료가 5개월 이상 없는 CSO를 별도로 표시하는 기능을 구현하기로 함(6개월 경과 시 해지 기준이므로, 5개월 미입력 시 사전 알림 및 표시 목적). CSO 수정 기능에 대한 보완이 필요하며, 계약 해지 관련 프로세스 및 모니터링 기능(EDI 자료 미입력 건 등)을 포함하여 관리하기로 함. 특히 월간 모니터링과 분기 교육을 체크리스트 형태로 관리하며, 월간 모니터링은 확인 위주로 진행함. 월간 모니터링 체크리스트는 확인 시 'Yes'로 표시하며, 분기 단위 교육 체크리스트는 항목별로 'Yes'를 선택할 수 있도록 구현함. 분기별 교육 체크리스트 질문지는 분기마다 생성하여 관리하며, 항목별로 선택 및 예약이 가능하도록 구현할 예정임. 협력사 관리 메뉴 내 CP 담당자(CP) 페이지에서 분기별 질문지를 관리할 수 있는 기능을 구현하며, 특정 분기에 어떤 질문이 포함되어 있는지 상세히 조회할 수 있도록 구성함. 또한, 분기별 교육 체크리스트는 분기별로 생성 및 관리하며, 질문지 생성 시 특정 분기에 포함된 질문 내용을 상세히 조회하고 수정할 수 있는 기능을 포함함. 본계약서 및 부속계약서 업로드 방식에 대해 논의함. 계약서 내 이름 등 주요 정보를 변수 처리하여 관리하고, 단순 업로드가 아닌 계약서 발송 및 등록 프로세스에 대해, 4개 계약서 업로드 후 발송 확인 버튼을 누르면 시스템에 저장된 변수 정보를 바탕으로 이메일이 자동 발송되도록 구현하기로 함. 계약서 관리와 관련하여, 현재 계약서 검색 기능이 부족하다다는 점이 지적되었으며, 계약서별로 세부 항목을 관리하고 검색할 수 있도록 개선이 필요함. 계약서 파일은 PDF 한 파일로 통합하여 관리하며, 페이지별로 구분하여 처리하는 방식을 논의함. 계약서 관리 효율화를 위해 여러 계약서를 개별적으로 처리하지 않고 PDF로 변환하여 통합 관리하는 방식을 채택함. 계약서 조합별(공급 제약사 포함 여부, 수급 제약사 포함 여부 등)로 구분하여 관리하는 방안을 논의함. 계약서 관리 시 조합, 버전(예: V3.0, 5.0.4.2 등), 관리 월, 문서명 등을 변수로 설정하여 관리할 예정임. 계약서 발송 시 사용할 템플릿을 선택하는 기능을 포함하며, 템플릿 선택 시 시스템에 저장된 변수 정보를 자동으로 매핑하여 정보를 채워 넣는 방식으로 구현하기로 함. 계약서 발송 프로세스는 본계약서, 제약사 계약서 1, 제약사 계약서 2 등을 선택하여 조합하고, 이를 PDF로 통합하여 대표자에게 발송하는 방식으로 구현하기로 함. 계약서별로 계약 기간이 상이하므로, 계약서 관리 시 계약 기간 정보를 포함하여 관리하기로 함. 또한, 시스템 내 데이터 관리와 관련하여, 상태가 불분명하거나 파악이 어려운 데이터(낙독, 동의 여부 등)에 대한 처리 및 관리 방안에 대해 추가 검토가 필요함. 낙독(데이터)은 도매업체 항목으로 통합하여 관리하고, 약국 등에서 사업자 정보와 주소만 존재하는 경우에도 이를 시스템에 등록하여 관리하기로 함. 계약서 관리 시 제약사 관련 부분에 대해서는 사용자의 요구사항을 유연하게 반영하여 구현하기로 함. 계약서 PDF 관리와 관련하여, API를 통해 PDF 다운로드 URL은 제공되나, PDF를 페이지별로 분할할 수 있는지에 대한 기술적 확인이 필요함. 또한, API 요청을 위한 테스트 계정 확보가 필요하며, 오드사인(OddSign) 측에 문의하여 테스트 계정을 발급받아 A-PES 테스트를 진행할 예정임. 공공 데이터 포털 로그인 계정은 개발 시 법인(거비) 계정을 사용하기로 함. 실제 운영 배포 시에는 고객사 계정을 연결할 예정임. 또한, 계약서 발송 후 반응 여부를 확인하여 회신자를 조회하고, 처리가 불가능한 경우에 대한 대응 방안을 조속히 논의하기로 함. (참고: 오드사인(OddSign) 테스트 계정 발급 및 A-PES 테스트 진행 예정. 계약서 관련 정보는 3가지 종류로 관리하며, 파일명뿐만 아니라 실제 내용 정보가 포함되어야 함. 교육비수증은 보수, 신규, 유사 세 가지 유형으로 구분하여 관리하며, 발급 날짜, 제목(신규명 등), 대상자 구분(대표자/직원 여부) 정보를 포함하여 관리함. 또한, 교육비수증 관리 시 개별 및 복수 유형을 모두 포함하도록 구성할 예정이며, 복수 유형은 현재 법적 제약으로 사용이 불가하나 향후를 대비해 테이블을 별도로 구성하기로 함. 복수 유형 교육비수증은 현재 법적 제약으로 사용이 불가하나, 향후 합법화 가능성을 고려하여 기능을 미리 구현해 두기로 함. 추가로, 경복궁 제공 이력 및 영업활동 이력, 지출 관련 필드는 심평원에서 제공하는 최신 규격에 맞춰야 하므로, 기존 레거시 시스템의 필드 구성을 확인하여 심평원 기준에 맞게 업데이트할 예정임. 지출 내역 관리 시, 동일 병원 내 여러 원장에게 지출이 발생할 경우 원장별로 각각 건을 분리하여 관리하며, 10만원 기준은 일 단위 합산으로 적용함. 현장 소프트웨어 연동과 관련하여, 현재 즉시 도입은 어려우며 향후 도입 가능성을 고려하여 검토할 예정임. 또한, 계약서 및 교육비수증 등 작성 시 사용자 편의를 위해 '작성 예시' 기능을 추가하기로 함. 작성 예시 버튼 클릭 시 가이드 팝업이나 캡처본이 노출되도록 구현할 예정임. CSO 기초 정보 항목에 대해서는 추가적인 보완 필요 여부를 검토 중이며, 면담 관련 항목은 삭제될 예정임. CSO 기초 정보 내 그룹은 2세트(총 4개 항목)로 구성하여 구현하기로 함. 교육 체크리스트 관리 시 2016년 1분기(1Q) 등 분기별 데이터 관리 및 조회를 지원함. 분기별 질문지는 질문 내용이 변경될 수 있으므로, 특정 분기의 질문지 데이터를 별도로 관리하여 조회할 수 있도록 구현함. 질문지 구성 시 문항 번호(1, 2, 3, 4, 5, 6 등)는 고정되지 않고 분기마다 달라질 수 있음을 고려하여 유연하게 설계함. 회의 마무리 단계에서 본계약서 및 제약사 계약서 관련 논의를 추가로 진행하기로 함. 계약서 관리 시 '3회차, 4월'과 같은 회차 및 월 정보가 조항과 함께 관리되어야 하며, 현재 세트 계약만 존재하는 상황임. 계약서 조합은 셀트리온, 라켄, 동국대역 등 다양한 조합이 존재하며, 이를 번호별로 구분하여 관리할 수 있도록 구현할 예정임. 또한, 계약서 조합별 숫자 매핑 정보를 현업에서 전달받아 시스템에 저장하여 관리하기로 함. 정보 업데이트 시 '취소' 버튼 대신 우측 상단에 'X' 버튼(다이얼로그 형태)을 배치하여 수정을 취소하는 방식으로 구현하기로 함. 추가로, AR(증강현실) 도입 여부에 대해 논의함. 계약서 관리 시 인감 정보는 필수 항목으로 포함하며, 거래처 주요 이메일 정보도 관리할 예정임(별도의 이메일 생성 로직은 없으며, 계정 생성 없이 이름 정보만 표기함). CSO 수정 모드에서 연결된 CSO에 대해 공기화/비공기화 여부를 설정하는 기능을 추가하기로 함.