保証登録記録は
2つの文書の衝突

適切な記録は1ユニットにつき1行であり、12項目すべてを持つドキュメントは存在しない

保証登録記録とは、5つの問いに答えるユニット単位のエントリです。どの物理製品が、誰に、いつ、誰によって販売され、どのような保証の対象か。ユニット単位という点が、多くの登録ファイルが誤る部分です。販売はイベントです。ユニットは、シリアル番号、サービス履歴、そしてレシートより長く続くライフサイクルを持つオブジェクトです。

以下の表は、実用的な記録に必要な項目のリストと、各項目をどのドキュメントが提供できるかを示しています。議論すべきは最後の列です。2つのドキュメントが矛盾する場合に、値がどこから来るべきかを示しています。

4つの項目はレシートにのみ現れ、2つはカードにのみ現れ、4つは両方に現れる可能性があります。最後の2つは、どちらにも確実には存在しません。保証開始日は、販売と配送に適用される規則であり、どこかに印刷された値ではありません。保証期間は製品ラインとプログラムから決まり、場合によっては延長プランが上乗せされます。どの抽出ツールも、このどちらかをカードから読み取ることはできません。

カードが無価値というわけではありません。所有者と連絡先の詳細を得られる唯一の情報源であり、これはリコールや安全通知が依存するデータでもあります。レシートは取引の唯一の情報源です。ユニットラベルは、その2つを物理的なオブジェクトに結びつける唯一の情報源です。これらは3つの異なる役割であり、1つのドキュメントですべてを担うことはできません。

カードは所有者を証明する。レシートは販売を証明する。本体ラベルは個体を証明する。

モデル名、小売SKU、GTINは別物であるため、識別情報が最初に破綻する

モデル欄は、カードとレシートの記載が最初に食い違う箇所であり、その不一致は事務的なものではなく構造的なものです。顧客は箱に印刷された名前を記入します。それが顧客の知っている名前だからです。小売店は自店の説明と在庫コードを印字します。それがPOSシステムに保存されている情報だからです。どちらも、定格銘板に記載されたメーカーのモデル番号ではありません。

小売バーコードの背後にある標準規格がこれらの識別子を区別しているのには理由があります。GS1はバーコードシステムを維持する団体であり、GTINを取引商品の識別子と定義しています。その商品のすべての個体が同じGTINを共有します。アプリケーション識別子21としてバーコードに含まれるシリアル番号を追加すれば、1つの物理的な個体を識別できます。GTINだけでは、同一の10個のうちどの個体が店頭から出たのかは分かりません。詳しい区別についてはGS1 Global Traceability Standardをご参照ください。

バーコード番号が記載されたレシートは、どの商品が販売されたかを示します。しかし、レシートにシリアル番号が印字されていない限り、どの個体が店頭から出たかは分かりません。ほとんどのレシートには印字されていません。だからこそ、レシート上のシリアル番号は1ページ分の商品説明よりも価値があり、そしてだからこそ、通常は記載されていないのです。

このギャップは理論上のものではありません。ある購入者がr/Lenovoで同じ問題を報告しています。「Cromaが発行した請求書のシリアル番号が、実際のノートPCと一致しませんでした。そのため保証の有効化に問題が生じ、CromaとLenovoの間で何度もやり取りが発生しました。」顧客はノートPCを、小売店は請求書を、メーカーは保証システムを持っていました。3者をつなぐ唯一の項目がシリアル番号であり、そしてそれが誤っていたのです。

手書きはカード上で第二の破綻を引き起こします。ラベルから書き写したシリアル番号では、Oが0に、Iが1になることがあり、感熱紙のレシートでは同じ文字列の中央に折り目が入ることがあります。登録ポータルはその値を無効として拒否し、正しい製品を持っている人が、製品が正しくないと告げられるのです。正しいシリアル番号と有効なシリアル番号は同じものではありません。

