有効日を変更したときに雇用変更を保持する例

新しい有効日が前のレコードと次のレコードの有効日の間である必要がある

有効日が2019年3月1日のアサイメント行を追加した場合、日付が2019年2月1日と2019年6月1日の間で変更された場合にのみ変更が保持されます。

日付	処理	ビジネス・ユニット	事業所	ジョブ	部門	等級	追加情報
2019年1月1日	採用	ビジネス・ユニット1	事業所1	ジョブ1	部門1	等級1	履歴レコード
2019年2月1日	異動	ビジネス・ユニット1	事業所1	ジョブ1	部門2	等級1	履歴レコード
2019年3月1日	事業所の変更	ビジネス・ユニット1	事業所2	ジョブ1	部門2	等級1	新規に追加されたレコード
2019年6月1日	昇格・昇進	ビジネス・ユニット1	事業所1	ジョブ1	部門2	等級1	先日付レコード

有効日の変更時に値が無効になる

新しく変更した日付時点で有効でない値を入力すると、その値は古い値に戻されます。この例を使用して、この動作を見てみます。

等級1は1951年1月1日からアクティブで、等級11は2019年6月1日からアクティブです。

日付	処理	ビジネス・ユニット	事業所	ジョブ	部門	等級	追加情報
2019年1月1日	採用	ビジネス・ユニット1	事業所1	ジョブ1	部門1	等級1	該当なし
2019年6月1日	昇格・昇進	ビジネス・ユニット1	事業所1	ジョブ1	部門2	等級11	新規に追加されたレコード

新しく追加されたレコードの日付を2019年6月1日から2019年5月1日に変更すると、等級11は新しい日付時点で有効ではないため、等級値は等級1に戻されます。

雇用変更を保持中の依存フィールドのデフォルト設定

事業所が部門からデフォルト設定されるアプリケーション設定について考えます。次の例では、ユーザーは部門をSalesからFinanceに変更し、事業所のデフォルトはTrivandrumになり、ユーザーはこれをクリアします。

処理	有効日	部門属性	事業所属性(依存属性)	ユーザー変更	アプリケーションの動作
採用	2010年1月1日	Sales	Hyderabad	該当なし	該当なし
異動	2010年3月01日	Finance	Null	Trivandrumの事業所をクリア	Trivandrumの事業所がクリアされました
異動	2010年3月15日	Finance	Null	変更有効日	Finance部門と空白の事業所を表示します

次の条件が当てはまる場合、依存属性に対するユーザー入力は無視されます。

依存属性の初期値はnullで、トランザクション中に依存属性のデフォルト値を手動でクリアしました。
雇用トランザクションの有効日を変更しました。

次の従業員の例では、採用時に部門と事業所が移入されず、ユーザーが異動時に部門の値をHuman Resourcesとしてロードします。

処理	有効日	部門属性	事業所属性(依存属性)	ユーザー変更	アプリケーションの動作
採用	2010年1月1日	値なし	値なし	該当なし	該当なし
異動	2010年1月10日	Human Resources	Null	Human Resourcesの選択 Bangaloreの事業所をクリア	Bangaloreの事業所がクリアされました
異動	2010年2月1日	Human Resources	Bangalore	変更有効日「割当」セクションにアクセス	Bangaloreの事業所がデフォルト設定されました

この例では、就業者の異動処理中に、ユーザーはHuman Resources部門を選択し、Bangalore事業所がデフォルト設定されます。次に、Bangaloreの事業所をクリアして空白にします。ユーザーが異動トランザクションの有効日を変更すると、Bangaloreの事業所がクリアされていても、Bangaloreは再度デフォルト設定されます。ユーザーは、Bangaloreの事業所を手動で再度クリアする必要があります。この動作は、最初に事業所がなく、その後、ユーザーがデフォルトの事業所をクリアするために発生します。このシナリオでは、事業所属性に対する初期値とユーザー変更後の値の間に変更がないため、アプリケーションではその値をユーザー変更とみなさず、値を保持しません。