독일 납품서(Lieferschein) 여러 건을 하나의 입고 로그로 일괄 처리하는 방법

Lieferschein을 하나씩 처리하면 확장이 안 되는 이유

일괄 처리가 효율적이라는 주장은 당연해 보입니다. "20개를 한 번에 처리하는 게 하나씩 20번 하는 것보다 낫다"는 식이죠. 하지만 단일 문서 처리의 진짜 비용은 입력 시간이 아닙니다. 바로 형식 간 전환 비용(context-switching cost)입니다. 접수 담당자가 다른 공급업체의 새 Lieferschein을 열 때마다 다시 적응해야 합니다. 이 레이아웃에서 Lieferscheinnummer는 어디 있지? Lieferdatum은 헤더에 있나, 푸터에 있나? 품목 수량은 세 번째 열인가, 네 번째 열인가? "Pos."는 라인 항목 번호인가, 창고 내 위치인가? 이 정신적 재매핑은 입력 자체보다 시간이 더 걸리며, 대부분의 데이터 입력 오류가 발생하는 지점입니다.

Lieferschein을 하나씩 처리하면 상호 참조 기능도 잃게 됩니다. 공급업체 A의 납품서 2026-478은 전체 납품이었나요, 부분 납품(Teillieferung)이었나요? 그 답은 15분 전에 처리해서 이미 닫은 같은 공급업체의 납품서 2026-479에 있을 수 있습니다. 일괄 처리는 모든 문서를 동시에 볼 수 있게 하여, 단일 문서 처리로는 숨겨져 있던 패턴과 불일치를 드러냅니다.

독일 창고의 현실: 다중 공급업체, 다중 형식, 다중 긴급도

독일 제조업 또는 유통업 창고 접수장의 전형적인 아침은 이렇습니다:

07:30 — SAP 생성 Lieferschein이 대형 자동차 부품 공급업체의 트럭과 함께 도착합니다. PDF는 8열 품목 테이블, 12자리 내부 코드인 자재 번호(Materialnummer), 그리고 별도의 Lieferscheinnummer와 Versandnummer(선적 번호)가 있는 조밀한 다중 페이지 문서입니다. 접수장은 08:15까지 WMS에 품목 수준 데이터가 필요하여 입고가 시작될 수 있어야 합니다.

08:00 — 두 개의 Lexware Lieferschein이 지역 수공업체(Handwerksbetriebe)로부터 도착합니다. 이들은 4열 테이블이 있는 깔끔한 단일 페이지 A4 문서입니다. SAP 문서와 동일한 정보 범주(Lieferscheinnummer, Lieferdatum, Artikel, Menge)를 포함하지만, SAP 형식과 픽셀 좌표를 전혀 공유하지 않는 레이아웃입니다.

08:30 — 종이 Lieferschein이 운전기사의 손에 도착합니다. 소규모 운송업체(Spediteur)가 복사 용지(Durchschreibesatz)를 사용하여 작성한 것입니다. Lieferscheinnummer는 오른쪽 상단 모서리에 손으로 쓰여 있습니다. 품목 테이블은 손으로 그린 격자입니다. 기사는 떠날 수 있도록 서명이 필요합니다.

세 가지 형식 세대 — 디지털 구조화(SAP), 디지털 단순(Lexware), 종이(수기) — 모두 한 시간 안에, 모두 오전 교대가 끝나기 전에 동일한 WMS에 입력되어야 합니다. 이것은 가상의 극단적인 경우가 아닙니다. 이는 독일 물류의 일상적인 운영 현실이며, 95,000개 이상의 기업이 GS1 표준을 사용하지만 대다수의 중소기업(SME) 공급업체는 DESADV와 같은 구조화된 EDI 메시징을 채택하지 않았습니다. 구조화된 미래와 PDF/종이 현재 사이의 격차가 바로 일괄 추출이 존재하는 곳입니다.

접수장은 데이터 입력 스테이션이 아닙니다. 검증 체크포인트입니다. 수동 전사가 검사에 할애해야 할 시간을 소비할 때, 접수의 전체 품질 관리 기능은 "상자 열고, 대충 세고, 종이에 서명"으로 붕괴됩니다.

일괄 추출이 다양한 형식을 대규모로 처리하는 방법

다양한 형식에서 일괄 Lieferschein 처리를 가능하게 하는 핵심 기능은 의미 기반 필드 매칭입니다. "Lieferscheinnummer", "Lieferdatum", "Bestellnummer", "Artikel", "Menge", "Einheit" 등 열 이름을 한 번 정의하면 AI가 동일한 열 정의를 배치 내 모든 문서에 형식과 관계없이 적용합니다. 이는 동일한 문서 레이아웃(비현실적)이나 공급업체별 템플릿 구성(확장 불가)이 필요한 템플릿 기반 일괄 처리와의 중요한 차이점입니다.

