Какие данные необходимы для интеграции доступа к заработной плате с системами учёта рабочего времени, расчёта зарплаты и ERP?

Какие данные необходимы для интеграции доступа к заработной плате с системами учёта рабочего времени, расчёта зарплаты и ERP?

Для интеграции доступа к заработной плате с системами учёта рабочего времени, расчёта зарплаты и ERP компаниям необходимо как минимум пять групп данных: профили сотрудников, утверждённые рабочие часы, периоды и правила расчёта зарплаты, корректировки или удержания, и транзакции по досрочному получению зарплаты. Все данные должны использовать единый идентификатор сотрудника, иметь статус, время обновления, версию данных и журнал аудита. Хорошая архитектура не только быстро передаёт данные, но и предотвращает дублирование выплат, обрабатывает поздние изменения данных и сверяет каждую транзакцию.

> Примечание: В статье представлена эталонная архитектура для системы доступа к заработной плате (EWA). Названия полей, статусы, потоки утверждения и фактические методы учёта должны быть подтверждены компанией Nhan Kiet и предприятием на этапе обследования интеграции.

> Объяснение терминов: EWA (доступ к заработной плате) · HRIS/HRM (система управления человеческими ресурсами) · ERP (система планирования ресурсов предприятия) · расчёт зарплаты · API (интерфейс программирования приложений) · пакетная обработка · SFTP (безопасная передача файлов) · идемпотентность (предотвращение дублирования: повторная отправка создаёт только один результат) · UAT (приёмочное тестирование) · ввод в эксплуатацию · откат · webhook/callback (автоматические уведомления между системами) · токен (замена исходных данных) · словарь данных · система учёта · повторная попытка · тайм-аут.

Почему доступ к заработной плате должен быть интегрирован с системами учёта рабочего времени, расчёта зарплаты и ERP?

Доступ к заработной плате должен ответить на три вопроса, прежде чем разрешить работнику получить деньги:

1. Работает ли этот человек и участвует ли в программе?

2. На данный момент, сколько заработной платы он заработал, чтобы иметь право на получение?

3. После предыдущих транзакций и удержаний, сколько денег ещё можно получить?

Система управления человеческими ресурсами обычно подтверждает личность и статус занятости. Система учёта рабочего времени фиксирует количество отработанных часов или смен. Система расчёта зарплаты содержит правила расчёта, периоды и корректировки. ERP или бухгалтерская система служат для учёта, сверки и окончательных расчётов. Платёжная система предоставляет статус окончательного перевода денег.

Если подключена только одна система, доступ к заработной плате может видеть работника, но не знать утверждённые рабочие часы; или видеть часы, но не знать, закрыт ли расчётный период; или деньги переведены, но система расчёта зарплаты не получила транзакцию для сверки. Поэтому важнейшим моментом является не просто "подключение к API", а установление последовательной цепочки данных от отработанных часов до окончательной транзакции.

1. Общая архитектура данных

Эталонная архитектура может быть организована следующим образом:

flowchart TD
    A["HRIS: сотрудники"] --> D["Интеграционный слой"]
    B["Учёт рабочего времени: утверждённые часы"] --> D
    C["Расчёт зарплаты: периоды и правила"] --> D
    D --> E["Модуль расчёта лимитов доступа к заработной плате"]
    E --> F["Приложение доступа к заработной плате"]
    F --> G["Платёжная система"]
    G --> H["Сверка расчёта зарплаты, ERP и бухгалтерии"]
    H --> E

Каждая область данных должна иметь один источник данных (система учёта). Не следует позволять HRIS, расчёту зарплаты и доступу к заработной плате изменять одно и то же свойство тремя разными способами.

2. Минимальный перечень данных сотрудников

Не следует синхронизировать все профили сотрудников только потому, что "это может понадобиться". Принцип заключается в сборе и передаче только тех данных, которые необходимы для определённой цели.

Полные данные банковского счёта должны существовать только в области, где они действительно необходимы для платежей, с соответствующими правами доступа и защитой. В тестовой среде следует использовать фиктивные или скрытые данные, а не копировать реальные данные из производственной среды.

3. Данные учёта рабочего времени и статус утверждения

Доступ к заработной плате не должен получать только одно число "общих рабочих часов за месяц". Система должна иметь достаточно информации, чтобы знать, какие данные были подтверждены, а какие ещё могут быть изменены.

Обычно требуются следующие поля:

• employee_id: единый идентификатор сотрудника;

• work_date: дата работы;

• shift_id: идентификатор смены, если компания управляет сменами;

• regularhours, overtimehours: обычные и сверхурочные часы;

• attendance_status: присутствие, отпуск, отсутствие или соответствующий статус;

