(JPN) コントロール テーブルの設定
日本のコントロール テーブルを設定するには、郵便番号 JPN コンポーネント (POSTAL_CODE_TBL)、学齢テーブル JPN コンポーネント (EDLVLAG_TBL_JPN)、パラメータ設定 JPN コンポーネント (SETUP_SALCOMP_JPN) を使用します。
次の各トピックでは、学齢の概要およびテーブルの設定について説明します。
ページ名 |
定義名 |
用途 |
---|---|---|
EDLVLAG_TBL_JPN |
企業で使用される学齢基準を設定します。 |
|
SETUP_SALCOMP_JPN |
学齢計算に使用される基準日を設定し、特定の給与コンポーネントに等級範囲チェックを適用するかどうかを指定します。 |
|
RUNCTL_POSTAL_JPN |
日本郵政が提供している郵便番号の CSV ファイルをインポートします。 |
|
POSTAL_TBL_JPN |
日本の郵便番号を管理するための情報の入力、または正常にインポートされなかったデータの追加を行います。 |
学齢テーブルによって、システム内に既に設定されている最終学歴を、採用時の "学齢基準" にリンクできます。学齢基準を使用して従業員の "学齢生年月日" が計算されます。学齢生年月日を使用すれば、いつの時点においても従業員の学齢を算出できます。従業員の学齢は、学齢給の計算に使用されます。学齢給とは、年功給の一種です。
従業員の学齢の計算
このトピックでは、学齢給の決定において、学齢基準がどのように使用されるかについて説明します。このトピックでは、説明の中で次の略語が使用されることがあります。
略語 |
意味 |
---|---|
ELABa (Eductaion Level Age Basis) |
学齢基準 (採用時) |
AELABa (Adjusted Education Level Age Basis) |
調整済み学齢基準 (採用時) |
ELABi (Education Level - Adjusted Birth Date) |
学齢生年月日 |
SCB (Standard Calculation Birthday) |
学齢計算基準の月日 |
CSD (Company Seniority Date) |
入社年月日 |
ELA (Education Level Age) |
学齢 |
A 社では、4 年制大学卒業者の学齢基準 (ELABa) を 22 と設定しています。また、学齢計算基準の月日 (勤続年数の加算日) は 4 月 1 日に設定されています。
ここで、A 社従業員の大和太郎さんの場合を例にして考えてみましょう。大和太郎さんは、1972 年 2 月 6 日生まれで、1994 年 3 月 23 日に 22 歳で 4 年制大学を卒業しました。その後 2 年間は世界を旅して回りました。A 社は、1996 年 6 月 1 日付けで大和太郎さんを従業員として採用しました。入社日が 4 月 1 日でないのは、大和太郎さんが 1996 年 5 月に日本に帰国したためです。採用されたとき大和太郎さんは 24 歳でした。
大和太郎さんの学齢給を計算するには、毎年大和太郎さんの学齢を計算する必要があります。その計算には、学齢生年月日を使います。
従業員の学齢生年月日の計算には、学齢基準、入社年月日、および学齢計算基準の月日が使用されます。
従業員の入社年月日の月日が学齢計算基準の月日の前か後かによって、学齢基準の調整が必要となる場合があります。調整されたものを、"調整済み学齢基準" (AELABa) と呼びます。従業員の入社年月日 ([配属開始日] フィールドの値) の月日が、学齢計算基準の月日よりも後の場合、従業員の学齢基準は 1 (年) 差し引かれます。
大和太郎さんの場合、入社日が 6 月 1 日で、A 社の学齢計算基準の月日である 4 月 1 日よりも後なので、大和太郎さんの学齢基準は 1 年引かれます。4 月 1 日かそれ以前に入社していれば、学齢基準の調整は必要ありません。
大和太郎さんの調整済み学齢基準は、次のように導き出されます。
CSD (入社年月日の月日 = 6 月 1 日) > SCB (学齢計算基準の月日 = 4 月 1 日) であるため、調整 = -1
この -1 によって、学齢基準が調整されます。
ELABa (学齢基準) - 1 = AELABa (調整済み学齢基準)
したがって、大和太郎さんの学齢基準は、次の値になります。
22 – 1 = 21
次に、この調整済み学齢基準 (21) を使用して、大和太郎さんの学齢生年月日を求めます。
計算式は次のとおりです。
入社年 - AELABa (調整済み学齢基準) = ELABi (学齢生年月日)
すなわち
1996 – 21 = 1975
したがって、学齢給の計算に使用する大和太郎さんの学齢生年月日は、会社の学齢計算基準の月日との組み合わせによって、1975 年 4 月 1 日になります (実際の生年月日は 1972 年 2 月 6 日)。
ここで、学齢生年月日がどのくらい重要か見てみましょう。
1 年後の 1997 年、大和太郎さんの学齢が必要となります。計算は次のようになります。
SCB (計算実行年の学齢計算基準の月日) - ELABi (学齢生年月日) = ELA (学齢)
すなわち
1997 年 4 月 1 日 - 1975 年 4 月 1 日 = 22
これは、大学新卒者の学齢と同じです。この一連の計算によって、大和太郎さんが卒業後 2 年間旅をしたこと、その年の会社の学齢計算基準の月日より後に入社したことが、学齢の調整に全て反映され、それに基づいて適切な学齢給が導き出されます。
注: 4 月から 6 月までの 2 か月間がそれほど大きくないと会社が判断した場合、大和太郎さんの学齢生年月日を 1975 年 4 月 1 日から、1974 年 4 月 1 日に変更できます。その場合、1997 年の計算では、大和太郎さんの学齢が 23 (1974 年 4 月 1 日~ 1997 年 4 月 1 日) となり、新卒者が 1 年間勤務した場合と同じになります。
学齢テーブル ページ (EDLVLAG_TBL_JPN) を使用して、企業の学齢基準を設定します。
ナビゲーション
画像: 学齢テーブル ページ
次の例では、学齢テーブル ページのフィールドおよびコントロールを説明します。このページのフィールドおよびコントロールの定義は後で説明します。

