8 設定オブジェクトのロード

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

• 処理のロード: 例

• 処理事由のロード: 例

• 銀行のロード: 説明

• 銀行支店のロード: 説明

• 外部銀行口座のロード: 説明

• カレンダ・イベントのロード: 説明

• チェックリスト・テンプレートのロード: 説明

• 労働協約のロード: 説明

• 文書タイプのロード: 説明

• 文書タイプのロード: 例

• 拡張参照コードのロード: 例

• 国別仕様データ・グループのロード: 例

• 名前書式のロード: 説明

• Personタイプのロード: 説明

• リソース例外のロード: 例

処理のロード: 例

雇用レコードや報酬レコードなどのデータに対する変更は、処理によって分類されます。レコードを作成または更新する場合は、処理値を使用して変更の事由を指定します。たとえば、アサイメント変更に関連付けられる処理には、昇格・昇進または異動があります。処理事由はオプションであり、変更に関する追加情報を提供します。処理オブジェクトの処理事由使用コンポーネントを使用して、処理と既存の処理事由との関係を指定します。このトピックでは、HCMデータ・ローダーを使用して、処理オブジェクトおよびその処理事由使用コンポーネントをロードする方法について説明します。

処理の作成

次のActions.datファイルの例では、処理コンポーネントを作成して処理事由使用コンポーネントに関連付けます。どちらのコンポーネントもソース・キーによって識別されます。

METADATA|Actions|SourceSystemOwner|SourceSystemId|ActionCode|ActionName|ActionTypeCode|StartDate|EndDate
MERGE|Actions|VISION|VISION_ACT_PROM|VISION_PROM|Vision Promotion|EMPL_PROMOTION|2000/01/01|
METADATA|ActionReasonUsage|SourceSystemOwner|SourceSystemId|ActionCodeId(SourceSystemId)|ActionReasonId(SourceSystemId)|StartDate|EndDate
MERGE|ActionReasonUsage|VISION|VISION_PROM_PERF|VISION_ACT_PROM|VISION_PERF|2000/01/01|

変換された処理名および摘要のロード

処理名と摘要は、これらをロードするユーザーの言語で指定します。処理が存在するようになった後、ActionsTranslation.datファイルを指定して、処理名と摘要をその他の対応言語に変換します。このサンプルのActionsTranslation.datファイルでは、処理名とその摘要を変換します。処理は、そのソース・キーによって識別されます。

METADATA|ActionsTranslation|SourceSystemOwner|SourceSystemId|Language|ActionName|Description
MERGE|ActionsTranslation|VISION|ACT_VISION_PROM|FR|Performance|Changement est survenu en raison de la performance des employes

処理の削除

HCMデータ・ローダーを使用して、処理と処理事由使用コンポーネントを削除できます。次のActions.datファイルの例では、処理事由使用コンポーネントを削除します。これには、属する処理への参照が含まれている必要があります。処理事由使用コンポーネントは、そのソース・キーによって識別されます。

METADATA|ActionReasonUsage|SourceSystemOwner|SourceSystemId|ActionId(SourceSystemId)
DELETE|ActionReasonUsage|VISION|ARU_VISION_PROM_PERF|ACT_VISION_PROM

注意: 個別の処理事由使用コンポーネントを削除する場合、ユーザー・キーを使用することはできません。

処理コンポーネントを削除する場合は、その処理事由使用コンポーネントも明示的に削除する必要があります。次のActions.datファイルの例では、処理コンポーネントとその処理事由使用コンポーネントを削除します。すべてのDELETE命令が同じファイルに含まれています。どちらのコンポーネントもソース・キーによって識別されます。

METADATA|Actions|SourceSystemOwner|SourceSystemId
DELETE|Actions|VISION|ACT_VISION_PROM
METADATA|ActionReasonUsage|SourceSystemOwner|SourceSystemId|ActionId(SourceSystemId)
DELETE|ActionReasonUsage|VISION|ARU_VISION_PROM_PERF|ACT_VISION_PROM

処理事由のロード: 例

処理事由はオプションであり、処理に関する追加情報を提供します。たとえば、就業者を昇格・昇進させる事由には、優良なパフォーマンスや年功があります。このトピックでは、HCMデータ・ローダーを使用して処理事由をロードする方法について説明します。

処理事由の作成

次のActionReasons.datファイルの例では、2つの処理事由コンポーネントを作成します。コンポーネントはソース・キーによって識別されます。

METADATA|ActionReasons|SourceSystemOwner|SourceSystemId|ActionReasonCode|ActionReason|StartDate|EndDate
MERGE|ActionReasons|VISION|AR_VISION_PERF|VISION_PERF|Performance|2000/01/01|4712/12/31
MERGE|ActionReasons|VISION|AR_VISION_TXFR|VISION_TXFR|Internal Transfer|2000/01/01|

変換された処理事由名のロード

処理事由名は、これらをロードするユーザーの言語で指定します。処理事由が存在するようになった後、ActionReasonsTranslation.datファイルを指定して、処理事由名をその他の対応言語に変換します。この例では、既存の処理事由の名前を変換します。処理事由コンポーネントは、そのソース・キーによって識別されます。

METADATA|ActionReasonsTranslation|SourceSystemOwner|SourceSystemId|ActionReason|Language
MERGE|ActionReasonsTranslation|VISION|AR_VISION_PERF|Accomplissement|FR
MERGE|ActionReasonsTranslation|VISION|AR_VISION_TXFR|Transfert interne|FR

処理事由の削除

