требования к программному коду 1с

Требования к написанию и оформлению программного кода 1С

Рассмотрим основные нормы применения и оформления программного кода 1С. Соблюдение данных правил обязательно для получения сертификата 1С:Совместимо.

Общие требования к конфигурации

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

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

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

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

Имя, синоним комментарий

Для подчиненных объектов метаданных, таких как реквизиты, измерения, ресурсы, рекомендуется не использовать имена, совпадающие с именами объектов-владельцев. Также рекомендуется не использовать имена, которые применяются при именовании таблиц языка запросов (например, «Документ», «Справочник», «РегистрСведений» и т.д.)

Многократное выполнение запросов

Рекомендуется получать все необходимые однотипные данные одним запросом вместо выполнения серии запросов.

Проверка на пустой результат выполнения запросов

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

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

Использование ключевых слов в запросах «Объединить» и «Объединить все» в запросах

В общем случае, при объединении в запросе результатов нескольких запросов следует использовать конструкцию «ОБЪЕДИНИТЬ ВСЕ», а не «ОБЪЕДИНИТЬ».
Поскольку во втором варианте при объединении запросов полностью одинаковые строки заменяются одной, на что затрачивается дополнительное время, даже в случаях, когда одинаковых строк в запросах заведомо быть не может.
Исключением являются ситуации, когда выполнение замены нескольких одинаковых строк одной является необходимым условием выполнения запроса.

Использование строк неограниченной длины

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

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

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

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

Программное управление формой

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

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

Программное управление формой из других модулей производится через присвоение её реквизитам (свойствам) значений и через вызов её методов или экспортных процедур (функций).

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

Не допускается обращение к элементам формы не из модуля этой формы: ни непосредственно, ни при помощи перебора коллекции «ЭлементыФормы», ни каким-либо другим способом.

Например, вполне корректно предполагать, что у формы элемента справочника есть свойство «ПараметрОснование», однако предположение о наличии у «ПараметрОснование» свойства «Дата» уже недопустимо.

Обращение к данным информационной базы в обработчиках часто вызываемых событий

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

События табличного поля:

В качестве средств минимизации в зависимости от ситуации могут быть:

Обращение к свойству «ТекущаяСтрока» табличного поля

Запрещается использовать свойство «ТекущаяСтрока» для получения значений полей строки табличного поля.
Обращение к данным значениям должно выполняться через «ТекущиеДанные» или «ДанныеСтроки».

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

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

Требования по локализации модулей

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

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

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

В функции НСтр() строка ограничивается символами одинарных кавычек.

Такое требование обусловлено частым использованием двойных кавычек в строковых литералах.

В том случае, если все же применяется не замена строк в строке-шаблоне, а сложение строк, то неязыковые символы (пробелы, табуляция и пр.) в начале и конце строк необходимо выделять в отдельные строковые литералы.
Правильно:

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

Тексты модулей

Тексты модулей должны быть написаны на русском языке.

Размер табуляции стандартный (4 символа).

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

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

Тексты модулей оформляются по принципу «один оператор в одной строке». Наличие нескольких операторов допускается только для «однотипных» операторов присваивания, например:

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

С крайней левой позиции должны начинаться только:

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

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

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

Небольшие комментарии пишутся в конце строки, которую комментируют, например:

Большие комментарии или комментарии к фрагменту кода пишутся перед комментируемым кодом в отдельной строке.

Комментарии записываются по правилам русского языка, то есть должны начинаться с большой буквы и заканчиваться точкой. Текст выравнивается по левой границе комментируемого фрагмента. Между символами комментария «//» и текстом комментария должен быть пробел.

Структура модулей

В программном модуле в общем случае могут присутствовать следующие разделы в приведенной ниже последовательности:

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

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

Заголовок модуля

Заголовок модуля представляет собой комментарий в самом начале модуля.

В заголовке модуля приводится его краткое описание и условия применения.

Для общих модулей заголовок является обязательным.

Раздел описания переменных

Переменным модуля обычного приложения, модуля управляемого приложения и внешнего соединения назначается префикс «гл».

Экспортные переменные модуля должны быть снабжены комментарием, достаточным для понимания их назначения. Для не экспортных переменных наличие комментария желательно, но не обязательно.

Комментарий рекомендуется размещать в той же строке, где объявляется переменная.

Процедуры и функции модуля

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

Обработчики событий элементов формы

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

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

Обработчики событий

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

Раздел инициализации

Раздел инициализации содержит операторы, инициализирующие переменные модуля или объект (форму).

Описание процедур и функций

Процедуры и функции рекомендуется комментировать.

Обязательного комментирования требуют экспортные процедуры и функции.

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

Комментарий размещается перед объявлением процедуры(функции) и имеет следующий формат:

Секция «Описание»

Содержит словесное краткое описание назначения и/или принципов работы процедуры(функции).

Секция «Параметры»

Описывает параметры процедуры (функции). Если их нет, секция пропускается. Предваряется строкой «Параметры:».

Секция «Возвращаемое значение»

