ヘッダーをスキップ

Oracle Self-Service Human Resourcesセルフ・サービス機能実装ガイド
リリース11i
B25738-01		目次へ
目次		前のページへ
戻る		次のページへ
次へ

承認

承認の概要

SSHR機能を定義するときは、人事システムの表に発行する前に、その機能に承認が必要かどうかを決定できます。様々なトランザクションに異なる承認要件を定義し、その承認要件を必要に応じて変更できます。たとえば、個人情報の住所部分には承認が必要で、電話番号部分には承認が不要になるようにワークフロー・プロセスを構成できます。また、承認要件は、従業員が変更したレコードは承認が必要で、マネージャが変更した場合は承認が不要になるように職責別に変更できます。

SSHRで使用されるすべての承認メカニズムは、基本承認ループに従っています。ロジックによって、現行承認者が階層内の最終承認者であるかどうかが確認されます。現行承認者が最終承認者でない場合は、承認通知を受け取る次の承認者が取り出されます。次の承認者は、該当するトランザクションを否認、承認、再割当するか、または訂正するように承認チェーン内のユーザーに送信できます。承認者は、システムの構成に応じて、トランザクションを更新することもできます。

テキストで説明されている画像

承認プロセス内では、ルールを使用して、SSHRトランザクションの承認者リストが生成されます。リストの生成方法は、使用している承認メカニズムによって異なります（「SSHRでの承認」を参照してください）。

アプリケーションでは、デフォルトで動的承認が使用されます。動的承認機能は、次の内容で構成されています。

動的承認ワークフロー・プロセスでは、承認者リストで識別された承認者と通知受信者に通知が送信されます。

SSHRでの承認機能

SSHRにセキュリティ保護された承認ツールはありますか?

あります。Oracle SSHRでは、Oracle Approvals Management（AME）またはPL/SQLパッケージとともに動的承認を使用して、セキュリティ保護された承認環境を提供します。

SSHRで承認に対してカスタマイズ可能なPL/SQLパッケージとAMEの両方を使用する理由は何ですか?

SSHR 4.1までは、SSHRでの承認の定義に、カスタマイズ可能なPL/SQLパッケージが使用されていました。ただし、SSHR 4.1から提供された機能では、標準としてOracle Approvals Management（AME）が使用されています。AMEのかわりに、対応するセルフ・サービス機能の構成によって動的承認の使用を選択できますが、今後のリリースで他の承認タイプがサポートされない可能性があるため、すべての承認にAMEを使用することをお薦めします。

Oracle Approvals Managementを使用する利点は何ですか?

Oracle Approvals Managementを使用すると、承認プロセスを制御するためのビジネス・ルールを定義できます。企業の要件を満たす承認プロセスを定義するために、条件、ルールおよび属性を定義できます。たとえば、昇給が一定の金額を超える場合のみ特定のユーザーからの承認を必要とするプロセスを作成できます。また、特定のビジネス・プロセスに対する承認プロセスを設定できます。

要件にあわせて承認チェーンを構成できますか?

構成できます。特定の承認者またはマネージャを含めるように承認プロセスを構成できます。特定のユーザーが承認通知を受信するように指定することもできます。動的承認を使用している場合は、Oracle Workflow Builderを使用してプロセスを構成できます。

Oracle Approvals Managementを使用するために別のライセンスが必要ですか?

必要ありません。いずれかのアプリケーション・ライセンスを購入している場合は、Oracle Approvals Managementが組み込まれています。

承認

SSHRでの承認

SSHR機能の承認インタフェースは、導入している承認タイプに応じて異なります。SSHRのリリース4.1からは、提供されているすべてのSSHR機能に対する承認ロジックの定義と管理に、Oracle Approvals Management（AME）が使用されています。SSHRバージョン4以上を使用するすべてのカスタム機能を備えたAMEも使用できます。

関連項目: Oracle Approvals Management（AME）の導入

すべてのSSHR機能に対してOracle Approvals Management（AME）を使用することをお薦めしますが、次の代替機能もすべて使用できます。

Oracle Approvals Management（AME）構成