学齢基準は、従業員の学齢生年月日の計算に使用されます。さらに、その学齢生年月日を使用して、従業員の学齢と学齢給が計算されます。
フィールドまたはコントロール |
定義 |
---|---|
学齢基準 |
最初のフィールドで選択した最終学歴に関連付ける値です。この学齢基準を使用して従業員の学齢生年月日が計算され、その学齢生年月日を使用して従業員の学齢が計算されます。 |
注: [最終学歴] の値は、最終学歴テーブルで設定されたトランスレート値です。各従業員の最終学歴は、個人情報ページの [個人情報の履歴] グリッドで、このテーブルにアクセスして設定します。これらのトランスレート値を変更 (非アクティブにするなど) した場合、その値を使用している従業員レコードも、他の値を使うように変更する必要があります。トランスレート値を追加し、学齢基準と関連付ける場合は、このページにも同じ値を追加して学齢基準を割り当て、最終学歴テーブルとの同期をとる必要があります。このページで値を追加せずに、新しい最終学歴の値を個人情報詳細ページの [個人情報の履歴] グリッドなどで使用しても、従業員の学齢生年月日は計算されず、フィールドは空白のままになります。この結果、従業員の学齢も計算されません。
計算ルール設定ページ (SETUP_SALCOMP_JPN) を使用して、学齢計算に使用される基準日を設定し、特定の給与コンポーネントに等級範囲チェックを適用するかどうかを指定します。
ナビゲーション
画像: 計算ルール設定ページ
次の例では、計算ルール設定ページのフィールドおよびコントロールを説明します。このページのフィールドおよびコントロールの定義は後で説明します。

