Доработка типовых конфигураций 1с. Внешние отчеты и обработки

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

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

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

1. Концепция минимизации «разрушений» типовой конфигурации

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

2. Комментирование изменений кода:

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

//++ VION 20.07.2016 0001234 Доработка на старте //-- VION 20.07.2016

• //++ — начало блока
• //— — конец блока
• VION — имя (или ник) разработчика
• 0001234 — номер задачи по трекеру, ставится только в открывающем комментарии, чтобы в результаты глобального поиска по номеру задачи каждое изменение кода попадало только один раз
• Доработка на старте — произвольный комментарий, используется при необходимости, но если номер задачи отсутствует, то краткий пояснительный текст обязателен

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

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

2.1 Вставка кода

Пример :

Процедура ПриОткрытии() Если ЭтоНовый() Тогда ЗаполнитьПоляПоУмолчанию(); КонецЕсли; НастроитьЭлементыФормы(); //++ VION 20.07.2016 0001234 НастроитьДополнительныеЭлементы(); //-- VION 20.07.2016 УстановитьВидимостьПолей(); КонецПроцедуры

2.2 Удаление кода

Пример :

Процедура ПриОткрытии() //++ VION 20.07.2016 0001234 //Если ЭтоНовый() Тогда // ЗаполнитьПоляПоУмолчанию(); //КонецЕсли; НастроитьДополнительныеЭлементы(); //-- VION 20.07.2016 УстановитьВидимостьПолей(); КонецПроцедуры

2.3 Изменение существующего кода

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

Пример :

Процедура ПриОткрытии() Если ЭтоНовый() Тогда //++ VION 20.07.2016 000123 //ЗаполнитьПоляПоУмолчанию(); НастройкаЗаполненияПолей = ПолучитьНастройкуЗаполненияПолей(); ЗаполнитьПоляПоУмолчаниюРасширенная(НастройкаЗаполненияПолей); //-- VION 20.07.2016 КонецЕсли; НастроитьЭлементыФормы(); УстановитьВидимостьПолей(); КонецПроцедуры

2.4 Добавление процедур и функций в модуле

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

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

Пример :

//++ VION 20.07.2016 000123 Перем мНастройкаЗаполненияПолей; Процедура ДоработатьФормуПрограммно() ... ... КонецПроцедуры //-- VION 20.07.2016 //++ VION 20.07.2016 000123 Процедура ДатаОтгрузкиОбработкаВыбора() ... ... КонецПроцедуры //-- VION 20.07.2016

Данное правило позволяет легко переносить изменения в модуле в «попроцедурном сравнении» конфигураций.

Если же закрывающий комментарий поставить на следующей строке:

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

3. Добавление объектов верхнего уровня

Имена объектов верхнего уровня, создаваемых в конфигурации, обязательно должны начинаться с префикса вашей компании или отдельного префикса проекта. Как правило, он состоит из двух-трех заглавных букв и подчёркивания, например АБ_ . Соответственно, создаваемые объекты будут называться АБ_НовыйСправочник , АБ_НовыйРегистрСведений , АБ_НовыйДокумент и т. д.

Синонимы (видимые пользователю имена) добавленных объектов верхнего уровня должны начинаться с префикса, заключённого в круглые скобки: (АБ) . В результате эти объекты будут визуально выделяться в списках и сгруппировано располагаться в их начале (что облегчает и тестирование, и использование).

В комментарии создаваемого объекта следует указать имя разработчика, дату и номер задачи, по аналогии с добавляемого кода, но без знаков «++». Это обеспечит привязку объекта конфигурации к задаче, отыскиваемую глобальным поиском.

Пример : Создать справочник «Проекты».

Действия разработчика : в конфигурации создается следующий справочник:

• Имя: АБ_Проекты
• Синоним: (АБ) Проекты

4. Добавление подчиненных объектов

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

4.1 Добавление подчиненных объектов в типовые объекты конфигурации

Подчинённые объекты, добавляемые в существующие (типовые) объекты конфигурации, должны снабжаться префиксами : АБ_ДополнительныйРеквизит , АБ_НоваяТабличнаяЧасть , АБ_ФормаНастроекПользователя , АБ_МакетСпециальнаяНакладная . Но при этом синонимы таких подчинённых объектов создаются без префикса .

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

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

Действия разработчика : в конфигурации создается следующий реквизит:

• Имя: АБ_Проект
• Синоним: Проект
• Комментарий: // VION 20.07.2016 000123

