구매 담당으로 견적 의뢰부터 발주·ERP 등록까지

부품이 필요해질 때마다 거래처에 메일을 따로 보내고, 받은 견적서를 열어 엑셀에 옮겨 적고, 발주서를 쓰고, ERP에 다시 입력하는 일을 AI 직원 구매 담당이 대신 준비합니다. 어느 거래처로 정할지는 사람이 정합니다. 직원은 고르지 않습니다.

무엇이 결과인가요

거래처 목록이 거래처 테이블로 정리됩니다.
필요한 부품 하나당 거래처마다 견적 의뢰 메일이 따로 나갑니다. 받는 사람은 다른 거래처가 누구인지 볼 수 없습니다.
돌아온 회신과 견적서 파일(PDF·엑셀)이 견적서 테이블에 줄 단위로 읽혀 들어옵니다. 원본 파일도 그 줄에 붙습니다.
거래처들이 한 화면에서 나란히 비교됩니다. 필요 수량에 맞는 줄이 거래처마다 하나씩 올라옵니다.
사람이 고르면 발주 메일과 ERP 등록이 이어집니다. 둘 다 사람이 승인한 내용과 같을 때만 진행됩니다.

사람이 하는 일, 직원이 하는 일

단계	직원	사람
거래처 목록 정리	파일을 읽어 테이블 구성을 제안	승인 카드로 테이블 생성을 승인
견적 의뢰	거래처별 메일을 준비해 내용을 보여 줌	받는 사람과 내용을 보고 발송 승인
회신 읽기	회신과 견적서를 읽어 테이블에 기록	수정본이 오면 어떻게 할지 결정
비교와 선정	필요 수량 기준으로 한 줄씩 비교	거래처를 선정
발주 메일	선정한 거래처에 보낼 메일 준비	승인
ERP 등록	첫 1건을 등록하고 저장된 값을 되읽어 보여 줌	쓰기 승인, 결과 확인

직원이 하지 않는 일도 분명합니다. 거래처를 고르지 않고, 통화를 환산하지 않고, 세금계산서를 발행하거나 대금을 지급하거나 계약 조건을 수락하지 않습니다. 거래처의 사내 품질 점수와 품질 메모도 사람이나 동기화만 바꿉니다.

준비물

거래처 목록 파일: 엑셀(xlsx)이나 csv 파일입니다. 거래처 코드나 상호, 견적 메일 주소, 담당자, 결제 조건이 있으면 좋습니다. 메일 주소가 비어 있어도 직원은 주소를 추측하지 않고 비어 있다고 알려 줍니다.
ERP 연결 정보: 이카운트를 쓰신다면 전용 연동이 있고, 다른 ERP·CRM이면 일반 연결 절차로 맞춥니다. 연결 정보는 안전 보관함에만 저장되고 대화나 메모에 남지 않습니다. 이카운트 준비는 거래처 주문 접수 → ERP 등록에서 같은 방식으로 다룹니다. ERP는 다음 단계라서 처음 대화에서 막히지 않습니다.
첨부할 도면·규격 파일(있다면): 견적 의뢰 메일에 함께 보낼 수 있습니다.

따라 하기

1단계: 직원 채용과 거래처 목록 맡기기

화면의 템플릿 메뉴에서 직원 템플릿 탭을 열어 공식 템플릿 구매 담당을 찾고 사용하기를 눌러 직원을 만든 뒤(확인 창에서 승인) 거래처 목록 파일을 첨부합니다. 개인 공간의 + 채용 창에 “경력직” 카드로 뜰 때도 있지만(인기순 최대 3개) 항상 뜨는 것은 아니니, 템플릿 메뉴가 확실한 길입니다. 템플릿의 사용하기는 개인 공간에 직원을 만듭니다. 조직 공간에서는 팀 채용에서 구매 업무를 설명하면 구매 담당이 팀 멤버로 제안될 수 있습니다(어떤 멤버를 넣을지는 제안을 보고 정합니다). 직원은 첫 대화에서 목록을 바로 읽고, 거래처 수, 메일 주소가 없는 거래처, 중복된 이름이나 코드, 머리글·합계처럼 보이는 줄을 요약해 줍니다. 파일을 아직 안 줬다면 그 파일 하나만 물어봅니다.

