月25件のROE、2つの給与システムEIコンプライアンスレポートを一括で作成

雇用保険規則(SOR/96-332、s.19(3))に基づき、カナダのすべての雇用主は、収入の中断(従業員が被保険者収入を受け取らなくなった日)から5暦日以内に雇用記録書を発行する義務があります。従業員1人であれば、5日間は余裕のある期間です。しかし、中規模の雇用主(季節的な一時解雇があるエドモントンの建設会社、離職率の高い小売チェーン、短期契約でスタッフが入れ替わるバンフのホスピタリティ事業者)は、月に1件の離職を処理するわけではありません。20件、25件、30件を処理します。それぞれに5日間の期限があり、Ceridian Dayforce、ADP Workforce Now、QuickBooks Canada Payrollから出力されるBlock 15Aの被保険者時間合計、Block 15Bの被保険者収入合計、Block 15Cの理由コードがあります。給与システムは各ROEを数秒で自動生成します。構造的なギャップはその後にあります。給与システムは一度に1人の従業員を処理しますが、人事部門は月次のEIレポート(1つのスプレッドシートに25行のBlockデータ、給与台帳と照合されたBlock 15Aの合計、離職書類と照合されたBlock 15Cの理由コード)を必要としており、すべてをコンプライアンス期間内にまとめる必要があります。この期間中、毎日が誰かの締め切りです。

手入力をやめよう — AIに読み取らせるだけ
画像やPDFをアップロード — 10秒で構造化データに
今すぐ試す
登録不要 · カード不要 · 10秒で結果
異なる給与システムから複数のカナダの雇用記録書(ROE)フォームを一括処理し、1つの統合されたサービス・カナダEIコンプライアンススプレッドシートにまとめる様子

重要なポイント

  1. 月25件の離職は、それぞれ独自のタイマーで動く25件の独立した5日間のROE期限を生み出しますが、月次のEIコンプライアンスレポートでは、経理責任者の締め切りまでにBlock 15A、15B、15Cの全25行を1つのスプレッドシートにまとめる必要があります。
  2. 月75分の転記時間のうち10分は、各給与プロバイダーの異なるレイアウトでBlock 15Aを視覚的に探し直すことに費やされます。Ceridian、ADP、QuickBooksは同じ53ブロックを異なる視覚的配置で印刷するため、プロバイダーを切り替えるたびに脳が再調整を行う必要があります。
  3. 列スキーマを一度定義すれば(Block 15Aの被保険者時間合計、Block 15Bの被保険者収入合計、Block 15Cの理由コード)、どのプロバイダーからの月次25件のROEバッチも同じ抽出プロセスで処理され、25件の個別転記ではなく1回の操作で統合スプレッドシートが生成されます。

なぜ25件の雇用記録書は1件とは異なる問題なのか

1件の雇用記録書からスプレッドシートにデータを抽出するのは単純な作業です。雇用記録書抽出ガイドでは、53ブロックの構造、理由コード、および単一の雇用記録書のワークフローについて説明しています。しかし、1件の雇用記録書を処理することと、月に25件を処理することは、同じことを25回繰り返すという問題ではありません。月次バッチ規模では、単一の雇用記録書規模では存在しない3つの構造的な問題が発生し、入力を速くしてもそれらの問題は解決しません。

1. 各ROEの期限は独立していますが、月次レポートは集約されます

最終出社日が11月3日の従業員のROE期限は11月8日です。別の従業員の最終被保険日が11月17日であれば、期限は11月22日です。3人目は11月28日→12月3日となります。25件の離職は、それぞれが独自の時計で刻む25の独立した5日間カウントダウンを生み出します。しかし、12月5日に人事マネージャーが経理部長に送付する月次EIコンプライアンスレポート(スプレッドシート)には、ブロック15A、15B、15Cの25行すべてが一箇所に必要です。ROEを入手次第、一つずつ転記(CeridianのPDFを開き、12のフィールドを再入力し、閉じる)していくと、25件目の転記におけるブロック15Cのコードが、2週間前に行った3人目の従業員の理由コードの修正と矛盾する可能性があります。そして、その矛盾は、スプレッドシートを従業員名で並べ替え、同一人物の行が2つあることに気づくまで見えません。代わりに月末に一括処理すると、25件すべての転記が同じ月の最終週に集中します。これはまさに12月5日の期限が迫っている時期であり、たった1日の病欠や給与システムの障害で、コンプライアンスレポート全体がペナルティ対象となってしまいます。

