Разработка и Конфигурация · 13 мин
Что такое конфигурируемость системы 1С:Предприятие
Конфигурируемость в 1С:Предприятие: что это такое, чем конфигурирование отличается от программирования, инструменты настройки, ограничения и типичные ошибки.
Конфигурируемость — ключевое архитектурное свойство платформы 1С:Предприятие, которое позволяет адаптировать прикладное решение под учётные процессы конкретной организации без переписывания ядра системы. Платформа поставляется как «конструктор»: разработчик или внедренец описывает структуру данных, формы, отчёты и алгоритмы в виде конфигурации, а платформа сама превращает это описание в работающее приложение.
Благодаря такому подходу типовые решения — «Бухгалтерия предприятия», «Управление торговлей», «Зарплата и управление персоналом» — можно подстраивать под специфику бизнеса: добавлять реквизиты, менять формы документов, строить собственные отчёты и даже создавать новые объекты учёта. При этом важно понимать границы: где заканчивается простая настройка и начинается доработка, требующая снятия конфигурации с поддержки.
В материале разобрано, что именно означает конфигурируемость технически, какими инструментами она обеспечивается, как выбрать безопасный способ доработки и какие ошибки чаще всего приводят к проблемам при обновлении.
Что означает конфигурируемость технически
Платформа 1С:Предприятие состоит из двух уровней: технологическая платформа (ядро, которое одинаково у всех) и конфигурация — описание прикладного решения. Конфигурация хранит структуру метаданных: справочники, документы, регистры, перечисления, отчёты, роли, а также программный код на встроенном языке. Платформа по этому описанию автоматически создаёт таблицы базы данных, генерирует интерфейс, обеспечивает проведение документов и построение отчётов.
Конфигурируемость и есть возможность менять это описание. Разработчик не программирует «с нуля» окна, таблицы и запросы к СУБД — он декларативно задаёт, какие объекты существуют и как связаны, а рутинную работу выполняет платформа. Это резко сокращает сроки разработки: добавление нового реквизита в документ занимает минуты, включая обновление структуры базы данных.
Важно отличать конфигурируемость от параметрической настройки. Настройка (функциональные опции, константы, настройки учётной политики) выполняется пользователем в режиме «Предприятие» и не меняет конфигурацию. Конфигурирование — работа в конфигураторе или через расширения, она меняет само прикладное решение.
Уровни адаптации: от настройки до доработки
На практике существует три уровня изменения поведения системы, и выбор правильного уровня определяет стоимость дальнейшего сопровождения.
Первый уровень — пользовательская настройка в режиме «Предприятие»: включение функциональных опций, заполнение учётной политики, настройка нумерации, прав доступа, дополнительных реквизитов и сведений. Это безопасно, не требует конфигуратора и не влияет на обновления.
Второй уровень — расширения конфигурации. Это механизм, позволяющий добавлять объекты, реквизиты, формы и обработчики поверх типовой конфигурации, не изменяя её саму. Расширение хранится отдельно, конфигурация остаётся на полной поддержке и обновляется штатно.
Третий уровень — прямое изменение конфигурации в конфигураторе. Это самый гибкий, но и самый «дорогой» в сопровождении способ: при снятии объектов с поддержки каждое обновление потребует ручного сравнения и объединения изменений.
Сравнение способов адаптации
Подходит для типовых сценариев: учётная политика, функциональные опции, дополнительные реквизиты. Полностью безопасна, обновления не затрагиваются. Ограничение — только предусмотренные разработчиком возможности.
Подходит для добавления реквизитов, печатных форм, отчётов, доработки форм и подмены типовых обработчиков. Конфигурация остаётся на поддержке. Ограничение — не все объекты и сценарии можно изменить через расширение.
Подходит для глубокой переработки логики, новых подсистем и объектов, недоступных в расширениях. Ограничение — усложняется обновление, требуется квалифицированный разработчик и тестирование.
Инструменты конфигурирования
Основной инструмент — конфигуратор, режим среды разработки 1С:Предприятие. В нём доступно дерево метаданных, редакторы форм, конструкторы запросов и схем компоновки данных, модули на встроенном языке, механизм сравнения и объединения конфигураций, а также отладчик.
Система компоновки данных (СКД) заслуживает отдельного упоминания: большинство отчётов в типовых решениях построено на ней, и пользователь с правами настройки может менять состав полей, группировки, отборы и оформление отчёта без вмешательства в код. Это тоже проявление конфигурируемости — на уровне аналитики.
Для командной разработки используются хранилище конфигурации и интеграция с системами контроля версий через формат EDT (1C:Enterprise Development Tools) — отдельная среда разработки на базе Eclipse, где конфигурация хранится в виде текстовых файлов, удобных для Git.
- Конфигуратор — основной инструмент изменения метаданных и кода.
- Расширения конфигурации — безопасная доработка без снятия с поддержки.
- СКД — гибкая настройка отчётов без программирования.
- Дополнительные отчёты и обработки (БСП) — подключаемые внешние модули в режиме «Предприятие».
- Хранилище конфигурации и EDT — командная разработка и контроль версий.
Как выбрать способ доработки
Правильное решение начинается с вопроса: «Можно ли закрыть потребность настройкой?» Часто за доработкой обращаются там, где достаточно включить функциональную опцию или завести дополнительный реквизит штатным механизмом. Проверьте документацию к типовой конфигурации и список функциональных опций — это экономит недели сопровождения в будущем.
Если настройки недостаточно, оцените, покрывает ли задачу механизм расширений. Через расширение можно добавить реквизит в документ, создать печатную форму, изменить форму, подменить обработчик события, добавить отчёт или роль. Ограничения: расширения не позволяют, например, менять структуру планов обмена или глубоко перестраивать типовые модули проведения — для таких задач потребуется изменение конфигурации.
Как выбрать способ доработки
Порядок безопасной доработки конфигурации
Любое изменение конфигурации начинается с резервной копии. Для файловой базы — копия каталога или выгрузка в dt, для клиент-серверной — штатный backup средствами СУБД плюс выгрузка cf конфигурации. Без проверенной копии доработку начинать нельзя: откатить неудачное изменение структуры данных бывает невозможно.
После внесения изменений конфигуратор предложит обновить конфигурацию базы данных. На этом этапе платформа выполняет реструктуризацию таблиц. На больших базах реструктуризация может занять значительное время и требует монопольного доступа — планируйте её на нерабочие часы и проверяйте свободное место на диске.
- 1Сделайте выгрузку базы (dt) и сохраните текущий файл конфигурации (cf)
- 2Внесите изменения в копии конфигурации или в расширении, а не в рабочей базе
- 3Протестируйте изменения на копии базы с реальными данными
- 4Проверьте конфигурацию штатной проверкой конфигуратора (синтаксис, логика, права)
- 5Выполните обновление конфигурации базы данных в нерабочее время при монопольном доступе
- 6Проверьте ключевые сценарии: проведение документов, отчёты, обмены, права пользователей
Ограничения и типичные ошибки
Конфигурируемость не безгранична. Ядро платформы изменить нельзя: нельзя добавить новый тип объекта метаданных, изменить принципы работы транзакций или движка СУБД. В расширениях действует список поддерживаемых объектов — он расширяется от версии к версии платформы, но не покрывает всех сценариев.
Самая дорогая ошибка — массовое снятие объектов с поддержки «на всякий случай». Каждый такой объект при обновлении придётся сопоставлять вручную, и через несколько обновлений сопровождение превращается в постоянный проект. Вторая частая ошибка — доработка напрямую в рабочей базе без копии и тестирования. Третья — игнорирование прав: новые объекты без настроенных ролей либо недоступны пользователям, либо, наоборот, открывают лишний доступ.
Отдельный риск — обмены данными. Если доработка меняет состав реквизитов, участвующих в синхронизации, правила обмена тоже нужно актуализировать, иначе получите расхождения между базами или ошибки выгрузки.
Как проверить результат доработки
Завершилось без ошибок, динамическое обновление не потребовалось либо прошло штатно
Ошибки реструктуризации, нехватка места, аварийное завершение
Документы проводятся, движения по регистрам корректны
Ошибки в модулях проведения, пустые или дублирующиеся движения
Новые объекты доступны нужным ролям, лишнего доступа нет
«Нарушение прав доступа» у пользователей или доступ у тех, кому не положен
Синхронизация проходит без ошибок, отчёты открываются и считают верно
Ошибки выгрузки, расхождения данных, падение отчётов
Сняты только реально изменённые объекты, остальное на поддержке
Сняты сотни объектов, включая нетронутые
Перед любой доработкой выпишите список затрагиваемых объектов и отметьте, какие из них можно закрыть расширением. На практике 60–80 % типовых пожеланий (реквизиты, печатные формы, отчёты, поправки форм) реализуются расширениями, и конфигурация остаётся полностью обновляемой.
Как конфигурируемость влияет на обновления
Цена доработки проявляется при обновлении. Конфигурация на полной поддержке обновляется автоматически: мастер сам применяет изменения поставщика. Конфигурация с расширениями обновляется так же штатно, но после обновления нужно проверить совместимость расширений — типовые модули, на которые они опираются, могли измениться.
Изменённая конфигурация обновляется через «Сравнение и объединение»: платформа показывает расхождения между старой типовой, новой типовой и вашей версией, и разработчик решает, какие изменения поставщика принять, а какие свои правки перенести. Чем меньше объектов изменено и чем аккуратнее ведётся учёт доработок (комментарии в коде, отдельные общие модули), тем быстрее проходит обновление.
Что важно запомнить
Конфигурируемость 1С — это возможность адаптировать решение описанием метаданных и кода без изменения ядра платформы. Выбирайте минимально достаточный уровень: настройка → расширение → изменение конфигурации. Любую доработку делайте на копии, с резервной копией рабочей базы и контролем статуса поддержки — это определяет стоимость обновлений на годы вперёд.
Частые вопросы
Чем конфигурирование отличается от программирования в 1С?
Программирование — это написание кода на встроенном языке в модулях объектов, форм и общих модулях. Конфигурирование шире: оно включает декларативное описание метаданных (справочников, документов, регистров, ролей), конструирование форм и отчётов и лишь при необходимости — код. Большая часть адаптации выполняется без единой строки программы.
Можно ли дорабатывать типовую конфигурацию без снятия с поддержки?
Да, через механизм расширений конфигурации. Расширение позволяет добавлять реквизиты, формы, отчёты, роли и подменять обработчики событий, не трогая типовую конфигурацию. Однако не все объекты и сценарии поддерживаются — глубокая переработка логики проведения или планов обмена может потребовать прямого изменения конфигурации.
Что произойдёт с доработками при обновлении конфигурации?
Настройки и расширения при обновлении сохраняются, но расширения нужно проверить на совместимость. Изменения, внесённые прямо в конфигурацию, сохраняются через процедуру сравнения и объединения: разработчик вручную переносит свои правки в новую типовую версию. Чем больше объектов снято с поддержки, тем дольше и дороже обновление.
Нужен ли конфигуратор, чтобы добавить новый реквизит в документ?
Не всегда. В типовых конфигурациях на базе БСП есть механизм дополнительных реквизитов и сведений, доступный администратору в режиме «Предприятие». Если же реквизит должен участвовать в проведении, отчётах СКД или печатных формах как полноценное поле — потребуется конфигуратор или расширение.
Кто может выполнять конфигурирование и какие права нужны?
Работа в конфигураторе требует права администратора информационной базы и навыков разработки на платформе. Изменение структуры метаданных требует монопольного доступа к базе. Настройка в режиме «Предприятие» (функциональные опции, дополнительные реквизиты, варианты отчётов) доступна пользователю с правами администратора системы без запуска конфигуратора.
Чем опасно динамическое обновление конфигурации?
Динамическое обновление применяет изменения без монопольного завершения сеансов, но подходит только для простых правок без реструктуризации данных. При изменении структуры таблиц возможны ошибки в открытых сеансах пользователей и рассинхронизация кэша метаданных. Для изменений, затрагивающих структуру данных, всегда используйте обычное обновление с завершением сеансов.