부족 재고를 말로 조회하고 발주 초안까지, 승인부터 설계하는 ERP 자동화

구매 담당자가 ‘다음 주 생산에 부족한 자재를 찾아 발주 초안을 만들어 줘’라고 입력했다고 가정해 보겠습니다. 필요한 것은 그럴듯한 답변 한 줄이 아닙니다. 어느 창고의 재고를 봤는지, 이미 주문한 물량은 뺐는지, 몇 개를 더 사야 하는지 확인할 근거가 필요합니다. 자연어 ERP 연동은 이 조회와 초안 작성을 돕되, 구매 확정은 권한이 있는 담당자에게 남기는 방식으로 설계할 수 있습니다.

소프트모아 자동화 서비스 안내에는 대화로 업무를 시작해 자료를 조회하고 저장 전에 확인하는 흐름, 지난 발주 내역으로 초안을 만들어 승인함에 올리는 기능이 소개돼 있습니다. 아래 재고 수량과 승인 규칙은 그 방향을 구매 업무에 적용해 보는 설계 제안입니다. 실제 고객의 납품 사례나 운영 성과를 소개하는 글은 아닙니다.

‘부족하다’는 기준부터 화면에 보여 줍니다

이 예시에서는 생산 계획에 필요한 수량과 생산 후 남겨 둘 안전재고를 합한 뒤, 사용 가능한 재고와 기한 내 입고가 확정된 미입고 수량을 뺍니다. 예약 재고와 검사 대기 재고는 사용 가능 수량에서 제외합니다. 이미 입고한 물량을 입고 예정에도 넣으면 이중 계산이 되므로 발주 잔량을 기준으로 조회하도록 정합니다.

가상의 자재 A를 보겠습니다. 다음 주 필요량은 120개, 안전재고는 20개입니다. 창고에 기록된 70개 중 다른 작업에 예약된 10개를 빼면 사용 가능한 수량은 60개입니다. 생산 시작 전에 들어올 확정 물량 30개를 반영하면 부족분은 50개가 됩니다. 공급처가 20개씩 포장해 판매한다는 조건에서는 발주 제안량이 3상자, 60개입니다. 부족분보다 10개 더 주문하는 이유도 초안에 표시합니다.

계산 결과 옆에는 대상 창고, 생산 기간, 조회 시각과 근거 문서 번호를 붙입니다. 입고 예정 30개의 납기가 아직 확인되지 않았다면 같은 결과를 확정안처럼 보여 주지 않습니다. 해당 물량을 제외한 부족분 80개와 ‘납기 확인 필요’ 사유를 함께 제시하고 담당자 검토를 기다리도록 제안합니다.

한 문장을 조회 조건과 구매 초안으로 나누기

사용자는 메뉴 이름을 외우는 대신 음성이나 텍스트로 요청합니다. 다만 ‘다음 주’의 날짜 범위와 대상 창고는 조회 전에 확인 카드에 표시하도록 설계합니다. 창고가 여러 곳인데 요청에 지정이 없으면 되묻습니다. AI가 임의로 전체 창고를 합산해 다른 사업장의 물량까지 쓸 수 있다고 판단하지 않게 하는 장치입니다.

연동할 데이터는 품목 코드, 재고와 예약 수량, 생산 계획, 미입고 발주 잔량, 납기, 공급처와 구매 단위입니다. ERP의 조회 API로 이 자료를 읽고 품목 코드를 맞춘 뒤 계산 결과를 표로 돌려주는 구성을 제안합니다. 자연어는 요청을 해석하는 데 쓰고, 수량 계산과 단위 변환은 합의한 업무 규칙으로 처리합니다. ‘개’와 ‘상자’의 환산 정보가 없으면 수량을 추측하지 않고 초안 작성 대상에서 제외합니다.

