В процессе эксплуатации типовых решений 1С, таких как Бухгалтерия предприятия, разработчики часто сталкиваются с необходимостью увеличить длину номера документа или кода справочника. Ранее это требовало снятия конфигурации с поддержки и внесения изменений непосредственно в основную базу. С выходом платформы 8.3.22 ситуация изменилась: теперь менять длину стандартных полей можно через расширения. Однако этот процесс таит в себе скрытые угрозы, связанные с потерей данных и нарушением уникальности. Проанализируем, как правильно выполнить этот переход, сохранив конфигурацию на поддержке.
Прежде чем приступать к разработке расширения, необходимо убедиться, что ваша информационная база соответствует техническим требованиям платформы. Рассмотрим ключевой момент: возможность изменения длины Кода или Номера напрямую зависит от свойства РежимСовместимости.
Если в вашей базе установлена версия 8.3.24, но режим совместимости основной конфигурации ниже 8.3.22, попытка изменить длину в расширении приведет к ошибке: "Значение контролируемого свойства ДлинаКода у объекта не совпадает со значением в расширяемой конфигурации". Платформа блокирует это изменение, так как механизм реструктуризации таблиц через расширения для стандартных реквизитов был реализован именно начиная с версии 8.3.22.
Таким образом, первым делом проверим настройки:
Режим совместимости установлен в значение 8.3.22 или выше.Важно осознать последствия использования расширений для изменения физической структуры таблиц базы данных. В отличие от обычных реквизитов, стандартные поля Номер и Код являются ключевыми. Разберем, что происходит при критическом сбое или случайном удалении расширения:
Физическая обрезка данных: Если в расширении длина номера увеличена до 15 символов, а в основной конфигурации она осталась равной 11, то при отключении или удалении расширения платформа выполнит реструктуризацию. Все номера, длина которых превышала 11 символов, будут физически усечены в таблицах SQL. Восстановить "отрезанные" хвосты простым обратным подключением расширения не удастся — данные будут безвозвратно потеряны.
Нарушение уникальности: Представим ситуацию, когда у вас были документы с номерами СТ1906/24-101 и СТ1906/24-102. При уменьшении длины до 11 символов оба номера превратятся в СТ1906/24-1. База данных выдаст ошибку нарушения уникальности индекса, что может привести к невозможности запуска системы или ошибкам при обновлении.
Рассмотрим наиболее надежный способ переноса данных, который позволяет избежать рисков, связанных с промежуточной реструктуризацией при возврате конфигурации на поддержку.
Шаг 1: Подготовка расширения
Создадим новое расширение и добавим в него целевой документ. Добавим в этот документ новый дополнительный реквизит, например, ВременныйНомер, с типом Строка и длиной, достаточной для хранения самого длинного номера в вашей базе. Установим расширение на рабочую базу.
Шаг 2: Копирование данных
Напишем и запустим обработку, которая перенесет текущие значения из поля Номер в поле ВременныйНомер. Пример кода для такой обработки:
Выборка = Документы.РеализацияТоваровУслуг.Выбрать();
Пока Выборка.Следующий() Цикл
ОбъектДок = Выборка.ПолучитьОбъект();
ОбъектДок.ВременныйНомер = ОбъектДок.Номер;
ОбъектДок.ОбменДанными.Загрузка = Истина;
ОбъектДок.Записать();
КонецЦикла;
Шаг 3: Приведение конфигурации к типовому виду
Теперь можно безопасно вернуть основную конфигурацию на поддержку (заменив её типовой конфигурацией того же релиза). В этот момент номера в основном поле Номер могут обрезаться, но мы об этом не беспокоимся, так как полные копии сохранены в поле ВременныйНомер нашего расширения.
Шаг 4: Изменение длины номера в расширении
В свойствах документа в расширении изменим длину стандартного реквизита Номер на нужную (например, 15). Платформа выполнит реструктуризацию и увеличит размер поля в таблицах БД.
Шаг 5: Восстановление номеров
Запустим обратную обработку, которая вернет данные из ВременныйНомер в стандартное поле Номер. После этого временный реквизит можно удалить из расширения.
Проанализируем альтернативный вариант, упомянутый в обсуждении — использование обработки УниверсальныйОбменДаннымиXML. Этот метод кажется проще, но имеет свои нюансы:
Выясним причину возможных проблем при таком подходе. Как показывает практика участников обсуждения, после масштабной загрузки XML могут возникнуть ошибки в журналах документов. Платформа может выдать сообщение: "Документ не зарегистрирован в журнале". Это происходит из-за того, что при изменении длины номера через расширение индексы журналов перестраиваются особым образом. После такой загрузки обязательно требуется запуск процедуры Тестирование и исправление (ТиИ) с флагами "Пересчет итогов" и "Реиндексация таблиц". Будьте готовы, что на больших базах (от 100 Гб) этот процесс может занять сутки и более.
При работе с расширенными номерами в 1С:Бухгалтерия часто возникает проблема с префиксами. Например, для счетов-фактур на аванс часто используется префикс "А". Рассмотрим ситуацию: если вы увеличили длину номера, но не скорректировали алгоритмы формирования номера в коде, 1С может начать генерировать номера некорректно.
Если в базе смешиваются старые короткие номера и новые длинные, механизм УстановитьНовыйНомер() может начать выдавать ошибки или дублировать номера. Проанализируем решение: в расширении рекомендуется перехватить процедуру ПриУстановкеНовогоНомера (или аналогичную в модуле менеджера) и убедиться, что префиксация учитывает новую длину. Помните, что 1С ищет максимальный номер в пределах текущего года и префикса. Если в базе останется хотя бы один некорректный "длинный" номер, автонумерация может "затыкаться" на нем до конца периода.
Если ваша база участвует в обмене данными (например, через EnterpriseData или РИБ), изменение длины номера через расширение должно быть синхронно внедрено во все узлы обмена. Рассмотрим последствия игнорирования этого правила:
Номер + Дата. Разная длина полей приведет к тому, что система "не узнает" существующий объект.Заключение: Перенос изменений в расширение — это правильный шаг для упрощения процесса обновлений, но он требует ювелирной точности при работе с данными. Обязательно тестируйте весь процесс на копии базы и проверяйте результат с помощью отчетов по уникальности номеров.