2. プロバイダー間のレイアウトの違いによる負荷は、バッチ処理の規模に比例して増大します

Ceridian Dayforceからの1件のROEでは、Ceridianのレイアウト上でブロック15Aを視覚的に見つけるのに少し時間がかかります。ADP Workforce Nowからの1件のROEでは、さらに少し時間をかけて方向を再調整する必要があります。ブロック15Aの位置が異なり、ブロック15Cは別の隅にあり、2ページ目の支払期間グリッドの開始位置の垂直オフセットも異なります。各システムから1件ずつ連続して処理する場合、2回の方向再調整のための中断が発生します(それぞれ約10秒で、どの尺度でも無視できる程度です)。同じバッチセッションで12件のCeridian ROE、8件のADP ROE、5件のQuickBooks ROEを処理する場合、プロバイダーを切り替えるたびに同じ方向再調整のペナルティが発生します。しかし、今回は2回の切り替えではなく、Ceridianフォルダ、ADPフォルダ、QuickBooksフォルダ間を移動するたびに切り替えが発生します。つまり、セッション中に3~5回のプロバイダー切り替えが発生し、そのたびに現在のレイアウトでブロック15Aがどこにあるかという身体的な記憶が途切れます。75分間ROEデータを転記する給与管理担当者は、そのうち約10分を視覚的な再調整に費やしており、データ入力には費やしていません。これは、同じブロックデータが異なる帳票の異なる位置に表示されるために、コンプライアンス期間の10分の1が無駄になっていることを意味します。

3. 件数が増えるほど例外ケースも増え、転記のリズムが崩れる

月に3件の離職票を処理する企業では、例外ケースは月に1件程度かもしれません。しかし、月に25件処理する企業では、毎月4~5件の例外に直面します。例えば、退職代休手当を受け取った従業員のため、ブロック11(最終支払日)が実際の最終勤務日より後になるケース。年度途中で給与計算プロバイダーを変更したため、同じ継続雇用期間に対して2つのシステムから2枚のCode Kの雇用記録書を発行しなければならないケース。離職期間がオンタリオ州北部と南部という2つの異なるEI経済地域にまたがり、ブロック15Aの被保険者時間の基準が問題となるケース。ブロック15CがCode MからCode Aに訂正されたため、以前発行した雇用記録書を修正版に差し替え、監査人から原本と修正版の両方を並べて提示するよう求められるケース。こうした例外ケースが発生するたびに、手動の転記作業は中断されます。タイピングを止め、例外を調査し、解決してから次の雇用記録書に戻るまでに10分が経過し、最初の15件を処理していた勢いは失われています。この中断こそが、ワークフローそのものなのです。

プロバイダ間の統合:月次バッチにレイアウト非依存の処理が必要な理由

雇用記録書は連邦政府が定める様式(様式INS5153)であり、53の番号付きブロックの内容と順序は規則で固定されています。ブロック10は常に最初の就業日、ブロック15Aは常に総被保険者時間、ブロック15Cは常に雇用記録書発行理由です。内容は標準化されています。しかし、各ブロックのページ上の位置は標準化されておらず、各給与計算ソフトウェアプロバイダは、同じ53ブロックを独自のデザインで視覚的に配置しています。

