В процессе эксплуатации информационных систем на платформе 1С:Предприятие разработчики и пользователи часто сталкиваются с необходимостью адаптации функционала под специфические требования бизнеса. Одна из распространенных задач — это изменение длины или типа стандартных реквизитов, например, поля ИНН. Однако такие модификации, особенно без учета архитектурных принципов платформы, могут привести к серьезным проблемам, в частности, к «слету» или некорректной работе сторонних расширений.
Рассмотрим ситуацию, когда возникает потребность увеличить длину поля ИНН с привычных 10 или 12 символов до 18. Автор темы на форуме столкнулся с тем, что после такого изменения, сделанного напрямую в конфигурации, все подключенные расширения, которые использовали или заимствовали реквизит ИНН, перестали корректно функционировать. Это создает проблему постоянной переработки и адаптации расширений при каждом обновлении, что крайне неэффективно и трудозатратно.
В данном материале мы подробно разберем, почему подобный подход к модификации стандартных реквизитов считается нежелательным, какие альтернативные и более правильные решения существуют в экосистеме 1С, и как их эффективно применять, чтобы избежать конфликтов с расширениями и сохранить возможность легкого обновления системы.
Прежде чем углубляться в методы решения проблемы, давайте выясним, почему изменение длины стандартного реквизита ИНН является архитектурно неверным подходом и приводит к описанным сложностям. Необходимо понимать, что стандартные конфигурации 1С разработаны с учетом законодательных требований и бизнес-практик, и их структура имеет глубокие внутренние связи.
Для начала, давайте вспомним, что такое ИНН в контексте российского законодательства:
Таким образом, потребность в ИНН длиной 18 символов не соответствует ни одному из стандартных российских форматов ИНН. Если такая потребность возникла, это почти всегда означает, что под видом «ИНН» пытаются хранить какой-то другой идентификационный номер, например, налоговый номер контрагента из другой страны, который может быть буквенно-цифровым и иметь значительно большую длину.
В разработке программного обеспечения существует важный принцип, известный как Принцип открытости/закрытости (Open/Closed Principle). Он гласит, что программные сущности (классы, модули, функции и т.д.) должны быть открыты для расширения, но закрыты для модификации. Применительно к 1С, это означает, что вы должны иметь возможность добавлять новый функционал (расширять систему) без изменения существующего, проверенного и поддерживаемого функционала (модификации типовой конфигурации). Прямое изменение длины стандартного реквизита — это явное нарушение этого принципа. Вы изменяете то, что должно быть закрыто, и это неизбежно порождает каскад проблем.
Любое изменение типовой конфигурации, включая изменение длины реквизита, усложняет процесс ее обновления. При каждом новом релизе вам придется либо вручную сравнивать и объединять измененные объекты, либо сталкиваться с автоматическими заменами, которые могут откатить ваши изменения или привести к ошибкам. Это существенно увеличивает стоимость владения системой и риски возникновения сбоев.
В конфигурациях 1С существуют встроенные механизмы проверки ИНН (например, по контрольным цифрам), интеграции с внешними сервисами ФНС, а также логика формирования регламентированной отчетности. Изменение длины поля ИНН может привести к некорректной работе этих механизмов, так как они ожидают стандартный формат. В результате, пользователь может столкнуться с ошибками при заполнении документов, отправке отчетности или использовании онлайн-проверок.
Если ваша система 1С интегрирована с другими информационными системами (банками, ЭДО, CRM и т.д.), то изменение формата ИНН может нарушить эти интеграции. Внешние системы ожидают определенный формат данных, и расхождение в длине или типе ИНН потребует доработки всех смежных систем, что является крайне нежелательным и дорогостоящим.
Основная проблема, с которой столкнулся автор темы, — это «слет» расширений после изменения длины реквизита ИНН. Давайте разберем, почему это происходит и как платформа 1С обрабатывает такие ситуации.
Расширения в 1С:Предприятии — это мощный инструмент для доработки функционала без изменения типовой конфигурации. Они позволяют заимствовать объекты конфигурации (формы, реквизиты, модули) и модифицировать их поведение или добавлять свои элементы. Однако, когда вы заимствуете реквизит, расширение «запоминает» его исходные свойства, включая тип и длину.
Когда вы изменяете длину реквизита ИНН непосредственно в основной конфигурации, расширения, которые заимствовали этот реквизит, могут столкнуться с несколькими проблемами:
Важно отметить, что начиная с платформы 8.3.18, возможности расширений были значительно расширены. Появилась возможность изменять типы и длину реквизитов основной конфигурации с помощью расширений напрямую, что позволяет, например, увеличить длину строковых или числовых полей без снятия конфигурации с поддержки. Однако, даже эта возможность предназначена для использования с осторожностью и не отменяет принципы хорошего проектирования. Она позволяет решить проблему, если изменение абсолютно необходимо, но не делает изменение стандартных полей рекомендуемым подходом для хранения нестандартных данных. Кроме того, если расширение было написано для более старых версий платформы или не использует эти новые возможности, проблема несоответствия метаданных все равно остается актуальной.
Если причина увеличения длины поля ИНН связана с необходимостью учета налоговых идентификаторов иностранных контрагентов, то в большинстве типовых конфигураций 1С (таких как 1С:Бухгалтерия 8 (редакция 3.0), 1С:Управление торговлей, 1С:Комплексная автоматизация, 1С:ERP Управление предприятием, и даже 1С:Управление нашей фирмой (УНФ)) уже предусмотрены специальные поля для этой цели. Использование этих полей является наиболее правильным и наименее болезненным способом решения данной задачи.
Рассмотрим, как найти и использовать эти поля в карточке контрагента:
Справочники или НСИ и администрирование, найдем пункт Контрагенты и откроем нужную карточку контрагента.Преимущества использования стандартных полей для иностранных контрагентов:
Таким образом, если ваша задача сводится к хранению идентификаторов иностранных контрагентов, всегда проверяйте наличие и используйте специализированные поля, предусмотренные в типовой конфигурации. Это избавит вас от множества проблем, связанных с изменением стандартных реквизитов.
Второй, не менее гибкий и правильный подход, если стандартные поля не подходят или если нестандартные идентификаторы нужны для объектов, отличных от контрагентов, — это создание дополнительных реквизитов. Механизм дополнительных реквизитов позволяет добавлять новые поля к существующим объектам конфигурации (справочникам, документам и т.д.) без изменения самой конфигурации.
Это идеальное решение, когда:
Рассмотрим пошагово процесс создания и использования дополнительного реквизита:
Администрирование.Администрирование найдите пункт Общие настройки и перейдите в него.Общих настройках вы увидите подраздел Дополнительные реквизиты и сведения. Установите флажок Использовать дополнительные реквизиты и сведения, если он еще не установлен. Затем перейдите по ссылке Дополнительные реквизиты.В открывшемся списке дополнительных реквизитов нажмите кнопку Создать.
Вам будет предложено выбрать, для какого объекта вы создаете реквизит. Например, если это идентификатор контрагента, выберите Справочник "Контрагенты". Если это номер для документа, выберите соответствующий документ.
Далее откроется форма создания реквизита, где необходимо заполнить следующие поля:
Строка.18. Также можно указать Допустимая длина и Минимальная длина, если это требуется.Сохраните новый реквизит. Он автоматически появится в карточках выбранного объекта (например, контрагента) на вкладке Дополнительные реквизиты.
Если у вас уже были данные, которые вы изначально вводили в измененное поле ИНН, и теперь хотите перенести их в новый дополнительный реквизит, вы можете воспользоваться стандартной обработкой Групповое изменение реквизитов.
Для этого:
Администрирование -> Обслуживание -> Корректировка данных -> Групповое изменение реквизитов.Справочники -> Контрагенты).Изменяемые реквизиты добавьте ваш новый дополнительный реквизит и укажите, какое значение в него нужно установить (например, можно использовать формулу для переноса данных из старого поля, если это возможно, или заполнить вручную).Изменить реквизиты.Этот механизм позволяет массово обновить значения нового реквизита, минимизируя ручной труд.
Преимущества использования дополнительных реквизитов:
В заключение, изменение длины стандартного поля ИНН с 12 до 18 символов, как это было сделано в исходной ситуации, является примером рискованного шага, нарушающего типовую логику конфигурации и принципы грамотной архитектуры информационных систем на платформе 1С:Предприятие. Подобные действия приводят к серьезным последствиям, таким как «слет» расширений, проблемы с обновлениями, некорректная работа встроенных проверок и сложность в интеграции с внешними системами.
Мы настоятельно рекомендуем использовать более правильные и гибкие решения для учета нестандартных идентификаторов:
НалоговыйНомер и РегистрационныйНомер. Эти поля специально разработаны для подобных целей и гарантируют стабильность работы системы.Принимая архитектурно верные решения сегодня, вы обеспечите стабильность, надежность и простоту поддержки вашей системы 1С в долгосрочной перспективе, а также избежите головной боли, связанной с постоянной адаптацией расширений и обновлением конфигурации. Всегда помните, что принцип «открыт для расширения, закрыт для модификации» является ключевым для успешной работы с платформой 1С:Предприятие.