이메일 주문서 관리 시스템 구축: 첨부 확인과 중복 주문 검수

이메일 주문서 관리 시스템 구축은 거래처가 보낸 메일과 첨부를 수신 사실부터 확인하고, 주문서인지와 수정본·중복 후보를 사람이 판정하는 흐름을 정하는 데서 시작합니다. ERP 주문 생성이나 발송 회신은 별도 승인·연동 범위입니다.

도매업체의 영업 담당자가 거래처별 주문서 파일을 메일함에서 찾아 주문번호와 품목·수량을 옮겨 적는 상황을 가정해 보겠습니다. 같은 제목으로 파일이 다시 오면 처음 메일의 재전송인지, 수량을 바꾼 수정본인지 확인해야 합니다. 담당자가 휴가 중이면 다른 직원은 어떤 파일이 검토를 마쳤고 어느 주문이 아직 대기 중인지 찾기 어렵습니다.

이 글은 우리 회사가 고객사의 주문서를 받는 업무를 다룹니다. 우리가 공급사에 보낸 발주에 대한 납기 회신이나 EDI 발주 응답을 처리하는 업무와 원천·판정 주체가 다릅니다. 고객 주문서를 받았다고 주문이 확정된 것은 아닙니다. 발신자 확인, 첨부 검토, 거래처와 품목 대조 후 주문 승인과 원장 반영을 각각 구분해야 합니다.

하루에 몇 건 되지 않고 메일 폴더와 공통 접수표로 담당자 인계가 잘 된다면 새 시스템이 필요하지 않을 수 있습니다. 반대로 여러 계정·담당자의 누락 확인과 수정본 구분이 반복되면 메일을 읽어 접수 후보를 보여주는 대시보드를 검토합니다. 우선 원본을 확인하고 담당자가 판정할 수 있는 범위를 정한 뒤 자동 등록이 필요한지 판단합니다.

이 글의 회사, 메일, 주문번호와 수량은 가상 표본입니다. 실제 고객 문의나 첨부를 재현한 것이 아닙니다. 회사별 이메일 서비스와 접근 권한에 따라 수신 이벤트·첨부 제공 방식이 다르며 특정 서비스의 사용 가능성, OCR 정확도 또는 자동 주문 확정을 보장하지 않습니다.

공식 문서에서 확인한 수신과 식별자 범위#

Microsoft Power Automate 문서는 새 메일의 발신자, 제목과 첨부 여부를 기준으로 흐름을 시작하는 제품 기능을 설명합니다. Microsoft Graph 문서는 Outlook 항목의 기본 ID가 이동 등의 경우 바뀔 수 있고, 별도 요청으로 불변 ID를 사용할 수 있음을 설명합니다. 이 ID도 같은 사서함을 벗어나거나 내보낸 뒤 다시 가져오는 상황에는 바뀔 수 있습니다. 이는 Microsoft 제품의 동작 범위이며 모든 메일 서비스의 ID 규칙이나 새 메일로 다시 전송된 업무 주문의 동일성을 보장하지 않습니다.

• Microsoft Learn: 이메일 속성을 이용한 흐름 시작: Outlook 기반 흐름의 발신자·제목·첨부 조건 예시입니다.
• Microsoft Graph: Outlook 불변 식별자: 같은 사서함 안 이동과 보관 사서함·내보내기 후 재가져오기의 차이를 설명합니다.
• Microsoft Learn: 공유 메일함 첨부 처리 문제: 첨부 유무와 첨부 내용 포함 설정의 차이를 해당 제품 기준으로 확인합니다.

메일 접근과 첨부 검토 책임을 어떻게 정할까요?#

개인 메일함을 무조건 공유하기보다 업무용 계정과 읽을 폴더, 접근을 승인한 관리자를 먼저 확인합니다. 거래처 주문 외의 인사·계약 메일이 섞이면 접수 화면에 모두 노출될 수 있습니다. 수집 범위와 최소 권한, 담당자 퇴사 시 권한 회수, 위탁된 파일 보관·삭제 책임을 계약과 운영 절차로 구분합니다.

발신 주소가 이전과 같다는 이유만으로 거래처 주문을 승인하지 않습니다. 거래처 식별자는 별도 기준정보와 매핑하고, 낯선 발신자나 갑작스러운 결제 정보 변경은 확인 대기로 둡니다. 확인 절차와 담당 연락 경로는 기존 계약과 내부 보안 정책에 맞게 정합니다. 이메일 한 통이 도착한 사실과 실거래처의 유효한 주문이라는 판정은 다른 단계입니다.

첨부파일이 있더라도 내용을 읽을 권한이나 형식이 없을 수 있습니다. 파일 목록, 실제 수신 여부, 손상·암호 설정·지원하지 않는 형식은 각기 다른 상태로 표시합니다. 실행 파일이나 수상한 링크를 자동으로 열지 않고 조직의 보안 검사와 승인 정책을 따릅니다. 첨부를 안전하게 보관하는 위치와 접근 권한, 보관 기간은 예시로 임의 확정하지 않습니다.