これは微妙なデザインの違いではありません。Ceridian Dayforceは、IDブロック(1~8)を上部の1つのテーブルに配置し、被保険者時間と収入(15A/15B)をサマリーブロックに分離し、支払期間(17A~17D)を2ページ目に横向きで印刷します。ADP Workforce Nowは、ブロックを2段組の縦長レイアウトで順次配置します。QuickBooks Canadaは、関連するブロック(すべての収入フィールド、すべての控除フィールド)をグループ化し、簡略化した表示にします。Wagepointはまた別のグリッドを使用します。Ceridianの雇用記録書でブロック15Aの位置を学習したテンプレートベースの抽出ツールは、バッチ内のすべてのADPの雇用記録書で間違った場所を参照し、空白セルを生成するか、さらに悪いことに、ADPレイアウトのその位置にあるフィールドの値を生成します。これは、出力をざっと確認した人間が見逃す可能性のある誤った属性です。

これは、T4バッチ処理ガイドで説明されているのと同じ構造上の問題であり、3つの給与計算プロバイダからの300枚のT4スリップを、T4サマリー用の1つの統合スプレッドシートにまとめる必要があります。雇用記録書版は、より頻度が高く(年次ではなく月次)、より重要です。なぜなら、その出力は個人の給付金支払いに影響を与える雇用保険の決定に使用され、CRAへの提出書類だけの問題ではないからです。T4バッチでブロック15Aの合計が間違っていると、6か月後にPIER調整レターが届きます。雇用記録書バッチでブロック15Aの合計が間違っていると、従業員は今日、420時間の雇用保険受給資格基準を下回ることになります。そして、法的に給付を受ける権利がある従業員に却下通知が届きます。

セマンティック抽出は、抽出ステップでプロバイダ間の統合を処理し、後処理ではありません。ツールに各ソフトウェアの雇用記録書上のブロック15Aの位置を教える代わりに、カスタム列抽出は出力列を「ブロック15A 総被保険者時間」と定義し、AIがブロックラベルの意味を理解することで、どのプロバイダの様式に表示されているかに関係なく値を見つけられるようにします。12件のCeridianの雇用記録書、8件のADPの雇用記録書、5件のQuickBooksの雇用記録書を含むバッチは、同じ列スキーマで実行されます。テンプレートの切り替え、座標の再学習、プロバイダ間の視覚的な再調整は必要ありません。通常、25件の個別の書き起こし後にExcelで行われる統合(コピー&ペースト操作のたびに行のずれが発生するリスクがある)は、抽出自体の中で行われます。

JPG/PNG/PDF AI抽出

ファイルは安全に処理され、保存されることはありません。

月次ROEバッチワークフローの設定 — 一度設定すれば、あとは繰り返すだけ

バッチワークフローは、25回の個別転記作業を、1回のエンドツーエンド抽出処理に置き換えます。月初めや導入時に一度設定すれば、給与計算で新しいROEバッチが生成されるたびに再利用できます。月末、季節的なレイオフ後、またはリストラで退職者が集中した場合のアドホックなタイミングでも構いません。設定が投資であり、毎月の実行がそのリターンです。

1

カラムスキーマを定義 — 一度定義すれば、すべての給与プロバイダー、すべての月で共通

フィールド名は、列ヘッダーとして表示したい名前をそのまま入力してください。中規模カナダ企業向けの実用的な月次EIレポートスキーマの例は次のとおりです:従業員名、従業員SIN、ブロック10 初日出勤日、ブロック11 最終支給日、ブロック15A 総被保険者時間数、ブロック15B 総被保険者収入、ブロック15C 理由コード、ブロック16 支払期間種別、ファイル名。これは、月次の離職サマリーを作成し、退職日でソートして期限を把握し、各行を元のROE PDFにトレースバックできるようにする最小セットです。レポートで期間ごとの時間数をブロック15Aのサマリーと照合する必要がある場合は、支払期間の列(直近1~4期間分のブロック17A~17D)を追加してください。この同じカラムスキーマは、Ceridian、ADP、QuickBooks、およびROE Webを使用しない小規模事業主からのスキャンされた紙のROEでも機能します。AIがフォームの座標ではなくブロックの意味を読み取るためです。