HCMデータ・ローダーを使用して、処理事由コンポーネントを削除できます。このサンプルのActionReasons.datファイルでは、2つの処理事由を削除します。ここでは、ソース・キーを使用してコンポーネントが識別されます。

METADATA|ActionReasons|SourceSystemOwner|SourceSystemId
DELETE|ActionReasons|VISION|AR_VISION_PERF
DELETE|ActionReasons|VISION|AR_VISION_TXFR

銀行のロード: 説明

銀行は、複数の支店を持つことができる金融機関です。外部銀行口座には銀行支店が関連付けられます。銀行、銀行支店および外部銀行口座は、その詳細が非HCM表に格納されるビジネス・オブジェクトです。ただし、これらは、HCMデータ・ローダーを使用してロードできます。このトピックでは、銀行を正常にロードするために理解する必要がある銀行オブジェクトの側面について説明します。

銀行のロード

HCMデータ・ローダーで処理するために、Bank.datファイルで銀行データをロードします。作成時に銀行の一意の参照を指定するには、銀行名または銀行番号の属性を指定する必要があります。国コード属性を指定する必要もあります。

次のBank.datファイルの例では、銀行名と国コードのユーザー・キーを使用して銀行オブジェクトを作成します。ここでは、銀行番号属性も指定します。

METADATA|Bank|BankName|BankNumber|CountryCode
MERGE|Bank|Vision Bank|100001A|CA

銀行の削除

銀行オブジェクトは、HCMデータ・ローダーを使用して削除できません。ただし、必要なくなった、または誤って入力した銀行を非アクティブ化できます。銀行の管理ページにはないこの機能により、監査証跡を維持できます。

次のBank.datファイルの例では、非アクティブ化する銀行オブジェクトの終了日を指定します。既存の銀行を一意に識別するために、国コードと銀行名または銀行番号を使用できます。

METADATA|Bank|BankNumber|CountryCode|EndDate
MERGE|Bank|100001A|CA|2016/03/01

銀行支店のロード: 説明

銀行は、複数の支店を持つことができる金融機関です。外部銀行口座には銀行支店が関連付けられます。銀行、銀行支店および外部銀行口座は、その詳細が非HCM表に格納されるビジネス・オブジェクトです。ただし、これらは、HCMデータ・ローダーを使用してロードできます。このトピックでは、銀行支店を正常にロードするために理解する必要がある銀行支店オブジェクトの側面について説明します。

銀行支店のロード

HCMデータ・ローダーで処理するために、銀行支店データをBankBranch.datファイルに指定する必要があります。銀行支店番号属性(これに対する銀行支店の管理ページのフィールド名は国によって異なります)により、銀行支店が一意に識別されます。これは、国固有の検証によっては、必須属性になる場合があります。

次の属性の組合せのいずれかを指定して、銀行支店および関連する銀行の一意の参照を指定する必要があります。

• 銀行支店名、国コードおよび銀行名または銀行番号

• 銀行支店番号、国コードおよび銀行名または銀行番号

次のBankBranch.datファイルの例では、銀行支店番号、銀行名および国コードのユーザー・キーを使用して銀行支店オブジェクトを作成します。

METADATA|BankBranch|BankBranchNumber|BankBranchName|BankName|CountryCode|EftSwiftCode
MERGE|BankBranch|111111A|Toronto 3|Vision Bank|CA|12345678

銀行支店の削除

銀行支店オブジェクトは、HCMデータ・ローダーを使用して削除できません。ただし、必要なくなった、または誤って入力した銀行支店を非アクティブ化できます。銀行支店の管理ページにはないこの機能により、監査証跡を維持できます。

次のBankBranch.datファイルの例では、銀行支店を非アクティブ化するための終了日を指定します。

METADATA|BankBranch|BankBranchNumber|BankName|CountryCode|EndDate
MERGE|BankBranch|111111A|Vision Bank|CA|2015/04/01

外部銀行口座のロード: 説明

外部銀行口座レコードでは、銀行支店の銀行口座の詳細が保持されます。銀行口座は、個人への支払を実行するために、支払方法によって使用されます。銀行、銀行支店および外部銀行口座は、その詳細が非HCM表に格納されるビジネス・オブジェクトです。ただし、これらは、HCMデータ・ローダーを使用してロードできます。このトピックでは、外部銀行口座を正常にロードするために理解する必要がある外部銀行口座オブジェクトの側面について説明します。

銀行および銀行支店

外部銀行口座オブジェクトを作成するには、銀行口座が保持される銀行と銀行支店の両方を作成する必要があります。

外部銀行口座のロード

HCMデータ・ローダーで処理するために、外部銀行口座データをExternalBankAccount.datファイルに指定します。次の属性の組合せのいずれかを使用して、外部銀行口座の一意の参照を指定する必要があります。

• 口座番号、国コード、通貨コード、銀行名および銀行支店名または銀行支店番号

• 口座番号、国コード、通貨コード、銀行番号および銀行支店名または銀行支店番号

外部銀行口座所有者コンポーネントによって、口座が属する個人が識別されます。1つの銀行口座を複数の所有者(いずれかがプライマリ所有者である必要があります)に関連付けることができます。外部銀行口座所有者コンポーネントをロードするには、弁別子ExternalBankAccountOwnerを使用します。プライマリ所有者を識別するには、関連するコンポーネントのPrimaryFlag属性をYに設定します。次の属性の組合せのいずれかを使用して、外部銀行口座所有者の一意の参照を指定する必要があります。

• 口座番号、個人番号、国コード、通貨コード、銀行名および銀行支店名または銀行支店番号