Oracle Approvals Management（AME）は、Oracle Workflowと統合されたWebベースのアプリケーションです。このアプリケーションを使用すると、承認プロセスを制御するビジネス・ルールを定義できます。

AMEとともに次のコンポーネントを使用して、承認プロセスを定義します。これらのコンポーネントは、特定のアプリケーションのトランザクション・タイプに関連付けられています。

AMEで使用されるコンポーネントの詳細は、『Implementing Oracle Approvals Management』（Metalink Note #227391.1）を参照してください。

SSHRにおけるデフォルトのAME構成の使用

Oracle SSHRには、PL/SQLパッケージで提供される機能をエミュレートするAME構成が用意されています。この構成では、AMEルールを使用した管理者ベースの承認階層が提供されます。

デフォルトのAME構成は、次のように構成されています。

SSHRの標準AME属性

Oracle SSHRには、承認プロセスの定義に役立つ次のAME属性が用意されています。

属性 説明
HR_TRANSACTION_CREATION_DATE_SS トランザクション作成日。
HR_IS_CHANGE_PAY_SS 支払指定の変更が含まれます。
HR_IS_ASSIGNMENT_CHANGE_SS アサイメント・データの変更が含まれます。
HR_IS_SUPERVISOR_CHANGE_SS 管理者の変更が含まれます。
HR_IS_TERMINATION_SS 退職の変更が含まれます。
HR_IS_LEAVE_OF_ABSENCE_SS 不就業の変更が含まれます。
HR_TERMINATION_REASON_SS 退職理由。
HR_LENGTH_OF_SERVICE_IN_YEARS_SS 勤続期間（年数）。
HR_PROPOSED_JOB_ID_SS 提示役職のID。
HR_PROPOSED_POSITION_ID_SS 提示職階のID。
HR_PROPOSED_GRADE_ID_SS 提示等級のID。
HR_PROPOSED_LOCATION_ID_SS 提示勤務地のID。
HR_PROPOSED_PAYROLL_ID_SS 提示給与のID。
HR_ASSIGNMENT_CHANGE_REASON_SS 提示アサイメントの変更理由。
HR_ASSIGNMENT_CATEGORY_SS 提示アサイメント・カテゴリのID。
HR_APPRAISAL_TYPE_SS 評価タイプ。
HR_SELECTED_PERSON_ID_SS 選択した個人のID。
HR_PAY_PERCENT_CHANGE_SS 支払指定の変更（パーセント）。
HR_PAY_AMOUNT_CHANGE_SS 支払指定の変更（金額）。
HR_PAY_BASIS_ID_SS 給与ベースのID。
HR_SELECTED_PERSON_PROPOSED_SUP_ID_SS 提示管理者のID。
HR_IS_PERSON_BASIC_DETAILS_CHANGE_SS 基本詳細の変更が含まれます。
HR_IS_SELECTED_PERSON_ADDRESS_CHANGE_SS アドレスの変更が含まれます。
HR_IS_SELECTED_PERSON_CONTACT_CHANGE_SS 契約の変更が含まれます。
HR_IS_RELEASE_INFORMATION_SS リリース情報の変更が含まれます。
WORKFLOW_PROCESS_NAME ワークフロー・プロセス名。
CURRENT_ASSIGNMENT_ID 現在のアサイメントのID。
CURRENT_EFFECTIVE_DATE 現在の有効日。
HR_PROPOSED_SALARY_BASIS_SS 提示給与ベース。
HR_ABSENCE_TYPE_ID_SS 不就業タイプのID。
HR_IS_MID_PAY_PERIOD_SS 期間中の支払指定変更が含まれます。

SSHRにおける属性の使用の詳細は、『Implementing Oracle Approvals Management』（Metalink Note #227391.1）を参照してください。

AMEにおけるSSHR承認レベルの構成

ビジネス・ニーズを満たすためには、提供されているSSHRMSトランザクション・タイプ内にルール、条件または属性を追加したり、カスタム・トランザクション・タイプを定義することができます。

AMEのルール、条件および属性の構成の詳細は、『Implementing Oracle Approvals Management』（Metalinkから入手可能）を参照してください。