抽出中の検証のために、計算列(詳細は後述)を追加してください。これにより、データがスプレッドシートに到達する前に不一致をフラグ付けします。ブロック15Aとブロック17Cの期間時間数の合計をクロスチェックしたり、ブロック15Cが有効なコード文字であることを確認したり、ブロック11がファイル日付から5暦日以内であるかを計算したりします。

2

当月のROEを一括アップロード — すべてのプロバイダー、すべての形式に対応

各給与システムの出力フォルダーからROEをまとめてください(CeridianがエクスポートしたPDF、ADPが生成したPDF、QuickBooksが作成したPDF)。それらを1つのバッチアップロードにドロップします。抽出エンジンはそれらを同時に処理します。各ROEは同じカラムスキーマで個別に読み取られ、すべての結果が統合されたスプレッドシートにマージされます。小規模事業主が退職者に郵送したスキャンされた紙のROE(小売、飲食、農業業界では今でも一般的なシナリオです)も、Ceridianのデジタル生成PDFと同じ方法で読み取られます。AIがブロックラベルの内容を読み取り、入力媒体を読み取るわけではないからです。

英国の退職者書類に同じバッチ処理アプローチを適用する場合は、英国P45バッチ処理ガイドを参照してください。このガイドでは、Sage、BrightPay、QuickBooksからの月次P45を、検索可能な退職者データベースに統合する同等のワークフローを説明しています。

3

エクスポート、検証、提出 — そしてスプレッドシートを6年間のコンプライアンス記録として保管してください

統合されたExcelファイルをダウンロードしてください。サマリーフィールドはROEごとに1行で表示され、支払期間の詳細は含まれている場合に別のタブに表示されます。検証チェック(次のセクションで説明します)を実行し、レビューが必要な行にフラグを立て、不一致を解決してください — 誤ってコード化されたブロック15Cに対する修正済みROE、最終被保険日が給与計算で誤って入力された従業員の訂正などです。ROE Webを通じてROEを提出し、退職する従業員にコピーを配布し、バッチスプレッドシートを恒久的なコンプライアンス記録として保管してください。雇用保険規則では、ROEの対象年度から6年間の保管が義務付けられています。ROEごとに1行ずつ、ファイル名にタイムスタンプが付いたバッチ抽出スプレッドシートは、監査証跡であり、6年間のコンプライアンスアーカイブでもあります。

手入力をやめよう — AIに読み取らせるだけ
画像やPDFをアップロード — 10秒で構造化データに
今すぐ試す
登録不要 · カード不要 · 10秒で結果

大規模検証:サービス・カナダが指摘する前に差異を発見する計算列

月に25件の雇用記録書を処理する場合、すべての行を手動で確認する——ブロック15Aが各従業員の給与台帳の年度累計被保険者時間と一致するか、ブロック15Cが離職証明書類と一致するか、最終支払日が法定期間内であるかを確認する——には、集中的なクロスチェックに約45分かかります。提出前に一度だけ行う場合です。ほとんどの月では、期限に追われて、体系的な検証ではなく、明らかな外れ値を素早くスキャンするだけの確認になります。このスキャンをすり抜けたエラー——従業員の状況に合わないが入力自体は可能なブロック15Cのコードミス、給与期間の集計が不完全だったために実際の被保険者時間より200時間少ないブロック15Aの合計——は、提出済みの雇用記録書としてサービス・カナダのシステムに登録され、従業員または当局が差異を発見した時点でようやく修正プロセスが始まります。

計算列は、検証を抽出処理そのものに組み込みます。計算ルールで列を定義すると、AIが抽出と同時にチェックを実行し、データがスプレッドシートに届く前に、専用の列に結果を出力します。これにより、検証が「時間があれば抽出後に確認」から「毎回、抽出と同時にフラグを立てる」に変わります。

バッチの雇用記録書ワークフローを「抽出のみ」から「抽出と検証」に変える3つの計算列:

