DAILY WAGEHired TodayPaid Today

Новости

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

Doanh nghiệp · 15/09/2026 · Автор: Nguyễn Minh Khang (Chuyên viên ban chiến lược)

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

Для внедрения доступа к заработанной зарплате в логистике компании должны четко разделять утвержденную почасовую оплату и доходы от рейсов, заказов, производительности, надбавок и премий, которые определяются только после сверки. Данные из систем учета рабочего времени, WMS, TMS, приложений для водителей/доставки и расчета зарплаты должны использовать общие коды сотрудников, локации, смены, задачи, расчетные периоды и статусы утверждения. Компаниям следует начинать с доходов с высокой степенью уверенности, отдельно обрабатывать поздние или отмененные данные и сверять каждую транзакцию перед расширением.

> Примечание: Статья является справочным бизнес-техническим руководством. Формулы расчета зарплаты, надбавок, премий, штрафов/компенсаций, компоненты, включаемые в лимиты, и методы расчетов должны быть подтверждены компанией, отделом расчета зарплаты, юридическим отделом, бухгалтерией и поставщиком доступа к заработанной зарплате в соответствии с контрактом и фактической политикой.

> Объяснение терминов: Доступ к заработанной зарплате (получение зарплаты за отработанные дни) · WMS (система управления складом) · TMS (система управления транспортом) · HRIS (система управления персоналом) · расчет зарплаты · COD (наложенный платеж при доставке) · cutoff (точка завершения периода) · пилот (пилотное внедрение) · UAT (пользовательское приемочное тестирование) · KPI (ключевые показатели эффективности) · хаб (перевалочный центр) · офлайн (вне сети).

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

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

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

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

  • рейс создан, но отменен;

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

  • сотрудник перемещен между сменами;

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

  • наложенный платеж не передан;

  • офлайн-данные синхронизированы с задержкой;

  • ночная смена учитывается в разные дни в разных системах.

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

1. Карта систем в логистической компании

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

Роль каждой системы

| Система | Данные | Не следует предполагать |
|---|---|---|
| HRIS | Идентификация, статус занятости, подразделение | Активный аккаунт означает, что сотрудник все еще работает |
| Учет рабочего времени | События входа/выхода, смены, исключения | Каждое событие учета — это оплачиваемое время |
| WMS | Складские операции, сканирование, обработка заказов/производительность | Каждая задача оплачивается как производительность |
| TMS | Рейсы, маршруты, координация, статусы | Каждый новый рейс — это уже возникший доход |
| Приложение на месте | Принятие задач, доставка, доказательства, местоположение | Каждый статус, установленный пользователем, — это окончательный результат |
| Расчет зарплаты | Периоды, правила, коды, утверждения | Деньги успешно переведены |
| Доступ к заработанной зарплате | Лимиты, запросы, транзакции | Источник данных больше не изменяется |
| Платежи | Результаты перевода денег | Расчет зарплаты учтен в правильном периоде/для правильного человека |

2. Классификация рабочей силы перед проектированием доступа к заработанной зарплате

(Для многосменных заводов: см. Доступ к заработанной зарплате для многосменных производственных компаний.)

Складские сотрудники по сменам

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

Водители

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

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

Доход может зависеть от количества принятых заказов, успешно доставленных заказов, возвратов, веса, района, наложенных платежей и премий за качество.

Временные/контрактные работники

Необходимо точно определить отношения, условия участия, срок действия и источник данных. Не следует объединять все формы работы в одну политику доступа к заработанной зарплате.

Координаторы и офисные сотрудники

Обычно имеют более стабильные данные, но их потребности и структура доходов отличаются от полевых групп.

Каждой группе требуется eligibilitypolicyid и earningpolicyversion, а не единая формула для всей компании.

3. Разделение уверенного дохода и изменяющегося дохода

Компоненты доходов, которые могут быть учтены в доступе к заработанной зарплате

| Группа доходов | Пример | Степень уверенности на раннем этапе | Рассмотрение для доступа к заработанной зарплате |
|---|---|---|---|
| Утвержденная почасовая оплата | Завершенная и утвержденная смена на складе | Высокая | Может быть основой для начала |
| Утвержденные сверхурочные | Завершенные сверхурочные, подтвержденные менеджером | Относительно высокая | В зависимости от политики |
| Завершенные рейсы после сверки | Рейсы с достаточными доказательствами, не отмененные | В зависимости от процесса | Только после статуса "достаточно для выплаты" |
| Успешно доставленные заказы | Заказы в конечном статусе и с качеством | Может измениться из-за возвратов/корректировок | Требуются правила удержания или ожидания завершения |
| Надбавки за маршрут/ночь | Зависит от маршрута, времени, утверждения | В зависимости от данных | Учитывается только при наличии четких оснований |
| Премии за производительность/присутствие | Обычно определяются в конце периода | Низкая в середине периода | Обычно не следует учитывать заранее, если не уверены |
| Возмещения/корректировки | Зависит от проверки и процесса | Не определено | Не следует автоматически вычитать или предполагать |

