Где собраны наиболее полные и подробные стандарты и правила от компании 1с

Обновлено: 07.07.2024

image

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

Особенности разработки

  1. «Объекты УП, УТ, КА» — объекты, входящие во все прикладные решения: Управление Торговлей, Комплексная Автоматизация, Управление Предприятием (русскоязычное название ERP).
  2. «Объекты УП, КА» — объекты, относящиеся только к конфигурациям Комплексная Автоматизация и ERP.
  3. «Объекты УП» — объекты, относящиеся только к решению ERP

Цифры после запятой

Версия продукта ERP состоит из четырех чисел, разделенных точками. Например — 2.1.3.117.

  • Первое число (редакция) в версии меняется крайне редко (например КА 1.х.х.х и КА 2.х.х.х разделяет почти 8 лет).
  • Второе число (подредакция) меняется примерно раз в год. В версии с новой подредакцией выпускается новая функциональность. Выпуск таких версий часто приурочивается к началу календарного года, чтобы у пользователей было достаточно времени на «переезд» на новую версию.
  • В версиях с новым третьим числом (релиз) развивается существующая функциональность; новый релиз выходит примерно раз в два-три месяца.
  • Версии с обновленным четвертым числом (исправительные сборки) содержат в себе только исправления ошибок и обновления для соответствия текущему законодательству. Выходят каждые две недели.
  1. 2.1.3.X – Поддерживаемый релиз предыдущей подредакции. Будет выпускаться до конца 2016 года. В этой версии идет только исправление ошибок и правки для соответствия текущему законодательству.
  2. 2.2.1.X – Текущий релиз текущей подредакции. В нем новая функциональность подредакции. Для него до выпуска релиза 2.2.2.X, будут выпускаться исправительные сборки.
  3. 2.2.2.X – Развитие функциональности текущей подредакции. Именно этот релиз активно разрабатывается.

Учитывая, что из каждой ветки ERP получаются, помимо ERP, еще 3 решения – КА, УТ и УТ Базовая – получаем 12 версий продуктов, находящихся в 12-ти разных хранилищах.
В ходе разработки мы имеем до 4 горизонтов планирования, например:

  1. 2.1.3 (поддерживается), решаем, какие ошибки правятся, какие проекты, связанные с изменением законодательства, будем реализовывать. Будут реализованы только те изменения, которые вступят в силу в 2016 году. Горизонт – до конца 2016 г.
  2. 2.2.1 (поддерживается) – исправляются «внешние» ошибки + изменения законодательства, вступающие в силу до выхода 2.2.2. Горизонт – до выхода 2.2.2.
  3. 2.2.2 (активно разрабатывается) — исправляются «внешние» ошибки + найденные нами ошибки + реализуется новая функциональность. Горизонт – до выхода 2.2.3
  4. 2.2.3 (планируется). Если проект большой, то он может сразу разрабатываться на эту версию (и не войдёт в предыдущую). Горизонт – до выхода 2.2.4 или до конца 2017 года.

Использование продукта «1С:Система проектирования прикладных решений» в разработке ERP

  1. Запрос от партнера или клиента. Такие запросы мы собираем, в частности, на партнерских семинарах; путем голосования среди партнеров мы выделяем наиболее приоритетные из них.
  2. Запрос может возникнуть в ходе пилотного проекта по внедрению новой версии в том случае, если у клиента возникло важное для него пожелание.
  3. Запрос от нашей службы техподдержки (точнее, запрос от партнера или клиента, прошедший через нашу техподдержку), запрос с нашего партнерского форума или от нашего аккаунт-менеджера (который сопровождает важного для нас клиента/клиентов).
  4. Запрос от команды разработки платформы 1С:Предприятие. Платформенная команда просит команду разработки ERP (и других типовых конфигураций) использовать новую платформенную функциональность – например, интерфейс Такси, отказ от модальных окон, отказ синхронных вызовов и т.д.
  5. Рефакторинг, оптимизация архитектуры, улучшение юзабилити.

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

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