計算列名ルールロジック検出内容
時間クロスチェックabs ≤ 5 の場合 "OK"、それ以外は "確認必要 — 差異: [実際の差]"最も一般的な雇用記録書のデータ整合性の問題:時間が誤った給与期間が存在し、被保険者時間の概要(ブロック15A)と期間ごとの明細(ブロック17C)の間に差異が生じます。ある給与計算でブロックされた期間やカウントミスした残業時間が原因でギャップが生じますが、手動レビューではほとんど見つかりません——25人の従業員に対して53行もの期間データを手作業で合計する人はいないからです。
理由コード検証ブロック15Cが有効なセット{A, B, C, D, E, F, G, H, J, K, M, N, P, Z}に含まれる場合 "有効"、それ以外は "無効なコード"キー入力ミス——"E"の代わりに"Q"、"I"の代わりに"1"——により、サービス・カナダのシステムが拒否する文字が生成されます。この計算列は、データがスプレッドシートに届く前にブロック15Cが認識された雇用記録書の理由コード文字であるかを検証し、認識されない文字を即座にフラグ付けして、元の給与システムで修正できるようにします。
期限監視ブロック11 + 5暦日 ≥ 本日の日付 の場合 "期限 — [ブロック11 + 5]"、それ以外は "提出済み"5暦日の法定期限は従業員ごとであり、バッチごとではありません。最終支払日が11月29日の従業員の期限は12月4日です。バッチが12月6日に処理された場合、その行は2日間の期限超過となり、雇用保険規則に基づき延滞提出による罰則が科される可能性があります。この列は期限超過の行を即座に表面化させ、別途管理が必要なカレンダーではなく、スプレッドシート自体から提出順序を優先順位付けできるようにします。

計算列アプローチは人間によるレビューを置き換えるものではありません。状況的にコードEが必要だったにもかかわらずコードAが発行された場合でも、「有効なコード」チェックはAが正当な文字であるため通過します。しかし、人が行うべきではない機械的な検証(列合計の集計、コード文字の有効セットとの照合、日付からの暦日数の計算)を排除し、人間の注意を、人にしかできない判断ベースの検証(理由コードの文字が、従業員の退職書類に記録された実際の離職事象と一致するかどうか)に集中させます。

季節レイオフ:同じ日に40件の雇用記録書が発行される場合

アルバータ州とBC州の建設会社、大西洋州の漁業事業、バンフとウィスラーの観光事業では、離職は毎月一定のペースで発生するわけではありません。これらは集中したイベントとして発生します。シーズンの終わりに、現場スタッフ全員または季節労働者全員が同じ日にレイオフ通知を受け取ります。エドモントンの屋根工事会社で42人の現場従業員がいる場合、11月28日に操業を停止します。42件のブロック15Aの被保険者時間の合計と42件のコードAの理由コードが42件の雇用記録書に記載され、それぞれが5暦日以内(12月3日)にサービス・カナダに提出される必要があります。会社がADP Workforce Nowで給与計算を実行している場合、42件すべての雇用記録書が同じシステムから1つのバッチで生成され、それぞれが同じレイアウト、同じブロック位置、同じ視覚的配置を持ちます。複数拠点の冬季閉鎖がどのように連鎖的な5日間の雇用記録書提出期限を生み出すか(6拠点、66件の雇用記録書、1つの11月)を段階的に確認するには、カナダの建設業における季節的な雇用記録書ラッシュに関するガイドをご覧ください。

バッチ抽出は簡単です。42件すべてをアップロードし、同じ列スキーマで処理し、42行の1つのスプレッドシートを受け取ります。しかし、季節雇用主はしばしばバッチ抽出を特に価値あるものにする複雑な問題に直面します。中小規模事業者の経営者は、多くの場合、40以上のROE Web認定給与計算サービスのいずれかを使用するか、サービス・カナダのROE Webポータルを通じて直接、自分で給与計算を実行しています。紙の雇用記録書提出を置き換えるために導入されたROE Webは、雇用記録書データのサービス・カナダへの電子提出を処理します。雇用主の内部記録用の要約スプレッドシートは生成されません。ROE Webを通じて42件の雇用記録書を提出した後、給与データは雇用主のドライブのスプレッドシートではなく、サービス・カナダのシステムに保存されます。雇用主は、誰がどのブロック15Aの合計を受け取ったか、誰のコードAがどのEI経済地域のしきい値をトリガーしたか、どの従業員の被保険者時間が420時間の統一入職要件を下回ったかの記録を引き続き必要とします。抽出がギャップを埋めます。雇用記録書(給与システムからのPDFまたはROE Web提出のスクリーンキャプチャのいずれか)をバッチ処理して、ROE Webが提供しない内部コンプライアンス記録として機能するスプレッドシートに変換します。

