1. HCMとの統合
  2. 就業者関連オブジェクトのロード

10 就業者関連オブジェクトのロード

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

休暇欠勤ケースのロード: 説明

休暇欠勤ケースを使用して、関連する休暇欠勤(通常は理由が同じもの)をグループ化します。たとえば、就業者が、勤務時の負傷後に2つの期間疾病休暇欠勤を取得するとします。この場合、管理しやすいように、2つの休暇欠勤を同じ休暇欠勤ケースに関連付けることができます。このトピックでは、HCMデータ・ローダーを使用して就業者の休暇欠勤ケース・オブジェクトをロードする方法について説明します。AbsenceCase.datファイルを使用します

休暇欠勤カテゴリ

休暇欠勤ケースを休暇欠勤カテゴリに関連付ける場合は、そのケースのすべての休暇欠勤のカテゴリが同じである必要があります。休暇欠勤ケースのカテゴリを指定しない場合は、休暇欠勤ケースに任意のタイプの休暇欠勤を関連付けることができます。休暇欠勤カテゴリを定義するには、「休暇欠勤管理」作業領域で「休暇欠勤カテゴリの管理」タスクを使用します。

休暇欠勤ケースのロード

次のレコードを参照する休暇欠勤ケースを作成する前に、そのレコードがOracle HCM Cloudに存在する必要があります。

  • 休暇欠勤カテゴリ(カテゴリを使用する場合)

  • 就業者および雇用関係

  • 就業者アサイメント(休暇欠勤がアサイメントに固有のものである場合)

  • 休暇欠勤レコード

休暇欠勤ケースの削除

HCMデータ・ローダーを使用して、休暇欠勤ケース・オブジェクトを削除できます。削除するレコードを識別するには、AbsenceCaseCode属性を指定します。

職責範囲のロード: 説明

職責範囲は、就業者がそのジョブの一部として負う職責です。このような職責には、国や部門などのスコープが定義されています。たとえば、就業者は次のようになる場合があります。

  • 組織のグループの人事担当者

  • 指定したジョブを持つ就業者の福利厚生担当者

  • ドイツの就業者の組合代表

個人レコードへのアクセスを保護する方法として、職責範囲を使用することをお薦めします。このトピックでは、HCMデータ・ローダーを使用して個人の職責範囲をロードする方法について説明します。AreasOfResponsibility.datファイルを使用します。

職責タイプ

職責範囲をロードする前に、職責タイプがターゲット環境に存在する必要があります。デフォルトでは、次の5つの職責タイプを使用できますが、ビジネス・ニーズにあわせて独自に追加できます。

  • 福利厚生担当者

  • 人事担当者

  • 給与担当者

  • 採用

  • 組合代表

職責タイプは、参照タイプPER_RESPONSIBILITY_TYPESに対して検証されます。

職責名

職責名は、個人と職責タイプの組合せに対して一意である必要があります。

職責のスコープ

職責範囲をロードする前に、ビジネス・ユニット、雇用主、部門、事業所などの職責のスコープで使用できる各種属性が存在する必要があります。たとえば、職責範囲のスコープとして事業所を識別するには、事前にその事業所が存在する必要があります。

職責範囲の削除

HCMデータ・ローダーを使用して、職責範囲を削除できます。ただし、職責範囲を削除することで意図しない結果が発生しないことを確認してください。たとえば、就業者の個人レコードに対する保護されたアクセスの基になる職責範囲を削除すると、その保護されたアクセスが失われる場合があります。

関連トピック

計算カードのロード: 説明