Компаниям следует начинать пилот с наиболее стабильных доходов. После улучшения данных и сверки можно рассмотреть добавление изменяющихся компонентов.

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

Профиль сотрудника

  • employee_id;

  • employerid или legalentity_id;

  • employment_status и дата вступления в силу;

  • payroll_group;

  • role_type: склад, водитель, доставка, координация и т.д.;

  • ewa_eligibility;

  • версия и время обновления.

Распределение

  • assignment_id;

  • siteid или hubid;

  • warehouse_id;

  • route_group, если используется политика;

  • shift_id;

  • vehicle_id, если это необходимо для бизнеса;

  • effectivefrom, effectiveto;

  • статус распределения;

  • источник утверждения.

Принципы минимизации

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

5. Данные о сменах на складе и почасовой оплате

(Основные понятия: см. Что такое утвержденные рабочие часы?.)

Обычно требуемые поля:

| Поле | Назначение |
|---|---|
| work_date | Дата операции |
| shift_id | Код смены |
| shiftstart, shiftend | Время с учетом часового пояса |
| checkin, checkout | События присутствия |
| regular_minutes | Определенные обычные рабочие минуты |
| overtime_minutes | Сверхурочные по статусу |
| break_minutes | Время перерыва по правилам |
| attendance_status | Полное присутствие, неполное присутствие, отсутствие и т.д. |
| approval_status | Ожидание, утверждено, отклонено, корректировка, заблокировано |
| record_version | Отслеживание изменений |

Разделенные смены и несколько мест в течение дня

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

Ночные смены

Учет рабочего времени, WMS и расчет зарплаты должны согласовывать work_date. Если одна система использует дату начала, а другая — дату окончания, рабочие часы и производительность могут не совпадать по периодам.

6. Какие статусы нужны для данных о рейсах и доставке?

Статусы рейсов доставки, имеющие право на расчет дохода в доступе к заработанной зарплате

Пример жизненного цикла:

Фактические названия статусов могут отличаться. Важно определить, на каком этапе данные становятся допустимыми для расчета зарплаты/доступа к заработанной зарплате.

Пример полей данных

  • taskid или tripid;

  • employee_id;

  • assignment_id;

  • siteid/routeid;

  • время принятия, начала, завершения;

  • тип задачи;

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

  • операционный статус;

  • статус утверждения;

  • причина отмены/возврата/корректировки;

  • лицо и время утверждения;

  • версия данных.

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

7. Является ли успешно доставленный заказ заработанной зарплатой?

Нельзя сделать вывод только из статуса "Доставлено". Компания должна проверить:

  • является ли статус конечным или возможен возврат/отмена;

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

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

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

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

  • какой доход выплачивается за какое действие;

  • не дублируются ли данные из-за смены маршрута или переназначения;

  • какой статус утвержден для расчета зарплаты.

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

8. Обработка возвратов заказов, отмен рейсов и поздних данных

Не удаляйте уже возникшие события

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

Процесс обработки

  1. получение события изменения с новой версией;

  2. проверка, являются ли данные поздними;

  3. определение затронутой части дохода;

  4. пересчет доступного лимита;

  5. если уже была транзакция, создание кейса расхождения;

  6. обработка в соответствии с утвержденной политикой;

  7. прозрачное уведомление, если права сотрудника затронуты;

  8. сохранение предыдущих/последующих значений и лица, утвердившего изменения.

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

9. Наложенный платеж (COD) не является зарплатой

Различие между наложенным платежом COD и доходом при внедрении доступа к заработанной зарплате

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

Дизайн данных должен разделять:

  • cod_collected;

  • cod_remitted;

  • codreconciliationstatus;

  • допустимый доход;

  • транзакции доступа к заработанной зарплате;

  • сумма выплаты сотруднику.

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

10. Офлайн-данные и события, поступающие в неправильном порядке

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

Каждое событие должно иметь:

  • уникальный event_id;

  • время возникновения на источнике;

  • время получения системой;

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

  • источник/устройство;

  • статус подписи/подтверждения, если применимо;

  • связь с taskid/tripid.

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