그다음 거래처 테이블 생성을 승인 카드로 제안합니다. 승인하기 전에는 아무것도 만들어지지 않습니다. 한 번에 제안에 실리는 거래처 줄은 최대 30줄이고, 나머지는 테이블이 생긴 뒤 다음 실행부터 채웁니다.

조직 공간에서는 직원이 처음에 데이터를 읽기만 할 수 있어서 “쓰기 권한 요청” 카드가 나올 수 있습니다. 이 카드는 공간의 소유자만 승인할 수 있고, 승인하면 다음 실행부터 줄을 쓸 수 있습니다. 그전에는 직원이 아직 쓸 수 없다고 말하고, 같은 실행에서 계속 다시 시도하지 않습니다.

이 단계에서는 메일도 나가지 않고 ERP에도 아무것도 기록되지 않습니다.

2단계: ERP 연결하기

직원이 쓰시는 ERP에 맞는 연결 절차를 안내합니다. 순서는 항상 같습니다.

연결이 끝날 때까지는 조회만 합니다.
처음 쓰기는 정확히 1건입니다. 직원이 무엇을 올릴지 항목별로 먼저 보여 줍니다.
올린 뒤에는 ERP에 실제로 저장된 값을 되읽어 의도한 값과 항목별로 비교해 보여 줍니다.
사람이 확인한 뒤에야 다음 건으로 넘어갑니다.

쓰기 주소는 사람이 선언해야 하고, 선언한 뒤에는 쓰기 호출마다 승인을 받습니다. 승인 카드에는 대상 서버와 경로만 나오고 보내는 내용은 나오지 않습니다. 그래서 직원이 호출 직전 메시지로 무엇을 올리는지 먼저 말합니다. 연결할 수 없는 시스템이면 직원이 그렇게 말하고, 파일 교환이나 화면 자동화를 “연동”이라고 부르지 않습니다.

3단계: 필요건을 만들고 견적 의뢰 보내기

필요한 부품과 수량, 필요일을 알려 주면 직원이 필요건을 만들고 활성 거래처마다 견적 의뢰를 한 건씩 만듭니다. 그다음 거래처마다 개별 메일을 준비합니다.

받는 사람 한 명당 메일이 따로 나갑니다. 다른 거래처 주소는 보이지 않습니다.
회신을 이 의뢰와 짝지을 수 있도록 메일 제목에 확인 코드가 들어갑니다.
회신 마감 시각을 정해 두면 서버가 기다립니다. 직원이 계속 대화를 열어 둘 필요가 없습니다.
직원이 받는 사람 목록, 제목, 본문, 첨부 파일을 먼저 보여 줍니다. 승인 카드에는 받는 사람 전원이 나옵니다. 사람이 승인해야 나갑니다.
승인을 받지 못한 메일은 나가지 않습니다.
결과를 알 수 없는 받는 사람(상태 모름)이 있으면 다시 보내지 않고 사람에게 알립니다.
아직 회신하지 않은 거래처에만 독촉 메일을 보낼 수 있고, 독촉도 새로 승인이 필요합니다.

4단계: 회신과 견적서 읽기

회신이 오거나 마감이 지나면 서버가 직원을 깨웁니다. 직원은 첨부 파일만 보지 않고 회신 본문도 읽습니다. 질문일 수도 있고, 도면을 달라는 요청이나 거절일 수도 있기 때문입니다.

견적서 파일(PDF·엑셀)이 있으면 품목, 단가, 통화, 수량, 최소 주문 수량, 납기, 유효기간, 조건을 원본 칸과 대조하며 줄 단위로 읽습니다. 거래처별 견적서 모양은 기억해 두었다가 다음 견적서에 씁니다. 조직이 이 기억을 꺼 둔 경우에는 이번 실행에서만 맞춥니다.
같은 견적을 다시 받으면 건너뜁니다(중복으로 쓰지 않습니다).
같은 번호인데 값이 달라진 수정본이 오면 덮어쓰지 않습니다. 직원이 달라진 내용을 보여 주고 사람에게 묻습니다. 이미 선정한 견적의 수정본이면 승인을 다시 받아야 한다고 알려 줍니다.
견적서 줄에는 필요건 번호와 거래처의 사내 품질 점수가 함께 복사됩니다.
전화나 다른 메일 대화로 받은 견적도 줄은 기록하고, 그 거래처 기다림은 “다른 경로로 받음” 메모와 함께 닫습니다.
모든 거래처의 회신이 정리되거나 마감이 지나면 비교로 넘어갑니다. 그 전에는 시작하지 않습니다.

5단계: 한 화면에서 비교하고 사람이 선정하기

비교는 거래처마다 필요 수량에 맞는 한 줄로 합니다. 수량별 단가가 여러 줄인 거래처도 필요 수량에 해당하는 줄만 올라옵니다. 비교 때마다 거래처의 품질 점수를 다시 복사해서 오래된 값으로 비교하지 않습니다.

통화는 환산하지 않습니다. 통화가 섞여 있으면 통화별로 나눠 보여 주고, 비교할 수 없는 묶음이라고 표시합니다. 판단은 사람이 합니다. 선택할 수 있는 통화는 KRW, USD, EUR, JPY, CNY입니다.
최소 주문 수량이 필요 수량보다 큰 견적은 숨기거나 조용히 빼지 않고 메모와 메시지로 알립니다.
선정은 사람만 기록합니다. 직원은 선정 칸을 쓸 수 없습니다. 선정을 기록한 뒤 직원이 읽어서 필요건과 견적 상태를 갱신합니다.
절차를 포털에 게시했다면 비교는 확인 담당자의 확인 화면에 나란히 뜹니다. 화면을 연 뒤 그 건의 값이 바뀌면 “확인 화면을 연 뒤 이 건의 값이 바뀌었습니다”라고 알리며 통과가 거절되고, 바뀐 값을 다시 보고 통과해야 합니다.

6단계: 발주 메일과 ERP 등록

업무 포털의 확인 화면에서 사람이 선정 결과를 고르고 통과하면(값을 고쳐야 하면 수정 후 통과) 그 통과가 승인으로 기록되고, 직원은 그 승인으로 발주 메일을 보냅니다. 서버가 보내기 직전에 승인한 줄을 다시 읽어 확인합니다. 이어서 사람이 발주 내용을 한 번 더 확인해 통과하면, 그 승인으로 ERP에 발주를 등록합니다. 첫 건은 직원이 되읽어 저장된 값을 보여 줍니다. 직원은 ERP 전표 번호와 등록일을 되읽은 값으로 발주 테이블에 기록합니다. 발주는 필요건 하나에 하나입니다.

승인한 뒤 내용이 바뀌면

승인한 뒤 거래처, 수량, 단가, 통화, 납기, 유효기간 같은 값이 바뀌었거나, 견적 유효기간이 지났거나(유효기간 날짜가 오늘보다 이전일 때이고, 유효기간이 비어 있으면 만료로 보지 않습니다), 줄이 사라졌으면 아무것도 나가지 않습니다. 발주 메일도, ERP 등록도 멈춥니다. 직원이 무엇이 바뀌었거나 만료됐는지 알려 주고 새로 승인을 요청합니다. 예전 승인으로 다시 시도하지 않고, 승인 없이 보내지도 않습니다.

ERP 응답이 “결과 모름”으로 오면 직원은 멈추고, 레코드를 읽어 실제로 들어갔는지 확인한 뒤 정리하거나 사람에게 넘깁니다. 같은 발주를 두 번 올리지 않도록 직원이 등록 키를 같은 발주에 대해 고정해서 씁니다.

반복 업무로 저장하기

한 번 끝까지 해 보았다면 직원에게 “이 일을 반복할 수 있게 저장해 줘”라고 요청하세요. 직원이 6단계 절차(필요건 접수, 견적 의뢰, 회신 수집, 비교·선정, 발주 메일, ERP 등록)를 만들고, 확인하는 사람과 고정 같은 설정은 승인 카드로 하나씩 받습니다. 절차 저장의 일반 흐름은 첫 업무를 업무 절차로 저장하고 다시 쓰기와 업무 절차를 참고하세요.

선정 단계와 ERP 등록 전 발주 확인 단계는 항상 사람이 확인합니다. 확인은 그 단계가 만든 결과를 다음 단계 전에 보는 것이라, ERP 등록 전 확인은 발주 단계에 둡니다. 표본으로 줄이는 설정은 권하지 않습니다.
확인하는 사람의 역할은 직원이 카드를 보내기 전에 물어봅니다. 조직에 없는 역할은 만들지 않습니다.
입력 양식에서 필요건 번호는 목록에서 고르지 못하고 직접 입력합니다.
비교와 선정은 포털에 게시된 절차에서만 가능합니다. 게시는 업무 포털이 열려 있어야 하고 조직 소유자가 합니다. 개인 공간이나 포털이 열리지 않은 공간에서는 절차만 저장되고, 선정은 데이터 화면의 견적서 테이블에서 해당 기록을 열어 수정으로 선정 칸을 직접 기록하는 방식으로 합니다(데이터를 수정할 수 있는 구성원이 가능하고, 직원이 못 쓰도록 보호된 칸도 사람은 고칠 수 있습니다). 이 경우 포털 확인 화면의 통과가 없어서 “승인한 내용과 같을 때만” 대조는 적용되지 않습니다.
고정하기 전에 견적서 읽기 스킬이 줄마다 줄 키를 쓰는지 직원이 확인합니다. 그 뒤 스킬이 바뀌면 다시 고정해야 합니다.
고정은 사람이 한 번 끝까지 본 뒤에 하는 것을 권합니다.

한계와 주의

통화 환산이 없습니다. 다른 통화의 금액을 같은 기준으로 바꿔 주지 않습니다.
필요건 번호는 직접 입력합니다(위 참고).
포털 게시에는 조직 소유자가 필요합니다.
비교 테이블 구성과 승인 대조 항목이 틀리면(항목 이름 오타 등) 비교나 대조가 빠질 수 있습니다. 게시한 뒤 첫 실행에서 비교 화면이 나오는지 눈으로 확인하세요.
거래처 메일 주소가 틀렸다면 알려 주세요. 직원이 수정을 기억해서 다음에 반영합니다.
메일은 성공한 한 통마다 SU가 들고, 하루 발송 한도가 있습니다. 거래처가 많아 남은 한도보다 큰 묶음은 준비 단계에서 거절됩니다.

다음 단계

거래처 주문 접수 → ERP 등록: 이카운트 연결 준비와 ERP 연동 방식
승인: 승인 카드가 뜨는 때
데이터: 테이블 보기와 편집
업무 절차: 저장한 절차와 게시

고급 (Advanced)

아래 내용은 일반 사용자에게 필요하지 않습니다. 테이블 구성을 직접 손보거나, 비교·승인 대조가 기대와 다를 때만 참고하세요.

테이블 5종과 기록 구분 기준

테이블	한 줄의 뜻	기록 구분 기준
필요건	부품 필요 한 건	필요건 번호
거래처	거래처 한 곳	거래처 코드
견적 의뢰	필요건 하나와 거래처 하나의 의뢰 (번호는 필요건 번호와 거래처 코드를 이은 값)	의뢰 번호
견적서	견적 한 줄	의뢰, 거래처, 견적 번호, 수정 차수, 줄 키
발주	필요건당 발주 한 건	필요건 번호

견적서의 줄 키가 없으면 수량별 단가처럼 줄이 둘 이상인 견적이 서로 덮어쓰거나 중복으로 거부됩니다. 줄 키는 견적서 읽기 스킬이 모든 줄에 채웁니다.
거래처 테이블의 사내 품질 점수·품질 메모, 견적서 테이블의 선정 칸은 보호 칸입니다. 사람이 쓰고 직원은 읽기만 합니다.
견적서 줄의 수정 차수는 문자열이며 표기가 없으면 “0”입니다.
이 테이블들은 프리셋 구성에서 바로 만들어지지 않고 승인 카드로 만들어집니다. 번들은 출발점일 뿐이며 기록 구분 기준은 상속되지 않으므로, 새 조직의 견적서 테이블에 줄 키가 빠지지 않았는지 확인하세요.

선정 단계가 싣는 설정

저장한 절차의 선정 단계에는 확인하는 사람(게이트)과 함께 두 설정이 실립니다.

비교 설정: 견적서 테이블의 단가를 값으로, 필요건 번호와 통화로 묶고, 거래처·납기일·품질 점수를 보조 칸으로 보여 줍니다. 같은 필요건, 같은 통화끼리만 최저·최고를 판정하며 환산하지 않습니다. 납기는 일수 대신 납기일을 보여 줍니다.
승인 대조 설정: 승인 뒤 바뀌면 안 되는 칸(거래처, 수량, 단위, 단가, 통화, 최소 주문 수량, 금액, 리드타임, 납기일, 유효기간)과 만료 기준 칸(유효기간)을 정합니다. 상태, 선정, 메모, 품질 점수는 넣지 않습니다. 이후 단계가 상태를 갱신해도 대조가 깨지지 않게 하기 위해서입니다.
이름이 테이블 정의와 다르면 대조 스냅샷이 만들어지지 않을 수 있습니다. 그러면 다음 단계가 대조 없이 돕니다. 게시 직후 첫 실행에서 비교 표가 보이는지, 다음 단계 입력에 승인 정보가 실려 있는지 확인하세요.

승인 id로 묶기 (`--approval-binding-id`)

선정이 승인되면 직원은 승인 id 하나를 받습니다. 발주 메일은 send --approval-binding-id <id> 한 번으로, 여러 받는 사람이면 prepare_batch --approval-binding-id <id>로 보냅니다. ERP 쓰기는 erp_write.approval_binding_id에 발주 확인 단계의 승인 id를 넣습니다(선정 id는 견적서 줄, 발주 확인 id는 발주 줄을 묶습니다). 호출당 id는 하나입니다. 서버는 보내기 직전에 승인된 줄을 다시 읽고, 바뀌었거나 만료되었거나 사라졌으면 APPROVAL_BINDING_*로 거절합니다. 이때 아무것도 나가지 않고, 응답에 어떤 항목이 달라졌는지 이름만 담깁니다.

회신 대기 상태

견적 의뢰 행의 진행 상태(발송 전, 의뢰됨, 회신됨, 마감)와 회신 결과(견적 준비, 문의·보완 필요, 거절, 무응답)는 따로 기록됩니다. 직원은 회신 결과를 메일 기다림 상태와 같은 턴에 맞춰 적습니다.

회신 결과	기다림 상태	조건
견적 준비	READY	견적서 줄이 들어와 의뢰와 이어짐, 짝지어진 회신 필요
문의, 보완 필요	NOT_READY	짝지어진 회신 필요
거절, 무응답	CLOSED	회신 없이도 닫을 수 있음

마감은 지금부터 10분~60일 사이에 두고 독촉 시각은 최대 3개입니다. 마감이 지나면 그 배치와 독촉은 더 보내지 못하고, 새 마감으로 새 배치를 만들어야 합니다.