• 口座番号、個人番号、国コード、通貨コード、銀行番号および銀行支店名または銀行支店番号

次のExternalBankAccount.datファイルの例では、外部銀行口座コンポーネントを作成して、2人の所有者(そのうちの1人はプライマリ所有者)に関連付けます。

METADATA|ExternalBankAccount|BankNumber|BankBranchNumber|CountryCode|AccountNumber|IBAN|AccountName|AccountType|CurrencyCode
MERGE|ExternalBankAccount|100001A|111111A|CA|12345678|CA23 ANBK 3350 1234 5678 20|J and P Smith||USD
METADATA|ExternalBankAccountOwner|BankNumber|BankBranchNumber|CountryCode|AccountNumber|CurrencyCode|PersonNumber|PrimaryFlag
MERGE|ExternalBankAccountOwner|100001A|111111A|CA|12345678|USD|121011|Y
MERGE|ExternalBankAccountOwner|100001A|111111A|CA|12345678|USD|126231|N

外部銀行口座の削除

外部銀行口座コンポーネントは、HCMデータ・ローダーを使用して削除できません。ただし、銀行口座を非アクティブにできます。次のExternalBankAccount.datファイルの例では、InactiveFlag属性を含めてYに設定することによって、外部銀行口座を非アクティブにします。

METADATA|ExternalBankAccount|BankNumber|BranchNumber|CountryCode|CurrencyCode|AccountNumber|InactiveFlag
MERGE|ExternalBankAccount|100001A|111111A|CA|USD|12345678|Y

カレンダ・イベントのロード: 説明

カレンダ・イベントは、祝日や工場閉鎖などの、勤務時間に影響を及ぼす可能性があるイベントです。カレンダ・イベントはオプションです。カレンダ・イベントによって影響を受ける就業者が属する必要がある地理的階層または組織階層を指定します。この階層は、関連するカレンダ・イベントをロードする前に存在する必要があります。このトピックでは、HCMデータ・ローダーを使用して正常にロードするために理解する必要があるカレンダ・イベントの側面について説明します。また、ここでは、カレンダ・イベントをロードする方法について、例を示して説明します。

カレンダ・イベントの参照カテゴリ

カレンダ・イベントには、PER_CAL_EVENT_CATEGORY参照タイプで定義されたカテゴリが指定されます。この参照タイプは、1つの提供された値として、祝日を示すPHの値を持ちます。追加のカテゴリを使用する場合は、カレンダ・イベントをロードする前に定義する必要があります。「設定および保守」作業領域で「勤務可能性参照の管理」タスクを使用します。

カレンダ・イベント対象範囲

カレンダ・イベント対象範囲コンポーネントによって、関連するカレンダ・イベントの適用先の地理的階層または組織階層のブランチが識別されます。階層ブランチのトップ・ノードを識別します。イベントは、そのノードとその子ノードに適用されます。次のことも実行できます。

• 指定した階層ブランチに出現する対象範囲の個々のノードから除外します。

• 階層内の個々のノードに対して、カレンダ・イベント名とそのカテゴリを上書きします。

地理的階層では、カレンダ・イベント対象範囲に含めた事業所のアサイメントを持つすべての就業者に、カレンダ・イベントが適用されます。組織階層では、カレンダ・イベント対象範囲に含めた部門のアサイメントを持つすべての就業者に、カレンダ・イベントが適用されます。影響を受ける就業者には、勤務スケジュールが割り当てられる場合もあります。この場合、勤務スケジュールまたは勤務スケジュール割当にリソース例外として追加した場合にのみ、イベントが就業者に適用されます。

カレンダ・イベントの作成

次のCalendarEvent.datファイルの例では、クリスマスの祝日と経過勤務スケジュールの半日イベントの両方を作成します。ここでは、ソース・キーによってカレンダ・イベントが識別されます。

METADATA|CalendarEvent|Name|Description|Category|CoverageType|ShortCode|StartDateTime|EndDateTime|TreeCode|TreeStructureCode|TreeVersionName|HalfDayForElapsed
MERGE|CalendarEvent|CPTAS6||PH|G|TAS6|2017/07/11 08:00:00|2017/07/11 12:30:00|WFMTL_Global|PER_GEO_TREE_STRUCTURE|WFMTL Bank Geography Version 1|Y
MERGE|CalendarEvent|Christmas Day 2017||PH|G|XMAS2017|2017/12/25 08:00:00|2017/12/25 18:00:00|WFMTL_Global|PER_GEO_TREE_STRUCTURE|WFMTL Bank Geography Version 1|N
METADATA|CalendarEventCoverage|ShortCode|CoverageScope|TerritoryCode|TreeStructureCode|TreeCode|TreeVersionName
MERGE|CalendarEventCoverage|TAS6|I|US|PER_GEO_TREE_STRUCTURE|WFMTL_Global|WFMTL Bank Geography Version 1
MERGE|CalendarEventCoverage|XMAS2017|I|US|PER_GEO_TREE_STRUCTURE|WFMTL_Global|WFMTL Bank Geography Version 1

カレンダ・イベントの削除

勤務スケジュールに割り当てられていないカレンダ・イベントは、削除できます。次のCalendarEvent.datファイルの例では、カレンダ・イベントを削除します。ここでは、ソース・キーによってカレンダ・イベントが識別されます。

METADATA|CalendarEvent|SourceSystemOwner|SourceSystemId
DELETE|CalendarEvent|VISION|XMAS2017

チェックリスト・テンプレートのロード: 説明

