EWAを勤怠管理、給与計算、ERPと統合するにはどのようなデータが必要か？

EWAを勤怠管理、給与計算、ERPと統合するにはどのようなデータが必要か？

EWAを勤怠管理、給与計算、ERPと統合するには、企業は最低限5つのデータグループが必要です：従業員プロファイル、承認済みの勤務、給与計算期間とルール、調整または控除項目、早期給与受け取りの取引。すべては統一された従業員コード、ステータス、更新時刻、データバージョン、トレースログを使用する必要があります。良好なアーキテクチャは、データを迅速に伝達するだけでなく、重複支払いを防ぎ、遅延修正データを処理し、各取引を照合する必要があります。

> 注意: この記事は、EWA（給与前払い）システムの参考アーキテクチャを示しています。フィールド名、ステータス、承認フロー、実際の会計処理方法は、Nhan Kietと企業が統合調査段階で確認する必要があります。

> 用語の説明: EWA（勤務日数に基づく給与受け取り） · HRIS/HRM（人事情報システム） · ERP（企業資源計画システム） · 給与計算 · API（ソフトウェア接続インターフェース） · バッチ（バッチ処理） · SFTP（セキュアファイル転送） · 冪等性（重複防止：同じ要求を何度も送信しても結果は一つ） · UAT（受入テスト） · go-live（本稼働） · ロールバック（巻き戻し） · webhook/callback（システム間の自動通知） · トークン（元データの代替コード） · データ辞書 · 正規データソース · リトライ（再試行） · タイムアウト（待ち時間切れ）。

なぜEWAは勤怠管理、給与計算、ERPと同時に接続する必要があるのか？

EWAは、労働者が給与を受け取る前に3つの質問に答える必要があります：

1. この人は現在働いており、プログラムに参加しているか？

2. 現時点までに、どれだけの給与が受け取れる資格があるか？

3. 以前の取引と保持する必要がある項目を考慮した後、受け取れる金額はいくらか？

人事システムは通常、身元と勤務状況を確認します。勤怠管理システムは、勤務日数または勤務時間を記録します。給与計算は給与ルール、給与期間、調整項目を管理します。ERPまたは会計システムは記録、照合、決算をサポートします。支払いシステムは最終的な送金ステータスを提供します。

一つのソースにのみ接続すると、EWAは労働者を確認できるが、承認済みの勤務日数を知らない場合があります。または、勤務日数を確認できるが、給与期間がロックされているかどうかを知らない場合があります。または、送金が行われたが、給与計算が取引を受け取って照合していない場合があります。したがって、最も重要な点は「APIを接続すること」ではなく、完了した勤務から決済済みの取引までの一貫したデータチェーンを確立することです。

1. 全体的なデータアーキテクチャ

参考アーキテクチャは次のように構成できます：

flowchart TD
    A["HRIS: 従業員"] --> D["統合レイヤー"]
    B["勤怠管理: 承認済み勤務"] --> D
    C["給与計算: 給与期間とルール"] --> D
    D --> E["EWA制限計算エンジン"]
    E --> F["EWAアプリケーション"]
    F --> G["支払いシステム"]
    G --> H["給与計算、ERP、会計の照合"]
    H --> E

各データ領域には一つの正規データソース（system of record）があるべきです。HRIS、給与計算、EWAが同じ属性を3つの異なる方法で修正することは避けるべきです。

2. 最低限必要な従業員データリスト

「必要かもしれない」という理由だけで、すべての人事プロファイルを同期するべきではありません。適切な原則は、特定された目的のために必要なデータを正確に収集し、伝達することです。

完全な口座番号は、実際に送金に必要な領域にのみ存在し、適切に権限付与され保護されるべきです。テスト環境では、偽データまたはマスクされたデータを使用し、実際のデータをコピーしないでください。

3. 勤怠データと承認ステータス

EWAは「月間勤務合計」という一つの数字だけを受け取るべきではありません。システムは、どのデータが確認され、どのデータが変更可能かを知るための十分な情報を必要とします。

通常必要なフィールドには以下が含まれます：

• employee_id: 統一された従業員コード;

• work_date: 勤務日;

• shift_id: シフトコード（シフト管理を行っている場合）;

• regularhours, overtimehours: 通常勤務時間と残業時間;

• attendance_status: 出勤、休暇、欠勤、または対応するステータス;

• approval_status: 承認待ち、承認済み、拒否、調整、またはロック;

• approvedby, approvedat: ポリシーが要求する場合の承認者と承認時刻;

• sourceupdatedat, record_version: レコードの更新時刻とバージョン;

• source_system: データを生成したシステム。

なぜ「承認済み」ステータスが重要なのか？