Вот, что открывается – это модель рабочего места в IDEF0:

Можно и наоборот – изучать функциональную модель и из нее открывать формы рабочих мест. Такой режим можно использовать при изучении работы программы.
Важный момент – открывается не СППР, открывается форма внутри ERP, куда подгружаются данные из СППР. Т.е. интеграция «бесшовная» (пользователь ее не видит). Этот прием применяется при интеграции и с другими продуктами. Например, с 1С:Документооборот (можно работать не выходя из ERP с почтой, задачами, бизнес-процессами, которые работают в другой базе).

Как мы разрабатываем ERP: 6 контрольных точек проекта

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

Тим-лид заводит технические проекты в СППР списком на релиз. В каждом проекте расписываются цели, указываются реализуемые требования. Список перед началом работы над релизом обсуждается с руководителем разработки. Собственно при открытии проекта совещаний не проводят – просто проект в СППР посылают на открытие.
Команда проекта приступает к разработке концепции.

Точка 2. Согласование концепции

Для согласования концепции проводится онлайн или офлайн встреча, в которой участвуют ответственный за проект, тим-лид, руководитель разработки, вовлеченные в проект специалисты. Обычно к этому этапу у ответственного за проект готов «крупноблочный» концепт, который дошлифовывается в ходе встречи. Также обсуждаются (и прописываются в СППР) сценарии, описание пользовательского интерфейса. Если требование родилось из запроса партнеров или клиентов, то материалы проекта (концепции, сценарии, UI) могут быть отправлены партнеру/клиенту для оценки решения.
В процессе встречи согласуется трудоемкость создания прототипа (обычно создание прототипа занимает до 5 рабочих дней). Команда приступает к созданию прототипа.

Точка 3. Согласование прототипов
  • Согласование правильности описания проекта в СППР (в частности, отслеживается, что все задачи на предыдущих контрольных точках проекта выполнены).
  • Какие новые объекты метаданных (справочники, документы и т.д.) будут добавляться в решение
  • Какие изменения будут делаться в уже существующих объектах метаданных
  • Согласование планов обменов данными с другими решениями(будут ли новые/измененные данные участвовать в обмене данными с другими приложениями, и если да – то как именно)
Точка 4. Согласование разработанного решения

Решение разработано, подготовлена презентация (в формате PowerPoint). Часто проводится очное совещание с «живым» показом разработанного решения.
Если проект публичный (опубликован в доступном партнерам списке планов на сайте 1С), то презентация выкладывается на партнерском форуме в разделе ERP, чтобы все заинтересованные партнеры могли ознакомиться и высказать свои замечания.

Точка 5. Тестирование и аудит проекта
Точка 6. Окончание проекта

Закрываем проект в СППР – присваиваем ему статус «Выполнено».

Выпуск версии

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

Исправительные сборки

Каждые две недели мы выпускаем исправительные сборки к версиям; на сегодня это 2.1.3.x, после выхода релиза 2.2.1 будут выпускаться 2 исправительные сборки — 2.1.3.x и 2.2.1.х. От регистрации ошибки до появления ее в исправительном релизе у нас проходит менее двух недель; наша статистика показывает, что среднее время от обращения клиента с ошибкой в ERP в поддержку до выхода ее исправления в исправительной сборке на сегодня – 9 дней.

Разветвленная разработка

image


В групповой работе над ERP мы стараемся использовать средства, предоставляемые нам платформой 1С:Предприятие. Конфигурации хранятся в хранилище конфигураций, при чекине новой функциональности в ветки используется стандартный механизм поставки и поддержки. Все операции автоматизируются по максимуму; в случае, если объекты менялись только на стороне разработчика – объединение кода происходит без участия программиста. Если для объединения исходников нужно вмешательство разработчика, обычно мы используем встроенные возможности платформы. Но есть также возможность вызова сторонних инструментов сравнения/объединения из инструментов платформы (например, KDiff3 или Araxis). Кстати, эта фича – вызова сторонних инструментов сравнения/объединения — была добавлена в платформу по запросу именно команды разработки ERP.

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