新規就業者のオンボーディング用のタスクなど、複数の実行者による一連の関連するタスクを定義するには、チェックリスト・テンプレートを使用します。たとえば、システム・アクセスの提供、バッジの発行、駐車場の割付などのタスクを含む、新規採用に関するチェックリスト・テンプレートを作成できます。このトピックでは、HCMデータ・ローダーを使用してチェックリスト・テンプレート・オブジェクトとその関連するチェックリスト・テンプレート・タスク・コンポーネントを作成および保守する方法について説明します。

チェックリスト・カテゴリおよびタスク名

Checklist.datファイルで、チェックリスト・テンプレートとチェックリスト・テンプレート・タスク・コンポーネントを指定します。チェックリスト・タスク名は、チェックリストで一意である必要があります。チェックリスト・カテゴリは、ターゲット環境のCHECKLIST_CATEGORY参照に存在する必要があります。「設定および保守」作業領域で「チェックリスト参照の管理」タスクを使用します。チェックリスト名とチェックリスト・カテゴリの組合せは、一意である必要があります。

チェックリスト処理、職責範囲および適格プロファイル

チェックリスト・テンプレートで処理を使用することを計画している場合は、それらの処理がターゲット環境に存在する必要があります。

タスク実行者を識別するために職責範囲を使用することを計画している場合は、職責タイプがターゲット環境のPER_RESPONSIBILITY_TYPES参照に存在する必要があります。または、次の表に示す値のいずれかを使用できます。

値	意味
ORA_LN_MGR	ライン・マネージャ
ORA_WORKER	就業者
ORA_INITIATOR	開始者

デフォルトの実行者はライン・マネージャです。

チェックリスト・タスクで適格プロファイルを使用することを計画している場合は、それらの適格プロファイルがターゲット環境に存在する必要があります。

翻訳されたチェックリスト値のロード

次のものを翻訳できます。

• チェックリスト・テンプレート名および摘要

• チェックリスト・タスク名、摘要および処理URL

ロードするユーザーの言語で、これらの値を指定します。チェックリストとタスクが存在するようになったら、これらの値を他の対応言語に翻訳するために、ChecklistTranslation.datファイルとChecklistTaskTranslation.datファイルを指定します。

労働協約のロード: 説明

労働協約は、雇用主と組合または交渉団体の間の合意文書です。これに、表示された従業員の雇用条件が定義されます。労働協約を指すために使用される用語は、国によって異なる場合があります。一般的に、労働協約は指定された期間を対象としています。このトピックでは、HCMデータ・ローダーを使用して正常にロードするために理解する必要がある労働協約オブジェクトの側面について説明します。

労働協約のロードの準備

労働協約は国固有です。そのため、LegislationCodeは、労働協約オブジェクトの必須属性です。

労働協約には、組合、交渉団体および雇用主の任意の組合せを関連付けることができます。たとえば、労働協約を組合に関連付けることも、組合と雇用主の両方に関連付けることもできます。労働協約に関連付けられたすべての組合、交渉団体または雇用主は、それらの労働協約をロードする前にターゲット環境に存在する必要があります。

労働協約の作成

HCMデータ・ローダーで処理するために、労働協約データをCollectiveAgreements.datファイルに指定します。次のCollectiveAgreements.datファイルの例では、ソース・キーを使用して労働協約を作成します。労働協約には、組合、交渉団体および雇用主が関連付けられます。

METADATA|CollectiveAgreements|SourceSystemOwner|SourceSystemId|CollectiveAgreementName|UnionName|EffectiveStartDate|EffectiveEndDate|Status|IdentificationCode|LegalEmployerName|LegislationCode|Description|BargainingUnitCode|EmployeeOrgName|EmployeeOrgContact|EmployerOrgName|EmployerOrgContact
MERGE|CollectiveAgreements|VISION|VISCAGR01|SEIU UHW Medical Social Workers (California, Northern)|Service Employees International Union|2010/01/01|4712/12/31|A|SEIU_UHW_MSW_CA_N|Vision Corporation|US|Collective Agreement covering the medical social workers in northern California affiliated to the Service Employees International Union.|BU_SEIU_UHW_MSW_CA_N|Vision Corporation|John Gorman|Vision Corporation|Jane Reifer

次のCollectiveAgreements.datファイルの例では、ユーザー・キーを使用して労働協約を作成します。労働協約には、組合、交渉団体および雇用主が関連付けられます。

METADATA|CollectiveAgreements|CollectiveAgreementName|UnionName|EffectiveStartDate|EffectiveEndDate|Status|IdentificationCode|LegalEmployerName|LegislationCode|Description|BargainingUnitCode|EmployeeOrgName|EmployeeOrgContact|EmployerOrgName|EmployerOrgContact
MERGE|CollectiveAgreements|SEIU UHW Medical Social Workers (California, Northern)|Service Employees International Union|2010/01/01|4712/12/31|A|SEIU_UHW_MSW_CA_N|Vision Corporation|US|Collective Agreement covering the medical social workers in northern California affiliated to the Service Employees International Union.|BU_SEIU_UHW_MSW_CA_N|Vision Corporation|John Gorman|Vision Corporation|Jane Reifer

労働協約の添付ファイルは、HCMデータ・ローダーを使用してロードできません。

労働協約の更新

既存の労働協約レコードの最初の有効開始日と最終有効終了日は、いずれも変更できません。このため、労働協約レコードを作成するときは、有効開始日が、それらを参照するすべてのレコードの開始日以前になるようにします。