提供されているAME構成に多少の変更を加えることは比較的簡単です。次に例を示します。

すべてのSSHRワークフロー・プロセスに対して異なる承認レベルを定義する場合

特定のワークフロー・プロセスに対して異なる承認レベルを定義する場合

新規承認レベルを定義する場合（提供された承認が要件と一致しない場合）

最終承認者（最終権限）として特定のユーザーを定義する場合（そのユーザーが承認チェーンでの最終ユーザーでない場合でも）

AMEが提供する構成オプションの詳細は、『Implementing Oracle Approvals Management』（Metalinkから入手可能）を参照してください。

AMEに関連する機能パラメータの詳細は、「提供されている機能」を参照してください。

機能パラメータの説明は、「メニュー機能パラメータの説明」を参照してください。

承認オプションの詳細

保留中のトランザクションの更新許可

承認者は、自分で処理を更新することも、訂正のために承認チェーン上の受信者に処理を差し戻すこともできます。ただし、更新機能は次の2つの構成に依存します。

保留中のトランザクションを更新する承認者には、処理を編集できる適切なロール・タイプが指定されたワークフロー・ロールが必要です。これによって、承認者は、承認チェーン内の位置に関係なく処理を更新できます。

保留中のトランザクションを更新する承認者の機能は、提供された2つのロール・タイプ（「SSHR更新許可」と「SSHR更新不可」）によって制御されます。これらのロール・タイプは、相互に組み合せて使用せず、処理が簡単なほうを使用してください。

ロール・タイプにロールを関連付けるには、「ロールの保守」ウィンドウを使用します。

人事担当者への処理のルーティング

人事担当者に処理をルーティングできます。処理は、シードされている人事担当者ロール・タイプに関連付けられたロールを持つすべての個人に送信されます。このロール・タイプにロールを関連付けるには、「ロールの保守」ウィンドウを使用します。

最初の人事担当者が、人事すべてを代表して処理を実行します。これは、個人のレコードに関する先日付の変更が、アプリケーションで検出された場合に特に便利です。「SSHRでの日付の管理」の先日付処理に関する説明を参照してください。

承認後の更新の遅延

デフォルトでは、データベースへのSSHRトランザクションの保存は、最終承認の後に、遅延されます。これは、最終承認者が「承認」ボタンをクリックしてから次の通知に進むまでの間を遅延させないためです。

トランザクションは、ワークフロー・バックグラウンド・プロセスの実行時に自動的に保存されます。システム管理者は、このプロセスを必要に応じて定期的に実行するようにスケジュールする必要があります。

ワークフロー・バックグラウンド・プロセスを実行するときは、次のパラメータを設定する必要があります。

関連項目: 『Oracle Applicationsシステム管理者ガイド』の要求の発行に関する説明

トランザクションが最終承認後すぐに保存されるように、デフォルトの動作を変更する必要がある場合は、ユーザー/職責/アプリケーション/サイト・レベルで、「HR: 承認後に更新遅延」システム・プロファイルを「No」に設定します。

関連項目: 『Oracle HRMSユーザーズ・ガイド（日本仕様）』のユーザー・プロファイルに関する説明

PL/SQLによる承認変更のサンプル・コード

必要な場合は、check_final_approver関数とget_next_approver関数のロジックを検討し、必要に応じてその内容を変更できます。これらの関数はHR_APPROVAL_CUSTOMパッケージにあります。

戻り値が正しいデータ型であることを確認してください。

次のコードは、承認機能のロジックを示しています。必要な場合、このコードは、異なる承認のルーティングを使用するように、または異なる等級レベルで停止するようにカスタマイズできます。 

??--        -Check_final_approver

function check_final_approver

           (p_forward_to_person_id in per_people_f.person_id%type

           ,p_person_id            in per_people_f.person_id%type)
         return varchar2 is
--
  cursor csr_pa(l_effective_date in date) is

    select  paf.person_id

    from    per_all_assignments_f paf

    start   with paf.person_id = p_person_id

      and     paf.primary_flag = 'Y'

      and     l_effective_date

      between paf.effective_start_date

      and     paf.effective_end_date

    connect by prior paf.supervisor_id = paf.person_id

      and     paf.primary_flag = 'Y'

      and     l_effective_date

      between paf.effective_start_date

      and     paf.effective_end_date;