1列ではなく3列を用意してください：カード上のモデル、レシートのSKUまたはGTIN、そしてシリアル番号です。シリアル番号がカードにしか記載されていない場合は、確認済みではなく申告値として扱ってください。シリアル番号が事実となるのは、カードではなくラベルにおいてです。

GTINはどの商品かを示す。どの個体かを示すのはシリアル番号だけである。

購入日はカード上では記憶、レシート上ではタイムスタンプ

次に失敗するフィールドは日付です。カードには記憶が記録され、レシートには出来事が記録されるためです。顧客は購入から数日または数週間後にカードを記入します。月と年を書いたり、製品が配送された日を書いたり、ようやく箱を開けた日を書いたりします。レシートには取引日、多くの場合は時刻もあり、これはレジによって生成されます。

保証期間を開始する日付は、必ずしもどちらか一方ではありません。EUでは、Directive (EU) 2019/771の第10条により、売主は引渡しから2年以内に明らかになった不適合について責任を負います。期間の起算は引渡し時であり、登録時ではありません。米国では、FTCによるMagnuson-Moss Warranty Actの解釈により、完全保証は消費者に登録カードの返送を要求できず、カードは購入日を証明する方法の一つとして提案できるにすぎないとされています（16 CFR 700.7）。どちらの制度でも、カードは法的な起算点ではありません。

どの日付を使用するかは、プログラムの規則によって決まります。販売日を使用するプログラムもあれば、配送日や設置日を使用するものもあり、販売日が記録されていない場合には、出荷日やディーラーへの請求書日付をデフォルトとするものもあります。この最後のデフォルトは、顧客の保証期間を静かに短縮するものであり、販売日の欠落が中立な出来事ではない理由です。

したがって、実用的な記録には少なくとも2つの日付列が必要です。購入証明書に記載された日付と、判明している場合は配送日または設置日です。単一の購入日列では、管理者はどちらか一方を選ばざるを得ず、もう一方の証拠を捨てることになります。

数量はもう一つの不一致を生みます。ディーラー請求書には数量行が含まれることがあります。あるモデル10台、請求書番号1つ、日付1つです。カードは1台につき1枚届きます。レシートごとに1行で作成されたシートには1行しかなく、9台分が欠落します。カードごとに1行で作成されたシートには10行ありますが、誰かが10回コピーしない限り請求書番号はありません。

請求書に10台のシリアル番号が記載されている場合は、数量とシリアル番号のリストを抽出し、そのリストをスプレッドシートの行に分割します。記載されていない場合、カードが唯一の1台ごとのリンクであり、そのすべてが確認ではなく主張となります。シリアル番号が請求書、梱包明細、カードに分散している場合、それらを1つの列にまとめること自体が1つのステップです。混在したドキュメントからシリアル番号を抽出するワークフローがその部分をカバーしています。

レシートは取引です。記録は1台です。この2つの数はめったに一致しません。

4人が同じ項目を転記し、そのたびにずれが生まれる

記録は4組の手を経由し、引き継ぎのたびにすでに一度書き留められたデータが再入力されます。ずれは不注意によるものではありません。各担当者が異なる書類を持ち、そこから転記する理由も異なるために起こります。

管理者が要となります。販売店からの請求では、一方の画面に販売店管理システム（DMS）の請求書、もう一方にメーカーの保証ポータルを開き、その間で再入力することがよくあります。再入力のたびに、数字を1桁落としたり、レシートのタイムスタンプではなくカードの手書き日付を選んだりする可能性があります。2回転記されると、どの値が原本かは誰にも分かりません。

また、登録は返品とは異なり、この違いがデータの所有者を決めます。登録記録は販売時に作成され、返品はまだ存在しません。返品承認（RMA）記録は故障時、製品が戻ってきたときに作成されます。同じシリアル番号が両方に現れることはありますが、書類、タイミング、それを扱う人物は異なります。チームがこれらを1つの紙の問題として扱っているなら、倉庫にある紙の返品フォームは別の問題であり、別の解決策が必要です。

3回目の転記のころには、記録は原本の噂にすぎなくなります。