労働協約がアサイメントにリンクされた場合、IdentificationCode、LegislationCode、BargainingUnitCode、LegalEmployerNameまたはLegalEntityIdの属性は編集できません。

翻訳された労働協約名のロード

次のCollectiveAgreementsTranslation.datファイルの例では、既存の労働協約の名前を翻訳します。ここでは、ソース・キーを使用して既存のレコードが識別されます。

METADATA|CollectiveAgreementsTranslation|SourceSystemOwner|SourceSystemId|EffectiveStartDate|EffectiveEndDate|Language|CollectiveAgreementName|Description
MERGE|CollectiveAgreementsTranslation|VISION|VISCAGR01|2001/01/01|4712/12/31|FR|SEIU UHW Travailleurs sociaux medicaux (Californie, Nord)|Convention collective couvrant les travailleurs sociaux medicaux dans le nord de la Californie affiliee a l'Union internationale des employes du service.

• 労働協約の管理: 説明

文書タイプのロード: 説明

パフォーマンス改善プランや認定書などの文書タイプによって、そのタイプの文書の目的および取扱が定義されます。文書タイプを定義する場合は、文書名、日付、発行機関などの属性を含めて、それらが必須かどうかを指定します。また、失効通知期間を指定して、承認が必要かどうかを指定し、文書の複数のオカレンスを有効にすることもできます。このトピックでは、HCMデータ・ローダーを使用して文書タイプを正常にロードするために理解する必要がある文書タイプ・オブジェクトの側面について説明します。

文書カテゴリおよびサブカテゴリ

文書タイプは文書カテゴリに属し、文書のサブカテゴリにも属する場合があります。費用や給与などの文書カテゴリにより、取得と管理が容易になるように文書タイプをグループ化できます。給与カテゴリの標準控除項目や追加所得などの文書のサブカテゴリにより、追加の詳細レベルが提供されます。

文書タイプをロードする前に、参照される文書カテゴリおよびサブカテゴリがターゲット環境に存在するようにします。文書カテゴリを作成するには、「文書参照の管理」タスクを選択します。文書のサブカテゴリを作成するには、「拡張参照コードの管理」タスクを選択します。「設定および保守」作業領域で両方のタスクを実行します。

文書タイプ

文書タイプをロードするときに、作成されるレコードの一意の参照を指定する必要があります。文書タイプが国固有ではない場合は、ソース・キーを指定する必要があります。このルールが存在するのは、Country属性がユーザー・キーの一部を構成するためです。

文書タイプ提供プリファレンス・コンポーネントをロードする場合は、文書タイプ・コンポーネントの階層コードの属性をGENERALまたはPAYROLLに設定します。この属性を除外するか、値を指定しない場合は、文書タイプで文書提供プリファレンスが有効になりません。

文書タイプ提供プリファレンス

文書タイプ提供プリファレンス・コンポーネントによって、ユーザーが、関連するタイプの文書の提供プリファレンスを指定できます。たとえば、給与明細を印刷物とオンラインの両方で提供できることについてのユーザーによる指定を有効化できます。

文書タイプの提供プリファレンスは上書き可能です。つまり、次の文書提供プリファレンスを指定できます。

• 給与法定ユニット・レベル(PAYROLLカテゴリの文書の場合)

• 雇用主レベル(他のすべてのカテゴリの文書の場合)

両方の場合に、提供プリファレンスを部門レベルおよび事業所レベルでさらに上書きできます。

次の図は、文書提供プリファレンスの上書き階層を要約しています。階層のいずれかのレベルのエントリによって、その上のエントリが上書きされます。

就業者上書きの許可の属性をYに設定した場合、就業者は自分の文書提供プリファレンスを指定できます。就業者のプリファレンスによって、他のすべてのレベルのプリファレンスが上書きされます。

• 文書提供プリファレンス: 説明

• 文書タイプおよびカテゴリ: 説明

文書タイプのロード: 例

このトピックでは、HCMデータ・ローダーを使用して文書タイプ・オブジェクトをロードおよび管理する方法について、例を示して説明します。

ソース・キーを使用した文書タイプの作成

次のDocumentType.datファイルの例では、1つのグローバルの文書タイプと1つの国固有の文書タイプを作成します。文書タイプは、ソース・キーを使用して識別されます。

METADATA|DocumentType|SourceSystemOwner|SourceSystemId|DocumentType|Description| LegislationCode|CategoryCode|AuthorizationRequiredFlag|MultipleOccurencesFlag|ActiveInactiveFlag|PublishRequiredFlag|HierarchyCode|DocumentNameRequired|DocumentNumberRequired|DateFromRequired|DateToRequired|IssuingCountryRequired|IssuingLocationRequired|IssuingAuthorityRequired|IssuedDateRequired|CommentsRequired
MERGE|DocumentType|VISION|DTYPETest001|RS Global DocType1|RS Global DocType1 Description||PAYROLL|Y|Y|N|Y|GENERAL|R|R|Y|Y|Y|Y|Y|Y|Y
MERGE|DocumentType|VISION|DTYPETest003|RS US DocType1|RS US DocType1 Description|US|AUDIT|Y|Y|N|Y|PAYROLL|R|R|Y|Y|Y|Y|Y|Y|Y

ユーザー・キーを使用した文書タイプの作成

次のDocumentType.datファイルの例では、1つの国固有の文書タイプを作成します。文書タイプは、ユーザー・キーを使用して識別されます。

