자재 수령증 50장, 프로젝트 원장 하나: 급하게 처리하지 않고 일괄 처리하는 방법

대부분의 중형 건설 현장에서 자재 수령증 — 트럭이 게이트를 통과할 때 현장소장이 서명하는 배송 전표 — 은 여전히 1995년과 같은 방식으로 현장에서 공사 원장까지 이동합니다. 글러브 박스에 사흘 동안 방치됐다가 금요일에 사무실 책상 위에 쌓이고, 스프레드시트에 필드 하나씩 다시 입력되는 식이죠. 다시 입력하는 것이 진짜 문제는 아닙니다. 진짜 문제는 모든 전표의 숫자가 구매 주문서와 공급업체 송장이라는 두 문서와 일치해야 하는데, 입력하는 사람만 그 세 문서를 모두 알고 있다는 점입니다. 업계 조사에 따르면 건설 현장에 배송된 자재의 최소 10%가 손상, 분실, 과다 주문으로 낭비됩니다 — 그리고 수령증이 기록되지 않았다면 이 세 가지 실패 유형 중 어느 것도 사후에 잡아낼 수 없습니다.

주간 티켓 더미: 자재 비용 데이터가 실제로 쌓이는 곳

자재 수령증은 공사 원장으로 끝나는 3개 문서 체인의 첫 번째 문서이며, 세 문서 중 현장에 실제로 반입된 것을 증명하는 유일한 문서입니다.

배송마다 티켓이 한 장씩 생성되며, 자재 유형마다 각기 다른 형식이 있습니다. 레미콘 공장은 배합 설계, 슬럼프, 입방 야드 단위의 용량, 배치 시간, 트럭 번호가 담긴 컴퓨터 티켓을 출력합니다. 목재소는 트럭을 적재한 직원이 약어로 품목을 적은 손으로 쓴 카본 사본을 보냅니다("2×6 #2 SPF 16'"). 철근 가공업체의 티켓은 등급과 길이별로 철근을 나열합니다. 공통된 골격이 있습니다: 티켓 번호, 날짜, 공급업체 이름, 자재 설명, 수량, 측정 단위, 그리고 수령을 법적으로 구속력 있게 만드는 서명란입니다. 5~8개 프로젝트를 운영하는 상업용 GC라면 이 골격은 매주 모든 활성 현장에서 30~60회 작성됩니다.

그 티켓들은 게이트를 지나면 어디로 갈까요? 트럭, 조끼, 센터 콘솔로 갑니다. r/Construction의 분실 현장 티켓 관련 게시글은 현실을 잘 보여줍니다: 작업자들의 기본 워크플로우는 "사진 + 음성 메모 보내기"이고, 서류는 분실되며, 인력이 부족할 때 규율 개선만으로는 한계가 있습니다. 오전 7시에 콘크리트를 서명 수령하고 현장소장에게 티켓 사진을 보내는 현장반장은 올바른 일을 하는 것입니다 — 하지만 문자 스레드 속 사진은 원장 항목이 아니며, 금요일이 되면 아무도 찾을 수 없는 40장의 사진 중 하나가 됩니다.

배송 전표는 현장에 실제로 반입된 것을 기록한 유일한 문서입니다 — 하지만 회계 구조는 전혀 포함되어 있지 않습니다. 누군가가 이를 변환해야 하며, 트럭에 방치된 하루하루가 지날수록 변환은 더 어려워지고 대사 기간은 더 짧아집니다.

그 변환을 미루는 비용은 측정 가능합니다. ScienceDirect의 건설 폐기물 문헌에 정리된 연구에 따르면 건설 현장에 반입된 자재의 최소 10%가 손상, 분실, 과잉 주문으로 낭비되며, 별도 추정치는 반입 자재 총 중량의 최대 30%에 달한다고 합니다. 과잉 주문은 "이미 현장에 얼마나 있는가?"라는 질문에 아무도 답할 수 없을 때 발생합니다. 수령증이 기록되지 않았기 때문입니다. 만들지도 않은 스프레드시트에서는 과잉 주문을 잡아낼 수 없습니다.

