← На главную

Переход с устаревшей версии ЗУП 2.5 на актуальную ЗУП 3.1 часто сопровождается трудностями при конвертации исторических данных. Одной из самых критических ошибок, с которой сталкиваются специалисты, является сообщение о том, что табличная часть объекта Начальная штатная расстановка содержит более 99 999 строк. Давайте разберем, почему это происходит и как мы можем с этим справиться.

Понимание природы ошибки

Системная архитектура платформы 1С:Предприятие накладывает физическое ограничение на размер табличной части любого объекта, включая документ Перенос данных. Если в процессе выгрузки данных алгоритм пытается записать в один документ более 99 999 строк, происходит аварийное завершение процесса записи. В контексте ЗУП 3.1 документ Начальная штатная расстановка является контейнером для исторических записей, и при выборе «полного» варианта переноса (так называемый 1-й вариант) система пытается перенести всю историю начислений, переводов и индексаций за много лет, что неизбежно приводит к переполнению.

Шаг 1: Очистка базы-источника (ЗУП 2.5)

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

1. Удаление объектов: Обязательно удалите помеченные на удаление элементы. Хотя помощник переноса может игнорировать часть данных, физическое присутствие огромного количества «мусорных» записей увеличивает размер выгрузочного файла XML и потребление оперативной памяти.
2. Очистка регистров: Проверьте регистры накопления и сведения. Нередко в них скапливаются данные по давно уволенным сотрудникам или архивные записи, которые не требуют переноса в новую систему.
3. Свертка данных: Если законодательство и бизнес-процессы компании позволяют, рассмотрите вариант переноса только «сальдо» и актуальных начислений на дату перехода. Это значительно сократит количество строк в табличных частях.

Шаг 2: Выбор стратегии переноса

Разберем варианты, которые предлагает помощник перехода:

• Вариант 1 (Рекомендуемый 1С): Подразумевает перенос всей истории. При больших объемах данных он чаще всего приводит к ошибке переполнения табличной части, так как документ Перенос данных не рассчитан на такие объемы.
• Вариант 2 (Ограниченный): Позволяет задать глубину переноса (например, данные за последние 2 года). Этот вариант значительно безопаснее с точки зрения нагрузки на базу и риска получения ошибки 99 999 строк. Мы рекомендуем использовать этот подход, так как хранить всю историю «царя Гороха» в оперативной базе часто нецелесообразно.

Шаг 3: Технические приемы при загрузке

Если вы все же вынуждены переносить полный объем данных, учтите следующие технические аспекты:

Потребление оперативной памяти: Процесс rphost может потреблять десятки гигабайт оперативной памяти при десериализации XML-файла. Убедитесь, что сервер 1С имеет достаточный запас ОЗУ. Если процесс «зависает» на сутки, скорее всего, происходит бесконечное разрастание табличной части в памяти.

Анализ структуры: Если есть возможность, используйте отладчик для мониторинга процедуры ПослеЗагрузкиОбъекта в модуле ПереносДанныхЗарплатаКадры. Это позволит увидеть, на каком именно сотруднике или начислении происходит разрастание строк.

Рекомендация по минимизации данных

Если вы хотите избежать «боданий» с пользователями по поводу отсутствующих данных, но при этом система «падает», попробуйте применить стратегию упрощения. Например, вместо переноса всей истории индексаций, перенесите только итоговые плановые начисления, актуальные на дату перехода. Это можно сделать через настройку правил конвертации или предварительную свертку регистров в ЗУП 2.5.

Помните, что перенос данных — это не просто выгрузка и загрузка файла, а процесс подготовки данных. Если в ЗУП 2.5 накоплено 17 ГБ данных, попытка «затолкнуть» их все в ЗУП 3.1 без предварительной фильтрации — путь к долгой и нестабильной работе системы.