1С Рекомендуемо (Система требований к продуктам 1С)

СИСТЕМА ТРЕБОВАНИЙ К ПРОДУКТАМ 1С8.х

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

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

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

Общие правила построения метаданных и создания объектов

• Конфигурация не должна иметь неиспользуемых объектов
  Стандартных средств для проверки нет

• ведущие объекты в дереве метаданных сортируются по имени по возрастанию
  TestIB8x - 0007

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

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

• Модуль может иметь заголовок - описание модуля, которое располагается до секции объявления переменных модуля.
  Для общих модулей заголовок является обязательным.
  В общем случае, заголовок модуля может включать следующие разделы:
       - обзор - объяснение, зачем этот модуль был написан и общие принципы его работы;
       - особые условия работы модуля.
  Предложения в описании модуля записываются по правилам русского языка, то есть начинаются с большой буквы и заканчиваются точкой. Следует проверять текст на отсутствие синтаксических и грамматических ошибок.
  Никто не мешает объявить стандартный заголовок для всех общих модулей в формате javadoc, ndoc, doxygen, http://rsdn.ru/article/helpsystems/Sandcastle.xml
  Стандартных средств для проверки нет – на тупом уровне проверки наличия комменатариев в начале блока сделать несложно.

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

• Следует отделять друг от друг пробелами: <список> (мое мнение каждое слово модуля, в вызовах методов, функций, процедур после запятой всегда пробел и след. параметр)
  Между идентификаторами или операторами должно быть расстояние в один пробел.
  Стандартных средств для проверки нет.

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

• Имена переменных (параметров) следует образовывать от терминов предметной области.(либо от действия переменной с обязательным указанием типа переменной в виде краткой аббревиатуры)
  В качестве идеи: Можно создать два словаря: Универсальные идентификаторы, Идентификаторы предметной области. Тест будет проверять вхождение идентификатора программы в один их словарей. У реквизитов можно контролировать тип и размеры.

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

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

• Где возможно, следует использовать системные наборы значений. Например, вместо Символ(10) следует использовать Символы.ПС
  Стандартных средств для проверки нет – сделать легко

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

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

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

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

• Имя объекта надо стремиться строить на основе синонима объекта так, как это делает система автоматически: пробелы и пр. недопустимые символы удаляются, первые буквы слов делаются заглавными
  Стандартных средств для проверки нет – сделать легко

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

• Комментарий задается только в тех случаях, когда необходимы какие-либо пояснения
  Стандартных средств для проверки нет – сделать легко

Порядок разработки, сборки и выпуска конфигураций

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

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

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

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

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

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

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

Разработка интерфейсов и форм

• Все решения в интерфейсе пользователя нужно разрабатывать из расчета, что конфигурация используется при разрешении экрана не менее 1024х768 и цветовой глубины не менее 24 бита. Разработка форм ведется при размере шрифта 96 точек на дюйм. (знакомо))
  Уже все работает.

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

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

• Привязка "по умолчанию" должна обеспечивать нормальное поведение форм при изменении размеров. Необходимо минимизировать ручную установку привязок.
  Было бы классно запретить ручные привязки в принципе! Но как это сделать?
  Стандартных средств проверки нет.

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

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

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

• Кнопки используются вне командных панелей. Минимальный размер кнопок: 60х19. Шарина кнопки может увеличиваться в зависимости от длины строки заголовка кнопки.
  Надпись на кнопке должна занимать одну строку.
  Стандартных проверок нет – сделать несложно.

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

• Для оформления элементов конфигурации используется стиль "Основной".Стиль Основной устанавливается в целом для конфигурации. Для форм конфигурации устанавливается стиль "Авто".
  Стандартных средств для проверки нет – сделать легко

• Каждый активный элемент управления должен содержать подсказку
  Стандартных средств для проверки нет – сделать легко

• Сообщения составляются в безличной форме: не употребляются местоимения «Вы», «Вас» и пр.
  Можно, конечно, проверять все Сообщить, но как-то ломает …

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

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

Настройка прав доступа к данным

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

• При достаточно сложной системе разграничения прав доступа рекомендуется также создание ролей:
  
  1. ПравоАдминистрирования
  2. ПравоВнешнегоПодключения
  3. ПравоЗапускаВнешнихОбработок
  Стандартных средств для проверки нет.- реализовать легко

Последовательности документов

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

Универсальные приемы и механизмы. Соглашения принятые при разработке

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

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

  Метаданные.Справочники[ИмяСправочника]

  Правильно:

  СправочникОбъект.Метаданные()

  Стандартных проверок нет – реализовать легко, но не всегда возможно сделать так как «правильно».

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

• Значения измерений в записях регистров, имеющих составной тип, и при этом содержащих в качестве значений пустое значение, перед записью должны приводиться к значению Неопределено.
  Под пустым значением подразумевается значение по умолчанию для данного типа - пустая ссылка для ссылочного типа данных; пустая строка, 0, Ложь, Дата('00010101') для соответствующих базовых типов.
  Стандартных проверок нет – сделать можно, но потребуется стандарт и тест.

• Для корректной работы конфигурации требуется, чтобы в информационной базе, еще до начала работы пользователя с конфигурацией, была уже заведена некая обязательная информация:
       - были заполнены конкретными значениями некоторые константы;
       - в справочники введены обязательные элементы;
  Также может быть предусмотрено первоначальное заполнение справочников необходимой информацией - для ускорения начал работы пользователя с конфигурацией.
  Конфигурация должна уметь определять, когда она запускается в первый раз, и выполнять необходимые действия. При этом обязательное первоначальное заполнение выполняется без дополнительных запросов у пользователя, а необязательное - с предварительным запросом
  Это требования 1С Совместимо – пункты 2.1.1-3

• При обновлении версии конфигурации зачастую требуется выполнять дополнительную обработку информационной базы. Конфигурация должна уметь определять первый запуск с новой версией, и производить необходимые действия по актуализации информации. Обработка запуска новой версии должна выполнять обновление с любой предыдущей версии. Отчет об изменениях в версиях должен также выдаваться в любой момент по запросу пользователя.
  Это требования 1С Совместимо – пункты 2.1.1-3

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

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

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

  Для каждого СтрокаТаблицыИсточника Из ТаблицаИсточник Цикл
       СтрокаТаблицыПриемника = ТаблицаПриемник.Добавить();
       ЗаполнитьЗначенияСвойств(СтрокаТаблицыПриемника,      СтрокаТаблицыИсточника);
  КонецЦикла;

  Стандартных проверок нет.

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

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

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

• При обращение к значению параметра сеанса необходимо учитывать, что, не смотря на то, что при это не выполняется обращение к БД, время обращения к  значению параметра все-таки значительно отличается от аналогичного времени обращения к переменной. Поэтому не рекомендуется выполнять многократное получение значения параметра сеанса – следует использовать "промежуточную" переменную
  На платформе 8.1 обращение к параметру сеанса оптимизировано, поэтому тезис об избавлении от глобальных переменных актуален.

Особенности при работе с сервером

• При разработке кода общего модуля и модулей объектов, которые должны быть доступны на сервере и во внешнем соединении, следует соблюдать следующие правила.
  
  Общее:
  Запрещено использование объектов имеющих тип данных, не доступный на сервере и во внешнем соединении:
       - ТабличныйДокумент
       - ТекстовыйДокумент
       - ДиалогВыбораФайла
       - все другие типы, использование которых невозможно на сервере 1С:Предприятие и во внешнем соединении.
  
  Запрещено использование средств, отвечающих за диалог с пользователем:
       - Предупреждение()
       - Вопрос()
       - методы работы с формами и прочие, для которых специально указано (в документации), что не доступны на сервере и/или во внешнем соединении.
  Исключением является метод Сообщить().(1Сэсовцы запрещают таймаут в диалоговых процедурах? но при этом априори не используют их в режиме сервера или внешнего соединения)
  Запрещается вызов экспортных процедур других общий модулей, у которых не установлен признак компиляции на сервере и во внешнем соединении.
  Участки кода, в которых используются конструкции не доступные на сервере или во внешнем соединении, должны выделяться соответствующими операторами препроцессора (#Если Клиент Тогда).
  Это все проверяется в тестах 0000 и 0009.

Механизмы в типовых конфигурациях

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

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

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

• Пользователь не сразу начинает работать с учетной системой быстро и эффективно. В самом начале работы происходит адаптация и обучение. В этот период пользователь учится вызывать конкретные функции учетной системы и осваивает последовательность ввода и обработки данных в ней.
  Пользователь работает медленно прежде всего по двум причинам:
       • ему трудно найти нужный пункт главного меню или кнопку панели инструментов
       • он не знает что и в какой последовательности необходимо отражать в учетной системе для достижения требуемого результата.
  Значительная часть пользователей не проходят предварительного обучение на курсах и не читают перед началом работы руководство пользователя. Они осваивают систему на практике, ориентируясь на примеры в демо-базе  и встроенную справку(мысль! Создание некой панели функции с набором функционала программы + основные справочники)
  Требуется ДЕМО-конфигурация и демо-панели как в типовых конфигурациях. А это – универсальная подсистема.

Отчеты

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

• В рамках конфигурации все табличные документы должны быть оформлены единообразно. Рекомендуется разделять оформление печатных и непечатных табличных документов.
  Табличные печатные документы должны иметь лаконично оформление
  Стандартных проверок нет.