협력사 납기 회신 포털 구축: 발주 변경과 확정 이력을 연결하는 법

협력사 납기 회신 포털 구축은 발주 행마다 협력사가 제안한 납기·수량과 구매자가 수락한 약속을 다른 상태로 보관하는 일입니다. 발주 변경 뒤에는 어떤 버전에 답했는지 다시 확인하고, 미회신과 확정 실패의 담당자를 분리해야 합니다. 발주번호가 보이는 화면보다 행별 약속·확정본·재회신의 연결이 먼저입니다.

구매자가 발주서를 보낸 뒤 협력사에서 다음 주에 일부 가능하다는 답을 받았습니다. 담당자는 메일을 읽고 엑셀 예정일을 고쳤지만 창고는 원래 발주서만 보고 입고를 준비합니다. 이때 필요한 자료는 마지막 메일 한 통으로 끝나지 않습니다. 어느 발주 행의 몇 개를 어느 날 납품하겠다는 제안인지, 구매자가 그 제안을 받아들였는지, 변경한 약속을 협력사가 다시 확인했는지를 함께 남겨야 합니다. 포털의 목적도 이 약속의 교환을 보이게 만드는 데 있습니다.

협력사 회신은 구매자 내부 확정과 다른 사건입니다. 전량 수락, 일부 수량의 날짜 변경, 납품 불가처럼 서로 다른 답을 한 발주서에 담을 수 있으며 한 행을 여러 납기 약속으로 나누기도 합니다. 회신이 도착했다는 이유로 ERP의 확정 납기를 바로 덮어쓰면 구매팀이 검토하지 않은 일정이 창고와 생산계획에 퍼집니다. 자동 확정을 허용할 조합과 사람이 수락할 조합을 분리하고, 처리 실패로 회신만 저장된 상태도 운영 목록에 표시하세요.

이 글은 외부 협력사의 납기 답변을 받아 구매자가 확인하는 구간에 한정합니다. 공급업체 선정과 내부 구매 승인 전체를 새로 설계하지 않습니다. 아래 수량과 날짜는 모두 가상 검수 예시이며 실제 납품 약속이나 특정 제품의 기본 설정이 아닙니다. 계약 효력, 전자서명 방식, 기록 보존 기간은 회사의 계약과 보안 정책을 별도로 확인해야 하고, 포털 수락 버튼이 모든 회사에서 같은 법적 의미를 갖는다고 전제해서는 안 됩니다.

공식 제품 문서는 회신과 확정을 구분하는 사례다#

2026년 11월 3일 Microsoft 공식 문서 두 편의 본문을 확인했습니다. Dynamics 365는 협력사 수락 뒤에도 설정이나 처리 결과에 따라 발주가 외부 검토에 남을 수 있고, 확정할 때 확정본 이력을 남긴다고 설명합니다. 이 구분을 참고해 아래 운영 조건을 제안했습니다. 분할 회신 자료 구조와 부분 수락 시나리오는 이 글의 설계 예시이며 특정 ERP에 그대로 들어 있다는 주장이 아닙니다.

• Microsoft 협력사 협업 안내: 수락·변경 제안과 자동/수동 확정, 가격 정보 노출 설정의 제품별 설명.
• Microsoft 발주 승인과 확정: 외부 검토와 확정, 확정 시 저장하는 버전 이력의 사례. 일반 계약 효력의 근거는 아님.

계정·재회신·확정 실패의 운영 책임을 정한다#

인쇄본과 내려받은 확정 문서에도 생성 기준을 표시합니다. 화면에서 가격 숨김을 바꿨다고 과거에 보낸 파일의 내용이 바뀌지는 않으므로 과거 파일과 새 파일을 구분할 문서번호와 생성 시각이 필요합니다. 구매자가 협력사에 재전달할 때 어느 버전을 보냈는지 남기고 이전 파일을 회수할 수 없는 한계도 안내하세요. 포털에서 최신본을 조회하는 경로를 제공하더라도 이미 내려받은 문서의 접근을 소급 통제한다고 약속하지 않습니다.

협력사 사용자는 회사와 거래처 계정에 연결합니다. 한 사람이 여러 법인의 발주를 처리한다면 허용 회사와 발주 범위를 각각 승인하고 전체 회사 접근을 기본값으로 주지 않습니다. 구매 가격이 필요 없는 물류 담당자에게는 수량과 날짜만 보여줄 수 있어야 합니다. 퇴사자 계정을 회수해도 과거 회신의 제출자 식별은 보존하되, 개인 연락처가 내려받은 파일에 과하게 남지 않도록 내보내기 항목과 보관 정책을 함께 정하세요.

회신 입력값은 발주 행, 기준 단위, 제안 수량, 납기, 회신 사유와 대상 버전을 가집니다. 박스와 낱개가 섞이면 합계 비교 전에 단위를 맞춰야 하며 분할 약속의 합계가 요청 잔량을 넘었을 때의 처리를 정합니다. 0개 회신은 무응답과 구별해 납품 불가 사유를 요구할 수 있습니다. 다른 날짜가 같은 날로 합쳐지는 현상을 막으려면 납기 날짜의 기준 시간대와 날짜만 쓰는지 시각도 쓰는지를 화면과 연동 문서에 일치시킵니다.

