Требования к программным продуктам, подаваемым на сертификацию с "1С:Предприятие 8.3"

1. Общие требования
2. Требования к конфигурациям, разработанным в среде "1С:Предприятие 8.3"
3. Требования к дополнениям конфигураций, разработанным в среде "1С:Предприятие 8.3" без использования механизма расширений
4. Требования к комплекту сервисных отчетов и обработок, разработанным в среде "1С:Предприятие 8.3"
5. Требования к внешним компонентам системы программ, разработанным в среде "1С:Предприятие 8.3"
6. Требования к системам удаленного банковского обслуживания
7. Требования к продуктам, использующим различные способы взаимодействия и обмена данными с системой "1С:Предприятие 8.3"
8. Требования к расширениям конфигураций, разработанным в среде 1С:Предприятие 8.3"

1. Общие требования

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

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

1.3. Продукт должен иметь документацию (Руководство пользователя). Руководство пользователя должно включать разделы, описанные ниже.

• Титульный лист.
• Информация о разработчике/правообладателе программного продукта.
• Информация о способах получения технической поддержки для пользователей (Информация о линии консультаций).
• Оглавление.
• Введение с описанием назначения продукта, основных возможностей, подходов к ведению учета, используемых методик учета, моделей и принятых допущений. Если в конфигурации используются элементы 1С:Библиотеки стандартных подсистем, то информация об этом должна быть приведена во ведении.
• Инструкция по установке. Описание начальной установки конфигурации. Описание должно быть таким, чтобы продукт мог установить конечный пользователь. Если в конфигурации используется система защиты, то описание ее установки должно быть включено в данный раздел.
• Руководство по ведению учета. Описание возможностей и порядок использования конфигурации.

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

• с помощью какой программы можно прочитать документацию;
• формат (размер печатных листов в оригинальном макете);
• количество страниц;
• наименование использованных шрифтов;
• список авторов.

1.4. В руководстве пользователя должно быть в явном виде описано взаимодействие продукта с "1С:Предприятием".

1.5. Программный продукт должен использовать только штатные и документированные возможности работы с "1С:Предприятием 8".

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

1.7. Использование логотипа "1С" в оформлении программного продукта и названия "1С" в его наименовании допускается только по специальному согласованию с фирмой "1С", например, для совместных с фирмой "1С" разработок. Использование логотипа "1C:Франчайзинг" допускается для продуктов партнеров-франчайзи. В случае успешной сертификации фирма-разработчик имеет право использовать для оформления логотип "1C:Совместимо!".

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

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

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

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

1.12. В заявке на получение логотипа "1С:Совместимо" разработчик должен предоставить письменную гарантию с подписью руководителя и печатью фирмы-разработчика в том, что продукт является собственной разработкой и при разработке продукта не были нарушены чьи-либо авторские или иные права.

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

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

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

2. Требования к конфигурациям, разработанным в среде "1С:Предприятие 8.3"

2.1. Общие сведения о конфигурации.

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

2.1.2. Номер версии указывается в свойствах конфигурации. Номер версии формируется по правилам, описанным в статье "Нумерация редакций и версий" Системы стандартов и методик разработки конфигураций, опубликованной на ИТС-ресурсе https://its.1c.ru/db/v8std.

2.1.3. Термин "типовая" может быть использован только для конфигураций, разработанных фирмой "1С", либо локализованных по заказу фирмы "1С".

2.1.4. Конфигурация должна быть одинаково рассчитана на работу со всеми СУБД, операционными системами, веб-браузерами и различными режимами работы, которые поддерживает платформа "1С:Предприятие 8". Если часть функционала не поддерживает какой-либо из этих режимов работы, то эти ограничения должны быть описаны в документации. Фирма "1С" может указывать в рекламной информации по данному продукту, что использование части функционала возможно с определенными ограничениями.

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

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

2.1.7. В конфигурации должна быть предусмотрена возможность исключения случайных выходов из программы "1С:Предприятие", например, если пользователь по ошибке нажал кнопку закрытия главного окна программы. При выходе из программы необходимо задавать пользователю вопрос: "Завершить работу с программой?". Если пользователь подтверждает выход из программы - программа закрывается. Если отказывается от выхода, то он продолжает работать с программой, при этом необходимо предусмотреть возможность отключать вывод вопроса в персональных настройках пользователя.

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

2.1.9. Если продукт является собственной разработкой, то он должен содержать соответствующую информацию в "Свойствах конфигурации".

В разделе "Основные":

• "Имя" образуется по правилам образования имен из синонима; слово "редакция", номер редакции (и подредакции) – не указываются.
• "Синоним" - указывается официальное название конфигурации, которое будет идентифицировать конфигурацию. В конце официального названия через запятую указывается слово "редакция" и номер редакции.

В разделе "Представление":

• "Краткая информация" указывается краткая информация о своем продукте.
• "Подробная информация" указывается подробная информация о своем продукте.
• "Авторские права" указывается информация о разработчике.
• "Адрес информации о поставщике" указывается ссылка на ресурс с информацией о своей компании.
• "Адрес информации о конфигурации" указывается ссылка на ресурс с информацией о своем продукте.

В разделе "Разработка":

• "Поставщик" - указывается наименование компании разработчика.
• "Версия" - указывается полный номер версии конфигурации.
• "Адрес каталога обновлений" - указывается ссылка на ресурс с обновлениями, если такой есть.

2.2. Начальные действия при работе конфигурации.

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

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

2.3. Оформление объектов конфигурации.

2.3.1. Имена объектов метаданных не должны превышать 80 символов.

2.3.2. Синоним объекта метаданных обязательно заполняется. Синоним должен быть определен так, чтобы осмысленно и лаконично описывать объект.

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