紙からデータへの変換ステップが失敗するのは、カードとレシートに共通のレイアウトもキーもないからです

紙からデータへの変換ステップは、テンプレートでは解決できない2つの理由で失敗します。カードとレシートには共通のレイアウトがなく、共通のキーもないことです。テンプレートベースの抽出は、フィールドがすべてのドキュメントで同じ位置にあることを前提としています。登録カードも小売店のレシートも、その前提を満たしません。カードは一度印刷された後に手書きで記入されます。チェックボックス、筆記体、シリアル欄を貫くステープル、斜めから撮影したスマートフォンの写真などです。レシートはさらに厄介です。小売店ごとのPOSシステムには、独自の略語、行の順序、用紙があります。感熱印刷はかすみ、カウンターで撮影したレシートは傾き、一部に影が入ります。

ある小売店のレシート用テンプレートは、次の小売店では使えません。あるカード印刷ロット用のテンプレートは、メーカーが再印刷すると使えなくなります。また、2つのドキュメントには共通の参照番号もありません。カードには請求書番号がなく、レシートには通常シリアル番号がありません。完璧に抽出しても、1つの列で結合できない2つのテーブルが残るだけです。レイアウトの問題は目に見えます。欠けているキーのほうが、作業を止めてしまう原因です。

Custom Column Extractionは逆の方向から始めます。Receipt Date、Receipt SKU、Serial Number など、必要な列名を入力すると、AI が座標ではなく意味によって各値を探します。描画するゾーンも、小売店ごとのテンプレートも不要なので、新しいレシートのレイアウトは新しい設定を作る対象ではなく、読み取る新しいページになります。

列名はフィールドだけでなくドキュメントも含めて付けてください。Model on Card、Date Written on Card、Receipt SKU、Receipt Date、Card Serial のようにします。カードのバッチでは、ラベルによって出力の正確さが保たれます。両方のドキュメントが写った1枚の画像では、最初に見たほうの日付値を返すのではなく、2つの日付値を区別して保持する手がかりにもなります。

バッチ処理がもう半分です。カード1箱を1回アップロードし、セットとして処理して1つの Excel ファイルにマージするため、作業の単位が受け入れの単位と一致します。出力は XLSX、CSV、JSON から選べ、次のステップがスプレッドシートなのか、保証システムへのインポートなのか、スクリプトなのかによって決められます。

Bbox 付きレビューモードは、競合しうる4つのフィールドを確認するための機能です。抽出されたセルにカーソルを合わせると、その値の元になった領域が元の画像上でハイライトされます。画像上の領域をクリックすると、対応するセルが選択されます。日付の食い違いは記憶力の勝負ではなくなります。カードに 3/2026 と書かれているのか 5/2026 なのか、レシートのタイムスタンプが納品書と同じ日なのかを目で確認できます。カードが密集した手書き文字の場合は、より高い Model Tier（基盤となるビジョンモデルを選択するアカウント設定）を使用してください。標準ティアは印刷された表向けに作られています。

抽出は意見の相違を解決しません。判断できる人の前に両方の値を提示するだけです。

4ステップの取り込みで、不一致を平均化せず可視化する

取り込みの目的は、きれいな一枚のシートを作ることではありません。すべての値が、それを提供したドキュメントまでたどれるシートを作ることです。そのためには4つの決定を一度行い、すべてのバッチに適用します。

記録だけでは保証対象を判断できず、抽出も同様です

抽出は根拠のある値を提供しますが、判定を下すものではありません。この境界が重要なのは、保証業務がどちらのドキュメントにも属さないルールによって決まるためであり、この線を曖昧にするツールは、権威があるように見えて擁護できない、新たな種類の不良記録を生み出します。

購入が実際に行われたことを検証するものでもありません。レシートは編集・再利用・借用が可能であり、ツールはページに記載されている内容を読み取るだけです。シリアル番号をメーカーのデータベースと照合することもありません。シリアル番号が箱や本体のプレートと一致していても、登録ポータルで拒否されることがあります。ポータルは目の前のドキュメントではなくデータベースを照合しているからです。製品番号とシリアル番号が配送箱と一致しているのに、購入者が「なぜ無効なのか？」と問い合わせているHPサポートスレッドは、このギャップを最も明確に示しています。