Описывает тип и содержание возвращаемого значения функции. Предваряется строкой «Возвращаемое значение:». Для процедур эта секция отсутствует.

Исключение составляют функции, которые предназначены только для проверки истинности некоторого факта и которые возвращают в качестве результата проверки значение типа Булево.

Имена таких функций образуются из написания проверяемого факта.

Например, если функция должна проверить, что в переданной строке присутствуют только цифры, то она может называться ТолькоЦифрыВСтроке().
Описание процедур и функций должны отделятся друг от друга в тексте модуля пустыми строками.

Правила образования имен переменных

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

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

Имена переменных запрещается начинать с подчеркивания.

Имена переменных не должны состоять из одного символа. Использование коротких имен переменных допускается только для счетчиков циклов.

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

Перенос выражений

Длинные арифметические выражения переносятся следующим образом:

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

Сложные логические условия в Если…ИначеЕсли…КонецЕсли могут переноситься следующим образом:

Определение типа значения переменной

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

Получение метаданных объектов

Получение метаданных объекта конфигурации следует выполнять с помощью метода Метаданные() этого объекта, а не путем обращения к свойству глобального контекста «Метаданные», так как второй способ существенно более медленный.

Сортировка таблиц значений

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

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

Использование объекта РегистрСведенийМенеджерЗаписи

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

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

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

Копирование строк между таблицами значений произвольной структуры

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

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

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

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

Поэтому в качестве параметров следует указывать сами представления.

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

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

Это может приводить к увеличению времени выполнения запроса (и как следствие, общего времени формирования итогового документа), а при большом количестве типов – к невозможности его выполнения в клиент-серверной версии из-за ограничения Microsoft SQL Server, по которому в запросе не может участвовать больше 256 таблиц. Такие случаи также могут быть исключением для данного правила, в них представления для ссылочных значений допускается получать в момент их вывода в табличный документ.

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

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

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

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

Особенности контекстного выполнения на сервере и в режиме внешнего соединения

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

1. Запрещено использование объектов, имеющих тип данных, недоступный на сервере и во внешнем соединении:

2. Запрещено использование средств, отвечающих за диалог с пользователем:

3. Запрещается вызов экспортных процедур других общий модулей, у которых не установлен признак компиляции на сервере и/или во внешнем соединении.

4. Участки кода, в которых используются конструкции, не доступные на сервере или во внешнем соединении, должны выделяться соответствующими инструкциями препроцессору, например:

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

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

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

Если Вы начинаете изучать 1С программирование, рекомендуем наш бесплатный курс (не забудьте подписаться на YouTube — регулярно выходят новые видео):

К сожалению, мы физически не можем проконсультировать бесплатно всех желающих, но наша команда будет рада оказать услуги по внедрению и обслуживанию 1С. Более подробно о наших услугах можно узнать на странице Услуги 1С или просто позвоните по телефону +7 (499) 350 29 00. Мы работаем в Москве и области.

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.1.2. Номер версии указывается в свойствах конфигурации. Номер версии формируется по правилам, описанным в статье «Нумерация редакций и версий» документа «Система стандартов и методик разработки конфигураций для платформы «1С:Предприятие 8», опубликованном на диске ИТС.

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

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

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

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

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.3.8. В конфигурациях следует использовать «Управляемый» режим блокировок (свойство «Режим управления блокировкой данных» конфигурации устанавливается в значение «Управляемый») и учитывать особенности работы в этом режиме. В случае наличия серьезных обоснований для другого вида блокировок именно для этой конфигурации, то эту особенность и ее обоснование следует отразить в документации к конфигурации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.5.6. При разработке конфигураций разделы и подразделы оформляются в виде областей. Правила и примеры оформления разделов и подразделов приведены в статье «Структура модуля» документа «Система стандартов и методик разработки конфигураций для платформы «1С:Предприятие 8», опубликованном на диске ИТС.

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

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

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

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

2.5.13. Запрещается использовать оператор Перейти в общих модулях с признаком «Клиент (управляемое приложение)», модулях команд и в клиентском коде модулей управляемых форм, так как данный метод не поддерживается платформой 1С:Предприятие в режиме веб-клиента.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. В описании конфигурации должны быть перечислены все основные объекты и механизмы, заимствованные из типовых конфигураций разработки фирмы «1C» или других авторов, от которых должно быть получено разрешение на использование, со ссылками на соответствующую конфигурацию или разработку.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. Все варианты компоненты должны быть упакованы в ZIP-архив с манифестом.

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

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

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

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

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

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

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

6.1. Программный продукт для удаленного банковского обслуживания клиентов, должен соответствовать одному или нескольким стандартам обмена данными:

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

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

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

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

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

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

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

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

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

7.6. Если продукт предоставляется на соответствие обмену данными EnterpriseData, то он должен быть выполнен в соответствии с технологией его создания, опубликованной на нашем сайте в разделе http://v8.1c.ru/edi/edi_app/enterprisedata/.

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.12. Документация должна содержать описание всех возможностей расширения и методику работы с ним в расширяемой конфигурации с приведением примеров использования.

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

Источник