--

  l_person_id per_people_f.person_id%type := null;

--

begin

  -- loop through each row. the rows are returned in an order which makes

  -- the last row selected the top most node of the chain.

  for csr in csr_pa(trunc(sysdate)) loop

    -- set the l_person_id variable to the row fetched

    l_person_id := csr.person_id;

  end loop;

  if p_forward_to_person_id = l_person_id then

    return('Y');

  else

    return('N');

  end if;

exception

  when others then

       return('E');

--

end check_final_approver;
()

-        -Get_next_approver

function get_next_approver

           (p_person_id in per_people_f.person_id%type)

         return per_people_f.person_id%type is

--

  cursor csr_pa(l_effective_date in date

               ,l_in_person_id   in per_people_f.person_id%type) is

    select  ppf.person_id

    from    per_all_assignments_f paf

           ,per_people_f      ppf

    where   paf.person_id             = l_in_person_id

    and     paf.primary_flag          = 'Y'

    and     l_effective_date

    between paf.effective_start_date

    and     paf.effective_end_date

    and     ppf.person_id             = paf.supervisor_id

    and     ppf.current_employee_flag = 'Y'

    and     l_effective_date

    between ppf.effective_start_date

    and     ppf.effective_end_date;

--

  l_out_person_id per_people_f.person_id%type default null;

--

begin

  -- [CUSTOMIZE]

  -- open the candidate select cursor

  open csr_pa(trunc(sysdate), p_person_id);

  -- fetch the candidate details

  fetch csr_pa into l_out_person_id;

  if csr_pa%notfound then
    -- if the cursor does not return a row then we must set the out

    -- parameter to null

    l_out_person_id := null;

  end if;

  -- close the cursor

  close csr_pa;

  return(l_out_person_id);

end get_next_approver;
()

PL/SQLの使用方法の詳細は、『Oracle Applications開発者ガイド』のアプリケーションにおけるPL/SQLの使用方法の概要に関する説明を参照してください。

Oracle Approvals Management（AME）の導入

SSHRの機能を使用する前に、AMEで構成する必要のある設定がいくつかあります。

また、リリース4.1より前に作成されたカスタム機能では、デフォルトの承認メカニズムとしてカスタマイズ可能なPL/SQLパッケージが使用されます。ただし、SSHRのカスタム機能は、2つの新規の機能パラメータを追加することで、AMEを指し示すように変更できます。

注意: AMEのルールと条件は、承認に適用する他のワークフロー属性設定（レビュー・アクティビティに対する属性設定など）より常に優先されます。あるワークフロー・プロセスについて、「承認要」ワークフロー属性が「Yes」に設定されているが、AMEから承認者が戻らない場合、そのプロセスは承認不要で完了します。一般的な設定の推奨事項として、現在承認不要となっているプロセスは、次のように設定する必要があります。

その後、プロセスへの承認者の追加が必要になった場合は、単純に別のAME条件を使用できます。

SSHRにAMEを設定する手順

  1. AME管理者職責を使用して、次の変数の値が「Yes」であることを確認します。

  2. Oracle Workflow Builderを使用して、ワークフロー・プロセスの通知アクティビティにタイムアウト値を設定します。

    関連項目: 『Oracle Workflow開発者ガイド』のプロセス内のノードの定義に関する説明

    関連項目: 『Oracle Workflow開発者ガイド』のタイムアウトのトランジションに関する説明

  3. カスタム・ワークフロー・プロセスを作成した場合は、Oracle Workflow Builderを使用して、既存の通知プロセスを新規プロセスの「承認者および通知者の通知プロセス」に置換します。

    関連項目: 『Oracle Workflow開発者ガイド』のプロセスの図示に関する説明

カスタム機能をAMEにリンクする手順

追加の機能パラメータは、「フォーム機能」ウィンドウで定義します。Oracle Workflow Builderを使用して、ワークフロー・プロセスのワークフロー属性を確認する必要もあります。

  1. 機能を問い合せます。

  2. 「フォーム」タブ・リージョンにナビゲートします。

  3. 機能の「パラメータ」フィールドに、次のパラメータ情報を追加します。

  4. 作業内容を保存します。