11. Расчет лимитов для комбинированного дохода

Концептуальная модель:

Допустимый доход = Утвержденные почасовые рабочие часы + Завершенная производительность + Допустимые надбавки
Доступный лимит = Допустимый доход x Разрешенная ставка - Удержания - Уже получено/в обработке

Каждый компонент требует:

  • код элемента;

  • статус допустимости;

  • формулу;

  • единицу измерения;

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

  • потолок;

  • дату вступления в силу;

  • лицо, утвердившее изменения;

  • версию.

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

12. Интеграция WMS, TMS и расчета зарплаты

(Требования к данным и архитектуре: см. Интеграция доступа к заработанной зарплате с учетом рабочего времени, расчетом зарплаты и ERP.)

Не подключайтесь по отображаемым именам

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

Слой стандартизации данных

Интеграционный слой должен приводить различные системы к общей модели:

  • сотрудники;

  • распределение;

  • смены/рабочие часы;

  • задачи/производительность;

  • статусы утверждения;

  • расчетные периоды;

  • элементы дохода;

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

API или пакетные файлы?

| Метод | Подходит для | Контрольные точки |
|---|---|---|
| API в реальном времени | Данные задач и рабочего времени обновляются постоянно | Аутентификация, версия, идемпотентность, повтор |
| Пакетные файлы/SFTP | Завершение производительности/рабочих часов по расписанию | Код партии, контрольная сумма, защита от дублирования, частичные ошибки файлов |
| Контролируемая ручная обработка | Малые пилоты или старые системы | Стандартные шаблоны, лица, создающие/утверждающие, логи, сверка |

Расширение возможно только при измерении ручной нагрузки и наличии плана по ее снижению.

13. Шестисторонняя сверка

(Подробности: см. Сверка транзакций доступа к заработанной зарплате с расчетом зарплаты и бухгалтерией.)

В зависимости от модели логистические компании могут проводить сверку:

  1. учет рабочего времени/расписание смен;

  2. WMS/TMS или приложение на местах;

  3. данные утвержденных доходов;

  4. транзакции доступа к заработанной зарплате;

  5. результаты платежей;

  6. расчет зарплаты/ERP/бухгалтерия.

Необходимые расхождения для обнаружения

  • есть рабочие часы, но отсутствует распределение;

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

  • рейс отменен, но доход не скорректирован;

  • производительность записана дважды;

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

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

  • ошибка периода из-за ночных смен/рейсов;

  • неправильная версия надбавки;

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

  • общая сумма совпадает, но ошибка по каждому сотруднику.

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

14. Управление специфическими рисками и мошенничеством

(Полный фреймворк: см. Управление рисками и предотвращение мошенничества в доступе к заработанной зарплате.)

Сигналы данных

  • одна и та же задача назначена нескольким людям;

  • множество задач завершено за нереалистично короткое время;

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

  • завершение из необычного местоположения/устройства;

  • массовые корректировки перед cutoff;

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

  • изменение счета получателя и немедленная транзакция;

  • множество сотрудников получают деньги на один и тот же счет.

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

Разделение обязанностей

Не позволяйте одному человеку одновременно:

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

  • утверждать доходы;

  • изменять лимиты;

  • обрабатывать транзакции;

  • закрывать расхождения.

15. Поддержка сотрудников, распределенных по многим локациям

Подходящие каналы

  • FAQ в приложении;

  • горячая линия/тикеты;

  • контактное лицо на складе/в хабе;

  • SMS/уведомления о статусе;

  • краткие инструкции по сменам;

  • QR-коды на рабочих местах.

Маршрутизация тикетов

| Проблема | Контактное лицо |
|---|---|
| Недостаток/ошибка учета рабочего времени | Управляющий складом/HR Operations |
| Ошибка рейса/производительности | Координация/WMS/TMS Operations |
| Отсутствие лимита | EWA Operations/Payroll |
| Зависшая транзакция | EWA/Payment Support |
| Ошибка расчета зарплаты | Payroll |
| Подозрение на захват аккаунта | Security/Risk |

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

16. Защита данных о местоположении и поведении

(Фреймворк безопасности: см. Защита данных и конфиденциальности при внедрении доступа к заработанной зарплате.)

Логистика может использовать GPS, историю маршрутов, доказательства доставки и устройства. Эти данные требуют строгого управления.

Компания должна определить:

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

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

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

  • используются ли данные для других целей;

  • как данные агрегируются/маскируются;

  • как обрабатываются отзывы сотрудников;

  • какие поставщики имеют доступ;

  • удаление/возврат при завершении услуги.

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

