4雇用管理
この章の内容は次のとおりです。
雇用情報の管理
雇用関係: 説明
雇用関係は、個人と雇用主の間の関係です。すべての雇用関係には、1つ以上のアサイメントが含まれる必要があります。
HR担当者は、「個人管理」作業領域から雇用関係を作成および管理できます。
ここで説明する雇用関係の内容は、次のとおりです。
-
雇用関係タイプ
-
非就業者の雇用関係
-
プライマリおよび非プライマリ雇用関係
-
プライマリ雇用関係の終了
-
個人に対する複数の雇用関係の作成
-
就業者タイプ
-
就業者番号
雇用関係タイプ
雇用関係には次のタイプがあります。
-
従業員
-
派遣就業者
-
非就業者
-
処理待ち就業者
雇用関係の作成時に選択した就業者タイプによって、関係タイプが決定されます。
非就業者の雇用関係
非就業者として分類するには、個人が雇用主との間に非就業者雇用関係を持っている必要があります。雇用関係があっても、個人が雇用主のために働いているとはかぎりません。それは、単に個人と、雇用関係およびアサイメントによって定義される雇用主との間に関連があることを意味するにすぎません。
処理待ち就業者の雇用関係
個人の雇用関係を終了する場合、個人レコードはアプリケーション内に保持され、雇用関係は非アクティブになります。後で同じ個人データを入力してこの個人を再雇用すると、アプリケーションではこの個人が重複として識別されます。既存の個人レコードを選択して、個人に対して処理待ち雇用関係を作成できます。
デフォルトでは、処理待ち就業者の雇用関係は非プライマリです。
プライマリおよび非プライマリ雇用関係
就業者または非就業者は、プライマリ雇用関係を1つのみ持つことができます。他のすべての雇用関係は、非プライマリです。個人の初回雇用関係は、デフォルトでプライマリ関係になります。ただし、このルールの例外に処理待ち就業者の雇用関係があり、これはデフォルトで非プライマリとして作成されます。
個人の総合プライマリ・アサイメントは、その個人のプライマリ雇用関係に属します。個人がどれほど多くの雇用関係およびアサイメントを持っていても、場合によっては、1つのアサイメントから個人の情報を取得する必要があります。たとえば、一部の政府報告書は、1つのアサイメントのみに基づきます。このような場合、個人のプライマリ・アサイメントが使用されます。通常、個人のプライマリ雇用関係およびアサイメントは、その個人のステータス、支払、福利厚生および勤務時間に関して最も重要なものです。
プライマリ雇用関係の終了
就業者や非就業者ではなく、雇用関係を終了させます。
個人が複数の現行雇用関係を持っている場合、最初に別のプライマリ関係を選択することなく、プライマリ雇用関係を終了することはできません。この制限が存在する理由は、現在の就業者または非就業者は、プライマリ雇用関係のない期間を持つことができないためです。
アサイメント: 説明
アサイメントは、雇用主の個人のロールに関する情報のセットです。これには、個人のジョブ、ポジション、支払、報酬、勤務時間および事業所が含まれます。
HR担当者は、「個人管理」作業領域からアサイメントを作成および管理できます。ライン・マネージャは、「自分のチーム」作業領域からチーム・メンバーのアサイメントを作成および管理できます。
このトピックでは、アサイメントの次の内容について説明します。
-
アサイメントと雇用関係
-
プライマリ・アサイメント
-
アサイメント番号
-
アサイメント名
-
アサイメント・ステータス
-
契約と労働協約
-
アサイメントの値の継承
アサイメントと雇用関係
すべての雇用関係には、タイプにかかわらず、1つ以上のアサイメントが含まれます。雇用主によっては、1つの雇用関係内に複数のアサイメントが許可されます。
プライマリ・アサイメント
1つのアサイメントから個人に関する情報が必要な場合、それは個人の総合プライマリ・アサイメントによって提供されます。たとえば、一部の政府報告書は、1つのアサイメントのみに基づきます。
各雇用関係で1つのアサイメントをプライマリ・アサイメントとして指定する必要があります。個人が複数の雇用関係を持つ場合、総合プライマリ・アサイメントは、プライマリ雇用関係のプライマリ・アサイメントです。
この例で、アサイメントCは、プライマリ雇用関係のプライマリ・アサイメントであるため、総合プライマリ・アサイメントです。
アサイメント番号
アサイメントは、手動または自動で割り当てることのできるアサイメント番号によって識別されます。手動で番号を割り当てる場合、それらは企業内で一意である必要があります。
アプリケーションでは、個人番号に文字E (従業員)、C (派遣就業者)、N (非就業者)またはP (処理待ち就業者)がプリフィクスとして付けられ、自動割付の番号が作成されます。同じタイプの個人の2番目以降のアサイメントには、サフィクス番号が付けられます。次に例を示します。
-
E45678
-
E45678-2
-
E45678-3
この例の個人番号は45678です。サフィクス番号のシーケンスはグローバルであり、企業内でのアサイメント番号の一意性が保証されます。1人の個人が複数のタイプのアサイメントを持っている場合、アサイメントの番号シーケンスは1から始まります。次に例を示します。
-
N45678
-
N45678-2
アサイメント名
アサイメントには名前があり、アサイメントを識別するための簡単な方法になります。デフォルトでは、アサイメント名はアサイメントに表示されませんが、パーソナライズを使用して、表示されるようにできます。
アサイメント名がどのように移入されるかを次に示します。
-
ユーザーがアサイメント名の値を入力します。
-
ユーザーがアサイメント名の値を入力しない場合、デフォルトでジョブ名がアサイメント名になります。
-
ジョブ名が複数のアサイメントで同じ場合、そのジョブ名にアサイメント順序が付加されます。
-
ユーザーがアサイメント名を入力せず、ジョブ名がない場合、デフォルトでアサイメント番号がアサイメント名になります。
アサイメント名は編集できます。
アサイメント・ステータス
アサイメント・ステータス値によって、アサイメントがアクティブであるか、非アクティブであるか、または一時休止中であるかを判別します。また、アサイメントが給与処理に適格であるかどうかを制御します。
アサイメントを作成または編集する場合、異動を分類する処理を選択しますが、これをレポートおよび分析に使うことができます。一部の処理では、アサイメント・ステータスが自動的に変更されます。たとえば、アサイメントを作成すると、そのステータスは自動的に「アクティブ - 給与適格」に設定されます。それ以外の場合、アサイメント・ステータスを直接設定する必要があります。
契約と労働協約
アサイメントには、一部の雇用主が必要とする契約詳細を含めることができます。契約詳細は、情報目的専用であり、処理に対する影響はありません。「契約更新」処理を使用して、アサイメントに含まれている契約の期間を延長できます。更新期間を指定するか、契約の現在の予定終了日を更新できます。契約詳細で、契約の延長の履歴を参照できます。
労働協約の交渉団体、国および雇用主がアサイメントと一致している場合、労働協約をアサイメントにリンクできます。労働協約を雇用主または交渉団体に関連付けないで作成した場合、その労働協約は、同じ国内の任意のアサイメントにリンクできます。
アサイメントの値の継承
ポジション同期化を使用する場合、アサイメントは、ポジションで指定された属性値を自動的に継承します。企業または雇用主の構成によって、どの属性をポジションから同期化するかと、関連アサイメントの継承値を更新できるかどうかが決定されます。
就業者番号: 説明
就業者番号は、従業員と派遣就業者の雇用関係を識別します(そのため、このような関係を複数持つ個人は、複数の就業者番号を持つことがあります)。
このトピックの内容は、次のとおりです。
-
就業者番号の有効化
-
就業者番号の割当
-
退職後の就業者番号の保持
就業者番号の有効化
就業者番号の使用の決定は、「企業HCM情報の管理」および「法的エンティティHCM情報の管理」タスクを使用して、企業レベルと雇用主レベルで行うことができます。就業者番号を有効にした場合は、従業員と派遣就業者の雇用関係ごとに1つの就業者番号が必要です。就業者番号を有効にしない場合、就業者番号は使用できません。企業レベルと雇用主レベルの両方で就業者番号を使用可能にすると、雇用主での設定が優先します。
就業者番号の割当
就業者番号は次の方法で割り当てることができます。
-
手動
-
グローバル順序を使用して自動
-
雇用主順序を使用して自動
各雇用主は、その雇用関係の番号割当方法を選択します。雇用主で順序を使用する場合、就業者番号は、企業内で一意にならないことがあります。自動的に割り当てられた就業者番号を変更することはできません。
退職後の就業者番号の保持
グローバルで順序を使用するとき、次の場合は就業者番号が変更されません。
-
同じ雇用主に再雇用される場合。
-
別の雇用主に再雇用される場合。
-
別の雇用主にグローバル異動する場合。
雇用主で順序を使用する場合、同じ雇用主に再雇用されると就業者番号は変更されません。ただし、別の雇用主に再雇用されたり、別の雇用主にグローバル異動する場合は、就業者番号が変更されます。
勤務メジャー: 説明
勤務メジャーは、アサイメントでの就業者の時間を計算する方法です。勤務メジャーには、FTEとヘッドカウントという2つのタイプがあります。アサイメントの勤務メジャーは、「個人管理」作業領域の「雇用の管理」タスクを使用して保守します。
FTE
デフォルトでは、FTEは、アサイメント勤務時間を標準勤務時間(通常はフルタイム就業者の勤務時間)で割った結果です。たとえば、アサイメントでの個人の勤務時間が20で、部門の標準勤務時間が40である場合、アサイメントのFTEは0.5です。企業、雇用主、ポジションまたは部門で使用できる標準勤務時間値がない場合、アサイメントはFTE値を持ちません。任意のアサイメントのFTE値を編集できます。
次のいずれかの方法でアサイメント勤務時間を指定できます。
-
固定時間: 「勤務時間」フィールドに1週間の合計時間数を入力します。
-
可変時間: 「アサイメント時間の詳細」ウィンドウで、就業者の毎日の勤務可能性を指定します。そのためには、勤務シフト・タイプとして「時間」を使用して開始時刻と終了時刻を指定するか、「経過」を使用して時間数を指定します。
ヘッドカウント
プライマリ雇用関係でのプライマリ・アサイメントのデフォルトのヘッドカウント値は1です。他のすべてのアサイメントのデフォルトのヘッドカウント値は0です。アサイメントのデフォルトのヘッドカウントは編集できます。
勤務メジャーの使用
Oracle Transactional Business Intelligence (OTBI)を使用して、ヘッドカウント情報とFTEを参照できます。
アサイメントでの複数のマネージャの定義: 例
すべてのアサイメントには、少なくとも1人のマネージャがいます(これはライン・マネージャである必要があります)。ライン・マネージャは、個人のスポットライトおよび他の制限付き就業者情報のライン・マネージャ・バージョンを参照します。マトリックス管理などの代替管理アプローチをサポートするため、個人のアサイメントに他のタイプの追加マネージャを指定できます。ライン・マネージャ以外のマネージャは、そのロールが適切なセキュリティ・アクセスを使用して作成されている場合にのみ、制限付き就業者情報を参照できます。アサイメントは、「個人管理」作業領域の「雇用の管理」タスクを使用して管理します。
マトリックス管理を使用するエンジニアリング会社
エンジニアリング会社の就業者は、全員2人のマネージャ(職務マネージャと業務マネージャ)を持ちます。エンジニアは、主任エンジニアから日常の職務ガイダンスを、業務マネージャからプロジェクトのリーダーシップを提供されます。この例では、主任エンジニアがライン・マネージャであり、このマネージャがチーム・メンバーと最も多く交流し、その評価を実施します。業務マネージャは、関連アサイメントのプロジェクト・マネージャとして指定します。
一時プロジェクト・マネージャを使用するサービス組織
サービス組織は、その就業者をサード・パーティに割り当て、契約サービスを提供するために必要なチームを編成します。会社の各就業者には、ライン・マネージャが1人割り当てられますが、そのタスクの1つは、就業者が自分の次のロールを見つけられるよう助けることです。就業者には、すべてのアサイメントで同じライン・マネージャが割り当てられます。プロジェクトにアサインされると、就業者は一時的なプロジェクト・マネージャも持つようになりますが、このマネージャは特定のアサイメントのみ管理し、その他のアサイメントは管理しません。プロジェクト・マネージャは、関連アサイメントの追加マネージャ(たとえば、プロジェクト・マネージャ)として識別します。
ライン・マネージャと異なる事業所の就業者
グローバル企業は機能によって編成され、就業者は最も適切なライン・マネージャに直属しますが、マネージャのタイム・ゾーンは異なる可能性があります。職務マネージャは、関連アサイメントのライン・マネージャです。費用の承認やローカル条件の施行などの日常の管理を目的として、各就業者には、管理マネージャも割り当てられます。このロールは事業所に依存するため、就業者には、すべてのアサイメントで同じ管理マネージャが割り当てられます。
ポジション階層を使用したアサイメントのライン・マネージャの同期化: 処理方法
ポジション・マネージャまたはHCMポジション階層を使用して、アサイメントのマネージャ値を同期化できます。このトピックでは、HCMポジション階層を使用してアサイメントのライン・マネージャを同期化する方法について説明します。
「雇用の管理」ページには、次の2つのセクションが表示されます。
-
「直属の部下の追加」セクションには、潜在的な直属の部下として子ポジションの在職者が表示されます。
-
「ラインの部下の再割当」セクションには、次の同期化条件に基づいて、現在の直属の部下および提示ライン・マネージャが表示されます。
新規アサイメント
次の処理の実行時に、新規アサイメントを作成し、ポジションを選択できます。
-
採用
-
アサイメントの追加
-
臨時アサイメント
-
雇用主の変更
-
雇用関係の作成
-
グローバル異動
-
グローバル臨時アサイメント
-
ローカル異動およびグローバル異動
前述のトランザクションで、ポジション階層に基づいてライン・マネージャが同期化される場合は、階層内の親ポジションの在職者がアサイメントの新規マネージャになります。
子ポジションの在職者(いる場合)は直属の部下として追加されます。子ポジションに既存のマネージャが存在する場合、この値は無視され、新規マネージャに置換されます。新規マネージャが既存マネージャとして同じポジションに採用される場合、現在のマネージャはそのまま残ります。
既存のアサイメント
既存のアサイメントのポジションを更新すると、「雇用の管理」ページの直属の部下の再割当セクションに直属の部下が表示されます。直属の部下のライン・マネージャは、次の条件に基づいて同期化されます。
-
ポジションに複数の在職者が存在する場合は、他の在職者が新規マネージャになります。
-
ポジションに他の在職者が存在しない場合は、親ポジションの在職者が新規マネージャになります。親ポジションにも在職者が存在しない場合は、在職者が検出されるまで、階層内を1レベルずつ上昇して在職者がチェックされます。
-
親ポジションに複数の在職者が存在する場合は、在職期間が最も長い在職者が新規マネージャになります。
-
親ポジションが存在しない場合、または階層内のすべての親ポジションに在職者が存在しない場合は、直属の部下を他のマネージャに手動で再割当できます。
Peopleグループ・キー・フレックスフィールド: 説明
特定の要素に対する適格性を判断したり、給与などへのアクセスを規制するために、組合や年金プランなどの特別なグループに個人を割り当てることができます。Peopleグループ・キー・フレックスフィールドを使用して、Peopleグループ情報を記録し、組合や作業グループなど、特定のグループに個人を割り当てます。
Peopleグループ・キー・フレックスフィールドの構成
Peopleグループ・キー・フレックスフィールドはオプションです。フレックスフィールドは、企業レベル(「企業HCM情報の管理」タスクを使用)または雇用主レベル(「法的エンティティHCM情報の管理」タスクを使用)で構成できます。このフレックスフィールドは、構成されている場合、人事(HR)担当者が実行するすべてのアサイメントおよび雇用条件関連のトランザクションで表示されます。たとえば、Peopleグループ・キー・フレックスフィールドは、次のページに表示されます。
-
個人の追加
-
雇用関係の作成
-
雇用の管理
また、このフレックスフィールドは、構成されている場合、ライン・マネージャによって実行されるすべてのセルフサービス・トランザクションで表示されます。たとえば、Peopleグループ・キー・フレックスフィールドは、次のマネージャのセルフサービス・ページに表示されます。
-
昇格・昇進
-
異動
-
勤務時間の変更
-
ポートレート
雇用情報の管理に関するFAQ
プライマリ雇用関係とは何ですか。
個人のプライマリ雇用関係は、通常、ステータス、支払、福利厚生および勤務時間に関して個人にとって最も重要な雇用関係です。プライマリ雇用関係には、従業員、派遣就業者または非就業者の雇用関係を使用できます。1つの雇用関係から個人に関する情報が必要な場合、プライマリ雇用関係がソースになります。たとえば、レポート目的で個人の単一の就業者タイプが必要な場合、それはプライマリ雇用関係によって提供されます。個人が企業との間に1つの雇用関係のみを持っている場合、その関係がプライマリ雇用関係になります。
個人のプライマリ雇用関係を変更するとどうなりますか。
新しいプライマリ雇用関係が、その個人の勤務関連情報のメイン・ソースになります。
新しいプライマリ雇用関係のプライマリ・アサイメントは、その個人の総合プライマリ・アサイメントになり、前のプライマリ雇用関係のプライマリ・アサイメントを置き換えます。新しいプライマリ雇用関係に先日付のアサイメントがある場合、プライマリ・ステータスの変更は将来のレコードに伝播されます。
プライマリ雇用関係およびアサイメントに基づく分析情報およびレポートでは、新しいプライマリ雇用関係と総合プライマリ・アサイメントからの情報を使用します。
新しいプライマリ雇用関係のタイプが前のプライマリ雇用関係と異なる場合、個人のメイン就業者タイプが変更されます。たとえば、前のプライマリ雇用関係が従業員であった個人が、後に派遣就業者になるかもしれません。
新しいプライマリ雇用関係を選択すると、前のプライマリ雇用関係は、自動的に非プライマリ雇用関係になります。
雇用関係を取り消すとどうなりますか。
雇用関係が取り消されると、次の処理が自動的に実行されます。
-
雇用関係とそれに関連するすべてのアサイメント、および給与、福利厚生、報酬の各レコードが削除されます。
-
手動または自動を問わず、この雇用関係で個人に割り当てられているロールが削除されます。
-
個人が他の雇用関係または連絡先続柄を持っている場合、雇用関係作成前の個人のステータスが回復されます。
個人の唯一の雇用関係を取り消して、連絡先続柄も存在しない場合、個人レコードは存在し続けますが、その個人は取消済の就業者として識別されます。このようなレコードは、通常の個人検索からは除外されます。ただし、後でその個人を採用したり、その個人を派遣就業者、非就業者または処理待ち就業者として追加すると、アプリケーションによって既存の個人レコードが検出されます。
現在、過去または先日付の退職が含まれる雇用関係を取り消すことはできません。この場合、雇用関係を取り消す前に、退職を取り消す必要があります。雇用関係のいずれかのアサイメントが給与計算に含まれる場合、雇用関係を終了することはできますが、取り消すことはできません。
Personタイプはどこから取得されますか。
Personタイプは、従業員や非就業者など事前定義済システムPersonタイプのサブカテゴリで、ユーザーPersonタイプと呼ばれることもあります。各システムPersonタイプには、デフォルトで、システムPersonタイプと同じ名前の単一のPersonタイプが含まれます。企業では、システムPersonタイプごとに追加のPersonタイプを定義できます。たとえば、システムPersonタイプの非就業者に対して、企業では、Personタイプのインターン、退職(定年他)従業員、ボランティアおよびカウンセラーを定義できます。
PersonタイプのリストにないPersonタイプのアサイメントを作成するにはどうすればよいですか。
欠落しているPersonタイプが就業者タイプに対して有効な場合、Personタイプのリストを更新する必要があります。たとえば、就業者タイプが従業員で、トレーニング生というPersonタイプを使用する場合、その値が従業員Personタイプのリストに表示されている必要があります。
欠落しているPersonタイプが就業者タイプにとって有効ではない場合、新しい雇用関係を作成するか、既存の雇用関係のうち関連するタイプのものを更新する必要があります。たとえば、ボランティアというPersonタイプを使用するには、ボランティアが非就業者として分類される場合、非就業者雇用関係にアサイメントを作成します。
アサイメントを終了できますか。
はい。アサイメントは終了できますが、いくつか制限があります。雇用関係のプライマリ・アサイメントを終了することはできません。この場合、元のアサイメントを終了する前に、別のアサイメントをプライマリ・アサイメントとして指定する必要があります。同様に、雇用関係内の唯一のアサイメントを終了することはできず、かわりにその雇用関係を終了する必要があります。
アサイメントに対して別のライン・マネージャを選択するとどうなりますか。
ユーザーがその個人のライン・マネージャの場合は、指定した日付にアサイメントへのアクセスを失います。たとえば、管理階層にアサイメントが表示されなくなります。個人に対して他のアサイメントを管理していない場合は、個人のスポットライトのラインマネージャ・バージョンにアクセスできなくなります。
さらに、次が適用されます。
-
新しいライン・マネージャは、指定した日付にアサイメントへのアクセスを取得します。たとえば、新しいマネージャは、管理階層にこのアサイメントを表示し、個人のスポットライトのラインマネージャ・バージョンを表示できます。
-
指定した日付から、管理対象の個人は、レポート階層に新しいマネージャの名前、およびこのアサイメントに関する他の情報を表示します。
-
企業で通知が使用されている場合は、新しいライン・マネージャ、管理対象の個人、およびユーザーにこの変更が自動的に通知されます。
アサイメントを作成すると一部の値が自動的に入力されるのはなぜですか。
ポジションを使用する場合、選択したポジションによって、ジョブ、部門、事業所、等級、上限ステップ、給与、給与ベース、試用期間、マネージャ、勤務時間、勤務時間周期、開始時間および終了時間の値は自動的に提供されます。
ポジションを使用しない場合:
-
事業所は、部門から継承されます。
-
標準勤務時間、勤務時間および勤務時間周期は、部門、雇用主または企業から継承されます。部門に指定された値は、雇用主に指定された値を上書きし、雇用主に指定された値は、企業に指定された値を上書きします。
継承値のソース属性を編集しても(たとえば、ポジションの給与ベースを更新するなど)、その変更はアサイメントに自動的にコピーされません。ただし、更新されたソース属性に一致するように継承値を編集できます。
アサイメントでビジネス・ユニットを変更する場合、組織、ジョブ、ポジション、等級およびジョブ値は、自動的にNULLに設定されます。
非アクティブなアサイメントにアクセスするにはどうすればよいですか。
「雇用の管理」ページの「雇用ツリー」を使用して、個人の雇用関係およびアサイメントのアクティブと非アクティブを切り替えます。
別の方法として、個人の現在の非アクティブなアサイメントを見つけるため、個人を検索できます。個人検索によって、個人の現在のアサイメントがそのステータスにかかわらずすべて戻されます。
退職のためにアサイメントが非アクティブになっている場合、拡張検索のオプションを選択して、検索結果に終了済雇用関係を含める必要があります。そうしないと、終了済雇用関係の非アクティブなアサイメントは、検索結果に表示されません。
派遣就業者の契約情報を追加できますか。
はい。構成した雇用モデルで契約がサポートされている場合は可能です。次のタスクを使用して派遣就業者の契約情報を管理できます。
-
派遣就業者の追加
-
処理待ち就業者の追加
-
処理待ち就業者の編集
-
雇用の管理
-
アサイメントの追加
-
臨時アサイメントの追加
-
グローバル異動
-
グローバル臨時アサイメント
-
雇用関係の作成
勤務時間と標準勤務時間の違いは何ですか。
通常、標準勤務時間は、フルタイム就業者の勤務時間です。これらは、企業、雇用主、部門またはポジションに対して定義します。
勤務時間は、デフォルトでは標準勤務時間と同じであり、アサイメントに対して定義されます。アサイメントに対して「時間」または「経過」のいずれかのタイプの勤務時間を定義できます。「時間」を選択した場合は、開始時刻と終了時刻を指定して、就業者の勤務可能性を日別に決定できます。「経過」を選択した場合は、各曜日の時間数を指定できます。
2つの値は同じままになる場合があります。たとえば、従業員が部門の標準勤務時間で勤務している場合、標準勤務時間と勤務時間は同じです。パートタイム就業者の場合、通常は標準勤務時間と勤務時間に差異があります。差異がある場合は、アサイメントに対する勤務時間を更新します。
勤務メジャーを編集する必要があるのはどのような場合ですか。
通常、デフォルトの勤務メジャーはアサイメントに自動的に割り当てられるため、勤務メジャーを編集する必要はありません。ただし、デフォルト値が表示されない場合は、FTE値を入力する必要がある場合があります。勤務メジャーを編集するための指示はローカルで発行されます。たとえば、企業では、非プライマリ・アサイメントに対して、ゼロより大きいヘッドカウント値を入力するよう指示する場合があります。
年功起算日の管理
年功起算日の管理: 概要
この項のすべてのトピックは、年功起算日機能のバージョン3 (V3)に関連しています。年功起算日機能のバージョン3を使用して就業者の年功を定義および管理できます。
「年功起算日の構成」タスクおよびFastFormulaを使用して、V3年功起算日を構成できます。要件に従って複数の年功起算日を構成し、「年功起算日の管理」タスクを使用して管理できます。
詳細は、次のホワイト・ペーパーを参照してください。
-
My Oracle Support (https://support.oracle.com)の『異なる年功起算日バージョンの比較』(2414630.1)。
-
My Oracle Support (https://support.oracle.com)の『年功起算日バージョン1のよくある質問』(2434532.1)。
-
My Oracle Support (https://support.oracle.com)の『年功起算日バージョン2』(2438572.1)。
年功起算日: 説明
年功起算日は、企業、部門、等級またはその他のエンティティでの個人の年功の計算の基になる日付です。ほとんどの場合、年功起算日は、開始日と同じになりますが、別個の年功起算日を使用して、開始日とは別にそれらを管理できます。
年功日の管理: 説明
年功起算日は、「年功起算日の管理」タスクを使用して管理します。
「年功起算日の管理」ページでは、各年功起算日の勤続期間、履歴およびその他の詳細情報を表示できます。また、年功起算日ルールが編集を許可するように構成されている場合、手動調整ユニットを更新または修正することで年功を調整できます。手動調整は、整数または小数を使用して入力できます。たとえば、調整済年功時間数を20時間または18.5時間と入力できます。
個人の年功を調整した後、「年功の再計算」機能を使用することによって、年功を再計算できます。すべての就業者の年功日を移入する場合は、「年功日の計算」バッチ・プロセスを実行します。
年功日の計算: 例
次の例は、アサイメント変更および雇用関係変更を基準とした年功日の計算を示しています。
この例では、ジョブ年功日は、次の年功日レベルで構成されています。
-
個人
-
雇用関係
-
アサイメント
アサイメント変更を基準とした場合
Vijay Singhは、2005年1月1日に雇用主Vision INDに採用されます。彼は企業内で複数のアサイメントおよび雇用関係を持っています。次の表に、そのデフォルトの年功日の概要を示します。
| 日付 | 処理 | 雇用主 | アサイメント | ジョブ | 部門 |
|---|---|---|---|---|---|
|
2005年1月1日 |
採用 |
Vision IND |
アサイメント1 |
営業コンサルタント |
ERP |
2006年1月1日時点での年功計算:
| 年功起算日レベル | ジョブ | 年功 | 年功起算日 | 終了日 |
|---|---|---|---|---|
|
ジョブ-個人レベル |
営業コンサルタント |
1年 |
2005年1月1日 |
N/A |
|
ジョブ - 雇用関係レベル |
営業コンサルタント |
1年 |
2005年1月1日 |
N/A |
|
ジョブ-アサイメント・レベル |
営業コンサルタント |
1年 |
2005年1月1日 |
N/A |
2007年1月1日から、VijayにはHCM部門の新しいアサイメントが設定されますが、引き続き同じジョブを実行します。現在のアサイメントは終了します。
| 日付 | 処理 | 雇用主 | アサイメント | ジョブ | 部門 |
|---|---|---|---|---|---|
|
2005年1月1日 |
採用 |
Vision IND |
アサイメント1 |
営業コンサルタント |
ERP |
|
2007年1月1日 |
アサイメントの終了 |
Vision IND |
アサイメント1 |
営業コンサルタント |
ERP |
|
2007年1月1日 |
アサイメントの追加 |
Vision IND |
アサイメント2 |
営業コンサルタント |
HCM |
2008年1月1日時点での年功計算:
| 年功起算日レベル | ジョブ | 年功 | 年功起算日 | 終了日 |
|---|---|---|---|---|
|
ジョブ-個人レベル |
営業コンサルタント |
3年 |
2005年1月1日 |
N/A |
|
ジョブ - 雇用関係レベル |
営業コンサルタント |
3年 |
2005年1月1日 |
N/A |
|
ジョブ-アサイメント・レベル |
営業コンサルタント(アサイメント1) |
2年 |
2005年1月1日 |
2006年12月31日 |
|
ジョブ-アサイメント・レベル |
営業コンサルタント(アサイメント2) |
1年 |
2007年1月1日 |
N/A |
雇用関係変更を基準とした場合
2010年1月1日付けで、Vijayのアサイメントは新しい雇用主にグローバル異動されます。ただし、引き続き同じHCM部門に属します。
| 日付 | 処理 | 雇用主 | アサイメント | ジョブ | 部門 |
|---|---|---|---|---|---|
|
2005年1月1日 |
採用 |
Vision IND |
アサイメント1 |
営業コンサルタント |
ERP |
|
2007年1月1日 |
アサイメントの終了 |
Vision IND |
アサイメント1 |
営業コンサルタント |
ERP |
|
2007年1月1日 |
アサイメントの追加 |
Vision IND |
アサイメント2 |
営業コンサルタント |
HCM |
|
2010年1月1日 |
グローバル異動 |
InFusion US |
アサイメント3 |
営業コンサルタント |
HCM |
2011年1月1日時点での年功計算:
| 年功起算日レベル | ジョブ | 年功 | 年功起算日 | 終了日 |
|---|---|---|---|---|
|
ジョブ-個人レベル |
営業コンサルタント |
6年 |
2005年1月1日 |
N/A |
|
ジョブ - 雇用関係レベル |
営業コンサルタント(Vision IND) |
5年 |
2005年1月1日 |
2009年12月31日 |
|
ジョブ - 雇用関係レベル |
営業コンサルタント(InFusion US) |
1年 |
2010年1月1日 |
N/A |
|
ジョブ-アサイメント・レベル |
営業コンサルタント(アサイメント1) |
2年 |
2005年1月1日 |
2006年12月31日 |
|
ジョブ-アサイメント・レベル |
営業コンサルタント(アサイメント2) |
3年 |
2007年1月1日 |
2009年12月31日 |
|
ジョブ-アサイメント・レベル |
営業コンサルタント(アサイメント3) |
1年 |
2010年1月1日 |
N/A |
累積年功日の計算: 例
年功を累積的に計算するように年功日ルールを構成できます。次の例は、累積年功および非累積年功を基準とした年功日の計算を示しています。
この例では、ジョブ年功日は、次の年功日レベルで構成されています。
-
個人
-
雇用関係
-
アサイメント
累積年功を基準とした場合
この例は、Priya Krishnanの年功日の計算を示しています。彼女は企業内で複数のアサイメントおよび雇用関係を持ち、3つのジョブ年功日のすべてに対して累積オプションが有効化されています。
Priya Krishnanは、2005年1月1日に雇用主Vision INDに採用されます。次の表に、そのデフォルトの年功日の概要を示します。
| 日付 | 処理 | 雇用主 | アサイメント | ジョブ | 部門 |
|---|---|---|---|---|---|
|
2005年1月1日 |
採用 |
Vision IND |
アサイメント1 |
営業コンサルタント |
ERP |
2006年1月1日時点での年功計算:
| 年功起算日レベル | ジョブ | 年功 | 年功起算日 | 終了日 |
|---|---|---|---|---|
|
ジョブ-個人レベル |
営業コンサルタント |
1年 |
2005年1月1日 |
N/A |
|
ジョブ - 雇用関係レベル |
営業コンサルタント |
1年 |
2005年1月1日 |
N/A |
|
ジョブ-アサイメント・レベル |
営業コンサルタント |
1年 |
2005年1月1日 |
N/A |
2007年1月1日付けで、Priya Krishnanは現在のアサイメントの中でジョブ異動になります。
| 日付 | 処理 | 雇用主 | アサイメント | ジョブ | 部門 |
|---|---|---|---|---|---|
|
2005年1月1日 |
採用 |
Vision IND |
アサイメント1 |
営業コンサルタント |
ERP |
|
2007年1月1日 |
ジョブ変更 |
Vision IND |
アサイメント1 |
ビジネス・アナリスト |
ERP |
2008年1月1日時点での年功計算:
| 年功起算日レベル | ジョブ | 年功 | 年功起算日 | 終了日 |
|---|---|---|---|---|
|
ジョブ-個人レベル |
営業コンサルタント |
2年 |
2005年1月1日 |
2006年12月31日 |
|
ジョブ - 雇用関係レベル |
営業コンサルタント |
2年 |
2005年1月1日 |
2006年12月31日 |
|
ジョブ-アサイメント・レベル |
営業コンサルタント |
2年 |
2005年1月1日 |
2006年12月31日 |
|
ジョブ-個人レベル |
ビジネス・アナリスト |
1年 |
2007年1月1日 |
N/A |
|
ジョブ - 雇用関係レベル |
ビジネス・アナリスト |
1年 |
2007年1月1日 |
N/A |
|
ジョブ-アサイメント・レベル |
ビジネス・アナリスト |
1年 |
2007年1月1日 |
N/A |
2008年1月1日付けで、Priya Krishnanには別の部門の新しいアサイメントが設定されます。ただし、ジョブは以前と同じ営業コンサルタントに戻ります。現在のアサイメントは終了します。
| 日付 | 処理 | 雇用主 | アサイメント | ジョブ | 部門 |
|---|---|---|---|---|---|
|
2005年1月1日 |
採用 |
Vision IND |
アサイメント1 |
営業コンサルタント |
ERP |
|
2007年1月1日 |
ジョブ変更 |
Vision IND |
アサイメント1 |
ビジネス・アナリスト |
ERP |
|
2008年1月1日 |
アサイメントの終了 |
Vision IND |
アサイメント1 |
ビジネス・アナリスト |
ERP |
|
2008年1月1日 |
アサイメントの追加 |
Vision IND |
アサイメント2 |
営業コンサルタント |
HCM |
2009年1月1日時点での年功計算:
| 年功起算日レベル | ジョブ | 年功 | 年功起算日 | 終了日 |
|---|---|---|---|---|
|
ジョブ-個人レベル |
営業コンサルタント |
2年 |
2005年1月1日 |
2006年12月31日 |
|
ジョブ - 雇用関係レベル |
営業コンサルタント |
2年 |
2005年1月1日 |
2006年12月31日 |
|
ジョブ-アサイメント・レベル |
営業コンサルタント(アサイメント1) |
2年 |
2005年1月1日 |
2006年12月31日 |
|
ジョブ-個人レベル |
ビジネス・アナリスト |
1年 |
2007年1月1日 |
2007年12月31日 |
|
ジョブ - 雇用関係レベル |
ビジネス・アナリスト |
1年 |
2007年1月1日 |
2007年12月31日 |
|
ジョブ-アサイメント・レベル |
ビジネス・アナリスト(アサイメント1) |
1年 |
2007年1月1日 |
2007年12月31日 |
|
ジョブ-個人レベル |
営業コンサルタント |
3年 |
2008年1月1日 |
N/A |
|
ジョブ - 雇用関係レベル |
営業コンサルタント |
3年 |
2008年1月1日 |
N/A |
|
ジョブ-アサイメント・レベル |
営業コンサルタント(アサイメント2) |
1年 |
2008年1月1日 |
N/A |
非累積年功を基準とした場合
この例は、Priya Krishnanの年功日の計算を示しています。彼女は企業内で複数のアサイメントおよび雇用関係を持ち、3つのジョブ年功日のすべてに対して累積オプションが無効化されています。
Priya Krishnanは、2005年1月1日に雇用主Vision INDに採用されます。次の表に、そのデフォルトの年功日の概要を示します。
| 日付 | 処理 | 雇用主 | アサイメント | ジョブ | 部門 |
|---|---|---|---|---|---|
|
2005年1月1日 |
採用 |
Vision IND |
アサイメント1 |
営業コンサルタント |
ERP |
2006年1月1日時点での年功計算:
| 年功起算日レベル | ジョブ | 年功 | 年功起算日 | 終了日 |
|---|---|---|---|---|
|
ジョブ-個人レベル |
営業コンサルタント |
1年 |
2005年1月1日 |
N/A |
|
ジョブ - 雇用関係レベル |
営業コンサルタント |
1年 |
2005年1月1日 |
N/A |
|
ジョブ-アサイメント・レベル |
営業コンサルタント |
1年 |
2005年1月1日 |
N/A |
2007年1月1日付けで、Priya Krishnanは現在のアサイメントの中でジョブ異動になります。
| 日付 | 処理 | 雇用主 | アサイメント | ジョブ | 部門 |
|---|---|---|---|---|---|
|
2005年1月1日 |
採用 |
Vision IND |
アサイメント1 |
営業コンサルタント |
ERP |
|
2007年1月1日 |
ジョブ変更 |
Vision IND |
アサイメント1 |
ビジネス・アナリスト |
ERP |
2008年1月1日時点での年功計算:
| 年功起算日レベル | ジョブ | 年功 | 年功起算日 | 終了日 |
|---|---|---|---|---|
|
ジョブ-個人レベル |
営業コンサルタント |
2年 |
2005年1月1日 |
2006年12月31日 |
|
ジョブ - 雇用関係レベル |
営業コンサルタント |
2年 |
2005年1月1日 |
2006年12月31日 |
|
ジョブ-アサイメント・レベル |
営業コンサルタント |
2年 |
2005年1月1日 |
2006年12月31日 |
|
ジョブ-個人レベル |
ビジネス・アナリスト |
1年 |
2007年1月1日 |
N/A |
|
ジョブ - 雇用関係レベル |
ビジネス・アナリスト |
1年 |
2007年1月1日 |
N/A |
|
ジョブ-アサイメント・レベル |
ビジネス・アナリスト |
1年 |
2007年1月1日 |
N/A |
2008年1月1日付けで、Priya Krishnanには別の部門の新しいアサイメントが設定されます。ただし、ジョブは以前と同じ営業コンサルタントに戻ります。現在のアサイメントは終了します。
| 日付 | 処理 | 雇用主 | アサイメント | ジョブ | 部門 |
|---|---|---|---|---|---|
|
2005年1月1日 |
採用 |
Vision IND |
アサイメント1 |
営業コンサルタント |
ERP |
|
2007年1月1日 |
ジョブ変更 |
Vision IND |
アサイメント1 |
ビジネス・アナリスト |
ERP |
|
2008年1月1日 |
アサイメントの終了 |
Vision IND |
アサイメント1 |
ビジネス・アナリスト |
ERP |
|
2008年1月1日 |
アサイメントの追加 |
Vision IND |
アサイメント2 |
営業コンサルタント |
HCM |
2009年1月1日時点での年功計算:
| 年功起算日レベル | ジョブ | 年功 | 年功起算日 | 終了日 |
|---|---|---|---|---|
|
ジョブ-個人レベル |
営業コンサルタント |
2年 |
2005年1月1日 |
2006年12月31日 |
|
ジョブ - 雇用関係レベル |
営業コンサルタント |
2年 |
2005年1月1日 |
2006年12月31日 |
|
ジョブ-アサイメント・レベル |
営業コンサルタント(アサイメント1) |
2年 |
2005年1月1日 |
2006年12月31日 |
|
ジョブ-個人レベル |
ビジネス・アナリスト |
1年 |
2007年1月1日 |
2007年12月31日 |
|
ジョブ - 雇用関係レベル |
ビジネス・アナリスト |
1年 |
2007年1月1日 |
2007年12月31日 |
|
ジョブ-アサイメント・レベル |
ビジネス・アナリスト(アサイメント1) |
1年 |
2007年1月1日 |
2007年12月31日 |
|
ジョブ-個人レベル |
営業コンサルタント |
1年 |
2008年1月1日 |
N/A |
|
ジョブ - 雇用関係レベル |
営業コンサルタント |
1年 |
2008年1月1日 |
N/A |
|
ジョブ-アサイメント・レベル |
営業コンサルタント(アサイメント2) |
1年 |
2008年1月1日 |
N/A |
時間ベースの年功計算の例
この例では、HR担当者として、企業年功起算日を個人レベルで構成します。就業者の勤続期間を計算するために、時間ベースの年功ルールを定義しています。時間換算ルールの定義は次のとおりです。
-
1日は8時間、1週間は40時間
-
1か月は173.33時間(1年の時間数を12で除算)
-
1年は2080時間、1年は52週
時間ベースの年功ルールを使用して、就業者Maya Singhの勤続期間を計算する方法を見てみましょう。Mayaは時給の従業員で、勤務時間は年功時間数表(PER_SENIORITY_HOURS)に毎週入力されます。
Mayaは、2007年1月1日に雇用主Vision INDに採用されます。
| 日付 | 処理 | 雇用主 | アサイメント | ジョブ | 部門 |
|---|---|---|---|---|---|
|
2007年1月1日 |
採用 |
Vision IND |
アサイメント1 |
営業コンサルタント |
ERP |
1週間後の年功
ルールを適用すると、Mayaの年功は週末の2007年1月7日で40時間です。
| 開始日 | 終了日 | 年功時間数 |
|---|---|---|
|
2007年1月1日 |
2007年1月7日 |
40 |
年功の計算方法は次のとおりです。
| 勤続期間 | 年功時間数合計 | 勤続期間の計算方法 |
|---|---|---|
|
0年0か月5日 |
40 |
年功時間数合計は1か月に定義された時間数(173.33)を下回ります。したがって、勤続期間の計算時に、年功時間数合計は日数に換算されます。勤続期間の日単位での計算は、40を8 (1日の時間数)で割ります。 |
6か月後の年功
Mayaの年功は、6か月後の2007年7月7日時点で1080時間です。
年功の計算方法は次のとおりです。
| 勤続期間 | 年功時間数合計 | 勤続期間の計算方法 |
|---|---|---|
|
0年6か月5日 |
1080 |
年功時間数合計は1年に定義された時間数(2080)を下回りますが、1か月に定義された時間数(173.33)を上回ります。 最初に月数が計算され、年功時間数合計 - (月数 * 月に定義された時間数) < 月に定義された時間数となります。 したがって、このシナリオの月数は6です。等式で値を使用すると、1080 - (6 * 173.33) = 40 (173.33を下回る)となります。残りの40時間については、日換算が行われ、5日(40を8で除算)になります。したがって、最終的な勤続期間は0年6か月5日です。 |
1年6か月後の年功
Mayaの年功は、1年6か月後の2008年7月7日時点で3160時間です。
年功の計算方法は次のとおりです。
| 勤続期間 | 年功時間数合計 | 勤続期間の計算方法 |
|---|---|---|
|
1年6か月5日 |
3160 |
年功時間数合計は1年に定義された時間数(2080)を上回ります。 最初に年数が計算され、年功時間数合計 - (年数 * 年に定義された時間数) < 年に定義された時間数となります。 したがって、このシナリオの年数は1です。等式で値を使用すると、3160 - (1 * 2080) = 1080 (2080を下回る)となります。残りの1080時間については、月換算が行われ、6か月になります。次に、日換算が行われ、5日となります。 |
「年功日の計算」プロセス: 説明
「年功日の計算」プロセスを使用すると、アプリケーションに構成されている年功ルールに基づいて就業者の年功日を計算できます。プロセスをスケジュールして実行するには、「スケジュール済プロセス」作業領域を使用します。
プロセス・パラメータ
個人番号: このパラメータは、処理のためにESSプロセスに含める個人番号をフィルタ処理します。複数の個人を対象としてこのプロセスを実行する場合は、個人番号をカンマで区切って入力します。たとえば、「個人番号1,個人番号2,個人番号3」のような形式を使用します。先頭または末尾のスペースや特殊文字を入力しないでください。すべての個人を対象としてこのプロセスを実行する場合は、何も値を入力しません。
「年功起算日コード」リスト: このパラメータは、ESSプロセスを実行する必要がある年功起算日ルールをフィルタ処理します。パラメータをNullとして渡すと、アプリケーション内のすべてのアクティブなルールに対してESSプロセスが実行されます。
過去N日間: このパラメータは、個人のデータが変更された最後の日数を示します。このパラメータは、次の表をスキャンしてデータ変更を検索します。
-
PER_ALL_ASSIGNMENTS_M
-
PER_ASSIGN_GRADE_STEPS_F
-
PER_SENIORITY_HOURS
このパラメータは、これらの表のLAST_UPDATE_DATE列を分析し、処理のためにパラメータで渡された日数と比較します。
雇用主: このパラメータは、指定された雇用主に基づいて個人レコードをフィルタ処理します。
組合: このパラメータは、指定された組合に基づいて個人レコードをフィルタ処理します。
終了済雇用関係を含む: このパラメータは、雇用関係のステータスをチェックします。値Yをパラメータとして渡すと、現在アクティブな雇用関係が検出されます。非アクティブな雇用関係のデータを変更し、値Nを渡すと、アプリケーションではこの雇用関係のアサイメントが処理されません。この動作は、過去N日間にアサイメント・レコードが変更されている場合でも発生します。
年功起算日の管理に関するFAQ
「年功起算日の管理」ページで個人に表示されない年功ルールがあるのはなぜですか。
年功ルールがその個人に適用されないか、年功ルールによって、個人の勤続期間がnullと計算されたためです。
時間ベースの年功の計算で使用される年功時間数のソースは何ですか。
ソースはPER_SENIORITY_HOURS表にロードされた時間です。
年功時間数表に時間をロードするにはどうすればよいですか。
HCMデータ・ローダーを使用します。詳細は、Help Center (https://docs.oracle.com/en/cloud/saas/index.html)で『Oracle Human Capital Management Cloud HCMとの統合』を参照してください。
時間ベースの年功の計算時にアサイメントまたは標準勤務時間を使用できますか。
いいえ。時間ベースの年功を計算するには、HCMデータ・ローダーを使用してPER_SENIORITY_HOURS表に時間をロードする必要があります。
職責範囲
職責範囲: 説明
個人に職責を割り当て、その個人が職責を持って対応する別の個人を指定することで職責のスコープを定義できます(その個人は、別の個人の「勤務連絡先」リストに表示されます)。たとえば、特定の組織または部門階層の個人に対する人事(HR)担当者として就業者を割り当てることができます。職責範囲は、「個人管理」作業領域の「職責範囲の管理」タスクを使用して管理します。
職責範囲の割当は、担当者が参照できる個人レコードに影響を与えません。レコードへのアクセスはセキュリティを使用して制御されます。セキュリティ管理者は、職責範囲を使用してセキュリティ・プロファイルを設定できます。
スコープの重複
同じ職責を複数の個人に割り当てると、スコープ間で重複が発生する可能性があります。たとえば、個人AにHR担当者の職責を割り当て、組織階層を使用して職責のスコープを定義するとします。次に、個人BにHR担当者の職責を割り当て、上長階層を使用してスコープを定義します。一部の就業者は両方の階層に表示されるため、スコープが重複します。これらの就業者は、AとBの両方が自分のHR担当者になります。この結果を望まない場合、異なる情報の組合せを指定してスコープを再定義できます。
チェックリストとの統合
チェックリストで使用する職責を作成して割り当てることができます。チェックリスト・テンプレートを作成するときに、タスク実行者の職責を指定します。チェックリストの割当時に、選択された職責を持つ個人がタスク実行者として自動的に導出および指定されます。
機密トランザクションとの統合
職責を機密トランザクションと組み合せて使用し、機密退職に関する通知の受信者を指定できます。特定の先日付の退職は、機密として指定され、適切な時期まで非公開にされることがあります。機密退職に関するすべての矛盾は、HR担当者の職責を持つ個人に処理をルーティングすることで対応されます。
職責のスコープの設定: 例
職責のスコープは複数の方法で設定できます。以下の各例で、これらのオプションについて説明します。職責範囲は、「個人管理」作業領域で管理します。
アサイメント情報基準
Vision社は、アメリカとイギリスに事務所を置くソフトウェア会社です。Gail Williamsは、イギリスのレディングを勤務地とするアプリケーション開発者の人事(HR)担当者です。GailにHR担当者の職責を割り当て、職責のスコープを定義します。スコープの設定によって、担当している個人が識別されます。スコープを定義するには、次の表に示されているフィールドに値を入力します。
| フィールド | 値 |
|---|---|
|
ビジネス・ユニット |
Vision Applications Development |
|
雇用主 |
Vision UK |
|
国 |
UK |
|
事業所 |
Reading |
|
ジョブ |
Applications Developer |
名前基準
Terry Smithは、イギリスVision社の就業者グループの福利厚生担当者です。彼は、アルファベット範囲内(AからL)の就業者に対する職責を持っています。Terryに福利厚生担当者の職責を割り当て、職責のスコープを定義します。スコープの設定によって、担当している個人が識別されます。スコープを定義するには、次の表に示されているフィールドに値を入力します。
| フィールド | 値 |
|---|---|
|
雇用主 |
Vision UK |
|
姓の最初の文字 |
A |
|
姓の最後の文字 |
L |
給与情報基準
Grace Millerは、アメリカVision社の外部トレーニング・スタッフの給与担当者です。Graceに給与担当者の職責を割り当て、職責のスコープを定義します。スコープの設定によって、担当している個人が識別されます。スコープを定義するには、次の表に示されているフィールドに値を入力します。
| フィールド | 値 |
|---|---|
|
法定ユニット |
Vision Training US |
|
国別仕様データ・グループ |
External Training |
職責範囲に関するFAQ
個人の職責範囲を記録しないとどうなりますか。
個人は、その個人が職責範囲を持って対応する別の個人の「勤務連絡先」リストに表示されません。
職責を再割当するとどうなりますか。
職責は、再割当された個人の関連アサイメント・レコードで即時に表示されます。職責の「日付: 自」は現在の日付になり、「日付: 至」は設定されません。職責が削除される個人のアサイメント・レコードでは、「日付: 至」が現時点で存在しない場合、現在の日付が「日付: 至」フィールドに追加されます。それ以外の場合、既存の「日付: 至」がそのまま残されます。
職責のスコープは、同じままです。レコードが次回表示されるときに、影響を受ける個人の「勤務連絡先」リストに変更が表示されます。
採用職責タイプとは何ですか。
採用職責を個人に割り当てて職責のスコープを定義すると、特定の採用属性に基づいてジョブ求人を保護できます。このような属性には、ジョブ・ファミリ、ジョブ機能、採用事業所階層、採用組織階層および採用タイプがあります。
勤務スケジュール・アサイメントの管理の運用管理
就業者スケジュール: 決定方法
選択した期間中の就業者のスケジュールは、次の要素を使用して自動的に決定されます。
-
就業者が現在使用しているスケジュールまたは勤務時間
-
カレンダ・イベントおよび勤務スケジュール・リソース例外
-
その期間中の休暇欠勤エントリ
就業者スケジュールの決定方法
アプリケーションでは、次の順序を使用して、就業者のアサイメントに適用されるスケジュールを決定します。
| 順序 | スケジュール・ソース | スケジュール・コンテンツ |
|---|---|---|
|
1 |
公開済ワークフォース管理(WFM)スケジュール |
就業者スケジュールはWFMスケジュールです。WFMスケジュールには、デフォルトで、すべての勤務週および勤務スケジュールの設定、標準勤務時間、カレンダ・イベント、リソース例外および休暇欠勤が含まれます。 |
|
2 |
雇用勤務週 |
就業者の雇用レコード、カレンダ・イベントおよび休暇欠勤で構成された勤務週。 |
|
3 |
これらのレベルの1つに割り当てられた勤務スケジュール(指定された順序)。プライマリ・スケジュールが見つかるとすぐに停止します
|
勤務スケジュール、カレンダ・イベント、リソース例外および休暇欠勤。 |
|
4 |
就業者のプライマリ・アサイメントに対して定義された標準勤務時間 |
標準勤務時間、カレンダ・イベントおよび休暇欠勤。 |
|
5 |
デフォルト時間の午前8時30分から午後5時 |
デフォルト時間、カレンダ・イベントおよび休暇欠勤 |
次の図は、就業者のスケジュールの決定方法を視覚的に示しています。
例
次のシナリオでは、プライマリ勤務スケジュールをどこで定義するかに応じて、就業者のスケジュールがどのように変化するかを示します。
| シナリオ | 結果 |
|---|---|
|
企業レベルでプライマリ勤務スケジュールを割り当てました。この企業の特定の部門に属する就業者は、異なる勤務時間に従っているため、その部門には異なるプライマリ勤務スケジュールを割り当てました。 |
部門レベルのスケジュールは企業レベルで定義されているスケジュールよりも優先されるため、部門レベルのプライマリ勤務スケジュールによって就業者のスケジュールが決まります。 |
|
同じ例で、同じ部門に属する就業者(プライマリ・アサイメント)にプライマリ勤務スケジュールを割り当てました。 |
就業者レベルで定義したプライマリ勤務スケジュールは、他のレベルで定義された勤務スケジュールよりも優先されます。 |
次の図は、2つのシナリオの視覚的に示しています。
プライマリ勤務スケジュールに存在するカレンダ・イベントおよびリソース例外と、選択した期間中の休暇欠勤は、就業者のスケジュールに影響します。
勤務スケジュールの例外: 説明
勤務スケジュールを作成するときに、祝日やトレーニング・セッションなどの例外を含めることができます。その後、そのスケジュールを使用して就業者勤務可能状況に対する影響を判別できます。次のいずれかの例外を勤務スケジュールに含めます。
| 例外タイプ | コメント |
|---|---|
|
カレンダ・イベント |
1日の1つのイベントの例外、または祝日やトレーニング・イベントなど、複数の日にわたる例外。 |
|
カレンダ・イベント・カテゴリ |
イギリスのすべての祝日など、イベント・カテゴリを構成するすべてのカレンダ・イベントの例外。 |
|
リソース例外 |
勤務スケジュールに関連付けられたすべての就業者の例外。たとえば、夜勤シフト・スケジュールに関連付けられたすべての就業者は、トレーニング・イベントに出席するようにスケジュールされ、通常の勤務には対応できません。 「勤務期間」例外は、表示オプション「雇用スケジュール」と「自分のスケジュール」のいずれかまたは両方が有効になっている場合、「時間」作業領域カレンダに表示されます。「非勤務期間」例外は表示されません。 |
勤務スケジュールの作成と割当: 作業例
この例では、シフト、パターンおよびカレンダ・イベントで構成される勤務スケジュールを作成して割り当てる方法について説明します。この勤務スケジュールはインドのサポート部門のもので、そのカレンダ年が対象となります。この部門には、週に2つのシフトがあります。日勤シフトは月曜日から水曜日の午前9時から午後5時までです。夜勤シフトは木曜日から金曜日の午後5時から午前1時までです。勤務スケジュールは、日勤シフトで始まります。すべてのサポート就業者はすべての祝日に適格です。この例では、1名のサポート就業者Vijay Singhが、2月8日の上級コミュニケーション・スキル・トレーニングに出席するようにスケジュールされています。その勤務スケジュールには、その日に勤務不可であることが示される必要があります。
タスク要約
この基本プロセスを使用して、勤務スケジュールを作成して割り当てます。
-
Public Holidayカテゴリ内にカレンダ・イベントを作成します。
-
日勤シフトおよび夜勤シフトを作成します。
-
日勤シフトおよび夜勤シフトで構成される週間勤務パターンを作成します。
-
週間勤務パターンとカレンダ・イベント・カテゴリの例外、Public Holidayで構成される勤務スケジュールを作成します。
-
この勤務スケジュールをSupport IN部門に割り当てます。
-
この勤務スケジュールをVijay Singhに割り当て、トレーニング中に勤務不可であることを示すトレーニング・カレンダ・イベント例外を追加します。
前提条件
次のタスクが完了していることを確認します。タスクは、「設定および保守」作業領域の「ワークフォース配置」オファリングの「ワークフォース情報」機能領域にあります。-
企業に対して作成した地理的階層にインドの国ノードが含まれることを確認します。地理ツリーの管理タスクを使用して、国ノードが存在することを確認するか、または国ノードを作成します。
-
Support_Workers適格プロファイルが存在し、サポート部門内のすべての就業者が識別されることを確認します。「適格プロファイルの管理」タスクを使用して、プロファイルが存在することを確認するか、またはプロファイルを作成します。
カレンダ・イベントの作成
「設定および保守」作業領域の「ワークフォース配置」オファリングの「ワークフォース情報」機能領域を使用して、このタスクを実行します。-
「ワークフォース情報」セクションで「カレンダ・イベントの管理」をクリックします。
-
「カレンダ・イベントの管理」ページで、「作成」をクリックします。
-
「カレンダ・イベントの作成」ページで、次の表に示されているフィールドに値を入力します。
フィールド 値 名前
Gandhi Jayantiなど、祝日の名前
カテゴリ
Public Holiday
開始日
祝日が開始される日付(10月2日午前12時など)
終了日
祝日が終了する日付(10月2日午後11時59分など)
短縮コード
祝日を識別するコード(GANJAYなど)
階層タイプ
地理的
階層
企業用に作成した地理的階層(企業事業所など)
-
選択した地理的階層を表示する「カバレッジ」セクションで、階層を展開し、「インド」ノードを選択します。
-
「含める」をクリックします。
-
「送信」をクリックします。
-
「確認」ダイアログ・ボックスで、「OK」をクリックします。
-
他のカレンダ・イベントを追加するには、手順2から7を繰り返します。
-
「完了」をクリックします。
シフトの作成
-
「ワークフォース情報」セクションで「勤務シフトの管理」をクリックします。
-
次の手順を2回実行してシフトを2つ作成します。
-
「勤務シフトの管理」ページの「作成」アイコン・メニューで「時間シフトの作成」を選択します。
-
「時間シフトの作成」ダイアログ・ボックスで、次の表に示されているように1つのシフトのフィールドに値を入力します。
フィールド 日勤シフト値 夜勤シフト値 名前
日勤シフト
夜勤シフト
開始時間
午前9時
午後5時
期間
8時間
8時間
シフト詳細タイプ
なし
なし
-
「保存してクローズ」をクリックします。
-
-
「勤務シフトの管理」ページで「完了」をクリックします。
勤務パターンの作成
-
「ワークフォース情報」セクションで「就業勤務パターンの管理」をクリックします。
-
「就業勤務パターンの管理」ページの「作成」アイコン・メニューで「時間稼働日パターンの作成」を選択します。
-
「時間稼働日パターンの作成」ダイアログ・ボックスで、次の表に示されているようにフィールドに値を入力します。
フィールド 値 名前
Weekly Work Pattern
長さ(日数)
7
-
次の手順を2回実行して、稼働日パターン詳細を2つ追加します。
-
「稼働日パターン詳細」セクションで、「行の追加」アイコンをクリックします。
-
次の表に示すように、1つのパターンのフィールドを入力します。
フィールド 日勤シフト値 夜勤シフト値 開始日
1
4
終了日
3
5
シフト名
日勤シフト
夜勤シフト
-
-
「保存してクローズ」をクリックします。
-
「就業勤務パターンの管理」ページで「完了」をクリックします。
勤務スケジュールの作成
-
「ワークフォース情報」セクションで「勤務スケジュールの管理」をクリックします。
-
「勤務スケジュールの管理」ページで、「作成」をクリックします。
-
「勤務スケジュールの作成」ページで、次の表に示されているように一般フィールドに値を入力します。
フィールド 値 名前
サポート用勤務スケジュール
カテゴリ
勤務
タイプ
時間
有効開始日
現在の年の1月1日
有効終了日
現在の年の12月31日
-
次の表に示すようにフィールドに入力して、パターンを追加します。
フィールド 値 順序
1
名前
Weekly Work Pattern
-
次の表に示すようにフィールドに入力して、例外を追加します。
フィールド 値 タイプ
カレンダ・イベント・カテゴリ
名前
Public holiday
-
Support_Workers適格プロファイルを追加します。
-
「送信」をクリックします。
-
「勤務スケジュールの管理」ページで、「完了」をクリックします。
部門への勤務スケジュールの割当
-
「ワークフォース情報」セクションで「勤務スケジュール割当の管理の運用管理」をクリックします。
-
「勤務スケジュール割当の管理の運用管理」ページで、「サポート用勤務スケジュール」を検索してクリックします。
-
「勤務スケジュール割当管理の編集: サポート用勤務スケジュール」ページの「リソース・アサイメント」セクションで、「行の追加」アイコンをクリックします。
-
次の表に示すように、フィールドに情報を入力します。
フィールド 値 リソース・タイプ
部門
名前
Support IN
開始日
現在の年の1月1日
終了日
現在の年の12月31日
プライマリ
はい
-
「送信」をクリックします。
-
「確認」ダイアログ・ボックスで、「OK」をクリックします。
-
「勤務スケジュール割当の管理の運用管理」ページで、「完了」をクリックします。
就業者の勤務スケジュールの変更
-
ナビゲータ→「個人管理」をクリックします。
-
「個人管理: 検索」ページで、Vijay Singhなどの就業者を検索してクリックします。
-
「タスク」パネル・タブで、「勤務スケジュール割当の管理」をクリックします。
-
「勤務スケジュール割当の管理」ページで、「行の追加」アイコンをクリックします。
-
次の表に示されているように、「スケジュール」セクションのフィールドに値を入力します。
フィールド 値 名前
サポート用勤務スケジュール
開始日
現在の年の1月1日
終了日
現在の年の12月31日
プライマリ
はい
-
「例外」セクションで、「行の追加」アイコンをクリックします。
-
次の表に示すように、フィールドに情報を入力します。
フィールド 値 タイプ
リソース例外
名前
選択リストで「作成」をクリックします。2月8日に開始し、同じ日に終了するAdvanced Communication Skillsというリソース例外を作成します。
勤務可能性
休暇期間
-
「送信」をクリックします。
勤務スケジュール・アサイメントの管理の運用管理に関するFAQ
プライマリ勤務スケジュールとは何ですか。
アプリケーションが就業者の勤務可能性を決定するために使用するスケジュールです。
プライマリ・スケジュールによってのみ、就業者の勤務可能性は決定されます。たとえば、就業者のプライマリ・アサイメントに異なる期間の2つのスケジュールを割り当てるとします。それらのスケジュールで各期間の就業者の勤務可能性を決定する場合、両方のスケジュールをプライマリとして選択する必要があります。勤務スケジュールは、「個人管理」作業領域の「勤務スケジュール割当の管理」タスクを使用して管理します。
1つの勤務スケジュールのみを割り当てる場合、そのスケジュールによって自動的に就業者勤務可能状況が決定されます。
カレンダ・イベントが就業者に影響するのはいつですか。
そのイベントを勤務スケジュールに例外として含め、それを就業者のアサイメントにプライマリ勤務スケジュールとして割り当てたときです。ただし、就業者のアサイメントに勤務スケジュールが存在しない場合、就業者の事業所または部門を対象とするカレンダ・イベントが適用されます。
個々の就業者の勤務スケジュールの例外を変更するにはどうすればよいですか。
「勤務スケジュール割当の管理」ページを使用して就業者にスケジュールを割り当てる場合、例外によるその就業者の勤務可能性に対する影響を変更できます。たとえば、すべての就業者に影響を与える例外としてカレンダ・イベントを追加したとします。特定の就業者は、重要な顧客問合せを処理できるよう勤務可能である必要があるため、その就業者のその例外に対する勤務可能性を変更します。