2.3.2.2. В случае если у объекта метаданных имеются стандартные реквизиты (стандартные табличные части), для них следует указывать синонимы, исходя из прикладного смысла каждого реквизита.

2.3.2.3. Для стандартных реквизитов Родитель и Владелец, следует всегда указывать синонимы, отличные от синонимов по умолчанию.

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

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

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

Исключение составляют:

• общие реквизиты (т.к. для общих реквизитов, являющихся разделителями, порядок следования в дереве метаданных должен подбираться, исходя из требуемого порядка установки параметров сеанса).
• объекты с префиксом "Удалить", которые допустимо размещать в конце соответствующей ветки метаданных;

2.3.6. Конфигурация в целом и ее основные объекты, имеющие свойство "Справочная информация", должны иметь пользовательское описание. Для объектов справочная информация должна содержать сведения:

• о назначении объекта;
• о способах его вызова - из меню программы, из других объектов;
• о порядке и особенностях ввода информации;
• описание реквизитов объекта, используемых пользователем;

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

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

2.3.8. В конфигурациях следует использовать "Управляемый" режим блокировок (свойство "Режим управления блокировкой данных" конфигурации устанавливается в значение "Управляемый") и учитывать особенности работы в этом режиме. В случае наличия серьезных обоснований для другого вида блокировок именно для этой конфигурации, то эту особенность и ее обоснование следует отразить в документации к конфигурации.

2.4. Интерфейсы и формы.

2.4.1. В случае использования фрагментов конфигураций, разработанных фирмой "1C", оригинальная часть конфигурации не должна отличаться по стилю оформления и написания от включенных частей типовых конфигураций. Не допускается использовать собственные стили, а также переопределять стили элементов для объектов конфигураций, разработанных фирмой "1С".

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

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

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

2.4.4.1. Последним разделом в интерфейсе всегда должен быть раздел для администрирования, настройки и выполнения сервисных действий.

2.4.4.2. Рабочий стол является обязательным разделом и не может быть отключен.

2.4.4.3. Следующие виды форм должны быть всегда доступны пользователю в режиме "1С:Предприятия" из меню "Все функции" вне зависимости от того, размещены ли соответствующие объекты в командный интерфейс приложения или нет:

• основная форма списка;
• основная форма отчета;
• основная форма обработки.

2.5. Общие принципы оформления модулей.

2.5.1. Тексты модулей оформляются по принципу "один оператор в одной строке". Наличие нескольких операторов допускается только для "однотипных" операторов присваивания, например: А = 0; Б = 0; С = 0;

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

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

2.5.4. Конфигурация не должна содержать ошибок, обнаруживаемых при проверке конфигурации (конфигуратор – меню Конфигурация – Проверка конфигурации…). Кроме отдельных, обоснованных случаев, описанных в Системе стандартов и методик разработки конфигураций https://its.1c.ru/db/v8std:

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

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

2.5.6. При разработке конфигураций разделы и подразделы оформляются в виде областей. Правила и примеры оформления разделов и подразделов приведены в статье "Структура модуля" Системы стандартов и методик разработки конфигураций, опубликованной на ИТС-ресурсе https://its.1c.ru/db/v8std.

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

• секция "Описание" - содержит краткое описание назначения и/или принципов работы процедуры(функции), может быть единственной секцией для функций без параметров;
• секция "Параметры" - описывает параметры процедуры (функции), если их нет, секция пропускается, предваряется строкой "Параметры:";
• секция "Возвращаемое значение" - описывает тип и содержание возвращаемого значения функции, предваряется строкой "Возвращаемое значение:", для процедур эта секция отсутствует;
• Секция "Пример" содержит пример использования процедуры, или функции. Предваряется строкой "Пример:". Далее с новой строки пример использования.

2.5.8. Тексты модулей в сложных алгоритмах должны содержать комментарии.

• Если комментарий относится к модулю в целом, то он располагается в начале модуля (заголовок модуля).
• Если комментарий относится к оператору или группе операторов, то он должен располагаться перед комментируемым оператором (группой операторов).
• Длинные комментарии должны начинаться с большой буквы и заканчиваться точкой. Следует проверять текст комментария на отсутствие грамматических и синтаксических ошибок.
• Текст длинного комментария должен быть выровнен по левой границе комментируемого оператора (первого оператора группы операторов).
• Между символами комментария "//" и текстом комментария должен быть пробел.
• Строки не должны быть длиннее 120 символов за исключением тех случаев, когда перенос невозможен.

2.5.9. Комментарии должны быть достаточно понятными, чтобы пояснять работу модуля или комментируемого оператора. Тексты комментариев должны составляться в деловом стиле, быть эмоционально сдержанными и не содержать слов, не относящихся к функциональности программы.

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

2.5.11. Программные модули не должны иметь неиспользуемых или пустых процедур и функций и закомментированных фрагментов кода.

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

2.5.13. Не следует размещать экспортные процедуры и функции в модулях форм. Исключения из этого правила возможны в отдельных, обоснованных случаях. Некоторые из них перечислены в системе стандартов и разработки конфигураций, опубликованных на ИТС в разделе "Правила создания модулей форм".

2.5.14. Свойство "Изменяет данные" должно быть установлено в "Истина" для всех команд, которые изменяют или могут изменять данные объекта.

2.5.15. При разработке конфигураций, предназначенных для работы в веб-клиенте, запрещено использовать модальные формы и диалоги. В противном случае, конфигурация окажется неработоспособной в ряде веб-браузеров, так как модальные окна не входят в стандарт веб-разработки. Для разработки качественных веб-приложений требуются асинхронные средства обеспечения взаимодействия с пользователем, которые предоставляет платформа 1С:Предприятие. Для этого свойство конфигурации "Режим использования модальности" должен быть установлено в "Не использовать", а вместо модальных методов следует вызывать их немодальные аналоги с блокированием окна владельца или всего интерфейса.