一度のカードスワイプが必ずしも有効な勤務とは限りません。従業員は退勤を忘れたり、シフトを間違えて登録したり、管理者の承認後に調整が行われることがあります。企業は、どのステータスがEWAの制限に含まれるかを明確に統一する必要があります（承認済み勤務とは何か？を参照）。

以下は例示的なレコードです：

{
  "employee_id": "EMP-000123",
  "work_date": "2026-08-18",
  "shift_id": "SHIFT-A",
  "regular_hours": 8,
  "overtime_hours": 0,
  "approval_status": "APPROVED",
  "source_updated_at": "2026-08-19T02:15:30Z",
  "record_version": 3
}

これは安全なデータ例であり、公式の給与前払いAPI仕様ではありません。

4. 給与データと調整項目

給与計算データは「承認済み勤務」を「資格のある給与部分」に変換するのに役立ちます。データセットには通常以下が含まれます：

• 給与期間ID payperiodid と開始日、終了日;

• 給与グループと支払いサイクル;

• 合意済みの計算式に必要な給与基準または単価;

• 収入コード earning_code;

• 関連する調整、保留、または控除項目;

• 勤務締め日と給与表ロック時刻;

• 給与期間のステータス：オープン、処理中、ロック済み、または決算済み;

• 通貨単位と丸めルール;

• 適用される計算式/ポリシーのバージョン。

給与明細のすべての要素がEWAの制限に含まれるわけではありません。基本給、手当、残業、ボーナス、コミッションは、それぞれ異なる確実性と承認時期を持ちます。企業は、どの項目が計算され、どのステータスから計算され、どのように制限されるかを明確に示すルール表を作成する必要があります。

ルール表にはどのような列が必要か？

この表の実際の値は、企業と実施者が確認する必要があります。給与項目名から推測するべきではありません。

5. 早期給与受け取りの取引データ

各早期給与受け取り要求は、独立して追跡可能な取引である必要があります。

参考となる取引ライフサイクルは次の通りです：CREATED → VALIDATING → PROCESSING → SUCCEEDED または FAILED。送金結果が不明な場合、取引はUNKNOWNまたは同等のステータスで調査されるべきであり、失敗と仮定して自動的に再送金するべきではありません。業務が発生した場合、返金と照合済みステータスも必要です。

6. API、バッチファイル、手動同期の選択

すべての企業に適した方法はありません。各システムの成熟度に応じて複数の方法を組み合わせることができます。

HTTP APIを使用する場合、企業はOpenAPI Specificationを使用して統合契約を記述し、エンドポイント、データ構造、応答を統一することができます。OpenAPIはHTTP APIを記述する標準であり、技術的に有用な選択肢であり、EWAを実装するための必須条件ではありません。

7. 識別と重複データ防止

誤った識別は最も危険なリスクの一つです。メール、電話番号、口座番号は変更される可能性があるため、主要な従業員キーとして適していません。

推奨事項：

• 企業内で不変のemployee_idを使用する;

• 複数の単位をサポートするプラットフォームではemployeridまたはlegalentity_idと組み合わせる;

• 退職者のコードを新しい従業員に再利用しない;

• HRISと給与計算が異なるコードを使用している場合、マッピングテーブルを維持する;

• 給与グループ、部門、勤務ステータスの変更に有効日を記録する;

• 業務キーに基づいて重複をチェックし、同じ内容だけでなく。

バッチファイルの場合、各ファイルにはロットコード、作成時刻、レコード総数、チェックサムが必要です。APIの場合、各取引作成要求にはidempotency_keyが必要です。

8. 冪等性と照合：異なる2つの保護層

冪等性は、同じ要求が何度も送信されても一つの業務結果しか生成しないことを保証します。例えば、送金命令を送信した後にアプリケーションがタイムアウトした場合。同じidempotency_keyを使用して再送信すると、システムは古い取引またはそのステータスを返すべきであり、新しい支払いを作成するべきではありません。

照合は、各システムが同じ取引を記録しているかどうかを確認します（勤怠管理から照合までの給与前払いプロセスに関連）。適切なモデルは3方向の照合です：

1. EWAプラットフォーム内の取引;

2. 銀行または支払い機関からの結果;

3. 給与計算/ERPまたは承認済みの決算記録。

照合レポートには少なくとも以下を示すべきです：

• 完全に一致する取引;

• EWAにあるが支払い結果がない;

• 支払い結果があるが給与計算/ERPにない;

• 金額、手数料、受取人、給与期間の不一致;

• 返金取引だが更新されていない;

• 重複レコードまたは順序の誤った更新。

各差異には担当者、処理ステータス、エラークローズの証拠が必要です。

9. エラー処理、リトライ、警告

すべてのエラーが自動的に再試行されるべきではありません。

