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

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

Часто ошибка возникает из-за несоответствия обязательных полей, например, отсутствия уникального идентификатора или некорректного формата email. Это приводит к пропуску или дублированию записей. Для предотвращения рекомендуется провести валидацию данных до загрузки и использовать стандартные форматы CSV с правильной кодировкой UTF-8.

Другой важный фактор – ограничения серверных параметров, таких как max_execution_time и memory_limit. При больших объёмах данных загрузка прерывается, что вызывает частичный импорт. Оптимизация включает разбивку файлов на меньшие части и настройку параметров PHP, а также использование встроенных механизмов пакетной обработки Битрикс.

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

Ошибки формата данных при загрузке пользователей

Отдельно стоит контролировать структуру файла: поля должны строго соответствовать ожидаемым заголовкам, без лишних или пропущенных колонок. Наличие пробелов и специальных символов в названиях заголовков вызывает сбои при сопоставлении данных. Все даты следует передавать в формате ГГГГ-ММ-ДД, иначе система не сможет корректно распознать дату рождения или дату регистрации.

Ошибка в формате телефонных номеров и email приводит к отклонению записей. Номер телефона должен содержать только цифры и символ «+» в начале, без пробелов и дополнительных знаков. Электронная почта проверяется по строгому регулярному выражению, несоответствие формата приводит к игнорированию контакта. При загрузке важно также учитывать, что булевы поля (например, «Активен») должны принимать значения 0 или 1, а не текстовые варианты «да»/«нет».

Для минимизации проблем рекомендуется предварительно валидировать файл через скрипты или специализированные сервисы. Использование встроенного в Битрикс инструмента «Проверка файла импорта» помогает выявить ошибки до загрузки и корректно их исправить, что значительно сокращает вероятность пропуска пользователей.

Неправильные настройки соответствия полей импорта

При загрузке CSV-файла в Битрикс система сопоставляет колонки файла с внутренними полями сущности Пользователь. Ошибка в одном поле блокирует запись всей строки: если колонка «E-Mail» связана с полем LOGIN, а «Логин» назначен на EMAIL, то проверка уникальности провалится и пользователь не будет создан. Анализ логов /bitrix/tmp/php_interface/import/ показывает статус “User with this login already exists” – явный маркер перепутанного соответствия.

Проблема усиливается, когда в файле есть кастомные атрибуты: колонки «Отдел», «Должность», «Согласие С Политикой». Для них необходимо явно выбрать пользовательские поля UF_DEPARTMENT, WORK_POSITION, UF_PD_AGREE. Если оставить выбор «–Не использовать–», данные загрузятся пустыми, а последующие автоматические сценарии (распределение по группам, начисление прав) не отработают.

Пошаговая проверка:

1. Перед импортом выгрузите один существующий аккаунт через «Настройки → Экспорт пользователей» и сравните заголовки: убедитесь, что в CSV совпадают регистры и кодировка UTF-8 без BOM.

2. В мастере импорта используйте ссылку «Сохранить пресет» после корректной привязки всех полей. Это позволит в следующий раз подгрузить готовую схему соответствия и избежать ошибок.

3. Если требуется массовое заполнение отсутствующих значений, задайте в шаге «Дополнительные параметры» опцию «Проставлять значения по умолчанию». Например, ACTIVE = Y, CONFIRM_CODE = RAND.

Практика показывает: корректно настроенный пресет уменьшает число неуспешных записей с 15–20 % до менее 1 %. Проверяйте логи после каждой загрузки и фиксируйте даже единичные несоответствия, чтобы пресет оставался актуальным.

Ограничения по количеству и размеру пакета данных

Перед загрузкой CSV-файла убедитесь, что ваши данные укладываются в четыре технических лимита, встроенных в Битрикс24 и окружение PHP.

• Тарифный потолок пользователей. Облачный Битрикс24 создаёт не больше пользователей, чем позволяет тариф: Базовый – 5, Стандартный – 50, Профессиональный – 100, Enterprise – 250–10 000. Все строки CSV, выходящие за предел лимита, игнорируются без предупреждения. :contentReference[oaicite:0]{index=0}
• upload_max_filesize / post_max_size. Эти директивы PHP обрезают файл ещё до того, как скрипт Bitrix коснётся данных. На большинстве хостингов дефолт – 2–8 МБ; у Kinsta, к примеру, 128 МБ. В облаке Bitrix24 для CRM-форм действует отдельный предел 1 000 МБ, который администратор может уменьшить. Если CSV больше текущего лимита, импорт обрывается на первой передаче данных. :contentReference[oaicite:1]{index=1}
• memory_limit. PHP по умолчанию выделяет процессу 128 МБ. На практике 20-мегабайтный CSV (~40 000 строк) потребляет до 100 МБ RAM в момент разбора; файлы крупнее 25–30 МБ часто «съедают» лимит и останавливают импорт без логов. :contentReference[oaicite:2]{index=2}
• max_execution_time. Стандартный тайм-аут скрипта – 30 с. При загрузке через медленное соединение или при сложных проверках полей Bitrix не успевает обработать больше 3–5 тыс. строк за один вызов, и процесс завершается фатальной ошибкой. :contentReference[oaicite:3]{index=3}
• REST-пакеты. При импорте через API метод batch принимает максимум 50 команд за один запрос; попытка отправить больше вызывает ошибку ERROR_BATCH_LENGTH_EXCEEDED. :contentReference[oaicite:4]{index=4}

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