발주 변경 화면은 바뀐 행과 바뀌지 않은 행을 나누어 보여줍니다. 납기만 바꾼 것인지 수량을 늘린 것인지 협력사가 즉시 알아야 재회신 범위를 판단할 수 있습니다. 이전 회신을 자동 복사하더라도 제출 전 초안으로 표시하고 협력사가 확인한 새 답변과 구별하세요. 구매자 내부 메모를 협력사 변경 사유로 잘못 공개하지 않도록 내부 메모와 외부 전달문도 필드를 나눕니다. 새 버전 통지를 실패했다고 이전 확정본을 지우지는 않습니다.

미회신 목록의 담당자는 구매팀입니다. 운영자는 전송 실패와 계정 장애를 해결하지만 납품 가능 여부를 대신 확정하지 않습니다. 발주 미열람, 열람 후 미제출, 일부 행 회신, 구매자 검토 대기, ERP 반영 대기를 구분하면 누구에게 연락할지 보입니다. 알림을 여러 번 보냈다는 사실을 업무 완료로 계산하지 마세요. 대리 담당자와 휴일 운영 조건을 정하고 협력사가 이메일로 답한 경우 원본을 붙여 대리 입력했음을 남깁니다.

ERP에 확정 요청을 보낸 뒤 응답이 끊기면 같은 요청을 즉시 새 건으로 만들지 않습니다. 먼저 발주 버전과 요청 식별자로 반영 여부를 조회하고, 반영된 확정본이 있으면 그 식별자를 회신에 연결합니다. 없을 때만 같은 의도로 재시도하는 절차가 필요합니다. 오류 문구만 사라지고 회신이 확정됐다고 표시되면 위험합니다. 접수된 회신은 유지한 채 확정 대기에 두고 복구 담당자와 마지막 점검 시각을 보여주세요.

협력사가 이미 확정한 날짜를 지킬 수 없다고 뒤늦게 알려오면 기존 약속을 수정한 새 제안을 만듭니다. 구매자는 영향받는 생산·창고 담당자와 검토한 뒤 새 확정본을 남깁니다. 이전 약속이 사라지면 지연 원인과 대응 시점을 확인하기 어렵습니다. 확정 취소에도 사유와 승인자를 남기고 실제 입고가 끝난 수량에는 어떤 수정이 허용되는지 ERP 책임자가 결정해야 합니다. 납기 회신 화면에서 입고 원장을 직접 고치는 우회 경로는 열지 않습니다.

다른 구매 담당자가 확정 이력을 복원할 수 있어야 한다#

인수 자료에는 발주 행과 외부 회신, 분할 약속, 수락본, ERP 확정본의 식별 관계를 넣습니다. 납기가 바뀐 한 행을 골라 최초 요청부터 최종 수락까지 다른 담당자가 따라가게 하세요. 가상 P-41의 60개 확정과 40개 미합의가 별도 표시되고 발주 v2의 추가 20개를 누가 다시 물어볼지 확인할 수 있으면 상태 정의가 실제 화면에 반영됐다고 볼 수 있습니다. 전체 완료 비율 하나로 이 과제를 대체하지 않습니다.

중복 제출 검수는 새로고침과 재전송을 섞어 수행합니다. 같은 회신이 두 번 도착해도 분할 약속이 복제되지 않아야 하며 서로 다른 내용의 동시 답변은 충돌 또는 새 버전으로 드러나야 합니다. 제출 완료 화면의 대상 버전과 서버에 저장된 대상 버전을 비교합니다. 구버전 링크에서 제출한 답변은 자료로 보존하되 현재 확정 납기를 바꾸지 않는 결과를 확인하고, 구매자가 재검토해 새 버전에 옮기는 과정도 기록합니다.

권한 인수에는 협력사 두 곳과 구매자, 읽기 전용 창고 담당자, 회수된 계정을 사용합니다. 각 역할로 목록·검색·직접 URL·첨부·내보내기를 확인하고 금액 숨김 설정이 확정 문서에서도 지켜지는지 검사하세요. 회사별 필터가 화면에서만 동작하면 통과시키지 않습니다. 계정 회수 뒤 남은 세션과 만료된 초대 링크도 포함하고, 실제 고객 개인정보를 시험 자료로 쓰기 전에 허용 범위부터 확인합니다.

운영 인수자는 전송 실패 한 건과 ERP 응답 유실 한 건을 직접 복구합니다. 회신을 새로 만들지 않고 같은 확정 결과로 수렴하는지, 실패 알림의 담당자를 바꾸어도 원래 이력이 남는지 확인하세요. 수동 이메일로 우회한 동안의 답변을 포털에 다시 합치는 절차와 미합의 잔량 대사표도 받습니다. 구축 뒤 지원은 계정 문의, 연동 오류, 새 ERP 버전 대응을 나누어 기간과 담당을 계약서에 적고, 특정 납기 준수 성과를 시스템만으로 보장하지 않습니다.

발주 전체 범위의 비교는 구매 발주 시스템 업체 선정에서 확인하세요. 입고와 매입까지 잇는 구조는 발주 관리 시스템 설계로 분리해 살펴봅니다.