すべてのリクエストにはcorrelation_idがあり、システム全体でトレース可能であるべきです。警告には取引ID、エラータイプ、時刻、ソースシステム、次の処理ステップを含めるべきですが、ログにパスワード、APIキー、完全な機密データを含めるべきではありません。

10. API要求の例

{
  "idempotency_key": "ewa-demo-20260818-0001",
  "employee_id": "EMP-000123",
  "pay_period_id": "2026-08",
  "requested_amount": 1000000,
  "currency": "VND",
  "source_data_version": "attendance-v18_payroll-v6",
  "requested_at": "2026-08-18T09:20:00+07:00"
}

応答は、要求が受け入れられたか、拒否されたか、追加処理が必要かを示すべきです。また、transactionid、ステータス、理由コード、correlationidを返すべきです。完全な口座データや不要な情報を返すべきではありません。

API仕様は以下を明確に規定すべきです：

• 認証方法と権限;

• APIバージョンと変更ポリシー;

• 日時形式、タイムゾーン、通貨単位;

• 金額の精度と丸めルール;

• エラーコードのカタログ;

• タイムアウトとリトライポリシー;

• コールバックまたはwebhookの署名/検証;

• 負荷制限;

• 冪等性ルール;

• ステータスとログの保存期間。

11. 設計段階からのデータセキュリティと保護

従業員データ、給与、受取口座、取引履歴は非常に機密性が高いです。統合設計には以下が含まれるべきです：

• 役割に基づく権限と最小権限の原則;

• データの送信時と保存時の暗号化;

• 中央管理された秘密管理、ソースコードやログにアクセスキーを含めない;

• 開発、テスト、本番環境の分離;

• 擬似データまたはマスクされたテストデータ;

• アクセスと設定変更のログ;

• 保存期間、削除プロセス、データ主体の要求処理;

• サプライヤー評価とデータ共有範囲;

• インシデント対応、通知、調査計画。

ベトナムでは、設計と運用は2026年1月1日から施行される個人データ保護法第91/2025/QH15号と政令356/2025/NĐ-CPに従って法務部門によってレビューされる必要があります。電子取引法2023および関連する業界規制の枠組み内で、記録、メッセージ、電子証書も考慮される必要があります。

12. 本稼働前のUATチェックリスト

UATは「ファイルを受け取った」または「APIが200を返した」だけを確認するべきではありません（90日間のEWAパイロット計画に含める）。すべての業務シナリオと運用エラーを十分にテストする必要があります。

従業員と参加条件

• [ ] 現在働いており、資格がある従業員。

• [ ] 有効日がまだ来ていない新しい従業員。

• [ ] 休職中または退職済みの従業員。

• [ ] 法人、給与グループ、従業員コードを変更した従業員。

• [ ] 正しい検証フローに従った受取口座の変更。

勤怠と制限

• [ ] ポリシーが承認済み勤務を要求する場合、承認待ちの勤務は計算されない。

• [ ] 承認済み勤務が制限を正しく変更する。

• [ ] 承認後に修正または取り消された勤務が正しく再計算される。

• [ ] 新しいデータが古いデータを上書きしない。

• [ ] 勤務締め日、タイムゾーン、夜勤が正しく処理される。

取引と支払い

• [ ] 同じidempotency_keyを使用した再送信が2つの取引を作成しない。

• [ ] 制限が不足している場合、正確な理由を返す。

• [ ] 支払いシステムのタイムアウトと結果不明が二重支払いを引き起こさない。

• [ ] 失敗、返金、ステータス変更が正しく更新される。

• [ ] 取引前後の制限が取引台帳と一致する。

バッチファイルとAPI

• [ ] 重複ファイル、順序の誤ったファイル、重複レコードが検出される。

• [ ] 一部のレコードエラーが処理済みレコードを失わない。

• [ ] APIの認証期限切れ、権限不足、負荷制限超過が正しいエラーを返す。

• [ ] 偽のコールバックまたは署名エラーが拒否される。

• [ ] リトライが制限を遵守し、重複防止キーを保持する。

給与計算、ERP、照合

• [ ] 給与期間のオープン、ロック、決算が正しく処理される。

• [ ] EWA取引が承認済みの給与期間照合記録に含まれる。

• [ ] EWA、支払い、給与計算/ERPの3つのソースが金額とステータスで一致する。

• [ ] 差異が警告を生成し、クローズまでの処理フローがある。

• [ ] レポートが会計エントリから取引、ソースデータまで追跡可能。

セキュリティと運用

• [ ] 権限のない人がデータを表示または変更できない。

• [ ] ログに秘密または完全な機密データが含まれない。

• [ ] アクセスキーが長時間の中断なしに回転可能。

• [ ] インシデント対応の担当者、警告チャネル、プロセスがある。

• [ ] 本稼働で重大なエラーが発生した場合のロールバック計画がある。

