Как Eligibility Engine определяет условия и лимиты?

Eligibility Engine — это слой проверки условий использования EWA в момент создания запроса работником. Он не формирует заработанную оплату, а получает уже рассчитанный результат и применяет статус профиля, политику компании, лимиты использования и контрольные условия, чтобы определить, можно ли продолжить запрос и в каком объёме.

На какой вопрос отвечает Eligibility Engine?

В EWA легко смешать два вопроса:

1. Сколько оплаты работник заработал за утверждённую работу?
2. Имеет ли он сейчас право пользоваться сервисом и в каком объёме может получить средства?

Первый вопрос относится к Earned Wage Engine, второй — к Eligibility Engine.

Разделение слоёв не позволяет системе путать стоимость, уже созданную трудом, с разрешением использовать финансовую функцию.

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

Шесть групп условий, которые обычно нужно проверять

Хороший Eligibility Engine организует условия в группы с ясным бизнес-смыслом.

Группа проверки	Вопрос	Источник данных
Статус работника	Активен ли профиль и входит ли он в область применения?	HRM/ERP
Работа и заработанная оплата	Сформирована ли допустимая заработанная оплата?	Earned Wage Engine
Политика компании	Включена ли политика для этого места работы?	Policy/configuration
Личность и счёт	Проверен ли профиль получателя?	Identity/account
Лимиты использования	Находится ли текущий запрос в разрешённых пределах?	Policy + transaction ledger
Состояние системы	Есть ли условие, требующее остановки или удержания?	Transaction/monitoring

У каждого условия должны быть ясный источник данных и ответственный владелец.

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

Лимит — результат политики, а не заработанная оплата

В EWA «лимит» не следует понимать как отдельную сумму, заранее предоставленную работнику.

Сначала Earned Wage Engine определяет уже сформированную оплату.

Затем Eligibility Engine может применить правила, чтобы сузить разрешённый объём использования, но не должен создавать стоимость выше допустимой заработанной оплаты.

Соотношение можно записать так:

Доступная для использования стоимость ≤ Уже сформированная допустимая заработанная оплата

Для сервиса доступа к заработанной оплате Nhan Kiet действует базовая формула:

Доступная сумма = (утверждённые рабочие дни × дневная ставка) − уже получено в периоде − резерв по правилам компании.

После этого оцениваются другие условия использования.

Зачем повторно проверять условия в момент запроса?

Статус «допущен», показанный в приложении, может уже устареть.

Между открытием экрана и подтверждением могут произойти следующие события:

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

Поэтому сервер должен повторно оценить условия при создании запроса.

Интерфейс должен только показывать данные; окончательное решение необходимо принимать по последним данным сервера.

Чем Eligibility Engine отличается от Earned Wage Engine?

Слой	Главный вопрос	Основные данные
Earned Wage Engine	Сколько заработанной оплаты уже сформировано?	Работа, ставка, полученная сумма, резерв
Eligibility Engine	Может ли человек использовать сервис сейчас и в каком объёме?	Профиль, политика, лимиты, счёт
Payment Orchestration	Как допустимый запрос будет обработан как транзакция?	ID транзакции, статус, банк

Разделение трёх слоёв даёт каждому ясную ответственность.

Если меняются рабочие данные, Earned Wage Engine пересчитывает сумму. Если меняется политика, Eligibility Engine проводит повторную оценку. Если банковская сеть не отвечает вовремя, Payment Orchestration управляет статусом транзакции.

Политикам нужны версии и даты вступления в силу

Распространённая ошибка — хранить только «текущую политику».

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

В каждом наборе правил должны быть:

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

При оценке запроса система должна сохранять след использованной версии политики.

Когда Eligibility Engine должен остановиться?

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

Например:

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

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

Это тот же принцип закрытия при сбое, который применяется в системах обработки денег.

Коды причин важны не меньше результата

Eligibility Engine не должен возвращать только:

• true;
• false;
• одно число.

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

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

Коды причин помогают:

• интерфейсу объяснять результат пользователю;
• службе поддержки проводить поиск;
• операционной команде классифицировать ошибки;
• измерять статистику;
• проверять решения при аудите.

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

Как компании следует управлять Eligibility Engine?

Eligibility Engine нужно рассматривать как исполняемую политику, а не просто фрагмент кода.

У каждого важного правила должны быть:

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

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

Операционная команда должна знать, почему запрос удержан.

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

KPI для мониторинга

Можно отслеживать:

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

Не следует оптимизировать KPI в направлении «разрешить как можно больше транзакций». Цель — правильные условия, объяснимость и последовательность.

Заключение

Eligibility Engine помогает EWA чётко разделять уже сформированную заработанную оплату и право использовать сервис в конкретный момент. Хороший механизм повторно оценивает условия при запросе, использует версионированные политики, возвращает ясные коды причин и останавливается при неопределённости важных данных. Компания может менять политику, сохраняя целостность расчёта зарплаты и возможность объяснить решение работнику.

Автор: Do Huy Le — Tổng Giám Đốc, Nhan Kiet Manpower Supply Co., Ltd.

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