2.5.16. Не следует размещать экспортные процедуры и функции в модулях команд и общих команд. К этим модулям нет возможности обращаться из внешнего по отношению к ним кода.

2.5.17. В процедуре ПриЗавершенииРаботыСистемы модуля управляемого приложения недопустимо использовать асинхронные вызовы.

2.5.18. Если в процедуре ПередЗавершениемРаботыСистемы модуля управляемого приложения используются асинхронные вызовы, то в ней необходимо установить значение параметра Отказ = Истина и из процедуры оповещения о завершении асинхронного вызова продолжить завершение работы системы.

2.5.19. Модули конфигурации не должны быть защищены паролями. О создании поставки без исходных модулей см. пункт 2.24.7.

2.6. Стандартные роли.

2.6.1. Если в конфигурации есть разграничение прав доступа пользователей к данным, то в конфигурации должны быть определены три обязательные роли, которые предназначены для "прикладного" и системного администрирования информационной базы, а также для интерактивного открытия внешних отчетов и обработок: "ПолныеПрава" (синоним "Полные права"), "АдминистраторСистемы" (синоним "Администратор системы") и "ИнтерактивноеОткрытиеВнешнихОтчетовИОбработок" (синоним "Интерактивное открытие внешних отчетов и обработок").

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

• позволять самостоятельное использование (может быть назначена пользователям);
• предоставлять неограниченный доступ ко всем данным области (к разделенным данным), кроме права интерактивного удаления;
• позволять выполнять все административные действия с областью данных (администрирование пользователей, настройка программы, удаление помеченных объектов и т.п.);
• включать в себя перечисленные права: Администрирование данных, Активные пользователи, Журнал регистрации, Монопольный, Тонкий клиент, Веб-клиент, Сохранение данных пользователя, Вывод.

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

2.6.3. "АдминистраторСистемы" - обязательная роль, предоставляющая дополнительные права на администрирование информационной базы в целом (обновление конфигурации, работа в конфигураторе и т.п.). Эта роль должна:

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

В случае если конфигурация рассчитана на работу в модели сервиса, то роли "АдминистраторСистемы" и "ПолныеПрава" назначаются администраторам сервиса.

2.6.4. "ИнтерактивноеОткрытиеВнешнихОтчетовИОбработок" - обязательная роль, предоставляющая дополнительные права на открытие внешних отчетов и обработок через меню "Файл – Открыть". Эта роль должна включать в себя права к корню конфигурации Интерактивное открытие внешних отчетов и Интерактивное открытие внешних обработок. При работе конфигурации в локальном режиме роль "ИнтерактивноеОткрытиеВнешнихОтчетовИОбработок" назначается администраторам, но в целях повышения безопасности информационной базы администратор может запретить использование данной роли. При работе в модели сервиса роли "АдминистраторСистемы", "ПолныеПрава" и "ИнтерактивноеОткрытиеВнешнихОтчетовИОбработок" назначаются администраторам сервиса.

2.6.5. Роли "ПолныеПрава", "АдминистраторСистемы" и "ИнтерактивноеОткрытиеВнешнихОтчетовИОбработок" должны устанавливаться как основные роли конфигурации (свойство "ОсновныеРоли").

2.6.6. Ни в одной роли, включая "ПолныеПрава" и "АдминистраторСистемы", не должно быть установлено (кроме отдельных обоснованных случаев) следующих прав:

• Право интерактивного удаления,
• Интерактивное удаление предопределенных данных,
• Интерактивная пометка удаления предопределенных данных,
• Интерактивное снятие пометки удаления предопределенных данных,
• Интерактивное удаление помеченных предопределенных данных.
• Право удаления рекомендуется оставить только в ролях "ПолныеПрава" и "АдминистраторСистемы".

2.6.7. Для проверки прав доступа в коде следует использовать метод ПравоДоступа. Такой подход позволяет повысить устойчивость кода к пересмотру состава ролей в конфигурации.

2.7. Оформление текстов запросов.

2.7.1. Все ключевые слова языка запросов пишутся заглавными буквами.

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

2.8. Сообщения, предупреждения, уведомления.

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

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

2.8.3. Конфигурация должна выдавать предупреждения с подробными пояснениями перед выполнением процедур, занимающих продолжительное время.

2.8.4. Модальные диалоги, вопросы, предупреждения не должны вызываться внутри транзакций записи и проведения.

2.8.5. При выдаче пользователю вопросов с несколькими вариантами выбора ответа, по умолчанию должен предлагаться ответ, выбор которого вызывает действия, либо наиболее безопасные для информационной базы, либо предусматривающие контроль пользователя за выполнением действий.
Пример 1. Если пользователю предлагается выбор между пунктами "Удалить" и "Пометить на удаление", выбором по умолчанию должен быть "Пометить на удаление".
Пример 2. Если пользователю предлагается выбор между ответами "Печатать без предварительного показа" и "Печатать с предварительным показом", выбором по умолчанию должен быть "Печатать с предварительным показом".

2.8.6. Информация об ошибках, выявленных при проверке заполнения, должна выводиться в панели сообщений формы.

2.8.7. Информация об ошибке должна доводиться до пользователя в отдельном диалоге.

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

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

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

2.9. Программное создание прикладных объектов

2.9.1. Для программного создания прикладных объектов следует использовать методы соответствующих менеджеров (СоздатьЭлемент, СоздатьДокумент, СоздатьНаборЗаписей и т.д.). Для программного создания прикладных объектов, у которых существует соответствующие менеджеры объектов, использование конструктора (оператор встроенного языка Новый) запрещается.

2.9.2. При программном создании объекта следует явно вызывать метод объекта Заполнить. Если данных для заполнения нет, то передать значение Неопределено. В этом случае корректно отработают свойства реквизитов объекта "Значение заполнения", будет вызван обработчик ОбработкаЗаполнения и подписки на это событие, как при интерактивной работе с объектом.

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

