협력사 등록 홈페이지 개발: 신청·보완·심사·승인 흐름 설계

협력사 등록 홈페이지 개발은 신청 폼을 받아 메일로 전달하는 수준을 넘어 신청서 원본, 보완본과 심사 결정을 구분하는 작업입니다. 접수 번호를 발급했다는 사실이 협력사 선정이나 ERP 거래처 등록을 뜻해서는 안 됩니다. 외부 신청자와 내부 심사자가 보는 정보, 법인과 담당자의 관계, 승인 이후 기준정보를 넘기는 경계를 먼저 정해야 합니다.

구매·품질·기술 부서가 같은 업체의 자료를 따로 요청하거나 신청자가 심사 진행 상황을 매번 전화로 묻고 있다면 등록 전용 흐름을 검토할 수 있습니다. 그러나 서류를 한곳에 모으는 것만으로 심사 기준이 정리되지는 않습니다. 어떤 자료를 누가 확인하고 어느 조건에서 보완을 요구하는지, 부서 의견이 엇갈릴 때 누가 최종 결정하는지까지 정의해야 업무가 시스템 안에서 진행됩니다.

이 글은 협력사 등록 신청과 심사 인계를 다룹니다. 발주·납품·정산, 공급망 평가 전체와 채용 지원은 별도 범위입니다. 가상 업체 A와 B, 분야 X와 Y의 사례는 설계 설명용이며 실제 구매 정책이나 회사 실적이 아닙니다. 제출 자료의 적법한 수집 범위와 보존 기간, 공정한 심사 정책 등은 조직의 담당자가 별도로 검토해야 합니다.

개발업체에는 빈 신청 양식만 보내지 말고 접수 후 실제로 반려·보완된 사례를 비식별 표본으로 정리하세요. 담당자 메일 주소가 바뀐 경우, 이미 등록된 법인이 다른 사업장으로 신청한 경우, 심사 도중 제출 자료가 교체된 경우를 포함하면 좋습니다. 이런 사건은 폼 디자인만으로 해결할 수 없고 데이터의 관계와 승인 권한을 결정해야 합니다.

접수 안내와 첨부 보안에서 참고할 공식 자료#

W3C WAI의 폼 알림 안내는 제출 결과와 오류를 이해할 수 있게 전달하고 해결 방법을 제시하도록 설명합니다. 협력사 신청에서도 필수 자료 누락, 제출 성공과 보완 필요를 구체적으로 구분하는 데 참고할 수 있습니다. OWASP의 파일 업로드 안내는 허용 형식, 파일 내용 검증과 저장 위치 등을 함께 고려하도록 설명합니다. 두 자료는 접근성과 보안 설계의 근거이며 기업별 협력사 선정 기준, 심사의 공정성이나 개인정보 처리의 법적 적합성을 자동으로 보증하지 않습니다.

• W3C WAI 폼 제출 결과·오류 안내: 신청 성공과 오류 해결 방법을 전달하는 원칙입니다. 개별 등록 정책의 적합성 판단은 별도입니다.
• OWASP 파일 업로드 보안 안내: 외부 첨부의 방어 설계를 확인합니다. 서류의 진위·내용 심사와 조직별 법적 검토를 대신하지 않습니다.

서류가 모이는 곳보다 다음 행동이 보이는 시스템을 만듭니다#

초청받은 업체만 신청하는 경우에는 초대 대상과 신청서 소유 관계를 확인하세요. 메일을 전달받은 사람이 누구나 기존 초청 업체 이름으로 제출할 수 있어서는 안 됩니다. 초대 유효기간이 지나거나 담당자가 바뀌었을 때 재발급 승인자를 두고, 초대 취소가 제출 완료한 기록까지 삭제하는 사건과 같지 않도록 구분합니다. 공개 모집과 초청 등록을 동시에 운영한다면 심사 기준과 권한의 차이를 신청 화면에도 설명해야 합니다.

양식 개정 시점에는 작성 중인 신청자와 심사 중인 신청자가 서로 다른 버전을 사용할 수 있습니다. 새 필수 항목을 이미 제출된 신청에 소급 적용할지, 별도 보완을 요청할지 정책을 정하세요. 이전 버전 점수를 새 평가표 기준처럼 비교하지 않도록 심사 결과에 양식 버전을 남깁니다. 개정 작업 전에 어떤 진행 건이 영향을 받는지 미리 확인하고, 변경 이후에도 신청자가 자신이 제출한 항목과 안내를 다시 볼 수 있게 해야 합니다.

외부 신청 화면은 공고·등록 분야별로 필요한 자료를 안내하고 준비되지 않은 항목의 처리 방식을 설명해야 합니다. 제출 직전에 모든 누락을 한꺼번에 알리기보다 각 항목의 형식과 용량, 필수 여부를 입력 단계에서 보여주세요. 실패한 경우 이미 입력한 내용을 유지하는 범위도 검토합니다. 다만 브라우저 임시 저장에 민감 자료가 무기한 남거나 공용 기기에서 다음 사용자가 볼 수 없도록 저장 정책을 함께 결정해야 합니다.

첨부 파일은 업로드 완료, 보안 검사 완료와 심사용 공개를 구분하세요. 파일명이나 확장자만으로 안전함을 확정하지 않고 서버 검증과 저장 위치를 검토합니다. 검사 대기 중인 파일을 심사자가 무조건 내려받지 않도록 하고, 차단된 파일은 신청자가 안전한 형식으로 다시 제출할 수 있게 안내합니다. 신청자가 제출하지 않은 다른 회사의 파일 주소를 추측해 접근하는 경우도 권한 시험에 포함해야 합니다.