주문서 표에서 품목·수량을 추출하는 기능을 추가할 경우 원본에 있는 단위와 문맥을 담당자가 직접 확인하도록 해야 합니다. 10박스와 10개의 차이, 빈 셀, 잘린 페이지나 여러 주문서가 한 파일에 있는 경우는 자동 확정하지 않습니다. OCR이나 언어 모델을 이용해도 추출 결과는 후보이며 실패와 신뢰도 표시, 사람 검토·수정 기록을 별도로 설계합니다.

수신 중단과 재처리는 메일 서비스의 제한과 권한을 먼저 확인해야 합니다. 마지막 성공 조회 시각과 누락 가능 구간, 계정 인증 만료, 재조회 담당을 기록하고 같은 메시지가 반복 수집돼도 접수 후보가 계속 늘지 않도록 확인합니다. 메일함 이동으로 식별자가 바뀔 수 있는 제품에서는 해당 제품의 지원 방식과 이력 복원 조건을 별도로 검토합니다.

승인 후 ERP 반영이 필요한 경우 조회 대시보드와 연동 작업을 나눠 산정합니다. 승인된 거래처·품목·단위·수량, 반영 대상 회사와 승인자를 검수하고 ERP의 성공 응답과 생성된 주문 참조를 대조해야 합니다. 실패했을 때 자동으로 반복 전송하는 대신 중복 생성 여부와 재실행 권한을 확인하고, 사람이 원장과 비교해 복구하도록 범위를 정합니다.

인수할 때는 메일 계정·폴더 범위, 읽기 권한, 첨부 보관 위치, 중복 후보 판정표, 장애 알림과 재처리 절차를 남깁니다. 발신자 회신이나 고객에게 주문 접수 알림을 보내는 기능은 외부 메시지 발송이므로 승인 방식과 문구, 실패 처리도 별도 결정해야 합니다. 초기 구축비와 운영 지원·메일 서비스 비용 역시 같은 항목으로 뭉뚱그리지 않습니다.

공급사에 보낸 발주의 납기 회신은 협력사 납기 회신 포털에서 구분해 보세요. 메일·ERP 연결의 접근 조건과 책임은 API 연동 개발 범위를 참고하세요.

네 통의 가상 메일로 접수와 수정본을 검수합니다#

M1과 M2는 거래처 A의 같은 PO-10·10개를 담은 별도 메시지입니다. M3은 같은 A·PO-10의 수량을 12개로 고쳤다는 수정 후보이고 M4는 거래처 B가 PO-10이라는 번호를 쓴 별도 주문 후보입니다. 네 통의 원본과 수신 이력은 모두 확인 가능해야 하며, 검토 전부터 파일명만 보고 메일을 삭제하거나 ERP에 네 건을 확정하지 않아야 합니다.

M2가 동일 주문의 재전송으로 확인되면 원본과 중복 판정 근거를 남기되 별도 주문으로 추가하지 않습니다. M3이 정당한 수정본으로 승인되면 A의 최신 확정 수량은 12개이고 이전 10개는 판본 이력입니다. M4는 거래처가 다르므로 같은 번호라도 B의 별도 주문으로 검토합니다. 이 가상 판정에서 업무상 주문은 A·B 두 건입니다. A 수량을 이전과 최신을 더해 22개로 계산해서는 안 됩니다.

동일 메시지를 재수집해도 새로운 후보를 중복 생성하지 않는지, 별도 새 메일로 다시 온 같은 첨부는 중복 후보로 남는지 시험합니다. 같은 파일명에 내용이 다르거나 같은 내용이 다른 파일명으로 온 예시도 넣습니다. 해시와 제목의 일치만으로 업무상 동일성을 확정하지 않고 담당자의 비교·승인이 반영되는지 확인합니다.

첨부가 없거나 암호가 걸린 파일, 지원하지 않는 서식, 누락된 품목코드, 단위가 모호한 수량을 각각 보류합니다. 메일 수신이 곧 첨부 본문 확보라는 가정도 검증합니다. 공유 메일함 사용 중 첨부 내용이 포함되지 않도록 설정된 경우 목록과 내용 읽기 실패가 구분돼야 합니다. 실제 메일 서버에 없는 기능을 성공으로 가정하지 않습니다.

권한 시험에서는 접수 담당자가 승인되지 않은 ERP 주문을 생성할 수 없는지, 권한 없는 사용자가 타 거래처 첨부를 볼 수 없는지 봅니다. 조회·검토·승인과 전송 책임은 역할별로 나눕니다. ERP 쓰기가 포함된 계약이라면 전송 실패 뒤 이미 주문이 생겼는지 확인하고, 중복 방지와 승인된 재실행을 별도 시연합니다.

장애 인수 시험에서는 계정 인증 만료, 수신 지연, 누락 구간 재조회와 담당자 부재를 가정합니다. 마지막 성공 시각과 미확인 구간이 표시되고, 대체 담당자가 보류 사유와 원본 접근 절차를 이해할 수 있어야 합니다. 실제 메일함 접근 권한이 없어 시험하지 못한 기능은 미검증으로 남기고 운영 전 후속 시험을 정합니다.