2.10. Порядок записи движений документов

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

2.11. Использование признака ОбменДанными.Загрузка в обработчиках событий объекта

Все действия в процедурах-обработчиков событий ПередЗаписью, ПриЗаписи, ПередУдалением должны выполняться после проверки на ОбменДанными.Загрузка. Это необходимо для того, чтобы никакая бизнес-логика объекта не выполнялась при записи объекта через механизм обмена данными, поскольку она уже была выполнена для объекта в том узле, где он был создан. В этом случае все данные загружаются в ИБ "как есть", без искажений (изменений), проверок или каких-либо других дополнительных действий, препятствующих загрузке данных.

2.12. Ограничения на регламентные задания при работе в режиме сервиса.

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

2.13. Транзакции: правила использования.

2.13.1. Все вызовы НачатьТранзакцию с одной стороны и ЗафиксироватьТранзакцию или ОтменитьТранзакцию с другой стороны должны быть парными.

2.13.2. Начало транзакции и ее фиксация (отмена) должны происходить в контексте одного метода

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

• метод НачатьТранзакцию должен быть за пределами блока Попытка-Исключение непосредственно перед оператором Попытка;
• все действия, выполняемые после вызова метода НачатьТранзакцию, должны находиться в одном блоке Попытка, в том числе чтение, блокировка и обработка данных;
• метод ЗафиксироватьТранзакцию должен идти последним в блоке Попытка перед оператором Исключение, чтобы гарантировать, что после ЗафиксироватьТранзакцию не возникнет исключение;
• необходимо предусмотреть обработку исключений – в блоке Исключение нужно сначала вызвать метод ОтменитьТранзакцию, а затем выполнять другие действия, если они требуются;
• рекомендуется в блоке Исключение делать запись в журнал регистрации;
• при использовании вложенных транзакций (см. п. 1.4) в конце блока Исключение рекомендуется добавить оператор ВызватьИсключение. В противном случае исключение не будет передано выше по стеку вызовов, там не сработает обработка исключения, внешняя транзакция не будет явным образом отменена и платформа вызовет исключение "В данной транзакции происходила ошибка"

2.13.4. При обработке исключения, если транзакция все еще активна, например, исключение возникло во вложенной транзакции, нельзя обращаться к базе данных, так как это приведет к исключению "В этой транзакции уже происходили ошибки". При этом нужно учитывать, что обращение к базе данных может быть неявным, например, для получения представления ссылки.

2.13.5. Следует избегать транзакций, которые выполняются длительное время. В рамках транзакции нужно стремиться выполнять минимум действий – только те, которые нельзя в соответствии с бизнес-логикой выполнять вне транзакции. Не следует в транзакции вызывать внешние ресурсы (сетевые папки, интранет- и интернет-сайты, почтовые, FTP-, HTTP-, веб-сервисы и т.п.):

• обращение к внешнему ресурсу может быть длительным;
• ресурс может быть недоступен;
• может произойти ошибка тайм-аута.

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

2.14. Использование директив компиляции и инструкций препроцессора

2.14.1. Директивы компиляции:

&НаКлиенте (&AtClient)
&НаСервере (&AtServer)
&НаСервереБезКонтекста (&AtServerNoContext)

следует применять только в коде модулей управляемых форм и в коде модулей команд. В остальных модулях рекомендуется применять инструкции препроцессору.