METADATA|DocumentType|DocumentType|Description|Country|CategoryCode|AuthorizationRequiredFlag|MultipleOccurencesFlag|ActiveInactiveFlag|PublishRequiredFlag|HierarchyCode|DocumentNameRequired|DocumentNumberRequired|DateFromRequired|DateToRequired|IssuingCountryRequired|IssuingLocationRequired|IssuingAuthorityRequired|IssuedDateRequired|CommentsRequired
MERGE|DocumentType|US Audit Doc Type|US Audit Doc Type Description|United States|AUDIT|Y|Y|Y|Y|PAYROLL|R|R|Y|Y|Y|Y|Y|Y|Y

注意: 文書タイプがグローバルの場合は、ユーザー・キーではなく、ソース・キーを指定する必要があります。この要件が存在するのは、Countryがユーザー・キーの必須属性であるためです。

提供プリファレンスを指定した文書タイプの作成

次のDocumentType.datファイルの例では、文書タイプ、給与法定ユニットおよび部門の提供プリファレンスを指定した国固有の文書タイプを作成します。文書タイプと提供プリファレンスは、ソース・キーを使用して識別されます。

METADATA|DocumentType|SourceSystemOwner|SourceSystemId|DocumentType|Description| LegislationCode|CategoryCode|AuthorizationRequiredFlag|MultipleOccurencesFlag|ActiveInactiveFlag|PublishRequiredFlag|HierarchyCode|DocumentNameRequired|DocumentNumberRequired|DateFromRequired|DateToRequired|IssuingCountryRequired|IssuingLocationRequired|IssuingAuthorityRequired|IssuedDateRequired|CommentsRequired
MERGE|DocumentType|VISION|DTYPETest003|RS US DocType1|RS US DocType1 Description|US|AUDIT|Y|Y|N|Y|PAYROLL|R|R|Y|Y|Y|Y|Y|Y|Y
METADATA|DeliveryPreference|SourceSystemOwner|SourceSystemId|DocumentTypeId(SourceSystemId)|InitialConsentValueFlag|OnlineConsentRequiredFlag|OnlineEnabledFlag|PaperEnabledFlag|AllowWorkerOverrideFlag|EmailEnabledFlag|LegislationCode|LevelCodeName|DocumentTypeCountry|DocumentTypeLegislationCode|PayrollStatutoryUnitName|DepartmentName
MERGE|DeliveryPreference|VISION|DTYPETest003_Pref0|DTYPETest003|N|N|Y|Y|N|N|US||US|US||
MERGE|DeliveryPreference|VISION|DTYPETest003_Pref1|DTYPETest003|N|N|Y|Y|N|N|US|Payroll Statutory Unit|US|US|GBI HCM Widgets USA|
MERGE|DeliveryPreference|VISION|DTYPETest003_Pref2|DTYPETest003|N|N|Y|Y|N|N|US|Department|US|US|GBI HCM Widgets USA|HCM-1001-Corporate

翻訳された文書タイプおよび摘要のロード

次のDocumentTypeTranslation.datファイルの例では、既存の文書タイプとその摘要を翻訳します。ここでは、ソース・キーを使用して文書タイプが識別されます。

METADATA|DocumentTypeTranslation|SourceSystemOwner|SourceSystemId|BaseDocumentType|LegislationCode|SourceLang|Language|DocumentType|Description
MERGE|DocumentTypeTranslation|VISION|DTYPETest001|RS Global DocType1||US|JP|RS Global DocType1 JP|RS Global DocType1 DESC JP
MERGE|DocumentTypeTranslation|VISION|DTYPETest003|RS US DocType1|US|US|JP|RS US DocType1 JP|RS US DocType1 DESC JP

文書タイプの削除

文書タイプは、そのタイプの文書レコードが存在しない場合にのみ削除できます。文書タイプを削除すると、関連するすべての提供プリファレンスも削除されます。次のDocumentType.datファイルの例では、ソース・キーによって識別された文書タイプを削除します。

METADATA|DocumentType|SourceSystemOwner|SourceSystemId
DELETE|DocumentType|VISION|DTYPETest001
DELETE|DocumentType|VISION|DTYPETest003

次のDocumentType.datファイルの例では、ユーザー・キーによって識別された文書タイプを削除します。

METADATA|DocumentType|DocumentType|Description|Country
DELETE|DocumentType|US Audit Doc Type|US Audit Doc Type Description|United States

拡張参照コードのロード: 例

拡張参照コードを使用して、参照コードのサブカテゴリを指定します。HCMデータ・ローダーを使用して拡張参照オブジェクトをロードするときには、関連付けられた参照コードがすでに存在する必要があります。参照コードが特定の国別仕様を対象としている場合は、これらの国別仕様についてのみ拡張参照コードを指定できます。たとえば、参照コードに+FRタグが含まれる場合は、FR国別仕様コードについてのみ拡張参照コードを指定できます。このトピックでは、HCMデータ・ローダーを使用して拡張参照オブジェクトをロードする方法について、例を示して説明します。

拡張参照コードの作成

このサンプルのExtendedLookupCode.datファイルでは、CONTRACT_TYPE参照タイプの拡張参照コードを作成します。この場合、拡張参照コードはソース・キーを使用して識別されます。

METADATA|ExtendedLookupCode|SourceSystemOwner|SourceSystemId|LookupType|LookupCode|LegislationCode|ExtendedLookupCode|ExtendedLookupCodeName
MERGE|ExtendedLookupCode|VISION|ELC_CONTRACT_LIMITED|CONTRACT_TYPE|5|NO|L|Limited Contract
MERGE|ExtendedLookupCode|VISION|ELC_CONTRACT_DIRECTOR|CONTRACT_TYPE|FR_CEO_MANDATE|FR|DC|Director Contract

