Почему в документе 1С нельзя ввести более 99 999 строк и как обойти это ограничение?

При попытке провести или записать документ с большим объемом номенклатуры пользователи и разработчики могут столкнуться с системным ограничением конфигурации или платформы. В типовых конфигурациях, таких как «1С:Управление торговлей», при превышении определенного объема строк срабатывают встроенные проверки вида:

Если Параметры.КоличествоСтрок > 99999 Тогда
    // Предупреждение о превышении допустимого количества строк
КонецЕсли;

Разберем детально, чем обусловлен данный лимит, к каким последствиям приводит его обход и как правильно организовать работу со сверхбольшими объемами данных в «1С:Предприятии».

Причина ограничения на уровне платформы и СУБД

Выясним природу этого лимита. Главная причина кроется не в логике конкретной конфигурации, а в архитектуре хранения табличных частей платформы 1С на уровне реляционной базы данных:

1. Разрядность поля номера строки в СУБД: Во всех таблицах табличных частей стандартный реквизит НомерСтроки транслируется в колонку базы данных _LineNo с фиксированным типом numeric(5, 0). Это физически ограничивает диапазон значений числами от 1 до 99 999. Попытка записать 100 000-ю строку вызовет ошибку переполнения разрядности на уровне SQL-сервера.
2. Сериализация и оперативная память: Передача табличной части с десятками тысяч строк между клиентом и сервером требует огромных ресурсов. Происходит сериализация данных формы, что приводит к резкому потреблению оперативной памяти рабочими процессами сервера 1С (rphost) и может вызвать аварийное завершение процесса по ограничению памяти.
3. Транзакционные блокировки: При проведении документа с десятками тысяч строк транзакция длится слишком долго. Это вызывает эскалацию блокировок таблиц регистров в СУБД, ошибки взаимных блокировок (deadlocks) и таймауты ожидания для других пользователей базы.

Способы решения и архитектурные рекомендации

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

1. Пакетная разбивка (дробление) документов

Наиболее надежный и рекомендуемый способ — программное разделение входящего массива на порции. Оптимальным размером пакета для проведения в типовых конфигурациях считается объем от 1 000 до 5 000 строк (максимум — 10 000 строк):

1. При загрузке данных из внешних источников (файлов Excel, XML, выгрузок через API) ведем подсчет добавляемых позиций.
2. При достижении установленного порога (например, 5 000 строк) завершаем запись текущего документа и создаем следующий экземпляр с тем же набором шапки.
3. Группируем документы по аналитическим разрезам — по складам, ставкам НДС, подразделениям или группам номенклатуры, что упрощает дальнейший контроль и проведение.

2. Свертка и агрегация строк

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

1. Загружаем данные во временную таблицу или в объект ТаблицаЗначений.
2. Применяем метод Свернуть() по ключевым аналитикам (номенклатура, характеристика, склад, цена, ставка НДС) с суммированием по полям количества и суммы.
3. Записываем в документ только агрегированный результат, что существенно сокращает итоговое количество строк.

3. Использование регистров сведений вместо табличных частей

Если документ выступает исключительно как регистратор исторического факта (например, импорт прайс-листа поставщика, инвентаризация гигантского распределительного центра или загрузка реестра платежей):

1. Отказываемся от заполнения табличной части документа.
2. Записываем строки напрямую в подчиненный или независимый регистр сведений, где в качестве измерения выступает ссылка на документ-регистратор, а номер строки хранится в ресурсе или реквизите с числовой разрядностью, превышающей 5 знаков.
3. Отображение данных в форме документа настраиваем через ДинамическийСписок с отбором по текущему документу. Это обеспечивает порционное чтение данных с сервера без зависания интерфейса и перегрузки оперативной памяти.

4. Фоновое и отложенное проведение

Если проведение созданных документов по-прежнему создает пиковую нагрузку на транзакционную систему, применяем разделение логики:

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