17. KPI пилота для логистики

Данные и операции

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

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

  • актуальность данных;

  • процент дублированных/поздних данных;

  • процент автоматической обработки;

  • процент автоматической сверки;

  • корректировки после cutoff.

Опыт

  • процент активации;

  • процент успешных транзакций;

  • время получения денег;

  • процент отказов;

  • количество тикетов на 1000 транзакций;

  • время обработки тикетов;

  • уровень понимания лимитов и сборов.

Персонал и финансы

  • запросы на ручные авансы;

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

  • процент присутствия в пиковые периоды;

  • стоимость на пользователя/транзакцию;

  • подтвержденные расхождения и мошенничество;

  • процент ошибочных блокировок.

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

18. Чеклист UAT для логистики

Чеклист тестирования доступа к заработанной зарплате для складов, водителей и сотрудников доставки

Склады и смены

  • [ ] Дневные, ночные и разделенные смены.

  • [ ] Один человек поддерживает два склада в течение дня.

  • [ ] Отсутствие check-in/check-out.

  • [ ] Ожидание и утверждение сверхурочных.

  • [ ] Перемещение между складами в течение периода.

Рейсы и заказы

  • [ ] Создание, принятие, завершение и утверждение рейсов.

  • [ ] Отмена или переназначение рейсов.

  • [ ] Успешно доставленные заказы, затем возвраты.

  • [ ] Поздние офлайн-данные.

  • [ ] Дублированные задачи/производительность.

  • [ ] Неправильный сотрудник или маршрут.

Лимиты и транзакции

  • [ ] Учитываются только допустимые элементы.

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

  • [ ] Повторные отправки не создают дублированные транзакции.

  • [ ] Тайм-аут создает неопределенный статус.

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

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

  • [ ] Ночные смены/рейсы в правильном периоде.

  • [ ] Импорт транзакций в расчет зарплаты защищен от дублирования.

  • [ ] Каждое расхождение создает кейс.

  • [ ] Возврат транзакций обрабатывается правильно.

  • [ ] Возможность отслеживания от расчета зарплаты до исходных данных.

19. Дизайн пилота и расширение

(Стандартный план: см. План пилота доступа к заработанной зарплате на 90 дней для компаний.)

Выбор первого этапа

Следует выбрать склад/хаб или группу доставки с:

  • реальной потребностью;

  • относительно стабильными данными;

  • четкими правилами доходов;

  • готовностью менеджмента к утверждению;

  • достаточной поддержкой;

  • процессами, представляющими расширяемые локации.

Начало с стабильных доходов

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

Расширение по волнам

Группируйте локации с одинаковыми WMS/TMS, расчетом зарплаты, политиками и моделями доходов. Каждая волна требует UAT, распределения прав, обучения, дашбордов, сверки и отката.

20. Частые ошибки

Использование количества возникших заказов вместо количества допустимых заказов

Заказы могут быть отменены, возвращены или переназначены.

Смешивание наложенного платежа с доходом

Два денежных потока имеют разную природу и процессы.

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

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

Учет всех изменяющихся элементов

Премии, надбавки или производительность, не завершенные, делают лимиты нестабильными.

Отсутствие кода распределения

Сотрудники, перемещающиеся между складами/маршрутами, могут быть неправильно учтены или дублированы.

Расширение, когда пилотная команда обрабатывает вручную

Результаты не отражают возможности масштабирования.

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

Можно ли сразу использовать количество успешно доставленных заказов для расчета доступа к заработанной зарплате?

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

Учитывается ли наложенный платеж в лимитах доступа к заработанной зарплате?

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

Обязательно ли использовать данные GPS для внедрения доступа к заработанной зарплате?

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

Как обрабатывать отмену рейса после создания лимита?

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

Как рассчитываются разделенные смены?

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

Можно ли пилотировать только с данными учета рабочего времени?

Можно, если начальная цель — только расчет утвержденной почасовой оплаты. Элементы рейсов/производительности следует добавлять после того, как статусы и сверка доказали свою надежность.

Подходит ли доступ к заработанной зарплате для пиковых периодов в логистике?

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

Заключение

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

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

Источники

---

Автор: Ho Tan Dat — Помощник заместителя генерального директора по стратегии, Nhan Kiet Manpower Supply Co., Ltd.

Консультации по решениям доступа к заработанной зарплате для компаний: Горячая линия 0937.022.655 · Email info@nhankiet.vn · Доступ к заработанной зарплате для компаний

← Новости