FD32インチ SAP: クレジット管理エリアチュートリアル

⚡ スマートサマリー

信用管理 SAP 信用管理領域内で各顧客に信用限度額を割り当てることで、不良債権へのエクスポージャーを制限します。トランザクションFD32は、その限度額が維持される代表的な画面です。

  • 🔘 範囲: 1つの信用管理領域で全ての会社コードに対応させることも、各会社コードに独自の領域を割り当てることも可能です。
  • ☑️ トランザクション: FD32は顧客与信マスタを開き、まず顧客、与信管理領域、およびデータセクションを選択します。
  • ✅ 中央データ: 合計金額は全ての分野におけるクレジット限度額を定め、個別限度額は各分野におけるクレジット限度額を定めます。
  • 🧪 ステータスデータ: ステータス画面に表示される信用限度額、リスク区分、および審査日によって、自動信用審査が実行されます。
  • 🛠️ 構成: OB45、OB38、OVFL、OB01、およびOVA8は、信用管理領域と、それを使用する小切手を作成します。
  • 📈 S/4HANA: FD32は利用できません SAP S/4HANAでは、ビジネスパートナーの役割であるUKM000が、従来のクレジットマスターに取って代わります。

FD32で顧客の信用限度額を維持する SAP

複数の未回収債権や不良債権は、企業の業績に大きな影響を与える可能性があります。信用管理は、顧客ごとに信用限度額を設定し、新規注文をすべてその限度額と照合することで、こうしたリスクを軽減します。

クレジットコントロールエリアとは何ですか SAP?

In SAP信用およびリスク管理は、信用管理領域で行われます。信用管理が集中管理されている場合は、すべての会社コードに対して1つの信用管理領域を定義できます。信用方針で分散管理が求められる場合は、会社コードごと、または会社コードのグループごとに信用管理領域を定義できます。

したがって、信用管理部門は顧客の信用限度額を定義および管理する組織単位です。独自の通貨を持ち、すべての売掛金は 売掛金 これにより、それに対して記録されている信用リスクが増加する。

信用管理分野は、特に以下の3つの事項を管轄する。

  • 制限: その地域内で顧客がいつでも保有できる最大受取額。
  • 暴露: 未処理項目、未処理注文、未処理配送、未処理請求書の累計額。
  • 反応: 制限を超える注文に対して、警告を発するか、ブロックするか、許可するか。

信用管理領域のマスターデータは顧客ごとに管理されており、以下の手順でその方法を説明します。

FD32で顧客の信用限度額を維持する方法(ステップバイステップ)

ステップ1) トランザクションコードFD32を SAP コマンドフィールド。

コマンドフィールドは左上にあります SAP GUI 画面には、以下に示すような表示がされます。

SAP トランザクションコードFD32が入力されたコマンドフィールド

ステップ2) 次の画面で、以下を入力してください。

  1. 信用限度額を維持する顧客の顧客IDを入力してください。
  2. 信用管理エリアに入ってください。
  3. データ選択ブロックで「中央データ」チェックボックスを選択してください。

3つの項目すべてが入力された入力画面は、以下のスクリーンショットのようになります。

FD32の初期画面で、顧客、信用管理領域、中央データが選択されています。

ステップ3) 次の画面で、顧客の信用管理データを管理してください。

スクリーンショットに示すように、中央のデータ画面には合計金額と個別の限度額が表示されます。

FD32中央データ画面には、合計金額と個別の制限フィールドが表示されます。

ステップ4) 保存ボタンを押してください SAP クレジット限度額への変更を保存するための標準ツールバー。

保存ボタンは、ツールバーの左側にあるディスクアイコンです(下図参照)。

保存ボタン SAP 標準ツールバー

ステータスバーに、変更が完了したことを示すメッセージが表示されます。新しい制限は次回の信用調査から適用されるため、既にブロックされている注文は別途解除する必要があります。

信用管理領域の設定と関連 SAP Tコード

FD32はマスタデータのみを管理します。与信管理領域自体、およびそれを参照するチェックはカスタマイズで設定されるため、効果がないように見える限度額は、通常、マスタデータのエラーではなく、設定の不備が原因です。

Tコード 目的
OB45 信用管理領域、その通貨、および更新グループを定義します。
OB38 信用管理領域に会社コードを割り当てる
OVFL 販売エリアを信用管理エリアに割り当てる
OB01 信用管理領域で使用可能なリスクカテゴリーを定義する
OVA8 信用管理領域、リスクカテゴリ、および信用グループに対して自動信用管理を設定する
FD32 / FD33 顧客の信用マスタデータの変更と表示
F.31 / F.35 信用概要および信用マスターシートの報告
VKM1 / VKM4 信用調査により保留されている販売書類の一覧表示と公開

FD32を開く前に確認しておくべき前提条件が2つあります。顧客が既に会社コードに存在していること、および会社コードが入力される信用管理領域に割り当てられていることです。限度額ではなくエクスポージャー額が間違っているように見える場合は、構成のSD側がカバーされています。 SAP SDクレジットマネジメント ガイド。