세 문서가 일치해야 합니다: 수령증, 구매 주문서, 송장

자재 수령증, 구매 주문서, 공급업체 송장은 3자 대사를 이루며, 각 문서는 서로 다른 질문에 답합니다: 무엇을 주문했는지, 실제로 무엇이 도착했는지, 공급업체가 지불을 요구하는 금액이 무엇인지.

구매 주문서는 약속입니다 — 트럭이 공급업체 창고를 떠나기 전에 합의한 수량과 가격입니다. 자재 수령증은 배송 증명입니다 — 현장에서 누군가 서명한, 실제로 트럭에서 내려진 수량입니다. 송장은 지불 요구입니다 — 공급업체의 청구 시스템이 생성한 것으로, 처음 두 문서 중 어느 것과도 일치하지 않을 수 있습니다. 건설에서 수령증과 송장이 거의 동시에 도착하는 경우는 없습니다: 화요일에 배달된 콘크리트는 다음 주에 나타나는 송장을 생성하며, 언제든지 지급 계정에는 수령되었지만 아직 청구되지 않은 자재 잔액이 있습니다 — 발생 회계에서는 이를 GRNI라고 부르며, 월말 마감 시 정확히 추정하지 않으면 프로젝트 비용이 잘못된 기간에 기록됩니다.

회계 위에는 법적 층위가 있습니다. UCC Article 2 §2-606에 따라, 합리적인 검사 기회 후 배송 전표에 서명하는 것은 상품 수령을 의미하며, §2-602에 따른 부족분 거부 권리는 트럭이 떠나면 종료됩니다. 그리고 AIA A201-2017 §3.3.3에 따라, 시공사는 인도된 작업을 검사할 계약상 의무를 집니다. 게이트에서의 서명은 부족한 배송을 잡을 마지막 기회이자 도착한 것을 수령했다는 법적 기록입니다. 그래서 전표 더미는 "그냥 서류"가 아닙니다 — 이번 분기에 공급업체와 겪을 모든 분쟁에 대한 증거 기록입니다. 이 체인의 수령 측면에 대해서는, 게이트에서 건설 BOL을 PO와 대사하는 가이드에서 운전자가 아직 있을 때 부족분을 잡는 방법을 다룹니다.

문서	증명하는 것	포함된 필드	출처
자재 수령증	현장에 실제로 도착한 것	전표 번호, 날짜, 공급업체, 자재, 수량, 단위, 수령자 서명	운전자 + 현장 서명
구매 주문서	구매를 약속한 것	PO 번호, 공사 번호, 비용 코드, 품목, 주문 수량, 단가	조달 팀
공급업체 송장	공급업체가 청구하는 금액	송장 번호, 날짜, 라인 항목, 가격, 합계, 지불 조건	공급업체 청구 시스템

맨 위 행의 중간 열에서 빠진 것이 무엇인지 주목하세요. 수령증 — 진실의 지점에서 생성되는 유일한 문서 — 에는 회계 시스템이 기록하는 데 필요한 필드가 전혀 없습니다: 공사 번호, 비용 코드, 일반적으로 PO 번호와 가격도 없습니다. 전표를 장부에 연결하는 모든 것은 문서 외부에서 제공되어야 합니다. 이것이 배송 전표 수동 입력이 오류에 취약한 구조적 이유이며, 문제가 더 빠른 타이피스트가 아닌 워크플로우를 필요로 하는 이유입니다.

금요일 수동 입력이 유일한 임무에서 실패하는 이유

배송 전표의 수동 입력은 속도 때문에 실패하는 것이 아닙니다. 맥락 때문에 실패합니다. 입력하는 사람이 전표에 인쇄되지 않은 세 가지 필드를 기억에서 연속 50회 제공해야 하기 때문입니다.