• approval_status: ожидает утверждения, утверждено, отклонено, скорректировано или заблокировано;

• approvedby, approvedat: лицо и время утверждения, если это требуется политикой;

• sourceupdatedat, record_version: время и версия записи;

• source_system: система, генерирующая данные.

Почему статус "утверждено" важен?

Одноразовое сканирование карты не обязательно является допустимым рабочим временем. Сотрудник может забыть отметить выход, зарегистрировать неправильную смену или внести изменения после утверждения менеджером. Компания должна чётко определить, какой статус учитывается в лимите доступа к заработной плате (см. Что такое утверждённые рабочие часы?).

Пример записи:

{
  "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. Данные расчёта зарплаты и корректировки

Данные расчёта зарплаты помогают преобразовать "утверждённые рабочие часы" в "сумму заработной платы, имеющую право на получение". Набор данных обычно включает:

• идентификатор периода расчёта зарплаты payperiodid и время начала и окончания;

• группа расчёта зарплаты и цикл выплат;

• основа для расчёта зарплаты или ставка, необходимая для согласованной формулы;

• код дохода earning_code;

• соответствующие корректировки, удержания или вычеты;

• дата закрытия учёта рабочего времени и время блокировки расчётной ведомости;

• статус периода расчёта зарплаты: открыт, в обработке, заблокирован или завершён;

• валюта и правила округления;

• версия применяемой формулы/политики.

Не все элементы расчётной ведомости учитываются в лимите доступа к заработной плате. Основная зарплата, надбавки, сверхурочные, бонусы или комиссии имеют разную степень уверенности и время утверждения. Компания должна составить таблицу правил, чётко указывающую, какие элементы учитываются, с какого статуса и как они ограничиваются.

Какие столбцы должны быть в таблице правил?

Фактические значения в этой таблице должны быть подтверждены компанией и внедряющей организацией. Не следует делать предположения на основе названия элемента зарплаты.

5. Данные транзакций по досрочному получению зарплаты

Каждый запрос на досрочное получение зарплаты должен быть независимой транзакцией, которую можно отследить.

Эталонный жизненный цикл транзакции включает: CREATED → VALIDATING → PROCESSING → SUCCEEDED или FAILED. Если результат платежа не определён, транзакция должна находиться в состоянии UNKNOWN или аналогичном для расследования; не следует автоматически считать её неудачной и повторно переводить деньги. Система также должна иметь статусы возврата и сверки при возникновении таких операций.

6. Выбор между API, пакетными файлами или ручной синхронизацией

Нет единого метода, подходящего для всех компаний. Можно комбинировать несколько способов в зависимости от зрелости каждой системы.

Если используется HTTP API, компания может описать контракт интеграции с помощью OpenAPI Specification, чтобы обе стороны согласовали конечные точки, структуру данных и ответы. OpenAPI — это стандарт для описания HTTP API; это полезный технический выбор, но не обязательное условие для внедрения доступа к заработной плате.

7. Идентификация и предотвращение дублирования данных

Ошибки идентификации — одна из самых опасных рисков. Электронная почта, номер телефона или номер счёта могут измениться, поэтому они не подходят в качестве основного идентификатора сотрудника.

Рекомендации:

• использовать неизменяемый employee_id в пределах одной компании;

• комбинировать с employerid или legalentity_id, если платформа обслуживает несколько единиц;

• не использовать повторно код уволенного сотрудника для нового сотрудника;

• поддерживать таблицу соответствия, если HRIS и расчёт зарплаты используют разные наборы кодов;

• фиксировать дату вступления в силу для изменений в группе расчёта зарплаты, подразделении и статусе занятости;

• проверять дублирование по бизнес-ключам, а не только по одинаковому содержимому.

Для пакетных файлов каждый файл должен иметь идентификатор партии, время создания, общее количество записей и контрольную сумму. Для API каждая транзакция должна иметь idempotency_key.

8. Идемпотентность и сверка: два разных уровня защиты

Идемпотентность позволяет повторно отправлять один и тот же запрос, но создавать только один бизнес-результат. Например, приложение получает тайм-аут после отправки команды на перевод денег. При повторной отправке с тем же idempotency_key система должна вернуть старую транзакцию или её статус, а не создавать ещё одну выплату.

Сверка проверяет, фиксируют ли системы одну и ту же транзакцию (связанную с процессом доступа к заработной плате от учёта рабочего времени до сверки). Подходящая модель — трёхсторонняя сверка:

1. транзакция в платформе доступа к заработной плате;

2. результат от банка или платёжного партнёра;

3. данные расчёта зарплаты/ERP или утверждённые окончательные расчёты.

Отчёт о сверке должен показывать как минимум:

• полностью совпадающие транзакции;

• есть в доступе к заработной плате, но нет результата платежа;

• есть результат платежа, но отсутствует в расчёте зарплаты/ERP;

• расхождение в сумме, комиссии, получателе или периоде расчёта зарплаты;

• возврат транзакции, но не обновлён;

• дублирование записей или неправильный порядок обновления.

Каждое расхождение должно иметь ответственного, статус обработки и доказательства закрытия ошибки.

9. Обработка ошибок, повторные попытки и предупреждения

Не все ошибки следует автоматически повторять.

Каждый запрос должен иметь correlation_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 и политику изменений;

• формат даты и времени, часовой пояс и валюту;

• точность суммы и правила округления;

• список кодов ошибок;

• тайм-аут и политику повторных попыток;

• подпись/проверку callback или webhook;

• ограничение нагрузки;

• правила идемпотентности;

• время хранения статуса и журнала.

11. Безопасность и защита данных на этапе проектирования

Данные сотрудников, зарплаты, платёжные данные и история транзакций имеют высокий уровень конфиденциальности. Проектирование интеграции должно включать:

• права доступа по ролям и принцип минимальных прав;

• шифрование данных при передаче и хранении;

• централизованное управление секретами, без хранения ключей доступа в исходном коде или журнале;

• разделение сред разработки, тестирования и производства;

• использование фиктивных или скрытых данных в тестовой среде;

• журнал доступа и изменений конфигурации;

• сроки хранения, процедуры удаления и обработки запросов субъектов данных;

• оценку поставщиков и объём обмена данными;

• план реагирования, уведомления и расследования инцидентов.

Вьетнамские компании должны учитывать, что проектирование и эксплуатация должны быть проверены юридическим отделом в соответствии с Законом о защите персональных данных № 91/2025/QH15 и Постановлением 356/2025/NĐ-CP, которые вступают в силу с 1 января 2026 года. Электронные документы, сообщения и записи также должны быть рассмотрены в рамках Закона об электронных транзакциях 2023 года и соответствующих отраслевых нормативов.

12. Контрольный список UAT перед вводом в эксплуатацию

UAT не должен проверять только "получение файла" или "API возвращает 200" (включено в план пилота доступа к заработной плате на 90 дней). Необходимо протестировать все бизнес-сценарии и ошибки эксплуатации.

Сотрудники и условия участия

• [ ] Сотрудник работает и имеет право на участие.

• [ ] Новый сотрудник ещё не достиг даты вступления в силу.

• [ ] Сотрудник в отпуске или уволен.

• [ ] Сотрудник сменил юридическое лицо, группу расчёта зарплаты или идентификатор сотрудника.

• [ ] Изменение платёжного счёта с правильной проверкой.

Учёт рабочего времени и лимиты

• [ ] Ожидающие утверждения часы не учитываются, если политика требует утверждённых часов.

• [ ] Утверждённые часы корректно изменяют лимит.

• [ ] Изменённые или отозванные после утверждения часы корректно пересчитываются.

• [ ] Старые данные, поступившие после новых, не перезаписывают версию.

• [ ] Дата закрытия учёта, часовой пояс и ночные смены корректно обрабатываются.

Транзакции и платежи

• [ ] Повторная отправка с тем же idempotency_key не создаёт две транзакции.

• [ ] Недостаточный лимит возвращает точную причину.

• [ ] Тайм-аут платёжной системы и неопределённый результат не вызывают повторного перевода денег.

• [ ] Неудачные транзакции, возвраты и изменения статуса корректно обновляются.

• [ ] Лимиты до и после транзакции совпадают с журналом транзакций.

Пакетные файлы и API

• [ ] Дублированные файлы, файлы в неправильном порядке и дублированные записи обнаруживаются.

• [ ] Ошибки в некоторых записях не теряют обработанные записи.

• [ ] API с истёкшей аутентификацией, недостаточными правами и превышением нагрузки возвращает правильные ошибки.

• [ ] Поддельные или неправильно подписанные callback отклоняются.

• [ ] Повторные попытки соблюдают ограничения и сохраняют ключ идемпотентности.

Расчёт зарплаты, ERP и сверка

• [ ] Открытые, заблокированные и завершённые периоды расчёта зарплаты корректно обрабатываются.

• [ ] Транзакции доступа к заработной плате включаются в сверку расчётного периода в соответствии с утверждённым процессом.

• [ ] Три источника доступа к заработной плате — платежи — расчёт зарплаты/ERP совпадают по сумме и статусу.

• [ ] Расхождения создают предупреждения и имеют процесс обработки до закрытия.

• [ ] Отчёты могут быть отслежены от бухгалтерской записи до транзакции и исходных данных.

Безопасность и эксплуатация

• [ ] Лица без прав доступа не могут просматривать или изменять данные.

• [ ] Журнал не содержит секретов или полных конфиденциальных данных.

• [ ] Ключи доступа могут быть изменены без длительных перебоев.

• [ ] Есть дежурные, каналы предупреждений и процедуры обработки инцидентов.

• [ ] Есть план отката, если при вводе в эксплуатацию возникают серьёзные ошибки.

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, шаблон файла или другие методы;

• фактическую периодичность синхронизации и обязательства по уровню сервиса;

• перечень endpoint, полей данных, статусов и кодов ошибок, которые разрешено публиковать;

• используемые механизмы аутентификации, idempotency, webhook и сверки данных;

• процесс обработки транзакций с неопределённым результатом, неудачных транзакций и возвратов;

• правила расчёта доступного лимита и компоненты заработной платы, учитываемые при расчёте;

• образцы технических отчётов с удалёнными персональными данными;

• зоны ответственности Nhân Kiệt, предприятия и платёжного партнёра;

• контактное лицо для получения интеграционной документации и поддержки UAT.

Не следует публиковать названия партнёров, время обработки, SLA или технические возможности без документального подтверждения.

-->

Часто задаваемые вопросы

Обязательно ли интегрировать EWA в режиме реального времени?

Нет. Предприятие может использовать API, близкий к режиму реального времени, плановую пакетную передачу файлов или контролируемый ручной процесс на этапе пилотного проекта. Периодичность должна соответствовать способу расчёта лимита, скорости изменения данных и возможностям исходных систем.

Достаточно ли одних данных об учёте рабочего времени для расчёта лимита EWA?

Обычно нет. Также необходимы статус сотрудника, расчётный период, правила расчёта заработной платы, соответствующие корректировки и история транзакций EWA. Зарегистрированные рабочие часы также должны иметь чёткий статус утверждения.

Почему необходимо использовать единый идентификатор сотрудника?

Единый идентификатор помогает избежать ошибочного связывания рабочего времени, заработной платы или транзакций одного сотрудника с другим. Если разные системы используют разные идентификаторы, предприятию необходимо поддерживать контролируемую таблицу соответствий с указанием даты вступления изменений в силу.

Является ли idempotency тем же самым, что и проверка дублирующихся транзакций?

Они связаны, но не являются полностью одинаковыми. Idempotency гарантирует, что повторная отправка одного и того же запроса не создаст новый бизнес-результат. При проверке дубликатов также могут использоваться другие бизнес-ключи для выявления двух запросов с разными идентификаторами, которые фактически являются одной и той же транзакцией.

Следует ли немедленно повторно отправлять платёжное поручение после timeout?

Не следует отправлять новое платёжное поручение, пока результат предыдущего поручения не определён. Система должна сохранить статус неопределённого результата, выполнить проверку по референсному номеру и продолжить обработку в соответствии с установленной процедурой, чтобы избежать двойной выплаты.

Кто отвечает за сверку данных EWA?

Ответственность должна быть определена в операционной матрице. Обычно в процессе участвуют оператор EWA, специалисты payroll, бухгалтерия/финансовый отдел, IT и платёжный партнёр. Для каждого типа расхождения должен быть назначен конкретный ответственный.

Заключение

Интеграция EWA — это не просто загрузка файла с данными об отработанном времени и расчёт определённого процента. Надёжная система должна связывать данные сотрудников, утверждённое рабочее время, правила payroll и транзакции с помощью единого идентификатора, а также обеспечивать версионирование данных, idempotency, статусы платежей, сверку данных и процесс обработки ошибок.

Если предприятие оценивает возможность подключения Lương Ngày к существующей системе учёта рабочего времени, payroll или ERP, следует подготовить схему системы, data dictionary с обезличенными персональными данными и сценарии бизнес-процессов, которые необходимо поддерживать, а затем ознакомиться с разделом Lương Ngày для предприятий, чтобы обсудить техническую интеграционную документацию и подходящий объём пилотного проекта.

Источники

• OpenAPI Initiative – OpenAPI Specification

• OpenAPI Specification на GitHub

• Закон о защите персональных данных № 91/2025/QH15

• Постановление № 356/2025/NĐ-CP о руководящих положениях к Закону о защите персональных данных

• Закон об электронных транзакциях № 20/2023/QH15

Автор: Ngô Nhã Kỳ — Редактор, Công ty TNHH Cung Ứng Nhân Lực Nhân Kiệt.

Консультации по решению Lương Ngày для предприятий: Телефон 0937.022.655 · Email info@nhankiet.vn · Lương Ngày для предприятий