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

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

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

Что платформа разрешает делать технически

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

Разработчик вправе писать код на встроенном языке в любых модулях: модуле объекта, менеджера, формы, команды, общих модулях. Доступны запросы на языке запросов 1С, построение произвольных отчётов на СКД, создание макетов печатных форм, работа с XDTO, HTTP-сервисами, веб-сервисами, планами обмена и механизмами интеграции.

Дополнительно разрешено подключать внешние компоненты по технологии Native API, использовать COM-соединения, OLE, работу с файловой системой и внешними источниками данных. Это штатные, документированные возможности, а не «обходы» — их применение не нарушает ни лицензию, ни поддержку.

Доработка типовых конфигураций: что можно и как безопасно

Типовые конфигурации («Бухгалтерия предприятия», «Управление торговлей», «Зарплата и управление персоналом» и другие) поставляются с правом их изменения под нужды заказчика. Это прямо предусмотрено лицензионной политикой: покупатель вправе адаптировать конфигурацию для собственного использования. Однако способ доработки определяет, сохранится ли возможность простого обновления.

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

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

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

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

Изменение с сохранением поддержки

Добавление собственных объектов без правки типовых. Обновление выполняется автоматически, но свобода ограничена новыми объектами.

Снятие с поддержки

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

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

Расширения конфигурации: границы разрешённого

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

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

Лицензионные ограничения и права на код

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

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

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

Режимы поставки и защита собственных разработок

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

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

1. 1
   Завершите и протестируйте конфигурацию, уберите отладочный код
2. 2
   В конфигураторе откройте настройку поддержки и создайте файл поставки
3. 3
   Отметьте модули, которые поставляются без исходных текстов
4. 4
   Определите права на изменение и обновление для заказчика
5. 5
   Сформируйте дистрибутив и проверьте установку на чистой базе
6. 6
   Убедитесь, что обновление из поставки проходит без ошибок

Типичные ошибки разработчиков

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

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

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

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

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

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

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

Состояние поддержки

Норма

Типовые объекты на замке, доработки в расширении или добавленных объектах

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

Массовые изменения типовых объектов со снятием с поддержки

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

Норма

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

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

Каждое обновление требует ручного анализа сотен объектов

Состав поставки

Норма

В поставке только собственные объекты и разрешённые компоненты

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

Включены чужие закрытые модули или типовые объекты без прав

Работа расширений

Норма

Расширения подключаются без отключения безопасного режима там, где это возможно

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

Расширение требует прав администратора без объективной необходимости

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

Можно ли дорабатывать типовую конфигурацию без потери гарантии и поддержки?

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

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

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

Что делать, если нужного изменения нельзя добиться расширением?

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

Можно ли смотреть и копировать код типовых конфигураций?

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

Разрешено ли использовать недокументированные возможности платформы?

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

Кто отвечает за нарушение лицензии — разработчик или заказчик?

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