Бизнес франшизы России изнутри: как платформа для аутсорсинга персонала считает выплаты и упирается в лимиты ФНС

Когда говорят о кадровой платформе для аутсорсинга линейного персонала, обычно представляют простую базу: список телефонов, кнопка «назначить на смену» и экран со статистикой по заказам. На практике любой такой сервис, который платит самозанятым, перед каждой выплатой обязан свериться с внешним API налоговой службы — и именно это определяет, сколько городов и исполнителей система способна обслуживать без задержек. Разберём архитектуру такой платформы и найдём её реальное узкое место.

Почему перед каждой выплатой нужен запрос в ФНС

Режим налога на профессиональный доход введён федеральным законом от 27.11.2018 № 422-ФЗ. У него есть жёсткое ограничение: доход самозанятого не может превышать 2,4 млн рублей за календарный год. Как только лимит пробит, человек автоматически теряет статус плательщика НПД. Если платформа всё равно проводит выплату как по договору с самозанятым, а по факту статус уже слетел, у заказчика услуг возникает риск переквалификации отношений в трудовые с доначислением налогов и взносов. Поэтому перед расчётом система не имеет права доверять тому, что исполнитель «вроде оформлен» — она обязана проверить статус именно на дату смены.

ФНС опубликовала описание открытого интерфейса для такой проверки (версия 1.0.0 от 21.02.2019): на один запрос подаётся ИНН и дата, в ответ приходит статус плательщика НПД на эту дату. Документация к сервису устанавливает конкретные технические рамки: не более двух запросов в минуту с одного IP-адреса, таймаут на стороне клиента не короче 60 секунд, а дата в запросе не может быть раньше 1 января 2019 года (старт режима) и позже текущего дня. Если запрос технически корректен, но данные в нём не проходят проверку — например, указана недопустимая дата — сервис возвращает не серверную ошибку, а бизнес-код HTTP 422. Разработчику нужно отдельно обрабатывать этот случай, а не падать в общий лог ошибок.

Расчёт очереди: почему 150 исполнителей не проверяются одновременно

Возьмём обычный вечер расчёта: по сети нужно закрыть выплаты 150 исполнителям, которые отработали смены в разных городах. Лимит — 2 запроса в минуту с одного IP. Арифметика простая: 150 / 2 = 75 минут очереди только на статус-чек, прежде чем деньги реально пойдут на карты. Это не сбой и не перегрузка серверов — система работает штатно, просто каждая проверка физически не может пройти быстрее лимита внешнего сервиса.

Если у оператора один IP-адрес и выплаты идут одной большой пачкой в конце дня, последний в списке исполнитель получит деньги почти на полтора часа позже первого. Решается это либо пулом из нескольких IP-адресов с распределением запросов между ними, либо растягиванием расчёта по времени в течение дня, а не одним залпом вечером. Оба варианта требуют отдельной очереди задач с ретраями на таймаут и на код 422 — то есть простого крон-скрипта «раз в сутки дергаем ФНС по всем» для сети из нескольких десятков городов уже недостаточно.

Конечный автомат смены: четыре кнопки и таймер на замену

Отдельный технический слой — статусная модель самой смены в мобильном приложении исполнителя. По сути это конечный автомат из четырёх состояний: «Выехал», «На месте», «Работа выполнена», «Оплата получена». Переход между ними логируется с таймстампом, и это не просто красивый трекинг для заказчика — на этом держится механизм замены.

За час до начала смены система проверяет, нажал ли исполнитель «Выехал». Если нет — срабатывает таймер-эскалация, и диспетчеру приходит сигнал, что человек, скорее всего, не выйдет. Остаётся час-полтора, чтобы подобрать замену из базы, пока смена ещё не началась. Технически это обычный отложенный джоб с условием: таймер ставится при назначении на смену и либо гасится статусом «Выехал», либо срабатывает и создаёт задачу диспетчеру.

Где на самом деле узкое место

Если смотреть на такую систему как на хранилище данных, она выглядит тривиально: таблицы исполнителей, заказов, статусов. Но реальное узкое место — не база данных и не рассылка push-уведомлений по заказу, а именно дисциплина обращения к чужому API с фиксированным лимитом в минуту. Любая платформа, которая массово выплачивает деньги самозанятым, рано или поздно упирается ровно в эти 2 запроса в минуту с одного IP — и дизайн очереди выплат определяет, сколько городов она способна обслуживать параллельно без роста задержек.

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

Комиссия сервиса, через который проходят сами выплаты на карту, в таких расчётах обычно составляет около 4,5% от суммы операции — отдельная строка расходов, не связанная с проверкой статуса, но учитываемая в той же очереди обработки платежа.

Как у вас в проектах решали проблему лимитов стороннего API при массовых выплатах — пул IP-адресов, растягивание по времени или что-то ещё? Поделитесь в комментариях, насколько сильно это било по срокам выплат.