13. 実施前に両者が確認すべき技術文書

最低限の統合文書には以下が含まれるべきです：

1. アーキテクチャ図と責任範囲;

2. 各フィールドのデータ辞書;

3. 従業員コード、給与期間、部門、項目コードのマッピング表;

4. API仕様またはファイル仕様;

5. ステータスとエラーコードのカタログ;

6. 承認済みの制限計算ルール;

7. 重複防止、リトライ、遅延データ処理ルール;

8. 照合フローと差異レポートテンプレート;

9. 権限マトリックスとセキュリティ要件;

10. UAT、カットオーバー、ロールバック、本稼働後サポート計画。

両者はデータ契約テストも実施するべきです。一つのシステムがフィールド名、データ型、ステータスカタログ、業務意味を変更する場合、パイプラインは本番環境外での制限誤りを引き起こす前に警告を発する必要があります。
14. 正式版を公開する前に Nhân Kiệt が追加で確認・補足する必要がある情報

記事の内容が Lương Ngày の実際の対応能力を正確に反映するよう、Product/IT チームは以下の項目を確認する必要があります。

• 現在対応している勤怠管理システム、給与計算（Payroll）システム、ERP システム

• 現在利用可能な連携方法：API、SFTP、サンプルファイル、その他の方法

• データ同期のサイクルおよび実際のサービス提供に関するコミットメント

• 公開可能なエンドポイント、データ項目、ステータス、エラーコードの一覧

• 現在使用している認証、Idempotency、Webhook、照合・突合の仕組み

• 結果が不明な取引、失敗した取引、返金処理に関する対応フロー

• 利用可能額の計算ルールおよび対象となる給与項目

• 個人情報を削除した技術レポートのサンプル

• Nhân Kiệt、企業、決済パートナーそれぞれの責任範囲

• 連携資料の受付および UAT サポートを担当する窓口

資料による確認が取れていない段階では、パートナー名、処理時間、SLA、技術的な機能について公開しないでください。

よくある質問

EWAはリアルタイム統合が必須ですか？

必須ではありません。企業はリアルタイムAPI、スケジュールに基づくバッチファイル、またはパイロットで管理された手動プロセスを使用できます。頻度は制限計算方法、データの変化速度、ソースシステムの運用能力に適合する必要があります。

勤怠データだけでEWAの制限を計算できますか？

通常は不十分です。従業員のステータス、給与期間、給与計算ルール、関連する調整項目、EWA取引履歴が必要です。記録された勤務も明確な承認ステータスが必要です。

なぜ同じ従業員コードを使用する必要があるのですか？

統一された識別子は、他の人の勤務、給与、取引を誤って関連付けることを防ぎます。システムが異なるコードを使用している場合、企業は管理されたマッピングテーブルと有効日を必要とします。

冪等性は取引重複チェックと同じですか？

関連していますが完全に同じではありません。冪等性は、同じ要求を再送信しても新しい業務結果を生成しないことを保証します。重複チェックは、異なるコードを持つ2つの要求が実際には同一の取引であることを検出するために他の業務キーを使用することもできます。

送金命令がタイムアウトした場合、すぐに再送信すべきですか？

古い命令の結果が確認されるまで、新しい送金命令を再送信すべきではありません。システムは不明なステータスを保持し、参照コードに基づいて調査し、定められたプロセスに従って次の処理を行う必要があります。

EWAの照合は誰が責任を持つのですか？

責任は運用マトリックスで規定されるべきです。通常、EWA運用ユニット、給与計算、会計/財務、IT、支払いパートナーが関与します。各種差異には特定の責任者が必要です。

結論

EWAの統合は、勤怠ファイルを引っ張ってパーセンテージを計算することではありません。信頼性のあるシステムは、従業員データ、承認済み勤務、給与計算ルール、統一された識別子でリンクされた取引を必要とし、データバージョン、冪等性、支払いステータス、照合、エラー処理プロセスを備えています。

企業が現在、既存の勤怠管理、給与計算、ERPシステムと給与前払いを接続する可能性を評価している場合、システム図、個人データを隠したデータ辞書、サポートが必要な業務シナリオを準備し、企業向け給与前払いを調べて技術統合文書と適切なパイロット範囲について相談してください。

参考文献

• OpenAPI Initiative – OpenAPI Specification

• OpenAPI Specification on GitHub

• 個人データ保護法第91/2025/QH15号

• 個人データ保護法ガイドライン政令356/2025/NĐ-CP

• 電子取引法第20/2023/QH15号

---

著者: Ngô Nhã Kỳ— 編集者, Nhan Kiet Manpower Supply Co., Ltd.

企業向け給与前払いソリューションの相談: ホットライン 0937.022.655 · メール info@nhankiet.vn · 企業向け給与前払い