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

Данная редакция требований действует с 1 мая 2010 года.

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

  1. Программный продукт, представленный на сертификацию, должен быть предназначен для тиражного распространения, и не иметь ориентации на конкретное внедрение. Это означает, что продукт должен продаваться или быть предназначен для продажи любому юридическому или физическому лицу, изъявившему желание его приобрести, и может быть внедрен и использован без помощи специалистов организации-разработчика.
  2. Продукт должен иметь документацию (руководство пользователя).
  3. В руководстве пользователя должно быть в явном виде описано взаимодействие продукта с "1С:Предприятием".
  4. Программный продукт должен использовать только штатные и документированные возможности работы с "1С:Предприятием 8".
  5. Продукт, ориентированный на конечного пользователя, должен иметь средства установки. Средства установки, при их наличии, должны быть описаны в документации к программному продукту.
  6. Использование логотипа "1С" в оформлении программного продукта и названия "1С" в его наименовании допускается только по специальному согласованию с фирмой "1С", например, для совместных с фирмой "1С" разработок. Использование логотипа 1C:Франчайзинг допускается для продуктов партнеров-франчайзи. В случае успешной сертификации фирма-разработчик имеет право использовать для оформления логотип "1C:Совместимо!".
  7. При внесении исправлений или изменений в сертифицированный продукт, связанных с изменениями в законодательстве и исправлением ошибок, разработчик обеспечивает соответствие измененного продукта требованиям, предъявляемым при сертификации. В случае внесения изменений, нарушающих требования сертификации, фирма "1С" имеет право приостановить действие сертификата. Новые редакции ранее сертифицированных продуктов, отличающиеся по функциональности от предыдущих версий, должны быть сертифицированы заново.
  8. В заявке на сертификацию разработчик должен предоставить письменную гарантию с подписью руководителя и печатью фирмы-разработчика в том, что продукт является собственной разработкой и при разработке продукта не были нарушены чьи-либо авторские или иные права.

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

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

  1. Конфигурации выпускаются версиями и редакциями. Версия - исправление текущих ошибок и внесение незначительных усовершенствований. Выпуск новой версии должен обеспечивать переход с предыдущей с сохранением данных. Редакция - внесение существенных изменений в структуру учета, требующих преобразования данных. При выпуске новой редакции должен быть обеспечен переход с сохранением данных или описана процедура перехода на новую редакцию (начало работы, перенос начальных остатков и т.д.).
  2. Номер версии указывается в свойствах конфигурации. Номер версии формируется по правилам, описанным в статье "Нумерация редакций и версий" документа "Система стандартов и методик разработки конфигураций для платформы "1С:Предприятие 8", опубликованном на диске ИТС в разделе "Методическая поддержка".
  3. Термин "типовая конфигурация" может быть использован только для конфигураций, разработанных фирмой "1С", либо локализованных по заказу фирмы "1С".
  4. Приложения, представленные на сертификацию, могут быть разработаны как с использованием режима управляемого приложения, так и без него. Наличие возможности работы в режиме управляемого приложения указывается в заявке на сертификацию, в документации к продукту.
  5. Если продукт предназначен для работы в режиме управляемого приложения, то он должен удовлетворять следующим требованиям:
    1. Продукт должен быть разработан с использованием управляемых форм и управляемого интерфейса.
    2. В нем должна поддерживаться полнофункциональная работа в тонком и веб-клиенте.
    3. Если работа в веб-клиенте не покрывает всей клиентской функциональности, то это должно быть описано в документации.

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

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

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

  1. Синоним объекта метаданных обязательно заполняется. Синоним должен быть определен так, чтобы осмысленно и лаконично описывать объект.
  2. Имя объекта метаданных и его синоним не должны содержать грамматических ошибок.
  3. Основные виды объектов конфигурации (объекты метаданных верхнего уровня): Константы, Справочники, Перечисления Документы, Журналы документов, Отчеты, Обработки, Планы видов характеристик, Планы счетов, Планы видов расчета, Планы обмена, Бизнес-процессы, Регистры - сортируются в дереве конфигурации по имени и по возрастанию. Исключение составляют объекты с префиксом "Удалить", которые должны размещаться в конце соответствующей ветки метаданных. Подчиненные объекты метаданных, такие как реквизиты, измерения, формы, располагаются в дереве метаданных в соответствии с проектной логикой.
  4. Конфигурация не должна иметь неиспользуемых объектов, элементов меню и кнопок панелей инструментов.
  5. Если в конфигурации есть разграничение прав доступа пользователей к данным, то должна быть обязательно определена роль, которая предназначена для администраторов системы и предоставляет неограниченный доступ к данным и к конфигурации информационной базы. Роль должна иметь возможность использоваться самостоятельно. У роли должны быть установлены все права, кроме интерактивного удаления.
  6. В случае если в конфигурации для пользователей необходимо настраивать общие права работы с информационной базой (такие как "Тонкий клиент", "Толстый клиент", "Интерактивное открытие внешних обработок" и т.д.), то в конфигурации должны быть определены отдельные роли для предоставления этих прав. Такие роли не предназначены для самостоятельного использования, их следует назначать пользователям совместно с остальными ролями конфигурации.
  7. Конфигурация в целом и ее основные объекты, имеющие свойство "Справочная информация", должны иметь пользовательское описание. Для объектов справочная информация должна содержать сведения:
    • о назначении объекта;
    • о способах его вызова - из меню программы, из других объектов;
    • о порядке и особенностях ввода информации;
    • описание реквизитов объекта, используемых пользователем;
    Cодержимое справочной информации основных объектов конфигурации должно включаться в общее описание конфигурации.
  8. Для поставки данных в составе конфигурации, например, данных, предназначенных для заполнения справочников, настроек отчетов, правил обмена данными и т.п. должны использоваться форматы, предназначенные для передачи данных (например, формат xml) и применять для этого макеты вида "Текстовый документ" или "Двоичные данные". Не следует использовать для этих целей макеты вида "Табличный документ”.
  9. В конфигурациях следует использовать "Управляемый" режим блокировок (свойство "Режим управления блокировкой данных" конфигурации устанавливается в значение "Управляемый") и учитывать особенности работы в этом режиме. В случае наличия серьезных обоснований для другого вида блокировок именно для этой конфигурации, то эту особенность и ее обоснование следует отразить в документации к конфигурации.

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

  1. В документации к конфигурации должно быть указано, для какого разрешения экрана и размера шрифта предназначена конфигурация. Типовым разрешением экрана считается 1024х768 pt.
  2. В случае использования фрагментов конфигураций, разработанных фирмой "1C", оригинальная часть конфигурации не должна отличаться по стилю оформления и написания от включенных частей типовых конфигураций.
  3. Для элементов диалога, информация в которые вводится пользователем, должны быть предусмотрены подсказки. Т.е для стандартных реквизитов, таких как Код, Наименование, Родитель, Владелец, Дата, Номер и для всех типизированных объектов метаданных (те объекты, для которых может быть указан тип информации, содержащейся в объекте) таких, как реквизиты объектов, реквизиты табличных частей, измерений и ресурсов регистров должно быть заполнено свойство Подсказка, поясняющее назначение данного объекта конечному пользователю. При этом не следует добавлять подсказки, совпадающие с синонимом объекта метаданных или реквизита. Текст подсказки не следует задавать в тех случаях, когда синоним объекта или реквизита достаточно полно поясняет его назначение пользователю, например, синоним к реквизиту НаименованиеПолное справочника Валюты достаточно подробно описывает его назначение пользователю как "Наименование валюты". А также в тех случаях, если предполагается, что значение реквизита будет недоступно для просмотра или редактирования из пользовательского интерфейса, например, в виде поля формы.
  4. Для всех типизированных объектов метаданных, а также для стандартных реквизитов, которые в соответствии с логикой объекта являются обязательными к заполнению, свойство "Проверка заполнения" должно иметь значение "Выдавать ошибку", либо подобная проверка должна быть прописана разработчиком самостоятельно в модуле.
  5. Если продукт предназначен для работы в режиме управляемого приложения, то он должен удовлетворять следующим требованиям:
    1. Последним разделом в интерфейсе всегда должен быть раздел для администрирования, настройки и выполнения сервисных действий.
    2. Рабочий стол является обязательным разделом и не может быть отключен.
    3. Следующие виды форм должны быть всегда доступны пользователю в режиме 1С:Предприятия из меню "Все функции" вне зависимости от того, размещены ли соответствующие объекты в командный интерфейс приложения или нет:
      • основная форма списка;
      • основная форма отчета;
      • основная форма обработки.
  6. Если продукт предназначен для работы в обычном режиме, то он должен удовлетворять следующим требованиям:
    1. В каждой конфигурации обязательно должны присутствовать интерфейсы "Общий" и "Полный". В интерфейсе “Общий” должны быть отображены общие для всех интерфейсов пункты меню и панели инструментов. У него снят признак "Переключаемый". У остальных интерфейсов признак "Переключаемый" устанавливается.
    2. В меню "Сервис" обязательно должно присутствовать подменю "Переключить интерфейс" для переключения текущего интерфейса на другой. Подменю должно содержать список всех интерфейсов конфигурации, кроме "Общий", который как составная часть входит во все остальные интерфейсы.
    3. Главное меню обеспечивает доступ ко всем формам, которые требуются пользователю для работы или сервисных функций. В подменю с большим числом элементов, группы элементов должны быть ограничены разделителями. Максимальное число элементов в одной группе не более 7. При любом положении выбора действия из главного меню, его размер должен быть таким, чтобы полностью умещаться на экране при минимальном разрешении, из расчета на которое разработана конфигурация.
    4. Элементы диалогов форм должны быть выровнены. Это значит, что левые, правые, верхние или нижние границы любых двух расположенных рядом элементов (за исключением элементов типа "Надпись") должны располагаться на одной вертикальной или горизонтальной линии. Привязка "по умолчанию" должна обеспечивать нормальное поведение форм при изменении размеров.

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

  1. Тексты модулей оформляются по принципу "один оператор в одной строке". Наличие нескольких операторов допускается только для "однотипных" операторов присваивания, например: А = 0; Б = 0; С = 0;
  2. Текст модулей должен быть выровнен синтаксическим отступом. Для синтаксического отступа следует использовать табуляцию, а не пробелы, чтобы при смене числа знаков в табуляции выравнивание текста сохранялось.
  3. Конфигурация не должна содержать ошибок, обнаруживаемых при синтаксическом контроле модулей.
  4. Конфигурация не должна содержать ошибок, обнаруживаемых при проверке конфигурации. Исключением является наличие процедур и функций, которые назначаются обработчикам событий элементов управления динамически из встроенного языка (с использованием объекта Действие). В комментариях к таким процедурам и функциям следует отражать, где она используется.
    Например:
    // Процедура назначается динамически действию кнопки командной панели КоманднаяПанельформы.КнопкиДействий.Кнопка
  5. Все переменные модуля обычного приложения, модуля управляемого приложения, модуля сеанса, модуля внешнего соединения, а также все экспортируемые переменные должны иметь комментарии. Комментарии должны быть достаточно подробными, чтобы пояснять назначение переменных. Комментарии ставятся в той же строке после переменной.
    Пример:
    Перем ДиалогРаботыСКаталогом; // Диалог работы с каталогом
  6. Процедуры и функции модуля обычного приложения, модуля управляемого приложения, модуля сеанса, общих модулей и экспортируемые, а также функции, предназначенные для использования другими подсистемами, должны предваряться заголовком. Заголовок имеет цель пояснить назначение и использование функции (процедуры) и размещается перед ее объявлением. Заголовок должен иметь следующий формат:
    • секция “Описание” - содержит краткое описание назначения и/или принципов работы процедуры(функции), может быть единственной секцией для функций без параметров;
    • секция “Параметры” - описывает параметры процедуры(функции), если их нет, секция пропускается, предваряется строкой "Параметры:";
    • секция “Возвращаемое значение“ - описывает тип и содержание возвращаемого значения функции, предваряется строкой "Возвращаемое значение:", для процедур эта секция отсутствует.
  7. Тексты модулей в сложных алгоритмах должны содержать комментарии. Если комментарий относится к модулю в целом, то он располагается в начале модуля (заголовок модуля). Если комментарий относится к оператору или группе операторов, то он должен располагаться перед комментируемым оператором (группой операторов). Длинные комментарии должны начинаться с большой буквы и заканчиваться точкой. Следует проверять текст комментария на отсутствие грамматических и синтаксических ошибок. Текст длинного комментария должен быть выровнен по левой границе комментируемого оператора (первого оператора группы операторов). Между символами комментария "//" и текстом комментария должен быть пробел. Строки не должны быть длиннее 120 символов за исключением тех случаев, когда перенос невозможен.
  8. Комментарии должны быть достаточно понятными, чтобы пояснять работу модуля или комментируемого оператора. Тексты комментариев должны составляться в деловом стиле, быть эмоционально сдержанными и не содержать слов, не относящихся к функциональности программы.
  9. Программные модули не должны иметь неиспользуемых или пустых процедур и функций и закомментированных фрагментов кода.
  10. Имена переменных не должны начинаться с подчеркивания. Имена переменных не могут состоять из одного символа. Использование коротких имен переменных допускается только для счетчиков циклов. Переменные, отражающие состояние некоторого флага, следует называть так, как пишется истинное значение этого флага.
  11. Функция глобального контекста ПредопределенноеЗначение() не должна применяться в тех условиях, когда доступны менеджеры прикладных объектов, вне кода тонкого или Web-клиента, т.е. в модулях объектов, наборов записей, общих модулях, для которых не установлен флаг компиляции на тонком клиенте, серверных процедурах и функциях модулей форм и т.д. Для указанных выше модулей обращение к предопределенным значениям должно выполняться через менеджер соответствующего объекта.
  12. Определение типа значения переменной необходимо выполнять путем его сравнения с типом, а не каким-либо другим методом.
    Правильно:
    Если ТипЗнч(Ссылка) = Тип("ДокументСсылка.ПоступлениеТоваровУслуг") Тогда
    Неправильно:
    Если Ссылка.Метаданные().Имя = "ПоступлениеТоваровУслуг" Тогда
  13. Для программного создания прикладных объектов следует использовать методы соответствующих менеджеров (СоздатьЭлемент, СоздатьДокумент, СоздатьНаборЗаписей и т.д.). Для программного создания прикладных объектов, у которых существуют соответствующие менеджеры объектов, использование конструктора (оператор встроенного языка Новый) запрещается.
    Правильно:
    ДокументПриходная = Документы.ПоступлениеТоваровУслуг.СоздатьДокумент();
    Неправильно:
    ДокументПриходная = Новый("ДокументОбъект.ПоступлениеТоваровУслуг").

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

  1. Все сообщения (предупреждения, уведомления) должны быть достаточно информативными и содержательными. Имена объектов конфигурации в сообщениях (предупреждениях, уведомлениях) должны даваться так, как они представлены в пользовательском интерфейсе. Имена объектов конфигурации всегда заключаются в кавычки. Сообщения составляются в безличной форме: не употребляются местоимения "Вы", "Вас" и пр.
  2. Конфигурация должна выдавать предупреждения с подробными пояснениями перед выполнением потенциально опасных действий. Потенциально опасными действиями считаются такие действия, исправить последствия которых можно либо путем повторного ввода информации, либо восстановлением данных из резервной копии.
  3. Конфигурация должна выдавать предупреждения с подробными пояснениями перед выполнением процедур, занимающих продолжительное время.
  4. Модальные диалоги, вопросы, предупреждения не должны вызываться внутри транзакций записи и проведения.
  5. При выдаче пользователю вопросов с несколькими вариантами выбора ответа, по умолчанию должен предлагаться ответ, выбор которого вызывает действия, либо наиболее безопасные для информационной базы, либо предусматривающие контроль пользователя за выполнением действий.
    Пример 1. Если пользователю предлагается выбор между пунктами "Удалить" и "Пометить на удаление", выбором по умолчанию должен быть "Пометить на удаление".
    Пример 2. Если пользователю предлагается выбор между ответами "Печатать без предварительного показа" и "Печатать с предварительным показом", выбором по умолчанию должен быть "Печатать с предварительным показом".

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

  1. Конфигурация должна поставляться с документацией. Документация должна включать разделы, описанные ниже.
    • Оглавление.
    • Инструкция по установке. Описание начальной установки конфигурации. Описание должно быть таким, чтобы продукт мог установить конечный пользователь.
      Если в конфигурации используется система защиты, то описание установки защиты должно быть включено в данный раздел.
    • Концепция конфигурации. Описание общих моментов, подходов к ведению учета, используемых методик учета, моделей и принятых допущений.
    • Руководство по ведению учета. Описание возможностей и порядок использования конфигурации.
  2. В описании конфигурации должны быть перечислены все основные объекты и механизмы, заимствованные из типовых конфигураций разработки фирмы "1C", со ссылками на соответствующую типовую конфигурацию.
  3. При использовании в конфигурации внешних компонент их свойства, методы, назначение и способы подключения должны быть описаны в документации. Если эти свойства и методы являются принципиально защищаемыми участками кода программы, то их достаточно перечислить.
  4. Выпуск новых релизов конфигурации должен сопровождаться описанием изменений в релизе. Пользовательское описание изменений готовится в виде файла в формате txt или html, в котором перечислено, что изменилось в этом релизе. Пользовательское описание должно быть ориентировано на конечных пользователей конфигурации.

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

  1. Для упрощения процесса создания и обновления информационных баз пользователем конфигурация должна инсталлироваться на компьютере пользователя в соответствии с рекомендациями фирмы "1С" определенным образом – все шаблоны должны находиться в подкаталогах предопределенного каталога и сопровождаться файлами-манифестами, описывающими установленные шаблоны. Имена параметров инсталляции должны быть уникальными. Для соблюдения уникальности параметров инсталляции название разработчика должно быть зарегистрировано в соответствии с рекомендациями, опубликованными на сайте "1С:Предприятие 8" в разделе Информация для разработчиков "Регламент регистрации названий разработчиков конфигураций" (http://partners.v8.1c.ru)
  2. Конфигурация должна поставляться с установленной поддержкой.
  3. Конфигурация должна поставляться с демонстрационным примером в отдельной Информационной Базе, содержащей данные гипотетического предприятия в виде законченного примера. В примере не допускаются имена объектов данных типа "Тест", "Товар 1", "Контрагент 3" и подобные. Также нежелательны "условные" заполнения полей документов и справочников, например: "Назначение 1", "Содержание 1". Введенные в демонстрационную базу данные должны соответствовать специфике той отрасли, к которой относится сертифицируемое решение.
  4. Наполнение демонстрационной базы должно быть таким, чтобы сформированные отчеты содержали информацию, отражающую назначение отчета. Недопустимо формирование отчетов, содержащих только заголовки.
  5. Модули конфигурации не должны быть защищены паролями. На сертификацию принимается продукт, в поставку которого включены исходные тексты модулей объектов. Однако допускается, что поставка для пользователей может быть сформирована без включения некоторых исходных текстов модулей.
  6. Конфигурация может быть защищена аппаратным или программным способом. В этом случае:
    • описание установки аппаратной защиты должно быть включено в печатное руководство;
    • в руководстве пользователя должно быть отражено, что данный продукт не является полностью конфигурируемым и перечислены объекты конфигурации, которые не могут быть изменены пользователем;
    • так как защищенная конфигурация не является полностью доступной для изменения, то разработчики берут на себя ответственность за ее корректную работу и полное соответствие требованиям сертификации в части недоступных для пользователя участков конфигурации;
    • фирма "1С" может указывать в рекламной информации по данному продукту, что он содержит фрагменты, которые не могут быть изменены в процессе его настройки на особенности учета на конкретном предприятии.
  7. Если документацию предполагается поставлять в электронном виде, то в поставку продукта должен быть включен файл описания состава продукта, в котором необходимо указать следующую информацию о документации:
    • с помощью какой программы можно прочитать документацию;
    • формат (размер печатных листов в оригинал макете);
    • количество страниц;
    • наименование использованных шрифтов;
    • список авторов.

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

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

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

  1. Комплект сервисных отчетов и обработок предоставляет дополнительный сервис при использовании актуальных на дату рассмотрения конфигураций. Программные продукты, представленные в данной категории, должны удовлетворять всем требованиям, предъявляемым к Конфигурациям в части оформления продукта и использования средств "1С:Предприятия 8".
  2. Если комплект предназначен для конфигурации, не являющейся разработкой фирмы "1С", то эта конфигурация должна иметь действующий сертификат "1С:Совместимо".
  3. Установка комплекта отчетов и обработок и подключение их к используемой конфигурации должно быть описано в документации.
  4. Все переменные модулей должны иметь комментарии. Комментарии должны быть достаточно подробными, чтобы пояснять назначение переменных. Комментарии ставятся в той же строке после переменной.
  5. Все процедуры и функции должны предваряться заголовком Заголовок имеет цель пояснить назначение и использование функции (процедуры) и размещается перед ее объявлением. Заголовок должен иметь следующий формат:
    • секция “Описание” - содержит краткое описание назначения и/или принципов работы процедуры(функции), может быть единственной секцией для функций без параметров;
    • секция “Параметры” - описывает параметры процедуры(функции), если их нет, секция пропускается, предваряется строкой "Параметры:";
    • секция “Возвращаемое значение“ - описывает тип и содержание возвращаемого значения функции, предваряется строкой "Возвращаемое значение:", для процедур эта секция отсутствует.

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

  1. Для расширения функциональных возможностей "1С:Предприятия 8" используются внешние компоненты. Внешние компоненты системы программ "1С:Предприятие 8" должны быть разработаны в соответствии с технологией создания внешних компонент "1С:Предприятия", поставляемой фирмой "1С". Она позволяет создавать внешние компоненты для ОС семейства Windows и ОС семейства Linux, а также для веб-клиента, работающего в веб-браузерах Microsoft Internet Explorer версии 6.0, 7 и 8, а также Mozilla Firefox версии 3 (для OC Windows и Linux). В данной категории сертифицируются внешние компоненты, не предназначенные для работы с торговым оборудованием. Сертификация внешних компонент для торгового оборудования проводится по категории Торговое оборудование.
  2. Внешняя компонента должна поставляться для всех операционных систем и клиентских приложений, работу в которых поддерживает то решение, для которого внешняя компонента предназначена. В документации они должны быть перечислены.
  3. Все варианты компоненты должны быть упакованы в ZIP-архив с манифестом.
  4. Если внешняя компонента предназначена для работы с типовой конфигурацией, то она должна быть работоспособной на актуальном на дату рассмотрения релизе.
  5. Все свойства и методы внешней компоненты должны быть описаны в документации.
  6. В руководстве пользователя должна быть описана технология подключения внешних компонент к системе 1С:Предприятие 8 с приведением иллюстрирующих примеров на конфигурации 1C:Предприятия 8.
  7. Все объекты конфигурации, в которых есть примеры использования внешней компоненты, должны иметь описание, поясняющее работу компоненты, включенное в справочную информацию.
  8. В текстах модулей все места подключения и использования методов внешней компоненты должны быть выделены комментариями.

6. Требования к продуктам системы электронных расчетов типа "Клиент банка", соответствующим стандарту обмена данными "1С:Предприятие" - "Клиент банка"

  1. Программный продукт типа "Клиент банка", должен соответствовать стандарту обмена данными, публикуемому на диске Информационно-технологического сопровождения (ИТС).
  2. Для программы этого класса допускается отсутствие "коробочного" вида продукта.
  3. Программа должна иметь дистрибутив, документацию (допускается электронная версия), гарантийные обязательства по сопровождению (или бланк договора). В документации должно быть указано, как пользователь должен настроить программу для обмена данными с "1С:Предприятием", и как производить обмен данными.
  4. Для прохождения процедуры сертификации необходимо предоставить демонстрационную базу для показа взаимодействия "Клиент банка" – "1С:Предприятие".

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

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