← На главную

При разработке и адаптации типовых конфигураций «1С:Предприятие» под нужды конкретного бизнеса программисты часто сталкиваются с требованиями пользователей увеличить разрядность номеров документов. Например, стандартной длины в 11 символов в конфигурации «1С:Зарплата и управление персоналом» (ЗУП) может не хватать, если организация использует сложные префиксы или осуществляет интеграцию с внешними системами, где номера документов имеют длину 20 и более знаков. Для взаимодействия с внешними ИТ-системами без прямого API можно настроить программных роботов для автоматического переноса данных без изменения структуры метаданных конфигурации.

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

Где находится свойство «Длина номера» в конфигураторе?

Часто начинающие разработчики пытаются найти реквизит Номер в ветке «Реквизиты» конкретного документа в дереве метаданных. Однако этого реквизита там нет. Дело в том, что Номер — это стандартный (платформенный) реквизит, управление свойствами которого осуществляется на уровне самого объекта метаданных.

Выясним по шагам, как найти и изменить это свойство в основной конфигурации:

1. Откроем дерево конфигурации и найдем интересующий нас документ (например, ДоговорАвторскогоЗаказа).
2. Нажмем на него правой кнопкой мыши и выберем пункт «Свойства» (или нажмем клавишу F4).
3. В открывшейся панели свойств найдем раздел «Нумерация».
4. Именно здесь располагается свойство «Длина номера» (по умолчанию для многих документов оно равно 11 символам).

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

Ограничение платформы: почему расширение выдает ошибку?

Если ваше обсуждение или разработка происходят на платформе версии **8.3.21 и ниже**, попытка изменить длину номера (например, с 11 на 21 символ) внутри расширения приведет к жесткой ошибке применения метаданных при попытке обновить конфигурацию базы данных. Платформа выдаст сообщение о невозможности изменения структуры данных через расширение.

Это связано с тем, что длина номера напрямую определяет физическую структуру таблиц СУБД (MS SQL, PostgreSQL и др.). На старых версиях платформы механизмы расширений не имели монопольного права на реструктуризацию таких системных полей метаданных, как коды справочников и номера документов.

Революция в платформе 8.3.22: официальная поддержка

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

Теперь в расширение можно заимствовать документ и изменять у него следующие свойства:

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

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

Важное условие работы нового механизма: режим совместимости вашей конфигурации в конфигураторе должен быть установлен в значение **не ниже 8.3.22**. Если конфигурация работает в режиме совместимости, например, 8.3.20 (что часто встречается в конфигурациях ERP или ЗУП предыдущих релизов), то новые возможности платформы задействованы не будут, и вы по-прежнему будете получать ошибку совместимости метаданных.

Смертельные риски работы с базой данных при изменении длины номера

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

1. Катастрофа при отключении расширения. Представим ситуацию: вы успешно увеличили длину номера до 21 символа через расширение. Пользователи начали активно вводить документы с длинными номерами (например, "ДГ-000000000000000021"). Спустя полгода в процессе обновления или из-за сбоя администратор временно отключает это расширение. При запуске системы без расширения платформа принудительно вернет длину номера к исходным 11 символам. Все длинные номера в физических таблицах базы данных будут безвозвратно **обрезаны**. Это мгновенно приведет к дублированию номеров, нарушению уникальности и полной невозможности создавать и записывать новые документы данного типа. При возникновении подобных ошибок в учете можно автоматически сравнить бухгалтерские и налоговые проводки между базами 1С для поиска расхождений.
2. Проблемы при обновлении типовой конфигурации. Расширения, меняющие структуру хранения данных, крайне чувствительны к релизам поставщика. Если фирма «1С» в очередном обновлении изменит свойства нумератора или самого документа, ваше расширение может не примениться («отвалиться») в режиме «Предприятие», заблокировав работу пользователей до вмешательства программиста. Для снижения рисков при выполнении подобных работ можно автоматизировать архивирование, обновление и тестирование баз 1С в тихом режиме.

Альтернативные и безопасные решения задачи

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

Вариант 1. Использование дополнительных реквизитов (БСП)

Самый безопасный и цивилизованный метод — оставить стандартный короткий системный номер (11 символов) в покое. Он будет использоваться платформой для внутренней автонумерации и поддержания уникальности транзакций. Для хранения реального длинного номера внешнего ведомства или контрагента мы настроим дополнительный реквизит.

Сделать это можно без программирования:

1. Перейдем в раздел «Администрирование» -> «Общие настройки» -> «Дополнительные реквизиты и сведения».
2. Найдем в списке документ ДоговорАвторскогоЗаказа и добавим новый реквизит с именем «Внешний номер» и типом «Строка» (длиной, например, 30 символов).
3. Выведем этот реквизит на форму документа. Теперь пользователи могут вводить любые длинные значения, а стандартные механизмы 1С не пострадают.

Вариант 2. Изменение длины номера в основной конфигурации

Если длинный номер обязательно должен быть именно в стандартном поле Номер (например, этого требуют жестко прописанные правила обмена в сторонних системах), то делать это нужно **в основной конфигурации**, сняв объект с поддержки (переведя в режим редактирования с сохранением поддержки).

Да, это усложнит процедуру последующих обновлений программы (придется вручную контролировать изменения этого документа при обновлении через сравнение-объединение), но этот шаг полностью обезопасит базу данных от случайной потери информации при отключении расширений.

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