Что разрешено разработчикам прикладных решений в системе 1С:Предприятие 8

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

Ключевой принцип прост: платформа неизменна, прикладное решение — изменяемо. Разработчик не может править ядро платформы, встроенный язык или механизмы СУБД, но может создавать и перестраивать любые объекты метаданных: справочники, документы, регистры, отчёты, роли. Внутри этих объектов доступны алгоритмы на встроенном языке, запросы, формы, макеты и настройки прав.

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

Что можно менять в конфигурации без ограничений

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

Разрешено писать произвольную логику на встроенном языке в модулях объектов, форм, общих модулях и модулях менеджеров. Язык позволяет работать с запросами, транзакциями, файлами, COM-объектами, веб-сервисами и HTTP-запросами, если режим безопасности это допускает. Можно подключать внешние компоненты по технологии Native API или COM.

Также разрешено проектировать интерфейс: создавать формы, команды, подсистемы, настраивать панели навигации, разрабатывать макеты печатных форм и схемы компоновки данных для отчётов. Ограничений по количеству объектов платформа не накладывает — сдерживающими факторами выступают производительность и сопровождаемость решения.

Работа с типовыми конфигурациями: поддержка и её границы

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

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

Безопасная практика — минимизировать прямые изменения типового кода. Там, где задачу можно решить расширением, подключаемой обработкой или настройкой, прямую правку лучше не делать. Это не запрет платформы, а инженерное правило, которое экономит часы при каждом обновлении.

Расширения конфигурации: что разрешено без изменения типового кода

Расширения — штатный механизм доработки, который разрешено применять без снятия конфигурации с поддержки. В расширении можно добавлять собственные объекты метаданных, заимствовать типовые объекты и изменять их свойства, формы и ряд обработчиков. Можно перехватывать вызовы процедур и функций через аннотации «Вместо», «Перед», «После», дополнять командный интерфейс и добавлять роли.

Есть и ограничения. Расширение не может изменять структуру существующих таблиц базы данных произвольным образом: добавлять измерения к типовым регистрам или реквизиты к типовым объектам в общем случае нельзя, хотя собственные объекты расширения создают свои таблицы. Не все обработчики событий доступны для перехвата, а изменение модуля с полной заменой делает расширение уязвимым к обновлениям типовой конфигурации.

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

Способы доработки типовой конфигурации

Расширение конфигурации

Подходит для добавления форм, печати, обработчиков и новых объектов; сохраняет автообновление, но не меняет состав таблиц типовых объектов

Прямое изменение типового кода

Позволяет любые правки, включая структуру данных, но усложняет каждое обновление и требует сопоставления изменений

Внешние обработки и отчёты

Подходят для разовых операций, печатных форм и сервисных функций; не трогают конфигурацию, но ограничены интерактивными сценариями

Подсистема БСП и настройки

Штатные функциональные опции и переопределяемые модули — самый безопасный путь, если задача укладывается в предусмотренные точки расширения

Права, роли и доступ к данным

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

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

Механизм функциональных опций разрешает включать и отключать части функциональности настройкой, а не кодом. Разработчик вправе создавать свои функциональные опции и связывать с ними объекты, реквизиты и команды — это предпочтительный способ управлять видимостью доработок.

Интеграции и внешние механизмы

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

Разрешено использовать внешние компоненты, библиотеки и COM-объекты, обращаться к СУБД напрямую через внешние источники данных. При этом прямое изменение данных в таблицах СУБД в обход платформы формально возможно технически, но нарушает логику работы системы: обходятся проверки, регистрация изменений в планах обмена, блокировки и кэши. Такой способ считается недопустимой практикой, а не разрешённой возможностью.

Для мобильных решений разрешено собирать отдельные мобильные конфигурации и клиенты с собственным интерфейсом и автономной базой, синхронизируемой с основной системой через веб-сервисы.

Лицензионные и технологические ограничения

Ряд ограничений задан не технически, а лицензионно. Разработчику запрещено обходить систему лицензирования платформы, модифицировать файлы платформы, извлекать и изменять защищённые модули поставщиков. Парольная защита модулей, поставка конфигурации без исходных текстов и скрытие паролей — штатные механизмы, и их взлом выходит за рамки разрешённой деятельности.

Технологически платформа запрещает изменять состав предопределённых таблиц, вмешиваться в работу механизмов транзакций и блокировок на уровне ядра, а также менять поведение встроенного языка. Всё, что выходит за пределы объектной модели, реализуется только через документированные точки: внешние компоненты, HTTP-сервисы, планы обмена.

Для разработчиков, распространяющих собственные прикладные решения, существуют правила совместимости и сертификации «Совместимо! Система программ 1С:Предприятие». Участие добровольное, но требования к стандартам разработки, демонстрационным базам и документации фактически задают рамки качественного продукта.

1. 1
   Сформулируйте задачу и проверьте, не решается ли она настройкой, функциональными опциями или переопределяемыми модулями БСП
2. 2
   Попробуйте реализовать доработку расширением конфигурации, не меняя типовой код
3. 3
   Если расширения недостаточно, включите возможность изменения только для нужных объектов и зафиксируйте правки комментариями в коде
4. 4
   Протестируйте доработку на копии базы под пользователем с ограниченными правами
5. 5
   Проверьте обновление на тестовой копии: убедитесь, что сопоставление изменений проходит без потери доработок

Как проверить, что доработка выполнена в рамках разрешённого

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

Дополнительный контроль — тестирование под пользователем с минимально необходимыми правами. Если сценарий работает только под полными правами, в доработке есть скрытая зависимость от привилегированного доступа, которую нужно оформить явно: отдельной ролью или серверным вызовом с проверками.

Контрольные точки

Как проверить результат доработки

Обновление типовой конфигурации

Норма

Обновление проходит автоматически или с минимальным сопоставлением

Тревожный признак

Каждый релиз требует ручного переноса десятков изменённых модулей

Работа под ограниченными правами

Норма

Все сценарии выполняются под целевой ролью пользователя

Тревожный признак

Функции доступны только с полными правами

Подключение расширения

Норма

Расширение подключается и отключается без ошибок и потери данных

Тревожный признак

После отключения остаются битые ссылки или ошибки при открытии форм

Проверка конфигурации

Норма

Штатная проверка не показывает критических ошибок

Тревожный признак

Неразрешённые ссылки, ошибки компиляции модулей, потерянные объекты

Частые вопросы

Можно ли дорабатывать типовую конфигурацию, не теряя автоматическое обновление?

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

Разрешено ли изменять данные напрямую в таблицах SQL-сервера?

Технически доступ к СУБД возможен, но платформа об этом «не знает»: обходятся проверки, блокировки, регистрация изменений в планах обмена и механизмы кэширования. Такой способ считается недопустимой практикой и приводит к рассинхронизации данных и ошибкам обменов.

Что можно изменить в типовом объекте через расширение?

Можно изменять формы, командный интерфейс, ряд свойств и перехватывать обработчики модулей через аннотации «Вместо», «Перед», «После». Нельзя произвольно менять состав таблиц типовых объектов — например, добавлять реквизиты к типовому документу напрямую. Собственные объекты расширения таких ограничений не имеют.

Разрешено ли создавать свои роли и менять типовые?

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

Можно ли обойти защищённый модуль поставщика без исходного кода?

Нет. Парольная защита и поставка без исходных текстов — штатные механизмы защиты, и их обход выходит за рамки разрешённой деятельности и нарушает условия лицензирования. Допустимый путь — расширять функциональность вокруг такого модуля через собственные объекты и расширения.

Чем внешняя обработка отличается от расширения по возможностям?

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