FD32クレジット管理画面の主要項目

FD32は複数画面のトランザクションであり、入力画面のデータ選択ブロックによって開く画面が決まります。最も重要な項目は以下のとおりです。

画面 フィールド 意味
中央データ 合計金額 顧客がすべての信用管理領域で受けられる可能性のある全体的な信用度
中央データ 個人制限 顧客が単一の信用管理区域内で受け取ることができる最大信用額
中央データ 取引通貨 中央制限が保持される通貨
ステータス 信用限度額 最初の画面で入力された、信用管理エリアで付与された限度額
ステータス リスクカテゴリー OVA8による自動信用調査の適用方法を決定するキー
ステータス 信用代表者グループ アカウントの監視を担当する従業員グループ
ステータス 前回および次回の内部レビュー 制限が最後に見直された日付と、次回の見直し予定日
支払歴 支払いデータ 決済済み項目、平均延滞日数、および最大未払い金額

総額と個別限度額は連動して機能します。個別限度額は各エリアの上限を定め、総額は全エリアの合計額の上限を定めます。個別限度額を総額より高く設定することは可能ですが、実際には効果はありません。 Rev閲覧日を指定すると信用審査の作業リストに反映されるため、空欄のままにしておくと、そのリストからアカウントが静かに削除されます。

信用管理 SAP S/4HANA:FD32に代わるものは何か

従来のSDクレジット管理は利用できません SAP S/4HANA。これは、 SAP 信用管理は財務サプライチェーン管理の一部であり、それに伴い取引コードも変更されます。

  • マスターデータ: 信用データは、トランザクション FD32 の代わりにトランザクション BP または UKM_BP を使用して管理されるロール UKM000 のビジネス パートナーに転送されます。
  • セグメント: 信用管理領域は信用セグメントに置き換えられ、限度額は領域ごとではなくセグメントごとに設定される。
  • ブロックされた文書: UKM_MY_DCDSに記録された信用決定情報は、従来のリリースリストに取って代わるものです。
  • テーブル: 従来のKNKAおよびKNKKクレジットマスターテーブルはUKMBP_CMSテーブルに置き換えられ、S066およびS067エクスポージャー構造も置き換えられます。
  • 変換: 既存の信用マスタデータはシステム移行時に移行されるため、限度額を再度入力する必要はありません。

まだ走っている人はいますか? SAP ERP Central Component は、上記のとおり FD32 をそのまま保持しており、概念はきれいに引き継がれています。制限、リスク カテゴリ、およびエクスポージャー 数値は両側に存在します。ビジネス パートナー ロールの詳細な説明は、このドキュメントに掲載されています。 SAP コミュニティ記事 SAP 与信管理下流では、同じ顧客残高が 督促 清算修正については クリア済みアイテムのリセット.

よくあるご質問

自動信用審査は、リスクカテゴリの設定に応じて、警告、エラー、または配送ブロックのいずれかの反応を示します。ブロックされた販売伝票は、信用担当者が承認または却下するまで、リリースリストに残ります。

静的チェックでは、限度額を未決済項目、注文、配送、請求書の合計と比較します。動的チェックでは、信用期間が設定されるため、その期間を超えて予定されている注文は無視されます。どちらのチェックも、リスクカテゴリごとに設定できます。

エクスポージャーはサマリー構造で管理されますが、更新エラーが発生すると、その構造がずれてしまう可能性があります。再編成レポートRVKRED77は、影響を受ける顧客および信用管理領域の信用額を再構築し、その後、数値が未決済項目と再び一致するようにします。

従来の信用データは、一般的な顧客マスタビューではなく、専用のテーブルに格納されています。KNKAテーブルには中央データが格納され、KNKKテーブルには信用管理領域ごとに1件のレコードが格納されます。そのため、データは顧客登録画面ではなく、FD32トランザクションコードを使用して管理されます。

機械学習モデルは、支払い行動、延滞日数、外部評価などを評価し、支払限度額やリスク区分を提案するとともに、回収作業リストを支払可能性に基づいてランク付けします。ただし、この提案は信用管理担当者に届く前に、人間の承認が必要です。

はい。アシスタントとしては GitHubコパイロット 一括信用限度額ロード処理の背後にあるABAPコード、バッチ入力コード、またはスクリプトコード、およびエクスポージャーレポートの背後にあるクエリを作成します。生成されたプログラムはすべて、まずサンドボックスクライアントでテストしてください。

限度額は、信用管理区域の通貨で設定され、その通貨は区域が定義される際に固定されます。他の通貨で計上された書類は、限度額と比較される前に、その通貨に換算されます。

信用マスタへの変更はすべて記録され、変更文書は顧客および信用管理領域ごとに一覧表示できます。ログには、変更前の値、変更後の値、ユーザー、日付が表示されます。これらは、信用判断の監査で通常求められる情報です。