식품 리콜 규모는
공급업체 청구서의 배치 번호에 달려 있습니다
2026년 6월, FDA는 6개 공급망에 걸친 15개 기업과 함께 실시한 추적성 훈련 결과를 발표했습니다. 이 훈련은 각 기업이 24시간 이내에 기록을 제출할 수 있는지 시험했으며, 응답 시간은 대체로 빨랐습니다. 대부분이 하지 못한 것은 해당 기록 전반에 로트 코드를 일관되게 유지하는 일이었습니다. 기록 중 40%만이 모든 단계에서 적절히 할당된 추적성 로트 코드를 담고 있었습니다.
해당 코드의 출처를 완전히 담은 기록은 27%에 불과했습니다. 격차는 서로를 연결하는 기록에 있었고, 대부분의 식품 기업에서 그 기록은 공급업체 청구서에서 시작됩니다.

핵심 요약
- FDA 추적성 훈련에서 기록 중 40%만이 모든 단계에서 로트 코드를 담고 있었고, 27%만이 해당 코드의 출처를 담고 있었습니다.
- 격차는 다른 기록을 연결하는 기록에 있으며, 연결된 행의 소유자를 직책으로 명시한 곳은 없습니다.
- 청구서는 결제를 증명할 뿐 팔레트에 무엇이 도착했는지는 증명하지 않으므로, 배치 코드를 인쇄된 그대로 캡처하여 입고 및 생산 기록과 연결해야 합니다.
리콜 범위는 대부분의 청구서가 선택 사항으로 취급하는 필드로 결정됩니다

배치 번호는 어떤 팔레트가 반품되는지를 결정하지만, 공급업체 청구서에서는 결제를 위해 설계된 제품 라인 옆에 작은 글씨로 한 번만 인쇄되는 경우가 많습니다. 청구서는 공급업체, 수량, 가격을 담아야 하며 그 역할은 잘 수행합니다. 배치 코드는 공급업체의 청구 시스템에 포함될 때 따라오고, 포함되지 않으면 사라집니다.
유럽연합 집행위원회의 Regulation (EC) No 178/2002 지침은 이 구분을 명확히 합니다. 청구서를 보관하는 것은 제품의 상업적 흐름을 추적하는 것이며, 이는 "제품의 물리적 흐름을 따르기에 충분하지 않았습니다." 규정 자체는 한 단계 뒤와 한 단계 앞을 요구하므로, 직전 공급업체와 직후 고객을 식별할 수 있습니다. 모든 청구서에 배치 번호를 요구하지는 않지만, 같은 지침은 배치 세부 정보를 "매우 유용하다"고 평가합니다. 청구서는 법적으로 유용하고 상업적으로 필수적이지만, 배치 기록으로서는 불완전합니다.
FDA Food Traceability Rule에 따르면, 추적성 로트 코드는 각 중요 추적 이벤트에서 요구되는 핵심 데이터 요소 중 하나입니다. 모든 요소는 로트에 연결되어야 하며, FDA는 청구서를 명시적으로 허용하여 해당 요소를 담는 참조 문서로 사용할 수 있게 합니다. 따라서 공급업체 청구서는 규정 준수 기록의 일부가 될 수 있습니다. 이는 코드가 올바른 수준에서 캡처되고, 인쇄된 그대로 유지되며, 이후 식품에 발생한 일을 설명하는 입고 및 생산 기록과 연결될 때만 가능합니다. 규정 준수 기한은 2028년 7월 20일이므로, 해당 사업자는 이 연결을 구축할 시간이 있습니다.
청구서는 상업적 이전을 증명합니다. 배치 기록은 실제로 무엇이 도착했는지를 증명하며, 이 두 가지 주장은 동일하지 않습니다.
배치 기록이 리콜 질문에 답하려면 갖춰야 할 것
리콜 상황에서 쓸 수 있는 배치 기록은 하나의 로트에 관한 네 가지 사실을 연결해야 합니다. 누가 공급했는지, 언제 얼마나 입고되었는지, 어떤 생산 런에 사용되었는지, 그리고 완제품을 받은 고객이 누구인지입니다. 리콜 통지는 보통 공급업체 이름과 코드와 함께 도착하며, 나머지 세 가지에 대한 시계가 그때부터 시작됩니다.
FDA의 입고 요건은 그 전반부의 형태를 보여줍니다. 적용 대상 식품의 각 추적성 로트에 대해 수령자는 로트 코드, 수량과 측정 단위, 제품 설명, 직전 공급원의 위치, 식품을 입고한 위치, 입고 날짜, 로트 코드의 출처, 그리고 참조 문서 유형과 번호를 보관해야 합니다. 이 아홉 개 필드가 표의 한 행을 정의합니다. 이 규칙은 또한 FDA가 요청할 때 전자적이고 정렬 가능한 형식으로 기록을 제출할 수 있는 24시간의 기한을 정합니다. PDF 아카이브는 이 기준을 충족하지 못하며, 로트당 한 행으로 구성된 스프레드시트는 충족합니다.
HACCP 시스템의 근간이 되는 위생 원칙을 제시한 Codex Alimentarius도 같은 입장입니다. 로트 식별은 제품 리콜과 재고 순환에 필수적이며, 각 용기는 생산자와 로트를 식별해야 합니다. 식품 사업체 내부에서 그 기록의 조각들은 서로 다른 사람에게 흩어져 있고, 어느 누구의 직함도 "연결된 행의 소유자"가 아닙니다.
| 역할 | 보유하는 것 | 그 기록이 답하는 것 | 단독으로는 답할 수 없는 것 |
|---|---|---|---|
| 입고 담당자 | 납품서, 팔레트 라벨, 게이트 로그 | 어떤 배치가 실제로 언제 도착했는지 | 어떤 청구서가 얼마의 가격으로 청구했는지 |
| 재무 / AP | 청구서 PDF 또는 전자 청구서 | 공급업체, 청구 수량, 가격, 결제 조건 | 팔레트에 어떤 배치가 있었는지 |
| QA 책임자 | 배치 대장, 생산 및 위생 로그 | 어떤 생산 런이 그 배치를 사용했는지 | 누가 공급했는지, 또는 어떤 고객이 받았는지 |
| 구매 | 발주서, 공급업체 연락처 | 코드가 없거나 잘못되었을 때 누구에게 물어야 하는지 | 도크에 실제로 무엇이 도착했는지 |

재무는 청구서를 받습니다. 지불해야 하기 때문입니다. 입고는 납품서를 보관합니다. 운전기사가 서명하기 때문입니다. QA는 배치 대장을 보관합니다. 감사자가 요청할 것이기 때문입니다. 각 기록은 그 자체의 목적에는 완전하지만, 이들 사이의 연결은 공급업체가 리콜 통지를 발행할 때마다 수작업으로 다시 만들어집니다. 바로 그 재구성 작업에 FDA의 실험이 수치를 매겼습니다.
실제 공급업체 청구서에서 배치 식별이 깨지는 지점

문제는 대개 청구서에 적힌 내용과 창고에서 실제로 처리한 내용 사이의 네 가지 작은 불일치에서 비롯되며, 청구서 금액은 여전히 맞아떨어지기 때문에 각 불일치가 수동 검사를 통과합니다.
하나의 청구서 항목, 세 개의 실제 배치
공급업체가 모차렐라 20케이스를 하나의 항목으로 단일 단가로 청구합니다. 도착한 팔레트에는 세 개의 생산 배치가 실려 있는데, 공급업체가 주문을 채우기 위해 세 번의 생산분에서 포장했기 때문입니다. 이 청구서는 결제용으로는 정확하지만 추적성 기록으로는 잘못된 것으로, 세 개의 로트를 하나로 합쳐버렸습니다. 배치 대장을 청구서 항목만으로 작성하면, 중간 배치에 대한 리콜 시 같은 항목을 공유하는 두 팔레트를 놓치거나, 20케이스 전체와 함께 고객 관계까지 끌어들일 수 있습니다.
분리는 입고 시점에 팔레트 라벨이나 납품서를 통해 이루어져야 하며, 배치 대장에는 배치별로 한 행씩, 각 행에 청구서 번호가 반복되어야 합니다. 이것이 또한 제품과 수량에서 멈추는 항목 테이블이 식품에는 충분하지 않은 이유이기도 합니다. 식품 유통업체 청구서 항목 추출과 동일한 메커니즘이 적용되며, 배치가 항목 아래의 추가 계층이 됩니다.
배치 코드가 청구서에 도달하지 않는 경우
많은 공급업체가 로트를 납품서, 케이스 라벨, 사전 선적 통지 또는 후속 이메일에 인쇄하고 청구서에는 기재하지 않습니다. IFSQN 식품 안전 포럼의 한 실무자는 로트나 배치 번호 없이 도착하는 원자재를 어떻게 추적하는지 질문했으며, 답변에는 입고 날짜와 소비기한(품질)으로 추적하거나 발주서 번호를 대용으로 사용하는 방법이 포함되었습니다. 이러한 임시 방편은 정직한 방법이며, 청구서가 제공할 수 있는 것의 한계도 보여줍니다. 코드가 인쇄되어 있지 않으면 추출로 생성할 수 없으며, 스프레드시트가 만들어낸 번호는 공백보다 더 나쁩니다.
실용적인 해답은 청구서와 납품서를 같은 테이블에 도착하는 두 개의 입고 대기열로 취급하는 것입니다. AP는 청구서를 전달하고, 입고 담당자는 부두에서 납품서를 촬영합니다. 둘 다 동일한 열에 대해 처리되며, 발주서 또는 납품서 번호가 조인 키가 되고 청구서 번호는 상업적 참조로 유지됩니다. 청구서에 배치가 없고 납품서에 있는 경우, 납품서 행이 그 공백을 채웁니다. 둘 다 없는 경우, 배치 대장에 그 사실을 기록하고 구매팀이 공급업체에 서면으로 요청하는데, 이는 FDA가 수령업체에 코드를 만들어내는 대신 하기를 기대하는 바이기도 합니다.
날짜 코드는 세 가지 다른 의미를 지니며 다섯 가지 형식으로 들어옵니다
생산일, 소비기한(품질), 유통기한(안전)은 서로 바꿔 쓸 수 없으며, 율리안 코드(Julian code)는 누군가 해독하기 전까지는 날짜가 아닙니다. 그런데도 대부분의 스프레드시트에서는 이 세 가지가 모두 "Expiry"라는 제목의 한 열에 들어갑니다. 한 공급업체는 BBE 03/2027로, 다른 업체는 27.03.2027로, 또 다른 업체는 26087 같은 율리안 코드(Julian code)로, 또 다른 업체는 연월만 인쇄합니다. Excel은 이 중 일부를 날짜로 기꺼이 읽고 다른 일부는 조용히 잘못 읽으며, 텍스트와 날짜가 섞인 열은 정렬되지 않습니다. 이는 선입선출(FEFO) 점검에 꼭 필요한 기능입니다.
두 가지 규칙만 지키면 대부분의 피해를 막을 수 있습니다. 원본 문자열은 한 열에 그대로 두고, 정규화된 날짜는 문서가 전체 날짜를 뒷받침할 때만 다른 열에 넣습니다. 월만 있는 소비기한(품질)은 그 달 1일로 바꾸지 말고 월만 있는 상태로 두어야 합니다. 그런 다음 날짜 유형을 위한 열을 추가하여 소비기한(품질)이 유통기한(안전)으로 취급되는 일이 없도록 합니다. 이 차이는 법적으로뿐 아니라 상업적으로도 중요합니다. 소비기한(품질)이 지난 것은 품질 문제이고, 유통기한(안전)이 지난 것은 안전 문제입니다.
코드는 한 글자씩 손으로 옮겨 적습니다
배치 코드는 고유하도록 설계된 영숫자 문자열이지, 입력하도록 만들어진 것이 아닙니다. L26-0412/A는 슬래시가 빠지면 L26-0412A가 되고, 0은 O가 되며, 1은 I가 되고, 끝에 붙은 접미사는 사라집니다. 배치 대장은 완벽해 보입니다. 리콜 검색은 아무것도 반환하지 않습니다. 배치 코드 조회는 정확한 문자열 일치이기 때문입니다. 이는 네 가지 실패 중 가장 조용한 실패이며, 일상 업무보다 감사 중에 드러날 가능성이 가장 큽니다. r/QAProfessionals에서 내부 감사를 설명한 한 QA 전문가는 수동 로그와 ERP 입력이 서로 맞지 않아 일부 로트를 원자재 출처까지 추적할 수 없었다고 밝혔습니다.
리콜 조회는 정확한 문자열 일치이므로, 한 글자가 틀린 배치 대장은 그 질문에 답할 수 없는 배치 대장입니다.
대응책은 시각적 검증입니다. 추출된 모든 배치 코드는 그것이 나온 픽셀과 대조해 확인할 수 있어야 하며, 이를 위한 것이 이 글 뒤에 나오는 검토 단계입니다.
인보이스 라인을 추적성 행으로 바꾸는 열
열을 한 번 정의하면 동일한 세트가 모든 공급업체에 적용됩니다. 출력이 공급업체의 레이아웃이 아니라 지정한 필드에 의해 결정되기 때문입니다. 다음은 인보이스 전반에 걸친 배치 번호 추출과 소비기한 추적을 하나의 배치 대장에 담아내는 필드이며, 각 필드의 규칙도 함께 제시합니다.
| 열 | 들어가는 내용 | 기록을 사용 가능하게 유지하는 규칙 |
|---|---|---|
| 공급업체 | 인쇄된 법적 명칭 | 인쇄된 명칭을 유지하고, 공급업체 ID 매핑은 추출 단계가 아니라 이후에 수행 |
| 인보이스 번호 | 접두사와 접미사를 포함해 인쇄된 그대로 | 모든 행에 반복 기재하여 각 배치 행을 청구서로 역추적 가능하게 함 |
| 인보이스 날짜 | 인보이스에 기재된 날짜 | 납품일이나 입고일과 혼동하지 않음 |
| 제품 설명 | 공급업체의 표기 | 인쇄된 그대로 유지하며, 내부 품목 코드는 별도 열로 관리 |
| 공급업체 품목 코드 | 공급업체의 SKU 또는 품번 | 설명이 알아볼 수 없을 정도로 축약된 경우 유용 |
| 배치 / 로트 코드 | 슬래시와 구분자를 포함해 인쇄된 그대로 | 식별자를 절대 "정리"하거나 재포맷하지 않음. 이 코드가 리콜 키이기 때문 |
| 생산일 또는 포장일 | 공급업체가 인쇄한 위치 | 소비기한만 인쇄된 경우 공란으로 둠 |
| 소비기한 | 인쇄된 날짜 또는 월 | 문서가 지원하는 정밀도까지만 정규화 |
| 유통기한 | 인쇄된 날짜 | 소비기한과 분리 유지. 서로 다른 위험을 내포하기 때문 |
| 수량 및 단위 | 납품 수량과 측정 단위 | 배치당 한 행으로 기록하여 코드별 수량을 명확히 함 |
| 입고일 | 납품서 또는 게이트 로그에서 확인 | FDA 입고 기록이 요구하는 날짜이며, 인보이스 날짜가 아님 |
| 날짜 유형 | 소비기한, 유통기한, 생산일 또는 미상 | 추론 열로, AI가 페이지의 라벨 문구에서 분류 |
열 12개면 리콜 질의의 인보이스 절반을 답하고 다음 시스템에 깨끗한 조인 키를 넘기기에 충분합니다. 의도적으로 전체 추적성 스키마는 아닙니다. 고객 열과 생산 런 열은 없는데, 그 정보는 공급업체 인보이스가 아니라 출하 및 제조 기록에 존재하기 때문입니다. 이를 위해 빈 열을 추가하면 아무것도 바뀌지 않으면서 테이블만 완성된 것처럼 보입니다.
배치 코드는 절대 정리해서는 안 되는 유일한 필드입니다. 날짜는 정규화하고, 식별자는 보존하십시오.
하나의 열 세트로 40개 공급업체를 처리합니다
공급업체가 40곳이라는 것은 40가지 청구서 레이아웃, 40가지 날짜 표기 관행, 그리고 일반적인 한 달에 하나의 일관된 배치 대장에 유지해야 할 1,000줄 이상의 항목을 의미합니다. 이러한 규모에서 수동 입력은 한 번에 실패하지 않습니다. 대신 서서히 무너지는데, 그 시작은 결제가 그것에 의존하지 않기 때문에 아무도 확인하지 않는 필드입니다.
여기에 적합한 추출 모델은 ImageToTable.ai가 맞춤 열 추출이라고 부르는 것입니다. 원하는 열 이름을 입력하면 AI가 고정된 위치를 대조하는 방식이 아니라 그 의미를 이해하여 페이지 어디에서든 각 값을 찾아냅니다. 입력한 이름이 출력 테이블의 헤더가 됩니다. 공급업체별 템플릿이 생성되지 않으므로, 공급업체가 청구서 레이아웃을 변경해도 다음 달 작업이 중단되지 않습니다.
데이터를 나누기 전에 입고 경로부터 나누십시오
청구서는 AP에서 추출 대기열로 보내고, 납품서는 하역장에서 보냅니다. 수집 링크를 사용하면 입고 담당자가 계정 없이 링크를 열고 짧은 인증 코드를 입력한 뒤 납품서 사진을 휴대폰으로 촬영해 처리 대기열에 업로드할 수 있습니다. 청구서가 이메일로 도착하는 경우, 계정의 Email Inbox 주소가 공급업체 허용 목록의 청구서를 받아 자동으로 처리를 시작할 수 있습니다.
배치 대장의 언어로 열을 정의하십시오
위 표의 필드 이름을 사용하십시오. "Batch / Lot Code"와 "Best Before"는 "Product Code 2"나 "Date 3"보다 모델에 더 명확하며, 1년 후 출력 헤더에서 보게 될 이름이기도 합니다. "Date Type"을 추론 열로 추가하면 AI가 라벨 문구를 바탕으로 각 날짜를 분류합니다.
한 달치를 한 번의 배치로 처리하십시오
모든 공급업체의 청구서를 함께 업로드하십시오. 배치 처리는 결과를 하나의 스프레드시트로 병합하므로, 한 번 실행하면 40개의 파일을 이어 붙이는 대신 하나의 배치 대장이 만들어집니다. 각 30줄인 청구서 40건의 배치는 하나의 표에서 약 1,200행이 되며, 공급업체 열을 통해 각 행이 어떤 레이아웃에서 왔는지 알 수 있습니다.
정밀도를 지어내지 말고 날짜를 정규화하십시오
규칙 형식을 사용하면 날짜를 하나의 일관된 스타일로 출력할 수 있으며, 이것이 열을 정렬 가능하게 만듭니다. 문서가 월 단위 정밀도까지만 뒷받침하는 값이 있는지 결과를 확인하십시오. 03/2027로 인쇄된 소비기한(품질)은 월 단위로 유지되어야 하고, 율리안 코드(Julian code)는 누군가 공급업체와 그 의미를 확인할 때까지 인쇄된 그대로 유지되어야 합니다.
합계가 아니라 코드를 검토하십시오
bbox 강조 표시가 있는 Review Mode는 추출된 각 셀을 원본 이미지의 위치와 연결합니다. 배치 번호를 클릭하면 해당 영역이 원본에서 강조 표시되므로, 청구서 전체를 다시 입력하지 않고도 O와 0을 구분할 수 있습니다. 배치 및 날짜 열을 검토하고 수량을 표본 점검한 뒤, 산술 계산은 AP에 맡기십시오.
PO 또는 납품서로 배치 대장을 생산 기록과 연결하십시오
표를 Excel 또는 CSV로 내보내고 PO 또는 납품서 번호를 사용해 각 배치 행을 입고 기록과 연결하되, AP 측을 위해 청구서 번호는 유지하십시오. 청구서 추출은 공급업체 측을 제공합니다. 생산 시스템은 "사용처" 측을 제공합니다. 이 연결이 추적성 기록입니다.
파일은 안전하게 처리되며 저장되지 않습니다.
당면한 문제가 추적성이 아니라 물량이라면, 동일한 설정이 배치 청구서를 Excel로 변환하는 워크플로로도 활용할 수 있으며, 이를 주간 식자재 원가 버전으로 다룬 내용은 식품 유통업체의 라인 항목을 주간 시트로 배치 처리하기에서 확인할 수 있습니다. 추적성 테이블은 동일한 데이터에서 배치 수준을 집계로 없애지 않고 유지한 것입니다.
청구서 추출이 식품 안전을 위해 할 수 없는 일
추출은 더 나은 배치 대장을 만들어 줍니다. 그러나 규정 준수를 만들어 주지는 않으며, 그렇다고 가정하고 작성한 리콜 파일은 느린 수작업 파일보다 더 위험합니다. 완성된 것처럼 보이기 때문입니다.
- 추적성 또는 규정 준수 시스템이 아닙니다. 추적성 계획도, 리콜 워크플로도, 감사자 포털도, 규제 기관 제출도 없습니다. FDA의 24시간 요청은 여전히 귀사의 비즈니스가 이 테이블을 증거로 삼아 답변해야 합니다.
- 바코드를 해독하지 않습니다. AI는 페이지에 인쇄되거나 손으로 쓰인 텍스트를 읽습니다. 배치 코드가 GS1-128 바코드나 DataMatrix 라벨 안에만 존재한다면 이 워크플로는 이를 보지 못하므로, 해당 로트에는 스캐너나 라벨 시스템이 필요합니다.
- 소비기한을 계산하거나 FEFO를 실행하지 않습니다. 30일 내에 만료되는 품목이나 어떤 팔레트를 먼저 출하해야 하는지 결정하는 내장 날짜 연산은 없습니다. 정규화된 날짜는 다운스트림에서 그러한 결정을 가능하게 할 뿐, 결정 자체를 내리지는 않습니다.
- 전방 추적을 하지 않습니다. 완제품을 누가 받았는지는 출하 사실이지 청구서 사실이 아닙니다. 청구서는 공급망의 한 단계 뒤쪽 절반만 제공하며, 앞쪽 절반은 동일한 배치 코드에 연결된 생산 및 출하 기록이 필요합니다.
- 공백을 채우지 않습니다. 공급업체가 코드를 누락하면 해당 행은 비어 있는 채로 남고 예외는 계속 보입니다. 이것이 올바른 동작입니다. 생성된 코드는 바로 그 코드가 필요한 시점에 공급업체 기록과의 연결을 끊어버립니다.
- 공급업체 마스터와 대조하여 코드를 검증하지 않습니다. 체크 디지트도, GS1 검증도, 제품 카탈로그 조회도 없습니다. 올바르게 인쇄되었지만 다른 제품에 속한 코드는 올바르게 추출된 후에도 여전히 잘못된 상태로 남습니다.
핵심은 역할 분담입니다. 소프트웨어는 낯선 레이아웃을 읽고 문자열을 보존하는 데 안정적입니다. 코드의 의미, 로트의 안전성, 누구에게 연락해야 하는지를 결정하는 것은 사람과 전문 시스템의 몫입니다. 그러한 결정을 더 쉽게 만들어 주는 배치 대장은 유용합니다. 그러한 결정을 대신 내리는 척하는 배치 대장은 위험 부담입니다.
다음 공급업체 리콜 통지를 받기 전에 해볼 5분 테스트
5분 테스트를 통해 공급업체가 리콜 관련 질문을 하기 전에 자사 기록만으로 답할 수 있는지 확인할 수 있습니다. 지난달 입고 건에서 배치 코드 하나를 무작위로 골라 타이머를 시작하고, 현재 기록만 사용해 네 가지 질문에 답해 보십시오:
- 이 배치는 어느 공급업체 청구서를 통해 들어왔으며, 입고 날짜는 언제입니까?
- 해당 배치는 얼마나 입고되었고, 현재 재고는 얼마나 남아 있습니까?
- 어떤 생산 작업에 사용되었으며, 어떤 완제품 로트가 생산되었습니까?
- 그 완제품 로트를 받은 고객은 어디입니까?
1번과 2번 질문은 몇 초 만에 답할 수 있는데 3번과 4번에 반나절이 걸린다면, 청구서 쪽은 작동하고 있지만 생산 기록과의 연결이 빠진 것입니다. 네 가지 모두 반나절이 걸린다면 문제는 상류에 있습니다. 즉, 배치 코드가 아예 수집되지 않고 있으며, 기록되지 않은 코드는 아무리 찾아도 발견할 수 없습니다. 어느 결과든 유용하며, 두 경우 모두 공급업체가 같은 날 모든 고객에게 전화를 돌리는 리콜 통지 시점보다 지금 발견하는 편이 비용이 적게 듭니다.
매 분기마다 다른 배치로 테스트를 실행하십시오. 실패하는 코드는 대화가 필요한 공급업체이며, 계속 비어 있는 열은 입고 프로세스가 수집하지 않는 필드입니다.
FAQ
모든 식품 공급업체 청구서에 배치 번호가 포함되어 있습니까?
아닙니다. 유제품, 육류, 신선 농산물처럼 부패성 및 규제 대상 품목은 보통 포함되어 있지만, 건조 식품은 포함되지 않는 경우가 많습니다. 일부 공급업체는 납품서나 케이스 라벨에만 로트 코드를 인쇄합니다. 청구서는 모든 구매 건에서 생성되는 유일한 문서이므로 배치 대장을 시작하기에 좋은 출발점이지만, 모든 배치 코드를 확보할 수 있는 신뢰할 만한 출처는 아닙니다.
청구서에 배치 번호가 없을 때는 어떻게 해야 합니까?
배치 번호 없이 입고를 기록하고, 자체적으로 번호를 만들어 공급업체의 번호인 것처럼 제시하지 말고 공급업체에 서면으로 코드를 요청하십시오. 내부 입고 번호는 별도 열에 둘 수 있지만, 공급업체 기록에 존재하지 않으므로 공급업체 코드를 대체하지는 못합니다. 납품서나 팔레트 라벨에 코드가 있다면 그것을 사용하고, PO 또는 납품서 번호를 통해 청구서와 연결하십시오.
도구가 바코드에서 배치 번호를 읽을 수 있습니까?
문서에 인쇄되거나 손으로 쓰인 문자를 읽으며, 바코드 옆에 인쇄된 코드도 포함됩니다. 바코드 자체를 해독하지는 않습니다. 코드가 GS1-128 또는 DataMatrix 심볼에만 인코딩되어 있는 경우에는 바코드 스캐너나 창고 시스템에서 제공해야 합니다.
하나의 청구서 항목이 세 개의 배치를 포함하는 경우 어떻게 처리합니까?
입고 시 팔레트 라벨이나 납품서를 사용하여 세 개의 행으로 분할하고, 각 행에 청구서 번호와 단가를 반복 입력한 뒤 수량을 세 개의 코드에 나누어 배분합니다. 추출은 문서에 표시된 내용만 생성할 수 있습니다. 분할은 입고 결정 사항이며, 테이블이 만들어진 후의 정리가 아니라 그 전에 이루어져야 합니다.
이것으로 FSMA 204 또는 EU 178/2002를 준수하게 됩니까?
아닙니다. 해당 규정이 요구하는 기록 보관을 지원하는 구조화되고 정렬 가능한 기록을 생성하며, 24시간 기록 요청에 하나의 테이블에서 답변할 수 있게 합니다. 준수를 위해서는 추적성 계획, 모든 중요 추적 이벤트에서의 기록, 생산 및 출하로부터의 전방 기록, 그리고 EU의 경우 고객에 대한 한 단계 전방 링크도 필요합니다. 추출된 배치 대장은 시스템이 아니라 하나의 구성 요소로 취급해야 합니다.
같은 테이블을 공급업체 가격 비교에 사용할 수 있습니까?
예, 항목 수준의 세부 정보를 유지한다면 가능합니다. 수량과 단가가 공급업체 전반에 걸쳐 하나의 테이블에 있으면 지불한 금액을 비교하는 것은 정렬 한 번이면 되며, 이는 청구서로 식품 공급업체 가격 비교하기에 설명된 워크플로입니다. 배치 열은 해당 분석을 방해하지 않으며, 이를 유지하면 동일한 추출 결과가 재무와 QA 모두에 사용됩니다.
핵심 요약
식품 추적성은 실험실에서 실패하기 훨씬 전에 기록 간의 연결에서 실패합니다. 공급업체 청구서는 모든 구매가 생성하는 문서이므로 배치 대장을 시작하기에 적합한 곳이며, 멈추기에도 적합한 곳은 아닙니다. 배치 코드를 인쇄된 그대로 캡처하고, 물리적 배치당 하나의 행을 유지하며, 소비기한(품질)과 유통기한(안전)을 구분하고, 결과를 PO 또는 납품서 번호로 입고 및 생산과 연결하십시오. 그렇게 하면 리콜 통지가 일주일간의 전화 통화 대신 스프레드시트의 필터가 됩니다.
귀하의 공급업체 청구서가 배치 대장으로 어떻게 보이는지 확인해 보십시오. 청구서 하나를 업로드하고 필요한 열의 이름을 지정한 뒤 배치 및 날짜 코드가 그 과정을 견디는지 확인하십시오.