サービス・カナダは、季節雇用主がROE Webを通じて雇用記録書を電子的に提出することを推奨しています。これは、紙の雇用記録書を5日間の期限を過ぎさせる可能性のある休日期間の郵便遅延を正確に回避するためです。電子提出は提出側を処理します。バッチ抽出は記録保持側を処理します。そして、42件すべてのコードAの雇用記録書と、ブロック15Aの合計が年末の給与台帳と照合されたスプレッドシートを提示できる季節雇用主は、監査人のレビューが数日ではなく数時間で完了する雇用主です。

ROE Webとバッチ抽出:二者択一ではなく、2つのステップ

ROE Webはサービス・カナダの電子提出ポータルであり、雇用記録書を提出する際の推奨方法です。紙のフォーム、郵送の遅延、サービス・カナダの受付システムへの手動データ入力が不要になります。ただし、ROE Webは提出ツールであり、報告ツールではありません。その役割は、ROEデータをサービス・カナダのシステムに送信することです。特定の月に発行されたすべてのROEの雇用者向けスプレッドシートを生成するものではありません。給与台帳と照合した全離職者のブロック15A合計を示す照合レポートを作成するものでもありません。誰が、なぜ退職し、被保険者時間と被保険者収入がいくらだったかを照会できる記録を雇用者に提供するものでもありません。

答え:ROE Webでの提出と、内部記録のためのバッチ抽出の両方です。どちらか一方ではありません。雇用者は、サービス・カナダへの最速かつ最も信頼性の高いチャネルであるため、ROE Webを通じて提出します。雇用者は、EI規則に基づく6年間の保存義務により自社で記録を保持する必要があるため、同じROEをバッチ処理してスプレッドシートにします。ROEごとに1行あり、ブロック15Aの時間で検索でき、ブロック11の最終支払日で並べ替えられ、ブロック15Cの理由コードで絞り込めるスプレッドシートは、コンプライアンス要件と離職分析の内部ニーズの両方を満たす記録です。抽出せずに提出するだけでは、データはサービス・カナダにのみ存在します。提出せずに抽出するだけでは、法定の提出要件に違反します。両方を組み合わせることで、政府への送信と雇用者側での保存という完全な義務を、同じデータを共有しながらも目的の異なる2つの補完的なステップでカバーできます。

よくある質問

デジタルROEと紙のスキャンが混在する場合、バッチ処理は機能しますか?

はい。抽出機能は、Ceridian、ADP、QuickBooksなどの給与ソフトウェアからのPDFエクスポートと、電子提出を利用しない小規模雇用者の紙のROEスキャンを同じように読み取ります。AIは入力元ではなく、ブロックの番号とラベルで識別するためです。ADPからのデジタルROE30件と、下請け業者の手書きフォームの紙のROEスキャン5件が混在するバッチでも、同じ抽出パスで同じ列スキーマの下で処理されます。唯一の要件は、紙のスキャンが判読可能であることです。これは人間がフォームを読む場合と同じ要件です。劣化が激しい紙のROEについては、判読限界の説明が単一ROE抽出ガイドで説明されています。

同じバッチ内に複数のROEを持つ従業員を扱うにはどうすればよいですか?例えば、給与移行によるコードKのROEと、離職時のコードAのROEがある場合です。