금요일 입력 작업이 실제로 무엇을 수반하는지 생각해 보세요. 각 전표에 대해 사무 관리자는 공급업체 이름을 읽고 올바른 공사에 정신적으로 매핑합니다. 그런 다음 각 품목을 읽고 자재 설명에 따라 CSI MasterFormat 비용 코드를 정신적으로 할당합니다. 그런 다음 해당 화물이 주문된 구매 주문서를 찾습니다. 그런 다음 수량과 단위를 입력합니다. 주당 40장의 전표에 전표당 평균 두 개의 품목이 있다면, 약 300개의 결정이 필요하며 각각은 자재, 공급업체, 공사 사이의 맥락 전환입니다.

이것이 프로세스가 최악의 오류를 만들어내는 지점이며, 건설 회계사가 즉시 알아볼 수 있는 패턴입니다. 이전 전표에서 "목재 모드"에 있던 입력자의 뇌 때문에 건식벽 나사가 09 29 00 대신 06 11 00으로 코딩되는 경우. 전표에 200이라고 되어 있는데 철근 길이 180개가 짧게 배송되어 게이트에서 서명되고 결코 표시되지 않으며, 송장은 200개에 대해 지불되는 경우. 공급업체의 공사 참조가 시스템의 어떤 구매 주문서와도 일치하지 않아 전표가 "기타" 폴더에 남고 자재 비용이 프로젝트에 전혀 게시되지 않는 경우. Acumatica Construction 커뮤니티 스레드 "PO Receipts in Construction — PMs Won't Do Them"은 입고 단계가 너무 어려울 때 무슨 일이 일어나는지에 대한 연속적인 기록입니다. 프로젝트 관리자는 "너무 어렵고 단계가 너무 많다"며 완전히 건너뛰고, 청구할 입고가 없어 송장이 지불되지 않으며, 실제 비용이 프로젝트 예산에 게시되지 않아 경영진이 모든 진행 중인 프로젝트에서 불완전한 데이터로 결정을 내립니다.

입고가 기록되지 않아 공사 비용이 과소 계상되면 진행 중인 작업 명세서는 부풀려진 총 이익을 보여줍니다. 초과 청구는 감지되지 않고, 보증 능력은 약화되며, 회사가 보게 되는 첫 번째 정확한 숫자는 모두가 괜찮다고 생각했던 프로젝트의 손실입니다.

이 중 어느 것도 데이터 입력 속도 문제가 아닙니다. 사무실에서 가장 빠른 타이피스트라도 전표에 없는 공사 번호, 전표에 없는 비용 코드, 또는 3일 전 게이트에서 서명된 내용에 대한 기억을 제공할 수 없습니다. 수동 접근 방식은 단지 지루한 부분이 아니라 중요한 부분인 대사에서 실패합니다.

일괄 워크플로: 원장을 한 번 정의하고 모든 전표에 적용하기

일괄 추출은 프로세스를 뒤집습니다: 필요한 원장 열을 한 번 정의하고, 그 주의 전표를 함께 업로드한 다음, 모든 전표가 이미 행으로 정리된 스프레드시트 하나를 다운로드합니다.

일괄 처리는 여러 문서를 한 번에 업로드하여 단일 출력 파일로 병합하는 것을 의미합니다 — 각 전표를 개별적으로 추출하고 결과를 마스터 시트에 복사하여 붙여넣는 대신, 병합이 추출 시점에 이루어집니다. 먼저 프로젝트 재고 원장에 필요한 열을 정의합니다 — 공사 원가 워크북이나 ERP 가져오기 템플릿에 원하는 헤더와 동일한 항목입니다:

전표 번호 | 날짜 | 공급업체 | 공사 번호 | 구매 주문서 번호 | 비용 코드 | 자재 | 수량 | 단위 | 단가 | 라인 합계 | 수령자 | 송장 번호 | 상태