4.2 Добавление подчиненных объектов в объекты, добавленные в рамках проекта

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

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

Пример : Создать реквизит «Ответственный» у справочника «(АБ) Проекты».

Действия разработчика : Если задача отличная от той, в которой создавался справочник «(АБ) Проекты», то в конфигурации создается следующий реквизит:

• Имя: Ответственный
• Синоним: Ответственный
• Комментарий: // VION 20.07.2016 000456

5. Добавление предопределенных элементов

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

5.1 Добавление предопределенных элементов в типовые объекты конфигурации

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

Пример: В план счетов «Хозрасчетный» добавить предопределенный счет 10.15 — Бланки строгой отчетности.

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

• Имя: АБ_БланкиСрогойОтчетности
• Код: 10.15
• Наименование: Бланки строгой отчетности

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

5.2 Добавление предопределенных элементов в объекты, добавленные в рамках проекта

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

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

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

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

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

7. Использование подписок и их строгая структура

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

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

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

Пример : При проведении документа «Авансовый платеж», делать записи в регистр накопления «(АБ) Затраты по проектам».

Действия разработчика :

1. Создать подписку «АБ_ДокументыОбработкаПроведения» (если такая подписка не была создана раннее), в качестве источника указать все документы, событие — «ОбработкаПроведения».

2. Создать общий серверный модуль «АБ_ДокументыОбработкаПроведения».

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

4. Модуль документа «Авансовый платеж» должен остаться без изменений.

8. Редактирование форм

8.1 Редактирование форм типовых объектов

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

Пример : На основную форму документа «Авансовый платеж», добавить реквизит «(АБ) Проект».

Действия разработчика : В обработчике формы «ПриСозданииНаСервере» добавить процедуру «ДоработатьФормуПрограммно()». В данной процедуре добавить нужный элемент в элементы формы.

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

В типовых конфигурациях на базе БСП 2, уже есть специальный функционал для данных целей:

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

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

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

8.2 Редактирование форм объектов, добавленных в рамках проекта

Формы объектов, добавленных в рамках проекта (т. е. имеющие в своем названии префикс) редактируются обычным способом.

9. Принципы работы с ролями

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

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

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

10. Внешние отчеты и обработки

Большинство доработок в системе может быть выполнено с помощью механизма Дополнительных отчетов и обработок.

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

Помогла ли вам данная статья?

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

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

Что обычно делают нового в 1С?

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

Примеры изменений в 1С 8.3:

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

Цена часа работы специалиста 1С

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

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

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

Существует два способа решения проблемы:
Перестроить бизнес под возможности 1С.
Доработать 1С под потребности бизнеса.

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

Преимущества 1С
У программ на базе 1С:Предприятие (7.7, 8.1, 8.2, 8.3) нет проблемы с изменением исходного кода, поэтому любой программист 1С может доработать ее под ваши потребности.

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

Примеры наиболее частых доработок в 1С:
Доработка печатных форм;
Доработка отчетов;
Изменение прав пользователей;
Разработка обработок для автоматизации каких-либо действий и процедур;
Разработка новых справочников и документов;

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

Конечно, чтобы минимизировать доработки, нужно выбирать систему, которая максимально подходит именно вам, ну а если такой нет (что случается довольно часто), вам потребуются доработка 1С! Компания W1C готова помочь Вам в доработке 1С !
Компания W1C имеет опыт комплексного внедрения программных продуктов "1С" на предприятиях различных видов деятельности, таких как производственные предприятия машиностроения, пищевой, мебельной и фармацевтической промышленности, бюджетные учреждения, финансово-кредитные организации, аптеки, автосалоны, СТО, предприятия оптовой и розничной торговли и др.

Ну а всем остальным, добро пожаловать под кат.

Правила и приемы доработки типовых конфигураций 1С для облегчения их дальнейшей поддержки и обновления

Итак, когда мы делаем некоторый проект (под словом «Мы» я понимаю всех людей, которые заняты в автоматизации бизнес-процессов), то надеемся, что потом он плавно перетечет в поддержку. Как правило, если все выполнено хорошо и заказчик доволен, так и происходит.

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

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

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

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

1. Концепция минимизации «разрушений» типовой конфигурации

Первое - это даже не правило, это некая концепция минимизации «разрушений» типовой конфигурации.

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

2. Комментирование изменений кода

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

У нас в компании мы используем следующую схему:

