1. HCMとの統合
  2. 就業者のロード

9 就業者のロード

この章の内容は次のとおりです。

就業者のロード: 概要

就業者オブジェクトには、個人とその雇用関係に関連するすべての情報が含まれます。このトピックでは、就業者をロードするときに適用される、いくつかの一般的な考慮事項について説明します。

就業者階層

「データ・ロードの開始」ページで就業者オブジェクトを選択して、そのコンポーネント階層をレビューします。

ソース・キーの使用方法

ユーザー・キーのみを指定する場合、就業者階層の多くのコンポーネントは更新できません。この制限が存在するのは、変更対象の属性が、レコードの識別に使用される属性であるためです。たとえば、個人住所コンポーネントでは、更新する住所の識別と新しい値の指定の両方にAddressLine1属性が使用されます。そのため、常に、就業者を作成するときにソース・キーを指定して、就業者レコードを更新するときにそれらを使用することをお薦めします。

コンポーネントの複数のインスタンス

個人は、個人住所、個人電話番号、個人Eメールなどの一部のコンポーネントのインスタンスを複数持つことができます。個人に関するコンポーネントの複数のインスタンスをロードする場合、次のことを行う必要があります。

  • コンポーネントのPrimaryFlag属性を使用して、レコードの1つをプライマリとして指定します。

  • オカレンスを同時に処理して、ファイルに親就業者コンポーネントを含めます。就業者がOracle HCM Cloudにすでに存在する場合は、就業者のプライマリ・キー属性のみを含めることができます。

雇用モデル

雇用関係とアサイメントをロードする雇用主の雇用モデルを理解する必要があります。一般的に、雇用モデルは、雇用条件をサポートする3階層とサポートしない2階層のいずれかにすることができます。雇用主には、「雇用モデル」オプションを次のいずれかの値に設定できます。

  • 2階層 - 単一アサイメント

  • 2階層 - 複数アサイメント

  • 2階層 - 単一契約 - 単一アサイメント

  • 3階層 - 単一雇用条件 - 単一アサイメント

  • 3階層 - 単一雇用条件 - 複数アサイメント

  • 3階層 - 複数雇用条件 - 単一アサイメント

  • 3階層 - 複数雇用条件 - 複数アサイメント

たとえば、2階層雇用モデルが実装された雇用主に雇用条件をロードしようとすると、失敗します。また、個人に複数の雇用関係またはアサイメントをロードするときに、PrimaryFlag属性を使用して、どれがプライマリであるかを指定する必要があります。個人が持つプライマリ雇用関係と、各雇用関係のプライマリ・アサイメントは、一度に1つのみである必要があります。

参照値の定義

就業者オブジェクトの多くのコンポーネントにはPersonタイプやアサイメント・ステータスなどの値があり、これらはターゲット環境に存在する必要があります。データをロードする前に、次の表に示すタスクを実行して、関連する値を定義します。

タスク 説明

処理の管理

変更を雇用データに分類するために使用される処理を定義します

Personタイプの管理

従業員や非就業者などの、事前定義済のPersonタイプのサブカテゴリを定義します

アサイメント・ステータスの管理

アクティブ、非アクティブ、停止などの、アサイメントのステータス値を定義します

さらに、就業者をロードする前に、住所タイプ、電話タイプ、エスニシティ、婚姻区分などの値リストをレビューして更新しておく必要があります。このステップは、実装中に実行済である場合があります。ポジションからアサイメントを同期化する場合は、アサイメントをロードする前にポジション同期化を有効にする必要があります。

就業者退職

就業者ではなく、雇用関係を終了します。HCMデータ・ローダーを使用して雇用関係を終了すると、アサイメント・コンポーネントなどのその子コンポーネントが自動的に終了します。個人名などの、就業者オブジェクトの他の子コンポーネントを終了しようとしないでください。個人レコードは引き続き存在し、検索結果などで戻される必要があります。

.datファイルの例の確認