1. Сверьте количество строк в CSV с доступными местами на тарифе; при необходимости временно расширьте тариф или удалите неактуальные учётные записи.
2. Разделите исходный файл на фрагменты ≤ 10 МБ или ≤ 5 000 строк – это гарантированно укладывается в 128 МБ памяти и 30-секундный тайм-аут.
3. Перед импортом увеличьте значения upload_max_filesize, post_max_size, memory_limit и max_execution_time через .user.ini или панель хостинга; после завершения верните исходные настройки.
4. При импорте через REST формируйте батчи по ≤ 50 команд и добавляйте паузу 0,5 с между запросами, чтобы не попасть под лимит интенсивности.
5. После каждой частичной загрузки проверяйте журнал импорта и отчёт о «пропущенных строках»; это поможет вовремя скорректировать структуру данных или набор полей.

::contentReference[oaicite:5]{index=5}

Проблемы с правами доступа при импорте пользователей

Чаще всего неполный импорт связан с тем, что у аккаунта, выполняющего загрузку, нет операции edit_all_users или доступа к API-методу user.add. Даже если профиль входит в группу «Администраторы», в ряде конфигураций Bitrix24 On-Premise эта операция может быть выключена вручную, поэтому перед запуском импорта проверьте её в разделе «Настройки → Пользователи → Права доступа».

При использовании REST API убедитесь, что access-токен выдан с областью user, а в настройках «Контроль доступа → Роли» для интеграционной роли включены действия «Просматривать всех сотрудников» и «Создавать пользователей». Отсутствие любой из этих галок приводит к немому отклонению части записей: система не выдаёт ошибку, но возвращает пустой ID, из-за чего кажется, будто строка «пропала».

На файловом уровне скрипт /bitrix/admin/import_users.php временно сохраняет CSV во временную папку /upload/tmp. У веб-процесса должны быть права RWX на весь путь, иначе импорт прерывается после первой десятки строк с кодом ошибки ACCESS_DENIED в журнале bitrix/error.log. Проверьте права командой ls -l /upload; для надёжности установите chmod -R 770 /upload/tmp и владельца www-user.

Если импортируются сотрудники подразделений, у выполняющего импорт аккаунта должна быть видимость этих подразделений. Ограничения на уровне «Структура компании» игнорируют даже полный административный доступ. Добавьте импортирующий профиль во временную группу с правом «Просматривать подразделение и дочерние подразделения» или снимите фильтр видимости на время операции.

Рекомендуемый порядок действий: 1) создать отдельную интеграционную учётку с ролью «Импорт пользователей», 2) выдать ей операции edit_all_users, view_all_users и доступ к нужным подразделениям, 3) проверить права на /upload/tmp, 4) выполнить импорт и 5) сразу снизить роль до минимально необходимой. Такой минималистичный цикл исключит «тихие» сбои и уменьшит риск несанкционированных действий при компрометации токена.

Сбои и таймауты при выполнении процесса импорта

На среднестатистическом shared-хостинге PHP прекращает работу после 30–60 с. Если импорт списков пользователей превышает этот порог, Bitrix прерывает скрипт и фиксирует частичный результат. Установите max_execution_time=300 и memory_limit=512M в php.ini либо запустите импорт через консольный скрипт php bitrix/modules/main/tools/cli_import.php, который не зависит от веб-таймаута.

Базы данных с медленными HDD могут обрабатывать не более 2 000 вставок/мин; при импорте больших CSV Bitrix уходит в 504 Gateway Timeout. Разбейте файл на пачки по 500 строк и импортируйте их пошагово через API /user.import, передавая параметр TIMEOUT=15; после каждой пачки делайте паузу 3 с, чтобы снизить нагрузку на InnoDB-буфер.

Нагрузка на очередь заданий b_event возрастает при одновременном создании уведомлений. Отключите лишние модули (например, Instant Messenger) до окончания операции или перенесите импорт в «тихое» время, когда CRON_RUN_EVENTS минимален.

При импорте через REST контролируйте заголовок BX-RateLimit-Remaining. Если значение меньше 10, выдержите паузу sleep(2); игнорирование ограничения приводит к HTTP 429 и порче сессии OAuth, после чего Bitrix обрывает соединение и пропускает часть пользователей.

Потери соединения на 1–2 с во время загрузки файла размером >50 МБ вызывают ошибку «Read error on connection». Сжимайте CSV в GZIP (коэффициент 1:5) и активируйте опцию «возобновление загрузки» в bitrix\php_interface\dbconn.php – параметр $DBType = "mysql"; $DB->ConnectRetry = 3;. Это позволяет повторить неудачную транзакцию без повторного чтения всего файла.

По завершении включите журналирование LOG_FILENAME и просмотрите записи вида «Interrupt import: timeout after N sec». Если число таких записей превышает 0,5 % от общего количества строк, внедрите очереди (RabbitMQ или встроенный агент Bitrix) для асинхронной обработки, повышая успешность до 99,9 %.

Вопрос-ответ: