SAP得意先マスタの重複チェック手順｜重複レコードの検出と是正

01SAP得意先マスタの重複チェック

SAPの得意先マスタに重複レコードがあると、受注、出荷、請求、入金消込、与信管理、分析の各処理で同じ取引先が別顧客として扱われます。重複チェックは一覧を目視するだけで終わらせず、候補抽出、同一性の確認、業務影響の確認、是正、再発防止までを一つの運用として設計します。

SAP ECCでは得意先マスタを販売エリアや会社コードなどの組織情報と組み合わせて管理します。SAP S/4HANAではビジネスパートナを中心に顧客情報を管理するため、利用中のデータモデルと業務画面を最初に確認します。日常の登録・変更手順は、全社のマスターデータ管理の基本方針に合わせて統一します。

重複レコードが引き起こす業務影響

同一法人に複数の得意先番号が存在すると、売上や債権残高が番号ごとに分散します。受注担当者が誤った得意先を選択した場合、価格、出荷条件、税分類、支払条件、請求先・納品先の関係にも影響します。住所や名称が少し違うだけのレコードは検索で見落としやすく、取引量が増えた後に問題が表面化しやすくなります。

重複の解消では、単純に片方を削除する判断を避けます。受注伝票、納品、請求、会計伝票、未消込明細、契約、EDIや外部連携で使用される番号を確認し、既存伝票の履歴を保てる方法を業務責任者と決めます。多くの場合は、正規レコードを定め、重複側への新規利用を止め、必要な後続処理を完了してから状態を整理します。

02重複候補を抽出する準備

比較対象の項目を決める

最初に「同じ顧客」と判定する基準を決めます。法人顧客では、次のような項目を組み合わせると候補を絞りやすくなります。

• 法人番号、税番号、登記番号などの公的識別子
• 正式名称、カナ名称、略称、旧社名
• 郵便番号、住所、建物名、電話番号
• 代表メールアドレス、Webサイトのドメイン
• 請求先、納品先、支払人などの関連関係
• 営業担当、販売組織、通貨、支払条件
• 外部CRM、受注サイト、EDIでの顧客コード

公的識別子が一致する場合は重複候補の優先度を高くします。一方、電話番号や住所だけの一致は、支店、事業所、グループ会社、移転前住所の可能性があります。完全一致だけでなく、表記ゆれを吸収した比較値も用意します。

抽出条件を固定する

抽出のたびに条件が変わると、前回との差分や改善効果を評価できません。対象クライアント、会社コード、販売組織、流通チャネル、削除フラグやブロック状態、作成日・変更日を記録し、抽出日時と担当者も台帳に残します。

名称の全角・半角、英字の大文字・小文字、法人格の表記、ハイフンや空白、住所の丁目表記を正規化して比較します。正規化後の値だけで判断せず、必ず元のマスタ表示と証憑を照合します。個人事業主や海外顧客では、法人顧客と異なる識別項目を定義します。

既存データを一括修正する場合は、先に検証環境または限定したテスト範囲で結果を確認します。大量変更を行う運用では、SAP MASSトランザクションの基本に沿って、対象ファイル、変更ログ、承認者、ロールバック方法を準備します。

03重複候補の判定手順

1. 候補グループを作る

公的識別子、正規化した名称、住所、電話番号などで候補グループを作成します。候補グループには得意先番号、名称、住所、販売エリア、作成日、最終変更日、登録担当、ブロック状態を記録します。名称の類似度だけで自動統合せず、候補を人が確認できる一覧にします。

判定結果は「同一顧客」「別顧客」「要追加確認」の3区分にすると、作業を進めやすくなります。要追加確認には、親会社と子会社、同一法人の支店、社名変更、事業譲渡、休眠顧客、外部システム専用レコードなどを含めます。

2. 業務上の同一性を確認する

名称と住所が一致していても、請求先を分ける契約や販売組織ごとの運用が存在する場合があります。営業部門、受注管理、経理、与信管理、マスターデータ責任者から確認を取り、法的な顧客単位と業務上の管理単位を整理します。

確認時には、取引先から提示された正式情報、契約書、請求書、税務情報、外部システムの顧客コードを参照します。個人情報や機密性の高い資料は、承認済みの保管場所とアクセス権限で管理します。

3. 利用状況を確認する

候補レコードごとに、未処理の受注、納品、請求、入金、返品、クレーム、契約、外部連携の有無を確認します。未処理伝票が残るレコードを先に統合対象から外し、業務停止や請求誤りを防ぎます。

利用実績がないレコードでも、インターフェースや帳票の固定値として参照されている場合があります。ジョブ、API、IDoc、帳票、外部システムのマッピングを確認し、番号変更が必要な連携を洗い出します。連携を伴う場合は、SAPマスターデータ移行の基本で扱う移行管理の考え方を適用します。

04正規レコードを決める

採用するレコードの基準

正規レコードは、登録情報の完全性、利用実績、組織上の責任、外部連携の安定性を総合して決めます。一般的には、正式な識別情報がそろい、現在の取引で継続利用され、関連組織との整合性が高いレコードを候補にします。

判断基準は次のように明文化します。

• 正式名称と公的識別情報が確認できる
• 住所、税分類、支払条件などの必須項目が整っている
• 現在の受注・請求・入金業務で利用されている
• 販売エリアや会社コードの割当が業務要件に合っている
• 外部システムとの連携コードを安全に維持できる
• 営業部門と経理部門の承認が取得できる

同一法人でも請求先や納品先を分ける必要がある場合は、1件に統合せず、関連する役割や組織関係を整理します。正規レコードの決定理由と承認記録は、後から追跡できる形で保存します。

変更前のバックアップと記録

変更前に対象レコード、関連組織、既存の役割、税情報、支払条件、連携コード、関連伝票の範囲をエクスポートします。取得したデータには抽出日時、抽出条件、実行者、承認者を付けます。

本番変更では、少数件のパイロット、結果確認、段階展開の順に進めます。監査要件がある場合は、元データ、変更後データ、変更理由、承認、実行ログを同じ案件番号で管理します。

05重複レコードを是正する

利用停止から整理までの流れ

重複側のレコードをすぐ削除するのではなく、まず新規受注や新規登録で選ばれない状態を作ります。業務上利用可能なブロック設定、関連伝票の完了、未消込明細の処理、外部連携の切替を順番に進めます。設定変更は、販売組織や会社コードなどの適用範囲を確認してから実施します。

代表的な作業順序は次のとおりです。

1. 正規レコードと整理対象レコードを承認済み台帳に登録する
2. 未処理伝票、未消込明細、返品、契約、連携を確認する
3. 外部システムと帳票の参照先を正規レコードへ切り替える
4. 整理対象レコードへの新規利用を停止する
5. 必要な履歴・残高・証憑を確認する
6. テスト結果を確認して本番処理を実施する
7. 変更後の受注、請求、入金、連携を監視する

既存伝票の得意先番号を変更できるかどうかは、業務処理、会計処理、法令、監査方針に依存します。伝票の直接書き換えを前提にせず、標準機能、取消・再作成、残高移管、後続処理など、システムで認められた方法を担当チームと確認します。

一括変更を安全に実施する

大量の名称、住所、検索語、ブロック状態を変更する場合は、入力ファイルのキー、文字コード、日付形式、必須列、空欄の扱いを検証します。テスト実行では、変更件数、エラー件数、スキップ件数、意図しない上書きの有無を確認します。

権限は、抽出、承認、変更、結果確認で分離します。変更用の強い権限を常用ユーザーに付与せず、期限、対象範囲、実行者、承認者を管理します。エラーが出た場合は入力を修正して再実行し、同じレコードへの重複変更を防ぐため、実行済みファイルと結果ログを照合します。

06データ品質を継続監視する

重複チェックは一度のクレンジングで完了しません。登録時、変更時、定期点検の3段階で品質を測定します。新規登録前に既存顧客を検索し、名称・住所・識別番号の候補を表示する手順を必須化すると、後続の統合コストを抑えられます。

定期点検では、次の指標を月次または四半期で集計します。

• 重複候補の件数と増減
• 公的識別子が未登録の件数
• 必須住所・電話・検索語の欠落件数
• ブロック済みなのに取引が発生した件数
• 同一法人に紐づく得意先番号の件数
• 重複候補の確認完了までの日数
• 部門別・登録経路別の新規重複発生数

品質指標は件数だけでなく、売上、債権残高、取引頻度などの業務影響と組み合わせます。登録経路別に分析すると、手入力、外部連携、一括登録、買収データなど、再発源を特定できます。判定ルールと責任分担はSAPマスターデータ品質チェックの基本に沿って運用台帳へ反映します。

07再発を防ぐ運用設計

重複の発生源を抑えるには、登録者だけに注意を求めるのではなく、プロセスに検索、照合、承認を組み込みます。新規登録フォームでは、公的識別子をキーにした検索、名称・住所の候補表示、必須項目チェック、登録理由の入力を実施します。

データ所有者は、顧客の定義、正規レコードの決定、例外承認、廃止判断を担当します。営業部門は取引実態と連絡先を確認し、経理部門は請求・入金・税務情報を確認し、ITや連携担当は外部コードとインターフェースを確認します。

ルール変更時には、テストデータで誤検知と見逃しを評価します。法人格の表記、住所変更、合併、社名変更、海外表記、同一グループ会社などの例外をルール台帳に追加し、判断結果を次回の候補抽出へ反映します。運用全体の責任分界はSAPマスターデータガバナンスの基本で整理する考え方と整合させます。

08トラブルシューティング

重複候補が多すぎる

名称や住所だけで候補を作ると、同じビルの別会社、同一グループ、支店が大量に候補になります。公的識別子、電話番号、外部コード、販売組織などの条件を段階的に追加し、候補を高・中・低の優先度に分けます。候補を減らしすぎると見逃しが増えるため、優先度の低い候補も定期点検の対象に残します。

正規レコードを決められない

営業と経理で利用実績が異なる場合は、法的顧客、請求単位、納品単位、受注単位を分けて確認します。合併や事業譲渡が関係する場合は、適用日、旧番号の扱い、未処理伝票、外部連携の切替日を決めます。判断が保留になった候補は、理由、担当者、次回確認日を記録します。

変更後も古いレコードが選ばれる

検索語、ブロック設定、販売エリア別の状態、ユーザーの検索手順を確認します。外部システムや帳票に古い番号が残っていないか、マスターデータ以外の参照先も点検します。変更後の一定期間は、古い番号で作成された受注や連携エラーを監視します。

一括処理でエラーが発生する

エラー行だけを再処理する前に、成功行と失敗行を分離し、対象キーと処理結果を突合します。入力値の桁数、必須項目、組織割当、権限、ロック状態を確認し、少数件で再実行します。結果が不明な場合は、画面表示と変更ログを確認してから再処理します。

09実務で使える確認チェックリスト

• 対象範囲、抽出日時、担当者を記録した
• 重複候補の比較項目と判定ルールを定義した
• 正式名称、公的識別情報、住所、連絡先を確認した
• 受注、納品、請求、入金、契約、外部連携を確認した
• 正規レコードと整理対象レコードを承認した
• 変更前データと実行ログを保存した
• テストまたはパイロットで結果を確認した
• 権限、承認、実行者を記録した
• 変更後の取引と連携を監視した
• 再発防止ルールと品質指標を更新した

得意先マスタの重複チェックは、候補の抽出精度だけでなく、業務影響を確認して安全に整理する運用が重要です。正規レコードの決定基準、変更権限、承認記録、定期的な品質指標をそろえることで、重複レコードの削減と登録品質の安定化を両立できます。