就業者オブジェクトのロード方法を示す.datファイルの例は、My Oracle Support (https://support.oracle.com)の『HCMデータ・ローダー: 就業者のロード』(文書ID 2022624.1)を参照してください。

関連トピック

新規就業者のロード: 考慮する点

就業者オブジェクト階層は、多数のコンポーネントと階層レベルがあり、複雑です。就業者を作成する場合(特に、大量に作成する場合)、最初に必須コンポーネントのみをロードすることをお薦めします。就業者オブジェクトが存在するようになると、給与やエレメント・エントリなど、関連するオブジェクトをロードできます。このトピックでは、就業者を作成するときにロードする必要があるコンポーネントと、状況によってロードする必要があるコンポーネントを示しています。就業者オブジェクトが存在するようになると、オプションの就業者コンポーネントをロードできます。

就業者オブジェクトの必須コンポーネントのロード

HCMデータ・ローダーを使用して就業者を作成するときに、就業者オブジェクトの次のコンポーネントを指定します。

  • 就業者

  • 個人国別仕様データ

  • 個人名

  • 雇用関係

  • 雇用条件(雇用主が3階層雇用モデルをサポートしている場合)

  • アサイメント

必要に応じて、各就業者に対して、有効日履歴を含めます。

注意: 就業者のStartDate属性とEffectiveStartDate属性の値は、両方とも就業者の最早の雇用関係の開始日と同じになる必要があります。

個人国別仕様データのロード

個人国別仕様データは、就業者を作成する場合の必須コンポーネントではありません。ただし、これを含めて、ソース・キー値を指定することをお薦めします。そうしない場合、コンポーネントがデフォルトのソース・キー値で自動的に作成されます。

アサイメント・マネージャのロード

就業者を正常にロードした後にのみ、アサイメント・マネージャ・コンポーネントをロードして、マネージャ関係を作成します。このアプローチでは、参照されるマネージャの就業者レコードが、アサイメント・マネージャ・コンポーネントで参照する前に存在するようになります。

契約のロード

次の雇用モデルのいずれかを使用している場合は、契約詳細を指定できます。

  • 3階層

  • 2階層で、単一の契約とアサイメントを含む

必要に応じて、就業者の作成時に、契約コンポーネントを指定する必要があります。契約コンポーネントは、後でロードできません。

ユーザーおよびロールのロード

企業オプション「ユーザー・アカウント作成」により、一括してロードされた就業者に対してユーザー・アカウントが自動的に作成されるかどうかが制御されます。ただし、ユーザー情報コンポーネントのGeneratedUserAccountFlag属性を含めてNに設定することによって、個々の就業者に対してユーザー・アカウントが作成されるのを禁止できます。ユーザー情報コンポーネントのUserName属性でユーザー名を指定することもできます。そうしない場合、企業のデフォルトの形式でユーザー名が自動的に生成されます。次の属性または属性ペアのいずれかを設定すると、既存のユーザー・アカウントを就業者にリンクするように試行されます。

  • UserGUID

  • UserNameおよびUsernameMatchingFlag

  • EmailAddressおよびEmailMatchingFlag

現在のロール・プロビジョニング・ルールで指定したとおりに、ロールが新しいユーザーに自動的にプロビジョニングされます。ロールを新しい就業者に手動で割り当てるには、就業者オブジェクトとともに個人ユーザー手動ロール・コンポーネントを含めます。

注意: ユーザー情報コンポーネントと個人ユーザー手動ロール・コンポーネントは、新しい就業者の作成時にのみ指定できます。就業者が存在するようになったら、ユーザー・オブジェクトとそのユーザー・ロール・コンポーネントを使用して、ユーザーとロールを管理します。

環境内でユーザー・アカウントがデフォルトで作成される場合、退職済就業者に対してユーザー・アカウントが作成されるのを禁止できます。企業オプション「退職済就業者のユーザー・アカウント作成」を「いいえ」に設定します。退職済就業者を一括してロードする場合、この設定によって、生成されたユーザー・アカウント要求が処理されなくなります。このオプションを設定するには、「設定および保守」作業領域で「企業HCM情報の管理」タスクを実行します。

就業者コンポーネントの有効開始日および有効終了日: 説明

就業者オブジェクトの多くのコンポーネントは、有効日です。就業者を作成するときに、個々の就業者コンポーネントの有効日が矛盾しないようにする必要があります。このトピックでは、各有効日コンポーネントに対して、最早有効開始日と最終有効終了日を設定するアプローチについて説明します。必ずしもこのガイダンスに従う必要はありません。ただし、完全な就業者オブジェクトに対応するように有効日が調整されていることを確認する必要があります。

次の表では、有効日の就業者コンポーネントに対して、最早有効開始日と最終有効終了日を設定する方法について説明します。

コンポーネント 最早有効開始日 最終有効終了日

就業者

就業者の最早開始日。

終了時間。

個人住所

就業者の最早開始日以降。

終了時間。

個人国別仕様データ

就業者の最早開始日。

終了時間。

個人名

就業者の最早開始日。

終了時間。

個人ビザ

就業者の最早開始日以降。

終了時間。

個人連絡先続柄

就業者の最早開始日以降。

連絡先続柄の有効終了日。

雇用条件

最初の雇用条件の有効開始日は、対応する雇用関係の開始日と同じになる必要があります。後続の雇用条件の有効開始日は、対応する雇用関係の開始日以降にすることができます。

終了時間。

アサイメント

最初のアサイメントの有効開始日は、すべての対応する雇用条件の最早有効開始日と同じになる必要があります。後続のアサイメントの有効開始日は、対応する雇用条件の最早有効開始日以降にすることができます。使用される雇用モデルに応じて、最早有効開始日に対する他の制限が存在する場合があります。

終了時間。

アサイメントその他情報

対応するアサイメントの最早有効開始日以降。

終了時間。

アサイメント等級ステップ

対応するアサイメントの最早有効開始日以降。

等級ステップの有効終了日。

アサイメント・マネージャ

対応するアサイメントの最早有効開始日以降。

マネージャ関係の有効終了日。

アサイメント勤務メジャー

対応するアサイメントの最早有効開始日以降。

終了時間。

契約

対応する雇用条件の最早有効開始日。

終了時間。

雇用条件等級ステップ

対応する雇用条件の最早有効開始日以降。

等級ステップの有効終了日。

雇用条件マネージャ

対応する雇用条件の最早有効開始日以降。

マネージャ関係の有効終了日。

雇用条件勤務メジャー

対応する雇用条件の最早有効開始日以降。

終了時間。

就業者その他情報

就業者の最早開始日以降。

終了時間。

就業者コンポーネントの削除: 説明

就業者オブジェクトの一部のコンポーネントは削除できますが、就業者全体は削除できません。個々の就業者コンポーネントの削除のサポートの詳細は、「データ・ロードの開始」ページのコンポーネント詳細を参照してください。このトピックでは、HCMデータ・ローダーを使用した一部の就業者コンポーネントの削除に関する追加情報を示します。

次の表では、就業者オブジェクトの一部のコンポーネントを削除できる状況に関する情報を示します。

コンポーネント 削除がサポートされている 注記

個人住所

はい

国固有の規制に従って、任意の住所を削除できます。郵送先住所が複数存在する場合、プライマリ郵送先住所を削除するには、すべての非プライマリ郵送先住所を削除する必要があります。または、現在のプライマリ郵送先住所を削除する前に、新しいプライマリ郵送先住所を指定します。

個人Eメール

はい

Eメールが1つのみ存在する場合は削除できます。Eメールが複数存在する場合、プライマリEメールを削除するには、すべての非プライマリEメールを削除する必要があります。または、現在のプライマリEメールを削除する前に、新しいプライマリEメールを指定します。

個人国別仕様データ

はい

1人の就業者に対して1つの国別仕様データ・レコードが存在する必要があります。この唯一のレコードは削除できません。追加のレコードは削除できます。

個人電話番号

はい

電話が1つのみ存在する場合は削除できます。電話が複数存在する場合、プライマリ電話を削除するには、すべての非プライマリ電話を削除する必要があります。または、現在のプライマリ電話を削除する前に、新しいプライマリ電話を指定します。

ユーザー情報

いいえ

ユーザー情報コンポーネントは、就業者を作成するときにのみ使用できます。就業者の更新時には、このコンポーネントは使用できません。

個人ユーザー手動ロール

いいえ

個人ユーザー手動ロール・コンポーネントは、就業者を作成するときにのみ使用できます。就業者の更新時には、このコンポーネントは使用できません。

就業者から単一のロールを削除するには、就業者オブジェクトではなくユーザー・オブジェクトを使用します。就業者から複数のロールを削除するには、ユーザー・オブジェクトのユーザー・ロール・コンポーネントを使用します。

雇用関係

はい

雇用関係を削除する場合は、値がYのCancelWorkRelationshipFlag属性を含める必要があります。

個人レコードの重複の確認: 説明

HCMデータ・ローダーを使用して個人レコードをロードするときに、重複レコードの確認を要求できます。この場合、重複レコードをロードしようとするとエラー・メッセージが表示されます。このトピックでは、個々の個人レコードの重複チェックの要求方法について説明します。また、重複チェックの企業設定とこのオプションがどのように連動するかについても説明します。

個々の個人レコードの重複チェック

個人レコードの重複チェックを要求するには、就業者オブジェクトのPersonDuplicateCheck属性を含めます。この属性には、次の表に示す値のいずれかを指定できます。「説明」列は、重複レコードを特定するたびに使用される属性を示しています。

値 説明

ORA_NONEまたは空白値

重複チェックは行われません

ORA_LN_FI_DOB_GEN_NID

姓、名のイニシャル、生年月日および性別、または国別ID

ORA_LN_FI_DOB_NID

姓、名のイニシャルおよび生年月日、または国別ID

ORA_LN_FN_DOB_GEN_NID

姓、名、生年月日および性別、または国別ID

ORA_NID_ONLY

国別ID

たとえば、PersonDuplicateCheckをORA_LN_FI_DOB_NIDに設定した場合は、次のいずれかの状況になったときに、重複レコードが特定されます。

  • 姓、名のイニシャルおよび生年月日が、既存の個人レコードのものとすべて一致する。

  • 国別IDが、既存の個人レコードのものと一致する。

注意: 国別IDの値は書式設定されている必要があります。たとえば、米国の社会保障番号987-65-4322をロードするには、ハイフンを含める必要があります。987654322のような数値は指定しないでください。国固有の書式設定を省略すると、チェックが国別識別子に基づくときは、重複する個人レコードが検出されません。

企業の重複チェック

企業オプション「個人作成サービス重複チェック」により、個人レコードを一括でロードしたときに、重複する個人レコードの確認がデフォルトで行われるかどうかが制御されます。就業者オブジェクトのPersonDuplicateCheck属性を除外した場合は、「個人作成サービス重複チェック」の現在の設定が適用されます。PersonDuplicateCheck属性を含めた場合は、関連する個人レコードで「個人作成サービス重複チェック」の現在の設定は無視されます。

関連トピック

就業者オブジェクトの個人番号: 説明

個人レコードには、Personタイプや雇用関係の番号に関係なく、それぞれ一意の個人番号が指定されます。個人番号は、企業オプション「個人番号生成方法」の設定に応じて、自動的に生成することも、手動で入力することもできます。このトピックでは、アップロード済の就業者オブジェクトの個人番号を指定する方法について説明します。

自動的に生成される個人番号

個人番号を自動的に生成するには、「個人番号生成方法」オプションを「送信前に自動」または「最終保存時に自動」に設定します。個人番号が自動的に生成される環境に個人レコードをロードする場合は、個人番号を指定しません。アップロード時に番号が自動的に生成されます。

個人番号のない個人レコードをロードする場合は、ソース・キーを指定して個人レコードを一意に識別する必要があります。PersonId(SourceSystemId)属性とヒントを使用して、就業者オブジェクトのすべての子コンポーネントに同じキーを使用する必要があります。

手動で入力される個人番号

「個人番号生成方法」オプションが「手動」に設定されている場合は、就業者オブジェクトに個人番号を指定する必要があります。

レガシーの番号のロード

個人番号が自動的に生成される環境にレガシーの番号をロードできます。「初期個人番号」企業オプションを、最も大きいレガシーの個人番号に1を足した番号に設定して、レガシーの連番が継続するようにします。

個人番号の訂正

「個人番号生成方法」が「手動」に設定されている場合は、個人番号を訂正できます。

企業の方法が自動生成のときに個人番号を訂正するには、次のようにします。

  1. 「送信前に自動」と「最終保存時に自動」の2つの自動の方法のどちらが使用されているかを確認します。

  2. 番号の生成方法を一時的に「手動」に変更します。

    注意: 訂正が行われているときは、就業者を採用しないことをお薦めします。

  3. 個人番号を訂正します。

  4. 元の自動番号生成方法に戻します。加えた訂正との矛盾を回避するために、「初期個人番号」オプションの値を更新する必要があるかどうかも検討します。

  5. 「個人検索キーワードの更新」プロセスを実行し、キーワード値として個人番号を使用した個人検索が成功するようにします。

個人番号を訂正すると、訂正は、個人レコードの存続期間のすべての有効日更新に適用されます。このルールにより、異なる時間の異なる個人番号を使用して個人が識別されることがなくなります。

訂正する個人レコードを識別するには、ソース・キー、Oracle Fusion GUIDまたはOracle FusionサロゲートIDを指定します。個人番号はユーザー・キーであるため、ユーザー・キーは単独では指定できません。

外部識別子のロード: 説明

就業者オブジェクトの外部識別子コンポーネントでは、時間デバイスや給与アプリケーションなどのサードパーティ・アプリケーションで使用される識別子が保持されます。このトピックでは、外部識別子コンポーネントの一部の属性の設定方法について説明します。

個人レベルまたはアサイメント・レベルの外部識別子

外部識別子は次のように取得できます。

  • 個人レベル(個人番号のみを指定)

  • アサイメント・レベル(個人番号とアサイメント番号の両方を指定)

外部識別子のタイプ

外部識別子のタイプは、参照タイプORA_PER_EXT_IDENTIFIER_TYPESで定義されます。この参照タイプに参照コードを追加できます。

日付値

DateFrom属性とDateTo属性には、タイム・スタンプが含まれます。タイム・スタンプにより、任意の日に複数回単一タイプの外部識別子を就業者に割り当てることができます。たとえば、個人が時間デバイス・バッジ識別子を失ったその日のうちに、時間デバイス・バッジ識別子を割り当てることができます。同じ日にバッジ識別子を置き換えると、タイム・スタンプによって外部識別子が区別されます。

外部識別子の連番

ExternalIdentifierSequence属性はユーザー・キーの必須コンポーネントで、一意である必要があります。就業者の最初のレコードには、この属性を1に設定することをお薦めします。後続のレコードに対して1ずつ増加します。

外部識別子の例

このWorker.datファイルの例では、個人の外部識別子をロードします。

SET PURGE_FUTURE_CHANGES N
METADATA|ExternalIdentifier|ExternalIdentifierNumber|PersonNumber|ExternalIdentifierType|ExternalIdentifierSequence
MERGE|ExternalIdentifier|rtyui45678|TestPer0TALTEST_9|Third-Party Payroll ID|1

個人名のロード: 考慮する点

就業者オブジェクトの個人名コンポーネントでは、個人の名前の共通のコンポーネントと国別仕様固有のコンポーネントの両方が保持されます。このトピックでは、HCMデータ・ローダーを使用して個人名をロードするときに決定する必要があるいくつかの事項について説明します。

ローカル名とグローバル名

個人名は常にグローバル・バージョンとローカル・バージョンの両方で作成されます。名前は、指定した名前タイプに基づいて作成され、他の名前が自動的に導出されます。たとえば、NameType属性をGLOBALに設定した場合は、ローカル名が導出されます。または、NameTypeをFRなどに設定した場合は、グローバル名が導出されます。通常、グローバル名のみが必須で、アプリケーションによってそれが自動的にローカル名にコピーされます。ただし、個人の名前が2つの異なる文字セットで保持される必要がある場合は、ローカル名を指定します。

国別仕様の場合、コアの名前フィールドが使用できない場合があります。たとえば、国別仕様が日本の場合、「姓(漢字)」は使用できません。この場合、NameInformation1からNameInformation14までの属性のいずれかにデータが格納されます。NameInformation1からNameInformation14までは、この目的で予約されています。個人名形式表には、名前形式と名前属性のマッピングが格納されます。名前形式は、グローバル名レコードとローカル名レコードで同じです。

特定の国別仕様の名前属性

特定の国別仕様の名前属性を指定するには、NameInformation15からNameInformation30までの属性のいずれかを使用します。たとえば、米国の名前属性Doing Business Asを定義する場合は、NameInformation15属性を使用できます。この要件に対してフレックスフィールドを定義する必要はありません。

有効日履歴の指定

個人名の有効日履歴をロードする場合は、ソース・キーを指定してコンポーネントを識別する必要があります。そうしない場合は、PersonNumber、EffectiveStartDateおよびNameTypeのユーザー・キー・コンポーネントを使用できます。

関連トピック

個人イメージのロード: 説明

個人イメージは、個人のレコードを識別するために、様々なOracle HCM Cloudアプリケーションのページに表示されます。このトピックでは、HCMデータ・ローダーを使用して就業者オブジェクトの個人イメージ・コンポーネントをロードするときの側面について説明します。

イメージ・タイプ

ImageType属性はPROFILEにのみ設定できます。ImageType属性を除外した場合、デフォルトでタイプがPROFILEになります。

イメージ・サイズ

イメージの推奨サイズは、90ピクセル×120ピクセルです。様々なサイズのイメージがサポートされていますが、歪みを抑えるために3対4のアスペクト比を維持することをお薦めします。イメージの解像度に関する推奨事項はありません。イメージ・ファイルの最大サイズは、2 GBです。ただし、提案された寸法を考慮するように、できるかぎり小さいサイズでイメージを格納することをお薦めします。イメージが小さくなるほど、アプリケーションに表示されるイメージのパフォーマンスが向上します。通常、推奨される寸法のイメージのファイル・サイズは、高解像度の場合でも、2 MBまたは3 MB程度にすぎません。

雇用関係変更: 例

就業者オブジェクトには、雇用関係の保守を簡素化する、いくつかのインジケータ属性が備えられています。これらのインジケータを使用して、退職やプライマリ・アサイメントの変更などの処理を要求します。このトピックでは、これらのインジケータを使用して要求する雇用関係の変更の例を示しています。

注意: 完全な有効日履歴を指定する場合、これらのインジケータはサポートされていません。これらは、独立した処理に対してのみ提供されています。また、同じ雇用関係レコードには、複数のインジケータは指定できません。たとえば、同時に同じ雇用関係に対して、雇用関係の終了(TerminateWorkRelationshipFlag)とグローバル異動の実行(GlobalTransferFlag)の両方を行うことはできません。

採用日の変更

採用日は、雇用関係の開始日です。採用日を変更するには、雇用関係コンポーネントのNewStartDate属性で新しい日付を指定します。雇用関係レコードのみをロードできます。雇用条件とアサイメント・レコードは自動的に保守されます。

次の例では、既存の就業者の採用日を変更します。

SET PURGE_FUTURE_CHANGES N
METADATA|WorkRelationship|SourceSystemOwner|SourceSystemId|PersonId(SourceSystemId)|LegalEmployerName|NewStartDate
MERGE|WorkRelationship|VISION|1009_POS|1009|Cox-6-CWB|2002/02/10

雇用関係の終了

雇用関係を終了するには、TerminateWorkRelationshipFlag属性がYに設定された雇用関係コンポーネントをロードします。ActualTerminationDate属性で退職日を指定します。退職日後は、すべての関連するアサイメントが自動的に非アクティブになります。

次の例では、雇用関係を終了します。

SET PURGE_FUTURE_CHANGES N
METADATA|WorkRelationship|SourceSystemOwner|SourceSystemId|PersonId(SourceSystemId)|LegalEmployerName|TerminateWorkRelationshipFlag|ActualTerminationDate|ActionCode|ReasonCode
MERGE|WorkRelationship|VISION|1009_POS|1009|Cox-6-CWB|Y|2015/10/02|RESIGNATION|RESIGN_PERSONAL

雇用関係の退職日の訂正

雇用関係終了日を訂正するには、新しいActualTerminationDateを指定して、CorrectTerminationFlag属性をYに設定します。

次の例では、終了済雇用関係の退職日を訂正します。

SET PURGE_FUTURE_CHANGES N
METADATA|WorkRelationship|SourceSystemOwner|SourceSystemId|PersonId(SourceSystemId)|LegalEmployerName|CorrectTerminationFlag|ActualTerminationDate
MERGE|WorkRelationship|VISION|1009_POS|1009|Cox-6-CWB|Y|2015/10/08

退職の取消

退職を取り消すには、ReverseTerminationFlag属性がYに設定された雇用関係コンポーネントをロードします。

次の例では、雇用関係の終了を取り消します。

SET PURGE_FUTURE_CHANGES N
METADATA|WorkRelationship|SourceSystemOwner|SourceSystemId|PersonId(SourceSystemId)|LegalEmployerName|ReverseTerminationFlag
MERGE|WorkRelationship|VISION|1009_POS|1009|Cox-6-CWB|Y

雇用関係の取消

雇用関係を取り消すには、雇用関係に対するDELETE命令を使用して、CancelWorkRelationshipFlag属性をYに設定します。

次の例では、指定した雇用関係とそのすべての子レコードを削除します。

SET PURGE_FUTURE_CHANGES N
METADATA|WorkRelationship|SourceSystemOwner|SourceSystemId|PersonId(SourceSystemId)|CancelWorkRelationshipFlag
DELETE|WorkRelationship|VISION|1008_POS|1008|Y

プライマリ・アサイメントまたはプライマリ雇用関係の変更

プライマリ雇用関係をロードすると、DateForPrimaryFlagChange属性で指定した日付で、既存のプライマリ雇用関係が自動的に非プライマリになります。

非プライマリ雇用関係をプライマリにするには、PrimaryFlag属性をYに設定して、プライマリにする対象の雇用関係をロードします。DateForPrimaryFlagChange属性で、雇用関係がプライマリになる日付を指定します。この対応する変更が、雇用条件とアサイメントに対して自動的に行われます。既存のプライマリ雇用関係のプライマリ・インジケータは、自動的にNに設定されます。

グローバル異動の実行: 説明

このトピックでは、HCMデータ・ローダーを使用して、プライマリ雇用関係と非プライマリ雇用関係の両方に対してグローバル異動を実行する方法について説明します。グローバル異動は、ある雇用主から別の雇用主への永続的な異動です。この結果、既存の雇用関係が終了し、新しい雇用関係が作成されます。既存の雇用関係の退職日は、新しい雇用関係の開始日の1日前になります。

プライマリ雇用関係に対するグローバル異動の実行

デフォルトでは、グローバル異動はプライマリ雇用関係に適用されます。グローバル異動を実行するには、新しい雇用関係コンポーネントとそのすべての子コンポーネントをロードします。新しい雇用関係で、次が必要になります。

  • Yに設定されたGlobalTransferFlag属性

  • EMPL_GLB_TRANSFER処理タイプからの処理コード

  • グローバル異動の日付となる開始日の値

終了する雇用関係は含めないでください。この雇用関係は自動的に終了します。

データの一貫性を確認するために、雇用関係の終了と作成が検証されます。特に、就業者が、アクティブな非プライマリ雇用関係のみを保持し続けることはできません。したがって、就業者が2つのアクティブな雇用関係を保持する場合、プライマリ雇用関係に対してグローバル異動を実行できません。グローバル異動を試行する前に、プライマリ雇用関係を非プライマリにする必要があります。

非プライマリ雇用関係に対するグローバル異動の実行

就業者は、複数の非プライマリ雇用関係を保持できます。したがって、非プライマリ雇用関係のグローバル異動を実行する場合は、適切な雇用関係が終了するように、追加情報を指定する必要があります。非プライマリ雇用関係に対してグローバル異動を実行するには、次を指定する必要もあります。

  • 親就業者コンポーネント。

  • 終了する非プライマリ雇用関係。ただし、次は含めないでください。

    • 終了する雇用関係の子レコード

    • GlobalTransferFlag属性

これらのレコードは、プライマリ雇用関係のグローバル異動に対して指定したレコードに追加するレコードです。

個人名国別仕様コードの更新

グローバル異動を実行するときに、新しい雇用関係に、個人の新しい国別仕様コードを含めることができます。この場合、個人名の国別仕様コードを更新する必要がある場合があります。個人名国別仕様コードは、すべての使用可能な雇用関係国別仕様コードに対して検証されます。したがって、雇用関係に対する変更は、個人名に対する変更の前に行われる必要があります。個人名の国別仕様コードは、次のいずれかの方法で更新できます。

  • 個人名と雇用関係のコンポーネントを変更する同じ.datファイルに、変更していない就業者オブジェクトを含めます。この場合、雇用関係に対する変更は、個人名に対する変更の前に処理されます。

  • 雇用関係に対する更新を、個人名に対する更新の前に処理します。

個人国別仕様データのロード: 説明

このトピックでは、HCMデータ・ローダーを使用してロードする個人国別仕様データの開始日を指定する方法について説明します。

個人国別仕様データの開始日

個人国別仕様データは、個人の最早有効開始日に開始する必要があります。個人は、異なる国別仕様の複数の雇用関係を保持できます。この場合、すべての個人国別仕様データは、雇用関係の開始日ではなく、個人の最早有効開始日に開始する必要があります。個人が新しい国別仕様の雇用関係を開始するときに、アプリケーションで次のことが行われます。

  • 個人の最早有効開始日付で、データのない個人国別仕様データ・レコードを作成します。

  • 新しい雇用関係の作成日付で、ユーザー指定のデータを使用して、個人国別仕様データ・レコードの更新を実行します。このアプローチにより、データの時系列が正しくなります。

たとえば、次の表の就業者の雇用関係を考えてみます。

日付 処理

2000

英国のVision Corporationに採用される

2005

英国のVision Corporationを退職する

2006

米軍に入隊する

2009

米軍を除隊し、米国の退役軍人になる

2010

米国のVision Corporationに採用される

この例では、2010年に、米国の個人国別仕様レコードが、個人の最早有効開始日である2000年付けで作成されます。米国の国別仕様レコードが、個人の米国の雇用関係の開始日である2010年付けで更新されます。更新には、ユーザーが指定したとおりに、米軍の軍歴に関する付加フレックスフィールドの詳細が含まれます。

雇用条件のロード: 説明

3階層雇用モデルが実装された環境には、雇用条件をロードできます。このトピックでは、HCMデータ・ローダーを使用してロードする場合の、雇用条件とその関連するアサイメントの属性値を設定する方法について説明します。

企業オプション「アサイメント時の雇用条件上書きの許可」により、アサイメントに対して、雇用条件から継承されるアサイメント属性を上書きできるかどうかが制御されます。ただし、雇用条件をロードする場合は、関連するアサイメントに雇用条件の属性値が継承されることはありません。次の表では、「アサイメント時の雇用条件上書きの許可」の現在の設定と矛盾しないように、雇用条件の属性値を設定する方法を要約しています。

アサイメント時の雇用条件上書きの許可 雇用条件の属性値

いいえ

関連するアサイメントの値と一致する必要があります

はい

関連するアサイメントの値と異なる値が許可されます

就業者のFTE値の自動計算: 説明

常勤換算(FTE)値は、アサイメント勤務時間を標準勤務時間(通常、これがフルタイム就業者の勤務時間です)で除算した結果です。たとえば、アサイメント勤務時間が10で標準勤務時間が40の場合、FTE値は0.25になります。ユーザー・インタフェースでアサイメント勤務時間を編集すると、FTEが自動的に計算されます。HCMデータ・ローダーを使用してアサイメント・レコードをロードするときに、アサイメント勤務メジャー・コンポーネントでFTE値を指定できます。または、FTE値が自動的に計算されることを要求できます。このトピックでは、FTE値の自動計算の要求方法について説明します。

FTE値の自動計算

Worker.datファイルですべてのアサイメントに対するFTE値の自動計算を要求するには、ファイルに次のSET命令を含めます。

SET CALCULATE_FTE Y

この命令を含めると、次のルールが適用されます。

  • Worker.datファイルには、アサイメントに対するアサイメント勤務メジャー・コンポーネントは含めないでください。

  • Oracle HCM Cloudでは、アサイメントに対して、複数のアサイメント勤務メジャー・レコードは存在できません。

  • 関連する期間全体で、アサイメントに対して、アサイメント勤務時間と標準勤務時間の両方が存在する必要があります。そうでない場合は、アサイメントに対するFTE値の計算が発生しません。

次の場合に、FTE値の自動計算が役立つことがあります。

  • アサイメント勤務時間を含む多数のアサイメント・レコードをロードします。

  • アサイメント勤務メジャー・コンポーネントでFTE値をロードしません。

.datファイルにSET CALCULATE_FTE Y命令を含めることによって、すべてのアサイメントに対するFTE値を生成できます。

ヒント: FTE値の計算という目的のみでデータ・ロードを実行できます。単に、SET CALCULATE_FTE Y命令を含むWorker.datファイルに、アサイメントのユーザー・キーを含めます。

関連トピック

デフォルトの勤務時間パターンの作成: 説明

勤務時間パターンにより、各曜日の勤務時間、開始時間および終了時間が定義されます。HCMデータ・ローダーを使用してアサイメント・レコードをロードするときに、デフォルトの勤務時間パターン・レコードの自動作成を要求できます。

デフォルトの勤務時間パターンの作成

Worker.datファイルですべてのアサイメントに対するデフォルトの勤務時間パターンを作成するには、Worker.datファイルに次の命令を含めます。

SET CREATE_DEFAULT_WORKING_HOUR_PATTERN Y

多数のアサイメント・レコードをロードするが、就業者オブジェクトの勤務時間パターン・コンポーネントをロードしない場合に、デフォルトの勤務時間パターンの自動作成が役立つことがあります。このデフォルト・レコードが存在するようになると、就業者オブジェクトの勤務時間パターン・コンポーネントをロードすることによって、各就業者の情報でこれを更新できます。

関連トピック

アサイメント適格ジョブのロード: 例

就業者アサイメントでは、就業者が適格である追加のジョブを識別できます。この機能は、追加のジョブの時間をレポートする必要がある就業者などに対して使用できます。単に、複数のジョブを持つ就業者の追加のジョブを追跡するために、これを使用することもできます。このトピックでは、HCMデータ・ローダーを使用して就業者オブジェクトのアサイメント適格ジョブ・コンポーネントを作成および更新する方法について、例を示して説明します。

アサイメント適格ジョブ・コンポーネントをロードするには、次の条件があります。

  • アサイメント・ジョブがターゲット環境に存在する必要があります。

  • 軽減タイプが導出の場合は、ジョブ・ファミリがターゲット環境に存在する必要があります。

    軽減タイプは手動または導出にできます。

    • 軽減タイプが導出の場合は、就業者のアサイメントのジョブ・ファミリに属するジョブのみを追加できます。導出の意味または参照コードORA_Dを使用して、ReliefType値を指定できます。

    • 軽減タイプが手動の場合は、任意のジョブを追加できます。ManualRateとFrequencyの値を指定する必要があります。手動の意味または参照コードORA_Mを使用して、ReliefType値を指定できます。

また、適格ジョブの開始日は、アサイメント開始日より前にはしないでください。

HCMデータ・ローダーで処理するために、Worker.datファイルでアサイメント適格ジョブ・データをロードします。「適格ジョブの管理」ページで、選択した就業者のこのデータを確認できます。

アサイメント適格ジョブの作成

次のWorker.datファイルの例では、ソース・キーを使用して、就業者のアサイメント適格ジョブを作成します。ReliefTypeは手動です。

METADATA|AssignmentEligibleJob|AssignmentId(SourceSystemId)|JobId(SourceSystemId)|ToDate|FromDate|SourceSystemOwner|SourceSystemId|ReliefType|ManualRate|Frequency
MERGE|AssignmentEligibleJob|1031101972|100000011571171|2000/04/01|2000/01/01|VISION|TEST_RC_ut0001|ORA_M|11.7|Hourly

次のWorker.datファイルの例では、ソース・キーを使用して、就業者のアサイメント適格ジョブを作成します。ReliefTypeは導出です。

METADATA|AssignmentEligibleJob|AssignmentId(SourceSystemId)|JobId(SourceSystemId)|ToDate|FromDate|SourceSystemOwner|SourceSystemId|ReliefType
MERGE|AssignmentEligibleJob|1031101860|100000011571171|2000/04/01|2000/01/01|VISION|TEST_RC_ut0002|ORA_D

次のWorker.datファイルの例では、ユーザー・キーを使用して、就業者のアサイメント適格ジョブを作成します。ReliefTypeは手動です。このコンポーネントのユーザー・キー属性は、AssignmentNumber、JobCode、BusinessUnitShortCodeおよびEffectiveStartDateです。

METADATA|AssignmentEligibleJob|AssignmentNumber|JobCode|ToDate|FromDate|BusinessUnitShortCode|ReliefType|ManualRate|Frequency
MERGE|AssignmentEligibleJob|TEST_ASG_ut0001|JOBOPMANCORE|2000/04/01|2000/01/01|Vision Corporation Enterprise|Manual|11.7|Hourly

アサイメント適格ジョブの更新

アサイメント適格ジョブのToDate属性の値のみを更新できます。次のWorker.datファイルの例では、ソース・キーを使用して、就業者のアサイメント適格ジョブを更新します。

METADATA|AssignmentEligibleJob|AssignmentId(SourceSystemId)|JobCode|ToDate|FromDate|BusinessUnitShortCode|SourceSystemOwner|SourceSystemId|ReliefType|ManualRate|Frequency
MERGE|AssignmentEligibleJob|1031101972|JOBOPMANCORE|2001/04/01|2000/01/01|Vision Corporation Enterprise|VISION|TEST_RC_ut0001|Manual|11.7|Hourly

次のWorker.datファイルの例では、ユーザー・キーを使用して、就業者のアサイメント適格ジョブを更新します。

METADATA|AssignmentEligibleJob|AssignmentNumber|JobCode|ToDate|FromDate|BusinessUnitShortCode|ReliefType|ManualRate|Frequency
MERGE|AssignmentEligibleJob|TEST_ASG_ut0001|JOBOPMANCORE|2001/04/01|2000/01/01|Vision Corporation Enterprise|Manual|11.7|Hourly

年功起算日のロード: 例

年功起算日は、企業での就業者の勤続期間の計算の基になる日付です。福利厚生に対する就業者のステータス、ランクまたは付与は、その年功に依存する場合があります。年功起算日は、雇用主やジョブなどの特定のエンティティの就業者の時間に基づく場合があります。そのため、労働協約、国、部門、企業、等級、ジョブ、雇用主、事業所、ポジション、組合などの値に基づいて、年功ルールを構成できます。このトピックでは、HCMデータ・ローダーを使用してこれらの値に基づいて年功起算日を更新する方法について、例を示して説明します。

注意: HCMデータ・ローダーを使用して就業者の年功レコードを更新できますが、作成はできません。更新する前に、「年功起算日の計算」プロセスを実行して、構成された年功起算日ルールに基づいて、就業者のデフォルトの年功レコードを作成する必要があります。HCMデータ・ローダーを使用して年功レコードを更新したら、「年功起算日の管理」ページで就業者の年功レコードを確認できます。

ユーザー・キーを使用した年功起算日の更新

次のWorker.datファイルの例では、様々なアサイメント属性に基づいて、就業者の年功起算日を更新します。ここでは、ユーザー・キーを使用して、年功起算日コンポーネントを参照します。これらの例で示すように、年功起算日を手動で調整するときはManualAdjustmentComments属性を含める必要があります。

次の例では、アサイメントに基づいて、就業者の年功起算日を更新します。

METADATA|SeniorityDate|SeniorityDateCode|PersonId|PersonNumber|EntryDate|EffectiveStartDate|EffectiveEndDate|SeniorityDate|BusinessUnitShortCode|ManualAdjustmentDays|ManualAdjustmentComments|JobCode|AssignmentNumber
MERGE|SeniorityDate|JUN_A||9990101|2012/01/01|2015/01/01|4712/12/31||Vision Corporation Enterprise|20|Data Correction|JOBCD7|E9990401

次の例では、部門に基づいて、就業者の年功起算日を更新します。

METADATA|SeniorityDate|SeniorityDateCode|PersonId|PersonNumber|EntryDate|EffectiveStartDate|EffectiveEndDate|SeniorityDate|BusinessUnitShortCode|ManualAdjustmentDays|ManualAdjustmentComments|DepartmentName
MERGE|SeniorityDate|JUN_DEPARTMENT||9990101|2012/01/01|2015/01/01|4712/12/31||Vision Corporation Enterprise|20|Data Correction|Commercial Sales

次の例では、企業に基づいて、就業者の年功起算日を更新します。

METADATA|SeniorityDate|SeniorityDateCode|PersonId|PersonNumber|EntryDate|EffectiveStartDate|EffectiveEndDate|SeniorityDate|BusinessUnitShortCode|ManualAdjustmentDays|ManualAdjustmentComments
MERGE|SeniorityDate|JUN_ET||9990101|2012/01/01|2015/01/01|4712/12/31||Vision Corporation Enterprise|20|Data Correction

次の例では、等級に基づいて、就業者の年功起算日を更新します。

METADATA|SeniorityDate|SeniorityDateCode|PersonId|PersonNumber|EntryDate|EffectiveStartDate|EffectiveEndDate|SeniorityDate|BusinessUnitShortCode|ManualAdjustmentDays|ManualAdjustmentComments|GradeCode
MERGE|SeniorityDate|JUN_GRADE||9990101|2012/01/01|2015/01/01|4712/12/31||Vision Corporation Enterprise|20|Data Correction|DHRX-AE-IC1

次の例では、ジョブに基づいて、就業者の年功起算日を更新します。

METADATA|SeniorityDate|SeniorityDateCode|PersonId|PersonNumber|EntryDate|EffectiveStartDate|EffectiveEndDate|SeniorityDate|BusinessUnitShortCode|ManualAdjustmentDays|ManualAdjustmentComments|JobCode
MERGE|SeniorityDate|JUN_JOB||9990101|2012/01/01|2015/01/01|4712/12/31||Vision Corporation Enterprise|20|Data Correction|JOBCD7

次の例では、ジョブに基づいて、就業者の年功起算日を更新します(ただし、コードではなく年功起算日ルール名を使用します)。

METADATA|SeniorityDate|SeniorityDateCode|PersonId|PersonNumber|EntryDate|EffectiveStartDate|EffectiveEndDate|SeniorityDate|BusinessUnitShortCode|ManualAdjustmentDays|ManualAdjustmentComments|JobCode
MERGE|SeniorityDate|SeniorityDateJUnit Person Job||9990101|2012/01/01|2015/01/01|4712/12/31||Vision Corporation Enterprise|20|Data Correction|JOBCD7

次の例では、雇用主に基づいて、就業者の年功起算日を更新します。

METADATA|SeniorityDate|SeniorityDateCode|PersonId|PersonNumber|EntryDate|EffectiveStartDate|EffectiveEndDate|SeniorityDate|BusinessUnitShortCode|ManualAdjustmentDays|ManualAdjustmentComments|LegalEmployerName
MERGE|SeniorityDate|JUN_LEMP||9990101|2012/01/01|2015/01/01|4712/12/31||Vision Corporation Enterprise|20|Data Correction|Vision Corporation

次の例では、事業所に基づいて、就業者の年功起算日を更新します。

METADATA|SeniorityDate|SeniorityDateCode|PersonId|PersonNumber|EntryDate|EffectiveStartDate|EffectiveEndDate|SeniorityDate|BusinessUnitShortCode|ManualAdjustmentDays|ManualAdjustmentComments|LocationCode
MERGE|SeniorityDate|JUN_LOCATION||9990101|2012/01/01|2015/01/01|4712/12/31||Vision Corporation Enterprise|20|Data Correction|V1-_NEW_YORK_CITY_0_2450399170046

次の例では、ポジションに基づいて、就業者の年功起算日を更新します。

METADATA|SeniorityDate|SeniorityDateCode|PersonId|PersonNumber|EntryDate|EffectiveStartDate|EffectiveEndDate|SeniorityDate|BusinessUnitShortCode|ManualAdjustmentDays|ManualAdjustmentComments|PositionCode
MERGE|SeniorityDate|JUN_POSITION||9990101|2012/01/01|2015/01/01|4712/12/31||Vision Corporation Enterprise|20|Data Correction|POSCD66

次の例では、雇用関係に基づいて、就業者の年功起算日を更新します。

METADATA|SeniorityDate|SeniorityDateCode|PersonId|PersonNumber|EntryDate|EffectiveStartDate|EffectiveEndDate|SeniorityDate|BusinessUnitShortCode|ManualAdjustmentDays|ManualAdjustmentComments|JobCode|WorkerType|LegalEmployerName|DateStart
MERGE|SeniorityDate|JUN_WR||9990101|2012/01/01|2015/01/01|4712/12/31||Vision Corporation Enterprise|20|Data Correction|JOBCD7|E|Vision Corporation|2001/05/05

ソース・キーを使用した年功起算日の更新

年功レコードはHCMデータ・ローダーを使用して作成できないため、ソース・システム所有者がFUSIONであるデフォルトのソース・キーを持ちます。そのため、ソース・キーを使用して年功起算日を更新するには、次のことを行う必要があります。

  • HCM抽出の統合オブジェクト・ユーザー・キー抽出を使用して、デフォルトのソース・キーを抽出します。

  • ソース・キー・オブジェクトを使用してそれらを更新し、単一の年功起算日コンポーネントのすべてのソース・キー参照でソース・システム所有者が同じになるようにします。

年功時間数のロード: 例

時給就業者については、時間数で年功を計算します。これらの就業者についてアプリケーションで年功の計算を実行できるように、HCMデータ・ローダーを使用して年功時間数をロードします。Oracle Time and LaborやOracle Global Payrollなどの様々なソース(サードパーティ・アプリケーションを含む)から年功時間数を取得できます。年功時間数をロードする就業者アサイメントが存在し、ロードする時間数の開始日時点でアクティブである必要があります。データをロードする期間全体で時給である必要もあります。

ヒント: 「年功起算日の管理」ページで就業者のロードされたデータを確認できます。複数の就業者のロードされたデータを確認するために、PER_SENIORITY_HOURS表を問い合せることができます。

このトピックでは、HCMデータ・ローダーを使用して就業者オブジェクトの年功時間数コンポーネントを作成、更新および削除する方法について、例を示して説明します。

年功時間数の作成

次のWorker.datファイルの例では、ソース・キーを使用して就業者オブジェクトの年功時間数コンポーネントを作成する方法を示します。

METADATA|SeniorityHour|AssignmentId(SourceSystemId)|ToDate|FromDate|Hours|SourceSystemOwner|SourceSystemId
MERGE|SeniorityHour|1031101972|2001/01/01|2000/01/01|500|VISION|UT00214

次のWorker.datファイルの例では、ユーザー・キーを使用して就業者オブジェクトの年功時間数コンポーネントを作成する方法を示します。このコンポーネントのユーザー・キー属性は、AssignmentNumberおよびFromDateです。

METADATA|SeniorityHour|AssignmentNumber|ToDate|FromDate|Hours
MERGE|SeniorityHour|E00214|2001/01/01|2000/01/01|500

年功時間数の更新

次のWorker.datファイルの例では、ソース・キーを使用して就業者オブジェクトの年功時間数コンポーネントを更新する方法を示します。

METADATA|SeniorityHour|AssignmentId(SourceSystemId)|ToDate|FromDate|Hours|SourceSystemOwner|SourceSystemId
MERGE|SeniorityHour|1031101972|2001/01/01|2000/01/01|600|VISION|UT00214

次のWorker.datファイルの例では、ユーザー・キーを使用して就業者オブジェクトの年功時間数コンポーネントを更新する方法を示します。

METADATA|SeniorityHour|AssignmentNumber|ToDate|FromDate|Hours
MERGE|SeniorityHour|E00214|2001/01/01|2000/01/01|600

年功時間数の削除

次のWorker.datファイルの例では、ソース・キーを使用して就業者オブジェクトの年功時間数コンポーネントを削除する方法を示します。

METADATA|SeniorityHour|AssignmentId(SourceSystemId)|SourceSystemOwner|SourceSystemId
DELETE|SeniorityHour|1031101972|VISION|UT00214

次のWorker.datファイルの例では、ユーザー・キーを使用して就業者オブジェクトの年功時間数コンポーネントを削除する方法を示します。

METADATA|SeniorityHour|AssignmentNumber|ToDate|FromDate|Hours
DELETE|SeniorityHour|E00214|2001/01/01|2000/01/01|500

就業者のデフォルト費用勘定のロード: 例

Oracle Expenses Cloudを使用するすべての就業者に対して、デフォルト費用勘定が定義される必要があります。デフォルト費用勘定キー・フレックスフィールドは、就業者オブジェクトのアサイメント・コンポーネントで使用できます。このトピックでは、就業者アサイメントで就業者のデフォルト費用勘定をロードする方法について説明します。

アサイメントでのデフォルト費用勘定のロード

費用勘定に複数のセグメントが構成されている場合、連結された値を指定します。次の例に示すように、費用勘定に対して構成されているセパレータを使用してセグメント値を区切ります。

METADATA|Assignment|AssignmentNumber|EffectiveStartDate|EffectiveEndDate|EffectiveSequence|EffectiveLatestChange|ActionCode|BusinessUnitId|DepartmentName|LocationCode|PrimaryAssignmentFlag|JobCode|GradeCode|DefaultExpenseAccount|WorkTermsAssignmentId(SourceSystemId)|SourceSystemOwner|SourceSystemId
MERGE|Assignment|E10020592|2012/08/13|2015/04/30|1|Y|MIGRATED|300000001934525|5005 - ICT|GB|N|ICT Manager|M|5101.0000.3030.0000.231200.0000.00000000.0000.0000|10020592_WORKTERMS|VISION|10020592_ASSIGNMENT
MERGE|Assignment|E10020592|2015/05/01|4712/12/31|1|Y|MIGRATED|300000001934525|5005 - ICT|GB|Y|ICT Manager|M|5101.0000.3030.0000.231200.0000.00000000.0000.0000|10020592_WORKTERMS|VISION|10020592_ASSIGNMENT

就業者のロードに関するFAQ

個人国別識別子をロードするには、どうすればよいですか。

個人国別識別子コンポーネントのNationalIdentifierNumber属性で指定する値に、書式設定文字を含める必要があります。たとえば、米国の社会保障番号987-65-4322をロードするには、ハイフンを含める必要があります。987654322のような数値は指定しないでください。国固有の書式設定を省略すると、チェックが国別識別子に基づくときは、重複する個人レコードが検出されません。

個人電話番号をロードするには、どうすればよいですか。

個人電話番号コンポーネントのPhoneNumber属性で指定する値に、書式設定文字を含める必要があります。たとえば、ユーザー・インタフェースで米国の電話番号650.555.0185を入力するには、「市外局番」フィールドに650、「番号」フィールドに555-0185を入力します。HCMデータ・ローダーを使用してこの番号をロードする場合は、PhoneNumber属性に値555-0185を指定する必要があります。

書式設定の要件は国別仕様によって異なります。HCMデータ・ローダーを使用して個人電話番号をロードする場合は、常に、ハイフンやピリオドなどの、国別仕様で指定された書式設定文字を含めます。