学齢計算基準の月日
この月日を基準に、全従業員の学齢が計算されます。
フィールドまたはコントロール |
定義 |
---|---|
学齢基準月 |
学齢計算の基準の月を入力します。たとえば、1 月ならば "1"、2 月ならば "2" と入力します。学齢計算基準の月が設定され、この月を基準として、従業員の年功が計算されます。各従業員の学齢を計算する際に使用されます。 |
学齢基準日 |
学齢計算の基準の日を入力します。たとえば、[学齢基準月] に "4"、[学齢基準日] に "1" と入力すると、4 月 1 日が学齢計算基準の月日になります。 |
範囲型給与チェック適用 |
このチェック ボックスをオンにすると、"職務データ - 給与" ページで、給与レート コード クラスが [DFRPAY] (範囲型給与レート コード) の給与レート レコードが追加された場合に、そのコンポーネントの金額が給与等級テーブルで定義した等級の範囲内に収まっているかどうかが確認されます。 この確認は、レコードが手動で追加された場合でも、システムにより自動追加された場合でも実行されます。 また、このチェック ボックスをオンにすると、1 人の従業員の給与データ ページに対して DFRPAY (範囲型給与レート コード) クラスの給与レート コードが 1 つしか入力されないようにチェックがかかります。 |
郵便番号のロード JPN ページ (RUNCTL_POSTAL_JPN) を使用して、日本郵政が提供している郵便番号の CSV ファイルをインポートします。
ナビゲーション
画像: 郵便番号のロード JPN ページ
次の例では、郵便番号のロード JPN ページのフィールドおよびコントロールを説明します。このページのフィールドおよびコントロールの定義は後で説明します。

注: このページを使用する前に、日本郵政の Web サイトから CSV ファイルをダウンロードして解凍し、自社内に設置している FTP サーバーに転送する必要があります。CSV ファイルは、Shift-JIS の文字セットでエンコードされている必要があります。郵便番号のロード プロセスを使用する前に、PeopleTools ユーティリティ メニューで URL データを定義する必要があります。
「住所フォーマット ページ」を参照してください。
フィールドまたはコントロール |
定義 |
---|---|
URL ID |
郵便番号データを含む CSV ファイルが保存されている FTP URL を選択します。 |
全ての都道府県 |
全ての都道府県の郵便番号データをロードする場合、このオプションを選択します。 注: 郵便番号データの行数は 120,000 行を超えるため、全ての行をインポートする際は、バッチ処理のパフォーマンスを考慮してください。 |
選択した都道府県 |
特定の都道府県の郵便番号をロードする場合、このオプションを選択します。 |
ロード結果
住所 1 または住所 1 のフリガナの文字数が 55 文字を超える場合、フィールドは空白となります。また、住所 1 または住所 1 のフリガナが長すぎるために複数の行に分割されている場合、最初の行のみがインポートされ、残りの行は未インポート行としてログ レポートに出力されます。
住所 1 および住所 1 のフリガナ の "以下に掲載がない場合 (イカニケイサイガナイバアイ)" を削除する場合、その文字列をストリング テーブル (プログラム ID は HGJPPSTL) に登録します。削除するテキストを [ストリング テキスト] フィールドに入力します。
都道府県、市区町村、住所 1 が同じ 1 つの郵便番号で、読み方が異なるため住所 1 のフリガナが複数ある場合など、1 つの郵便番号に複数行存在するときには、全ての行が表示されないことがあります。
目的のデータがロードされない場合、郵便番号 JPN ページでデータを追加または編集します。
郵便番号ロード プロセスのログ レポート
プロセスが完了すると、インポートされた行数、およびインポートされなかった行数とその詳細な理由がリストされたプロセス ログ レポートが生成されます。行がインポートされなかった理由として、以下が考えられます。
インポート ファイルが見つからなかった。
ファイルが正しくフォーマットされていない。
インポート ファイルが、[選択した都道府県] フィールドで指定した都道府県以外の都道府県のデータを含むファイルである。
郵便番号 JPN ページ (POSTAL_TBL_JPN) を使用して、日本の郵便番号を管理するための情報の入力、または正常にインポートされなかったデータの追加を行います。
ナビゲーション
画像: 郵便番号 JPN ページ
次の例では、郵便番号 JPN ページのフィールドおよびコントロールを説明します。このページのフィールドおよびコントロールの定義は後で説明します。

フィールドまたはコントロール |
定義 |
---|---|
自治体コード |
この郵便番号が属す日本の自治体コードを選択して入力します。 |
都道府県 |
この郵便番号の都道府県をリストから選択します。 |