사용자가 조회 결과를 확인하면 구매 초안을 저장하는 별도 API를 호출하도록 나눕니다. 초안에는 품목 A, 3상자, 총 60개, 공급처, 희망 납기와 계산 근거를 담습니다. 단가나 공급처가 미확정이면 빈칸을 임의로 채우지 않고 확인할 항목으로 남깁니다. 이 단계의 상태는 DRAFT이며, 저장했다는 메시지가 거래처에 발주서를 보냈다는 뜻은 아닙니다.

승인 버튼 뒤에서도 조건을 다시 확인합니다

제안하는 권한 구조에서는 재고 조회, 초안 작성, 구매 승인, 발주서 전송을 구분합니다. AI의 연동 계정에는 허용한 창고의 조회와 초안 작성 권한만 부여합니다. 승인 권한은 구매 책임자의 계정에서 서버가 확인하고, 사용자가 대화에 ‘승인 완료’라고 적어도 실제 승인 기록으로 받아들이지 않도록 설계합니다.

승인 화면에는 수량과 단가, 금액, 납기, 공급처를 한 번에 보여 줍니다. 검토 중 재고가 바뀌거나 다른 담당자가 같은 자재를 주문했다면 기존 초안을 그대로 확정하지 않고 다시 계산하게 합니다. 수정된 수량은 재승인을 받습니다. 승인 후 발주서 전송까지 연결할지는 별도 범위로 정하며, 이 예시의 기본 범위는 초안 저장과 사람의 승인 처리까지입니다.

응답이 끊겼을 때도 같은 초안을 또 만들지 않도록

저장 버튼을 눌렀는데 응답이 늦으면 사용자는 다시 누르기 쉽습니다. 이때 새 구매 건을 만드는 대신 동일 요청에 같은 식별자를 보내 기존 처리 결과를 확인하는 멱등성 설계를 제안합니다. 요청 식별자와 초안 번호를 연결하고 서버에서 중복 생성을 막는 방식입니다. 서로 다른 사용자가 별도로 만든 유사한 요청까지 자동으로 같은 건이라고 단정하지는 않습니다.

ERP가 초안을 저장했는지 알 수 없는 통신 오류는 ‘실패했으니 재작성’으로 처리하지 않습니다. 결과 확인 중 상태를 남기고 요청 식별자로 조회한 뒤 재시도 여부를 정합니다. 연동 대상이 이 조회나 중복 방지를 지원하지 않는다면 별도 연동 기록과 수동 확인 절차를 먼저 마련하는 것이 구현 조건입니다.

감사 기록에는 요청자, 조회 조건과 시각, 참조한 데이터 버전, 계산 근거, 초안 변경 전후 값, 승인자와 ERP 반환 번호를 남기도록 제안합니다. 비밀키는 기록하지 않고 업무 자료의 열람 범위와 보관 기간도 함께 정합니다. 초안 저장, 승인, 전송, 입고는 각각 다른 상태로 관리해야 화면의 완료 표시가 실제 물품 입고로 오해되지 않습니다.

도입 상담에는 현재 쓰는 발주서부터 준비하세요

처음부터 구매 전 과정을 연결하기보다 창고 한 곳과 품목군 하나로 조회 결과와 사람이 계산한 수량을 대조하는 범위를 제안합니다. 현재 발주서 양식, 재고 기준, 포장 단위, 승인 담당자, ERP API 제공 여부를 준비하면 어디까지 연동할지 구체적으로 논의할 수 있습니다. API가 없거나 쓰기 권한을 받을 수 없는 경우에는 조회나 검토용 초안까지만 범위를 줄여야 합니다.

소프트모아 홈페이지에서는 고객맞춤 ERP와 전산시스템, AI 업무자동화 및 API 개발을 안내합니다. 재고 부족 판단과 발주 승인 규칙은 회사마다 다르므로 기존 업무와 데이터부터 확인한 뒤 구축 범위를 정하는 방식으로 상담할 수 있습니다.

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

참고: https://www.softmoa.com/ · https://www.softmoa.com/automation

소프트모아 · 구축 문의