본 사례는 실제 외주 프로젝트 수행 기록을 바탕으로 작성했습니다.
엑셀 열 변환보다 주문 메일의 최신본과 ERP 반려행을 끝까지 관리하는 일이 문제였습니다
저희는 OO유통사 수주운영팀입니다. 거래처 주문 엑셀을 ERP 업로드 양식으로 바꾸는 매크로는 이미 있었습니다. 지정된 시트와 열을 쓰는 주문서는 잘 처리됐지만, 업무의 시작은 폴더가 아니라 공용 메일함이었습니다.
주문은 메일뿐 아니라 거래처 발주 포털에도 올라왔습니다. 한 거래처가 주문서를 보낸 뒤 제목만 조금 바꿔 수정본을 다시 보내거나, 포털의 PO Rev.를 올린 뒤 메일에도 같은 파일을 첨부했습니다. 파일명은 같지만 납품요청일이나 수량이 달라진 경우도 있었고, 본문에는 “1번 품목 취소”라고 적고 첨부파일은 수정하지 않은 경우도 있었습니다. 담당자는 포털 이벤트·PO 번호·Rev., 메일 스레드, 수신시각과 주문행 내용을 함께 봐야 실제 적용할 최신 주문을 정할 수 있었습니다.
그 뒤에는 거래처 품목코드를 사내 SKU로, EA·BOX·CS를 ERP UOM으로, 납품처명과 주소를 Ship-to 코드로 바꿔야 했습니다. 단종·대체 품목, 거래처별 박스입수, 최소주문수량, 필수 납품처 코드가 맞지 않으면 ERP가 업로드 행을 반려했습니다. 재고가 부족한 행은 백오더 가능일이나 분할출고일을 확인해 거래처 포털에 행별 승인·변경 회신도 해야 했습니다. 파일 변환, 오류 수정, 재업로드, PO 행 상태 회신까지가 하나의 주문 처리였습니다.
기존 AI는 첨부파일을 바꿔 줬지만 메일과 ERP 사이의 상태를 이어 가지 못했습니다
일반적인 AI에 주문 엑셀 한 개를 올리면 열을 바꾸고 ERP 양식처럼 정리할 수 있었습니다. 하지만 공용 메일함과 거래처 발주 포털에 로그인해 신규·수정 PO를 수집하고, Rev.와 행별 취소를 판별하거나, 최신 품목·UOM·Ship-to 마스터를 조회하는 일은 하지 못했습니다.
ERP에 업로드한 뒤 반환되는 품목 사용중지, UOM 불일치, 납품처 미등록, 요청일 마감 같은 반려 사유를 해당 원본 주문행과 다시 연결하고, 수정된 행만 재시도하는 상태 관리도 끊겼습니다. 담당자는 AI가 만든 파일을 받은 뒤에도 메일을 다시 찾고 ERP 오류를 엑셀에 옮겨 적어야 했습니다.
yaap에 문의해 메일주문-ERP 재처리 플러그인을 만들었습니다
플러그인의 입력은 주문 수신용 메일함과 거래처 발주 포털, 첨부 주문서와 변경 지시, ERP 거래처·품목·UOM·Ship-to·재고 마스터, ERP 업로드 규격과 반려 로그였습니다. 출력은 적용 PO와 제외된 수정·중복본 목록, ERP 업로드 준비파일, 매핑 예외표, 반려행 재처리 대기열, PO 행별 승인·백오더 회신 준비본이었습니다.
1. 신규·수정 PO 수집 — 담당자가 허용한 공용 메일함과 거래처 발주 포털에서 PO 번호·Rev.·이벤트 상태를 기준으로 메시지와 첨부를 모았습니다. 수신시각, 파일 해시, 주문행 차이, 수정·취소 문구를 비교해 적용본과 완전 중복·구버전을 나눴습니다.
2. 주문행과 기준정보 매핑 — 주문번호·행번호·납품요청일·거래처 품목코드·수량·UOM·단가·납품처를 읽고 ERP의 고객코드, 내부 SKU, 환산단위, Ship-to와 연결했습니다. 단종품·복수후보·환산기준 없음·납품처 미등록은 자동 확정하지 않았습니다.
3. 업로드 준비본과 통제표 생성 — 승인된 매핑만 ERP 열 순서와 데이터 형식으로 만들고 취소·합계·메모행은 제외 근거와 함께 분리했습니다. 원본 주문행 수와 정상·제외·예외 건수, 수량과 금액 합계가 이어지는지 통제표에 표시했습니다.
4. ERP 반려로그 회수 — 담당자가 업로드한 뒤 ERP가 반환한 처리결과를 읽어 성공행과 반려행을 주문번호·행번호로 다시 연결했습니다. 반려 사유를 품목, UOM, Ship-to, 날짜, 중복주문 유형으로 분류해 원본 메일과 함께 재처리 대기열에 넣었습니다.
5. 승인된 행 재시도와 PO 회신 — 운영팀이 신규 품목 매핑이나 납품처, 날짜 변경을 승인하면 해당 반려행만 다시 생성했습니다. ERP 성공행은 거래처 포털의 PO 행과 연결하고, 재고부족 행은 승인된 백오더·분할출고일을 회신 준비본에 반영했습니다. 재시도와 행별 확인상태를 남겨 중복 등록을 막았습니다.
전체 주문을 다시 만드는 대신 미매핑 품목과 반려행만 처리하게 됐습니다
거래처가 수정본을 보내도 담당자가 메일함과 다운로드 폴더를 다시 뒤지지 않습니다. 어떤 첨부가 적용본이고 어떤 파일이 중복·구버전인지 근거가 남고, 본문의 취소 지시도 주문행과 함께 확인할 수 있습니다.
ERP 업로드 뒤에도 업무가 끊기지 않습니다. 정상 처리된 행은 닫히고, 담당자는 품목·UOM·Ship-to가 매핑되지 않았거나 ERP에서 반려된 행, 백오더 협의가 필요한 행만 확인합니다. 매핑과 납기 회신은 사람이 승인하지만, 포털·메일 수집부터 ERP 재시도와 PO 행 확인까지 같은 주문번호로 이어집니다.