カスタム・ワークフロー・プロセスを、SSHRMS AMEトランザクション・タイプに対する条件属性の値リストに追加する手順（提供されたSSHRトランザクション・タイプを使用する場合は必須）

  1. Oracle Approvals Managementにログインします。

    注意: 次のAME職責のいずれかを使用する必要があります（AMEは、Oracle Approvals Managementに対するOracleの内部的な略語です）。

  2. SSHRMSトランザクション・タイプを選択します。

  3. 「条件」タブを選択して、WORKFLOW_PROCESS_NAME条件をクリックします。

  4. 「テキスト値の追加」ボタンを選択し、属性値として新規のワークフロー・プロセス名を入力します。

  5. 作業内容を保存します。

技術的な情報

ワークフロー・プロセス

注意: AME.A以上を使用しない場合、ワークフロー・プロセスは次のようになります。

構成可能なワークフロー属性

プロセス名 機能名 属性名 説明
参考通知プロセス 通知 メッセージ名 通知のメッセージ名を指定します。トランザクションの発行時や承認時などに送信される通知に対して、個別のメッセージを作成できます。
参考通知プロセス 通知 拡張ロール 複数のユーザーで構成されているロールにこの通知を割り当て、そのロールの各ユーザーに対してこの通知の個別のコピーを送信するには、「Yes」を選択します。「No」を選択すると、通知の1つのコピーのみがロール全体に対して提供されます。
参考通知プロセス 通知 実行者 通知の送付先のロールです。定数のロール名、または実行時にロールを動的に決定する項目タイプ属性を選択できます。

構成可能なプロファイル・オプション

ユーザーが保留中のトランザクションを更新できるかどうかを制御するプロファイル・オプションの詳細は、「承認オプションの詳細」を参照してください。

Oracle Workflow Builderでの承認の構成

Oracle Approvals Management（AME）を使用していない場合は、Oracle Workflow Builderで事前定義の承認プロセスを構成します。この承認プロセスは、ワークフロー属性を使用して設定します。

注意: 承認は、カスタマイズ可能なPL/SQLパッケージではなく、AMEを使用することをお薦めします。

Oracle Workflow Builderで承認を構成する手順

  1. ワークフロー項目タイプを開きます。

  2. 変更するプロセスにナビゲートしてダブルクリックし、ワークフロー・ダイアグラムを開きます。

  3. ワークフロー・プロセスのレビュー・ページ・アクティビティを開きます。

    注意: 正しいレビュー・ページ・アクティビティを検索するには、いくつかのサブプロセスをドリルダウンする場合があります。

  4. プロセスと影響を受けるサブプロセスのコピーを作成します。たとえば、個人情報プロセスの承認を変更する場合は、個人情報プロセスとその関連サブプロセス（基本詳細プロセス・サブプロセスなど）をコピーする必要があります。

    関連項目: ワークフロー・オブジェクトの更新

  5. プロセス/サブプロセスのレビュー・ページ・アクティビティを選択し、承認が必要なワークフロー属性（HR_APPROVAL_REQ_FLAG）を「Yes」に設定します。これによって、プロセス/サブプロセスに対する承認が有効になります。

    注意: デフォルト値は、モジュールによって異なります。

    関連項目: レビューおよび確認

  6. プロセスを承認チェーン全体にわたって通過させる方法、つまり、必要な承認レベルの数を決定します。承認レベル属性（HR_DYNAMIC_APPROVAL_LEVEL）を使用して承認レベルを設定します。承認レベル値を「デフォルト値」フィールドに追加します。たとえば、値1を入力すると、承認は1レベル上の管理者チェーンを通過します。

    注意: デフォルトのレベルは0（ゼロ）です。これは、レベル数に制限がないことを意味します。

  7. 作業内容を保存します。

目次   |   戻る   |   先頭へ   |   次へ

Oracleロゴ
Copyright © 2002, 2006, Oracle. All rights reserved.