거래처 엑셀 일괄 등록 오류 검수 시스템 구축 방법

거래처 목록을 엑셀로 한꺼번에 등록할 때는 같은 코드가 두 번 들어 있거나 기존 거래처를 덮어쓰는 문제가 생길 수 있습니다. 파일을 올리자마자 저장하지 않고, 행별 오류 검수와 승인 뒤에 확정 반영하도록 나누면 처리 기준이 분명해집니다. 아래는 신규 거래처 생성만 허용하고 오류가 한 건이라도 남으면 전체 등록을 막는 시스템 설계 예시입니다. 실제 고객 사례나 운영 실적을 뜻하지 않습니다.

코드 0012가 12로 바뀌기 전에 막아야 합니다

입력 화면에는 거래처 코드와 거래처명 두 열을 가진 양식을 제공합니다. 이 예시의 코드는 영문 대문자·숫자·하이픈·밑줄로 된 1~20자 문자열이며, 이름은 공백을 제외하고 1~100자입니다. 파일은 최대 5MB, 데이터는 10,000행까지 받는다고 가정합니다. 이 수치는 제품 성능이 아니라 구현 시 합의할 제한값입니다.

Excel은 숫자로 해석한 값의 앞자리 0을 지울 수 있습니다. 코드 열은 입력 또는 가져오기 단계부터 텍스트로 다뤄야 합니다.[1] 화면에 0012처럼 보이는 숫자 서식만 믿지 말고, 검수 화면에서 시스템이 읽은 코드도 0012인지 확인합니다. 이미 12로 저장된 값을 업로드 시스템이 원래 코드로 복원할 수는 없습니다.

서버는 코드와 이름을 문자열로 읽고 수식 셀은 거부합니다. 누락된 셀은 빈 문자열로 통일한 뒤 필수값을 검사합니다. 앞뒤 일반 공백을 제거했다면 원본과 정리된 값을 함께 보여주고, 소문자를 대문자로 바꾸거나 코드를 임의로 보충하지 않습니다. 이름이 같다는 이유만으로 서로 다른 코드를 합치지도 않습니다.

업로드 담당자와 승인자가 보는 화면

• 담당자가 파일을 올리면 서버가 작업번호와 원본 파일을 보관하고 검수 대기 상태를 만듭니다. 아직 운영 거래처 목록에는 쓰지 않습니다.
• 검수 화면은 전체 행 수, 오류가 있는 행 수, 정상 행 수를 구분합니다. 오류마다 원본 시트·행·열, 읽은 값, 수정 이유를 표시합니다. 아래 사례는 데이터 5행 중 오류 4행, 정상 1행입니다.
• 담당자는 원본 파일을 고쳐 다시 올립니다. 새 검수본을 만들고 이전 검수본의 승인은 무효로 처리합니다. 정상 1행만 먼저 등록하는 버튼은 제공하지 않습니다.
• 승인자는 오류 0건인 검수본의 전체 내용과 등록 예정 건수를 확인합니다. 업로드 권한과 승인 권한을 분리하고, 승인 기록을 해당 검수본에 연결합니다.

기존 코드가 발견되면 신규 등록 작업에서 이름을 덮어쓰지 않고 충돌로 안내합니다. 거래처명 변경은 기존값과 변경값을 비교하는 별도 수정 절차로 넘깁니다. 같은 파일의 중복도 먼저 나온 행만 살리는 방식 대신 양쪽 모두 수정 대상으로 표시합니다.

검수 기준을 확인하는 읽기 전용 SQL

다음은 파일 읽기가 끝났다고 가정한 합성 데이터입니다. SQLite 3.54.0의 메모리 데이터베이스에서 실행해 결과를 확인했습니다. WITH로 임시 입력을 구성하고 CASE로 행별 판정을 반환하며, 운영 테이블을 만들거나 변경하지 않습니다.[2][3] trim()의 기본 처리는 앞뒤 일반 공백 제거이므로 탭이나 다른 공백 문자까지 정리하는 완성된 입력 검증기로 볼 수 없습니다.[4]