• В начале изменения находится открывающий комментарий (начинается со знаков //++ )
• В конце - закрывающий комментарий (начинается со знаков //-- )
• А те изменения, который выполнил разработчик, находятся в середине .

Это - обязательное правило для любых изменений.

У открывающего и закрывающего комментария указывается метка изменения . Она содержит в себе следующие составляющие :

• Префикс проекта - по умолчанию мы используем ФТО
• Доменное имя разработчика . Оно формируется очень удобно: компания большая, распределенная, и если ты разработчика не знаешь, но его надо о нем что-то спросить, можно взять его ник из этой метки, поставить справа @fto.com.ru и отправить ему письмо, чтобы таким образом с ним связаться.
• Дальше идет дата изменений . Когда изменения идут в рамках нескольких задач, эти связки комментариев могут быть вложенными одна в другую, и не всегда понятно, к какому открывающему блоку относится этот закрывающий комментарий, поэтому мы ориентируемся на дату. Кроме этого, по дате сразу видно, когда была сделана модификация: три года назад, полгода назад или вчера.
• Затем идет номер задачи , который ставится только в открывающем комментарии . Почему только там? Чтобы при глобальном поиске по номеру задачи в выборку попадало только начало изменений кода, от которого дальше уже можно вниз смотреть, иначе будет двоиться. Например, при передаче задачи на code-review очень удобно искать именно по метке.

Примеры

Вот так выглядит вставка кода:

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

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

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

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

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

3. Добавление объектов верхнего уровня

Следующее правило - это добавление в конфигурацию объектов верхнего уровня (справочников, документов, регистров и т.д.).

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

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

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

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

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

Итак, подытожим:

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

4. Добавление подчиненных объектов

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

Здесь нужно сразу выделить две ситуации, куда мы добавляем подчиненный объект:

• В типовой объект конфигурации
• Или в какой-то объект, который был добавлен ранее в рамках проекта.

Рассмотрим каждую из этих ситуаций отдельно.

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

• Имена должны начинаться точно так же с префикса . За счет этого мы добиваемся уникальности имени и визуально тоже всегда понятно, что это - наш объект.

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

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

Итак, давайте подытожим, как происходит добавление подчиненных объектов в типовые объекты конфигурации:

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

А если мы добавляем подчиненные объекты в те объекты, которые были ранее добавлены в рамках проекта и уже содержат в своем имени префикс, то:

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

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

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

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

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

Если это правило объединить для обоих случаев и «разложить по полочкам», то получится следующая табличка:

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

5. Добавление предопределенных элементов

Следующее правило - добавление предопределенных элементов.

Здесь точно так же можно выделить две ситуации:

• Когда мы добавляем предопределенный элемент в типовой объект конфигурации (в справочник, в план видов характеристик)
• И когда мы добавляем предопределенный элемент в объект, добавленный в рамках проекта.

Если мы добавляем предопределенный элемент в типовой объект конфигурации ,

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

А если мы добавляем предопределенные элементы в объекты, добавленные в рамках проекта , то

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

Итак, если провести аналогию с предыдущей таблицей, то:

• Предопределенные элементы для типовых объектов добавляются с префиксом,
• А все остальные - по общим правилам, никаких специальных добавлять префиксов не надо.

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

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

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

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

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

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

• ФТО_ОбщегоНазначенияКлиент,
• ФТО_ОбщегоНазначенияСервер,
• ФТО_ОбщегоНазначениеГлобальный,
• ФТО_РегламентныеЗаданияСервер
• И т.д.

А какие-то большие отдельные задачи можно (и, наверное, нужно) выносить в отдельные общие модули .

7. Использование подписок и их строгая структура

Следующее правило - это использование подписок и их строгая структура. В чем его суть?

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

• Перед записью
• При записи
• И т.д.

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

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

1. Для всех однотипных событий в системе добавляется только одна подписка . Например, если мне нужно для различных справочников в событии «Перед записью справочника» задействовать свой алгоритм, то для всех этих справочников я использую только одну добавленную подписку «Перед записью справочника».
2. В источнике выделяются все объекты в рамках этого класса (например, все справочники)
3. Для добавленной подписки создается отдельный модуль, который называется точно так же (просто для удобства).
4. В основном обработчике события определяется условие, анализирующее вид объекта (вид справочника).
5. И уже в зависимости от вида объекта выполняются те или иные действия .

Могу показать на примере. Предположим, есть такая задача: при проведении документа «Авансовый отчет» делать записи в добавленный ранее регистр накопления.

Сначала мы добавляем общий модуль ФТО_ДокументыОбработкаПроведения по всем правилам.

• В качестве источника указываем ДокументОбъект (все документы);
• В качестве обработчика - наш добавленный выше модуль.

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

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

В результате, порядок действий для создания подписки такой:

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

8. Редактирование форм

Следующее правило - редактирование форм.

Здесь точно так же выделим два момента, две ситуации:

• Когда мы редактируем типовые формы;
• И когда мы редактируем формы, добавленные в рамках проекта.

Первая ситуация - это редактировани е типовых форм, форм типовых объектов . Это самый спорный пункт правил. В свое время, еще во времена обычных форм, когда проекты в основном делались на УПП, у нас было много дискуссий по поводу того, что делать с формами. Какие были варианты?

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

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

В конфигурациях на базе БСП 2 (таких, как ERP, Бухгалтерия и т.д.) добавился обработчик СобытияФорм.ПриСозданииНаСервере() , который среди прочего, заходит еще и в переопределяемый модуль .

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

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

Кроме того, в конфигурациях на базе БСП 2 переопределены еще и другие обработчики форм - такие как ПриЧтенииНаСервере(), ПередЗаписьюНаСервере() и т.д. И в этих обработчиках также можно активно использовать переопределение вызываемых процедур. Тем более что поставщиком переопределяемый модуль теоретически не меняется, и там можно без боязни конфликтов писать свой код.

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

9. Принципы работы с ролями

И последнее правило - это принципы работы с ролями.

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

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

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

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

Дополнительные объекты и приемы, облегчающие жизнь

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

1. Самоидентификация тестовых баз

Первый прием - это самоидентификация тестовых баз.

Суть в том, что:

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

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

Таким образом, мы делаем изменение данных в информационных базах более безопасным.

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

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

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

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

2. Обработка инициализации

Следующий прием - обработка инициализации.

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

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

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

На схеме этот порядок работы показан так:

• Старт системы
• Сравнение версии константы с версией обработки .
• Если не совпадает , выполняются последовательно все необходимые обработчики ,
• Устанавливается новое значение константы .

В результате везде, во всех базах данные обновлены.

3. Справочник предопределенных значений

Следующий прием - это справочник предопределенных значений.

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

Какие тут есть варианты реализации?

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

Этот справочник содержит в себе только один реквизит с типом СправочникСсылка (ссылка на все справочники).

Если мне в рамках задачи нужно обратиться к какому-то элементу, я в этот справочник добавляю предопределенный элемент (например, Контрагент_Агроимпульс)

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

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

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

4. Просмотр временных таблиц в отладчике

Ну и последний прием - это просмотр временных таблиц в отладчике.

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

• И назвать как-нибудь коротко, например ВТ()

В этом случае:

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

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

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

Заключение

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

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

Компания 1С прочно закрепились в нише программ для автоматизации деятельности предприятий. «Бухгалтерия предприятия », «Управление торговлей », «Зарплата управление персоналом » и т.д. – стали визитными карточками компании и успешно применяются как в маленьких, так и больших предприятиях.

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

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

Проблема

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

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

Документирование, инструменты

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

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

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

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

Конфигурирование

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

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

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

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

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

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

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

Внешние печатные формы

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

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

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

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

Функция «СведенияОВнешнейОбработке » описывает структуру с базовой информацией по обработке. Перечисленные сведения необходимо для успешной регистрации в механизме внешних печатных форм. Непосредственная регистрация происходит через добавление элемента в справочник «Дополнительные отчеты и обработки» (см. рисунок 2).

Особое внимание стоит обратить на следующие свойства:

• МассивНазначений. Содержит название объектов метаданных, для которых будет регистрировать печатная форма. Допускается несколько вариантов указания объектов: «Документ.ПриходныйКассовыйОрдер», «Документ.*». Последняя запись подразумевает все документы, доступные в системе.
• Вид. Определяет вид внешней обработки. Обработки разных видов регистрируются по-разному. Для печатных форм указываем «ПечатнаяФорма», остальные доступные виды привел в комментариях.
• Наименование. Название обработки в системе.
• Идентификатор. Используется в нескольких местах, рекомендуется присваивать осмысленное имя. Чаще всего здесь указывает имя обработки, например: «РогаИКОпыта_ФормированиеМакетаКассовогоОрдера».
• Модификатор. Если в качестве макета используется табличный документ, то указываем «ПечатьXML».

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

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

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

• Имя для сохранения параметров печати. Чаще пользуются шаблоном: «ПАРАМЕТРЫ_ПЕЧАТИ_ИмяПечатнойФормы».
• Макет. В методе «ПолучитьМакет» требуется указать имя макета.

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

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

Обработки для заполнения

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

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

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

Листинг 1. Заготовка для обработки заполнения

ПараметрыРегистрации = ДополнительныеОтчетыИОбработки.СведенияОВнешнейОбработке("2.1.2.1"); ПараметрыРегистрации.Вид = ДополнительныеОтчетыИОбработкиКлиентСервер.ВидОбработкиЗаполнениеОбъекта(); ПараметрыРегистрации.Назначение.Добавить("Документ.КонтСтраховойПолис"); ПараметрыРегистрации.Наименование = НСтр("ru= "Заполнение способов урегулирования убытков""); ПараметрыРегистрации.БезопасныйРежим = Ложь; ПараметрыРегистрации.Информация = "Демонстрирует механизм создания обработок заполнения"; ПараметрыРегистрации.Версия = "1.0.1"; НоваяКоманда = ПараметрыРегистрации.Команды.Добавить(); НоваяКоманда.Представление = НСтр("ru = "Заполнить способами урегулирования убытков""); НоваяКоманда.Идентификатор = "ЗаполнитьСпособыУрегулированияУбытков"; НоваяКоманда.Использование = ДополнительныеОтчетыИОбработкиКлиентСервер.ТипКомандыОткрытиеФормы(); Возврат ПараметрыРегистрации;

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

Рассмотренной функции достаточно для создания каркаса обработки-заполнения. Дальше все зависит от решаемой задачи. Если требуется создать форму обработки и наладить связь с объектом заполнения, вам потребуется описать в форме несколько параметров:

• ОбъектыНазначения (Произвольный) – массив ссылок на объекты заполнения.
• Идентификатор (Строка) – идентификатор команды.
• ДополнительнаяОбработкаСсылка (СправочникСсылка.ДополнительныеОтчетыИОбработки).

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

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

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

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

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

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

Для создания нового расширения нажимаем кнопку «Добавить» и в появившемся окне заполним поля (рисунок 4):

• Имя. Стандартные правила именования объектов метаданных 1С.
• Синоним.
• Префикс. Дополнительное значение, которое будет автоматически добавляться для всех созданных сущностей в расширении.

Нажимаем “Ok” и перед вами отобразится дополнительное дерево конфигурации (рисунок 5).

Принцип работы с деревом конфигурации расширения мало чем отличается от работы со стандартным деревом конфигурации информационной базы. Отличие заключается в ограничениях (http://its.1c.ru/db/v839doc#bookmark:dev:TI000001513).

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

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

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

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

Я расширил документ «КонтСтраховойПолис » (добавил табличную часть и новые реквизиты), а затем добавил основную форму документа в созданное расширение (контекстное меню «Добавить в расширение»).

Вместе с формой будут перенесены связанные реквизиты, а также ряд других объектов (рисунок 6).

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

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

Идеи для расширений

Не стоит думать о расширениях, как о своеобразных костылях для модификации объектов. Это полноценная система плагинов с большим потенциалом на развитие. Уже сегодня расширения позволяют создавать: подсистемы, общие модули, роли, общие формы, обработки, отчеты, HTTP-сервисы, WS-ссылки, XDTO-пакеты. Перечисленных объектов хватит для решения многих реальных задач.

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

Аналогичным образом обстоят дела с интеграцией КИС и CMS. Стандартные механизмы обменов в виде громоздкого CommerceML – не самый удобный и быстрый способ выгружать номенклатуру на сайт. Расширения от разработчиков CMS могут запросто решить эту проблему и не создать пользователю типовых решений проблем с последующим обновлением.

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

На что еще способны расширения

О механизме расширений конфигурации можно говорить долго и написать отдельную статью. Технология постоянно развивается и пополняется новыми возможностями. Наиболее интересные новинки произошли с релизом платформы 8.3.9. Свет увидела первая концепция перехвата/подмена функций в модулях (расширение модулей).

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

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

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

&Перед, &Вместо, &После. Например: &Вместо ("РассчетСтраховойПремии") Функция РассчетСтраховойПремииСДополнительнымиРисками(Параметр) // Какой-то код КонецФункции

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

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

Подписки на события

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

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

Программная доработка форм

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

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

Модификация ролей

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

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

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

Не ленитесь

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

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