変換された拡張参照コード名のロード

拡張参照コードの名前は、これらをロードするユーザーの言語で指定します。コードが存在するようになった後、ExtendedLookupCodeTranslation.datファイルを指定して、拡張参照コードの名前をその他の対応言語に変換します。この例では、既存の拡張参照コードの名前を変換します。この場合、コードはそのソース・キーによって識別されます。

METADATA|ExtendedLookupCodeTranslation|SourceSystemOwner|SourceSystemId|Language|ExtendedLookupCodeName
MERGE|ExtendedLookupCodeTranslation|VISION|ELC_CONTRACT_LIMITED|FR|Contrat a Duree Limitee

拡張参照コードの削除

HCMデータ・ローダーを使用して、拡張参照オブジェクトを削除できます。このサンプルのExtendedLookupCode.datファイルでは、CONTRACT_TYPE参照コードの特定の拡張参照コードを削除します。この場合、拡張参照コードはソース・キーを使用して識別されます。

METADATA|ExtendedLookupCode|SourceSystemOwner|SourceSystemId
DELETE|ExtendedLookupCode|VISION|ELC_CONTRACT_LIMITED
DELETE|ExtendedLookupCode|VISION|ELC_CONTRACT_DIRECTOR

国別仕様データ・グループのロード: 例

国別仕様データ・グループは、給与と関連データの分割に使用されます。企業が運営されている国ごとに、少なくとも1つの国別仕様データ・グループが必要です。各国別仕様データ・グループには、国別仕様コード、通貨および原価配賦キー・フレックスフィールドが保持されています。また、1つ以上の給与法定ユニットにも関連付けられています。このトピックでは、HCMデータ・ローダーを使用して国別仕様データ・グループ・オブジェクトをロードおよび管理する方法について、例を示して説明します。

国別仕様データ・グループの作成

このサンプルのLegislativeDataGroup.datファイルでは、イギリスの国別仕様データ・グループを作成します。この場合、国別仕様データ・グループはそのソース・キーを使用して識別されます。コードは、通貨および国別仕様に対して指定されます。

METADATA|LegislativeDataGroup|SourceSystemOwner|SourceSystemId|Name|LegislationCode|DefaultCurrencyCode
MERGE|LegislativeDataGroup|VISION|LDG_VI_UK|Vision UK|GB|GBP

このサンプルのLegislativeDataGroup.datファイルでは、アメリカの国別仕様データ・グループを作成し、原価配賦キー・フレックスフィールドに関連付けます。

METADATA|LegislativeDataGroup|Name|Territory|DefaultCurrency|StructureInstanceName
MERGE|LegislativeDataGroup|Vision US|United States|US Dollar|System Test Costing

国別仕様データ・グループの削除

HCMデータ・ローダーを使用して、国別仕様データ・グループ・オブジェクトを削除できます。このサンプルのLegislativeDataGroup.datファイルでは、国別仕様データ・グループを削除します。この場合、国別仕様データ・グループはそのソース・キーによって識別されます。

METADATA|LegislativeDataGroup|SourceSystemOwner|SourceSystemId
DELETE|LegislativeDataGroup|VISION|LDG_VI_UK

名前書式のロード: 説明

名前書式は、名や姓など、個々の名前コンポーネントを組み合せて完全な個人名を形成するためのルールのセットです。名前書式は、国別仕様および名前書式タイプに固有です。名前書式タイプは、表示名、リスト名、順序名および氏名です。事前定義されたグローバル書式は、書式タイプや国別仕様に書式が存在しない場合に使用されます。このトピックでは、HCMデータ・ローダーを使用して名前書式オブジェクトをロードする方法について説明します。

書式マスクについて

書式マスクは、名前書式の構成に使用されるコードの文字列です。コードは、必要な名前コンポーネント、記号および特殊文字を表します。名前コンポーネントを識別するには、次の表に示すコードを使用します。

コード	名前コンポーネント
$FIR$	名
$LAS$	姓
$MID$	ミドル・ネーム
$PLN$	旧姓
$KNA$	呼称
$HNS$	表彰
$PNA$	プリフィクス
$SUF$	サフィクス
$TIT$	敬称
$MLR$	軍階級
$INF1$から$INF30$	「名前情報1」から「名前情報30」

記号および特殊文字には、次の表に示すコードを使用します。

コード	説明	値
$SPA$	スペース
$COM$	カンマ	,
$OPE$	左カッコ	(
$CLO$	右カッコ	)
$QUO$	引用符	"
$DOT$	ピリオド	.
$SLA$	スラッシュ	/
$COL$	コロン	:
$SEM$	セミコロン	;
$ATT$	アットマーク	@

書式マスクの構成

書式マスクは、次の条件を満たしている必要があります。

• 縦棒(|)で開始および終了します。

• 各名前コンポーネントを2つの縦棒(||)で区切ります。

縦棒は、HCMデータ・ローダーの.datファイル用のデフォルト・デリミタです。異なるデフォルト・デリミタを選択しなかった場合は、名前書式マスク内の縦棒の前にHCMデータ・ローダーのエスケープ文字を追加する必要があります。エスケープ文字を使用すると、HCMデータ・ローダーで、書式マスク内のデリミタが無視されます。デフォルトのエスケープ文字はバックスラッシュ(\)です。たとえば、名前書式Title Last Name, First Name (Known As)に書式マスクを指定するには、次の表に示すように、名前の各エレメントにコードを指定します。