同じ従業員のコードKのROE(給与計算サービス事業者の変更)とコードAのROE(一時解雇)は、スプレッドシートに2行として表示されます。コードKのROEは移行日までの被保険者時間と収入を報告し、コードAのROEは移行日から離職日までの時間と収入を報告します。SINで識別される同じ従業員の両方の行のブロック15Aを合計する計算列により、雇用期間全体の総被保険者時間が算出されます。これは、サービス・カナダがEI受給資格を判断するために必要な数値です。バッチ抽出で両方の行が表示され、計算列がそれらを結び付けます。

先月のバッチに含まれていた雇用記録書を修正する必要がある場合はどうすればよいですか?

給与システムから修正版の雇用記録書を生成してください。「修正」ボックスにチェックが入り、修正されたブロック値が記載されます。それを今月のバッチに含めてください。出力の「ファイル名」列で、元の雇用記録書とは別のものとして識別されます。コンプライアンススプレッドシートで、元の行を修正行に置き換え、修正日と理由を記入してください。抽出処理自体はバッチ間で状態を保持しません。各雇用記録書を新しい書類として読み取るため、古いデータが残るリスクはありません。6年間のコンプライアンス記録には修正データが含まれ、修正の経緯(ブロック10の元の雇用記録書日付、スプレッドシートの注記列の修正日)が監査要件を満たします。

バッチ抽出は、被保険者期間中に複数の州で働いていた従業員の雇用記録書も処理できますか?

はい。雇用記録書の様式にはブロック8(雇用州)が含まれており、抽出処理は他のブロックと一緒にこれを読み取ります。州コードは、従業員の受給資格基準に適用されるEI経済地域の失業率を決定します。経済地域は州境と異なる場合があります(例:オンタリオ州北部はオンタリオ州南部とは別のEI経済地域です)。そのため、州コードだけでは受給資格基準を完全に決定できません。しかし、ブロック8をスプレッドシートの列に取り込むことで、従業員の勤務地記録や、サービス・カナダが公開している現在のEI経済地域失業率と照合するための出発点が得られます。バッチアプローチでは、これらの複数州の雇用記録書も単一州のものと同様に処理します。州コードは、AIがブロックラベルから読み取る単なる別のフィールドです。

バッチ内のどの雇用記録書がまだ提出が必要で、どの雇用記録書がサービス・カナダに提出済みかを追跡するにはどうすればよいですか?

列スキーマに「提出状況」という列を追加してください。AIにこの列を入力させようとしないでください。AIは雇用記録書を読み取りますが、雇用記録書には提出状況は記載されていません。バッチ抽出でスプレッドシートが生成された後、手動で(または追跡システムで)別の列を追加し、各雇用記録書がROE Webを通じて提出済みかどうかを記録してください。抽出スプレッドシートは、各行を元の雇用記録書にリンクするファイル名列があるため、提出状況を追跡するためのマスターリストになります。提出状況列で並べ替えて未提出の雇用記録書を抽出し、ブロック11の最終支払日を使用して、次にどの雇用記録書を提出する必要があるかを優先順位付けしてください。このアプローチにより、提出ワークフローと抽出ワークフローを分離できます。抽出はデータを取得し、トラッカーは提出状況を取得します。両方のシステムが互いを理解する必要はありません。

月に10件未満の離職しかない企業でも、バッチワークフローは有効ですか?

バッチ抽出の基準は、特定の従業員数ではありません。重要なのは、月ごとのROEの列スキーマに一貫性があり、その再利用に価値があるかどうかです。月に6件の離職(年間72件)がある企業でも、毎月同じBlock 15A、15B、15Cの列を定義します。セットアップ時間(列スキーマを一度定義する作業)は、12回の月次バッチ全体に分散されます。手動で6件のROEを転記する場合、約18分(1件あたり3分)かかり、負担にならない時間です。しかし、年間72件のROEでは、転記に21時間を費やすことになり、その時間のすべては、給与システムがすでに生成しているデータを転記するために使われます。重要なのは、6件のROEがバッチ抽出を正当化する十分な量かどうかではなく、列を定義するために30分を一度投資し、年間21時間(毎年)を取り戻せるかどうかです。

📮 contact email: [email protected]