保証対象、除外事項、プログラム規則に基づく開始日と終了日、または請求が有効かどうかを判断するものでもありません。共通キーがない場合に2つのテーブルを結合することもなく、それはスプレッドシートの数式か人の判断に委ねられます。RMAや請求を実行するものでもありません。ユニットが故障すると、書類は登録カードから返品承認に変わり、在庫システムに入力するRMAデータは異なるフィールドを持つ別の作業となります。

また、出力は記録システムではありません。既に運用している保証システムにインポート、レビュー、またはマージするテーブルです。そして、スキャンには記録と同じ名前、住所、連絡先が含まれるため、記録に適用される保持およびアクセスのルールはファイルにも適用されます。

記録は完全であっても、なお誤っていることがあります。完全とはすべてのフィールドが埋まっていることです。正確とはすべてのフィールドに根拠があることです。

記録は最も弱い情報源の精度に左右される

デジタル製品の登録記録は、記入済みのフォームではありません。出典が明示された値の集合であり、紛争時に生き残るのはその出典です。登録カードにも役割はあります。所有者が存在する唯一の場所だからです。レシートにはより強い役割があります。販売が存在する唯一の場所だからです。製品ラベルは同一性について最終的な判断を下すものであり、通常は誰も最後まで見ないものです。

この3つを比較できるように記録を構築してください。両方の日付を保持します。両方のモデル欄を保持します。申告されたシリアル番号と確認されたシリアル番号を分けて保持します。そして、それらが一致しない行を確認してください。そうした行こそが、2年後に却下される請求になるからです。

1カートン分のカードとそれに付属するレシートをバッチで処理し、顧客より先に競合を確認してください。 カートン分のカードで試す。

FAQ

保証登録カードは製品を購入した証明になりますか？

米国では、完全保証は消費者にカードの返送を要求できず、カードは購入日の証明方法の一つとして提案することしかできません（16 CFR 700.7）。レシート、請求書、注文確認は取引を記録しているため、より強い証明となります。両方を保管しつつ、記録は購入証明を中心に構築し、カードは所有者記録として扱ってください。

手書きの登録カードも読み取れますか？

はい。手書き、筆記体、チェックボックスに対応しており、印刷されたレシートやスキャンにも対応しています。密集した手書きの場合は、より高い処理ティアが適しています。ツールは書かれている内容を抽出するものであり、手書きのシリアル番号が正しいものかどうかを判断するものではありません。

1枚のレシートが複数の製品をカバーしている場合はどうなりますか？

レシートから数量とシリアル番号のリストを抽出し、スプレッドシートでシリアル番号ごとに1行に分割してください。レシートにシリアル番号が記載されていない場合、カードが製品ごとの唯一の紐付けとなり、製品ラベルが確認されるまでは申告値として扱う必要があります。

シリアル番号はメーカーのデータベースと照合されますか？

いいえ。印刷されているシリアル番号を読み取るだけです。検証は、自社のマスターデータ、販売店の記録、メーカーのポータルに対する別のステップであり、ラベル上は正しい値でもそのチェックに失敗することがあります。

保証の起算日はどの日付にすべきですか？

登録カードに書かれた日付ではなく、購入証明書の配送日または販売日から起算します。それが請求書の日付、配送・設置日、または有効化日のいずれになるかは、保証プログラムの規則によって決まります。ツールは候補となる日付を提示するだけであり、どれを選ぶかを決める規則は保証プログラム側にあります。

販売店が登録カードと請求書を直接提出できますか？

はい。コレクションリンクを使えば、販売店はアカウントなしでファイルをアップロードでき、すでに受け取った登録カードは通常のバッチとして処理できます。販売店のアップロードにも同じソースチェックが必要です。販売店の請求書に、実際の製品と一致しないシリアル番号が記載されていることがあるためです。