Как разместить расширение, обработку или конфигурацию в каталоге
Содержание
Готовое решение на 1С можно не только продавать клиентам напрямую, но и разместить в каталоге приложений — тогда его увидят пользователи облачного сервиса и партнёры по всей сети. Чтобы опубликовать приложение 1С в каталоге, решение проводят через три обязательных этапа: приводят конфигурацию, расширение или внешнюю обработку к стандартам разработки, собирают комплект документации и материалов для витрины, а затем сдают продукт на тестирование и экспертизу фирмы «1С».
Публикация — это не одно нажатие кнопки, а процедура с модерацией. От момента подачи заявки до появления карточки в каталоге обычно проходят недели: решение проверяют на соответствие требованиям, а замечания нужно устранять и присылать сборку заново. Ниже — порядок действий и что подготовить на каждом шаге, чтобы не вернуться на старт после первой же проверки.
Что именно размещают в каталоге и где
Под «публикацией приложения» понимают несколько разных по объёму задач. Прежде чем собирать документы, определитесь, что вы выкладываете:
- 🧩 Расширение конфигурации
— доработка к типовой программе (например, к «1С:Бухгалтерии» или «1С:Управлению торговлей»). Расширения как механизм появились в платформе
8.3.6, подключаются к основной конфигурации без снятия её с поддержки. - ⚙️ Внешняя обработка или отчёт — отдельный файл
.epfили.erf, который пользователь подключает в раздел дополнительных отчётов и обработок. - 📦 Самостоятельная конфигурация — полноценное прикладное решение, которое работает отдельно или в составе облачного сервиса.
Выбор типа решения определяет и объём проверки, и порядок установки у пользователя:
| Тип решения | Когда выбирать | Что учесть при публикации |
|---|---|---|
| Расширение | Доработка к типовой конфигурации | Проверяют совместимость с релизами типовых решений; переживает обновления |
| Внешняя обработка/отчёт | Отдельная функция без изменения конфигурации | Оформляется по формату дополнительных обработок; проще в приёмке |
| Самостоятельная конфигурация | Законченное прикладное решение | Полная проверка стандартов, своя модель обновления и прав |
Каталогов тоже несколько. Облачный каталог приложений (модель, когда программа работает «через интернет ») и каталог готовых решений для партнёрской сети — это разные витрины со своими правилами приёма. Намерение у них общее: пользователь находит ваш продукт, а не вы ищете пользователя. Поэтому дальше описан общий порядок, применимый к обоим случаям; конкретные формы и номера пунктов берите из действующей документации площадки, на которую подаётесь.
Если вы делаете доработку к типовой конфигурации, почти всегда выгоднее оформить её расширением, а не отдельной конфигурацией. Расширение переживает обновления типового решения и не требует снимать базу клиента с поддержки.
С чего начать: статус разработчика и договор
Физическое лицо «с улицы» выложить решение в каталог не может. Размещение идёт через договорные отношения с фирмой «1С», поэтому первый шаг — организационный, а не технический.
Что потребуется:
- Статус партнёра или разработчика. Публикация доступна организациям, заключившим соответствующий договор с фирмой «1С». Если такого договора нет, его оформляют до подачи решения.
- Доступ в кабинет разработчика. После заключения договора вы получаете учётную запись на портале (кабинете) разработчика той площадки, куда публикуете. Через него загружают сборки, ведут переписку с модераторами и отслеживают статус заявки.
- Согласование модели распространения. Платное решение, условно-бесплатное, демо-доступ — это нужно определить заранее, потому что от модели зависит состав договора и настройка тарифа в карточке.
До подачи заявки проверьте, на какое юридическое лицо оформлен договор и на него ли заведён кабинет разработчика: если решение загружает сотрудник со своей личной учётки, модерация его не примет.
Не торопитесь загружать «сырую» сборку, чтобы «посмотреть, как пойдёт». Каждая отклонённая заявка — это цикл проверки и исправлений, который растягивает публикацию. Дешевле один раз собрать всё по списку.
Приведение решения к стандартам разработки
Главная причина, по которой приложения возвращают с модерации, — несоответствие стандартам кода. Фирма «1С» публикует систему стандартов и методик разработки конфигураций; решение в каталоге обязано им следовать. Это не формальность: по этим же правилам проверяют код автоматически.
На что смотрят чаще всего:
- 🔤 Поддержка нескольких языков и региональных настроек. Тексты в интерфейсе выносят в строки локализации, а не «зашивают» в код.
- 🔐 Ролевая модель и права доступа . Роли должны быть осмысленными, а не одной «ПолныеПрава» на всё.
- 🧱 Стиль и структура кода. Именование объектов, модульность, обработка исключений, отсутствие «мёртвого» кода и отладочных вставок.
- 🔄 Корректное обновление. Решение должно обновляться у клиента без потери данных: продуманные процедуры при переходе между версиями.
- 🚫 Отсутствие небезопасных конструкций. Запуск внешнего кода, прямые запросы в обход объектной модели, работа с файловой системой сервера без необходимости — всё это повод для отказа.
Проверьте код инструментами автоматической проверки (их поставляет сама «1С» для разработчиков) ещё до загрузки. Они находят большую часть замечаний, которые иначе всплывут на модерации.
Для облачного каталога требования строже, чем для «коробочного» распространения: в сервисе ваше решение работает в общей инфраструктуре, поэтому ограничены операции с сервером, внешними соединениями и длительные фоновые задания. Эти ограничения читайте в требованиях конкретной площадки — они обновляются.
Особенность для внешних обработок и расширений
Внешняя обработка или отчёт для каталога оформляются по формату дополнительных обработок: с описанием команд, вариантов запуска и указанием, к каким конфигурациям они подходят. Расширение проверяют на совместимость с актуальными релизами тех типовых конфигураций, для которых оно заявлено. Загрузка расширения (.cfe) в базу и команда «Обновить конфигурацию
базы данных» — отдельные шаги; это стоит учитывать в инструкции для пользователя.
Полезный приём: заявляйте совместимость только с теми релизами типовых конфигураций, которые вы реально проверили. Соблазн написать «подходит для всех версий» оборачивается жалобами пользователей и замечаниями при следующем обновлении типового решения. Лучше честный узкий список, который вы расширяете по мере проверки новых релизов, чем широкий, но неподтверждённый.
Документация и материалы для карточки
Пользователь в каталоге видит не код, а карточку приложения. Если она пустая или написана «для себя», решение не скачают, даже если оно технически безупречно. Поэтому к сдаче готовят два комплекта материалов — для модерации и для витрины.
Для модерации (техническая документация):
- описание назначения и состава решения;
- инструкция по установке и началу работы;
- список поддерживаемых конфигураций и минимальная версия платформы (указывайте номер однозначно — «не ниже
8.3.2x», а не «новая версия»); - порядок обновления и перечень изменений по версиям.
Для витрины (маркетинговые материалы):
- короткое и понятное название;
- иконка или логотип в требуемом формате;
- описание выгод простым языком: какую задачу решает, кому подходит;
- скриншоты рабочих окон;
- при наличии — демо-доступ или видеоролик.
Отдельно подготовьте тестовый пример — заполненную демо-базу или набор данных, на которых проверяющий увидит работу решения без долгой настройки. Это ускоряет экспертизу.
Как проходит тестирование и модерация
После загрузки сборки в кабинет разработчика приложение попадает на проверку. Она делится на автоматическую и экспертную.
Автоматическое тестирование. Код прогоняют инструментами проверки стандартов. Здесь отсеиваются формальные нарушения: небезопасные конструкции, ошибки структуры, проблемы с правами. Результат вы видите в кабинете в виде списка замечаний.
Экспертная проверка. Специалист смотрит на решение глазами пользователя: запускается ли оно, понятен ли интерфейс, соответствует ли заявленному назначению, корректно ли обновляется. На этом этапе всплывают логические и содержательные замечания, которые автомат не ловит.
Дальше — обычный цикл:
- Вы получаете список замечаний.
- Исправляете код или документацию.
- Загружаете новую сборку с увеличенным номером версии.
- Решение снова уходит на проверку.
Цикл повторяется, пока замечаний не останется. Поэтому первая сборка должна быть максимально чистой: каждая итерация — это дни или недели ожидания. Сроки зависят от загруженности проверяющих и сложности решения, заранее назвать точную дату публикации нельзя.
Отвечайте на замечания по существу и в кабинете, а не «где-то в почте». Структурированная переписка с привязкой к конкретным пунктам ускоряет повторную проверку — модератору не приходится заново искать контекст.
После успешной экспертизы карточка приложения публикуется в каталоге, и решение становится доступно пользователям.
Из-за чего чаще всего возвращают заявку
Отказ модерации почти всегда укладывается в несколько повторяющихся причин. Если закрыть их заранее, число циклов проверки резко падает.
- 🧩 Нарушения стандартов кода. Жёстко заданные тексты интерфейса вместо строк локализации, роль «ПолныеПрава» на все объекты, прямые запросы в обход объектной модели. Это ловит автоматическая проверка — прогоняйте её до загрузки.
- 📄 Пустая или формальная карточка. Описание «для разработчика», без скриншотов и понятной выгоды для пользователя. Решение могут вернуть не из-за кода, а из-за непригодной витрины.
- 🔢 Неоднозначные требования к версии. Формулировки вроде «работает на новой платформе» без номера релиза. Указывайте минимальную версию числом — «не ниже
8.3.2x». - 🔄 Нет механизма обновления. Если решение не умеет корректно переходить со старой версии на новую без потери данных пользователя, его не примут.
- ⚙️ Небезопасные операции в облачном каталоге. Запуск внешнего кода, работа с файловой системой сервера, длительные фоновые задания — в общей инфраструктуре сервиса они запрещены или ограничены.
- 🏢 Несовпадение юрлица. Сборка загружена с учётной записи, не привязанной к договору. Формальная, но частая причина возврата на старте.
Отдельно стоит проверить решение на чистой базе, а не только на своей рабочей, где уже есть все нужные справочники и настройки. Проверяющий запускает приложение «с нуля», и расхождения вскрываются сразу.
Что делать после публикации: обновления и поддержка
Публикация — это начало жизненного цикла решения, а не финал. Карточка в каталоге обязывает поддерживать продукт.
Что входит в сопровождение:
- 🔧 Выпуск обновлений. При выходе новых релизов платформы и типовых конфигураций ваше расширение или решение нужно проверять на совместимость и при необходимости дорабатывать. Каждое обновление снова проходит проверку перед публикацией.
- 📨 Поддержка пользователей. Вопросы по установке и работе решения — ваша зона ответственности. Контакты поддержки указывают в карточке.
- 📈 Работа с карточкой. Описание, скриншоты и список совместимых конфигураций держат в актуальном состоянии — устаревшая карточка снижает доверие и скачивания.
- 🗂 История версий. Понятный список изменений помогает и пользователям, и модераторам при следующей проверке.
Заброшенное решение, которое давно не обновлялось и не совместимо с актуальными релизами, со временем теряет позиции в каталоге и пользователей. Если планируете публиковать, закладывайте ресурс на сопровождение, а не только на разработку.
Если решение больше не развивается, его лучше корректно снять с публикации или перевести в архивный статус, предупредив пользователей, а не оставлять «висеть» неработающим. Порядок снятия с публикации и возврата описан в правилах площадки — он тоже проходит через кабинет разработчика.