サプライヤ登録プロセス

企業を代表する会社および内部ユーザーは、サプライヤ登録プロセスを使用して、購買組織のサプライヤになるためのリクエストを発行できます。

サプライヤの登録は、サプライヤにとって非常に簡単で直感的です。サプライヤ登録の主なハイライトは次のとおりです:

プロファイル詳細およびその他の要件を簡単に取得できるように最適化されたガイド付きプロセス
顧客定義の検証やデフォルト・ロジックなどの拡張性の向上
地理的な応答性に優れたデータ入力

サプライヤは、次の方法で購買組織との関係に入る可能性があります:

セルフサービスまたは外部サプライヤ登録
内部サプライヤ登録
- 内部サプライヤ登録では、Oracle Sourcing、「サプライヤ」作業領域およびOracle Self Service Procurementを通して新規サプライヤを要求できます。

サプライヤは、見込みおよび費用承認済という2つのビジネス関係のいずれかに登録できます。見込みサプライヤはネゴシエーションおよび資格アクティビティにのみ参加できます。つまり、財務は関与しませんが、費用承認済サプライヤは財務を含むすべてのトランザクションに使用されます。

サプライヤがどのように紹介されているかに関係なく、購買組織はコラボレーション・レビュー・プロセスを使用して登録要求をレビューし、この会社を新しい供給ソースとみなすかどうかを決定します。

サプライヤ登録フロー

次に、サプライヤ登録プロセスの機能を示します。

外部登録の場合:
- 購買組織は、サプライヤ登録URLを潜在的なサプライヤに提供します。これらのURLは、ビジネス関係と招待調達ビジネス・ユニットの暗号化された値で構成されます。
  各ビジネス関係タイプの登録URLは、「調達ビジネス機能の構成」ページの見込みサプライヤ登録URLフィールドおよび費用承認済サプライヤ登録URLフィールドに掲載されています。ページにアクセスするには、「設定およびメンテナンス」作業領域で「調達ビジネス機能の構成」タスクに移動します:
  オファリング: 調達
  機能領域: 調達ファウンデーション
- 外部登録のこの開始ページは、サプライヤの登録およびオンボーディング・プロセスに関する情報を通知するためにパーソナライズできます。ワンタイム・アクセス・コードを送信するEメール通知を調整するために、情報または企業ブランディングを追加することもできます。
- 依頼者は、登録リクエストの開始ページにEメールを入力して、サプライヤ登録の開始に使用される1回かぎりのアクセス・コードを受信することから開始できます。これはセキュリティ機能であり、ボットによる登録リクエストの送信を防ぎます。これにより、各登録に有効な電子メールが確実に関連付けられます。後でEメールを再度指定して登録を完了し、新しいアクセス・コードを取得することで、保存された登録を取得できます。サプライヤ登録URLは、すべてのユーザー(登録を終了するために戻ったユーザーでも)に対して常に同じであるため、サプライヤ・サポートが簡略化されます。
- 電子メールを入力すると、電子メールの検証に必要なアクセス・コードが表示されます。
- Eメールの検証後、会社情報と担当者、住所、事業分類、銀行口座、製品およびサービス・カテゴリ、質問リスト・レスポンスを提供するようにガイドされます。
- すべての情報を指定したら、最終ページでリクエストを送信できます。送信時に、注意が必要な訂正または不足している情報がある場合はガイダンスが提供され、ない場合は、フォローアップ連絡で参照するための登録要求番号とともに、成功確認が表示されます。このページをパーソナライズして、依頼者が追加の連絡に使用できる連絡先詳細などの情報を含めることができます。
内部登録の場合:
- セルフサービス調達ユーザーとしてユーザーまたはサプライヤ管理者は、レスポンシブ・セルフサービス調達またはサプライヤ作業領域にそれぞれナビゲートして、サプライヤのかわりに登録リクエストを発行できます。
- 登録リクエストの発行に必要な情報がすべてない場合は、欠落している情報を保存して返却し、すべての情報の完了後にリクエストを発行できます。
- カテゴリ・マネージャは、ネゴシエーションの作成時に、ソーシング・ワークエリアを介してサプライヤにかわって登録リクエストを発行することもできます。
  
  ノート:
  ネゴシエーション・プロセス中にカテゴリ・マネージャによって送信された内部サプライヤ登録は、クラシック・サプライヤ登録フローです。
登録リクエストを発行すると、購買組織はリクエストを受信し、コラボレーション・レビュー・プロセスを経ます。承認管理サービスを使用すると、登録の承認ルーティングが容易になります。登録承認ルールを保守するには、「設定およびメンテナンス」作業領域で次の場所に移動します:
- オファリング: 調達
- 機能領域: 承認管理
- タスク(外部登録リクエスト用): サプライヤ登録承認の管理
- タスク(内部登録リクエスト用): 内部サプライヤ登録承認の管理
レビュー・プロセス中に、会社名、D-U-N-S番号(指定されている場合)および税金識別子が既存のサプライヤ・マスターに対して検証され、重複するサプライヤが作成されないようになります。
必要な権限を持つ承認者は、承認時に、サプライヤの銀行口座を除き、登録を編集できます。サプライヤ登録のデフォルト承認者は、リクエストの参加依頼調達BUの「サプライヤの管理」機能の調達エージェント表で定義されます。承認ルーティングでは、支出承認者zedサプライヤ登録リクエストに対する見込みサプライヤ登録リクエストまたはサプライヤ・マネージャ・ロールのサプライヤ管理者ロールを持つ調達エージェントが検索され、承認リクエストがルーティングされます。
レビューの結果は承認または否認されます。登録リクエスト結果を含む通知が、外部および内部両方の登録リクエストに対してサプライヤ登録リクエストを発行したユーザーに送信されます。また、外部登録リクエストの場合、この通知は登録の管理担当者としてマークされた担当者に送信されます。
- 承認済: 登録からサプライヤ・レコードを作成するプロセスが自動的に開始されます。登録で担当のユーザー・アカウントが要求された場合は、ユーザー・プロビジョニング要求が処理のためにIdentity Managementシステムに送信されます。見込みサプライヤが承認されると、そのサプライヤはソーシングと資格のトランザクションで使用可能になります。費用承認済サプライヤが承認されると、次のレベルの承認プロセスに対して費用承認承認リクエストが発行されます。
- 否認済: 要求を否認し、要求者に通知を送信します。

この図に、前述の登録フローを示します。調達アプリケーション管理者、潜在的サプライヤ、サプライヤ管理者、内部ユーザー、サプライヤ管理者または調達依頼者によって実行される処理が表示されます。

登録文書には次が含まれます。

会社詳細: 名前、国、税金識別子、組織、サプライヤ・タイプなどの会社詳細を取得します。会社詳細では、国は後続のページでデフォルトを設定する必要があり、これによって国に基づいてUIルール条件を構成することもできます。次に例を示します。
- 国がUSAでない場合は、納税者IDなどのフィールドを非表示にします。
- 国固有の添付インストラクションを表示して、必要な文書のタイプに関するガイダンスを提供します。国以外にも、構成可能な条件をサポートする属性が複数あり、同様の動的なUI動作が可能になります。
- ビジネス要件で、必要に応じて国を指定しない場合は、ページをパーソナライズして、国の必須プロパティを削除できます。
連絡先: 様々なビジネス活動についてバイヤーと関わるすべての担当者の詳細を取得します。担当者では、外部登録で、確認済み電子メールが最初の担当者に対してデフォルト設定されます。携帯電話、電話およびFAXの国コードは、会社詳細ページで選択した国に基づいてデフォルト設定されます。
担当者ユーザー・アカウント: 担当者のユーザー・アカウント情報を取得します。担当者のユーザー・アカウントをリクエストするための選択をデフォルト設定するようにパーソナライズできます。
住所: すべてのサプライヤ住所とそのビジネス・アクティビティの発生元となる目的の詳細を取得します。「住所」では、国を使用して、住所の国と電話およびFAXの国コードがデフォルト設定されます。このページをパーソナライズして、住所目的をデフォルトで選択することもできます。

Loqateスマート・アドレス・サービスは、登録の統合サービスであり、オプト・インすることを強くお薦めします。このサービスは、240か国を超える詳細な住所のロケーションを管理し、データ入力エラーや入力エラーをなくす住所検索を自動的に提案した優れたユーザー・エクスペリエンスを提供します。

事業分類: 適用可能なサプライヤ多様性分類の証明詳細(少数民族所有、中小企業、LGBTQ+所有、障害者所有など)を取得します。
銀行口座: 供給に対する支払を受け取るすべてのサプライヤ銀行口座の詳細を取得します。サプライヤ銀行口座は、国固有の銀行口座属性を提供する国主導のロジックに従います。表示されるデフォルトの国レイアウトは、サプライヤの国に基づいています。シードされる構成は、ほとんどの国で標準で提供されます。

たとえば、米国の銀行口座の場合はルーティング番号が表示され、イギリスのレイアウトではソート・コードが使用されます。国固有のルールを変更または追加して、属性の表示/非表示、必須指定またはラベル変更を行うことができます。国固有のレイアウトを使用して、必要なフィールドにのみ情報を指定する必要があります。

製品およびサービス: 要約カテゴリから、サプライヤが提供できる商品とサービスのタイプを選択します。
質問リスト: サプライヤおよびレスポンシブ・セルフサービス調達作業領域から、外部サプライヤ登録および内部サプライヤ登録の追加登録質問へのレスポンスを取得します。
添付: 会社詳細、事業分類および銀行口座は、これらのページで取得された情報の証明として文書のアップロードをサポートしています。たとえば、会社詳細の添付の場合、サプライヤの税金証明書と銀行口座のスキャン済小切手を取得できます。

構成されている場合、サプライヤ登録承認者は、サプライヤ登録の「会社詳細」セクションに追加されたファイル・タイプ添付の承認通知に自動生成された添付要約を表示できます。

会社および銀行口座の検証に関する厳しいポリシーを実装するために、必要に応じて会社詳細および銀行口座添付を構成できます。ネゴシエーション・プロセス中にソーシング・ワークエリアからカテゴリ・マネージャによって発行されたクラシック内部サプライヤ登録では、銀行口座添付を使用できません。

付加フレックスフィールド: サプライヤ登録プロセス中に会社、担当者および住所の追加情報を取得します。これらの追加情報属性を付加フレックスフィールドとして構成し、パーソナライズを介して有効にして、登録時にそれらの値を取得できます。

サプライヤ登録ビジネス関係

サプライヤとのビジネス関係を開始するには、通常、サプライヤが暫定ステータスになります。暫定的なサプライヤの場合、一般的に、必要となる情報は最小限です。財務トランザクションを行うサプライヤの場合は、さらに多くの情報が必要です。

また、一般的に、見込みサプライヤに対して必要となるレビューと監督のレベルも、契約サプライヤに対して必要になるレベルよりも低くなります。

様々なレベルのサプライヤ情報が必要となる状況に効率的に対処するには、サプライヤに2つのステータスを付与します。暫定的なステータスでは、アプリケーション機能への制限付きアクセス・レベルを許可します。フル・ステータスでは、より広い範囲の機能にアクセスできます。

見込みサプライヤ

サプライヤは、購買会社の登録webページにアクセスして、独立してアプリケーションに登録するか、内部で登録できます。いずれの場合も、登録要求はレビューのためにサプライヤ・マネージャに送信されます。サプライヤ・マネージャが登録要求を承認すると、そのサプライヤはアプリケーション内で見込みサプライヤになります。見込みサプライヤには、制限付きのアクセス・レベルが付与されます。見込みサプライヤはサプライヤ資格イニシアチブに参加し、ネゴシエーションを表示して応答できます。アプリケーション内では、見込みサプライヤは見込みのステータスを示すアイコンで識別されます。

費用承認済サプライヤ

カテゴリ・マネージャがネゴシエーションに応答した見込みサプライヤにビジネスを落札させることを決定した場合、そのサプライヤ向けに購買文書を作成するためには、サプライヤが購買組織との間で費用トランザクションを行うことを承認される必要があります。同様に、支出トランザクションに参加する準備ができている契約済サプライヤは、費用承認済ビジネス関係に登録されます。

費用承認には、サプライヤに関するより詳細なレベルの情報が必要であり、サプライヤ・マネージャの承認も必要となります。サプライヤは、費用処理を行うことを承認されると、アプリケーションのすべての標準機能にアクセスできるようになります。

サプライヤ登録リクエストの管理

「サプライヤ登録要求の管理」ページは、登録の検索、待ち状態の登録のモニター、承認履歴を含むすべての登録データの表示、経過期間登録に対するフォロー・アップに使用します。

サプライヤ・ワークエリアからサプライヤ管理者またはサプライヤ・マネージャとしてこのタスクにアクセスし、アクセス権を持つ登録リクエストにアクセスできます。登録リクエストへのアクセスは、リクエストの参加依頼調達BUのサプライヤ管理機能を持つ調達エージェント・アクセスに基づいて決定されます。

登録リクエストの表示ページには、リクエストのステータスや承認履歴など、登録リクエストの完全な情報が表示されます。「サプライヤ登録リクエストの再送信」権限がある場合は、表示ページを使用して、保留中の承認リクエストの承認プロセスを再開できます。

このページでは、サプライヤの作成を完了したり、サプライヤの作成を取り消すために最終的に修正できるエラーになったリクエストを検索することもできます。

依頼者は登録リクエストを保存できるため、多くの場合、リクエストを発行しない可能性があります。このようなリクエストのステータスは「ドラフト」になり、このページで検索できます。その後、依頼者とフォローアップして完了するか、依頼者から関心がない場合にリクエストを削除できます。

承認処理は、ワークリスト・アプリケーションによりアクセスされる承認要求通知によってのみ実行されます。また、削除アクションは、保存されているが未送信の放棄されたリクエストに対してのみ許可され、承認待ち、承認済み、または却下された他のリクエストは削除できません。