2.14.2. Не следует использовать инструкции препроцессора в клиент-серверных общих модулях для проверки клиентского и серверного контекстов (#Если Сервер, #Если Клиент) ввиду невозможности надежного определения контекста исполнения. Процедуры и функции, которые работают по-разному при вызове с клиента и с сервера, следует размещать в общих модулях с постфиксами Клиент и Сервер, а не КлиентСервер. В противном случае невозможно гарантировать корректную работу клиент-серверных

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

2.15. Ограничения на использование Выполнить и Вычислить на сервере.

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

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

УстановитьБезопасныйРежим(Истина);
Выполнить Алгоритм;

2.15.3. Если произвольный код не может быть успешно выполнен в безопасном режиме (например, в нем используется обращение к файлам), то такой код должен предварительно пройти аудит и должен быть размещен в справочнике, к которому есть доступ только у пользователя ответственного за безопасность (например, администратора).

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

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

2.16. Таймауты при работе с внешними ресурсами

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

2.17. Ограничение на выполнение "внешнего" кода.

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

• как расширения конфигурации – с помощью средств подсистемы "Базовая функциональность";
• как внешние отчеты и обработки – через "Дополнительные отчеты и обработки";
• в виде внешних компонент – через подсистему "Внешние компоненты";
• для запуска внешних программ – см. Безопасность запуска приложений.

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

2.17.3. Необходимо предупреждать администраторов об опасности перед подключением любого внешнего кода.

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

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

При использовании в конфигурации Библиотеки стандартных подсистем

• подобное отключение предупреждений уже предусмотрено в соответствующих подсистемах;
• запрещено отключать предупреждения об опасных действиях во всех остальных случаях.

2.17.6. Если в конфигурации предусмотрены средства обновления конфигурации (из файлов .cf, .cfu), восстановления из резервной копии или загрузки из dt-файла в режиме 1С:Предприятия, то эти операции должны выполняться с соблюдением следующих правил:

• обновление должно быть доступно только пользователю с ролью "Администратор системы";
• такое обновление должно выполняться только интерактивно текущим пользователем, а не служебным пользователем с полными правами;
• перед обновлением конфигурации из файла или восстановления из резервной копии, администратору должно показываться предупреждение о том, что он должен убедиться, что файл обновления получен из надежного источника;
• при обновлении конфигурации через Интернет, должно использоваться защищенное соединение и надежный источник, о чем нужно предупредить пользователя, когда он настраивает параметры подключения к источнику обновления.

При использовании в конфигурации Библиотеки стандартных подсистем (БСП) операции обновления конфигурации и восстановления из резервной копии следует выполнять только средствами подсистем "Обновление конфигурации" и "Резервное копирование ИБ" БСП. При этом автоматически будут выполнены все требования, перечисленные выше в этом пункте.

2.17.7. Если в конфигурации предусмотрены средства загрузки произвольных файлов в программу, то следует также иметь в виду, что они могут содержать вредоносный исполняемый код.
В этом случае в конфигурации следует предусмотреть

• для администратора – дополнительные средства контроля, в частности, список разрешенных (запрещенных) расширений файлов для загрузки в программу;
• блокирование открытия исполняемых файлов из программы (даже если их разрешено загружать и хранить в программе).

При использовании в конфигурации Библиотеки стандартных подсистем (БСП) работу с файлами следует организовывать только средствами подсистемы "Работа с файлами". При этом автоматически будут выполнены все требования, перечисленные выше в этом пункте.

2.18. Безопасность внешних компонент.

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

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

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

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

2.18.3. Внешние компоненты, входящие в состав конфигурации, должны храниться в макетах типа "Внешняя компонента".

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

• ПодключитьВнешнююКомпоненту;
• НачатьУстановкуВнешнейКомпоненты;
• УстановитьВнешнююКомпоненту;
• НачатьПодключениеВнешнейКомпоненты;
• ЗагрузитьВнешнююКомпоненту.

Для подключения компоненты из макета в составе конфигурации на клиенте следует использовать:

ОбщегоНазначенияКлиент.ПодключитьКомпонентуИзМакета

Для подключения компоненты из макета в составе конфигурации на сервере следует использовать:

ОбщегоНазначения.ПодключитьКомпонентуИзМакета

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

ВнешниеКомпонентыКлиент.ПодключитьКомпоненту

2.18 5. При загрузке внешнего кода из удаленных источников в конфигурацию, следует:

• использовать только надежные источники, к которым есть доверие;
• выполнять передачу данных только по защищенным каналам связи;
• защищенное соединение следует устанавливать с проверкой подлинности сервера, к которому выполняется подключение.

Это требование также справедливо для загрузки любых данных по защищенным протоколам HTTPS и FTPS с использованием объектов и методов HTTPСоединение, FTPСоединение, WSПрокси, WSОпределения, WSСсылкаМенеджер.СоздатьWSПрокси. При использовании в конфигурации Библиотеки стандартных подсистем необходимо использовать функцию НовоеЗащищенноеСоединение общего модуля ОбщегоНазначенияКлиентСервер.

2.19. Безопасность запуска приложений.

2.19.1. При запуске внешней программы из кода требуется составлять строку запуска таким образом, чтобы она собиралась только из проверенных частей.
Если одна из частей, из которых собирается строка запуска, содержит данные, полученные из базы данных, из поля ввода на форме или прочитаны из хранилища настроек, то перед запуском программы требуется проверить, являются ли запуск безопасным. Безопасными считаются такие строковые данные, которые не содержат в себе следующие символы: "$", "`", "|", "||" ";", "&", "&&".

Данное требование распространяется на все способы запуска программы, в том числе:

• КомандаСистемы(<СтрокаКоманды>, <ТекущийКаталог>)
• ЗапуститьПриложение(<СтрокаКоманды>, <ТекущийКаталог>, <ДождатьсяЗавершения>, <КодВозврата>) ;
• НачатьЗапускПриложения(<ОписаниеОповещения>, <СтрокаКоманды>, <ТекущийКаталог>, <ДождатьсяЗавершения>);
• ПерейтиПоНавигационнойСсылке(<НавигационнаяСсылка>);
• Использование COM объектов "Wscript.Shell" и "Shell.Application".

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

• Для того чтобы открыть проводник с фокусировкой на указанном файле, использовать процедуру ФайловаяСистемаКлиент.ОткрытьПроводник.
• Для того чтобы открыть файл в программе просмотра, ассоциированной с расширением файла, использовать процедуру ФайловаяСистемаКлиент.ОткрытьФайл. Она исключает запуск исполняемых файлов (например, *.exe, *.bin, *.apk).

2.19.3. Для того чтобы открыть веб-страницу в браузере, запустить программу по протоколу (например, mailto:, skype:, tel: и.т.д) или открыть навигационную ссылку информационной базы следует использовать процедуру ФайловаяСистемаКлиент.ОткрытьНавигационнуюСсылку. При этом в веб-клиенте пользователю будет предложено установить расширение для работы с файлами в тех случаях, когда оно необходимо для выполнения операции.
В то же время, для открытия проводника или файла в программе просмотра не следует формировать ссылку по протоколу file://, для этого следует использовать одну из процедур: ОткрытьПроводник или ОткрытьФайл.

2.19.4. Для того чтобы:

• запускать файлы на исполнение (например, *.exe, *bat),
• использовать системные команды (например, ping, tracert или traceroute, обращаться к rac-клиенту),
• выполнять команды на сервере,
• а также получать код возврата и значения потоков вывода (stdout) и ошибок (stderr)

следует использовать ФайловаяСистемаКлиент.ЗапуститьПрограмму (в клиентском коде) и ФайловаяСистема.ЗапуститьПрограмму (в серверном коде).

2.20 Безопасность программного обеспечения, вызываемого через открытые интерфейсы.

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

2.20.2. В частности, перед программным открытием документов Microsoft Word и Microsoft Excel через COM следует запрещать исполнение макросов. Иначе это может привести к выполнению вредоносных макросов (вирусов), если таковые присутствуют в документе.

2.20.3. Если при программном открытии документов Microsoft Office все же необходимо разрешить выполнение автоматически запускающихся макросов, тогда следует реализовать следующую логику работы:

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

2.21. Документация по конфигурации.

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

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

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

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

2.21.5. Конфигурация может быть защищена аппаратным или программным способом. В этом случае в руководстве пользователя кроме описания установки системы защиты должно быть отражено:

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

2.22. Поставка конфигурации.

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

2.22.1.2. Все шаблоны должны находиться в подкаталогах предопределенного каталога и сопровождаться файлами-манифестами, описывающими установленные шаблоны. Имена параметров инсталляции должны быть уникальными. Для соблюдения уникальности параметров инсталляции название разработчика должно быть зарегистрировано в соответствии с рекомендациями, опубликованными на сайте "1С:Предприятие 8" в разделе Информация для разработчиков "Регламент регистрации названий разработчиков конфигураций (http://partners.v8.1c.ru).

2.22.1.3. Конфигурация должна инсталлироваться на компьютер пользователя с названием решения (раздел Catalog в файле-манифесте) и в каталог (раздел Destination в файле-манифесте), утвержденным по итогам регистрации вашей фирмы.

2.22.1.4. Разработчик совместного решения должен зарегистрироваться как разработчик в обычном порядке (см. п. 2.10.1.2), то есть, у него должно быть, как минимум, "свое" имя каталога. Название решения должно использоваться для названия совместного продукта с добавлением "1С:". Название каталога установки – свое зарегистрированное название каталога.

2.22.2. В поставку продукта включается файл readme, в котором необходимо указать полное название конфигурации, ее редакцию, версию и номер релиза, а также рекомендуемую к использованию версию "1С:Предприятия". В нем также описываются дополнительные файлы, включенные в поставку, если такие есть.

2.22.3. Выпуск новых релизов конфигурации должен сопровождаться описанием изменений в релизе. Пользовательское описание изменений готовится в виде файла с названием, состоящем из имени конфигурации, ее версии, и слов "Новое в версии". Например, "Бухгалтерия предприятия. Версия 3.0.147. Новое в версии.htm". В файле перечисляется, что изменилось в этом релизе. Этот файл включается в поставку обновления конфигурации и показывается пользователю в конце установки продукта или его обновления. Пользовательское описание должно быть ориентировано на конечных пользователей конфигурации.

2.22.4. Конфигурация должна поставляться с установленной поддержкой.

2.22.5. Конфигурация должна поставляться с демонстрационным примером в отдельной Информационной Базе, содержащей данные гипотетического предприятия в виде законченного примера. В примере не допускаются имена объектов данных типа "Тест", "Товар 1", "Контрагент 3" и подобные. Также нежелательны "условные" заполнения полей документов и справочников, например: "Назначение 1", "Содержание 1". Введенные в демонстрационную базу данные должны соответствовать специфике той отрасли, к которой относится сертифицируемое решение. Наполнение демонстрационной базы должно быть таким, чтобы сформированные отчеты содержали информацию, отражающую назначение отчета. Недопустимо формирование отчетов, содержащих только заголовки.

2.22.6. Вместо включения в поставку демонстрационной базы допускается предоставление временного доступа к опубликованному примеру на сайте разработчика. Если конфигурация содержит заимствованные фрагменты типового решения фирмы "1С", то публикация должна выполняться способами, изложенными в Информационном письме № 21502 "О правомерном предоставлении удаленного демо-доступа к программам "1С:Предприятие".

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

Подробней о требованиях к разработке конфигураций смотрите в документе "1С:Предприятие 8. Система стандартов и методик разработки конфигураций", опубликованном в разделе Методические материалы для разработчиков и администраторов 1С на ИТС: https://its.1c.ru/db/v8std

Для автоматизированной проверки конфигураций, разработанных на платформе "1С:Предприятие 8", на соответствие требованиям "1С:Совместимо" рекомендуется использовать инструмент "1С:Автоматизированная проверка конфигураций" . https://solutions.1c.ru/catalog/apk, https://releases.1c.ru/project/ACC

3. Требования к дополнениям конфигураций, разработанным в среде "1С:Предприятие 8.3" без использования механизма расширений.

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

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

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

3.4. В текстах модулей все добавленные фрагменты к конфигурации должны быть выделены комментариями.

3.5. Продукт, являющийся дополнением, должен содержать заполненную информацию в "Свойствах конфигурации".

В разделе "Представление":

• "Краткая информация" указывается название конфигурации вместе с дополняемой.
• "Подробная информация" указывается подробная информация о своем продукте.
• "Адрес информации о поставщике" указывается ссылка на ресурс с информацией о своей компании.
• "Адрес информации о конфигурации" указывается ссылка на ресурс с информацией о своем продукте.

В разделе "Разработка":

• "Поставщик" - указывается наименование компании разработчика.
• "Версия" - указывается полный номер версии конфигурации.
• "Адрес каталога обновлений" - указывается ссылка на ресурс с обновлениями, если такой есть.

3.6. Документация по дополнениям к конфигурации.

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

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

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

3.7. Поставка дополнения к конфигурации.

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

Название решения (раздел Catalog в файле-манифесте) должно использоваться для названия дополнения тем же, что и у дополняемой конфигурации, при этом можно добавить к нему свое зарегистрированное название. Название каталога установки (раздел Destination в файле-манифесте) это свое зарегистрированное название каталога установки, утвержденное по итогам регистрации названий установки вашей фирмы.

3.7.2. Разработчик совместного решения должен зарегистрироваться как разработчик в обычном порядке (см. п. 2.10.1.2), то есть, у него должно быть, как минимум, "свое" имя каталога. Название решения должно использоваться для названия совместного продукта с добавлением "1С:". Название каталога установки – свое зарегистрированное название каталога.

3.7.3. В поставку продукта должен быть включен файл readme, в котором указывается полное название продукта вместе с его редакцией и версией. А также полное название конфигурации, для которой он разработан, с номером редакции, релизом и рекомендуемую к использованию версию "1С:Предприятия". В нем также описываются дополнительные файлы, включенные в поставку, если такие есть

3.7.4. Выпуск новых релизов продукта должен сопровождаться описанием изменений в релизе. Пользовательское описание изменений готовится в виде файла с названием, состоящем из имени конфигурации, ее версии, и слов "Новое в версии". Например, "Учет ГСМ. Версия 3.0.147. Новое в версии.htm". В файле перечисляется, что изменилось в этом релизе. Этот файл включается в поставку обновления продукта. Пользовательское описание должно быть ориентировано на конечных пользователей конфигурации.

3.7.5. Дополнение к Конфигурации должно поставляться с установленной поддержкой.

3.8 Дополнение должно поставляться с демонстрационным примером в отдельной Информационной Базе, содержащей данные гипотетического предприятия в виде законченного примера. В примере не допускаются имена объектов данных типа "Тест", "Товар 1", "Контрагент 3" и подобные. Также нежелательны "условные" заполнения полей документов и справочников, например: "Назначение 1", "Содержание 1". Введенные в демонстрационную базу данные должны соответствовать специфике той отрасли, к которой относится сертифицируемое решение. Наполнение демонстрационной базы должно быть таким, чтобы сформированные отчеты содержали информацию, отражающую назначение отчета. Недопустимо формирование отчетов, содержащих только заголовки.

3.9. Вместо включения в поставку демонстрационной базы допускается предоставление временного доступа к опубликованному примеру на сайте разработчика. Если конфигурация содержит заимствованные фрагменты типового решения фирмы "1С", то публикация должна выполняться способами, изложенными в Информационном письме № 21502 "О правомерном предоставлении удаленного демо-доступа к программам "1С:Предприятие".

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

3.11. Использовать программный продукт, являющийся дополнением, можно только пользователям, правомерно владеющим основной поставкой "1С:Предприятия 8", на основе которой создано данное тиражное решение.

4. Требования к комплекту сервисных отчетов и обработок, разработанным в среде "1С:Предприятие 8.3"

4.1. Комплект сервисных отчетов и обработок предоставляет дополнительный сервис при использовании актуальных на дату подачи заявки релизов конфигураций.

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

4.3. Программные продукты, представленные в данной категории, должны удовлетворять всем требованиям, предъявляемым к Конфигурациям в части оформления продукта и использования средств "1С:Предприятия 8".

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

4.5. В руководстве пользователя должно быть указано полное название конфигурации с номером редакции, для которой этот продукт можно применять.

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

4.7. Все переменные модулей должны иметь комментарии. Комментарии должны быть достаточно подробными, чтобы пояснять назначение переменных. Комментарии ставятся в той же строке после переменной.

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

• секция "Описание" - содержит краткое описание назначения и/или принципов работы процедуры(функции), может быть единственной секцией для функций без параметров;
• секция "Параметры" - описывает параметры процедуры(функции), если их нет, секция пропускается, предваряется строкой "Параметры:";
• секция "Возвращаемое значение" - описывает тип и содержание возвращаемого значения функции, предваряется строкой "Возвращаемое значение:", для процедур эта секция отсутствует.

4.9. В поставку продукта должен быть включен файл readme, в котором указывается полное название продукта вместе с его редакцией и версией. А также полное название конфигурации, для которой он разработан, с номером редакции, релизом и рекомендуемую к использованию версию "1С:Предприятия". В нем также описываются дополнительные файлы, включенные в поставку, если такие есть.

5.0. Выпуск новых релизов продукта должен сопровождаться описанием изменений в релизе. Пользовательское описание изменений готовится в виде файла с названием, состоящем из имени конфигурации, ее версии, и слов "Новое в версии". Например, "Дополнительные отчеты. Версия 3.0.147. Новое в версии.htm". В файле перечисляется, что изменилось в этом релизе. Этот файл включается в поставку обновления продукта. Пользовательское описание должно быть ориентировано на конечных пользователей конфигурации.

5. Требования к внешним компонентам системы программ, разработанным в среде "1С:Предприятие 8.3"

5.1. Для расширения функциональных возможностей "1С:Предприятия 8" используются внешние компоненты. Внешние компоненты должны быть разработаны в соответствии с технологией создания внешних компонент "1С:Предприятия", поставляемой фирмой "1С". Она позволяет создавать внешние компоненты для ОС семейства Windows и ОС семейства Linux, а также для веб-клиента, работающего в веб-браузерах Microsoft Internet Explorer версии 8 и выше, Google Chrome 4 и выше (для OC Windows), Mozilla Firefox версии 17 и выше (для OC Windows и Linux).

5.2. В данной категории сертифицируются внешние компоненты, не предназначенные для работы с торговым оборудованием. Сертификация внешних компонент для торгового оборудования проводится по категории Торговое оборудование.

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

5.4. Все варианты компоненты должны быть упакованы в ZIP-архив с манифестом.

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

5.6. В руководстве пользователя должно быть указано, для какой конфигурации (полное название, редакция и версия) этот продукт можно применять.

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

5.8. Все свойства и методы внешней компоненты должны быть описаны в документации.

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

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

6.1. В текстах модулей все места подключения и использования методов внешней компоненты должны быть выделены комментариями.

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

6. Требования к системам удаленного банковского обслуживания

6.1. Программный продукт для обмена электронными документами между системой "1С:Предприятие 8" с одной стороны и системой дистанционного банковского обслуживания или "шлюзом" автоматизированной банковской системы с другой стороны должен соответствовать правилам стандарта DirectBank, опубликованным на http://directbank.1c.ru/standart

6.2. Для программы допускается отсутствие "коробочного" вида продукта.

6.3. Программа должна иметь документацию (допускается электронная версия), гарантийные обязательства по сопровождению (или бланк договора). В документации должно быть указано, как пользователь должен настроить программу для обмена данными с "1С:Предприятием", какой использует стандарт обмена и как производить обмен данными.

6.4. Для прохождения процедуры сертификации необходимо предоставить дистрибутив (при наличии) с демонстрационной базой или обеспечить доступ к тестовому стенду для проверки взаимодействия.

7. Требования к продуктам, использующим различные способы взаимодействия и обмена данными с системой "1С:Предприятие 8.3"

7.1 Программные продукты, интегрированные с системой "1С:Предприятие 8", должны со стороны "1С:Предприятия 8" использовать только штатные и документированные средства для взаимодействия и обмена.

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

7.3. Программные продукты, представленные в данной категории, должны удовлетворять всем требованиям, предъявляемым к Конфигурациям в части оформления продукта и использования средств "1С:Предприятия 8".

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

7.5. В руководстве пользователя должен быть указан номер версии "1С:Предприятия" и полное название конфигурации с номером редакции, для которой разработан продукт.

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

7.7. В руководстве пользователя должна быть описана технология и механизм взаимодействия между программами с приведением иллюстрирующих примеров.

7.8. Если продукт предоставляется на соответствие обмену данными EnterpriseData, то он должен быть выполнен в соответствии с технологией его создания, опубликованной на сайте ИТС, и на актуальной версии формата.

7.9. В поставку продукта должен быть включен файл readme, в котором указывается полное название продукта вместе с его редакцией и версией. А также полное название конфигурации, для которой он разработан, с номером редакции, релизом и рекомендуемую к использованию версию "1С:Предприятия". В нем также описываются дополнительные файлы, включенные в поставку, если такие есть.

8.0. Выпуск новых релизов продукта должен сопровождаться описанием изменений в релизе. Пользовательское описание изменений готовится в виде файла с названием, состоящем из имени конфигурации, ее версии, и слов "Новое в версии". Например, "Интеграция. Версия 3.0.147. Новое в версии.htm". В файле перечисляется, что изменилось в этом релизе. Этот файл включается в поставку обновления продукта. Пользовательское описание должно быть ориентировано на конечных пользователей.

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

8. Требования к расширениям конфигураций, разработанным в среде 1С:Предприятие 8.3"

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

8.2. Расширение должно быть тиражным и иметь ориентацию на внедрение для отрасли, ведомства и т.п., а не на одно конкретное предприятие.

8.3. Расширение должно иметь одно из следующих назначений:

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

В документации нужно указать, какое именно назначение имеет расширение – Адаптация или Дополнение.

8.4. Расширения конфигураций должны корректно учитывать следующие предположения:

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

8.5. Все добавленные объекты (методы и объекты, отчеты, обработки и подсистемы, а также обработчики событий) расширения, а также имена собственных методов и переменных расширяющих модулей, должны иметь префикс, соответствующий префиксу самого расширения.

8.6. Если расширяемые методы содержат какие-либо параметры, то все расширяющие методы обязаны иметь в точности такое же описание, как и расширяемый метод, с точностью до ключевых слов "Знач" в описаниях параметров методов.

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

8.8. Если продукт является собственной разработкой, то он должен содержать соответствующую информацию в "Свойствах расширения":

В разделе "Основные":

• "Имя" расширения образуется по правилам образования имен из синонима; слово "редакция", номер редакции (и подредакции) – не указываются.
• "Синоним" - указывается официальное название расширения, которое будет его идентифицировать. В конце официального названия через запятую указывается слово "редакция" и номер редакции.

В разделе "Представление":

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

В разделе "Разработка":

• "Поставщик" - указывается наименование компании разработчика.
• "Версия" - указывается полный номер версии расширения.

8.9. В расширениях допускается применять только программную защиту.

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

8.11. Требования к документации.

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

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

8.11.3. В руководстве пользователя должно быть указано, для какой конфигурации (полное название, номер редакции и номер релиза) это расширение можно применять.

8.11.4. В документации необходимо указать требуемый профиль безопасности для клиент-серверного варианта работы или написать следующее: "Профиль безопасности для клиент-серверного варианта работы дополнительных настроек не требует".

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

8.11.6. Если в расширяемой конфигурации используется Библиотека стандартных подсистем (БСП), то методика подключения и работа с расширением должна быть описана с использованием механизма БСП по администрированию расширений конфигурации. Подключение расширений должно производиться через меню Администрирование – Печатные формы, отчеты и обработки – Расширения.

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

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

8.11.8. Если расширение поддерживает работоспособность только в небезопасном режиме с учетом требований работы с внешними ресурсами, информация об этом обязательно должна быть отражена в документации. Фирма "1С" может указывать в рекламной информации по данному продукту, что использование расширения возможно только в небезопасном режиме с учетом требований работы с внешними ресурсами.

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

8.12. В поставку продукта, кроме самого файла расширения и документации, должен входить файл readme, в котором указывается полное название продукта вместе с его редакцией и версией. А также полное название конфигурации, для которой он разработан, с номером редакции, релизом и рекомендуемую к использованию версию "1С:Предприятия". В нем также описываются дополнительные файлы, включенные в поставку, если такие есть.

8.13. Выпуск новых релизов расширения должен сопровождаться описанием изменений в релизе. Пользовательское описание изменений готовится в виде файла с названием, состоящем из имени расширения, его версии, и слов "Новое в версии". Например, "Реализация учета. Версия 3.0.147. Новое в версии.htm". В файле перечисляется, что изменилось в этом релизе. Этот файл включается в поставку обновления расширения. Пользовательское описание должно быть ориентировано на конечных пользователей конфигурации.

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