심사 배정은 담당자 개인 이름만 저장하기보다 분야와 역할을 기준으로 운영할 수 있게 설계하세요. 한 부서의 보완 요청이 전체 신청을 멈추게 할지 다른 부서 심사는 계속 진행할지 정해야 합니다. 병렬 검토를 허용한다면 모든 필수 분야가 완료되었는지 최종 승인자가 확인할 수 있어야 합니다. 검토 기간을 약속하는 경우에는 보완 대기와 내부 검토 시간을 어떻게 해석하는지도 합의해야 불필요한 일정 오해를 줄일 수 있습니다.

이메일은 안내 수단이지 심사 상태의 유일한 원장이 되지 않도록 합니다. 발송 실패, 주소 변경과 재발송을 접수 번호로 추적하고 고객이 포털에서 확인한 안내와 일치시켜야 합니다. 메일 제목이나 본문에 불필요한 평가 정보나 민감 첨부를 넣지 않는 방법을 검토하세요. 링크로 조회하는 경우에는 링크 만료와 재인증, 권한 회수 규칙을 정하고 전달받은 사람이 누구나 신청서 전체를 보는 구조는 피해야 합니다.

신청 취소와 미선정 후 재신청도 별도 경로가 필요합니다. 취소한 신청을 심사자가 계속 승인할 수 있는지, 다시 신청하면 과거 결론을 어떤 범위로 참조할지 정하세요. 심사 양식이 개정되었다면 재신청에 어느 버전을 적용할지도 명확해야 합니다. 심사 편의를 위해 모든 자료를 무기한 보관한다고 가정하지 말고 목적별 보존·삭제 정책과 삭제 시 남길 최소 기록은 관련 책임자와 검토합니다.

ERP 연동을 포함한다면 처음에는 승인 목록 내보내기와 기준정보 담당자 확인으로 시작할 수도 있습니다. 자동화를 선택할 때는 회사 코드 중복, 응답 지연과 재전송을 시험하고 같은 신청이 여러 거래처를 만들지 않도록 식별자를 사용합니다. 지급계좌 등 높은 확인 수준이 필요한 정보는 단순 신청자 입력만으로 확정하지 않는 절차를 검토하세요. 이 단계의 책임을 홈페이지 개발 범위에 포함할지 별도 프로젝트로 나눌지 견적서에 적어야 합니다.

공통 관리자 기능은 홈페이지 관리자 페이지 개발을 참고하되 심사 상태와 권한은 별도로 설계하세요. 선정 이후 거래처별 문서 조회는 B2B 고객 포털 개발의 업무 범위로 구분할 수 있습니다.

협력사 등록 시스템 검수표는 신청 한 건의 변화를 따라갑니다#

가상 업체 A의 초기 제출본을 만든 뒤 품질 자료만 보완받고 기술 분야의 검토를 진행하는 시연을 요청하세요. 신청자는 지정된 항목만 수정하고 심사자는 자신이 본 버전과 새 버전을 구분할 수 있어야 합니다. 보완 기한이 지난 경우, 보완 완료 직전에 담당자가 교체된 경우와 동시에 여러 부서가 의견을 등록한 경우를 검수 표본에 포함합니다. 정상 제출 한 번만으로는 업무 일관성을 확인하기 어렵습니다.

회사 A의 담당자와 회사 B의 담당자를 준비해 신청 목록·상세·첨부·결과 조회의 접근을 검사합니다. URL을 직접 요청하거나 파일 다운로드 주소를 재사용했을 때도 회사 관계가 확인되어야 합니다. 내부 심사 메모가 외부 화면, 이메일과 데이터 내려받기에 포함되지 않는지 별도로 대조하세요. 관리자 계정으로만 시연하면 외부 담당자 관점의 경계 오류를 놓칠 수 있습니다.

중복 신청 판정은 경고와 업무 결정을 분리해 검수하세요. 같은 회사가 다른 사업장·분야에 신청할 때 무조건 차단하는지, 기존 담당자에게 자동 권한을 주는지 확인합니다. 중복 의심 건을 담당자가 정리할 때도 원래 신청자와 제출 이력은 보존되어야 합니다. 신원 확인이 끝나지 않은 신청자에게 기존 거래 여부나 비공개 심사 정보가 노출되지 않는 완료 기준을 두세요.

인수 자료에는 신청 데이터 사전, 제출·보완·심사 상태도, 양식 버전, 부서별 권한과 최종 승인 조건을 포함합니다. 통지 문구와 발송 실패 처리, 보존·삭제 작업과 ERP 연동 재처리 방법도 필요합니다. 구매 운영자가 테스트 신청을 접수부터 결정까지 처리하고 담당자 변경까지 수행하도록 시연받으면 개발팀 없이 가능한 운영 범위를 확인할 수 있습니다. 운영 계정과 저장소 권한도 회사가 소유하는 방식으로 이관해야 합니다.

견적 비교는 외부 폼, 신청자 조회, 보완 회차 관리, 분야별 심사와 기준정보 연동을 나누어 진행하세요. 제출 파일 수가 적더라도 조직별 승인과 권한이 복잡하면 구현 범위가 커질 수 있습니다. 실제 심사 기준이 정리되지 않은 부분은 가정으로 견적받지 말고 별도 기획 항목으로 표시합니다. 완료 기준은 ‘신청서가 메일로 옴’이 아니라 신청자가 어떤 상태인지 알고 심사자가 검토한 원본과 결정 근거를 설명할 수 있는 상태여야 합니다.