計算カードによって、休暇欠勤支払や標準控除項目など、一部の支給項目および控除項目について給与計算に必要な値が収集されます。様々なタイプの計算カードが存在します。たとえば、英国の計算カードには、法定控除項目、年金の自動登録、裁判所命令と奨学金、および福利厚生と年金を対象としたものが含まれます。ほとんどの国別仕様で計算カード・オブジェクトがサポートされています。ただし、サポートされる計算カードのタイプは、国別仕様によって異なります。このトピックでは、HCMデータ・ローダーを使用して計算カードをロードするときに、すべての計算カードに適用されるいくつかの一般的な考慮事項について説明します。国別仕様固有の情報は、My Oracle Support (https://support.oracle.com)の『Oracle Fusion Applications HCMのすべてのホワイトペーパー』(文書ID 1504483.1)を参照してください。

各計算カードには1つ以上のコンポーネントがあり、各コンポーネントは1つ以上のコンポーネント詳細のセットを持つことができます。たとえば、英国の裁判所命令と奨学金の計算カードでは、各コンポーネントが、異なるタイプの裁判所命令に対応します。コンポーネント詳細に、その裁判所命令に関連する情報を入力します。

計算カードは、主に、給与関係のレベルで使用されます。国別仕様によっては、給与法定ユニットまたは税レポート・ユニットのレベルで使用されることもあります。ただし、HCMデータ・ローダーでは、計算カードは給与関係レベルでのみサポートされています。

キーのサポート

計算カード・オブジェクトは統合有効です。これらは、HCMデータ・ローダーがサポートしているすべてのキー・タイプをサポートしています。

統合キーの突合せプロセスの使用方法

ソース・キーは、統合有効オブジェクトに対してのみサポートされています。計算カード・ビジネス・オブジェクトが統合に対して有効になる前に作成されたビジネス・オブジェクトのオカレンスには、SourceSystemOwnerとSourceSystemIdの値が含まれない場合があります。これらのオブジェクトのソース・キーを指定するには、計算カード・ビジネス・オブジェクトの個々のコンポーネントに対して統合キーの突合せプロセスを実行します。このプロセスでは、ソース・キーのないコンポーネントのインスタンスにデフォルトのソース・キーを割り付けます。

ヒント: ソース・キー・オブジェクトを使用して、後でこれらのデフォルトのソース・キーを更新できます。

計算カード・オブジェクトのコンポーネントごとに、1回のみ統合キーの突合せプロセスを実行します。次の表では、コンポーネントとその統合オブジェクト名をリストしています。統合キーの突合せプロセスの実行中に、統合オブジェクト名を選択します。

計算カード・コンポーネント 統合オブジェクト名

計算カード

CalculationCard

カード関連付け

コンポーネント関連付け

CalculationCardAssociations

カード関連付け詳細

コンポーネント関連付け詳細

CalculationCardAssociationDetails

カード・コンポーネント

CalculationCardComponents

計算値定義

ValueDefinition

入力可能計算値

RangeItem

コンポーネント詳細

CalculationComponentDetails

属性値の翻訳

次の属性の値は翻訳可能で、ユーザー・セッションの言語に応じて異なります。

  • DirCardDefinitionName

  • DirCardCompDefName

  • ValueDefinitionName

CalculationCard.datファイルを確実に正常にアップロードするには、ファイルをロードするユーザーが、作成したユーザーと同じ言語を使用する必要があります。翻訳された値はベース・オブジェクトで指定します。個別の翻訳オブジェクトは存在しません。

論理開始日および論理終了日の変更

一般的に、既存の計算カードの最初の有効開始日と最終有効終了日は、変更できます。必要に応じて、METADATA行にReplaceFirstEffectiveStartDate属性およびReplaceLastEffectiveEndDate属性を含めて、Yに設定します。EffectiveStartDate属性およびEffectiveEndDate属性に新しい値を指定します。

注意: 国別仕様固有の検証によって、論理開始日および論理終了日に対する一部の変更が有効でないことが示される場合があります。

計算カードの削除

HCMデータ・ローダーを使用して、計算カード・オブジェクトのすべてのコンポーネントを削除できます。計算カード・コンポーネントを削除すると、その子コンポーネントが自動的に削除されます。個々の子コンポーネントを削除することもできます。

関連トピック

文書提供プリファレンスのロード: 説明

雇用主から就業者に、給与明細や年末の税金文書などの文書が定期的に提供されます。文書提供プリファレンスで、就業者がこれらの文書を受け取る方法が指定されます。たとえば、就業者は、自分の給与明細をオンラインで受け取ることができます。文書タイプに対してデフォルトの提供方法を指定でき、関連するワーク・ストラクチャでデフォルトの方法を上書きできます。たとえば、給与文書の提供プリファレンスを、給与法定ユニット・レベルで上書きできます。個人の提供プリファレンスを指定することもできます。個人レベルで指定されたプリファレンスによって、他のすべてのレベルのプリファレンスが上書きされます。このトピックでは、HCMデータ・ローダーを使用して個人の文書レコード提供プリファレンス・オブジェクトをロードする方法について説明します。

文書タイプ

個人の文書提供プリファレンスをロードするには、次のことが必要になります。

  • 文書タイプがターゲット環境に存在する必要があります。

  • 文書提供プリファレンスが、文書タイプに対して有効になっている必要があります。文書タイプ定義で、階層の上書きがPayrollまたはGeneralの適切なほうに設定されている必要があります。たとえば、パフォーマンス文書の提供プリファレンスをロードする場合は、階層の上書きをGeneralに設定する必要があります。

文書提供プリファレンスのロード

個人の文書提供プリファレンスは、DocumentDeliveryPreference.datファイルでロードします。

次のDocumentDeliveryPreference.datファイルの例では、文書提供プリファレンス・レコードをロードします。これらのレコードは、ソース・キーDT1345で識別された文書タイプおよび個人番号ユーザー・キーで識別された3人の個人に対するものです。

METADATA|DocumentDeliveryPreference|DocumentTypeId(SourceSystemId)|LevelCode|PersonNumber|OnlineEnabledFlag|PaperEnabledFlag|AllowWorkerOverrideFlag|OnlineConsentRequiredFlag|InitialConsentFlag|SourceSystemId|SourceSystemOwner
MERGE|DocumentDeliveryPreference|DT1435|900_PERSON|Z8154257|Y|N|Y|Y|Y|LoadPref1|PSFT-US
MERGE|DocumentDeliveryPreference|DT1435|900_PERSON|Z8154806|N|Y|Y|Y|Y|LoadPref3|PSFT-US
MERGE|DocumentDeliveryPreference|DT1435|900_PERSON|Z8154813|Y|N|Y|Y|Y|LoadPref2|PSFT-US

文書レコードのロード: 説明

文書レコードには、ビザ、免許、診断書などの、個人の文書に関する情報が格納されます。文書レコードには、文書レコードの電子版を添付ファイルとして含めることができます。このトピックでは、HCMデータ・ローダーを使用して個人の文書レコードおよび文書レコード添付コンポーネントをロードする方法について説明します。

文書タイプ

文書レコードは、特定の文書タイプに対して存在します。ターゲット環境にその文書タイプが存在することを確認する必要があります。文書タイプの定義によって、サポートされる属性および必須属性が識別されます。

添付ファイル

文書レコード添付コンポーネントには、個人の文書の電子版が保持されます。次のものを指定するには、属性URLorTextorFilenameを使用します。

  • URL (DataTypeCodeがWEB_PAGEの場合)

  • テキスト(DataTypeCodeがTEXTの場合)

  • ファイル名(DataTypeCodeがFILEの場合)

添付ファイルをアップロードする場合は、関連する文書レコードを含むDocumentsOfRecord.datファイルと同じ.zipファイルにこれらを格納する必要があります。すべての添付ファイルは、BlobFilesというサブディレクトリに配置する必要があります。このサブディレクトリの名前は、添付ファイルが保持されるBLOBデータ型書式に由来します。文書レコード添付コンポーネントのFile属性で、添付ファイルの名前を指定します。

文書レコードのロード

文書レコード・データをDocumentsOfRecord.datファイルに指定します。次のDocumentsOfRecord.datファイルの例では、個人のパスポート文書を作成して、パスポートのPDFファイルを添付ファイルとして含めます。ここでは、ソース・キーを使用して文書レコードと添付ファイルの両方が識別されます。

METADATA|DocumentsOfRecord|SourceSystemOwner|SourceSystemId|PersonId(SourceSystemId)|DocumentCode|DocumentName|DateFrom|DateTo|IssuingAuthority|IssuedDate|IssuingCountry
MERGE|DocumentsOfRecord|VISION|56883|134003891|PASSPORT_2442|UK Passport|2012/04/03|2022/04/03|United Kingdom Passport Control|2012/04/03|UK
METADATA|DocumentAttachment|SourceSystemOwner|SourceSystemId|DocumentsOfRecordId(SourceSystemId)|DataTypeCode|URLorTextorFileName|File
MERGE|DocumentAttachment|VISION|90982|56883|FILE|Passport_2442|JSmithPassport.pdf

文書レコードの削除

HCMデータ・ローダーを使用して、文書レコード・オブジェクトを削除できます。文書レコードを削除すると、関連するすべての添付ファイル・レコードが自動的に削除されます。必要に応じて、添付ファイルのみを削除できます。

次のDocumentsOfRecord.datファイルの例では、既存の文書レコードを削除します。ここでは、ソース・キーを使用して文書レコードが識別されます。

METADATA|DocumentsOfRecord|SourceSystemOwner|SourceSystemId
DELETE|DocumentsOfRecord|VISION|56883

関連トピック

レガシー学習アイテムのロード: 例

レガシー学習アイテムは、学習者の学習履歴に含める完了したコースまたは講義を表します。レガシー学習アイテムにはサポート・コンテンツはなく、これらを他の学習者に割り当てることはできません。このトピックでは、HCMデータ・ローダーを使用してレガシー学習アイテム・オブジェクトをロードする方法について、例を示して説明します。

レガシー学習アイテムの作成

次のLegacyLearningItem.datファイルの例では、学習者の学習履歴に表示されるレガシー学習アイテムを作成します。この例では、ソース・キーによってレガシー学習アイテムが識別されます。

COMMENT: Data for Business Object LegacyLearningItem
METADATA|LegacyLearningItem|EffectiveStartDate|LearningItemNumber|Title|ShortDescription|OwnedByPersonNumber|SourceType|SourceId|SourceInfo|SourceSystemOwner|SourceSystemId
MERGE|LegacyLearningItem|2017/07/26|LEGACY-201710161121-HDL|Title:Legacy LI 201710161121|DescShort:LEGACY-201710161121|8153756|FUSION_HCM_LEARNING|201710161121|HCM Learn 201710161121 Source Info|VISION|201710161121

HCMデータ・ローダーを使用してレガシー学習アイテム・オブジェクトを作成する場合は、次のルールが適用されます。

  • OwnedbyPersonNumber属性によって識別された個人が、ターゲット環境に存在する必要があります。

  • LearningItemNumberは必須です(このレコードを一意に識別する英数字の値)。この先頭をOLCという文字にしないでください。これらの文字は、Oracle Learning Cloudカタログ・アイテム用に予約されています。

  • 有効開始日は、レガシー学習アイテム・レコードを参照する、学習レコードなどの有効日レコードの開始日以前にする必要があります。デフォルトでは、有効終了日は終了時間です。既存のレガシー学習アイテム・オブジェクトの有効開始日と有効終了日は変更できません。

レガシー学習アイテムの翻訳された名前および摘要のロード

レガシー学習アイテムの名前とその摘要を翻訳できます。レガシー学習アイテムがターゲット環境に存在するようになったら、翻訳データをLegacyLearningItemTranslation.datファイルに指定します。次のLegacyLearningItemTranslation.datファイルの例では、既存のレガシー学習アイテム・オブジェクトの名前および摘要の翻訳を提供します。ここでは、ソース・キーによってオブジェクトが参照されます。

COMMENT: Data for Business Object LegacyLearningItemTranslation
METADATA|LegacyLearningItemTranslation|EffectiveStartDate|Language|LearningItemNumber|Title|ShortDescription|SourceSystemOwner|SourceSystemId
MERGE|LegacyLearningItemTranslation|2017/07/26|FR|LEGACY-201710161121-HDL|French Title:Legacy LI 201710161121|French ShortDesc:LEGACY-201710161121|VISION|201710161121

ユーザーの更新要求のロード: 説明

ユーザー・オブジェクトを使用して、既存のOracle HCM Cloudユーザー・アカウントを更新する要求を作成します。このトピックでは、どのようなときにユーザー・オブジェクトの各コンポーネントを使用するかについて説明します。また、その使用に関する制限についても説明します。

ユーザー・コンポーネント

次の要求を作成する場合は、ユーザー・コンポーネントを使用できます。

  • ユーザー名の更新。

  • ユーザーの停止またはアクティブ化。

  • ユーザーへの単一ロールの追加またはユーザーからの単一ロールの削除。

  • 特定の状況でのユーザー・アカウントの作成。

  • ユーザー・アカウントの削除。

PER_USERS表のCredentialsEmailSent値を更新する場合も、このコンポーネントを使用します。この値は、アカウントとパスワードの詳細がユーザーに送信されたかどうかを記録します。有効な値はYおよびNです。Eメールが送信されたら、この値をリセットするまで再送信できません。たとえば、ユーザー・パスワードをリセットする場合は、「ユーザー名およびパスワードEメール通知の送信」プロセスを実行できます。これを行う前に、このユーザーに新しいパスワードが通知されるように、CredentialsEmailSentをNに設定できます。そうしない場合は、通知されません。

ユーザー・ロール・コンポーネント

ユーザー・ロール・コンポーネントは、ユーザー・オブジェクトの子です。ユーザーに対して複数のロールを追加または削除する場合は、ユーザー・ロール・コンポーネントを使用します。単一ロールを追加または削除する場合は、ユーザー・コンポーネントを使用します。

ユーザー・アカウントの作成

「ユーザー・アカウント作成」企業オプションの設定によっては、一括してロードされた就業者に対してユーザー・アカウントを自動的に作成できます。ただし、個々の就業者に対して、ユーザー・アカウントが作成されないようにしている可能性があります。または、なんらかの理由でこの作成が失敗した可能性があります。このような場合は、ユーザー・オブジェクトを使用してユーザー・アカウントを要求できます。

注意: ユーザー・アカウントを要求する場合、ユーザー・オブジェクトは例外としてのみ使用できます。標準の方法は、就業者を作成するときにユーザー・アカウントを要求する方法です。

「ユーザー・アカウント作成」企業オプションによってユーザー・アカウントの自動作成が有効になっている場合にのみ、ユーザー・オブジェクトを使用してユーザー・アカウントを作成できます。

ユーザー・アカウントの削除

ユーザー・アカウントを削除する必要がある場合があります。たとえば、誤った書式でユーザー名を作成した場合などです。テスト環境と本番環境の両方で、ユーザー・アカウントを、そのステータスに関係なく削除できます。ユーザーおよびロール・プロビジョニングの各オプションが、ユーザー・アカウントの削除に影響を及ぼすことはありません。たとえば、削除要求は抑制できません。

ヒント: ユーザーは、LDAPディレクトリからも、PER_USERS、PER_USER_ROLESおよびPER_USER_HISTORYのレコードからも削除されます。そのため、ユーザー名を再利用できます。ユーザー・アカウントは、セキュリティ・コンソールで再作成することも、「ユーザーの管理」タスクの使用またはユーザー・オブジェクトのロードによって再作成することもできます。

「待ち状態のLDAP要求の送信」の実行

ユーザーの更新要求のロード後に、「待ち状態のLDAP要求の送信」プロセスを実行して、LDAPディレクトリ・サーバーに配信できます。このプロセスを毎日実行するようにスケジュールすることをお薦めします。CredentialsEmailSentインジケータの更新後にこのプロセスを実行する必要はありません。

関連トピック

ユーザーの更新要求のロード: 例

既存のユーザーおよびロールを管理するには、ユーザー・オブジェクトを使用します。このトピックでは、いくつかの一般的なユーザーの更新要求の作成方法を示す例を示しています。

ユーザーの更新

次の例では、指定した個人番号で識別されたユーザーのユーザー名を更新する要求を作成します。

METADATA|User|PersonNumber|Username
MERGE|User|12312|carlton.baugh@vision.com

次の例では、アクティブ・ユーザーを停止する要求を作成します。

METADATA|User|PersonNumber|Suspended
MERGE|User|12312|Y

次の例では、停止されたユーザーをアクティブ化する要求を作成します。

METADATA|User|PersonNumber|Suspended
MERGE|User|12312|N

次の例では、ユーザー資格証明を含むEメールがユーザーに送信されるかどうかを決定するCredentialsEmailSentインジケータを更新します。CredentialsEmailSentインジケータがYの場合、Eメールは送信されません。インジケータがNの場合、Eメールが送信されます。この例では、インジケータがYからNに変更されます。

METADATA|User|PersonNumber|CredentialsEmailSent
MERGE|User|12312|N

ユーザー・ロールの更新

単一ロールを追加する場合は、ユーザー・コンポーネントを使用します。ロール名ではなく、ロール・コードを指定します。たとえば、EmployeeではなくORA_PER_EMPLOYEE_ABSTRACTを指定して、従業員ロールを追加します。無効なロール・コードを指定すると、要求は作成されますが、ロールのプロビジョニングの試行は失敗します。

次の例では、ユーザーに単一ロールを追加する要求を作成します。

METADATA|User|PersonNumber|RoleCommonName|AddRemoveRole
MERGE|User|12312|ORA_PER_EMPLOYEE_ABSTRACT|ADD

次の例では、ユーザーに複数のロールを追加する要求を作成します。ユーザー・ロール・コンポーネントを使用して、複数のロールを追加します。

METADATA|User|PersonNumber
MERGE|User|12312
METADATA|UserRole|PersonNumber|RoleCommonName|AddRemoveRole
MERGE|UserRole|12312|ORA_PER_EMPLOYEE_ABSTRACT|ADD
MERGE|UserRole|12312|ORA_PER_LINE_MANAGER_ABSTRACT|ADD

次の例では、ユーザーから単一ロールを削除する要求を作成します。ユーザー・コンポーネントを使用して、単一ロールを削除します。

METADATA|User|PersonNumber|RoleCommonName|AddRemoveRole
MERGE|User|12312|ORA_PER_EMPLOYEE_ABSTRACT|REMOVE

次の例では、ユーザーから複数のロールを削除する要求を作成します。ユーザー・ロール・コンポーネントを使用して、複数のロールを削除します。

METADATA|User|PersonNumber
MERGE|User|12312
METADATA|UserRole|PersonNumber|RoleCommonName|AddRemoveRole
MERGE|UserRole|12312|ORA_PER_EMPLOYEE_ABSTRACT|REMOVE
MERGE|UserRole|12312|ORA_PER_LINE_MANAGER_ABSTRACT|REMOVE

ユーザー・アカウントの作成

限定的な状況では、ユーザー・オブジェクトを使用してユーザー・アカウントを作成できます。次に例を示します。

  • 就業者オブジェクトのロード中に、ユーザー・アカウントを要求する試行が失敗しました。

  • ロードした就業者について、誤りが発生したか意図的に、個人ユーザー情報コンポーネントのGeneratedUserAccountFlag属性がNに設定されました。

ユーザー・アカウントの作成は、2ステップのプロセスです。

  1. ユーザーを作成します。

  2. ユーザーをアクティブ化して、ロールを追加します。

次の例では、指定した個人番号のユーザー・アカウントを作成する要求を作成します。必要に応じて、ユーザー名を指定することもできます。ユーザー名を指定しない場合、ユーザー名は、セキュリティ・コンソールで指定したデフォルトの形式で生成されます。アカウントが存在するようになると、ロールが指定されていないため、すぐに停止されます。

METADATA|User|PersonNumber|GenerateUserAccount
MERGE|User|12312|Y

次の例では、ユーザー・アカウントをアクティブ化して、アカウントがアクティブなままになるようにロールを追加します。

METADATA|User|PersonNumber|Suspended
METADATA|UserRole|PersonNumber|RoleCommonName|AddRemoveRole
MERGE|User|12312|N
MERGE|UserRole|12312|ORA_PER_EMPLOYEE_ABSTRACT|ADD
MERGE|UserRole|12312|ORA_PER_LINE_MANAGER_ABSTRACT|ADD
ヒント: 「待ち状態のLDAP要求の送信」が次回実行されるまで、ユーザーの更新要求は処理されません。プロセスがスケジュールされていない場合は、実行することを覚えておいてください。

ユーザー・アカウントの削除

次の例では、指定した個人番号の就業者のユーザー・アカウントを削除します。

METADATA|User|PersonNumber
DELETE|User|12312

就業者スケジュールのロード: 説明

就業者スケジュールによって、指定した期間の就業者のシフト・パターンが定義されます。HCMデータ・ローダーを使用して就業者スケジュールをロードするには、スケジュール要求オブジェクトを使用します。このトピックでは、正常にロードするために理解する必要がある就業者スケジュールのいくつかの側面について説明します。

就業者スケジュールのロードの準備

就業者スケジュールをロードする前に、シフト・コードとスケジューラ・プロファイルを定義する必要があります。必要に応じて、シフト・レイアウトを定義することもできます。次の表は、関連するタスクを示しています。これらのタスクは、「時間管理」作業領域で実行します。

タスク 説明

シフト・プロパティの管理

すべてのシフトのシフト・コードを定義します

スケジューラ・プロファイルの管理

スケジューラ・プロファイルを定義します。ロード対象のシフトに該当するそれぞれの就業者がスケジューラ・プロファイルに含まれることを確認します。

レイアウト・セットの管理

ロードされる時間属性のシフト・レイアウトを定義します。このタスクはオプションです。シフト・レイアウトを定義しない場合、時間属性はロードできるもののアプリケーションで表示されません。

スケジューラと就業者に対して通知を設定して有効にすることもできます。次の表は、通知を示しています。これらの通知は、「アラート・コンポーザ」作業領域で構成します。

通知 説明

HTS就業者シフト・インポート済

新しいスケジュールがロードされるときに、マネージャとスケジューラに送信されます

HTSスケジュール公開

新しいスケジュールが公開されるときに、就業者に送信されます

ヒント: スケジュール要求をロードするときにスケジュール・イベント・コンポーネントのWorkerNotification属性を設定して、就業者通知を有効または無効にすることもできます。

就業者スケジュールがロードされる方法

他のほとんどのHCMデータ・ローダー・ビジネス・オブジェクトとは異なり、就業者スケジュールがHCMデータ・ローダー・ステージ表からアプリケーション表にロードされることはありません。かわりに、就業者スケジュールはHCMデータ・ローダー・ステージ表からスケジュール・ステージ表にロードされます。その後、「インポートされたシフトの処理」プロセスを実行して、計画スケジュール表または計画および公開済スケジュール表に就業者スケジュールをロードする必要があります。「インポートされたシフトの処理」プロセスは、「時間管理」作業領域の「予定プロセスの管理」タスクを使用して実行します。このプロセスでは、次のことが行われます。

  • HCMデータ・ローダーとRESTサービスからの就業者のすべてのスケジュール・イベントをマージします

  • 複数のスケジュール要求からの就業者のスケジュール・イベントを統合し、要求時間によってそれらを順序付けして、その順序で処理します

このアプローチでスケジュール要求オブジェクトをロードすると、データ整合性が維持されます。ただし、HCMデータ・ローダーからの基本的な検証エラーのみが表示されます。「インポートされたシフトの処理」でスケジュール要求オブジェクトがスケジュール表にロードされるときに、多くの検証が実行されます。

インポート・モード

スケジュール要求オブジェクトをロードする場合は、スケジュール・イベント・コンポーネントのImportMode属性をFULLまたはUPDATEに設定する必要があります。次の表では、インポート・モードについて説明しています。

インポート・モード 説明

FULL

就業者スケジュールの作成時にFULLモードを使用します。たとえば、実装中に就業者スケジュールをロードする場合にこのモードを使用します。モードがFULLの場合は、スケジュール・イベントのすべてのスケジュール・シフト・イベント・コンポーネントのShiftAction属性をCREATEに設定する必要があります。

UPDATE

既存の就業者スケジュールを更新または削除する場合にUPDATEモードを使用します。モードがUPDATEの場合は、追加のシフトの作成、既存のシフトの更新または既存のシフトの削除を行うことができます。必要に応じて、スケジュール・シフト・イベント・コンポーネントのShiftAction属性を設定します。

ロードされたスケジュールの確認

勤怠管理マネージャおよびスケジューラは、「時間管理」作業領域でロードされたスケジュールを確認します。確認する内容は、次のとおりです。

  • 計画スケジュール(「計画スケジュールの管理」ページ)

  • 公開済スケジュール(「公開済スケジュールの表示」タスクを使用)

就業者は、カレンダおよび「時間」作業領域の「チーム・スケジュール」ページを使用して公開済スケジュールを表示します。

就業者スケジュールの作成: 例

このトピックでは、HCMデータ・ローダーを使用して就業者スケジュールを作成する方法について、例を示して説明します。

特定の週の就業者のスケジュールの作成

スケジュールを作成する就業者ごとに、スケジュール要求、スケジュール・イベントおよびスケジュール・シフト・イベントのコンポーネントをロードする必要があります。スケジュール・イベント・コンポーネントで、ImportMode属性をFULLに設定します。スケジュール・シフト・イベント・コンポーネントで、ShiftAction属性をCREATEに設定します。

次のScheduleRequest.datファイルの例では、指定した週の就業者のスケジュールを作成します。ここではユーザー・キーを使用します。

METADATA|ScheduleRequest|ScheduleRequestNumber|RequestSource|RequestTime
MERGE|ScheduleRequest|SR1234501|3RD_PARTY_ABC|2017-01-01T13:25:20.010+01:00
METADATA|ScheduleEvent|ScheduleRequestNumber|ScheduleEventNumber|ImportMode|PersonNumber|PeriodStartDate|PeriodEndDate|AllowEdits|Publish|WorkerNotification
MERGE|ScheduleEvent|SR1234501|SE001|FULL|955160008182092|2017/01/01|2017/01/07|Y|Y|N
METADATA|ScheduleShiftEvent|ScheduleRequestNumber|ScheduleEventNumber|ScheduleShiftEventNumber|ShiftAction|ReferenceDay|ShiftStartTime|ShiftEndTime|ShiftTimeNotWorked|ShiftCode|ShiftCategory|ShiftType|AllowEdits
MERGE|ScheduleShiftEvent|SR1234501|SE001|SSE101|CREATE|2017/01/01|2017-01-01T09:00:00+01:00|2017-01-01T17:00:00+01:00|60|MORNTIME|WORK|TIME|N
MERGE|ScheduleShiftEvent|SR1234501|SE001|SSE102|CREATE|2017/01/02|2017-01-02T09:00:00+01:00|2017-01-02T17:00:00+01:00|60|MORNTIME|WORK|TIME|N
MERGE|ScheduleShiftEvent|SR1234501|SE001|SSE103|CREATE|2017/01/03|2017-01-03T09:00:00+01:00|2017-04-03T17:00:00+01:00|60|MORNTIME|WORK|TIME|N
MERGE|ScheduleShiftEvent|SR1234501|SE001|SSE104|CREATE|2017/01/04|2017-01-04T09:00:00+01:00|2017-04-04T17:00:00+01:00|60|MORNTIME|WORK|TIME|N
MERGE|ScheduleShiftEvent|SR1234501|SE001|SSE105|CREATE|2017/01/05|2017-01-05T09:00:00+01:00|2017-04-05T17:00:00+01:00|60|MORNTIME|WORK|TIME|N
METADATA|ScheduleShiftAttribute|ScheduleRequestNumber|ScheduleEventNumber|ScheduleShiftEventNumber|ScheduleShiftAttributeNumber|AttributeName|AttributeValue
MERGE|ScheduleShiftAttribute|SR1234501|SE001|SSE101|SSA001|PayrollTimeType|WFM_PAY_REGULAR_US
MERGE|ScheduleShiftAttribute|SR1234501|SE001|SSE101|SSA002|GD_Department_CHAR|1000
MERGE|ScheduleShiftAttribute|SR1234501|SE001|SSE102|SSA001|PayrollTimeType|WFM_PAY_REGULAR_US
MERGE|ScheduleShiftAttribute|SR1234501|SE001|SSE102|SSA002|GD_Department_CHAR|1000
MERGE|ScheduleShiftAttribute|SR1234501|SE001|SSE103|SSA001|PayrollTimeType|WFM_PAY_REGULAR_US
MERGE|ScheduleShiftAttribute|SR1234501|SE001|SSE103|SSA002|GD_Department_CHAR|1000
MERGE|ScheduleShiftAttribute|SR1234501|SE001|SSE104|SSA001|PayrollTimeType|WFM_PAY_REGULAR_US
MERGE|ScheduleShiftAttribute|SR1234501|SE001|SSE104|SSA002|GD_Department_CHAR|1000
MERGE|ScheduleShiftAttribute|SR1234501|SE001|SSE105|SSA001|PayrollTimeType|WFM_PAY_REGULAR_US
MERGE|ScheduleShiftAttribute|SR1234501|SE001|SSE105|SSA002|GD_Department_CHAR|1000

特定の日の就業者のシフトの作成

就業者の単一のシフトを作成するには、スケジュール要求、スケジュール・イベントおよびスケジュール・シフト・イベントのコンポーネントをロードします。スケジュール・イベント・コンポーネントで、ImportMode属性をFULLに設定します。スケジュール・シフト・イベント・コンポーネントで、ShiftAction属性をCREATEに設定します。

次のScheduleRequest.datファイルの例では、特定の日の就業者のシフトを作成します。ここではユーザー・キーを使用します。

METADATA|ScheduleRequest|ScheduleRequestNumber|RequestSource|RequestTime
MERGE|ScheduleRequest|SR1234502|3RD_PARTY_ABC|2017-01-01T13:25:20.010+01:00
METADATA|ScheduleEvent|ScheduleRequestNumber|ScheduleEventNumber|ImportMode|PersonNumber|PeriodStartDate|PeriodEndDate|AllowEdits|Publish|WorkerNotification
MERGE|ScheduleEvent|SR1234502|SE001|FULL|955160008272091|2017/01/01|2017/01/07|Y|Y|N
METADATA|ScheduleShiftEvent|ScheduleRequestNumber|ScheduleEventNumber|ScheduleShiftEventNumber|ShiftNumber|ShiftAction|ReferenceDay|ShiftStartTime|ShiftEndTime|ShiftDuration|ShiftTimeNotWorked|ShiftCode|ShiftCategory|ShiftType|AllowEdits
MERGE|ScheduleShiftEvent|SR1234502|SE001|SSE101|SN001|CREATE|2017/01/01|2017-01-01T06:00:00+01:00|2017-01-01T09:00:00+01:00||60|MORNTIME|WORK|TIME|N
METADATA|ScheduleShiftAttribute|ScheduleRequestNumber|ScheduleEventNumber|ScheduleShiftEventNumber|ScheduleShiftAttributeNumber|AttributeName|AttributeValue
MERGE|ScheduleShiftAttribute|SR1234502|SE001|SSE101|SSA001|PayrollTimeType|WFM_PAY_REGULAR_US
MERGE|ScheduleShiftAttribute|SR1234502|SE001|SSE101|SSA002|GD_Department_CHAR|1000
注意: スケジュールを作成する場合、シフト番号はオプションです。通常、これらはサードパーティのスケジュール・システムによって生成されます。シフト番号は、シフトを更新または削除するときに指定する必要があります。

就業者スケジュールの更新: 例

このトピックでは、HCMデータ・ローダーを使用して既存の就業者スケジュールを更新する方法について、例を示して説明します。

シフトの更新

既存のシフトを更新するには、スケジュール要求、スケジュール・イベントおよびスケジュール・シフト・イベントのコンポーネントをロードします。スケジュール・イベント・コンポーネントで、ImportMode属性をUPDATEに設定します。スケジュール・シフト・イベント・コンポーネントで、シフト番号を指定して、ShiftAction属性をUPDATEに設定します。

次のScheduleRequest.datファイルの例では、サードパーティ・アプリケーションからの既存の就業者のシフトを更新します。

METADATA|ScheduleRequest|ScheduleRequestNumber|RequestSource|RequestTime
MERGE|ScheduleRequest|SR1234503|3RD_PARTY_ABC|2017-01-01T13:25:20.010+01:00
METADATA|ScheduleEvent|ScheduleRequestNumber|ScheduleEventNumber|ImportMode|PersonNumber|PeriodStartDate|PeriodEndDate|AllowEdits|Publish|WorkerNotification
MERGE|ScheduleEvent|SR1234503|SE001|UPDATE|955160008272091|2017/01/01|2017/01/07|Y|Y|N
METADATA|ScheduleShiftEvent|ScheduleRequestNumber|ScheduleEventNumber|ScheduleShiftEventNumber|ShiftNumber|ShiftAction|ReferenceDay|ShiftStartTime|ShiftEndTime|ShiftTimeNotWorked|ShiftCode|ShiftCategory|ShiftType|AllowEdits
MERGE|ScheduleShiftEvent|SR1234503|SE001|SSE101|SN001|UPDATE|2017/01/01|2017-01-01T07:00:00+01:00|2017-01-01T11:00:00+01:00|60|MORNTIME|WORK|TIME|N

シフトの削除

シフトを削除するには、スケジュール要求、スケジュール・イベントおよびスケジュール・シフト・イベントのコンポーネントをロードします。スケジュール・イベント・コンポーネントで、ImportMode属性をUPDATEに設定します。スケジュール・シフト・イベント・コンポーネントで、シフト番号を指定して、ShiftAction属性をDELETEに設定します。

次のScheduleRequest.datファイルの例では、既存のシフトを削除します

METADATA|ScheduleRequest|ScheduleRequestNumber|RequestSource|RequestTime
MERGE|ScheduleRequest|SR1234504|3RD_PARTY_ABC|2017-01-01T13:25:20.010+01:00
METADATA|ScheduleEvent|ScheduleRequestNumber|ScheduleEventNumber|ImportMode|PersonNumber|PeriodStartDate|PeriodEndDate|AllowEdits|Publish|WorkerNotification
MERGE|ScheduleEvent|SR1234504|SE001|UPDATE|955160008272091|2017/01/01|2017/01/07|Y|Y|N
METADATA|ScheduleShiftEvent|ScheduleRequestNumber|ScheduleEventNumber|ScheduleShiftEventNumber|ShiftNumber|ShiftAction|ReferenceDay|ShiftStartTime|ShiftEndTime|ShiftDuration|ShiftTimeNotWorked|ShiftCode|ShiftCategory|ShiftType|AllowEdits
MERGE|ScheduleShiftEvent|SR1234504|SE001|SSE101|SN001|DELETE|2017/01/01|2017-01-01T07:00:00+01:00|2017-01-01T11:00:00+01:00||60|MORNTIME|WORK|TIME|N

スケジュールの消去

就業者スケジュールを消去するには、スケジュール要求コンポーネントとスケジュール・イベント・コンポーネントをロードします。スケジュール・イベント・コンポーネントで、ImportMode属性をFULLに設定します。スケジュール・シフト・イベント・コンポーネントは指定していないため、「インポートされたシフトの処理」プロセスで、指定した期間のすべてのシフトが削除されます。

次のScheduleRequest.datファイルの例では、指定した期間の就業者の既存のシフトをすべて消去します。

METADATA|ScheduleRequest|ScheduleRequestNumber|RequestSource|RequestTime
MERGE|ScheduleRequest|SR1234537|3RD_PARTY_ABC|2017-05-01T13:25:20.010+01:00
METADATA|ScheduleEvent|ScheduleRequestNumber|ScheduleEventNumber|ImportMode|PersonNumber|PeriodStartDate|PeriodEndDate|AllowEdits|Publish|WorkerNotification
MERGE|ScheduleEvent|SR1234537|SE002|FULL|955160008182092|2017/05/01|2017/05/31|Y|Y|N

就業者関連オブジェクトのロードに関するFAQ

HCMデータ・ローダーを使用して割付チェックリストをロードできますか。

はい。チェックリスト・テンプレートと、チェックリストが割り付けられる就業者の両方が、ターゲット環境に存在する必要があります。