그런 다음 그 주의 전표를 하나의 배치로 업로드합니다 — 콘크리트 공장의 컴퓨터 출력물, 목재소의 탄소 사본, 철근 제조업체의 시스템 전표, 현장소장이 트럭에서 내려온 물건을 찍은 휴대폰 사진까지. 여기서 열 이름 추출이 작동합니다: 각 문서에서 각 필드가 어디에 있는지 도구에 알려주는 대신, 각 필드가 무엇을 의미하는지 알려줍니다. AI는 손으로 쓴 탄소 사본에서 "전표 번호"를 찾을 때, 해당 공급업체 형식에서의 위치가 아니라 전표 번호가 무엇인지 이해하여 찾습니다. 수량이 표의 열에 있든, 설명 아래에 있든, 여백에 휘갈겨 쓰여 있든 "수량"을 찾아냅니다.

금요일 오후 5시에 중요한 운영상의 차이: 파일 하나를 다운로드하는 것이지 50개가 아닙니다. 모든 전표의 모든 라인 항목이 동일한 열로 동일한 스프레드시트에 들어갑니다 — 개별 내보내기를 열 필요도, 마스터 워크북에 행을 복사할 필요도, 뭔가 어긋나지 않기를 바랄 필요도 없습니다. 파일이 열리는 순간 행은 이미 공사 번호별로 정렬 가능하고, 구매 주문서 번호별로 필터링 가능하며, 비용 코드별로 소계를 낼 수 있습니다.

JPG/PNG/PDF AI 추출

파일은 안전하게 처리되며 저장되지 않습니다.

일괄 처리 방식은 설정 비용 없이도 확장됩니다. 41번째 공급업체가 완전히 새로운 전표 형식을 가져와도 추가 설정 비용은 0원입니다. 만들 템플릿도, 그릴 영역도, 공급업체별 학습 데이터도 없습니다. 열 정의는 형식에 구애받지 않으며, 새 공급업체의 전표는 처음 40개와 동일한 파이프라인을 거쳐 동일한 통합 스프레드시트에 들어옵니다. 이것이 매달 더 어려워지는 프로세스와 일정하게 유지되는 프로세스의 차이입니다.

전표에 인쇄되지 않는 필드: 공사 번호, 비용 코드, 구매 주문서

원장에 가장 필요한 세 가지 필드는 정확히 공급업체의 배송 전표에 거의 인쇄되지 않는 필드입니다.

레미콘 공장은 내부 공사 번호를 모릅니다. 목재 야적장은 CSI MasterFormat을 알지 못합니다. 그들의 전표에는 자체 주문 번호와 자체 자재 코드가 있으며, 누군가는 그 간극을 메워야 합니다. 수동 작업에서는 그 다리가 사무실 관리자의 기억력이며, 금요일마다 300번씩 사용됩니다. 일괄 처리에서는 그 다리가 한 번 작성하면 AI가 모든 전표에 적용하는 규칙 집합입니다. 이것이 추론 열이 하는 일입니다. 추론 열은 페이지에 인쇄된 값을 추출하지 않고, 문서에 없던 값을 결정하기 위해 정의한 규칙을 적용합니다. 공사 번호의 경우 다음과 같은 추론 규칙이 있는 "공사 #" 열을 정의합니다:

공사 #:

AI가 Gerdau의 전표를 읽으면 공급업체 이름을 규칙과 대조하여 해당 전표의 모든 줄에 "24-003"을 채웁니다. 동일한 패턴이 비용 코드에도 적용되지만, 추론은 공급업체별이 아니라 자재별로 이루어집니다. "레미콘"은 03 31 00, "#4 철근"은 03 21 00, "2×6 SPF"는 06 11 00, "5/8″ Type X"는 09 29 00에 매핑됩니다. 목재와 건식벽체를 모두 배송하는 공급업체는 두 개의 서로 다른 비용 코드가 있는 행을 생성하며, 둘 다 자동으로 할당됩니다. 규칙에 일치하는 항목이 없으면 셀은 추측하는 대신 비워 두는데, 이것이 바로 원하는 방식입니다. 빈 셀은 검토 단계에서 예외를 표시하여 비용을 잘못된 부문에 조용히 코딩하는 것을 방지합니다.