개별 독일어 Lieferscheine에서 의미 기반 추출이 작동하는 방식(필드 정의, 불일치 확인을 위한 계산 열, 수기 주석 같은 예외 처리 포함)에 대한 자세한 설명은 독일 납품서 데이터를 Excel로 추출하는 가이드를 참조하세요. 이 글은 한 문서에서 전체 교대분으로 확장할 때 달라지는 점에 초점을 맞춥니다.

일괄 처리는 단일 문서 추출 외에 세 가지 추가 요구 사항을 도입합니다:

행 수준 문서 추적성. 일괄 출력에서 스프레드시트의 모든 행은 어떤 Lieferschein에서 왔는지 식별할 수 있어야 합니다. Lieferscheinnummer 열이 기본 키 역할을 합니다. 이것이 없으면 불일치를 유발한 문서를 추적할 수 없는 품목 더미만 남게 됩니다.

일관된 null 처리. Lexware Lieferschein에 Chargennummer(로트/배치 번호) 열이 있고 종이 Lieferschein에 없는 경우, 출력 열 "Chargennummer"는 종이 행에 대해 빈 셀을 표시해야 합니다(0, 오류, 추정 값이 아님). 빈 셀은 정보를 전달합니다(이 공급업체는 배치 번호를 추적하지 않음). 0으로 채워지면 잘못된 정보가 됩니다.

출력 행 순서. 출력은 논리적 순서를 유지해야 합니다: Lieferschein별로 행을 그룹화하고, 각 Lieferschein 내에서는 Positionsnummer 순서로 정렬합니다. 20개의 문서를 처리하는 경우 출력의 처음 3개 행은 첫 번째 Lieferschein의 3개 품목에 해당해야 하며, 여러 문서의 품목이 뒤섞여서는 안 됩니다.

일괄 추출은 단일 문서 추출을 20배 빠르게 수행하는 것이 아닙니다. 문서 간 일관성, 추적성, 출력 구성이 필드별 정확성만큼 중요한 별개의 작업입니다.

입고장에서 WMS까지: 일괄 처리 워크플로 단계별 가이드

이 워크플로는 입고장에서 다양한 형식의 Lieferscheine 더미를 WMS 가져오기에 적합한 구조화된 스프레드시트로 변환하며, 오류가 하류로 전파되는 것을 방지하는 모든 운영 체크포인트를 포함합니다.

명명 규칙 및 출력 구성

일괄 처리는 더 많은 데이터를 생성하므로 데이터 구성이 더욱 중요해집니다. 다음은 200행짜리 스프레드시트를 관리 가능하게 유지하는 규칙입니다.

Lieferscheinnummer이 기본 키입니다. 모든 라인 항목 행은 해당 원본 문서의 납품서 번호를 포함해야 합니다. AI가 Lieferscheinnummer를 읽을 수 없는 경우(얼룩진 종이, 번호가 잘린 PDF) 해당 행은 자동으로 null 키가 할당되지 않고 수동 검토를 위해 플래그가 지정되어야 합니다. 계산 열 "Lieferscheinnummer vorhanden (옵션: Ja, Nein)"이 이러한 행을 자동으로 플래그 지정합니다.

필드별이 아닌 문서별로 출력을 그룹화합니다. 출력은 Lieferschein A의 모든 라인 항목을 나열한 다음 Lieferschein B의 모든 라인 항목을 나열하는 식이어야 합니다. 이 그룹화를 통해 예상치 못한 출력을 생성한 문서를 빠르게 스캔할 수 있습니다(예: 40줄 Lieferschein이 3행만 생성한 경우 — 다중 페이지 항목 테이블에 문제가 있는 것입니다). 출력이 섞여 있으면(A의 행, B의 행, 다시 A의 행) 처리 아티팩트의 증상이며 배치 검토가 거의 불가능합니다.

배치 추적성을 위한 메타데이터 열을 추가합니다. "Verarbeitungsdatum"(처리 날짜 — 배치가 추출된 시점), "Dateiname"(원본 파일 이름 — 출력 행을 소스 파일에 매핑), "Quellformat"(소스 형식 — SAP, Lexware, Papier 등)을 추가하는 것을 고려하십시오. 이러한 열은 원본 Lieferscheine에는 나타나지 않습니다. 이는 출력을 자체 문서화하는 배치 수준 메타데이터로, 지난달 배치를 다시 확인하고 어떤 파일이 어떤 행을 생성했는지 알아야 할 때 유용합니다.

FAQ: 독일 납품서 일괄 처리

한 배치에 종이 스캔본과 디지털 PDF를 섞어서 업로드할 수 있나요?

