← На главную

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

Анализ проблемы: почему данные могут пострадать?

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

Рассмотрим, что происходит на физическом уровне СУБД. Если между принятием изменений метаданных и окончательным обновлением базы данных (нажатие клавиши F7) мы не восстановим свою длину номера, платформа выполнит SQL-команду по изменению структуры таблицы. В этот момент произойдет усечение (truncation): все символы, выходящие за пределы новой (укороченной) длины, будут физически удалены из таблиц базы данных. Даже если после этого мы снова увеличим длину до 15, потерянные символы не вернутся — они будут заменены пробелами или просто исчезнут.

Способ 1. Правильная последовательность действий при ручном обновлении

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

1. Запускаем процедуру обновления через меню Конфигурация — Поддержка — Обновить конфигурацию.
2. Проходим все этапы сопоставления объектов. На этапе сравнения и объединения важно убедиться, что изменения в структуре номера принимаются.
3. После завершения объединения, когда конфигуратор предложит обновить конфигурацию базы данных (синий бочонок или клавиша F7), не нажимаем «Да».
4. Переходим в свойства измененного документа и вручную возвращаем нужную нам длину номера (например, снова устанавливаем 15 вместо 9).
5. Только после того, как в метаданных установлена корректная длина, выполняем обновление базы данных (F7).

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

Способ 2. Использование настроек сравнения и объединения

Чтобы не заниматься ручной правкой после каждого обновления, мы можем настроить правила объединения объектов. Рассмотрим подробнее этот функционал:

В окне «Сравнение и объединение» при обновлении конфигурации найдите нужный документ. Если раскрыть дерево свойств объекта, можно увидеть свойство Длина номера. Мы можем:

• Снять галочку напротив этого свойства, тогда настройки поставщика не перекроют наше изменение.
• Установить режим объединения «Взять из основной конфигурации» для данного конкретного свойства.

Важно: этот метод требует внимательности, так как при массовом обновлении легко пропустить один из объектов.

Способ 3. Использование расширений (для платформы 8.3.22 и выше)

Самым современным и безопасным методом является использование расширений конфигурации. Начиная с версии платформы 8.3.22, возможности расширений были значительно расширены. Теперь мы можем менять свойства Длина кода и Длина номера, не снимая основную конфигурацию с «замка».

Проанализируем преимущества этого подхода:

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

Однако здесь есть критически важный нюанс, который мы должны учитывать: Режим совместимости. Даже если вы установили платформу 8.3.22 или 8.3.25, но ваша конфигурация работает в режиме совместимости, например, с версией 8.3.21, возможность изменения длины номера в расширении будет заблокирована. Система выдаст ошибку при попытке применить такое расширение.

Посмотрим, какие еще свойства номеров можно менять в расширениях версии 8.3.22+:

• Тип номера: можно изменить с «Число» на «Строка».
• Контроль уникальности: возможность включить или отключить проверку дублей.
• Периодичность: изменение частоты обнуления нумерации (год, квартал, месяц и т.д.).

Нюансы автонумерации при изменении длины

Рассмотрим ситуацию, когда мы успешно увеличили длину номера. Стоит помнить о механизме автонумерации 1С. Если вы увеличили длину с 9 до 12 символов, старые номера (например, «000000001») останутся прежними. При создании нового документа система попытается сгенерировать номер, исходя из имеющихся данных.

Иногда это приводит к сбоям, если в базе присутствуют номера, заполняющие всю старую длину без префиксов. Рекомендуется после изменения длины выполнить перенумерацию документов (с помощью стандартных обработок), чтобы привести все номера к единому формату с учетом новой разрядности. Это гарантирует корректную работу метода УстановитьНовыйНомер().

Работа в облачных сервисах (1C:Fresh)

Если ваша база работает во «Фреше», использование расширений для изменения структуры данных (к которым относится длина номера) накладывает дополнительные обязательства. Такие расширения проходят строгий аудит безопасности и производительности. Поскольку изменение длины номера — это изменение структуры таблиц базы данных, специалисты сервиса проверяют, не приведет ли это к блокировкам или деградации производительности при реструктуризации больших объемов данных.

Подведем итог: наиболее надежный путь для современных систем — переход на платформу 8.3.22+ и использование расширений при условии отключения режима совместимости. Для устаревших систем единственным выходом остается жесткий контроль последовательности действий при обновлении метаданных и обязательное создание резервной копии перед любым обновлением конфигурации базы данных.