여러 독일 납품서(Lieferschein)를 하나의 입고 대장으로 일괄 처리하는 방법

한 번에 하나씩 처리하는 Lieferschein 방식이 확장되지 않는 이유

배치 처리의 효율성 논리는 명백해 보입니다 — "20개를 하나씩 20번 하는 대신 한 번에 처리하라." 하지만 단일 문서 처리의 진짜 비용은 입력에 걸리는 시간이 아닙니다. 바로 형식 간의 전환 비용입니다. 입고 담당자가 다른 공급업체의 새 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 Lieferscheine이 지역 Handwerksbetriebe에서 도착합니다. 이들은 4열 테이블이 있는 깔끔한 단일 페이지 A4 문서입니다. SAP 문서와 동일한 정보 범주 — Lieferscheinnummer, Lieferdatum, Artikel, Menge — 를 담고 있지만, SAP 형식과 픽셀 좌표를 전혀 공유하지 않는 레이아웃입니다.

08:30 — 종이 Lieferschein이 기사 손에 들려 도착합니다. 소규모 Spediteur가 Durchschreibesatz(탄소 복사 용지)로 작성한 것입니다. Lieferscheinnummer는 오른쪽 상단에 손으로 적혀 있습니다. 품목 테이블은 손으로 그린 격자입니다. 기사는 서명을 받아야 떠날 수 있습니다.

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

입고 도크는 데이터 입력 스테이션이 아닙니다. 검증 체크포인트입니다. 수동 입력이 검사에 할애되어야 할 시간을 잡아먹으면, 입고의 전체 품질 관리 기능이 "상자 열고, 대충 세고, 종이에 서명"으로 무너집니다.

배치 추출이 대규모에서 형식 변동성을 처리하는 방법

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

개별 독일어 Lieferschein에서 의미 기반 추출이 어떻게 작동하는지 — 필드 정의, 불일치 확인을 위한 계산 열, 수기 주석 같은 예외 처리 포함 — 더 자세히 알아보려면 독일어 납품서 데이터를 Excel로 추출하는 가이드를 참조하세요. 이 글은 문서 하나에서 한 교대조 분량으로 확장할 때 무엇이 달라지는지에 초점을 맞춥니다.

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

행 수준 문서 추적성. 배치 출력에서 스프레드시트의 모든 행은 어느 Lieferschein에서 왔는지 식별해야 합니다. Lieferscheinnummer 열이 기본 키 역할을 합니다. 이것이 없으면 불일치를 초래한 문서로 추적할 방법이 없는 항목 더미만 남습니다.

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

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

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

입고장에서 WMS까지: 배치 워크플로 단계별 안내

이 워크플로는 입고장에 쌓인 다양한 형식의 Lieferschein 더미에서 WMS 가져오기에 바로 쓸 수 있는 구조화된 스프레드시트까지 안내하며, 오류가 하위 단계로 전파되는 것을 막는 모든 운영 점검 지점을 포함합니다.

명명 규칙 및 출력 구성

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

Lieferscheinnummer는 기본 키입니다. 모든 라인 항목 행은 원본 문서의 납품서 번호를 포함해야 합니다. AI가 Lieferscheinnummer를 읽을 수 없는 경우 — 종이 전표가 번진 경우, PDF에서 번호가 잘린 경우 — 해당 행은 조용히 null 키로 할당되는 대신 수동 검토용으로 플래그되어야 합니다. 계산 열 "Lieferscheinnummer vorhanden (options: Ja, Nein)"이 이러한 행을 자동으로 플래그합니다.

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

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

FAQ: 배치 독일어 납품서 처리

한 배치에 종이 스캔본과 디지털 PDF를 섞을 수 있나요?

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

배치 추출은 단일 페이지 문서와 함께 다중 페이지 Lieferschein을 어떻게 처리하나요?

AI는 페이지 수에 관계없이 각 파일을 완전한 논리적 문서로 취급합니다. 30개 품목이 있는 3페이지 SAP Lieferschein과 5개 품목이 있는 1페이지 Lexware Lieferschein이 같은 배치에 있습니다. 출력은 SAP 문서에 대해 30개 행, Lexware 문서에 대해 5개 행을 올바르게 생성하며, 추적성을 유지하기 위해 모든 행에 Lieferscheinnummer가 반복됩니다. 다중 페이지 문서의 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개의 Lieferschein을 처리하는 경우, 검토가 관리 가능하고 불일치를 특정 시간대까지 추적할 수 있도록 교대조 수준의 배치로 나누세요.

배치 추출이 GoBD 추적성 요건을 충족하나요?

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

Lieferscheine을 배치 대신 개별적으로 처리해야 하는 경우는 언제인가요?

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

여러 유럽 언어로 납품서를 받는 경우, 동일한 배치 워크플로가 인접 문서 유형에도 적용됩니다: 프랑스어 bons de livraison 및 스페인어 albaranes. AI가 언어나 레이아웃이 아닌 필드 의미로 읽기 때문에 하나의 열 정의로 모두 처리됩니다.