В процессе разработки на платформе «1С:Предприятие» программисты часто сталкиваются с необходимостью кастомизации типовых решений без изменения основной конфигурации. Использование расширений — это стандарт индустрии, однако работа с метаданными, такими как Длина номера документа или Длина кода справочника, имеет свои тонкости. Разберем ситуацию, когда вы изменили длину номера в расширении, но в пользовательском режиме длина осталась прежней.
Первым делом проанализируем технические требования. Возможность изменять длину номера и кода в расширениях — это относительно новая функциональность. Она появилась только в версии платформы 8.3.22. Если ваша информационная база работает на более старой платформе, данная настройка просто не будет учитываться системой.
Однако простого обновления платформы недостаточно. Рассмотрим критически важное условие: режим совместимости. Для того чтобы изменения вступили в силу, необходимо соблюдение следующих правил:
Если основная конфигурация, например, находится в режиме совместимости 8.3.17, то даже на платформе 8.3.24 расширение не сможет переопределить длину номера. Выясним причину: платформа в режимах совместимости ниже 8.3.22 использует старые алгоритмы работы с таблицами базы данных, которые не предполагают динамического изменения структуры ключевых полей через расширения. Для предотвращения других потенциальных ошибок и несовместимостей при разработке расширений можно использовать инструмент для автоматического анализа конфигураций и расширений.
Проанализируем правила изменения длины. В среде «1С:Предприятие» действует строгий принцип сохранения целостности данных. В расширениях длину номера можно только увеличивать. Рассмотрим пример:
Если в основной конфигурации длина номера документа СчетФактураВыданный составляет 11 символов, а вы в расширении установите значение 9, платформа проигнорирует это изменение. Это сделано для того, чтобы избежать обрезки существующих данных и нарушения уникальности номеров. Если же вы увеличите длину до 15 символов, система примет изменения, при условии соблюдения режимов совместимости.
Посмотрим на свойства объекта в расширении. Для корректной работы механизма нумерации крайне важно, чтобы Тип номера (Число или Строка) в расширении полностью совпадал с типом в основной конфигурации. Разберем ситуацию: если при добавлении документа в расширение вы случайно изменили тип или он определился неверно, платформа заблокирует любые попытки изменения длины, так как возникнет конфликт типов на уровне SQL-таблицы.
Изменение длины номера — это не просто визуальная настройка, это физическое изменение структуры таблиц. В отличие от модулей или форм, такие изменения требуют реструктуризации. Иногда, особенно на ранних релизах ветки 8.3.22, платформа может не инициировать автоматическое обновление таблиц при сохранении расширения.
Разберем шаги, которые помогут «подтолкнуть» систему к обновлению:
Активно в списке расширений для вашего расширения.В некоторых случаях помогает временное удаление документа из расширения и его повторное добавление с уже нужной длиной номера.
Допустим, метаданные изменились успешно, но в интерфейсе вы по-прежнему не можете ввести длинный номер. Выясним причину в свойствах элементов формы. Если форма документа была заимствована в расширение ранее, она сохранила свойства элементов управления из «старой» версии метаданных.
Проверьте следующие свойства поля ввода номера на форме:
Маска: если там жестко задано количество символов, ввод будет ограничен.Формат: проверьте наличие ограничений на количество знаков.АвтоотметкаНезаполненного и другие связанные свойства.Рекомендуется обновить форму в расширении или вручную скорректировать свойства поля ввода, чтобы они соответствовали новой длине номера.
Рассмотрим ситуацию: вы увеличили длину, но при создании нового документа номер кажется прежним. Важно понимать, что 1С использует механизм автонумерации, который опирается на существующие записи. Если в базе есть номер "00001", и вы увеличили длину, платформа может продолжать предлагать номера в старом формате, пока не встретит номер новой длины или пока не будет выполнена перенумерация.
Для проверки работы новой длины попробуйте программно создать объект и присвоить ему длинный номер:
НовыйДокумент = Документы.СчетФактураВыданный.СоздатьДокумент();
НовыйДокумент.Дата = ТекущаяДата();
// Проверяем возможность записи номера увеличенной длины
НовыйДокумент.Номер = "СФ-0000000001";
НовыйДокумент.Записать();
Если программная запись проходит успешно, значит, на уровне базы данных изменения применились, и проблему стоит искать в интерфейсе или механизме префиксов.
Как отмечают специалисты, в первых сборках версии 8.3.22 наблюдались ошибки, когда платформа игнорировала настройки расширения при использовании метода ЗаполнитьЗначенияСвойств() или при копировании документов. Эти баги были исправлены в последующих патчах и в ветке 8.3.23. Если вы столкнулись с необъяснимым поведением системы, проанализируйте возможность обновления платформы до актуального релиза. Переход с 8.3.22 на 8.3.23 часто решает проблемы с нестабильной работой метаданных в расширениях.