Эталон кода 1С

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

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

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

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

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

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

Если вы только начинаете программировать в 1С или просто хотите систематизировать свои знания - попробуйте Школу программирования 1С нашего друга Владимира Милькина. Пошаговые и понятные уроки даже для новичка с поддержкой учителя.
Попробуйте бесплатно по ссылке >>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • ТабличныйДокумент
  • ТекстовыйДокумент
  • ДиалогВыбораФайла
  • все другие типы, использование которых невозможно на сервере 1С:Предприятие и во внешнем соединении.

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

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

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

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

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

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

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

Сергей Лунев

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

Среда разработки и базовые механизмы

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

Принципы работы системы 1С:Предприятие 8.3

Перечислим основные и показательные:

Два режима работы с информационной базой: файловый и клиент-серверный

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

Для больших же компаний целесообразно использовать серверный вариант хранения в реляционных базах данных, но такой режим работы потребует усилий по установке и администрированию. Этот вариант реализован на механизме трехуровневой архитектуры, он использует СУБД и кластер серверов 1С, которые успешно решают проблему надежности, быстродействия и производительности.

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

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

Рис.2 Система позволяет осуществлять переход из одного режима работы на другой

Рис.2 Система позволяет осуществлять переход из одного режима работы на другой

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


Клиентские приложения

У платформы 1С:Предприятие 8.3 есть несколько клиентских приложений. Их основное предназначение — организация интерфейса, взаимодействие с пользователем, они отображают данные и дают пользователю возможность вносить изменения.

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

Ниже представлена архитектура приложений для файлового и клиент-серверного вариантов работы.

Рис.3 Архитектура приложений для файлового варианта работы

Рис.3 Архитектура приложений для файлового варианта работы

Рис.4 Архитектура приложений для клиент-серверного варианта работы

Рис.4 Архитектура приложений для клиент-серверного варианта работы

Объектно-реляционная модель базы данных

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

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

Внутренний язык программирования

Он схож с таким языком, как Visual Basic. Особенности языка:

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

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

Основные и наиболее интересные из них:

Собственный язык запросов

Запросы представляют собой мощный инструмент для получения данных из базы данных в удобном виде. На выбранные данные посредством языка запросов можно наложить фильтры, сгруппировать, отсортировать, но изменять данные при их помощи нельзя. Запросы являются основой для построения отчетов. Синтаксис языка запросов 1С похож на SQL, так как основан на нем. Существует визуальный помощник для составления текста запроса – «Конструктор запроса». Текст запроса можно написать вручную, но нередко он может состоять из нескольких сотен строк, поэтому визуальное представление текста запроса намного облегчает эту задачу. Конструктор запроса выглядит следующим образом:

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

Система компоновки данных (СКД)

Это инструмент, предназначенный для создания отчетов. Разработчик при помощи данного средства декларативно описывает поведение отчета, при этом программного описания зачастую не требуется. Рутинную работу запроса к базе данных, вывод данных в макет и т.д. сделает СКД. Еще одна важная возможность СКД — различные варианты отчетов. На основании одного и того же источника данных можно получить несколько вариантов, как именно эти данные будут представлены пользователю.

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

Мобильная платформа

Данная технология позволяет создавать приложения для мобильных устройств под управлением операционных систем Android, iOS, Windows Phone. Мобильное приложение, установленное на устройстве, представляет собой комбинацию мобильной платформы и мобильной конфигурации. Информационная база на мобильном устройстве содержит аналог файловой базы данных (для хранения данных, с которыми работает пользователь) и мобильное приложение (программный код, исполняющийся на мобильном устройстве).

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

Система взаимодействий

Процесс разработки

Что же представляет собой профессиональная разработка на 1С:Предприятие 8.3? Для начала определимся, что разработка – это не синоним программирования. Проектирование и конструирование системы – интересный, творческий процесс, который включает в себя множество аспектов. Само написание программного кода – один из инструментов разработки и не является ключевым.

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

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

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

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

Разработка в системе 1С:Предприятие 8.3 – процесс многогранный, в большей мере требующий навыков аналитики и понимания бизнес-процессов предприятия. А среда разработки – очень мощный и гибкий инструмент, который предоставляет разработчику множество возможностей для успешной и быстрой автоматизации деятельности предприятия. Аналогов данной системы в настоящий момент в России нет. И программная линейка 1С является стандартом для работы различных организаций разных направлений бизнеса. Наша компания предоставляет услуги сопровождения, внедрения и доработки 1С в Москве. Если у вас остались вопросы, свяжитесь с ним, мы с радостью вам поможем.

Анна Викулина

Внедрение 1С

Быстрое внедрение, внедрение по Agile, проектное внедрение. ISO 9001:2015. Оценка стоимости - бесплатно!

Переход на 1С 8

  • Переход на актуальные версии программ 1С;
  • Опыт более 17 лет;
  • Сертифицированные специалисты 1С;
  • Оперативность

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

Перед подробным разбором достоинств новейшей версии, системных требований и технических нюансов, уделим внимание общему пониманию, что же такое 1С.

Зачем обновлять конфигурации 1С Предприятие 8.3?

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

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

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

На клиентские ПК системные требования выдвигаются следующие:

  • Процессор с частотой более 1,8 ГГц;
  • Оперативная память объемом более 512 Мб;
  • Жесткий диск емкостью более 40 Гб.

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

  • Intel Pentium 4 с частотой более 2,4 ГГц;
  • Более 1 Гб оперативной памяти;
  • Жесткий диск в зависимости от размеров базы, но не менее 40 Гб.

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

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

  • Выполняется обновление программного обеспечения;
  • Выполняются доработки программного обеспечения собственными или внешними программистами;
  • База данных наполняется данными в процессе промышленной эксплуатации;
  • Изменяется конфигурация и архитектура локально-вычислительной сети и ИТ-оборудования;
  • И многое другое.

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

Многие клиенты 1С не ограничиваются Бухгалтерией или УТ – после успешного внедрения и оценки результата компания решает автоматизировать другие области учета. Программы на базе 1С Предприятие 8.3 помогут решить любую задачу: автоматизировать узкий участок или всю деятельность компании. Учитывая постоянное развитие, выбрать и внедрить 1С на базе платформы 8.3 эффективнее, чем поддерживать многочисленные программы на разных языках программирования.

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

  • Уникальный, подстраиваемый под конкретного пользователя интерфейс «Такси»;
  • Улучшение производительности функционирования и разработки на платформе 1С 8.3;
  • Оптимизация многих механизмов интерфейса и клиентской части;
  • Новые инструменты для разработчиков;
  • Мобильная платформа 1С.

Улучшение существующего функционала 1С в релизе 8.3

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

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

  1. Добавлены два сервиса: сервис лицензирования, отвечающий за распределение программных лицензий клиентским сеансам, позволит более свободно конфигурировать кластер серверов и менять его параметры; сервис внешнего управления клиентскими сеансами, отвечающий за регулирование подключений пользователей к конкретной информационной базе на сервере. Эти сервисы также помогут снизить затраты ресурсов;
  2. Оптимизировано распределение загруженных процессов на сервере или кластере серверов и повышена отказоустойчивость;
  3. Созданы профили безопасности в кластере серверов. Они отвечают за настройку разрешений на потенциально опасные действия. К ним 1С относит открытие внешних отчетов и обработок, запуск приложений и обращение к ресурсам из Интернета;
  4. Обновление клиентских приложений через Интернет;
  5. Модернизация реструктуризации информационных баз с целью сокращения времени на монопольный доступ разработчика к базе.

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

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

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

Читайте также: