보증 등록 기록은서로 충돌하는 두 문서

보증 등록 기록은 애초에 일치하도록 설계되지 않은 두 문서로 구성됩니다. 하나는 식탁이나 대리점 카운터에서 작성하는 카드입니다. 다른 하나는 판매 시점에 출력되는 영수증 또는 인보이스입니다. 카드에는 소유자가 담기고, 영수증에는 거래가 담깁니다. 대부분의 영수증에는 제품이 담기지 않습니다.

기록에는 열두 개의 필드가 필요합니다. 두 문서를 합치면 열 개를 확보할 수 있습니다. 두 개는 파생해야 하며, 열 개 중 네 개는 두 문서에 서로 다른 값으로 나타날 수 있습니다. 이러한 산술 구조 때문에 등록 파일이 완전해 보여도 첫 청구에서 실패할 수 있습니다.

수작업 입력은 그만 — AI가 대신 읽어드립니다
이미지나 PDF를 업로드하세요 — 10초 만에 정형 데이터로
지금 체험하기 →
A minimalist editorial illustration with the title 'Why Warranty Registration Records Disagree With the Receipt' in bold dark blue, below it three icons with labels 'Card vs Receipt', 'Identity & Date Drift', and 'Traceable Sources', on a soft gradient background with hand-drawn blue line decorations in the corners.

핵심 요약

  1. 보증 기록에는 열두 개의 필드가 필요하며, 카드와 영수증을 합쳐도 열 개만 확보할 수 있습니다.
  2. 이 중 네 개의 필드는 두 문서에 서로 다른 값으로 나타날 수 있으므로, 완전해 보이는 파일도 첫 청구에서 실패할 수 있습니다.
  3. 두 값과 출처 열을 모두 유지해야 합니다. 완전은 모든 필드가 채워진 상태를, 정확은 모든 필드에 출처가 있는 상태를 의미하기 때문입니다.

좋은 레코드는 단위당 한 행이며, 열두 개 필드를 모두 갖춘 문서는 없습니다

보증 등록 레코드는 다섯 가지 질문에 답하는 단위별 항목입니다. 어떤 실물 제품인지, 누구에게 판매되었는지, 언제, 누구에 의해, 어떤 보증 범위 아래에서인지입니다. 단위별이라는 점이 대부분의 등록 파일이 틀리는 부분입니다. 판매는 이벤트입니다. 단위는 일련번호, 서비스 이력, 그리고 영수증보다 오래가는 수명 주기를 가진 객체입니다.

아래 표는 실무 레코드에 필요한 필드 목록과 각 필드를 어떤 문서에서 제공할 수 있는지 보여줍니다. 마지막 열이 논쟁의 대상입니다. 두 문서가 불일치할 때 값이 어디에서 와야 하는지를 나타냅니다.

필드등록 카드영수증 또는 인보이스권위 있는 출처
제품 모델때때로, 박스에서때때로, 소매점 설명카톤 라벨 또는 유닛 명판
SKU 또는 바코드 번호아니오예, 바코드 또는 매장 코드영수증
일련번호때때로, 손으로 옮겨 적음드물게유닛 라벨
수량아니오, 단위당 카드 한 장예, 라인 수량영수증
구매 날짜자주, 기억에 의존예, 거래 타임스탬프영수증 또는 납품서
소매점 또는 딜러자주예, 헤더영수증
영수증 또는 인보이스 번호아니오예영수증
지불 가격아니오예영수증
소유자 이름예아니오, 인보이스에 이름이 있는 경우 제외카드
소유자 연락처 및 주소예아니오카드
보증 시작일아니오아니오프로그램 규칙
보증 기간아니오드물게, 플랜이 판매된 경우프로그램 규칙

네 개 필드는 영수증에만 나타나고, 두 개는 카드에만 나타나며, 네 개는 양쪽 모두에 나타날 수 있습니다. 마지막 두 개는 어느 쪽에도 안정적으로 존재하지 않습니다. 보증 시작일은 판매와 배송에 적용되는 규칙이지 어디에도 인쇄된 값이 아닙니다. 보증 기간은 제품 라인과 프로그램에서 비롯되며, 때로는 연장 플랜이 그 위에 더해지기도 합니다. 어떤 추출 도구도 카드에서 이 둘 중 하나를 읽어낼 수 없습니다.

카드가 쓸모없는 것은 아닙니다. 카드는 소유자와 연락처 정보의 유일한 출처이며, 이는 리콜이나 안전 공지가 의존하는 데이터이기도 합니다. 영수증은 거래의 유일한 출처입니다. 유닛 라벨은 이 둘을 실물 객체에 연결하는 유일한 출처입니다. 이들은 서로 다른 세 가지 역할이며, 하나의 문서가 이 모두를 수행할 수는 없습니다.

카드가 소유자를 증명합니다. 영수증이 판매를 증명합니다. 제품 라벨이 정체성을 증명합니다.

모델명, 소매 SKU, GTIN은 서로 다른 것이기에 정체성 확인이 가장 먼저 실패합니다

'모델명 vs 소매 SKU vs GTIN'이라는 제목의 3열 비교 일러스트: '모델명'이라고 표시된 제품 상자 아이콘과 '상자에 인쇄된 이름', '소매 SKU'라고 표시된 가격표 아이콘과 '소매업체의 재고 코드', 'GTIN'이라고 표시된 바코드 아이콘과 '해당 품목의 모든 개별 제품이 공유', 하단에 '일련번호만이 개별 제품을 식별함'이라는 결론 문구가 있으며, 은은한 선 장식이 있는 밝은 그라데이션 배경.

모델 필드는 카드와 영수증이 처음으로 불일치를 보이는 지점이며, 이 불일치는 사무적인 실수가 아니라 구조적인 문제입니다. 고객은 자신이 아는 이름인 상자에 인쇄된 이름을 기재합니다. 소매업체는 자사의 POS 시스템에 저장된 자체 설명과 자체 재고 코드를 인쇄합니다. 어느 쪽도 명판에 있는 제조사의 모델 번호가 아닙니다.

소매 바코드의 기반이 되는 표준이 이러한 식별자를 구분하는 데는 이유가 있습니다. 바코드 시스템을 관리하는 기관인 GS1은 GTIN을 거래 품목의 식별자로 정의합니다. 해당 품목의 모든 개별 제품이 이를 공유합니다. 여기에 바코드에서 응용 식별자 21로 표시되는 일련번호를 추가하면 하나의 물리적 제품을 식별할 수 있습니다. GTIN만으로는 동일한 제품 10개 중 어느 것이 매장에서 나갔는지 알 수 없습니다. 전체 구분에 대해서는 GS1 Global Traceability Standard를 참조하십시오.

바코드 번호가 있는 영수증은 어떤 제품이 판매되었는지 알려줍니다. 일련번호가 영수증에 인쇄되어 있지 않다면 어느 개별 제품이 매장에서 나갔는지는 알려주지 않습니다. 대부분의 영수증에는 인쇄되어 있지 않습니다. 그래서 영수증에 있는 일련번호가 한 페이지의 제품 설명보다 가치가 있으며, 대개 없는 것입니다.

이 격차는 이론적인 것이 아닙니다. 한 구매자가 r/Lenovo에서 같은 문제를 설명했습니다: "Croma가 발행한 인보이스의 일련번호가 실제 노트북과 일치하지 않았습니다. 이로 인해 보증 활성화 문제가 발생했고 Croma와 Lenovo 사이에 많은 왔다 갔다가 있었습니다." 고객은 노트북을 가지고 있었고, 소매업체는 인보이스를 가지고 있었으며, 제조사는 보증 시스템을 가지고 있었습니다. 일련번호는 이 세 가지를 모두 연결하는 유일한 필드였고, 바로 그것이 잘못된 것이었습니다.

필기체는 카드에 두 번째 실패를 추가합니다. 라벨에서 복사한 일련번호는 O를 0으로, I를 1로 바꿀 수 있으며, 감열 영수증은 같은 문자열 중간에 접힘 선을 만들 수 있습니다. 등록 포털은 해당 값을 유효하지 않다고 거부할 수 있으며, 올바른 제품을 가진 사람은 제품이 올바르지 않다는 말을 듣게 됩니다. 올바른 일련번호와 유효한 일련번호는 같은 것이 아닙니다.

하나가 아닌 세 개의 열을 유지하십시오: 카드의 모델, 영수증의 SKU 또는 GTIN, 일련번호. 일련번호가 카드에만 나타나는 경우 확인된 것이 아니라 주장된 것으로 표시하십시오. 일련번호가 사실이 되는 곳은 카드가 아니라 라벨입니다.

GTIN은 어떤 제품인지 알려줍니다. 일련번호만이 어느 개별 제품인지 알려줍니다.

구매 날짜는 카드에서는 기억이고, 영수증에서는 타임스탬프입니다

'카드의 날짜 대 영수증의 날짜'라는 제목의 2단 비교 일러스트. 왼쪽 열에는 물음표가 있는 달력 아이콘과 '카드 날짜'라는 라벨, '구매 후 며칠 또는 몇 주 뒤에 작성됨'이라는 텍스트가 있고, 오른쪽 열에는 체크 표시가 있는 시계 아이콘과 '영수증 타임스탬프'라는 라벨, '계산대에서 생성됨'이라는 텍스트가 있으며, 은은한 선 장식이 있는 밝은 그라데이션 배경입니다.

두 번째로 문제가 되는 필드는 날짜입니다. 카드에는 기억이 기록되고 영수증에는 사건이 기록되기 때문입니다. 고객은 구매 후 며칠 또는 몇 주 뒤에 카드를 작성합니다. 월과 연도만 적거나, 제품을 배송받은 날짜를 적거나, 마침내 상자를 개봉한 날짜를 적습니다. 영수증에는 계산대에서 생성된 거래 날짜와 종종 시간까지 있습니다.

보증이 시작되는 날짜가 반드시 둘 중 하나인 것은 아닙니다. EU에서는 Directive (EU) 2019/771 제10조에 따라, 판매자는 배송 후 2년 이내에 발견되는 부적합에 대해 책임을 집니다. 기산점은 등록이 아니라 배송 시점입니다. 미국에서는 FTC의 Magnuson-Moss Warranty Act 해석에 따라, 완전 보증은 소비자에게 등록 카드 반환을 요구할 수 없으며, 카드는 구매 날짜를 입증하는 한 가지 방법으로만 제안될 수 있습니다(16 CFR 700.7). 어느 제도에서도 카드가 법적 기산점은 아닙니다.

어떤 날짜를 사용할지는 여전히 프로그램 규칙이 결정합니다. 일부 프로그램은 판매 날짜를 사용하고, 일부는 배송 또는 설치 날짜를 사용하며, 일부는 판매 날짜가 기록되지 않은 경우 출하 날짜나 딜러에게 발행된 인보이스 날짜를 기본값으로 사용합니다. 마지막 기본값은 고객의 보증 기간을 조용히 단축시키는 원인이며, 판매 날짜 누락이 중립적인 사건이 아닌 이유입니다.

따라서 실용적인 기록에는 최소 두 개의 날짜 열이 필요합니다. 구매 증빙에 기재된 날짜와, 확인 가능한 경우 배송 또는 설치 날짜입니다. 단일 Purchase Date 열은 관리자가 하나를 선택하도록 강제하고 다른 하나의 증거를 버리게 만듭니다.

수량은 또 다른 불일치를 만듭니다. 딜러 인보이스에는 수량 라인이 있을 수 있습니다. 한 모델 10대, 인보이스 번호 하나, 날짜 하나입니다. 카드는 대당 한 장씩 도착합니다. 영수증당 한 행으로 만든 시트는 행이 하나이고 10대 중 9대가 누락됩니다. 카드당 한 행으로 만든 시트는 행이 열 개이고, 누군가 인보이스 번호를 열 번 복사하지 않는 한 인보이스 번호가 없습니다.

인보이스에 10개의 일련번호가 나열되어 있다면 수량과 일련번호 목록을 추출한 뒤, 스프레드시트에서 목록을 행으로 분할합니다. 그렇지 않다면 카드가 유일한 대당 연결 고리이며, 그중 어느 것도 확인이 아니라 주장에 불과합니다. 일련번호가 인보이스, 패킹 리스트, 카드에 흩어져 있을 때 이를 하나의 열로 모으는 것 자체가 하나의 단계입니다. 혼합 문서에서 일련번호를 추출하는 워크플로가 그 부분을 다룹니다.

영수증은 거래입니다. 기록은 대당 단위입니다. 두 개수가 일치하는 경우는 드뭅니다.

네 사람이 같은 필드를 복사하고, 각 복사본은 어긋날 기회입니다

기록은 네 쌍의 손을 거치며, 모든 인계마다 이미 한 번 적힌 데이터를 다시 입력합니다. 어긋남은 부주의 때문이 아닙니다. 각자가 다른 문서를 가지고 있고, 그 문서에서 복사할 다른 이유가 있기 때문입니다.

누구아는 것추가하거나 잃는 것
고객이름, 연락처, 주소, 그리고 언제 어디서 구매했는지에 대한 기억을 보유소유자 데이터를 추가하고, 모델·일련번호·날짜를 추측하며, 종종 몇 주 후에 등록하거나 아예 하지 않음
소매업체 또는 딜러영수증을 발행하고, 실제 배송 날짜와 다중 판매의 경우 일련번호 목록을 앎거래를 추가하고, 판매 시점에 등록할 수 있으며, 한 번의 카운터 판매로 하나의 인보이스 뒤에 열 대가 묶일 수 있음
보증 관리자카드와 증빙을 받고, 보증 시스템에 입력하며, 기록이 완전한지 판단프로그램 규칙과 활성화를 추가하고, 모든 필드를 다시 입력하며, 청구 실패 시 거절을 담당
서비스 기술자기기의 모델과 일련번호 명판을 읽고, 고장 지점에서 고객을 만남기록을 실제 기기와 처음으로 대조하며, 종종 몇 년 후에 함

관리자가 중심입니다. 딜러 청구의 경우, 한 화면에는 딜러 관리 시스템(DMS)의 딜러 인보이스가, 다른 화면에는 제조사 보증 포털이 있는 경우가 많고, 그 사이에서 다시 입력합니다. 각 재입력은 숫자 하나를 빠뜨리거나 영수증의 타임스탬프 대신 카드의 손글씨 날짜를 선택할 기회입니다. 두 번 복사한 후에는 어느 값이 원본인지 아무도 알 수 없습니다.

등록은 반품이 아니며, 그 차이가 누가 데이터를 소유하는지 결정합니다. 등록 기록은 판매 시점에 생성되며, 반품이 존재하기 전입니다. 반품 승인(RMA) 기록은 고장 시점에 생성되며, 기기가 반환될 때입니다. 같은 일련번호가 둘 다에 나타날 수 있지만, 문서와 시점, 그리고 이를 보유한 사람이 다릅니다. 팀에서 이를 하나의 종이 문제로 취급하고 있다면, 창고의 종이 반품 양식은 별도의 해결책이 필요한 별개의 문제입니다.

세 번째 복사본쯤 되면, 기록은 원본에 대한 소문이 됩니다.

수작업 입력은 그만 — AI가 대신 읽어드립니다
이미지나 PDF를 업로드하세요 — 10초 만에 정형 데이터로
지금 체험하기 →

종이에서 데이터로 넘어가는 단계가 깨지는 이유는 카드와 영수증이 레이아웃도, 키도 공유하지 않기 때문입니다

종이에서 데이터로 넘어가는 단계는 템플릿으로 해결할 수 없는 두 가지 문제에서 깨집니다. 카드와 영수증은 레이아웃을 공유하지 않고, 키도 공유하지 않습니다. 템플릿 기반 추출은 필드가 모든 문서에서 같은 위치에 있다고 가정합니다. 등록 카드도, 소매점 영수증도 그런 보장을 하지 않습니다. 카드는 한 번 인쇄한 뒤 손으로 채웁니다. 체크박스, 필기체, 일련번호 칸을 뚫고 지나간 스테이플러 심, 비스듬히 찍은 휴대폰 사진까지 있습니다. 영수증은 더 심합니다. 소매점마다 POS 시스템의 약어, 줄 순서, 용지가 다릅니다. 감열 인쇄는 흐려지고, 카운터에서 찍은 영수증은 기울고 일부는 그림자가 집니다.

한 소매점 영수증용 템플릿은 다음 소매점에서 깨집니다. 한 카드 인쇄분용 템플릿은 제조사가 재인쇄할 때 깨집니다. 두 문서는 참조 번호도 공유하지 않습니다. 카드에는 인보이스 번호가 없고, 영수증에는 보통 일련번호가 없습니다. 완벽하게 추출해도 단일 열로 조인할 수 없는 두 개의 테이블이 남습니다. 레이아웃 문제는 눈에 보입니다. 빠진 키가 작업을 멈추게 하는 문제입니다.

맞춤 열 추출은 반대쪽 끝에서 시작합니다. Receipt Date, Receipt SKU, Serial Number처럼 원하는 열 이름을 입력하면 AI가 좌표가 아니라 의미로 각 값을 찾습니다. 그릴 영역도, 소매점별 템플릿도 없으므로 새로운 영수증 레이아웃은 새로 만들 설정이 아니라 읽을 새 페이지일 뿐입니다.

열 이름은 필드뿐 아니라 문서도 반영해 지정합니다. Model on Card, Date Written on Card, Receipt SKU, Receipt Date, Card Serial처럼요. 카드 배치에서는 이런 레이블이 출력을 정직하게 유지합니다. 두 문서가 함께 나오는 단일 이미지에서는 모델이 먼저 본 날짜 값을 반환하는 대신 두 날짜 값을 구분할 수 있게 해줍니다.

배치 처리가 나머지 절반입니다. 카드 한 상자는 한 번 업로드되어 한 세트로 처리되고 하나의 Excel 파일로 병합되므로 작업 단위가 입고 단위와 일치합니다. 출력은 다음 단계가 스프레드시트인지, 보증 시스템 가져오기인지, 스크립트인지에 따라 XLSX, CSV 또는 JSON이 될 수 있습니다.

Bbox가 있는 검토 모드는 충돌할 수 있는 네 개 필드를 확인하는 방법입니다. 추출된 셀 위에 마우스를 올리면 원본 이미지에서 해당 영역이 강조 표시됩니다. 이미지에서 영역을 클릭하면 일치하는 셀이 선택됩니다. 분쟁이 있는 날짜는 더 이상 기억력 싸움이 되지 않습니다. 카드에 3/2026이라고 적혀 있는지 5/2026이라고 적혀 있는지, 영수증의 타임스탬프가 납품서와 같은 날인지 직접 볼 수 있습니다. 카드가 빽빽한 손글씨라면 더 높은 Model Tier, 즉 기반 비전 모델을 선택하는 계정 설정을 사용해야 합니다. 표준 티어는 인쇄된 표를 위해 만들어졌습니다.

추출은 의견 충돌을 해결하지 않습니다. 판단할 수 있는 사람 앞에 두 값을 나란히 놓을 뿐입니다.

4단계 접수 절차로 불일치를 평균으로 덮지 않고 그대로 드러냅니다

'불일치를 그대로 드러내는 4단계 접수 절차'라는 제목의 목록형 일러스트로, 2x2 격자에 네 개의 번호 항목이 표시되어 있습니다: '필드 목록과 기록 출처 확정', '문서 세트를 분리 유지', '쌍을 비교하고 충돌만 검토', '규칙을 기록에 반영', 밝은 그라데이션 배경에 은은한 선 장식이 있습니다.

접수의 목표는 깔끔한 시트가 아닙니다. 모든 값이 이를 제공한 문서로 여전히 추적될 수 있는 시트입니다. 이를 위해서는 네 가지 결정을 한 번 내리고 모든 배치에 적용해야 합니다.

1

필드 목록과 기록 출처 확정

열두 개 필드를 가져와 각 필드에 어떤 문서가 우선하는지 적습니다. 영수증은 구매 날짜, 가격, 판매처, 영수증 번호에 우선합니다. 제품 라벨은 일련번호에 우선합니다. 등록 카드는 소유자와 연락처 정보에 우선합니다. 보증 시작일과 기간은 문서를 읽은 후 프로그램 규칙에 따라 채워지며, 어느 문서에서도 복사하지 않습니다.

2

문서 세트를 분리 유지

등록 카드는 하나의 배치로, 구매 증빙은 다른 배치로 처리합니다. 한 제품의 카드와 영수증이 별도 파일로 도착하면 두 개의 테이블을 유지하고 나중에 조인합니다. 하나의 다중 페이지 스캔으로 도착하면 페이지가 기본적으로 별도 행으로 반환되는데, 이는 검토에는 적합하지만 조인하기 전까지는 제품별 기록이 아닙니다. 딜러는 Collection Link를 통해 자체 카드와 인보이스를 업로드할 수 있습니다. 이는 계정 외부의 사람이 등록 없이 파일을 업로드할 수 있게 하는 공유 가능한 링크입니다.

3

쌍을 비교하고 충돌만 검토

양쪽 모두에 일련번호가 있는 경우 이를 기준으로 조인합니다. 영수증이 한 제품을 포함하는 경우 인보이스 번호를 키로 사용할 수 있습니다. 나머지는 담당자가 날짜, 판매처, 모델로 매칭합니다. 그런 다음 두 값이 다른 행에 Review Mode를 엽니다. 일치하는 카드 10장이 있는 10개 제품 인보이스는 10개의 행과 확인할 하나의 패턴을 생성해야 하며, 10개의 개별 조사를 생성해서는 안 됩니다.

4

규칙을 기록에 반영

해결한 모든 충돌에 대해 Source 열과 짧은 메모를 추가합니다. Source: 날짜의 경우 영수증. Source: 다른 곳에 나타나지 않는 일련번호의 경우 카드, 미확인. 이 메모는 해결한 담당자가 떠난 6개월 후에도 기록을 감사 가능하게 만드는 요소입니다.

JPG/PNG/PDF AI 추출

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

기록만으로는 보증 적용 여부를 판단할 수 없고, 추출도 마찬가지입니다

추출은 출처가 확인된 값을 제공합니다. 판정을 내리지는 않습니다. 보증 업무는 두 문서 어디에도 없는 규칙으로 결정되기 때문에 이 경계가 중요하며, 이 경계를 흐리는 도구는 권위 있어 보이지만 방어할 수 없는 새로운 유형의 잘못된 기록을 만들어냅니다.

구매가 실제로 이루어졌는지도 검증하지 않습니다. 영수증은 편집되거나 재사용되거나 빌려올 수 있으며, 도구는 페이지에 적힌 내용을 읽을 뿐입니다. 일련번호를 제조사 데이터베이스와 대조하지도 않습니다. 일련번호가 박스와 제품 명판에 일치하더라도 등록 포털에서 거부될 수 있는데, 포털은 눈앞의 문서가 아니라 데이터베이스를 확인하기 때문입니다. 제품 번호와 일련번호가 배송 박스와 일치하는데도 구매자가 "어떻게 무효가 될 수 있나요?"라고 묻는 HP 지원 스레드가 이 간극을 가장 명확하게 보여줍니다.

보증 적용 여부, 제외 항목, 프로그램 규칙에 따른 시작일과 종료일, 청구의 유효성도 판단하지 않습니다. 공통 키가 없을 때 두 테이블을 결합하지도 않으며, 이는 여전히 스프레드시트 수식이나 사람의 판단에 달려 있습니다. RMA나 청구를 처리하지도 않습니다. 제품이 고장 나면 서류는 등록 카드에서 반품 승인으로 바뀌고, 재고 시스템으로 들어가는 RMA 데이터는 필드가 다른 별개의 작업입니다.

출력물은 기록 시스템도 아닙니다. 이미 운영 중인 보증 시스템에 가져와 검토하거나 병합하는 테이블일 뿐입니다. 또한 스캔본에는 기록과 동일한 이름, 주소, 연락처 정보가 담겨 있으므로 기록에 적용되는 보존 및 접근 규칙이 파일에도 적용됩니다.

기록은 완전하면서도 틀릴 수 있습니다. 완전하다는 것은 모든 필드가 채워졌다는 뜻입니다. 정확하다는 것은 모든 필드에 출처가 있다는 뜻입니다.

기록은 가장 약한 출처만큼만 신뢰할 수 있습니다

디지털 제품 등록 기록은 작성된 양식이 아닙니다. 출처가 문서화된 값의 집합이며, 분쟁에서 살아남는 것은 바로 그 출처입니다. 등록 카드에도 역할은 있습니다. 소유자가 존재하는 유일한 장소라는 점입니다. 영수증의 역할은 더 강력합니다. 판매가 존재하는 유일한 장소이기 때문입니다. 제품 라벨은 정체성에 대한 최종 결정권을 가지며, 보통 아무도 마지막까지 확인하지 않는 항목입니다.

이 세 가지를 비교할 수 있도록 기록을 구성하십시오. 두 날짜를 모두 보관하십시오. 두 모델 필드를 모두 보관하십시오. 신고된 일련번호와 확인된 일련번호를 분리하여 보관하십시오. 그런 다음 서로 불일치하는 행을 검토하십시오. 그 행들이 2년 후 거부되는 청구로 이어지기 때문입니다.

카드 한 상자와 함께 온 영수증을 배치로 처리하고, 고객보다 먼저 충돌을 확인하십시오. 카드 한 상자로 시도해 보십시오.

FAQ

보증 등록 카드가 제품 구매를 증명하나요?

미국에서는 완전 보증(full warranty)이 소비자에게 카드 반환을 요구할 수 없으며, 16 CFR 700.7에 따라 카드는 구매 날짜를 문서화하는 한 가지 방법으로만 제안될 수 있습니다. 영수증, 인보이스 또는 주문 확인서가 거래를 기록하므로 더 강력한 증거입니다. 둘 다 보관하되, 구매 증명을 중심으로 기록을 구성하고 카드는 소유자 기록으로 취급하십시오.

이 도구가 손으로 작성한 등록 카드를 읽을 수 있나요?

예. 손글씨, 필기체, 체크박스가 지원되며, 인쇄된 영수증과 스캔본도 마찬가지입니다. 빽빽한 손글씨는 더 높은 처리 티어가 필요한 경우입니다. 이 도구는 적힌 내용을 추출할 뿐, 손으로 쓴 일련번호가 올바른 것인지 판단하지는 않습니다.

하나의 영수증이 여러 제품을 포함하는 경우는 어떻게 하나요?

영수증에서 수량과 일련번호 목록을 추출한 다음, 스프레드시트에서 일련번호당 한 행으로 목록을 분할하십시오. 영수증에 일련번호가 나열되어 있지 않다면, 카드가 제품별로 연결할 수 있는 유일한 수단이며, 제품 라벨을 확인할 때까지 신고된 값으로 취급해야 합니다.

제조사 데이터베이스와 대조하여 일련번호를 검증하나요?

아니요. 인쇄된 그대로 일련번호를 읽습니다. 검증은 자체 마스터 데이터, 딜러 기록 또는 제조사 포털과 대조하는 별도의 단계이며, 라벨에 올바르게 적힌 값도 이 검사에서 실패할 수 있습니다.

보증은 어느 날짜부터 시작해야 하나요?

등록 카드에 적힌 날짜가 아니라 구매 증빙에 있는 배송 또는 판매 날짜부터 시작합니다. 인보이스 날짜인지, 배송 또는 설치 날짜인지, 활성화 날짜인지는 프로그램 규칙이 결정합니다. 도구는 후보 날짜를 제공하며, 그중 하나를 선택하는 규칙은 보증 프로그램에 속합니다.

딜러가 등록 카드와 인보이스를 직접 제출할 수 있나요?

예. 수집 링크를 사용하면 딜러가 계정 없이 파일을 업로드할 수 있으며, 이미 받은 등록 카드는 일반 배치로 처리할 수 있습니다. 딜러 인보이스에 실제 제품과 일치하지 않는 일련번호가 있을 수 있으므로, 딜러의 업로드에도 동일한 출처 확인이 필요합니다.

📮 contact email: [email protected]