구매 주문서 참조는 약간 다른 처리가 필요합니다. 공급업체의 전표에는 공사 이름이나 자체 주문 번호가 있을 수 있고, 구매 주문서 번호가 아닐 수 있기 때문입니다. 가장 깔끔한 방법은 전표에 있는 참조를 자체 열로 추출한 다음 조회 테이블을 사용하여 추출 후 스프레드시트의 구매 주문서 열을 채우는 것입니다. 구매 주문서에 직접 주문한 하중의 경우 계산 열이 배송 수량을 구매 주문서의 주문 수량과 비교하여 차이를 표시할 수도 있습니다. 계산 열은 추출 중에 계산을 실행합니다. "라인 합계"는 전표에 인쇄되지 않은 값을 도출하고, "수량 vs 구매 주문서"는 "OK", "SHORT", "OVER"를 출력하여 불일치가 별도의 다음 주 검토 회의가 아닌 데이터와 같은 파일에서 표시되도록 합니다.

개별 전표 버전의 이 워크플로우 — 자재 수령증 하나를 추출하고 모든 필드 선택을 살펴보는 과정 — 에 대해서는 건설 자재 수령증 데이터 추출 단계별 가이드에서 더 자세히 다룹니다. 또한 구매 주문서 자체를 수령증과 함께 일괄 처리하는 경우, 건설 구매 주문서 일괄 공사 원장 워크플로우에서 동일한 원장의 주문 측면을 다룹니다.

원장 행에서 3자 대사까지

한 주의 전표가 하나의 스프레드시트에 행으로 정리되면, 3자 대사는 더 이상 문서 찾기가 아니라 열 필터가 됩니다.

1. 수령증 대 구매 주문서 — 부족 납품을 설명 가능한 시점에 잡아냅니다. PO 번호로 정렬하거나 필터링하여 납품 수량을 주문 수량과 비교합니다. #4 철근 200개 길이를 3회에 나눠 납품받은 PO는 세 개의 전표 행을 생성하며, 필터로 그룹화하면 합계가 한눈에 PO와 대조할 수 있는 하나의 숫자가 됩니다. "수량 대 PO" 열은 20개 부족하게 도착한 화물을 표시합니다. 그 부족분은 게이트에서 서명되었고 — 전표가 증명합니다 — 수령증이 기록되어 있으므로, 인출 마감일에 발견하는 대신 문서를 들고 공급업체에 이의를 제기할 수 있습니다.

2. 수령증 대 송장 — 월말 마감 시 미청구 입고품을 정확히 유지합니다. "송장 번호" 열을 추가하고 송장이 도착할 때마다 표시합니다. 수령증은 있지만 송장 번호가 없는 행이 미청구 입고품(GRNI) 잔액입니다 — 입고는 했지만 송장이 다음 기간에 도착할 자재입니다. 공급업체별, 공사별로 소계를 내면, 회계 담당자가 마감 시 서류 더미 없이 필요한 발생 비용 숫자가 나옵니다. 송장이 도착하면 전표 번호로 VLOOKUP 매칭하고 — 원장에 없는 전표를 참조하는 송장은 지불 후가 아니라 지불 전에 조사 대상으로 표시됩니다.

3. 수령증 대 시공 수량 — 현장에 실제로 남아 있는 것. 원장을 공사 번호와 비용 코드별로 소계하여 프로젝트별 수령 자재 수량을 얻습니다. 이 숫자는 누군가 추가 주문을 하기 전에 "이미 현장에 얼마나 쌓여 있나?"라는 질문에 답합니다. 이 확인은 10% 폐기율 수치에서 과잉 주문 요소를 직접 공격하는 검증입니다: 원장에 40,000보드피트가 입고되었고 골조 팀이 30,000을 사용했다면, 20,000을 추가 주문하는 것은 기본값이 아니라 대화가 필요합니다. 수령증과 함께 쌓이는 월간 문서에는 허가증과 규정 준수 문서도 포함됩니다 — 건설 허가증 데이터 추출 워크스루에서 동일한 일괄 접근 방식을 해당 서류에 적용하는 방법을 보여줍니다.

원장이 대사를 대신 해주지는 않습니다 — 대사가 보이게 만듭니다. 다섯 개의 문서를 열고 기억에 의존해야 했던 모든 확인이 이제 필터, 소계, 또는 SHORT라고 표시된 열이 됩니다.

배치가 깔끔하지 않을 때: 손글씨, 분할 배송, 누락된 전표

배송 전표 배치에는 번진 손글씨, 분할 배송, 그리고 사무실에 도착하지 못한 전표가 섞여 있기 마련입니다 — 워크플로는 이런 예외 상황을 흡수할 수 있어야지, 무너져서는 안 됩니다.

손글씨. AI는 손글씨 전표를 인쇄된 전표와 동일한 방식으로 읽으며, 판독 가능 여부가 핵심 변수입니다. 현장 직원이 작성한 또렷한 카본 사본은 인쇄된 전표와 거의 동일한 정확도로 추출되지만, 어두운 트럭 안에서 촬영한 번진 사본은 정확도가 낮아 확인이 필요합니다. 바로 여기서 검토 모드의 가치가 드러납니다: 추출된 셀 위에 마우스를 올리면 도구가 원본 이미지에서 해당 값이 나온 위치를 정확히 표시해 주므로, 손글씨 수량을 확인할 때 전표 전체를 뒤질 필요 없이 한눈에 확인할 수 있습니다. 검증 단계가 존재하는 이유는 추출이 항상 완벽하다고 보장할 수 없기 때문입니다 — 완벽하다고 가정하는 워크플로는 처음 틀렸을 때 버려지기 마련입니다.

분할 배송. 하나의 구매 주문서가 트럭 3대로 나뉘어 배송되면 전표 3장이 생성되는데, 이는 문제없습니다 — 각 전표는 각자의 행이 되고, 구매 주문서 필터가 이를 하나의 이행 보기로 묶어 줍니다. 원장 구조는 부분 배송을 자연스럽게 흡수합니다; 어려움을 겪던 쪽은 수작업 프로세스였습니다. 전표가 각각 따로 파일링되어 "전부 받았나?"라는 질문에 단일한 답이 없었기 때문입니다.

누락된 전표. 현장 반장이 전표를 촬영했지만 아무도 기록하지 않았거나, 콘크리트 전표가 운전석에 그대로 남아 있는 경우가 있습니다. 원장은 이를 정직하게 처리합니다: 해당 주의 행은 완전하고, 수령 행이 0으로 표시된 구매 주문서는 눈에 띄는 공백으로 남습니다. 그 가시성이 바로 해결책입니다 — 수령 내역이 없는 구매 주문서는 아무도 열어보지 않는 빈 폴더가 아니라, 배송이 아직 최근일 때 현장소장에게 물어볼 수 있는 구체적이고 실행 가능한 질문이 됩니다.

그리고 단일 전표가 잘못 추출된 경우 — AI가 4,800야드를 4,200야드로 읽은 경우 — 배치 전체가 아닌 해당 행 하나만 수정하면 됩니다. 출력물은 하나의 스프레드시트이므로, 잘못된 줄은 다시 추출하거나 그 자리에서 수정하면 되고 나머지 파일은 그대로 유지됩니다. 워크플로가 완벽할 필요는 없습니다; 통제 가능하면 충분합니다. 그래야 잘못된 전표 하나가 금요일 밤에 전체 재실행이 아니라 5분만에 해결됩니다.

직접 배송 전표로 차이를 확인해 보세요

일주일치 전표를 업로드하세요 — 페이지당 10초 만에 구조화된 원장 데이터 생성

직접 사용해 보기 →

가입 불필요 · 신용카드 불필요 · 10초 내 결과 확인

자주 묻는 질문

AI가 공급업체의 손글씨 배송 전표를 읽을 수 있나요?

네, 가능합니다. 추출 엔진은 인쇄된 텍스트와 동일한 방식으로 손글씨를 읽으며, 판독 가능 여부가 정확도의 주요 변수입니다. 선명하게 작성된 카본 사본 배송 전표는 인쇄된 전표와 거의 동일한 정확도로 추출됩니다. 조명이 좋지 않은 상태에서 촬영한 번진 사본은 신뢰도가 낮을 수 있으므로 검토 단계를 거쳐야 합니다. 검토 모드에서는 원본 이미지에서 각 추출 값이 어디서 왔는지 보여주므로, 손글씨 수량을 확인하는 데 몇 초밖에 걸리지 않으며 전표를 다시 읽을 필요가 없습니다.

전표에 단가가 없으면 라인 합계를 얻을 수 없나요?

네, 계산 열을 사용하면 가능합니다. 특히 콘크리트 및 골재 전표와 같은 많은 자재 전표에는 수량은 있지만 가격이 없습니다. 가격은 구매 주문서에 있기 때문입니다. "라인 합계" 열을 수량 × 단가 논리로 정의하고, 전표에 인쇄된 가격이 있으면 이를 가져오거나 규칙에서 구매 주문서의 단가를 고정 매개변수로 설정하세요. 계산은 추출 중에 실행되므로, 숫자가 인쇄되지 않은 전표에도 출력 파일에 사용 가능한 금액이 포함됩니다.

Sage, Viewpoint 또는 QuickBooks 공사 원장과 어떻게 연동되나요?

일괄 출력은 공사 원장 시스템 또는 ERP 가져오기 템플릿이 기대하는 구조화된 행을 생성합니다. 전표 라인당 한 행씩, 공사 번호, 비용 코드, 수량, 가격 열이 포함됩니다. 이는 ERP의 입고 입력, 승인 라우팅 또는 3자 대사를 대체하지 않습니다. 종이 전표를 읽고 화면에 숫자를 입력하는 단계를 대체할 뿐입니다. QuickBooks 또는 스프레드시트 원장을 사용하는 계약자의 경우, 파일이 워크북에 직접 공급됩니다. Sage 100, Sage Intacct 또는 Trimble Viewpoint Vista의 경우, ERP 가져오기 전의 데이터 캡처 병목 현상을 제거합니다. 이 지점이 바로 수동 프로세스가 실제로 중단되는 곳입니다.

현장 반장들이 휴대폰으로 전표를 촬영합니다 — 그런 사진도 일괄 처리에 사용할 수 있나요?

네. 배송 전표의 휴대폰 사진은 스캔과 동일한 방식으로 추출되며, 동일한 가독성 조건이 적용됩니다. 밝은 조명에서 또렷하게 정면으로 찍은 사진은 스캔만큼 잘 작동하지만, 어두운 조명에서 비스듬히 찍은 번진 카본 사본은 검토 대상으로 표시됩니다. 사진이 문자 대화에 묻히지 않고 체계적으로 수집되길 원한다면, 수집 링크를 사용하세요. 현장 직원이 로그인 없이 처리 대기열에 파일을 바로 올릴 수 있는 공유 업로드 페이지로, "사진을 문자로 보내는" 습관을 체계적인 파이프라인으로 바꿔줍니다.

배송이 세 대의 트럭으로 나뉘어 도착하면 어떻게 하나요?

각 트럭은 자체 전표와 원장의 자체 행을 생성합니다 — 이것이 올바른 구조입니다. PO 번호로 필터링하면 세 장의 전표를 하나의 이행 보기로 묶을 수 있고, "수량 vs PO" 확인 기능으로 분할 적재가 합쳐져 주문을 충당하는지 보여줍니다. 일괄 워크플로우는 분할 배송을 자연스럽게 처리합니다. 전표가 원자 단위이지 PO가 아니기 때문입니다. 그래서 단일 주문에 대해 세 장의 수령증이 생성되는 경우가 있으며, 세 장 모두 동일한 대사 보기에 표시되길 원할 것입니다.

배송 전표 일괄 처리하기

자재 수령증 50장, 프로젝트 원장 하나:급하게 처리하지 않고 일괄 처리하는 방법

핵심 요점