NewERP
고객·영업·재무·재고·운송·무역의 핵심 로직·데이터·API 전면 통합·재구축
← 로드맵 돌아가기CCBIO / 6-MONTH TRANSITION PLAN
업무·데이터 진단부터 통합 구현·검증·운영 전환까지 같은 기준으로 관리합니다.
AX TRANSFORMATION
NewERP·Commerce·AGENT·CMS를 통합해 AI NATIVE 업무 환경을 구축합니다. ERP 핵심 기반을 전면 재구축하고 검증한 데이터·업무 API에 RAG와 담당·팀장 Agent·Orchestrator를 연결합니다.
고객·영업·재무·재고·운송·무역의 핵심 로직·데이터·API 전면 통합·재구축
회원·상품·주문·결제·배송 운영과 ERP 연결
RAG·담당 Agent·팀장 Agent·Orchestrator·CMS Agent
경영관리 · 사양관리 · 자산평가 · ChamFi
재구축 범위· 우선순위 확정
16개 실행 작업구조·업무 기준· API 규격 확정
27개 실행 작업핵심 기능· 공통 API 검증
79개 실행 작업조회부터 실행까지 업무 흐름 검증
24개 실행 작업전환 승인· 확대 여부 판단
18개 실행 작업| 로드맵 항목 | 계획 내용·시점 | 완료·확인 기준 | 관련 WBS |
|---|---|---|---|
| 구성요소NewERP로드맵 26p ↗ | 고객·영업·재무·재고·운송·무역의 핵심 로직·데이터·API 전면 통합·재구축W04–20 | 설계·구현·통합 검증 | |
| 구성요소Commerce로드맵 26p ↗ | 회원·상품·주문·결제·배송 운영과 ERP 연결W04–20 | 설계·구현·통합 검증 | |
| 구성요소AGENT로드맵 26p ↗ | RAG·담당 Agent·팀장 Agent·Orchestrator·CMS AgentW04–20 | 설계·구현·통합 검증 | |
| 구성요소CMS로드맵 26p ↗ | 농가 정보·기록·상담·성장지원의 통합 관리 · 경영관리·사양관리·자산평가·ChamFiW04–20 | 설계·구현·통합 검증 | |
| 전환방법적용 대상 선정로드맵 25p ↗ | 담당자·대표 업무 선정 · 적용 범위·승인 수준 합의 · 성과 기준·목표 설정W03 | 대상·범위·목표 확정 | |
| 전환방법적용 준비·검증로드맵 25p ↗ | 데이터·업무 정확성 확인 · 권한·승인·복구 검수 · 사용자 교육·적용 승인W21–22 | 검수 통과·적용 승인 | |
| 전환방법제한 적용로드맵 25p ↗ | 승인된 담당자부터 사용 · 기존·신규 업무 전환 관리 · 오류·불편·사용 효과 관찰W23 | 실제 사용 결과 확보 | |
| 전환방법안정화·확대 판단로드맵 25p ↗ | 보완 사항 수정·재검증 · 운영 책임·지원 체계 인수 · 확대·보완·보류 결정W24 | 운영 인수·확대 판단 | |
| 리스크 관리범위 확대에 따른 일정·품질 변동 가능성로드맵 24p ↗ | 업무·데이터 기준과 우선순위 확정단계별 검수 | W03 범위·우선순위·담당 역할·검수 기준을 승인하고 변경은 업무·품질 영향과 함께 검토 | |
| 리스크 관리오류데이터로 인한 AI Hallucination 문제 가능성로드맵 24p ↗ | 단계별 검증 후 통합·AI 활용 확대단계별 검수 | 원본·문서 품질을 확인하고 출처·기준일·근거 부족·실시간 값·답변 거절을 평가한 범위만 연결 | |
| 리스크 관리운영 전환 혼선과 현업 활용 저조 가능성로드맵 24p ↗ | 제한 적용·복구 준비·사용 효과 확인단계별 검수 | W22 교육·복구·승인 후 W23 제한 적용, 오류·사용성 관찰과 W24 운영 인수·확대 판단 | |
| 기대효과업무 신뢰성 향상로드맵 26p ↗ | 일관된 데이터와 처리 기준으로 입력·계산·업무 처리 오류 감소W03 기준 합의 · W23–24 확인 | 이전 전후 데이터 일치, 업무 오류·재처리, 계산·상태·권한의 정상·예외 결과 확인 | |
| 기대효과처리 효율 향상로드맵 26p ↗ | 조회·정리·초안 작성 지원으로 반복 업무와 처리 대기 시간 단축W03 기준 합의 · W23–24 확인 | 동일 업무의 처리 시간·수정·재질문·불필요한 개입을 도입 전후 비교 | |
| 기대효과협업 연속성 강화로드맵 26p ↗ | 요청·승인·진행 상태를 연결해 부서 간 전달 누락과 확인 부담 감소W03 기준 합의 · W23–24 확인 | 팀 간 요청 누락·반송·대기, 재시도·인계와 요청자에게 돌아오는 최종 회신 확인 | |
| 기대효과서비스 확장 기반 확보로드맵 26p ↗ | 사업 변화와 새로운 요구에 맞춰 업무 기능과 서비스를 유연하게 확대W03 기준 합의 · W23–24 확인 | 구성요소별 책임·공통 API·권한·변경 영향과 기능 추가 시 재검증·운영 인계 절차 확인 |
실제 담당자에게 권한·전문 설정·업무 맥락을 배정합니다. 11개 전문 능력 중 CMS의 경영관리·사양관리·자산평가·ChamFi는 농가 성장지원 담당에게 함께 배정하며 별도 직원 네 명을 전제하지 않습니다.
| 전문 분야 | 담당 역할 | 달라지는 업무 | 개인별로 구분할 정보 | 연결 작업 |
|---|---|---|---|---|
| 고객·상담 | 고객관리·상담 담당담당 업무·권한 W03 확정 | 고객 정보를 모으고 상담 후속 업무를 준비 | 담당 고객·농가와 상담 이력 | |
| 영업 | 영업 담당담당 업무·권한 W03 확정 | 주문 이력·판매 가능 수량을 확인하고 판매 초안 작성 | 담당 거래처·영업 조건·진행 중인 판매 | |
| 커머스 운영 | 커머스 운영 담당담당 업무·권한 W03 확정 | 주문·배송·환불 문의와 운영 업무를 연결 | 담당 채널·주문·운영 권한 | |
| 재무 | 재무 담당담당 업무·권한 W03 확정 | 입금과 받을 돈을 비교하고 미처리 건 정리 | 담당 거래처·입금·승인 한도 | |
| 재고 | 재고 담당담당 업무·권한 W03 확정 | 가용 수량과 변동 내역을 확인하고 차이 설명 | 담당 창고·품목·조회 기준 시각 | |
| 물류·배차 | 배차·운송 담당담당 업무·권한 W03 확정 | 배송 조건을 확인하고 배차·작업 요청을 준비 | 배정 운송 건·창고·운송사·진행 상태 | |
| 무역 | 무역 담당담당 업무·권한 W03 확정 | 계약·선적·통관 진행과 누락 서류를 확인 | 담당 계약·거래처·선적 서류 | |
| 경영관리 | 농가 성장지원 담당담당 업무·권한 W03 확정 | 수입·지출·구매 기록을 분석해 상담 자료 준비 | 연결 농가·동의 범위·장부 기준일 | |
| 사양관리 | 농가 성장지원 담당담당 업무·권한 W03 확정 | 급여 기록을 확인해 소진 예상과 재주문 상담 지원 | 담당 농가·두수·급여 기준·기록 품질 | |
| 자산평가 | 농가 성장지원 담당담당 업무·권한 W03 확정 | 평가 대상과 근거를 확인하고 자산 현황 설명 | 담당 농가·평가 동의·산식 적용 조건 | |
| ChamFi 상담 | 농가 성장지원 담당담당 업무·권한 W03 확정 | 자금 수요와 동의받은 자료로 상담을 지원 | 배정 상담·동의 정보·허용 제휴 범위 |
전문 분야는 능력 설정의 구분이며 직원 수가 아닙니다. CMS의 경영관리·사양관리·자산평가·ChamFi는 농가 성장지원 담당에게 함께 배정하고, 개인별 권한·대화·업무 맥락을 구분합니다.
| 지표 | 측정 방법 | 현재 기준선 | 목표·판단 기준 | 측정 책임·연결 작업 |
|---|---|---|---|---|
| 업무 처리 시간 | 동일 업무의 요청부터 완료까지 걸린 시간의 중앙값 | W02–03 기존 방식 측정 | W03 업무별 목표 합의 | 업무 책임자·AX 기획 |
| 업무 완료 정확도 | 정답·업무 기준을 만족한 완료 건 / 평가한 업무 건 | 분야별 정상·예외 사례 작성 | W03 분야별 통과 기준 합의 | 전문 분야 담당자·QA |
| 담당자 개입 | 업무당 수정·재질문·수동 보완 횟수와 사유 | 시범 전 동일 업무 비교 | 필수 승인은 유지하고 불필요한 보완 감소 | 업무 책임자·AX 운영 |
| 권한·중복 처리 | 타인 자료 노출·무승인 실행·중복 저장 시험 결과 | 정상·우회·재시도 사례 | 출시 평가에서 위반 0건 · 미달 업무 보류 | 백엔드·QA |
| 응답 시간·비용 | 응답 시간 상위 95% 지점 / 완료 업무당 모델·도구 비용 | W13–16 실측 | W03 예산 상한 정의 후 실측으로 재검토 | AX 개발·운영 |
| 실제 사용·정착 | 배정 담당자 중 주간 사용 인원 / 미사용·중단 사유 | W23 시범 운영 측정 시작 | W03 시범 대상·측정 기간과 목표 합의 | 업무 책임자·AX 운영 |
담당 Agent는 허용된 업무를 직접 처리합니다. 팀장 Agent는 팀 문맥·배분·검토를 담당하고 Orchestrator는 팀 간 요청·상태·체크포인트·실패 재개·회신을 조율합니다. 승인 책임은 사람에게 유지합니다.
상위 항목의 +로 세부 작업을 펼치세요. 작업명·막대를 누르면 담당·선행/병행 관계·산출물·완료 기준이 열립니다.
| 파트 | 전환 단계 / WBS · 실행 작업작업 선택 → 담당·관계·완료 기준 | W01–03 · 업무·데이터 진단 | W04–06 · 통합 구조 설계 | W07–16 · ERP 핵심 재구축 | W17–20 · RAG·Agent 통합 | W21–24 · 검증·운영 전환 | |||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 기획 · QA | 5개 | ||||||||||||||||||||||||
| 기획 | |||||||||||||||||||||||||
| QA | |||||||||||||||||||||||||
| QA | |||||||||||||||||||||||||
| 기획 | |||||||||||||||||||||||||
| 기획 | |||||||||||||||||||||||||
| 개발 · QA · 기획 | 4개 | ||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| QA | |||||||||||||||||||||||||
| 기획 | |||||||||||||||||||||||||
| 기획 | |||||||||||||||||||||||||
| 개발 · 기획 | 3개 | ||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 기획 | |||||||||||||||||||||||||
| 기획 · QA | 4개 | ||||||||||||||||||||||||
| 기획 | |||||||||||||||||||||||||
| QA | |||||||||||||||||||||||||
| 기획 | |||||||||||||||||||||||||
| QA | |||||||||||||||||||||||||
| 개발 | 5개 | ||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 · 디자인 | 6개 | ||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 디자인 | |||||||||||||||||||||||||
| 개발 · 기획 | 5개 | ||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 기획 | |||||||||||||||||||||||||
| 기획 | |||||||||||||||||||||||||
| 개발 · QA | 4개 | ||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| QA | |||||||||||||||||||||||||
| 개발 · 디자인 | 6개 | ||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 디자인 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 기획 | 1개 | ||||||||||||||||||||||||
| 기획 | |||||||||||||||||||||||||
| 개발 · QA | 6개 | ||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| QA | |||||||||||||||||||||||||
| 개발 · QA | 4개 | ||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| QA | |||||||||||||||||||||||||
| 개발 | 5개 | ||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 · QA | 6개 | ||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| QA | |||||||||||||||||||||||||
| 개발 · QA | 7개 | ||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| QA | |||||||||||||||||||||||||
| 개발 | 5개 | ||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | 5개 | ||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | 6개 | ||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 · QA | 5개 | ||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| QA | |||||||||||||||||||||||||
| 개발 · QA | 7개 | ||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| QA | |||||||||||||||||||||||||
| 개발 | 6개 | ||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 · QA | 5개 | ||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| QA | |||||||||||||||||||||||||
| 개발 · QA | 6개 | ||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| QA | |||||||||||||||||||||||||
| 개발 · QA | 4개 | ||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| QA | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| QA · 기획 | 2개 | ||||||||||||||||||||||||
| QA | |||||||||||||||||||||||||
| 기획 | |||||||||||||||||||||||||
| 개발 | 6개 | ||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | 6개 | ||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 · QA | 5개 | ||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| QA | |||||||||||||||||||||||||
| QA | |||||||||||||||||||||||||
| 개발 | 3개 | ||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| QA · 기획 | 4개 | ||||||||||||||||||||||||
| QA | |||||||||||||||||||||||||
| QA | |||||||||||||||||||||||||
| QA | |||||||||||||||||||||||||
| 기획 | |||||||||||||||||||||||||
| 개발 · QA | 4개 | ||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| QA | |||||||||||||||||||||||||
| QA | |||||||||||||||||||||||||
| QA | |||||||||||||||||||||||||
| QA · 개발 | 3개 | ||||||||||||||||||||||||
| QA | |||||||||||||||||||||||||
| QA | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| 운영 · 기획 | 3개 | ||||||||||||||||||||||||
| 운영 | |||||||||||||||||||||||||
| 기획 | |||||||||||||||||||||||||
| 기획 | |||||||||||||||||||||||||
| 운영 · QA · 개발 | 4개 | ||||||||||||||||||||||||
| 운영 | |||||||||||||||||||||||||
| 운영 | |||||||||||||||||||||||||
| QA | |||||||||||||||||||||||||
| 개발 | |||||||||||||||||||||||||
| QA · 운영 · 기획 | 4개 | ||||||||||||||||||||||||
| QA | |||||||||||||||||||||||||
| 운영 | |||||||||||||||||||||||||
| 운영 | |||||||||||||||||||||||||
| 기획 | |||||||||||||||||||||||||
조건에 맞는 작업이 없습니다.
진단 결과·데이터 위험·RAG 자료·담당 역할·검수 기준을 검토하고 구현 범위·우선순위·적용 대상·승인 수준·평가 목표가 승인됨
미충족 업무는 다음 단계의 실행·운영 전환을 보류하고 담당·보완·재검수 일정을 정한다.업무·데이터·API·권한·평가·복구 규격과 구현 우선순위가 승인됨
미충족 업무는 다음 단계의 실행·운영 전환을 보류하고 담당·보완·재검수 일정을 정한다.핵심 기능·공통 API·RAG/Agent 준비 기준을 통과한 범위만 통합에 진입함
미충족 업무는 다음 단계의 실행·운영 전환을 보류하고 담당·보완·재검수 일정을 정한다.데이터 이전 리허설과 현업 검수에 진입할 범위·차단 결함·보류 기능이 확정됨
미충족 업무는 다음 단계의 실행·운영 전환을 보류하고 담당·보완·재검수 일정을 정한다.승인자·범위·전환 순서·복구 기준이 확정되고 미통과 범위는 보류됨
미충족 업무는 다음 단계의 실행·운영 전환을 보류하고 담당·보완·재검수 일정을 정한다.미충족 기능을 완료로 계산하지 않고 검증한 범위의 운영 책임과 다음 조치가 확정됨
미충족 업무는 다음 단계의 실행·운영 전환을 보류하고 담당·보완·재검수 일정을 정한다.메뉴를 눌러 화면을 바꿔보세요. 판매 등록과 담당자별 전문 AI의 초안 연결을 체험할 수 있습니다.
업무 홈 / 영업 담당
| 업무 | 고객·거래처 | 현재 상태 | 다음 행동 |
|---|---|---|---|
| 판매 등록 | 한빛목장 | 주문 접수 | |
| 출고 확인 | 들녘목장 | 재고 확인 필요 | |
| 입금 대조 | 푸른목장 | 입금 확인 대기 |
고객·농가 / 통합 프로필
내부 고객 ID · F-0102 | 충남 예산 · 한우 120두
영업 / 판매 / 신규 작성
F-0102 · 농업경영체 확인
선택한 고객에 판매를 연결합니다. 고객 정보 수정은 프로필에서.
공급가액 기준 예시 · 세금·운임 별도
수량과 배송 요청을 확인해 주세요.
선택한 고객·수량·금액으로 저장할까요?
재무 / 채권·수금
| 입금 내역 | 연결할 채권 | 대조 결과 | 처리 |
|---|---|---|---|
| 한빛목장 · 2,000,000원 | 한빛목장 · 4,000,000원 | 담당자 확인 | 확정 전 |
재고·물류 / 재고 원장·가용량
| 판매·고객 | 수량 | 배송 상태 | 다음 단계 |
|---|---|---|---|
| S-EX01 · 한빛목장 | 10톤 | 배차 대기 | 차량·기사 배정 |
| S-EX02 · 들녘목장 | 5톤 | 배송 완료 | 수령 확인 |
무역 / 국제물류·통관
| 거래처 | 계약 물량 | 입항 | 통관 | 연결 업무 |
|---|---|---|---|---|
| 예시 공급사 A | 200톤 | 도착 확인 | 서류 확인 중 |
Commerce / 커머스 운영
| 주문 | 농가 | 상품·수량 | 상태 | 연결 업무 |
|---|---|---|---|---|
| O-EX01 | 한빛목장 | 배합사료 A · 10톤 | 결제 확인 | |
| O-EX02 | 들녘목장 | 조사료 B · 5톤 | 배송 중 |
SEED 수집 · 검수 · RAG 자료 · 대화 로그
기존 운영 기능 유지 · 필요한 연결 보완
내 담당 고객·주문을 조회하고 업무 초안 작성
영업 담당자 · 나의 Agent
기준정보 / 창고·협력사
| 창고 | 연결 협력사 | 사용 업무 | 상태 |
|---|---|---|---|
| 예시 중앙창고 | 협력사 A | 입고 · 재고 · 출고 | 사용 |
| 예시 보조창고 | 협력사 B | 재고 · 출고 | 사용 |
시스템 / 변경 이력·대사·복구
| 업무 | 처리자 | 결과 | 후속 처리 |
|---|---|---|---|
| 판매 S-EX01 | 예시 담당자 | 처리 완료 | 고객·품목·수량 확인 |
| 배송 D-EX02 | 예시 담당자 | 최신 상태 확인 필요 | 다시 조회 후 처리 |
내 농장 / 농업경영체 확인
배송 5일 + 여유 3일을 고려한 알림 예시
급여량과 두수 변동을 기록하세요.
구매·생산 기록을 수입·지출과 함께 봅니다.
경영관리 / 수입·지출
| 구분 | 내용 | 금액 | 출처 |
|---|---|---|---|
| 지출 | 배합사료 구매 | 4,000,000원 | 커머스 주문 연결 |
| 수입 | 출하 대금 | 12,000,000원 | 직접 기록 |
| 지출 | 기타 농장 운영비 | 4,500,000원 | 직접 기록 |
사양관리 / 급여·사양 기록
| 대상 | 사료 | 급여량 | 기록 상태 |
|---|---|---|---|
| 한빛목장 사육군 | 배합사료 A | 360kg | 기록 완료 |
자산평가 / 가축·시설
| 종류 | 자산 | 수량 | 평가 상태 |
|---|---|---|---|
| 가축 | 한우 사육군 | 120두 | 평가 자료 확인 |
| 시설 | 축사 A동 | 1동 | 등록 완료 |
| 장비 | 급이기 | 2대 | 등록 완료 |
ChamFi / 상담·연계
커머스 / 재주문
최근 구매 · 배합사료
최근 주문 10톤 · 현재 잔량 약 2.9톤
400,000원 / 톤가상 가격 · 세금·운임 별도
업무 홈 · 담당자의 할 일에서 고객·판매·재고로 바로 이동합니다.
이 화면의 개발 범위 보기 →수량·금액·고객은 설명용 예시입니다. 입력·저장은 이 미리보기 안에서만 동작하며 새로 열면 초기화됩니다.
각 업무의 현재 방식과 앞으로 사용할 방식을 나란히 설명합니다. 아래에는 바꾸는 이유와 확인이 필요한 점을 적었습니다.
‘개선 후’는 앞으로 만들 기능입니다. 현재 상태는 코드·일부 시험·사용자 설명으로 확인했으며, 실제 사용 현황을 더 확인해야 하는 항목은 따로 표시했습니다.
ERP 전면 재구축업무 틀을 계승하고 데이터·로직·공통 API를 새로 만듭니다.
RAG·담당·팀장·Orchestrator문서 근거·실시간 도구·승인·팀 간 협업을 연결합니다.
사용하지 않는 구메뉴왼쪽 메뉴 목록에서 숨깁니다.
홈, 영업, 고객, 상담 현황을 각각 다른 화면에서 확인합니다.
첫 화면에서 내 담당 업무의 현황과 오늘 할 일, 확인이 필요한 건을 모아 봅니다. 주문·출고·수금 등의 항목을 누르면 해당 업무 화면으로 바로 이동합니다.
각 화면의 숫자가 어떤 자료로 계산됐는지, 확인한 뒤 어느 업무를 처리해야 하는지 정리가 필요합니다.
재고 대시보드 · 고객 현황 · 대시보드 · 홈
→ 업무 홈 / 직무별 현황
//dashboard/sales/dashboard/customers/dashboard/consultations/dashboard업무 틀·필수 양식·검증한 데이터만 계승하고 해당 업무의 핵심 로직·데이터·공통 API·권한·이력을 새 구조로 통합·재구축한다. 신규 API에 업무 화면과 담당 Agent를 연결한다.
담당 업무에 맞는 첫 화면이 뜨는지, 표시된 숫자가 실제 거래 기록과 맞는지 확인합니다. 볼 권한이 없는 정보는 표시하지 않습니다. 새 데이터·공통 API에서 권한·정합성·중복 요청·실패 복구를 검수한다.
각 화면의 숫자가 어떤 자료로 계산됐는지, 확인한 뒤 어느 업무를 처리해야 하는지 정리가 필요합니다.
영업 대시보드 진입점.
ccbio_erp/frontend/app/sales/dashboard/page.tsx:5export default
별도 전체 대시보드 구현이 존재한다.
ccbio_erp/frontend/app/dashboard/page.tsx:176export default
판매를 입력하거나 쇼핑몰 회원 정보를 가져올 때 기존 고객 정보도 바뀔 수 있습니다. 고객 기본 정보와 운영형태는 따로 저장합니다.
판매 등록에서는 고객을 선택만 하고, 이름·주소 등의 수정은 고객 정보 화면에서 합니다. 담당자가 같은 농가인지 확인해 연결하면 회원 정보, 거래·상담 내역, 누가 무엇을 수정했는지를 한곳에서 볼 수 있습니다.
일부 조건에서 다른 고객 정보를 덮어쓰거나 정보의 일부만 저장되는 문제를 시험에서 확인했습니다. 관련 사례는 C01~C03입니다.
고객 관리
→ 고객·농가 / 통합 프로필
/customers업무 틀·필수 양식·검증한 데이터만 계승하고 해당 업무의 핵심 로직·데이터·공통 API·권한·이력을 새 구조로 통합·재구축한다. 신규 API에 업무 화면과 담당 Agent를 연결한다.
전화번호나 사업자번호가 같다는 이유만으로 고객을 자동으로 합치지 않습니다. 농업경영체 증빙을 확인하고, 다른 사람이 먼저 수정한 내용을 덮어쓰지 않는지와 이전한 정보가 원본과 맞는지 점검합니다. 새 데이터·공통 API에서 권한·정합성·중복 요청·실패 복구를 검수한다.
일부 조건에서 다른 고객 정보를 덮어쓰거나 정보의 일부만 저장되는 문제를 시험에서 확인했습니다. 관련 사례는 C01~C03입니다.
회원 동기화의 고객 저장 경로. 일부 오류는 C02·C03에서 격리 재현.
ccbio_erp/backend/src/modules/customers/customers.service.ts:804async syncExternalMallCustomer
판매 저장에서 고객 원장을 갱신하는 경계. C01 사례와 연결.
ccbio_erp/backend/src/modules/sales/sales.service.ts:272async upsertCustomer
상담 내용과 통계를 보는 화면이 있습니다. 상담을 수정할 때 본문을 먼저 저장한 뒤, 기존 상담 품목을 지우고 새 품목을 저장합니다.
고객별로 상담 내용과 연락·활동 내역을 함께 봅니다. 상담 내용과 품목은 모두 저장됐을 때만 완료로 처리하고, 중간에 실패하면 수정 전 상태로 되돌립니다.
품목 저장에 실패했을 때 상담 내용만 바뀌거나 기존 품목이 사라지지 않는지 추가 확인이 필요합니다.
상담 관리 · 상담 통계
→ 고객·농가 / 상담·활동
/consultations/consultations/stats업무 틀·필수 양식·검증한 데이터만 계승하고 해당 업무의 핵심 로직·데이터·공통 API·권한·이력을 새 구조로 통합·재구축한다. 신규 API에 업무 화면과 담당 Agent를 연결한다.
일부 품목 저장이 실패해도 기존 상담이 보존되는지 확인합니다. 일부 내용 수정, 여러 사람의 동시 수정, 삭제 후 복구도 점검합니다. 새 데이터·공통 API에서 권한·정합성·중복 요청·실패 복구를 검수한다.
품목 저장에 실패했을 때 상담 내용만 바뀌거나 기존 품목이 사라지지 않는지 추가 확인이 필요합니다.
상담 본문 저장 후 품목 변경이 이어진다.
ccbio_erp/backend/src/modules/consultations/consultations.service.ts:875await this.consultationRepository.save(consultation);
기존 품목을 제거한 뒤 신규 저장. 이 경로 전체 원자성·실패 복구 검증 필요.
ccbio_erp/backend/src/modules/consultations/consultations.service.ts:1058await this.consultationProductRepository.remove(existingProducts);
표 형태의 견적·예약 화면과 예약을 판매로 넘기는 기능이 있습니다. 예약 수량은 여러 곳에 저장된 자료를 모아 계산합니다.
견적·예약의 업무 틀을 계승하고 예약·가용량·판매 전환을 새 데이터와 API로 구현합니다. 예약 해제·동시 변경·재전송에도 중복 수량이 발생하지 않게 합니다.
예약 수량, 판매로 넘어간 수량, 실제 판매 가능한 수량이 서로 맞는지 먼저 확인해야 합니다. 자료가 여러 곳에 있다는 것만으로 오류가 있다고 판단하지는 않습니다.
판매예약 · 견적서
→ 영업 / 견적·예약
/sales/product-reservations/sales/product-reservations-sheet/sales/quotation-sheet업무 틀·필수 양식·검증한 데이터만 계승하고 해당 업무의 핵심 로직·데이터·공통 API·권한·이력을 새 구조로 통합·재구축한다. 신규 API에 업무 화면과 담당 Agent를 연결한다.
예약 전후와 판매 전환 후의 수량을 실제 자료와 비교합니다. 동시 수정과 재시도 때 수량이 잘못 바뀌지 않는지 확인합니다. 새 데이터·공통 API에서 권한·정합성·중복 요청·실패 복구를 검수한다.
예약 수량, 판매로 넘어간 수량, 실제 판매 가능한 수량이 서로 맞는지 먼저 확인해야 합니다. 자료가 여러 곳에 있다는 것만으로 오류가 있다고 판단하지는 않습니다.
구 예약 메뉴를 숨겨도 페이지와 데이터 경로는 남는다.
ccbio_erp/frontend/components/layout/app-sidebar.tsx:77const SHOW_SALES_RESERVATION_SIDEBAR_MENU = false
시트 예약 집계.
ccbio_erp/backend/src/modules/trade-contracts/trade-contracts.service.ts:4101loadGridSheetReservationTotalsByBlProduct()
구 예약 집계도 별도로 남아 있다.
ccbio_erp/backend/src/modules/trade-contracts/trade-contracts.service.ts:4130loadTbSalesMgmtReservationTotalsByOrder(
행 upsert는 존재한다. 업무 단위 충돌·전환 검증과 구분한다.
ccbio_erp/backend/src/modules/sales-reservation-sheet/sales-reservation-sheet.service.ts:661await this.repo.upsert(payload
판매를 저장할 때 선택한 고객의 기본 정보도 함께 수정하는 처리가 들어 있습니다.
판매는 선택한 고객에게만 등록됩니다. 판매를 수정해도 고객 이름·주소는 바뀌지 않으며, 입력이 잘못됐거나 다른 사람이 먼저 수정했으면 이유를 화면에 알려줍니다.
전화번호를 기준으로 다른 고객을 선택하고 그 정보를 덮어쓰는 조건을 시험에서 확인했습니다. 관련 사례는 C01입니다.
판매관리 (신규) · 판매관리
→ 영업 / 판매
/sales/sales/management-v2/sales/management-v2/sales업무 틀·필수 양식·검증한 데이터만 계승하고 해당 업무의 핵심 로직·데이터·공통 API·권한·이력을 새 구조로 통합·재구축한다. 신규 API에 업무 화면과 담당 Agent를 연결한다.
고객을 바꾸거나 판매 내용을 수정해도 고객 기본 정보가 바뀌지 않는지 확인합니다. 동시 저장, 반복 저장, 일부 취소, 출하 후에도 수량과 금액이 맞는지 점검합니다. 새 데이터·공통 API에서 권한·정합성·중복 요청·실패 복구를 검수한다.
전화번호를 기준으로 다른 고객을 선택하고 그 정보를 덮어쓰는 조건을 시험에서 확인했습니다. 관련 사례는 C01입니다.
판매와 고객 원장 변경의 결합을 분리할 근거.
ccbio_erp/backend/src/modules/sales/sales.service.ts:272async upsertCustomer
명세서의 일부 내용을 바꿔도 저장할 때는 기존 품목 전체를 지우고 다시 만듭니다. 이 과정은 모두 성공하거나 함께 취소되도록 묶여 있습니다.
명세서에서 바꾼 품목만 추가·수정·삭제합니다. 수정하거나 취소한 금액이 수금 내역에도 맞게 반영되도록 하고, 기존 출력 양식은 계산 결과를 확인한 뒤 계속 사용합니다.
품목을 전부 다시 만들 때 기존 품목 번호나 수정 내역이 끊기지 않는지, 여러 사람이 수정해도 문제가 없는지 확인해야 합니다.
거래명세서 관리
→ 영업 / 거래명세서
/sales/invoice-management업무 틀·필수 양식·검증한 데이터만 계승하고 해당 업무의 핵심 로직·데이터·공통 API·권한·이력을 새 구조로 통합·재구축한다. 신규 API에 업무 화면과 담당 Agent를 연결한다.
수정하지 않은 품목의 번호와 이력이 유지되는지 확인합니다. 발행일·부가세·반올림, 중복 발행, 이미 돈을 받은 명세서의 수정·취소도 점검합니다. 새 데이터·공통 API에서 권한·정합성·중복 요청·실패 복구를 검수한다.
품목을 전부 다시 만들 때 기존 품목 번호나 수정 내역이 끊기지 않는지, 여러 사람이 수정해도 문제가 없는지 확인해야 합니다.
수정 경로 시작.
ccbio_erp/backend/src/modules/sales/invoice.service.ts:1374async updateInvoice
트랜잭션 내 품목 전체 교체를 확인. 데이터 유실 재현과는 구분.
ccbio_erp/backend/src/modules/sales/invoice.service.ts:1403await manager.delete(InvoiceItem, { invoiceId: id });거래 한 건의 입금을 처리할 때 받은 돈의 기록과 남은 금액을 따로 저장합니다. 고객별로 모아 처리하는 수금은 다른 저장 방식을 씁니다.
거래처별로 받을 돈, 받은 돈, 미리 받은 돈을 함께 확인합니다. 입금 기록과 남은 금액을 한 번에 반영해 중복 수금을 막고, 월말에도 지급기일이 맞게 계산되도록 합니다.
동시에 입금을 처리하거나 저장 도중 실패하면 기록과 잔액이 어긋나는 문제, 월말 지급기일 계산 문제를 시험에서 확인했습니다. 관련 사례는 C05·C09입니다.
선입금 관리 · 수금 관리 · 이카운트 잔액 비교 · 입금예상액 · 거래처관리대장 · 채권관리 · 채권 경고 문자 발송 이력 · 채권 경고 설정
→ 재무 / 채권·수금·선입금
/finance/prepayments/finance/receivables/finance/receivables/collect/finance/receivables/compare-excel/finance/receivables/expected/finance/receivables/ledger/finance/receivables/sms-batch-history/finance/receivables/warning-config업무 틀·필수 양식·검증한 데이터만 계승하고 해당 업무의 핵심 로직·데이터·공통 API·권한·이력을 새 구조로 통합·재구축한다. 신규 API에 업무 화면과 담당 Agent를 연결한다.
동시 입금, 환불, 선입금 사용 후에도 입금 기록과 남은 금액이 맞는지 확인합니다. 월말 지급기일, 안내 문자, 회계 자료의 금액도 비교합니다. 새 데이터·공통 API에서 권한·정합성·중복 요청·실패 복구를 검수한다.
동시에 입금을 처리하거나 저장 도중 실패하면 기록과 잔액이 어긋나는 문제, 월말 지급기일 계산 문제를 시험에서 확인했습니다. 관련 사례는 C05·C09입니다.
건별 수금 경로. C05는 이 경로의 격리 재현 사례.
ccbio_erp/backend/src/modules/receivables/receivables.service.ts:435async collect(receivableId
고객별 수금에는 별도 트랜잭션 경로가 있다.
ccbio_erp/backend/src/modules/receivables/receivables.service.ts:508async collectByCustomer
계약·발주·선하증권(BL)을 처리하는 기능에 송장 결제와 재고 조정도 함께 들어 있습니다.
계약·발주·선적 서류의 필요한 부분만 수정할 수 있게 합니다. 수정한 내용은 관련 업무에 반영하되, 이미 처리한 결제·재고 기록과 진행 상태는 보존합니다.
계약이나 발주를 수정할 때 결제 내역과 재고까지 잘못 바뀌지 않는지 함께 살펴야 합니다.
계약 · 구매관리 · 발주
→ 무역 / 구매·계약·발주
/trade/management/trade/contract-confirmed/trade/order업무 틀·필수 양식·검증한 데이터만 계승하고 해당 업무의 핵심 로직·데이터·공통 API·권한·이력을 새 구조로 통합·재구축한다. 신규 API에 업무 화면과 담당 Agent를 연결한다.
계약·발주·선적 서류를 일부 수정해도 결제와 재고 이력이 남는지 확인합니다. 중복 발주를 막고, 시스템 전환 당시 진행 중인 계약도 이어서 처리할 수 있어야 합니다. 새 데이터·공통 API에서 권한·정합성·중복 요청·실패 복구를 검수한다.
계약이나 발주를 수정할 때 결제 내역과 재고까지 잘못 바뀌지 않는지 함께 살펴야 합니다.
동일 서비스에 송장 결제 저장이 포함된다.
ccbio_erp/backend/src/modules/trade-contracts/trade-contracts.service.ts:10740async saveInvoice
동일 서비스가 재고 조정까지 담당한다.
ccbio_erp/backend/src/modules/trade-contracts/trade-contracts.service.ts:12120async adjustContainerInventory
선적 예약, 서류, 화물 인도지시서(DO), 통관 화면에서 송장·컨테이너·입고의 진행 상태를 바꿉니다.
선적 예약 → 서류 준비 → 통관 → 입고를 하나의 흐름으로 확인합니다. 현재 단계와 다음 할 일이 보이도록 하고, 도착 예정일과 운임 정보도 확인된 자료를 연결해 보여줍니다.
어느 단계에서 어떤 상태를 바꾸는지 정리가 필요합니다. 서류 저장이나 외부 정보 조회가 실패했을 때 다음 단계에 미치는 영향도 확인해야 합니다.
FT 관리 · 부킹 · 통관 처리 · DO 처리 · 서류 처리 · ETA 정보 갱신 이력 · 물류관리
→ 무역 / 국제물류·통관
/logistics/management/logistics/booking/logistics/documents/logistics/documents-processing/logistics/do-processing/logistics/customs-processing/logistics/eta-update-history/free-time업무 틀·필수 양식·검증한 데이터만 계승하고 해당 업무의 핵심 로직·데이터·공통 API·권한·이력을 새 구조로 통합·재구축한다. 신규 API에 업무 화면과 담당 Agent를 연결한다.
단계를 건너뛰거나 이전 단계로 돌릴 수 있는 담당자를 확인합니다. 서류 저장 실패, 도착 정보 지연, 통관 후 입고가 중복되거나 누락되는 경우도 점검합니다. 새 데이터·공통 API에서 권한·정합성·중복 요청·실패 복구를 검수한다.
어느 단계에서 어떤 상태를 바꾸는지 정리가 필요합니다. 서류 저장이나 외부 정보 조회가 실패했을 때 다음 단계에 미치는 영향도 확인해야 합니다.
통합 물류에서 서류 처리 컴포넌트를 참조한다.
ccbio_erp/frontend/app/logistics/management/page.tsx:46DocumentsProcessing
컨테이너 변경 경로와 연결된다.
ccbio_erp/backend/src/modules/trade-contracts/trade-contracts.service.ts:11451async updateContainer
사용 중인 입고 기능이 있습니다. 새로 만들 예정이었던 일부 화면은 안내만 표시하며 실제 처리 기능은 연결되지 않았습니다.
입고 예정·부분 입고·확정·취소·실수량·증빙을 새 입고 서비스와 화면으로 연결합니다. 재고 원장과 공통 저장 규칙으로 수량·상태를 일치시킵니다.
기존 입고 화면에서 어떤 업무까지 처리하는지 먼저 확인해야 추가로 필요한 기능을 정할 수 있습니다.
입고 확정 · 입고 대기 · 입고 예정
→ 재고·물류 / 입고
/inbound/pending/inbound/scheduled/inbound/confirmed/sales/inbound/pending/sales/inbound/scheduled/sales/inbound/confirmed업무 틀·필수 양식·검증한 데이터만 계승하고 해당 업무의 핵심 로직·데이터·공통 API·권한·이력을 새 구조로 통합·재구축한다. 신규 API에 업무 화면과 담당 Agent를 연결한다.
일부만 입고하거나 취소·재시도해도 창고별 수량이 맞는지 확인합니다. 담당 창고 외에는 처리할 수 없도록 하고, 새 화면은 확정된 필수 기능을 기준으로 점검합니다. 새 데이터·공통 API에서 권한·정합성·중복 요청·실패 복구를 검수한다.
기존 입고 화면에서 어떤 업무까지 처리하는지 먼저 확인해야 추가로 필요한 기능을 정할 수 있습니다.
신규 확정 페이지가 Shell을 사용한다.
ccbio_erp/frontend/app/sales/inbound/confirmed/page.tsx:3SalesInboundV2Shell
준비 중 안내이며 실제 입고 목록·연동 기능 완성과 구분한다.
ccbio_erp/frontend/components/sales/sales-inbound-v2-shell.tsx:41목록·연동 API는 이후 단계에서 붙입니다
재고를 조정할 때 조정용 판매·품목 기록을 저장하고 관련 상태를 여러 단계에 걸쳐 다시 계산합니다.
입출고·예약·이동·조정·원가를 통합 원장과 공통 API로 재구축합니다. 영업·재무·물류 화면과 Agent가 같은 기준 시각의 수량·계산 근거를 확인합니다.
저장 후 계산에 실패해 다시 시도하면 같은 재고가 두 번 줄어드는 조건을 시험에서 확인했습니다. 관련 사례는 C07입니다.
입고확정 · 입고예정 · 입고확정재고 · 재고 관리 · 입고예정재고 · /sales/management-v2/inventory
→ 재고·물류 / 재고 원장·가용량
/inventory/inventory/pending/inventory/confirmed/sales/inventory/pending/sales/inventory/confirmed/sales/management-v2/inventory/finance/inventory-pending/finance/inventory-confirmed업무 틀·필수 양식·검증한 데이터만 계승하고 해당 업무의 핵심 로직·데이터·공통 API·권한·이력을 새 구조로 통합·재구축한다. 신규 API에 업무 화면과 담당 Agent를 연결한다.
처음 재고에 입출고·이동·조정 수량을 반영한 결과가 현재 재고와 맞는지 확인합니다. 예약과 판매의 이중 차감, kg·베일 환산, 원가, 재고 부족 때의 처리 기준도 점검합니다. 새 데이터·공통 API에서 권한·정합성·중복 요청·실패 복구를 검수한다.
저장 후 계산에 실패해 다시 시도하면 같은 재고가 두 번 줄어드는 조건을 시험에서 확인했습니다. 관련 사례는 C07입니다.
재고 조정 명령 경계. C07 재시도 중복 사례와 연결하여 저장·멱등 처리 검증.
ccbio_erp/backend/src/modules/trade-contracts/trade-contracts.service.ts:12120async adjustContainerInventory(
결제 대기·완료 화면이 있습니다. 송장을 저장할 때는 연결된 결제 목록을 새 목록으로 바꿉니다.
한 화면에서 대기·완료 상태를 골라 결제 건을 봅니다. 메모를 고쳐도 기존 결제는 그대로 두고, 결제나 송금 자체를 바꿀 때만 담당 권한과 변경 내역을 확인해 반영합니다.
메모 등 일부 항목만 수정하면서 결제 목록을 보내지 않으면 기존 결제가 지워지는 조건을 시험에서 확인했습니다. 관련 사례는 C04입니다.
결제 완료 · 결제관리 · 결제 대기
→ 재무 / 매입결제·송금
/finance/payment-management/finance/payment-pending/finance/payment-completed업무 틀·필수 양식·검증한 데이터만 계승하고 해당 업무의 핵심 로직·데이터·공통 API·권한·이력을 새 구조로 통합·재구축한다. 신규 API에 업무 화면과 담당 Agent를 연결한다.
결제 내용을 수정하지 않은 경우와 삭제한 경우를 구분하는지 확인합니다. 중복 송금, 환율과 잔액 계산, 증빙을 볼 수 있는 담당자 범위도 점검합니다. 새 데이터·공통 API에서 권한·정합성·중복 요청·실패 복구를 검수한다.
메모 등 일부 항목만 수정하면서 결제 목록을 보내지 않으면 기존 결제가 지워지는 조건을 시험에서 확인했습니다. 관련 사례는 C04입니다.
송장·결제 저장 경계.
ccbio_erp/backend/src/modules/trade-contracts/trade-contracts.service.ts:10740async saveInvoice
통합 결제 화면이 존재한다.
ccbio_erp/frontend/app/finance/payment-management/page.tsx:747export default
운송 내용을 수정할 때 화면을 열었을 당시의 배송 상태도 다시 저장합니다. 관련 처리 중 일부가 실패해도 다음 상태로 넘어가는 경우가 있습니다.
메모를 수정해도 배송 진행 상태는 바뀌지 않습니다. 상태를 바꿀 때는 최신 진행 상황을 확인하고, 상차·하차 등 관련 저장에 실패하면 원래대로 돌리거나 미완료라고 알려줍니다.
오래 열어 둔 화면에서 저장하면 완료된 배송이 이전 상태로 돌아가거나, 복구에 실패해도 성공으로 표시되는 문제를 시험에서 확인했습니다. 관련 사례는 C06·C08입니다.
기사별 운송 · 판매·운송 불일치 · 운송비 통계 · 운송관리
→ 재고·물류 / 배차·상하차·배송
/sales/transport-management/transport/sales/transport-management/by-driver/sales/transport-management/transport-fee-stats/sales/transport-management/mismatch업무 틀·필수 양식·검증한 데이터만 계승하고 해당 업무의 핵심 로직·데이터·공통 API·권한·이력을 새 구조로 통합·재구축한다. 신규 API에 업무 화면과 담당 Agent를 연결한다.
완료된 배송이 잘못 이전 상태로 돌아가지 않는지 확인합니다. 일부 상차·하차, 복구 실패, 동시 수정도 점검합니다. 미사용 배차 화면의 자료 이전이나 통합은 하지 않습니다. 새 데이터·공통 API에서 권한·정합성·중복 요청·실패 복구를 검수한다.
오래 열어 둔 화면에서 저장하면 완료된 배송이 이전 상태로 돌아가거나, 복구에 실패해도 성공으로 표시되는 문제를 시험에서 확인했습니다. 관련 사례는 C06·C08입니다.
실패 후 진행 분기. 전체 예외 경로 검증과 상태 경계 재작성 대상.
ccbio_erp/backend/src/modules/sales-delivery/sales-delivery.service.ts:3820// 판매 항목 상태 업데이트 실패해도 배송 상태 업데이트는 계속 진행
창고·상차·배차 협력사가 각자 접속해 작업을 조회하고 입력하는 전용 화면이 있습니다.
협력사는 재설계한 업무 화면에서 자신에게 배정된 입고·상차·배차만 처리합니다. 최신 상태·중복·부분 수량을 검사하고 내부 원장·화면에 동일한 결과를 반영합니다.
내부 입고·운송 기능을 바꾸면 협력사 화면에서도 같은 수량과 진행 상태가 보이도록 맞춰야 합니다.
배차관리 · 입고 관리 · 상차관리
→ 협력사 업무 / 배정 작업
/loading-company/loading-management/loading-company/inbound-management/dispatch-company/dispatch-management업무 틀·필수 양식·검증한 데이터만 계승하고 해당 업무의 핵심 로직·데이터·공통 API·권한·이력을 새 구조로 통합·재구축한다. 신규 API에 업무 화면과 담당 Agent를 연결한다.
다른 업체의 작업을 조회·수정할 수 없는지 확인합니다. 일부 작업만 끝내거나 같은 결과를 다시 보내도 내부 화면과 수량·상태가 맞아야 합니다. 새 데이터·공통 API에서 권한·정합성·중복 요청·실패 복구를 검수한다.
내부 입고·운송 기능을 바꾸면 협력사 화면에서도 같은 수량과 진행 상태가 보이도록 맞춰야 합니다.
상차 업체 전용 화면.
ccbio_erp/frontend/app/loading-company/loading-management/page.tsx:1173export default
배차 업체 전용 화면.
ccbio_erp/frontend/app/dispatch-company/dispatch-management/page.tsx:1169export default
공급자, 창고, 운송 업체, 소속 직원, 요금 기준을 각각 다른 메뉴에서 관리합니다.
거래처·창고·협력사 정보를 한 메뉴 묶음에서 관리합니다. 중복 등록을 확인하고, 기존 거래에 쓰이는 업체를 잘못 삭제하지 않도록 안내합니다.
같은 업체가 중복 등록됐는지, 어느 창고·직원과 연결되는지, 삭제하면 기존 거래에 문제가 생기는지 확인해야 합니다.
배차 업체 관리 · 배차 업체 직원 관리 · 공급자 관리 · 하차 업체 관리 · 직원 관리 · 창고 이고비 관리 · 창고 관리
→ 기준정보 / 거래처·창고·협력사
/suppliers/warehouses/warehouse-employees/warehouse-igobi/dispatch-companies/dispatch-company-employees/unloading-companies업무 틀·필수 양식·검증한 데이터만 계승하고 해당 업무의 핵심 로직·데이터·공통 API·권한·이력을 새 구조로 통합·재구축한다. 신규 API에 업무 화면과 담당 Agent를 연결한다.
기존 거래와 연결된 업체 정보가 유지되는지 확인합니다. 거래에 쓰이는 업체의 삭제를 막고, 업체별 직원과 요금을 허용된 담당자만 수정하는지 점검합니다. 새 데이터·공통 API에서 권한·정합성·중복 요청·실패 복구를 검수한다.
같은 업체가 중복 등록됐는지, 어느 창고·직원과 연결되는지, 삭제하면 기존 거래에 문제가 생기는지 확인해야 합니다.
창고 기준정보 화면.
ccbio_erp/frontend/app/warehouses/page.tsx:72export default
배차 업체 직원 화면은 별도 경로로 존재한다.
ccbio_erp/frontend/app/dispatch-company-employees/page.tsx:59export default
문자 보내기, 발송 내역, 발신번호, 문구 양식 화면이 있습니다. 개발 확인용 문자 테스트 화면도 있습니다.
받는 사람과 문구·발신번호를 확인해 문자를 보내고, 결과와 실패 내역을 이어서 봅니다. 재시도 때 중복 발송을 막고, 테스트 화면은 일반 직원 메뉴에서 제외합니다.
누구에게 보낼 수 있는지, 수신 동의·거부가 반영되는지, 실패 후 재시도 때 문자가 중복 발송되지 않는지 확인해야 합니다.
SMS 발송 이력 · SMS 관리 · SMS 발신자 관리 · SMS 템플릿 관리 · SMS 발송 테스트
→ 고객·농가 / 메시지 운영
/sms-management/sms-history/sms-senders/sms-templates/sms-test업무 틀·필수 양식·검증한 데이터만 계승하고 해당 업무의 핵심 로직·데이터·공통 API·권한·이력을 새 구조로 통합·재구축한다. 신규 API에 업무 화면과 담당 Agent를 연결한다.
수신 거부와 발송 권한이 적용되는지, 재시도해도 같은 문자가 중복되지 않는지 확인합니다. 실제 발송 결과·비용을 비교하고 일반 사용자의 테스트 화면 접근도 막습니다. 새 데이터·공통 API에서 권한·정합성·중복 요청·실패 복구를 검수한다.
누구에게 보낼 수 있는지, 수신 동의·거부가 반영되는지, 실패 후 재시도 때 문자가 중복 발송되지 않는지 확인해야 합니다.
테스트 화면이 별도로 존재한다.
ccbio_erp/frontend/app/sms-test/page.tsx:16export default
업무 발송 이력 화면.
ccbio_erp/frontend/app/sms-history/page.tsx:356export default
직원 역할에 따라 보이는 메뉴가 다릅니다. 다만 확인한 사용자 수정·삭제 코드에서는 로그인 확인 외에 담당 권한까지 검사하는지 분명하지 않습니다.
직원·협력사·농가별로 볼 수 있는 정보와 처리할 수 있는 업무를 정합니다. 화면에서 작업하든 직원 챗봇에 요청하든 같은 권한을 확인하고, 허용되지 않은 조회·수정은 차단합니다.
메뉴가 안 보이더라도 주소나 요청을 직접 보내면 처리될 수 있는지 추가 시험이 필요합니다.
인증 · 사용자 관리 · 로그인 · 승인 대기 · 회원가입 · 권한 관리
→ 시스템 / 계정·역할·업무권한
/login/register/pending-approval/auth/callback/users/users/permissions/dashboard/users업무 틀·필수 양식·검증한 데이터만 계승하고 해당 업무의 핵심 로직·데이터·공통 API·권한·이력을 새 구조로 통합·재구축한다. 신규 API에 업무 화면과 담당 Agent를 연결한다.
역할별 조회·수정 허용 범위를 시험합니다. 사용 중지된 계정이나 로그인 기한이 지난 계정의 접근, 권한을 임의로 높이는 시도, 숨긴 메뉴의 직접 접근도 확인합니다. 새 데이터·공통 API에서 권한·정합성·중복 요청·실패 복구를 검수한다.
메뉴가 안 보이더라도 주소나 요청을 직접 보내면 처리될 수 있는지 추가 시험이 필요합니다.
컨트롤러에 JWT 인증 가드가 선언돼 있다.
ccbio_erp/backend/src/modules/users/users.controller.ts:12@UseGuards(JwtAuthGuard)
사용자 수정 호출에 호출자 정보가 전달되지 않는다.
ccbio_erp/backend/src/modules/users/users.controller.ts:40this.usersService.update(id, updateUserDto)
프론트 메뉴 역할 조건과 서버 행위 권한을 함께 대조해야 한다.
ccbio_erp/frontend/components/layout/app-sidebar.tsx:265role.code === 'ROLE_SYSTEM'
회사 정보, 업무 구분값, 입고 기본값, 행정구역, 운임을 개별 화면에서 관리합니다.
업무에 쓰는 공통 기준과 운임을 한 메뉴 묶음에서 관리합니다. 누가 언제 바꿨는지, 언제부터 적용되는지, 바꾸면 어떤 계산에 영향을 주는지 확인할 수 있게 합니다.
운임이나 업무 기준을 바꾸면 어느 시점부터 어떤 견적·원가 계산에 적용되는지 확인해야 합니다.
코드 관리 · 안전운임 요금표 관리 · 회사 정보 관리 · 입고 기본 설정 · 법정동 마스터
→ 기준정보 / 코드·회사·업무정책
/codes/settings/company-info/settings/inbound-defaults/settings/legal-admin-master/safe-freight-rates업무 틀·필수 양식·검증한 데이터만 계승하고 해당 업무의 핵심 로직·데이터·공통 API·권한·이력을 새 구조로 통합·재구축한다. 신규 API에 업무 화면과 담당 Agent를 연결한다.
중복되거나 더 이상 쓰지 않는 구분값이 적용되지 않는지 확인합니다. 적용 날짜·단위·요율을 바꾼 전후의 견적과 원가도 비교합니다. 새 데이터·공통 API에서 권한·정합성·중복 요청·실패 복구를 검수한다.
운임이나 업무 기준을 바꾸면 어느 시점부터 어떤 견적·원가 계산에 적용되는지 확인해야 합니다.
입고 기본 설정.
ccbio_erp/frontend/app/settings/inbound-defaults/page.tsx:45export default
운임 요금표 관리.
ccbio_erp/frontend/app/safe-freight-rates/page.tsx:72export default
구글 드라이브를 따로 여는 화면과 업무에 문서를 연결하는 기능이 있습니다.
계약·농가·배송 상세 화면에서 관련 서류를 바로 엽니다. 파일을 볼 권한이 없거나 드라이브 연결이 끊겼으면 이유를 알려주고, 다시 연결하거나 재시도할 수 있게 합니다.
해당 업무의 담당자만 파일을 볼 수 있는지, 드라이브 연결이 끊기거나 로그인 기한이 지나면 어떻게 안내하는지 확인해야 합니다.
구글 드라이브
→ 업무별 증빙 / 연계 설정
/google-drive업무 틀·필수 양식·검증한 데이터만 계승하고 해당 업무의 핵심 로직·데이터·공통 API·권한·이력을 새 구조로 통합·재구축한다. 신규 API에 업무 화면과 담당 Agent를 연결한다.
권한 없는 사람의 서류 열기를 차단하는지 확인합니다. 연결 만료·서비스 장애를 안내하고, 파일을 옮긴 뒤에도 원래 업무에서 열리는지 점검합니다. 새 데이터·공통 API에서 권한·정합성·중복 요청·실패 복구를 검수한다.
해당 업무의 담당자만 파일을 볼 수 있는지, 드라이브 연결이 끊기거나 로그인 기한이 지나면 어떻게 안내하는지 확인해야 합니다.
독립 문서 연계 화면.
ccbio_erp/frontend/app/google-drive/page.tsx:62export default
파일 연계 서비스가 존재한다.
ccbio_erp/backend/src/modules/google-drive/google-drive.service.ts:8export class
코드에 AI가 만든 조회 명령을 실행하는 화면(/data-chat)이 있습니다. 실제로 누가 어떤 용도로 쓰는지는 아직 확인하지 못했습니다.
현재 누가 이 화면을 사용하는지, 어디에 표시되는지, 어떤 업무에 쓰는지부터 확인합니다. 확인 결과를 기록하고 직원용 새 챗봇의 개발 범위와 따로 관리합니다.
이 화면이 있다는 것만으로 직원용 업무 챗봇이 이미 운영 중이라고 볼 수는 없습니다.
/data-chat
→ 기존 /data-chat · 사용·노출 여부 확인
/data-chat실제 사용 여부와 담당자를 확인하는 대상입니다. 이 화면을 다시 만들거나 새 직원 챗봇으로 자료를 옮기는 작업은 계획에 넣지 않습니다.
사용 여부·메뉴 표시 여부·용도·담당자를 기록했는지 확인합니다. 직원용 새 챗봇의 기능과 개발 작업으로 중복 계산하지 않습니다.
이 화면이 있다는 것만으로 직원용 업무 챗봇이 이미 운영 중이라고 볼 수는 없습니다.
AI 생성 SQL 실행 경로.
ccbio_erp/backend/src/modules/data-chat/data-chat.service.ts:130this.dataSource.query(sql)
유기축산 인증자료를 관리하는 별도 화면이 있습니다.
농가 정보 화면에서 농업경영체 등록자료와 유기축산 인증서를 구분해 봅니다. 각 자료가 어느 농가의 것인지, 언제까지 유효한지, 누가 볼 수 있는지를 함께 관리합니다.
유기축산 인증 여부와 어느 농업경영체에 속하는지는 서로 다른 정보이므로 구분해서 관리해야 합니다.
유기축산 인증 관리
→ 고객·농가 / 증빙·인증
/organic-certifications업무 틀·필수 양식·검증한 데이터만 계승하고 해당 업무의 핵심 로직·데이터·공통 API·권한·이력을 새 구조로 통합·재구축한다. 신규 API에 업무 화면과 담당 Agent를 연결한다.
인증 종류·농가·유효기간이 정확한지 확인합니다. 농업경영체 증빙이 맞는 농가에 연결되고, 허용된 담당자만 자료를 볼 수 있어야 합니다. 새 데이터·공통 API에서 권한·정합성·중복 요청·실패 복구를 검수한다.
유기축산 인증 여부와 어느 농업경영체에 속하는지는 서로 다른 정보이므로 구분해서 관리해야 합니다.
유기축산 인증 관리 화면.
ccbio_erp/frontend/app/organic-certifications/page.tsx:89export default
독립 인증자료 서비스.
ccbio_erp/backend/src/modules/organic-certification/organic-certification.service.ts:12export class
ERP에서는 쇼핑몰 통계를 보고, 상품·회원·주문·배송 처리는 별도 쇼핑몰 관리자 화면(CMS)에서 합니다.
ERP 안에서 쇼핑몰 회원·상품·주문·배송 업무도 처리합니다. 고객 정보에서 관련 주문을 찾아 판매 업무로 이어갈 수 있게 하고, 주문·결제 처리는 기존 쇼핑몰 기능을 활용합니다.
직원이 ERP와 쇼핑몰 관리자 화면을 오가며 일하므로 메뉴, 담당 권한, 고객·주문 정보를 연결해야 합니다.
일별 데이터 관리 · 대시보드
→ 커머스 운영 / 회원·상품·주문·배송·프로모션
/mall-stats/mall-stats/daily업무 틀·필수 양식·검증한 데이터만 계승하고 해당 업무의 핵심 로직·데이터·공통 API·권한·이력을 새 구조로 통합·재구축한다. 신규 API에 업무 화면과 담당 Agent를 연결한다.
기존 관리자 화면과 회원·상품·주문·환불·행사 처리 결과가 같은지 비교합니다. 담당 권한, 처리 실패 안내, 상태 누락, 금액 차이도 확인합니다. 새 데이터·공통 API에서 권한·정합성·중복 요청·실패 복구를 검수한다.
직원이 ERP와 쇼핑몰 관리자 화면을 오가며 일하므로 메뉴, 담당 권한, 고객·주문 정보를 연결해야 합니다.
CMS에 주문·배송 운영 메뉴가 있다.
ccbio_ecommerce/apps/cms/src/components/layout/app-sidebar.tsx:221title: '주문 관리'
상품 운영 화면과 데이터 훅을 보유한다.
ccbio_ecommerce/apps/cms/src/app/products/page.tsx:10useProducts
주문 운영 화면이 존재한다.
ccbio_ecommerce/apps/cms/src/app/orders/page.tsx:188export default
일부 기능에는 처리 내역이 남습니다. 하지만 여러 업무의 금액·수량을 비교하거나 실패한 작업을 복구하는 공통 화면은 확인되지 않았습니다.
누가 무엇을 바꿨고 어느 단계에서 실패했는지 한 화면에서 확인합니다. 관련 기록의 금액·수량을 비교해 차이를 찾고, 담당자가 영향 범위를 확인한 뒤 복구하거나 다시 처리합니다.
기록이 남는 것만으로는 어디서 저장이 실패했는지 찾고 업무를 정상 상태로 되돌리기 어렵습니다.
별도로 사용하는 메뉴 없음
→ 시스템 / 변경 이력·대사·복구
업무 틀·필수 양식·검증한 데이터만 계승하고 해당 업무의 핵심 로직·데이터·공통 API·권한·이력을 새 구조로 통합·재구축한다. 신규 API에 업무 화면과 담당 Agent를 연결한다.
사용자 요청부터 실제 저장까지 따라가며 빠진 실패 내역을 찾을 수 있는지 확인합니다. 복구·재시도 권한을 점검하고 처리 후 수량·금액이 맞는지 비교합니다. 새 데이터·공통 API에서 권한·정합성·중복 요청·실패 복구를 검수한다.
기록이 남는 것만으로는 어디서 저장이 실패했는지 찾고 업무를 정상 상태로 되돌리기 어렵습니다.
기능 로그 저장 서비스가 있다.
ccbio_erp/backend/src/modules/feature-audit-log/feature-audit-log.service.ts:24async create
감사 기록 실패를 경고로 처리하는 경로. 업무 성공/로그 누락 정책 보완 대상.
ccbio_erp/backend/src/modules/sales-delivery/sales-delivery.service.ts:3877배송 수정 로그 저장 실패
쇼핑몰 고객에게 답하는 챗봇을 운영 중입니다. 답변 자료를 수집·검토하고, 참고 자료와 대화 내역을 관리하는 기능도 있습니다.
고객 챗봇의 답변·자료·SEED·로그 운영을 보호하면서 CMS Agent를 확장합니다. 커머스 자체 처리 여부를 판단하고 ERP 업무는 담당자별 Agent에 전달한 뒤 허용된 결과를 취합·회신합니다.
직원용 새 챗봇을 만드는 동안에도 기존 쇼핑몰 고객 응대와 답변 자료 관리가 계속돼야 합니다.
챗봇 대화 로그 · 챗봇 SEED 수집 · 챗봇 SEED 검수 · 챗봇 RAG 소스
→ 커머스 운영 / 쇼핑몰 챗봇 지식·품질 관리
/chatbot-seed/chatbot-seed/review/chatbot-seed/sources/chatbot-seed/logs고객 챗봇의 답변·자료·SEED·로그 운영을 보호하면서 CMS Agent를 확장합니다. 커머스 자체 처리 여부를 판단하고 ERP 업무는 담당자별 Agent에 전달한 뒤 허용된 결과를 취합·회신합니다.
기존 답변·자료 수집·검토·갱신·대화 내역 기능이 유지되는지 확인합니다. 쇼핑몰 고객이 직원용 업무 자료나 대화 내역에 접근하지 못하도록 구분합니다. 새 데이터·공통 API에서 권한·정합성·중복 요청·실패 복구를 검수한다.
직원용 새 챗봇을 만드는 동안에도 기존 쇼핑몰 고객 응대와 답변 자료 관리가 계속돼야 합니다.
기존 SEED 엑셀 가져오기 사전 검증 경로.
ccbio_erp/frontend/app/chatbot-seed/page.tsx:184/chatbot-seeds/import?dryRun=1
검수 상태·검수자·시각 저장과 동기화 연결.
ccbio_erp/backend/src/modules/chatbot-seed/chatbot-seed.service.ts:143async review(
기존 RAG 소스 운영·상태 조회.
ccbio_erp/frontend/app/chatbot-seed/sources/page.tsx:92/chatbot-rag/status
기존 쇼핑몰 대화 로그 운영 화면.
ccbio_erp/frontend/app/chatbot-seed/logs/page.tsx:72/chatbot-rag/logs
메뉴에 예전 기능을 모은 구메뉴 그룹이 있습니다. 현재 사용하지 않는다는 점을 사용자가 확인했습니다.
사용하지 않는 구메뉴를 왼쪽 메뉴 목록에서 숨깁니다. 현재 쓰는 메뉴는 그대로 찾고 이용할 수 있게 합니다.
사용하지 않는 메뉴가 보이면 실제 쓰는 업무를 찾기 어려울 수 있어 메뉴 정리가 필요합니다.
입고 관리 · 스케줄 관리 · 대시보드 · 배차완료 · 배차중 · 배차실패 · 배차관리 · 배차요청 · 일정조정 · 상차완료 · 상차중 · 하차완료 · 배차 관리
→ 미사용 구메뉴 · 메뉴에서 숨김
/inbound/schedules/transport/dashboard/transport/dispatch-completed/transport/dispatch-dispatching/transport/dispatch-failed/transport/dispatch-management/transport/dispatch-request/transport/dispatch-rescheduled/transport/loading/transport/loading-completed/transport/unloading-completed/vehicle-dispatch/vehicle-dispatch-user/vehicle-dispatch-warehouse구메뉴를 화면에서 숨기는 작업만 합니다. 해당 기능 재개발, 다른 기능과의 통합, 자료 이전, 예전 주소 변경, 저장 기능 종료는 추가하지 않습니다.
구메뉴가 표시되지 않고 현재 사용하는 메뉴는 정상적으로 열리는지 확인합니다.
사용하지 않는 메뉴가 보이면 실제 쓰는 업무를 찾기 어려울 수 있어 메뉴 정리가 필요합니다.
사이드바의 구메뉴 그룹. 사용자가 현재 미사용이라고 확인한 숨김 범위.
ccbio_erp/frontend/components/layout/app-sidebar.tsx:1451<span>구메뉴</span>
직원이 고객·영업·재고 등의 업무를 요청하는 챗봇은 새로 만들어야 합니다. 현재 운영 중인 것은 쇼핑몰 고객용 챗봇입니다.
각 담당자가 자신의 전문 AI와 대화하며 담당 업무를 조회·분석하고 초안을 만듭니다. 실행할 내용과 필요한 협업을 같은 업무 공간에서 확인하고, 회사 규칙에 맞게 승인·처리합니다.
직원 권한에 맞게 자료를 찾고, 요청한 업무를 처리하기 전에 내용을 확인받으며, 처리 결과를 남기는 기능이 필요합니다.
별도로 사용하는 메뉴 없음
→ 직원 AI 업무 / 대화·조회·분석·실행·승인
담당자별 전문 에이전트 대화·업무 화면과 조회·분석·실행 도구를 신규 개발합니다. 배정은 M28, 협업 조율은 M27, 품질·비용·운영은 M29와 연결합니다.
로그인한 담당자의 배정 에이전트·권한·업무 맥락이 적용되고, 대화와 업무 화면에서 같은 권한·계산·승인 기준으로 처리되는지 검수합니다. 새 데이터·공통 API에서 권한·정합성·중복 요청·실패 복구를 검수한다.
직원 권한에 맞게 자료를 찾고, 요청한 업무를 처리하기 전에 내용을 확인받으며, 처리 결과를 남기는 기능이 필요합니다.
기존 쇼핑몰 고객용 도구 정의. 직원 업무 도구는 신규 개발 범위.
ccbio_erp/backend/src/modules/chatbot-seed/chatbot-tools.service.ts:111const tools:
여러 담당자의 전문 에이전트를 연결하는 공통 조율 기능은 이번에 새로 설계할 대상입니다.
팀장 Agent는 팀 문맥·배분·승인을 연결하고 Orchestrator는 팀 간 처리 순서·대기·재개·취소·결과 회신을 관리합니다. 요청자의 권한이 협업 과정에서 확대되지 않게 합니다.
업무가 부서 사이를 오갈 때 담당자·진행 상태·승인·실패 처리 기준이 필요합니다.
별도로 사용하는 메뉴 없음
→ 직원 AI 업무 / 메인 오케스트레이터 · 전문 에이전트 협업
요청을 필요한 업무로 나누고 맞는 담당자 에이전트에게 전달합니다. 진행 결과를 모아 보여주며, 담당자가 바뀌는 업무는 상대 작업함의 확인·승인 절차를 따릅니다.
역할·담당 대상·정상·실패·중복·승인 사례를 실제 업무 담당자가 검수합니다. 새 데이터·공통 API에서 권한·정합성·중복 요청·실패 복구를 검수한다.
업무가 부서 사이를 오갈 때 담당자·진행 상태·승인·실패 처리 기준이 필요합니다.
직원용 챗봇 개발 계획을 담당자별 전문 에이전트 구조로 확장합니다. 배정 기능이 운영 중이라는 뜻은 아닙니다.
담당자별 Prompt Engineering 설정·권한·도구·개인 문맥을 배정합니다. 경영관리·사양·자산·ChamFi는 농가 성장지원 담당의 네 분야 능력으로 묶고 겸직·대리·회수도 관리합니다.
같은 분야라도 담당 고객·창고·권한이 달라 각자의 업무 맥락을 구분해야 합니다.
별도로 사용하는 메뉴 없음
→ 직원 AI 업무 / 담당자별 배정 · 전문 분야 설정
각 담당자에게 자기 전문 분야의 AI를 배정합니다. 공통 전문 지식은 활용하면서 각자의 담당 대상·권한·진행 중인 업무·대화는 구분합니다.
역할·담당 대상·정상·실패·중복·승인 사례를 실제 업무 담당자가 검수합니다. 새 데이터·공통 API에서 권한·정합성·중복 요청·실패 복구를 검수한다.
같은 분야라도 담당 고객·창고·권한이 달라 각자의 업무 맥락을 구분해야 합니다.
담당자별 전문 에이전트와 협업 기능의 품질·비용·운영 기준은 신규 정의 대상입니다.
RAG 검색·근거·실행 정확도와 응답 시간·비용·오류·수동 개입을 측정합니다. 모델·프롬프트·색인·도구 변경을 검증하고 문제 버전을 중단·되돌립니다.
답변이 자연스러운지만으로 실제 업무가 정확하게 끝나는지 판단할 수 없습니다.
별도로 사용하는 메뉴 없음
→ 직원 AI 업무 / AI 품질·비용·실행 운영
업무별 정확도·처리 시간·담당자 개입·비용을 측정합니다. 문제 있는 버전은 적용을 멈추고, 담당자가 업무를 이어받을 수 있도록 실행 내역과 중단·복구 기능을 제공합니다.
역할·담당 대상·정상·실패·중복·승인 사례를 실제 업무 담당자가 검수합니다. 새 데이터·공통 API에서 권한·정합성·중복 요청·실패 복구를 검수한다.
답변이 자연스러운지만으로 실제 업무가 정확하게 끝나는지 판단할 수 없습니다.
농장 기본 정보와 쇼핑몰 구매, ERP 거래·명세서 내역이 있습니다.
농가가 수입·지출·생산 내역을 직접 기록합니다. 기존 구매 내역도 함께 모아 월별로 얼마를 벌고 썼는지 확인합니다. 네 분야의 기록은 농가 성장지원 담당의 자료·상담·리포트로 함께 연결합니다.
구매·거래 내역만으로는 농가가 직접 기록할 수입·지출·생산 장부를 대신할 수 없습니다.
수입·지출·생산을 직접 입력하고 구매 내역을 연결해 월별 현황을 보여줍니다.
세무 신고, 전체 회계 업무, 은행 거래 자동 수집은 이번 범위에 포함하지 않습니다.
기초 잔액과 입력·수정·취소 결과가 장부 합계에 맞게 반영되는지 확인합니다. 다른 농가의 정보는 볼 수 없어야 합니다.
농장 프로필이 존재하며 수입·지출 장부와는 별개.
ccbio_ecommerce/apps/api/src/farm-management/entities/user-cattle-farm.entity.ts:26@Entity(
본인 주문 조회를 구매 내역 연결의 출발점으로 사용.
ccbio_ecommerce/apps/api/src/orders/orders.controller.ts:52@Get('me')축산물 이력제와 연결된 농장·가축 정보가 있고, 두수·출생·체중 등의 항목을 보유하고 있습니다.
농가가 매일 준 사료의 양과 가축 사육 기록을 입력합니다. 구매량·두수·급여량을 바탕으로 사료가 언제 떨어질지 예상하고 재주문 시점을 알려줍니다. 기록이 부족하면 예상할 수 없다고 표시합니다. 네 분야의 기록은 농가 성장지원 담당의 자료·상담·리포트로 함께 연결합니다.
매일 준 사료의 양을 기록하고, 구매량·사육 두수와 함께 계산해 다음 주문 시점을 알려주는 기능이 필요합니다.
기본 급여·사육 기록, 예상에 사용한 자료와 계산 기준일, 재주문 알림을 제공합니다.
센서를 통한 자동 수집, 질병 진단, 최적 사료 배합 AI는 이번 범위에 포함하지 않습니다.
같은 가축이 중복 등록되지 않는지 확인하고 예상 소비량을 실제 소비량과 비교합니다. 기록이 부족한 경우에는 예상값을 표시하지 않습니다.
개체 조회 API가 있음. 일별 급여 장부가 있다는 의미는 아님.
ccbio_ecommerce/apps/api/src/farm-management/farm-management.controller.ts:107@Get('animals')개체·이력제 데이터 항목 존재. 신규 기록의 연결 대상.
ccbio_ecommerce/apps/api/src/farm-management/entities/user-cattle-farm-animal.entity.ts:29@Entity(
일부 소의 자산가치를 계산하는 기능과 평가 내역, 농장별 평가 동의 기능이 있습니다.
기존 계산이 가능한 소는 검증한 방식으로 평가합니다. 그 밖의 가축·시설은 담당자가 자산과 평가금액을 직접 입력하고, 금액을 언제 어떤 방법으로 정했는지 함께 봅니다. 네 분야의 기록은 농가 성장지원 담당의 자료·상담·리포트로 함께 연결합니다.
기존 계산식이 모든 가축·시설에 맞는 것은 아닙니다. 자동 평가할 수 있는 대상부터 확인해야 합니다.
기존 자동 평가 대상은 계산 결과를 검증한 뒤 사용합니다. 나머지 자산은 직접 등록하고 평가에 사용할 금액을 입력합니다.
모든 축종·시설의 자동 평가나 금융기관이 인정할 담보 금액 계산은 이번 범위에 포함하지 않습니다.
도축 여부·사육 목적·거세 여부 등 기존 계산식의 적용 조건을 명확히 합니다. 지원하지 않는 자산에 같은 계산식을 임의로 적용하지 않는지 확인합니다.
기존 계산의 대상 조건과 한계를 코드로 확인.
ccbio_ecommerce/apps/api/src/farm-management/farm-asset-valuation.service.ts:71private static readonly TARGET_SQL
대상 개체 조회·평가 로직 재사용 후보.
ccbio_ecommerce/apps/api/src/farm-management/farm-asset-valuation.service.ts:906private async findTargetAnimals(
대출 상담을 신청하고 진행 상태를 보는 기능과 관리자의 상담 처리 기능이 있습니다.
농가가 필요한 자금과 상담 내용을 신청하고 진행 상황을 확인합니다. 담당자는 동의받은 농가·자산 정보를 참고해 상담하며, 금융기관 연결은 승인된 제휴 범위에서 제공합니다. 네 분야의 기록은 농가 성장지원 담당의 자료·상담·리포트로 함께 연결합니다.
상담에 필요한 농가·자산 정보, 정보 제공 동의, 금융기관과의 제휴 조건을 연결해야 합니다.
자금 정보 안내, 상담 신청·접수·처리를 제공합니다. 금융기관 연결은 승인된 경우에만 포함합니다.
실제 대출 실행, 자동 신용 심사, 대출 한도 계산, 승인받지 않은 금융기관 연결은 제외합니다.
착수 후 3주 차에 법무·제휴·동의 조건을 확인합니다. 필요한 조건이 갖춰지지 않은 외부 연결은 보류합니다.
상담 신청 생성 기능 존재. 대출 실행 기능의 근거로 사용하지 않음.
ccbio_ecommerce/apps/api/src/loan-consultations/loan-consultations.service.ts:85async create(
CMS 상담 처리 API 존재.
ccbio_ecommerce/apps/api/src/loan-consultations/cms-loan-consultations.controller.ts:36@Patch(':lcId')상품 조회부터 주문·결제·배송·취소·환불까지 처리하는 쇼핑몰 기능이 이미 있습니다.
농가가 최근 산 상품을 다시 주문하고 배송 상태를 확인합니다. 주문·취소·환불 결과를 ERP에도 반영하고, 같은 주문이 두 번 잡히거나 수량·금액이 달라지지 않도록 확인합니다.
농가의 구매·사육 기록에서 재주문으로 이어지고, 주문 결과가 ERP에도 정확하게 반영되도록 연결해야 합니다.
기존 구매 흐름을 유지하며 농가별 구매 내역을 연결합니다. 주문·배송·취소가 ERP에 맞게 반영되는지 확인합니다.
쇼핑몰·결제 기능 전체 재개발과 쇼핑몰 저장 자료의 직접 수정은 제외합니다.
쇼핑몰팀이 제공하는 연결 기능과 이용 조건을 확인합니다. 결제·취소·환불의 중복 반영이 없어야 하고 양쪽 수량·금액이 맞아야 합니다.
농가 주문 API 등 기존 구매 흐름을 활용.
ccbio_ecommerce/apps/api/src/orders/orders.controller.ts:34@Post()
기존 결제 상태 관리 경로 확인. 신규 결제 엔진을 만드는 계획이 아님.
ccbio_ecommerce/apps/api/src/orders/cms-orders.controller.ts:133@Patch(':id/payment')ERP 주문 수신은 명세상 추후 구현. 연결을 기존 완료 기능으로 보지 않음.
ccbio_ecommerce/docs/ERP_API_SPEC.md:304## 3. 이커머스 주문 수신
일치하는 업무가 없습니다.
회원·고객 번호와 농업경영체 증빙, 심사 상태가 저장돼 있습니다. 일부 업무에는 삭제한 내용을 복구하는 기능도 있습니다.
새 데이터·공통 API를 기준으로 담당자가 등록정보와 증빙을 확인해 경영주·농장·회원 정보를 연결합니다. 기존 고객 번호는 유지하고, 다른 농가의 정보를 보거나 다른 사람의 수정을 덮어쓰지 않도록 합니다. 변경 내역과 복구 기록도 남깁니다.
회원과 농장이 어떻게 연결되는지, 누가 정보를 보고 고칠 수 있는지, 동시에 수정하면 어떻게 처리할지 공통 기준이 필요합니다.
증빙·심사 엔티티 확인. 등록번호 전용 필드는 확인되지 않음.
ccbio_ecommerce/apps/api/src/agri-entity/entities/user-agri-entity.entity.ts:14@Entity(
배차에는 복구 구현이 있음. 전 업무 공통 복구가 완성됐다는 뜻은 아님.
ccbio_erp/backend/src/modules/vehicle-dispatch/vehicle-dispatch.service.ts:814async restore(
기존 ERP·쇼핑몰 관리자 화면과 표·입력칸 등 재사용할 수 있는 화면 요소가 있습니다.
새 데이터·공통 API를 기준으로 농가는 경영·사양 기록을, 직원은 고객·판매 등의 업무를 쉽게 찾도록 메뉴를 구성합니다. 입력 오류, 다른 사람의 수정, 승인 대기 상태는 이유와 다음 할 일을 화면에 알려줍니다.
농가가 기록하는 화면과 직원이 업무를 처리하는 화면을 구분하고, 새 기능을 어느 메뉴에서 여는지 정해야 합니다.
공용 테이블 구성요소 존재. 구 화면 전체 재사용과 구분.
ccbio_erp/frontend/components/ui/data-table.tsx:379export
특정 저장 경로에 하위 작업 행 삭제·재생성이 남아 있어 변경 단위 저장으로 교체할 대상.
ccbio_erp/backend/src/modules/sales-delivery/sales-delivery.service.ts:2566if (dto.syncWorkLine === true)
고객 번호와 상담·연락·거래 내역, 기존 입력 화면이 있습니다.
새 데이터·공통 API를 기준으로 고객 한 명을 선택하면 농장 정보와 회원·거래·상담·연락 내역을 함께 봅니다. 판매에서는 고객을 선택하고, 고객 정보 수정과 상담 저장은 각각 맞는 화면에서 처리합니다.
고객 정보를 가져오거나 상담을 저장할 때 기존 정보가 덮어써지거나 일부만 저장되는 문제를 고쳐야 합니다.
기존 고객을 찾아 update하는 동기화 경로. 데이터는 살리고 매칭·수정 방식은 교체.
ccbio_erp/backend/src/modules/customers/customers.service.ts:804async syncExternalMallCustomer(
연결에 쓸 기존 고객·농가 필드 확인.
ccbio_erp/backend/src/modules/customers/customers.service.ts:824private async buildCreateCustomerDtoFromMallSync(
판매·거래명세서·수금 내역과 출력 양식, 금액 계산 기능이 있습니다.
새 데이터·공통 API를 기준으로 판매 → 출하 → 명세서 → 수금으로 업무를 이어갑니다. 수정·취소한 내용이 관련 금액과 남은 받을 돈에 맞게 반영되는지 확인하고, 기존 거래 내역과 출력 양식은 검증 후 활용합니다.
판매 저장 때 고객 정보가 함께 바뀌는 문제, 동시 수금·저장 실패 문제, 월말 지급기일 계산 문제를 고쳐야 합니다.
코드는 존재하지만 월말 발행 시 다음 달을 건너뛰는 ERP-C09를 원문 함수로 재현. 수정·경계값 검증 전 재사용 보류.
ccbio_erp/backend/src/modules/receivables/utils/payment-due-date-calculator.ts:61export function calculatePaymentDueDate
경과일 계산 유틸리티 존재. 현행 업무 규칙과 결과 대조 필요.
ccbio_erp/backend/src/modules/receivables/utils/collection-elapsed-calculator.ts:23export function
컨테이너·입고·판매 품목·배송 내역과 재고 조회·운송 처리 기능이 있습니다.
새 데이터·공통 API를 기준으로 입고·출고·이동·반품·조정 기록으로 재고 수량을 확인합니다. 배차·상차·하차를 처리할 때 최신 상태를 확인하고, 실패한 작업은 완료로 표시하지 않습니다.
재고 조정을 다시 시도할 때 중복 차감되는 문제와 배송 상태가 잘못 바뀌거나 실패가 숨겨지는 문제를 고쳐야 합니다.
기존 분석에서 컨테이너−판매품목 계산과 독립 재고 원장 부재 확인.
docs/crm_roadmap/보관/2026-10-12_정리전/ERP_BUSINESS_ANALYSIS.md:36| 7 | 재고 |
운송 규칙은 추출하되 하위 행 전체 교체 저장 방식은 교체.
ccbio_erp/backend/src/modules/sales-delivery/sales-delivery.service.ts:2566if (dto.syncWorkLine === true)
계약·발주·선하증권(BL)·송장·결제·통관 내역과 이들을 연결하는 기능이 있습니다.
새 데이터·공통 API를 기준으로 계약부터 결제·물류·입고까지 진행 상황을 이어서 확인합니다. 필요한 부분만 수정하고 변경 승인과 이력을 남기며, 입고·취소 결과가 재고와 비용에도 맞게 반영되는지 확인합니다.
계약, 결제, 입고, 재고가 한 처리에 묶인 부분을 나누고 한 업무 수정이 다른 업무에 미치는 영향을 정리해야 합니다.
독립 체선 알림 집계 규칙 존재.
ccbio_erp/backend/src/modules/trade-contracts/detention-alerts.util.ts:25export function groupDetentionAlertRows
기존 업무 규칙 추출 대상. 서비스 전체를 그대로 이식하는 대상은 아님.
ccbio_erp/backend/src/modules/trade-contracts/trade-contracts.service.ts:176export class TradeContractsService
별도 쇼핑몰 관리자 화면(CMS)에서 회원·상품·주문·쿠폰·상담을 처리하고 있습니다.
새 데이터·공통 API를 기준으로 직원이 ERP 안에서 쇼핑몰 회원·주문·상품·행사 업무를 처리합니다. 실제 저장과 결제 관련 처리는 기존 쇼핑몰 기능을 이용하고, 직원마다 허용된 업무만 표시합니다.
ERP 직원이 담당 권한에 맞게 쇼핑몰 업무와 고객 정보를 이어서 확인할 수 있어야 합니다.
CMS 주문 변경 API 존재.
ccbio_ecommerce/apps/api/src/orders/cms-orders.controller.ts:124@Patch(':id')상품 변경 서비스 존재.
ccbio_ecommerce/apps/api/src/products/products.controller.ts:225this.productsService.update(
쿠폰 운영 컨트롤러 존재. ERP 권한 연결·API 범위는 확인 필요.
ccbio_ecommerce/apps/api/src/coupons/coupons.controller.ts:19@Controller(
쇼핑몰 고객 챗봇과 답변 자료·대화 내역 관리 기능은 운영 중입니다. 직원용 업무 챗봇은 새로 만들어야 합니다.
고객 챗봇의 답변·자료·로그 운영을 보호하면서 CMS Agent의 업무 분류·자체 처리·담당자 전달을 추가합니다. 직원 Agent는 RAG와 새 ERP API로 조회·초안·승인 후 실행을 수행합니다.
고객용 챗봇이 있다는 이유로 직원용 업무 기능도 이미 갖춰졌다고 보면 필요한 개발 작업을 빠뜨릴 수 있습니다.
기존 도구 호출형 답변 엔진 존재.
ccbio_erp/backend/src/modules/chatbot-seed/chatbot-answer.service.ts:323const calls = msg.tool_calls
기존 고객용 도구 정의. 직원용 권한·실행 도구는 별도 작업.
ccbio_erp/backend/src/modules/chatbot-seed/chatbot-tools.service.ts:111const tools:
SELECT 검사 후에도 생성 SQL을 직접 실행하는 경로. 신규 공통 실행 구조에 이식하지 않음.
ccbio_erp/backend/src/modules/data-chat/data-chat.service.ts:130this.dataSource.query(sql)
이카운트 연결과 문자 발송, 중복 확인, 발송 내역 기능이 있습니다.
새 데이터·공통 API를 기준으로 기존 회계·문자 서비스를 업무 화면에서 이어서 사용합니다. 실패한 건은 실제 처리 결과를 확인한 뒤 다시 처리하고, AI가 문자를 보낼 때도 받는 사람과 내용을 먼저 확인받습니다.
담당 권한과 발송 대상, 실패 후 재시도, 결과 확인을 업무 흐름에 맞춰 연결해야 합니다. 주문·재고 수치가 외부 처리 결과와 맞는지도 확인해야 합니다.
이카운트 어댑터 존재. 인증·현행 API 계약 검증 후 유지.
ccbio_erp/backend/src/modules/ecount/ecount.service.ts:9export class EcountService
메시지 발송 서비스에 중복 확인과 이력 처리 존재. 직원 권한·승인 연결은 별도.
ccbio_platform/src/messaging/messages/messages.service.ts:29async send(
여러 담당자의 전문 에이전트를 연결하는 공통 조율 기능은 이번에 새로 설계할 대상입니다.
팀장은 허용된 팀 문맥으로 배분·검토하고 Orchestrator는 팀 간 의존 관계와 실패 재개를 조율합니다. 실제 실행은 해당 담당 Agent의 권한·승인과 공통 API를 적용합니다.
업무가 부서 사이를 오갈 때 담당자·진행 상태·승인·실패 처리 기준이 필요합니다.
직원용 챗봇 개발 계획을 담당자별 전문 에이전트 구조로 확장합니다. 배정 기능이 운영 중이라는 뜻은 아닙니다.
각 담당자에게 자기 전문 분야의 AI를 배정합니다. 공통 전문 지식은 활용하면서 각자의 담당 대상·권한·진행 중인 업무·대화는 구분합니다.
같은 분야라도 담당 고객·창고·권한이 달라 각자의 업무 맥락을 구분해야 합니다.
담당자별 전문 에이전트와 협업 기능의 품질·비용·운영 기준은 신규 정의 대상입니다.
업무별 정확도·처리 시간·담당자 개입·비용을 측정합니다. 문제 있는 버전은 적용을 멈추고, 담당자가 업무를 이어받을 수 있도록 실행 내역과 중단·복구 기능을 제공합니다.
답변이 자연스러운지만으로 실제 업무가 정확하게 끝나는지 판단할 수 없습니다.
| 현재 화면·주소 | 메뉴 변경 방식 | 앞으로 사용할 메뉴 | 바꾸는 방식 |
|---|---|---|---|
인증/auth/callback | 수정 | 시스템 / 계정·역할·업무권한 | 해당 업무 재개발 |
챗봇 대화 로그/chatbot-seed/logs | 유지·필요 보완 | 커머스 운영 / 쇼핑몰 챗봇 지식·품질 관리 | 기능 추가 · 기능 보완 |
챗봇 SEED 수집/chatbot-seed | 유지·필요 보완 | 커머스 운영 / 쇼핑몰 챗봇 지식·품질 관리 | 기능 추가 · 기능 보완 |
챗봇 SEED 검수/chatbot-seed/review | 유지·필요 보완 | 커머스 운영 / 쇼핑몰 챗봇 지식·품질 관리 | 기능 추가 · 기능 보완 |
챗봇 RAG 소스/chatbot-seed/sources | 유지·필요 보완 | 커머스 운영 / 쇼핑몰 챗봇 지식·품질 관리 | 기능 추가 · 기능 보완 |
코드 관리/codes | 통합·이동 | 기준정보 / 코드·회사·업무정책 | 해당 업무 재개발 |
재고 대시보드/consultations/dashboard | 통합·이동 | 업무 홈 / 직무별 현황 | 해당 업무 재개발 |
상담 관리/consultations | 통합·이동 | 고객·농가 / 상담·활동 | 해당 업무 재개발 |
상담 통계/consultations/stats | 통합·이동 | 고객·농가 / 상담·활동 | 해당 업무 재개발 |
고객 현황/customers/dashboard | 통합·이동 | 업무 홈 / 직무별 현황 | 해당 업무 재개발 |
고객 관리/customers | 통합·이동 | 고객·농가 / 통합 프로필 | 해당 업무 재개발 |
대시보드/dashboard | 통합·이동 | 업무 홈 / 직무별 현황 | 해당 업무 재개발 |
사용자 관리/dashboard/users | 폐지·대체 | 시스템 / 계정·역할·업무권한 | 해당 업무 재개발 |
/data-chat/data-chat | 용도 확인 | 기존 /data-chat · 사용·노출 여부 확인 | 변경 미정 · 신규 직원 챗봇과 별도 |
배차 업체 관리/dispatch-companies | 통합·이동 | 기준정보 / 거래처·창고·협력사 | 해당 업무 재개발 |
배차 업체 직원 관리/dispatch-company-employees | 통합·이동 | 기준정보 / 거래처·창고·협력사 | 해당 업무 재개발 |
배차관리/dispatch-company/dispatch-management | 통합·이동 | 협력사 업무 / 배정 작업 | 해당 업무 재개발 |
입고확정/finance/inventory-confirmed | 실사용 유지·필요 보완 | 재고·물류 / 재고 원장·가용량 | 해당 업무 재개발 |
입고예정/finance/inventory-pending | 실사용 유지·필요 보완 | 재고·물류 / 재고 원장·가용량 | 해당 업무 재개발 |
결제 완료/finance/payment-completed | 통합·이동 | 재무 / 매입결제·송금 | 해당 업무 재개발 |
결제관리/finance/payment-management | 통합·이동 | 재무 / 매입결제·송금 | 해당 업무 재개발 |
결제 대기/finance/payment-pending | 통합·이동 | 재무 / 매입결제·송금 | 해당 업무 재개발 |
선입금 관리/finance/prepayments | 통합·이동 | 재무 / 채권·수금·선입금 | 해당 업무 재개발 |
수금 관리/finance/receivables/collect | 통합·이동 | 재무 / 채권·수금·선입금 | 해당 업무 재개발 |
이카운트 잔액 비교/finance/receivables/compare-excel | 통합·이동 | 재무 / 채권·수금·선입금 | 해당 업무 재개발 |
입금예상액/finance/receivables/expected | 통합·이동 | 재무 / 채권·수금·선입금 | 해당 업무 재개발 |
거래처관리대장/finance/receivables/ledger | 통합·이동 | 재무 / 채권·수금·선입금 | 해당 업무 재개발 |
채권관리/finance/receivables | 통합·이동 | 재무 / 채권·수금·선입금 | 해당 업무 재개발 |
채권 경고 문자 발송 이력/finance/receivables/sms-batch-history | 통합·이동 | 재무 / 채권·수금·선입금 | 해당 업무 재개발 |
채권 경고 설정/finance/receivables/warning-config | 통합·이동 | 재무 / 채권·수금·선입금 | 해당 업무 재개발 |
FT 관리/free-time | 통합·이동 | 무역 / 국제물류·통관 | 해당 업무 재개발 |
구글 드라이브/google-drive | 통합·이동 | 업무별 증빙 / 연계 설정 | 해당 업무 재개발 |
입고 확정/inbound/confirmed | 실사용 보완·필수 신규 | 재고·물류 / 입고 | 해당 업무 재개발 |
입고 관리/inbound | 숨김 | 미사용 구메뉴 · 메뉴에서 숨김 | 기능 개발 제외 · 메뉴 숨김 |
입고 대기/inbound/pending | 실사용 보완·필수 신규 | 재고·물류 / 입고 | 해당 업무 재개발 |
입고 예정/inbound/scheduled | 실사용 보완·필수 신규 | 재고·물류 / 입고 | 해당 업무 재개발 |
입고확정재고/inventory/confirmed | 실사용 유지·필요 보완 | 재고·물류 / 재고 원장·가용량 | 해당 업무 재개발 |
재고 관리/inventory | 실사용 유지·필요 보완 | 재고·물류 / 재고 원장·가용량 | 해당 업무 재개발 |
입고예정재고/inventory/pending | 실사용 유지·필요 보완 | 재고·물류 / 재고 원장·가용량 | 해당 업무 재개발 |
입고 관리/loading-company/inbound-management | 통합·이동 | 협력사 업무 / 배정 작업 | 해당 업무 재개발 |
상차관리/loading-company/loading-management | 통합·이동 | 협력사 업무 / 배정 작업 | 해당 업무 재개발 |
로그인/login | 수정 | 시스템 / 계정·역할·업무권한 | 해당 업무 재개발 |
부킹/logistics/booking | 통합·이동 | 무역 / 국제물류·통관 | 해당 업무 재개발 |
통관 처리/logistics/customs-processing | 통합·이동 | 무역 / 국제물류·통관 | 해당 업무 재개발 |
DO 처리/logistics/do-processing | 통합·이동 | 무역 / 국제물류·통관 | 해당 업무 재개발 |
서류 처리/logistics/documents-processing | 통합·이동 | 무역 / 국제물류·통관 | 해당 업무 재개발 |
서류 처리/logistics/documents | 폐지·대체 | 무역 / 국제물류·통관 | 해당 업무 재개발 |
ETA 정보 갱신 이력/logistics/eta-update-history | 통합·이동 | 무역 / 국제물류·통관 | 해당 업무 재개발 |
물류관리/logistics/management | 통합·이동 | 무역 / 국제물류·통관 | 해당 업무 재개발 |
일별 데이터 관리/mall-stats/daily | 통합·이동 | 커머스 운영 / 회원·상품·주문·배송·프로모션 | 해당 업무 재개발 |
대시보드/mall-stats | 통합·이동 | 커머스 운영 / 회원·상품·주문·배송·프로모션 | 해당 업무 재개발 |
유기축산 인증 관리/organic-certifications | 통합·이동 | 고객·농가 / 증빙·인증 | 해당 업무 재개발 |
홈/ | 통합·이동 | 업무 홈 / 직무별 현황 | 해당 업무 재개발 |
승인 대기/pending-approval | 수정 | 시스템 / 계정·역할·업무권한 | 해당 업무 재개발 |
회원가입/register | 수정 | 시스템 / 계정·역할·업무권한 | 해당 업무 재개발 |
안전운임 요금표 관리/safe-freight-rates | 통합·이동 | 기준정보 / 코드·회사·업무정책 | 해당 업무 재개발 |
대시보드/sales/dashboard | 통합·이동 | 업무 홈 / 직무별 현황 | 해당 업무 재개발 |
입고 확정/sales/inbound/confirmed | 실사용 보완·필수 신규 | 재고·물류 / 입고 | 해당 업무 재개발 |
입고 대기/sales/inbound/pending | 실사용 보완·필수 신규 | 재고·물류 / 입고 | 해당 업무 재개발 |
입고 예정/sales/inbound/scheduled | 실사용 보완·필수 신규 | 재고·물류 / 입고 | 해당 업무 재개발 |
입고확정재고/sales/inventory/confirmed | 실사용 유지·필요 보완 | 재고·물류 / 재고 원장·가용량 | 해당 업무 재개발 |
입고예정재고/sales/inventory/pending | 실사용 유지·필요 보완 | 재고·물류 / 재고 원장·가용량 | 해당 업무 재개발 |
거래명세서 관리/sales/invoice-management | 통합·이동 | 영업 / 거래명세서 | 해당 업무 재개발 |
/sales/management-v2/inventory/sales/management-v2/inventory | 실사용 유지·필요 보완 | 재고·물류 / 재고 원장·가용량 | 해당 업무 재개발 |
판매관리 (신규)/sales/management-v2 | 실사용 유지·필요 보완 | 영업 / 판매 | 해당 업무 재개발 |
판매관리 (신규)/sales/management-v2/sales | 실사용 유지·필요 보완 | 영업 / 판매 | 해당 업무 재개발 |
판매관리/sales | 실사용 유지·필요 보완 | 영업 / 판매 | 해당 업무 재개발 |
판매예약/sales/product-reservations-sheet | 실사용 유지·필요 보완 | 영업 / 견적·예약 | 해당 업무 재개발 |
판매예약/sales/product-reservations | 실사용 유지·필요 보완 | 영업 / 견적·예약 | 해당 업무 재개발 |
견적서/sales/quotation-sheet | 실사용 유지·필요 보완 | 영업 / 견적·예약 | 해당 업무 재개발 |
기사별 운송/sales/transport-management/by-driver | 실사용 유지·필요 보완 | 재고·물류 / 배차·상하차·배송 | 해당 업무 재개발 |
판매·운송 불일치/sales/transport-management/mismatch | 실사용 유지·필요 보완 | 재고·물류 / 배차·상하차·배송 | 해당 업무 재개발 |
운송비 통계/sales/transport-management/transport-fee-stats | 실사용 유지·필요 보완 | 재고·물류 / 배차·상하차·배송 | 해당 업무 재개발 |
운송관리/sales/transport-management/transport | 실사용 유지·필요 보완 | 재고·물류 / 배차·상하차·배송 | 해당 업무 재개발 |
스케줄 관리/schedules | 숨김 | 미사용 구메뉴 · 메뉴에서 숨김 | 기능 개발 제외 · 메뉴 숨김 |
회사 정보 관리/settings/company-info | 통합·이동 | 기준정보 / 코드·회사·업무정책 | 해당 업무 재개발 |
입고 기본 설정/settings/inbound-defaults | 통합·이동 | 기준정보 / 코드·회사·업무정책 | 해당 업무 재개발 |
법정동 마스터/settings/legal-admin-master | 통합·이동 | 기준정보 / 코드·회사·업무정책 | 해당 업무 재개발 |
SMS 발송 이력/sms-history | 통합·이동 | 고객·농가 / 메시지 운영 | 해당 업무 재개발 |
SMS 관리/sms-management | 통합·이동 | 고객·농가 / 메시지 운영 | 해당 업무 재개발 |
SMS 발신자 관리/sms-senders | 통합·이동 | 고객·농가 / 메시지 운영 | 해당 업무 재개발 |
SMS 템플릿 관리/sms-templates | 통합·이동 | 고객·농가 / 메시지 운영 | 해당 업무 재개발 |
SMS 발송 테스트/sms-test | 폐지·대체 | 고객·농가 / 메시지 운영 | 해당 업무 재개발 |
공급자 관리/suppliers | 통합·이동 | 기준정보 / 거래처·창고·협력사 | 해당 업무 재개발 |
계약/trade/contract-confirmed | 통합·이동 | 무역 / 구매·계약·발주 | 해당 업무 재개발 |
구매관리/trade/management | 통합·이동 | 무역 / 구매·계약·발주 | 해당 업무 재개발 |
발주/trade/order | 통합·이동 | 무역 / 구매·계약·발주 | 해당 업무 재개발 |
대시보드/transport/dashboard | 숨김 | 미사용 구메뉴 · 메뉴에서 숨김 | 기능 개발 제외 · 메뉴 숨김 |
배차완료/transport/dispatch-completed | 숨김 | 미사용 구메뉴 · 메뉴에서 숨김 | 기능 개발 제외 · 메뉴 숨김 |
배차중/transport/dispatch-dispatching | 숨김 | 미사용 구메뉴 · 메뉴에서 숨김 | 기능 개발 제외 · 메뉴 숨김 |
배차실패/transport/dispatch-failed | 숨김 | 미사용 구메뉴 · 메뉴에서 숨김 | 기능 개발 제외 · 메뉴 숨김 |
배차관리/transport/dispatch-management | 숨김 | 미사용 구메뉴 · 메뉴에서 숨김 | 기능 개발 제외 · 메뉴 숨김 |
배차요청/transport/dispatch-request | 숨김 | 미사용 구메뉴 · 메뉴에서 숨김 | 기능 개발 제외 · 메뉴 숨김 |
일정조정/transport/dispatch-rescheduled | 숨김 | 미사용 구메뉴 · 메뉴에서 숨김 | 기능 개발 제외 · 메뉴 숨김 |
상차완료/transport/loading-completed | 숨김 | 미사용 구메뉴 · 메뉴에서 숨김 | 기능 개발 제외 · 메뉴 숨김 |
상차중/transport/loading | 숨김 | 미사용 구메뉴 · 메뉴에서 숨김 | 기능 개발 제외 · 메뉴 숨김 |
하차완료/transport/unloading-completed | 숨김 | 미사용 구메뉴 · 메뉴에서 숨김 | 기능 개발 제외 · 메뉴 숨김 |
하차 업체 관리/unloading-companies | 통합·이동 | 기준정보 / 거래처·창고·협력사 | 해당 업무 재개발 |
사용자 관리/users | 통합·이동 | 시스템 / 계정·역할·업무권한 | 해당 업무 재개발 |
권한 관리/users/permissions | 통합·이동 | 시스템 / 계정·역할·업무권한 | 해당 업무 재개발 |
배차 관리/vehicle-dispatch-user | 숨김 | 미사용 구메뉴 · 메뉴에서 숨김 | 기능 개발 제외 · 메뉴 숨김 |
배차 관리/vehicle-dispatch-warehouse | 숨김 | 미사용 구메뉴 · 메뉴에서 숨김 | 기능 개발 제외 · 메뉴 숨김 |
배차 관리/vehicle-dispatch | 숨김 | 미사용 구메뉴 · 메뉴에서 숨김 | 기능 개발 제외 · 메뉴 숨김 |
직원 관리/warehouse-employees | 통합·이동 | 기준정보 / 거래처·창고·협력사 | 해당 업무 재개발 |
창고 이고비 관리/warehouse-igobi | 통합·이동 | 기준정보 / 거래처·창고·협력사 | 해당 업무 재개발 |
창고 관리/warehouses | 통합·이동 | 기준정보 / 거래처·창고·협력사 | 해당 업무 재개발 |
각 항목에서 확인 내용과 관련 WBS 작업을 볼 수 있습니다.
고객정보에 등록해놓고 며칠 뒤면 또 사라져있고, 등록하기를 계속 반복하고 잇거든여...그것때문에 연결되어 있는 명세서도 자꾸 오류가 나네요..ㅜㅜ
출처: 2026-10-15 사용자가 전달한 현업 제보
관련 항목은 조사 참고 경로이며 동일 원인으로 확인된 것은 아니다.
기록 출처: 기존 운영 기록 117행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 연결된 수정 커밋은 저장소에 존재하는지와 제목을 대조했으며, 이 확인을 현재 운영 상태나 원인 재현으로 간주하지 않는다.
원기록의 근거 표기: 07a7cbe, docs/INVOICE_RECIPIENT_MISSEND_ANALYSIS.md, 메모 invoice-recipient-missend
07a7cbe1 · 2026-08-24 · feat(sales): 거래명세서 발행·발송 전 수취인 대조 경고기록 출처: 기존 운영 기록 118행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 연결된 수정 커밋은 저장소에 존재하는지와 제목을 대조했으며, 이 확인을 현재 운영 상태나 원인 재현으로 간주하지 않는다.
원기록의 근거 표기: a09d657, backups/2026-09-08-customer-4660/(백업 3·복구/롤백 SQL 4), 메모 consultation-phone-zero-overwrite
a09d657f · 2026-09-08 · fix(consultations): 상담 등록/수정에서 고객 마스터 덮어쓰기 제거 — 연결 또는 신규 등록만 허용기록 출처: 기존 운영 기록 119행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 연결된 수정 커밋은 저장소에 존재하는지와 제목을 대조했으며, 이 확인을 현재 운영 상태나 원인 재현으로 간주하지 않는다.
원기록의 근거 표기: c5bfc50, 메모 inbound-506-status-db-fix
c5bfc509 · 2026-08-11 · fix(inbound): 서류처리가 진행된 부킹의 영업 상태를 입고대기로 되돌리던 문제기록 출처: 기존 운영 기록 120행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 연결된 수정 커밋은 저장소에 존재하는지와 제목을 대조했으며, 이 확인을 현재 운영 상태나 원인 재현으로 간주하지 않는다.
원기록의 근거 표기: 2b306ea, sales-delivery.service.ts:3987-4035 주석, 메모 transport-loading-info-loss
2b306ea3 · 2026-09-09 · fix(sales-delivery): 상차 행 재생성 시 상차일정·실적값을 기존 행에서 승계 — 하차완료 건 상차지·상차일정 공백 방어기록 출처: 기존 운영 기록 121행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 연결된 수정 커밋은 저장소에 존재하는지와 제목을 대조했으며, 이 확인을 현재 운영 상태나 원인 재현으로 간주하지 않는다.
원기록의 근거 표기: 051a5ab
051a5abe · 2026-06-22 · fix(sales-delivery): prevent loading item loss on status-only edit기록 출처: 기존 운영 기록 122행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 연결된 수정 커밋은 저장소에 존재하는지와 제목을 대조했으며, 이 확인을 현재 운영 상태나 원인 재현으로 간주하지 않는다.
원기록의 근거 표기: 1b16c69, sales-delivery.service.ts:1429, 3092
1b16c698 · 2026-06-17 · fix(unloading): 하차완료 판매값 오반영 재발방지 (AM-2606-0016)기록 출처: 기존 운영 기록 123행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 연결된 수정 커밋은 저장소에 존재하는지와 제목을 대조했으며, 이 확인을 현재 운영 상태나 원인 재현으로 간주하지 않는다.
원기록의 근거 표기: 7c09414
7c09414b · 2026-06-22 · fix(sales-delivery): 하차완료 상태 운송 수정 시 loadingItems 제외기록 출처: 기존 운영 기록 124행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 연결된 수정 커밋은 저장소에 존재하는지와 제목을 대조했으며, 이 확인을 현재 운영 상태나 원인 재현으로 간주하지 않는다.
원기록의 근거 표기: edd64f0
edd64f01 · 2026-06-19 · fix(unloading): actual 컨테이너 확정 시 작업 컨테이너 검증 우회 및 카고 타입 보존기록 출처: 기존 운영 기록 125행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 연결된 수정 커밋은 저장소에 존재하는지와 제목을 대조했으며, 이 확인을 현재 운영 상태나 원인 재현으로 간주하지 않는다.
원기록의 근거 표기: 00e1718
00e17180 · 2026-08-11 · fix(sales): SMS 발송만으로 이카운트 처리 상태가 확인 필요로 되돌아가던 문제기록 출처: 기존 운영 기록 126행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 연결된 수정 커밋은 저장소에 존재하는지와 제목을 대조했으며, 이 확인을 현재 운영 상태나 원인 재현으로 간주하지 않는다.
원기록의 근거 표기: 8bfd275, 791884d, b50867c, backups/product-reservations-sheet-*
791884d7 · 2026-08-04 · fix(sales): 판매예약 엑셀 복구가 끝나기 전에 화면을 벗어나면 남은 행이 저장되지 않던 문제8bfd2756 · 2026-08-04 · fix(sales): 판매예약 엑셀 복구 시 BL 값이 반영되지 않던 문제 수정b50867c9 · 2026-08-04 · feat(sales): 판매예약 엑셀 복구를 전체 교체로 변경 + BK 되짚기 매칭기록 출처: 기존 운영 기록 127행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 연결된 수정 커밋은 저장소에 존재하는지와 제목을 대조했으며, 이 확인을 현재 운영 상태나 원인 재현으로 간주하지 않는다.
원기록의 근거 표기: 36ebf93
36ebf93e · 2026-08-24 · fix(sales): 판매예약 시트에서 동명 업체의 연락처·주소가 사라지던 문제기록 출처: 기존 운영 기록 128행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 연결된 수정 커밋은 저장소에 존재하는지와 제목을 대조했으며, 이 확인을 현재 운영 상태나 원인 재현으로 간주하지 않는다.
원기록의 근거 표기: fd563d0, 메모 sheet-customer-name-sync
fd563d00 · 2026-09-09 · feat(sales-reservation-sheet): 고객 상호 변경을 판매예약 시트 업체명에 반영기록 출처: 기존 운영 기록 129행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 원기록에 기재된 운영 메모·DB·로그 등 원자료와 현재 운영 상태는 이번에 재확인하지 않았다.
원기록의 근거 표기: docs/RESTORE_20260326_DECOMMISSION.md 3장, backups/deleted_customers_30.csv, backups/restore-20260326_ccbio_erp_20260820.dump
기록 출처: 기존 운영 기록 135행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 원기록에 기재된 운영 메모·DB·로그 등 원자료와 현재 운영 상태는 이번에 재확인하지 않았다.
원기록의 근거 표기: 메모 collect-sms-false-success, aligo.service.ts
기록 출처: 기존 운영 기록 136행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 연결된 수정 커밋은 저장소에 존재하는지와 제목을 대조했으며, 이 확인을 현재 운영 상태나 원인 재현으로 간주하지 않는다.
원기록의 근거 표기: 3476e1a, edf2ff2, f550119, c94ef08, 4c785c0, 904a2e7, b4173a2, 177de3f
177de3f6 · 2026-07-01 · fix(sales-delivery): 하차완료 컨테이너 분할·재고 갱신 타이밍 수정3476e1a5 · 2026-06-09 · Fix unloading container swap sync and enhance customer/logistics features.4c785c08 · 2026-06-18 · fix(unloading): 컨테이너 타입 하차완료 시 베일·중량 입력 필수 해제904a2e7b · 2026-06-18 · fix(unloading): 요청 컨테이너 타입일 때 카고 검증 오적용 방지b4173a29 · 2026-06-18 · fix(unloading): 하차완료 검증 오류 메시지 구체화 및 BL 초기값 보정c94ef087 · 2026-06-18 · fix(unloading): 작업 중량 없이도 실제 중량으로 하차완료 허용edf2ff2a · 2026-06-11 · Refactor unloading completion to guarantee SalesItem status sync via finally blockf550119b · 2026-06-11 · Refactor: 하차완료 SalesItem 상태 반영 로직 개선기록 출처: 기존 운영 기록 137행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 연결된 수정 커밋은 저장소에 존재하는지와 제목을 대조했으며, 이 확인을 현재 운영 상태나 원인 재현으로 간주하지 않는다.
원기록의 근거 표기: 58414ad
58414add · 2026-08-27 · fix(codes): 코드 카테고리(parentId) 수정이 저장되지 않던 문제기록 출처: 기존 운영 기록 138행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 연결된 수정 커밋은 저장소에 존재하는지와 제목을 대조했으며, 이 확인을 현재 운영 상태나 원인 재현으로 간주하지 않는다.
원기록의 근거 표기: ffb8034
ffb80346 · 2026-06-08 · Fix arrival port and inbound quarantine display across dashboard and inventory.기록 출처: 기존 운영 기록 139행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 연결된 수정 커밋은 저장소에 존재하는지와 제목을 대조했으며, 이 확인을 현재 운영 상태나 원인 재현으로 간주하지 않는다.
원기록의 근거 표기: 381f5cb
381f5cbd · 2026-06-11 · Fix receivables sorting and add transport fee stats.기록 출처: 기존 운영 기록 140행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 연결된 수정 커밋은 저장소에 존재하는지와 제목을 대조했으며, 이 확인을 현재 운영 상태나 원인 재현으로 간주하지 않는다.
원기록의 근거 표기: e6c1644
e6c16445 · 2026-06-11 · Fix: 거래명세서 품목 잘림 이슈 수정기록 출처: 기존 운영 기록 141행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 연결된 수정 커밋은 저장소에 존재하는지와 제목을 대조했으며, 이 확인을 현재 운영 상태나 원인 재현으로 간주하지 않는다.
원기록의 근거 표기: 1daba2b, 메모 inventory-confirmed-sort-plan
1daba2b9 · 2026-07-29 · fix(inventory): 입고확정재고 컨번호 정렬을 BL → [N] 순번 기준으로 변경기록 출처: 기존 운영 기록 142행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 연결된 수정 커밋은 저장소에 존재하는지와 제목을 대조했으며, 이 확인을 현재 운영 상태나 원인 재현으로 간주하지 않는다.
원기록의 근거 표기: dfdab65
dfdab659 · 2026-08-27 · fix(sales-reservation-sheet): 고객 주소 표시에서 지역·상세주소 중복 제거기록 출처: 기존 운영 기록 143행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 연결된 수정 커밋은 저장소에 존재하는지와 제목을 대조했으며, 이 확인을 현재 운영 상태나 원인 재현으로 간주하지 않는다.
원기록의 근거 표기: d0ed1fd
d0ed1fd4 · 2026-09-29 · fix(sales): 거래명세서 수신자 주소를 도로명 우선으로 표시기록 출처: 기존 운영 기록 144행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 연결된 수정 커밋은 저장소에 존재하는지와 제목을 대조했으며, 이 확인을 현재 운영 상태나 원인 재현으로 간주하지 않는다.
원기록의 근거 표기: 4476bc7
4476bc7d · 2026-06-22 · fix(배차관리): 상·하차일 DatePicker 적용 및 날짜 형식 정규화기록 출처: 기존 운영 기록 145행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 연결된 수정 커밋은 저장소에 존재하는지와 제목을 대조했으며, 이 확인을 현재 운영 상태나 원인 재현으로 간주하지 않는다.
원기록의 근거 표기: d5546e1, 449e6a1
449e6a16 · 2026-07-02 · fix(customers): 고객 엑셀 export 주소 컬럼에 시/도 fallback 추가d5546e1a · 2026-07-02 · fix(customers): 고객 관리 엑셀 다운로드에 누락 컬럼 추가기록 출처: 기존 운영 기록 146행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 연결된 수정 커밋은 저장소에 존재하는지와 제목을 대조했으며, 이 확인을 현재 운영 상태나 원인 재현으로 간주하지 않는다.
원기록의 근거 표기: 3ea89f2
3ea89f29 · 2026-07-14 · fix(frontend): 로그인 무한 리다이렉트 루프 해결 및 로컬 포트 충돌 방지용 동적 API 포트 매핑 적용기록 출처: 기존 운영 기록 147행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 원기록에 기재된 운영 메모·DB·로그 등 원자료와 현재 운영 상태는 이번에 재확인하지 않았다.
원기록의 근거 표기: 메모 trade-management-slowdown-analysis
기록 출처: 기존 운영 기록 153행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 연결된 수정 커밋은 저장소에 존재하는지와 제목을 대조했으며, 이 확인을 현재 운영 상태나 원인 재현으로 간주하지 않는다.
원기록의 근거 표기: 10284fa, 메모 searates-to-trackingone-migration
10284faa · 2026-08-26 · feat(trade-contracts): 컨테이너 추적 API를 SeaRates에서 tracking.one으로 교체기록 출처: 기존 운영 기록 154행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 원기록에 기재된 운영 메모·DB·로그 등 원자료와 현재 운영 상태는 이번에 재확인하지 않았다.
원기록의 근거 표기: 메모 trackingone-plan-quota
기록 출처: 기존 운영 기록 155행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 원기록에 기재된 운영 메모·DB·로그 등 원자료와 현재 운영 상태는 이번에 재확인하지 않았다.
원기록의 근거 표기: 메모 trackingone-plan-quota
기록 출처: 기존 운영 기록 156행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 원기록에 기재된 운영 메모·DB·로그 등 원자료와 현재 운영 상태는 이번에 재확인하지 않았다.
원기록의 근거 표기: 메모 cloudsql-max-connections-100
기록 출처: 기존 운영 기록 157행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 연결된 수정 커밋은 저장소에 존재하는지와 제목을 대조했으며, 이 확인을 현재 운영 상태나 원인 재현으로 간주하지 않는다.
원기록의 근거 표기: 27d5ae3
27d5ae35 · 2026-06-11 · fix(docker): correct NestJS entrypoint to dist/src/main.js기록 출처: 기존 운영 기록 158행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 연결된 수정 커밋은 저장소에 존재하는지와 제목을 대조했으며, 이 확인을 현재 운영 상태나 원인 재현으로 간주하지 않는다.
원기록의 근거 표기: 4be5524
4be55248 · 2026-06-17 · fix(deploy): CRON_SECRET 환경변수 Cloud Run 배포 스크립트에 추가기록 출처: 기존 운영 기록 159행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 연결된 수정 커밋은 저장소에 존재하는지와 제목을 대조했으며, 이 확인을 현재 운영 상태나 원인 재현으로 간주하지 않는다.
원기록의 근거 표기: 4016104, 985d04e
4016104a · 2026-08-24 · perf(build): 빌드마다 node_modules 1.6GB 를 업로드하던 문제 + 레이어 순서 교정985d04e2 · 2026-08-24 · perf(build): 업로드에서 Cloud SQL Proxy 바이너리 60MB 를 제외한다기록 출처: 기존 운영 기록 160행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 연결된 수정 커밋은 저장소에 존재하는지와 제목을 대조했으며, 이 확인을 현재 운영 상태나 원인 재현으로 간주하지 않는다.
원기록의 근거 표기: 88d8004 → bddf7d0
88d80042 · 2026-08-24 · feat(db): RDS SSL 대응 — CA 번들 기반 ssl 옵션과 풀 상한을 env 로 분리bddf7d0d · 2026-08-24 · fix(db): RDS CA 번들이 이미지에 없어 부팅이 죽는 문제 + CA 경로 탐색기록 출처: 기존 운영 기록 161행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 연결된 수정 커밋은 저장소에 존재하는지와 제목을 대조했으며, 이 확인을 현재 운영 상태나 원인 재현으로 간주하지 않는다.
원기록의 근거 표기: 83f8662, 928cf20
83f86625 · 2026-09-11 · ci(deploy): docs/·*.md 만 바뀐 main 푸시는 AWS 배포 생략(paths-ignore)928cf208 · 2026-09-11 · ci(deploy): 모든 docs 폴더(backend/docs 등)를 배포 제외 대상에 포함기록 출처: 기존 운영 기록 162행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 연결된 수정 커밋은 저장소에 존재하는지와 제목을 대조했으며, 이 확인을 현재 운영 상태나 원인 재현으로 간주하지 않는다.
원기록의 근거 표기: 같은 커밋들, 메모 erp-local-dev-rds-tunnel
2ebffd0b · 2026-09-09 · fix(app.module): DB SSL 설정을 .env 로드 뒤에 계산 — 로컬 nest start 가 RDS 에 SSL 없이 붙어 기동 실패하던 문제b812ee8a · 2026-09-07 · fix(aws): db-tunnel.bat — cmd 파싱 오류 수정 (CP949+CRLF, 괄호 블록 대신 goto, 명령 줄은 영문만)d7bedd54 · 2026-09-08 · fix(aws): db-tunnel — ~/.aws/config 에 [profile ccbio] 가 없으면 스크립트가 만든다dd0148aa · 2026-09-14 · fix(tools): RDS 터널 keepalive — SSM 유휴 타임아웃(20분→계정 설정 60분)으로 끊기던 문제, 5분마다 pg_isready 로 유지기록 출처: 기존 운영 기록 163행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 연결된 수정 커밋은 저장소에 존재하는지와 제목을 대조했으며, 이 확인을 현재 운영 상태나 원인 재현으로 간주하지 않는다.
원기록의 근거 표기: 676f33b
676f33b3 · 2026-09-15 · chore: docs/ 를 git 에서 제외 — 추적 중이던 문서 16개 인덱스 제거(로컬 파일 유지), TRACKINGONE 예외 삭제기록 출처: 기존 운영 기록 164행 · 2026-10-12 작성
기존 조사 문서의 해당 행을 확인했다. 원기록에 기재된 운영 메모·DB·로그 등 원자료와 현재 운영 상태는 이번에 재확인하지 않았다.
원기록의 근거 표기: 메모 safe-freight-rate-import-plan, safe-freight-rate.service.ts:569-575
738 if (updateCustomerDto.contacts !== undefined) {
739 await this.syncCustomerContacts(updated.id, contacts);
740 }
741 990 private async syncCustomerContacts(
991 customerId: string,
992 items: CustomerContactItemDto[] | undefined,
993 ): Promise<void> {
994 if (items === undefined) return;
995
996 const valid = items
997 .map((item) => ({
998 id: item.id?.trim() || undefined,
999 name: (item.name ?? '').trim(),
1000 phone: item.phone?.trim() || null,
1001 relationship: item.relationship?.trim() || null,
1002 }))
1003 .filter((item) => item.name.length > 0);
1004
1005 const existing = await this.contactRepository.find({
1006 where: { customerId },
1007 order: { createdAt: 'ASC' },
1008 });
1009
1010 const keepIds = new Set(
1011 valid
1012 .map((v) => v.id)
1013 .filter((id): id is string => !!id && /^\d+$/.test(id)),
1014 );
1015
1016 for (const row of existing) {
1017 if (!keepIds.has(row.id)) {
1018 await this.contactRepository.remove(row);
1019 }
1020 }
1021
1022 for (const item of valid) {
1023 if (item.id && keepIds.has(item.id)) {
1024 const row = existing.find((e) => e.id === item.id);
1025 if (row) {
1026 row.name = item.name; 1017 if (!keepIds.has(row.id)) {
1018 await this.contactRepository.remove(row);
1019 }
1020 } 979 async remove(id: string): Promise<void> {
980 const customer = await this.customersRepository.findOne({ where: { id } });
981 if (!customer) {
982 throw new NotFoundException('고객 정보를 찾을 수 없습니다.');
983 }
984 await this.customersRepository.remove(customer);
985 } 53 @ManyToOne(() => Customer, { nullable: true, onDelete: 'SET NULL' })
54 @JoinColumn({ name: 'cu_id' })
55 customer?: Customer | null; 64 @Column({ name: 'iv_company_name', length: 150, nullable: true })
65 companyName?: string | null;
66
67 @Column({ name: 'iv_ceo', length: 100, nullable: true })
68 ceo?: string | null;
69
70 @Column({ name: 'iv_phone', length: 50, nullable: true })
71 phone?: string | null; 21 @ManyToOne(() => Customer, { onDelete: 'CASCADE' })
22 @JoinColumn({ name: 'cu_id' })
23 customer?: Customer | null;순수 함수 재현 · 운영 DB·전체 화면 검증과 구분
독립 함수 원문을 그대로 실행. 발행일이 29~31일인 경계 사례이며 실제 운영 중 영향 건수는 별도 조사 필요.
26 function addMonths(date: Date, months: number): Date {
27 const result = new Date(date);
28 result.setMonth(result.getMonth() + months);
29 return result;
30 } 89 case 'NEXT_MONTH_DAY': {
90 // 다음달 N일
91 const day = paymentTermsValue ?? 1;
92 const nextMonth = addMonths(baseDate, 1);
93 nextMonth.setHours(0, 0, 0, 0);
94 return getMonthDay(nextMonth, day);
95 } 107 case 'NEXT_MONTH_END': {
108 // 다음달 마지막일
109 const nextMonth = addMonths(baseDate, 1);
110 nextMonth.setHours(0, 0, 0, 0);
111 const monthEnd = getMonthEnd(nextMonth);
112 monthEnd.setHours(0, 0, 0, 0);
113 return monthEnd;
114 }646 paymentDueDates.push( 647 calculatePaymentDueDate( 648 inv.issuedAt, 649 paymentTermsType as any, 650 paymentTermsValue ?? undefined, 651 ), 652 ); 653 }
서비스 로직 재현 · 운영 DB·전체 화면 검증과 구분
기존 전화번호 0인 고객이 있을 때의 서비스 경로. 전체 화면·DB 실행은 아님.
118 const digits = phone.replace(/[^0-9]/g, ''); 119 return digits.length > 0 ? digits : null; 120 }
301 if (!customerIdProvided && !customer && dto.phone) {
302 const normalized = this.normalizePhone(dto.phone);
303 if (normalized) {
304 customer = await customerRepo
305 .createQueryBuilder('customer')
306 .leftJoinAndSelect('customer.regionEntity', 'region')
307 .leftJoinAndSelect('customer.cityEntity', 'city')
308 .where("regexp_replace(customer.cu_phone, '[^0-9]', '', 'g') = :normalized", { normalized })
309 .getOne();
310 } 336 if (dto.companyName !== undefined) {
337 customer.companyName = this.sanitize(dto.companyName);
338 }
339
340 if (dto.ceo !== undefined) {
341 customer.ceo = this.sanitize(dto.ceo);
342 }
343 636 const customer = await this.upsertCustomer(dto, manager, {
637 skipCustomerAddressUpdates: Boolean(deliveryAddrIdCreate),
638 });
639 if (!customer) {77 phone?: string;
서비스 로직 재현 · 운영 DB·전체 화면 검증과 구분
이미 mallUserId로 연결된 고객의 DTO 작성·코드 변환·update 저장 경로를 실행. 코드표는 가상 데이터이며 실제 DB·전화번호 중복 매칭은 별도 검증 대상.
21 @Post('sync')
22 @ApiOperation({
23 summary: '몰 회원 → ERP 고객 동기화',
24 description:
25 'mallUserId·이름 필수. 기존 고객은 mallUserId → 사업자번호 → 휴대전화 순 매칭 후 갱신, 없으면 생성. 법정동코드 legalBCode(선택, 10자리 숫자) → cu_legal_b_code. 신규 참참(Chamcharm)은 chamcharmMemberStatus 생략 시 ERP가 CHAMCHARM_MEMBER_STATUS 기본 참참회원으로 자동 설정. 구(레거시) 참참바이오(cu_chamcham_status)는 이 API로 설정하지 않음. email 등은 수신만 하고 tb_customer에 저장하지 않음. 상세: docs/EXTERNAL_API.md',
26 })
27 async sync(@Body() body: ExternalCustomerSyncDto): Promise<{ customerId: string }> {
28 return this.customersService.syncExternalMallCustomer(body); 811 const payload = await this.buildCreateCustomerDtoFromMallSync(body, mallUserIdStr);
812
813 if (existing) {
814 await this.update(existing.id, payload as UpdateCustomerDto);
815 this.logger.log(`[mall-sync] updated customerId=${existing.id} mallUserId=${mallUserIdStr}`);
816 return { customerId: existing.id };
817 }857 customerType: '농가', 858 customerGrade: 'GENERAL', 859 };
714 Object.assign(customer, customerData); 715 const updated = await this.customersRepository.save(customer); 716
실패 주입 재현 · 운영 DB·전체 화면 검증과 구분
두 번째 저장 실패를 주입. 실제 DB 오류 빈도나 현재 손상 건수는 측정하지 않음.
234 @Patch(':id')
235 update(@Param('id') id: string, @Body() updateCustomerDto: UpdateCustomerDto) {
236 return this.customersService.update(id, updateCustomerDto);
237 } 714 Object.assign(customer, customerData);
715 const updated = await this.customersRepository.save(customer);
716
717 // operations 업데이트 (기존 삭제 후 새로 생성)
718 if (operations !== undefined) {
719 // 기존 operations 삭제
720 if (customer.operations && customer.operations.length > 0) {
721 await this.customerOperationRepository.remove(customer.operations);
722 }734 await this.customerOperationRepository.save(operationEntities); 735 }
서비스 로직 재현 · 운영 DB·전체 화면 검증과 구분
DTO가 허용하는 payments 생략 요청을 재현. 현재 일정 화면은 payments를 전송하므로 모든 메모 저장이 이 입력을 만든다고 주장하지 않음.
677 @Put('orders/:id/invoice')
678 async saveInvoice(@Param('id') id: string, @Body() body: SaveInvoiceDto) {
679 return this.tradeContractsService.saveInvoice(id, body);
680 }117 payments?: SaveInvoicePaymentDto[] | null;
10885 await manager.delete(TradeOrderPayment, { order: { id: order.id } as any });
10886
10887 if (normalizedPayments.length && dto.payments) {
10888 // dto.payments와 normalizedPayments를 매칭하여 krwAmount 포함
10889 const paymentEntities = normalizedPayments.map((payment, index) => {
10890 const originalPayment = dto.payments?.[index];
10891 // krwAmount 계산: DTO에서 제공되면 사용, 없으면 amount * exchangeRate 계산933 payments: paymentsPayload,
경합·실패 주입 재현 · 운영 DB·전체 화면 검증과 구분
스냅샷을 반환하는 메모리 저장소로 가능한 경합 순서를 재현. PostgreSQL 동시 트랜잭션 시험은 별도 필요.
325 @Post(':id/collect')
326 async collect(@Param('id') id: string, @Body() dto: CollectReceivableDto) {
327 return this.receivablesService.collect(id, dto);
328 } 435 async collect(receivableId: string, dto: CollectReceivableDto): Promise<ReceivableDetail> {
436 const receivable = await this.receivableRepository.findOne({
437 where: { id: receivableId },
438 });
439 474 await this.collectionRepository.save(collection); 475 476 // 채권 정보 업데이트 477 // 수금(양수): totalCollected 증가, balance 감소 478 // 환불(음수): totalCollected 감소, balance 증가 479 const newCollectedAmount = Number(receivable.totalCollected) + collectionAmount; 480 const newBalance = currentBalance - collectionAmount; 481 482 receivable.totalCollected = String(newCollectedAmount); 483 receivable.balance = String(newBalance); 484
497 await this.receivableRepository.save(receivable); 498 499 // 업데이트된 채권 정보 반환
서비스 로직 재현 · 운영 DB·전체 화면 검증과 구분
서버에 오래된 상태가 도착하는 경우 재현. 브라우저 두 창의 실제 경쟁은 별도 검증 대상.
985 status: delivery.status === 'PENDING_DISPATCH' ? 'DISPATCH_REQUESTED' : delivery.status, // 배차 대기 상태일 때만 배차 요청으로 변경
986 ...(loadingItems !== undefined ? { loadingItems } : {}),
987 }; 2093 if (dto.status !== undefined) {
2094 delivery.status = dto.status;
2095 // 상차완료 → 하차완료 변경 시 추적용 (체크 포인트)
2096 if (dto.status === 'UNLOADING_COMPLETED' && previousStatus === 'LOADING_COMPLETED') {2178 await this.salesDeliveryRepository.save(delivery); 2179
실패 주입 재현 · 운영 DB·전체 화면 검증과 구분
외부 재계산 실패를 주입해 비원자적 저장·재시도 결과를 확인. 사용자 재시도 빈도는 미확인.
553 @Post('containers/:containerId/adjust-inventory')
554 async adjustContainerInventory(
555 @Param('containerId') containerId: string,
556 @Body() body: AdjustContainerInventoryDto,
557 @Req() req: any,
558 ) {
559 const userId = req.user?.id;
560 return this.tradeContractsService.adjustContainerInventory(containerId, body, userId);12193 } else if (dto.type === 'CONSUMPTION') {
12194 // 재고 소모: 전체 수량은 변경하지 않고, 가용 수량만 감소
12195 // 판매 수량을 양수로 처리하여 가용 수량 계산 시 차감
12196 try {
12197 const SalesEntity = (await import('../sales/entities/sales.entity')).Sales;
12198 const salesRepository = this.dataSource.getRepository(SalesEntity);
12199 12222 await this.salesItemRepository.save(salesItem); 12223 12224 // 재고 상태 재계산 (판매 수량에 양수가 추가되어 가용 수량 감소) 12225 await this.updateContainerInventoryStatusAfterSalesChange(container.id); 12226
실패 주입 재현 · 운영 DB·전체 화면 검증과 구분
하차완료→상차완료 복구의 연관 행 조회 실패를 주입. 하차완료 저장의 catch/finally 경로는 정적으로만 추가 확인.
2178 await this.salesDeliveryRepository.save(delivery); 2179
2587 if (dto.status === 'LOADING_COMPLETED' && previousStatus === 'UNLOADING_COMPLETED' && delivery.salesId) {
2588 this.logger.log(`[상차완료 복구] 하차완료에서 상차완료로 상태 변경 시작 - 배송 ID: ${id}, 판매 ID: ${delivery.salesId}`);
2589 try {
2590 // 저장된 loadingItems 조회 (요청 정보가 포함된 데이터)
2591 const loadingItemsWithRelations = savedLoadingItems.length > 0
2592 ? savedLoadingItems
2593 : await this.loadingItemRepository.find({
2594 where: { salesDeliveryId: id },
2595 relations: ['salesItem', 'salesItem.container', 'salesItem.container.order'],
2596 });2954 // 판매 항목 상태 복구 실패해도 배송 상태 업데이트는 계속 진행 2955 } 2956 }
3878 return updatedDelivery;