260622 메딕스 유선미팅 - 대메뉴정리
2026년 6월 22일 공유
메뉴 구조 및 기능 정의 회의 정리
개요
콘텐츠 유형: 회의
- 시스템 메뉴 구조를 확정하기 위해 기존 Word 문서, Notion, 기존 구조도를 함께 검토했다.
- 초기 전달 자료와 최신 요구사항 간 차이가 있어, 이번 회의에서는 세부 화면 확정보다 메뉴 체계 정리를 우선했다.
- 논의 범위는 거래처 관리, 품목 관리, EDI 관리, 도매 매출 자료 관리, 흡수율, 지급관리, 제약사 청구관리, CP 관리, 유통관리, 협력사 포털, 대시보드 전반이었다.
- 일부 항목은 구조만 우선 정리하고, 세부 기능은 후속 회의에서 확정하기로 했다.
참석자 및 역할
개발사 측
- 메뉴 구조 정리 및 화면/기능 설계 방향 제안
- 기존 전달 자료와 최신 요구사항 간 차이 확인
고객사 측
- 실제 업무 흐름 설명
- 메뉴 분류, 운영 방식, 우선순위, 조회 목적 검토
- 코어넷 기준 기능과 신규 시스템 방향 비교 검증
결정 사항
1. 자료 기준 및 진행 방식
- 기존에 전달된 문서는 초기 방향성 검토용 자료로, 현재 요구사항을 충분히 반영하지 못한 상태였다.
- 메뉴 정의는 Notion 정리본과 최근 공유 자료를 기준으로 진행한다.
- 이번 회의의 목표는 메뉴 구조 우선 확정, 세부 기능은 후속 논의로 넘긴다.
2. 거래처 관리
- 거래처 관리의 기본 범주는 다음으로 유지한다.
- CSO
- 도매
- 약국
- 병의원
- 제약사
- 유통관리 쪽에서 논의된 거래처 관련 기능은 별도 거래처 관리 메뉴로 분리하기보다, 도매업체 관리에 통합하는 방향이 적절하다는 의견이 정리됐다.
신성 데이터와 연계되는 거래처 코드, 여신, 계약정보, CSO 연결 등이 도매업체 관리 문맥에 포함될 수 있다.
3. 품목 관리
- 병원별 계약/요율 운영 중 기본 요율이 아닌 예외 적용 품목은 관리 대상이다.
- 다만 이를 별도 대메뉴로 분리하기보다:
- 별도 조회 화면 또는 탭/필터 방식으로 제공하는 방향이 적절하다는 의견이 나왔다.
- 이후 논의 결과, 단순 필터 수준을 넘어 예외 수수료 적용 품목을 모아보는 별도 조회 성격이 필요하다는 쪽으로 정리됐다.
4. EDI 관리
- EDI 관리 하위 메뉴는 우선 다음 3개로 정리됐다.
- 당월 EDI 입력
- 월별 EDI 내역 조회
- 기간별 EDI 내역 조회
기간별 EDI 내역 조회는 실무 입력용이라기보다 추이·분석용 성격이 강해, 향후 레포트 영역으로 이동 가능하다.
- 월별/기간별 조회 모두:
- 정산월 기준 조회
- 처방월 기준 조회가 가능해야 한다.
크로스체크는 별도 메뉴로 두지 않고, 이상값 검증 기능 내부 처리로 정리됐다.
- EDI에서 품목 등록이나 수수료 등록을 직접 하는 것은 아니며, 조회 및 이상값 확인 중심으로 본다.
5. 도매 매출 자료 관리
- 메뉴 구조는 EDI와 유사하게 다음 축으로 정리됐다.
- 도매 매출 입력
- 월별 도매 매출 조회
- 기간별 도매 매출 조회
- 단, EDI와 달리 도매 매출은 업무 흐름이 더 복잡하다.
- 메일/파일로 받은 엑셀 자료를 우선 적재
- 도매업체 단위 1차 검증
- 전체 도매 자료를 모아 2차 검증
- 따라서 기능 역할은 다음과 같이 구분된다.
도매 매출 입력
- 기본적인 파일 업로드 기능은 필요하다.
- 자동 수집이 주가 되더라도, 예외 상황 대응을 위해 수동 업로드 기능은 유지한다.
- 입력 단계에서는:
- 최소한의 형식 오류
- 명백한 이상값
- 기본 정보 누락 정도의 1차 검증 및 일부 수정 기능이 필요하다.
- 세부 내역 전체를 모두 노출하기보다, 이상값만 필터링해서 보여주는 방식이 적절하다.
월별 도매 매출 조회
- 도매업체 구분을 넘어서 당월 전체 자료를 모아 보는 화면이 필요하다.
- 여기서:
- 누락 여부
- 중복 여부
- 메인 매출과의 비교
- 업체 간/파일 간 검증 같은 2차 검증을 수행한다.
- 수정 기능도 이 화면에서 빈번하게 발생할 수 있다.
기간별 도매 매출 조회
- 추이 분석 및 다양한 조합 조회가 목적이다.
- 단순 월별 조회가 아니라:
- 거래처
- 병원
- 제품
- 제약사
- CSO 등의 다양한 축으로 보고 싶다는 요구가 있었다.
- 다만 이 부분은 엑셀 피벗테이블 수준의 자유도를 원하고 있어, 실제 구현 가능 범위는 추가 정의가 필요하다.
- 우선 메뉴는 유지하되, 구체 조합 및 결과 컬럼 정의는 후속 작업으로 남겼다.
6. 흡수율 관리
- 흡수율은 기본적으로 병원별 조회가 메인이다.
- 제품별, CSO별 등은 운영상 필요하지만, 성격상 레포트에 가까운 조회로 보는 의견이 나왔다.
- 미연계 데이터 관리도 흡수율과 연결된다.
미연계 데이터
- 병원-약국 매칭 과정에서 연계되지 않는 병원/약국 데이터가 발생할 수 있다.
- 이 중:
- 미연계 병원은 병원별 흡수율 조회 등에서 드러날 가능성이 있어 별도 분리 필요성이 낮다.
- 미연계 약국 리스트는 별도 조회 필요성이 있다.
- 미연계 약국 조회 시 필요한 정보:
- 약국
- 월별 제품
- 매출액
- 관련 도매 정보
7. 지급관리
- 기존에 기능 목록이 혼재되어 있었으나, 메뉴 관점에서는 단순화가 필요하다는 방향으로 정리됐다.
- 핵심 흐름은 다음과 같다.
- 수수료/인센티브 산출
- 정산 결과 확인
- 세금계산서 발행 여부 관리
- 지급 완료 여부 관리
지급관리 내부 핵심 기능
- 정산 수수료 계산
- 정산 결과 조회
- 세금계산서 발행/미발행 관리
- 지급 여부 확인
- 알림톡 발송 연계
알림톡 관련
- 세금계산서 발행 요청, 미발행 재알림, 수정 요청 등은 알림톡 연계 대상이다.
- 알림톡은 외부 서비스 연동이 필요하며, 템플릿 유형별 사전 승인/심사 이슈가 있다.
- 기존 템플릿 구조와의 정합성도 고려해야 한다.
8. 제약사 청구관리
- 지급관리와 별도 메뉴로 분리하는 것이 적절하다고 정리됐다.
- 이유:
- 지급관리는 CSO에 돈을 지급하는 프로세스
- 제약사 청구관리는 제약사로부터 돈을 청구·수취하는 프로세스
- 하위 메뉴 방향:
- 당월 제약사별 청구 금액 조회
- 수익 조회
수익 조회 개념
- 단순 청구 금액 누적이 아니라:
- 청구한 금액
- 실제 받은 금액
- 지급한 금액
- 차액
- 최종 수익 을 함께 볼 수 있어야 한다.
- 청구 후 일부 금액을 못 받는 경우까지 관리 대상이다.
9. 인센티브 관리
- 별도 메뉴로 뺄 수도 있으나, 지급관리 안에 포함하는 것도 가능하다고 정리됐다.
- 기능적으로는:
- 인센티브 기준 등록
- 수정/삭제
- 적용기간/대상 설정
- 결과 조회 성격이다.
10. 유통관리
- 기존 영업성과 관리 개념은 유통관리/유통현황으로 재정리됐다.
- 이 중 거래처 관련 내용은 도매업체 관리로 흡수한다.
- 유통관리 자체에서는 우선 유통 이상 분석 성격이 핵심이다.
- 예:
- 신성 데이터 기반 이상 탐지
- 여신 한도 초과 가능성
- 재고/매출 이상 징후
11. 목표관리
- 목표관리는 유통관리 내부보다 전사 공통 메뉴로 두는 편이 적절하다는 의견이 정리됐다.
- 필요 기능:
- 목표 설정
- 달성 여부 시각화
- 시뮬레이션 기능은 필요성이 언급됐지만, 후순위로 분류됐다.
- 시장 용량 등 추가 분석 항목도 후순위다.
12. 협력사 포털 관리
- 협력사 포털 관련 메뉴는 재배치 논의가 있었다.
카탈로그
- 단순히 품목관리 하위로 넣기보다, 우선 협력사 포털 쪽에 두는 것이 적절하다는 방향으로 정리됐다.
- 다만 영업 활용성을 위해, 다른 조회 화면이나 레포트에서 해당 제품 관련 카탈로그를 노출하는 방식은 가능하다.
- 등록/관리는 포털, 조회 연계는 다른 화면에서 하는 구조가 적절하다.
공지/CP 공지
- 단순 게시글만 보면 포털 성격이지만, 실제로는 분기별 CP 모니터링, 교육, 의견 기록과 연결되어 있다.
- 따라서 CP 공지 및 모니터링은 CP 관리 쪽으로 묶는 것이 더 적절하다는 의견으로 정리됐다.
CS 처리
- 협력사 포털을 통해 들어오는 경우도 있지만, 다른 채널 유입도 많아 포털 전용 메뉴로 보기 어렵다는 의견이 나왔다.
- CSO 또는 거래처/레포트 관련 영역에 두는 방안을 추가 검토하기로 했다.
- 최종 위치는 추가 확인 후 확정한다.
13. CP 관리
- CP 관리는 단순히 CSO별 상세를 보는 기능이 아니라, 전체 현황을 모아보고 관리하는 기능이 필요하다.
- 월간/분기별 관리, 교육 이수 여부, 모니터링, 의견 기록 등이 포함된다.
- CSO 내부 정보만 보는 구조가 아니라, 전체 현황 기반 조회가 필요하다는 점이 강조됐다.
- 또한 계약 여부와 EDI 발생 여부를 비교해 추가 계약서 발송이 필요한 대상을 식별하는 기능도 필요하며, 이는 CP보다는 CSO/계약 관리 영역과 더 가까움이 확인됐다.
14. 대시보드
- 초기에는 업무 진행도 등 세부 운영 정보가 포함되어 있었으나, 대시보드는 전반 현황 중심으로 단순화하는 방향으로 봤다.
- 포함 후보:
- 이상값 요약
- 알림센터
- 실적 추이
- 공지사항 노출
- 활성 현황 요약
- 업무 처리 진행도는 메인 대시보드보다는 다른 화면에 배치하는 것이 적절하다는 의견이 나왔다.
- CSO 현황, 병의원 현황, 품목 현황 관련 내용은 별도 현황 탭/화면에서 다룰 예정이다.
액션 아이템
- 개발사
- 이번 회의 내용 기준으로 메뉴 구조 정리본 작성 후 공유
- Figma 업데이트 준비
- 수요일 회의에서 도매업체 / 병의원 / 제약사 관련 디테일 논의 준비
- 고객사
- 공유받은 메뉴 구조안 내부 검토 후 피드백 전달
- 기간별 조회 조합, 레포트 요구, CS 처리 위치, CP 관련 세부 분류 재검토
- 다음 회의 전 필요한 자료 정리
논의 포인트
API 계정 및 테스트 권한
- 테스트 API 사용을 위해 계정 생성 후, 해당 계정에 대해 권한 부여를 요청하는 방식으로 운영된다.
- 원칙적으로 메일을 받은 담당자가 회신하는 구조이나, 개발업체가 직접 계정을 생성하고 회신할 수 있는지 여부는 공급사 확인이 필요하다.
- 테스트 API 사용 기간은 계정 발급 후 약 1개월이다.
구현 시 주의점
- 코어넷에는 메뉴가 세분화되어 있지만, 신규 시스템은 메뉴 수를 줄이고 기능 내 필터/탭으로 해결할지를 계속 검토해야 한다.
- 다만 실무에서는 단순 조회가 아니라 집계 관점 변경, 예외값 추적, 계약/정산 연계 검증이 많아, 너무 단순화하면 오히려 사용성이 떨어질 수 있다.
- 특히 도매 매출, 기간별 조회, 흡수율, CP 전체 현황, 제약사 청구/수익 구조는 업무 로직 이해가 더 필요하다.
이번 회의의 핵심은 화면 확정이 아니라, 업무 흐름에 맞는 메뉴 구조를 먼저 정리하는 것이었다.
최종 메뉴 확정 전까지는 도매 매출 조회 구조, 기간별 분석 구조, CP/포털 기능 분리, CS 처리 위치가 주요 추가 검토 항목이다.