エレメント	コード
Titleスペース	$TIT$$SPA$
Last Name,スペース	$LAS$$COM$$SPA$
First Nameスペース	$FIR$$SPA$
(Known As)	$OPE$$KNA$$CLO$

書式マスクでは、各名前コンポーネントを2つの縦棒で区切る必要があります。

$TIT$$SPA$\|\|$LAS$$COM$$SPA$\|\|$FIR$$SPA$\|\|$OPE$$KNA$$CLO$

さらに、書式マスクは、単一の縦棒で開始および終了する必要があります。

\|$TIT$$SPA$\|\|$LAS$$COM$$SPA$\|\|$FIR$$SPA$\|\|$OPE$$KNA$$CLO$\|

名前書式の作成

このサンプルのNameFormat.datファイルでは、Title First Name Last Nameという書式でフランスの表示名を作成します。名前書式は、そのソース・キーによって識別されます。

METADATA|NameFormat|SourceSystemOwner|SourceSystemId|FormatName|LegislationCode|UserFormatChoice|FormatMask
MERGE|NameFormat|VISION|NF_FR_L_DISP|DISPLAY_NAME|FR|L|\|$TIT$$SPA$\|\|$FIR$$SPA$\|\|$LAS$\|

名前書式の削除

名前書式が使用中でない場合、HCMデータ・ローダーを使用して名前書式オブジェクトを削除できます。このサンプルのNameFormat.datファイルでは、名前書式を削除します。この場合、名前書式はそのソース・キーによって識別されます。

METADATA|NameFormat|SourceSystemOwner|SourceSystemId
DELETE|NameFormat|VISION|NF_FR_L_DISP

Personタイプのロード: 説明

システムPersonタイプは事前定義された値であり、これにより、従業員や派遣就業者などのグループを識別します。システムPersonタイプを作成、編集または削除することはできません。ただし、各システムPersonタイプは1つ以上のユーザーPersonタイプに関連付けられ、これにより、グループがさらに分類されます。ユーザーPersonタイプは、作成、編集および削除できます。たとえば、「従業員」システムPersonタイプのユーザーPersonタイプとして、関連就業者や在宅就業者を定義できます。任意のシステムPersonタイプについて、1つのユーザーPersonタイプをデフォルト値として指定する必要があります。このトピックでは、HCMデータ・ローダーを使用してユーザーPersonタイプ・オブジェクトをロードおよび管理する方法について、例を示して説明します。

Personタイプの作成

このサンプルのPersonType.datファイルでは、「従業員」システムPersonタイプのユーザーPersonタイプとして、士官と兵を作成します。この場合、Personタイプはソース・キーを使用して識別されます。

METADATA|PersonType|SourceSystemOwner|SourceSystemId|SystemPersonType|UserPersonType|ActiveFlag|DefaultFlag
MERGE|PersonType|VISION|PT_EMP_OFFICER|EMP|Officer|Y|N
MERGE|PersonType|VISION|PT_EMP_RATING|EMP|Rating|Y|N

変換されたPersonタイプ名のロード

Personタイプ名は、これらをロードするユーザーの言語で指定します。Personタイプが存在するようになった後、PersonTypeTranslation.datファイルを指定して、Personタイプ名をその他の対応言語に変換します。この例では、既存のPersonタイプの名前を変換します。Personタイプは、そのソース・キーによって識別されます。

METADATA|PersonTypeTranslation|SourceSystemOwner|SourceSystemId|Language|UserPersonType
MERGE|PersonTypeTranslation|VISION|PT_EMP_OFFICER|FR|Officier

Personタイプの削除

Personタイプが使用中でない場合、HCMデータ・ローダーを使用してPersonタイプ・オブジェクトを削除できます。このサンプルのPersonType.datファイルでは、Personタイプおよび変換されたすべてのバージョンのPersonタイプ名を削除します。この場合、Personタイプはそのソース・キーによって識別されます。

METADATA|PersonType|SourceSystemOwner|SourceSystemId
DELETE|PersonType|VISION|PT_EMP_OFFICER
DELETE|PersonType|VISION|PT_EMP_RATING

リソース例外のロード: 例

リソース例外とは、勤務可能性の、勤務スケジュールやスケジュール割当からの逸脱です。リソース例外では、リソースが勤務できない時期を定義します。たとえば、就業者がトレーニングに参加するため、指定した日付の間は勤務できない場合があります。オプションで、特定の勤務スケジュールまたはスケジュール割当に対してリソース例外を作成します。関連付けられるリソース例外を作成するには、勤務スケジュールまたはスケジュール割当が存在する必要があります。このトピックでは、HCMデータ・ローダーを使用してリソース例外オブジェクトをロードする方法について、例を示して説明します。

リソース例外の作成

このサンプルのResourceException.dat fileでは、病院の予約のためにリソース例外を作成します。この場合、リソースはそのソース・キーによって識別されます。

METADATA|ResourceException|SourceSystemOwner|SourceSystemId|ExceptionName|StartDateTime|EndDateTime
MERGE|ResourceException|VISION|RE_VISION_HOSPITAL|Hospital Appointment|2015/08/15 08:00:00|2015/08/15 17:00:00

リソース例外の削除

勤務スケジュールによってリソース例外が参照されていない場合、HCMデータ・ローダーを使用して、そのリソース例外オブジェクトを削除できます。このサンプルのResourceException.datファイルでは、未使用のリソース例外を削除します。この場合、リソースはそのソース・キーによって識別されます。

METADATA|ResourceException|SourceSystemOwner|SourceSystemId
DELETE|ResourceException|VISION|RE_VISION_HOSPITAL