WITH incoming(row_no, code, name) AS (
  VALUES (2, '0012', '모아부품'),
         (3, '0012', '새봄부품'),
         (4, 'A009', '기존코드 거래처'),
         (5, 'B010', ''),
         (6, 'C011', '한빛부품')
), existing(code) AS (VALUES ('A009')),
clean AS (
  SELECT row_no, trim(code) AS code,
         trim(name) AS name FROM incoming
)
SELECT row_no, code,
  CASE
    WHEN code = '' OR name = '' THEN '필수값 누락'
    WHEN (SELECT count(*) FROM clean c
          WHERE c.code = clean.code) > 1 THEN '파일 내 중복'
    WHEN EXISTS (SELECT 1 FROM existing e
                 WHERE e.code = clean.code) THEN '기존 코드 충돌'
    ELSE 'OK'
  END AS result
FROM clean ORDER BY row_no;

헤더를 1행으로 놓은 예시에서 2·3행의 0012는 모두 파일 내 중복, 4행의 A009는 기존 코드 충돌, 5행의 B010은 이름 누락, 6행의 C011만 OK를 반환했습니다. 3행 코드만 0013으로 바꾸면 2·3행은 OK가 되지만 다른 두 오류는 남습니다. 따라서 파일 전체를 등록할 조건은 아직 충족되지 않습니다.

2행 코드를 앞뒤 공백이 있는 ' 0012 '로 바꿔도 정리 후 중복 판정은 같았습니다. 이 SQL은 세 가지 오류 중 처음 만나는 이유 하나만 반환합니다. 화면에서 여러 오류를 한꺼번에 보여주려면 오류 항목을 별도로 모아야 합니다. 코드 형식·길이, 파일 크기, 수식 셀 검사는 이 쿼리에 포함되어 있지 않습니다.

승인 후에도 반영 직전에 다시 확인합니다

검수 중 다른 직원이 같은 코드를 등록할 수 있습니다. 확정 반영 요청에서 서버는 승인 권한과 승인된 검수본이 그대로인지 확인하고, 현재 거래처 코드와 다시 대조해야 합니다. 운영 테이블에는 코드의 NOT NULL과 UNIQUE 제약을 함께 둡니다. SQLite의 UNIQUE만으로는 NULL 값까지 하나로 제한되지 않기 때문입니다.[5]

이 설계의 전체 반영 방식은 모든 INSERT와 작업 결과 저장을 한 트랜잭션으로 묶는 것을 전제로 합니다. 충돌이나 저장 오류가 나면 전부 되돌리고 재검수 대상으로 표시합니다. 대용량 파일을 여러 번 나눠 커밋하면서 전체 성공이라고 알리면 이 기준과 맞지 않습니다.

반영 작업번호는 한 번만 확정하도록 관리합니다. 버튼을 두 번 누르거나 응답이 끊겨도 같은 작업번호로 결과를 조회하고, 확인 없이 새 등록을 시작하지 않습니다. 완료 화면에는 파일명, 검수본, 승인자, 반영 건수와 완료 시각을 남깁니다. SQL에서 OK를 받은 것과 운영 목록에 실제로 반영된 것은 서로 다른 결과입니다.

검수 보고서와 원본 파일도 거래처 정보를 담으므로 작업 참여자만 조회하게 합니다. 이번 확인 범위는 SQL 판정과 공백·중복 수정 입력의 결과입니다. 실제 Excel 업로드, 승인 API, 동시 등록 및 장애 복구까지 검증한 시스템은 아니며 구축 시 별도의 통합 시험이 필요합니다.

구현 시 확인할 공식 문서

• [1] Microsoft: 코드의 앞자리 0 보존
• [2] SQLite: WITH
• [3] SQLite: CASE 표현식
• [4] SQLite: trim()
• [5] SQLite: NOT NULL·UNIQUE 제약

소프트모아의 개발 서비스는 softmoa.com에서 확인할 수 있습니다.

소프트모아는 해당 시스템을 구축합니다. 문의하기