네. 사진으로 찍은 종이 납품서, 스캔한 종이 사본, 모든 ERP 시스템에서 생성된 디지털 PDF를 동일한 배치에 업로드할 수 있습니다. 유일한 요구 사항은 스캔하거나 사진으로 찍은 문서가 밝고 초점이 맞아야 한다는 점입니다. 이는 읽으려는 모든 문서에 적용하는 것과 동일한 품질 기준입니다. 종이 납품서가 접혀 있거나 구겨져 있거나 일부가 가려진 경우, 영향을 받은 영역의 추출 정확도는 떨어지지만 나머지 문서는 정상적으로 처리됩니다.

일괄 추출은 여러 페이지로 구성된 납품서와 단일 페이지 납품서를 어떻게 처리하나요?

AI는 페이지 수와 관계없이 각 파일을 완전한 논리적 문서로 처리합니다. 30개 라인 항목이 있는 3페이지 SAP 납품서와 5개 라인 항목이 있는 1페이지 Lexware 납품서가 동일한 배치에 포함됩니다. 출력은 SAP 문서의 경우 30행, Lexware 문서의 경우 5행을 올바르게 생성하며, 추적 가능성을 유지하기 위해 모든 행에 납품서 번호가 반복됩니다. 여러 페이지로 구성된 문서의 1페이지에만 나타나는 헤더 필드는 모든 페이지의 모든 라인 항목과 올바르게 연결됩니다.

SAP EWM 또는 Lexware 가져오기와 호환되는 내보내기 형식은 무엇인가요?

추출은 XLSX(Excel), CSV 및 JSON을 생성합니다. SAP EWM은 표준 트랜잭션 코드(MIGO - 입고, VL31N - 입고 납품)를 통해 입고 처리를 위한 CSV 및 XLSX 가져오기를 지원합니다. Lexware Warenwirtschaft는 CSV 가져오기를 지원합니다. 대부분의 WMS 플랫폼은 최소한 수령 기록을 위한 CSV 가져오기를 허용합니다. 시스템에 특정 열 순서나 헤더 형식이 필요한 경우, 가져오기 전에 Excel에서 열을 다시 정렬할 수 있습니다. 추출 출력은 독점 형식이 아닌 표준 스프레드시트입니다.

배치 크기에 실질적인 제한이 있나요?

엄격한 기술적 제한은 없지만, 운영 모범 사례는 교대 또는 일별로 배치하는 것을 권장합니다. 일반적으로 배치당 20~50개 문서입니다. 더 큰 배치(100개 이상)도 기술적으로 가능하지만, 수백 개의 행에서 이상 징후를 검사해야 하는 검토 단계(워크플로의 4단계)가 번거로워집니다. 여러 교대에 걸쳐 하루에 200개의 납품서를 처리하는 경우, 검토가 관리 가능하고 불일치를 특정 시간대에 추적할 수 있도록 교대 수준 배치로 분할하십시오.

일괄 추출이 GoBD 추적 요구사항을 충족하나요?

GoBD는 추출된 데이터가 원본 문서까지 추적 가능해야 한다고 요구합니다. Lieferscheinnummer 열이 이 목적을 수행합니다 — 출력의 모든 행은 해당 원본 문서의 고유 식별자를 포함합니다. (GoBD에 따라 별도로 보관해야 하는) 원본 PDF 아카이브와 결합하면 완전한 감사 추적이 생성됩니다: 출력 행 → Lieferscheinnummer → 원본 PDF. 추가 감사 대비를 위해 "Dateiname" 메타데이터 열은 출력 행을 원본 파일 이름에 매핑합니다. 추출된 Excel은 원본 PDF 아카이브를 대체하지 않으며 보완한다는 점에 유의하세요.

Lieferscheine를 개별 처리해야 하는 경우와 일괄 처리해야 하는 경우는 언제인가요?

일괄 처리는 다음과 같은 경우에 적합합니다: 한 교대조의 Lieferscheine 모음이 있는 경우; 출력에서 문서 간 일관성이 필요한 경우; 동일 주문에 대해 여러 문서에 걸친 부분 납품을 조정해야 하는 경우; 문서별 즉시 출력이 필요하지 않은 경우. 개별 처리는 다음과 같은 경우에 적합합니다: 트럭이 기다리는 동안 즉시 WMS 입력이 필요한 긴급한 단일 Lieferschein이 있는 경우; 나머지 문서를 처리하기 전에 하나의 복잡하거나 문제가 있는 문서를 상세히 검토해야 하는 경우; 또는 공급업체가 당일 일괄 처리가 이미 완료된 후에 Lieferschein을 보내는 경우. 일괄 처리와 단일 문서 추출은 상호 배타적이지 않으며 상호 보완적입니다.