Д.И. Гончаров, Е.Ю. Хрусталева

Решение специальных прикладных задач в «1С:Предприятии 8.2»

Д.И. Гончаров, Е.Ю. Хрусталева

Решение специальных прикладных задач в «1С:Предприятии 8.2»

Электронная книга в формате ePub; ISBN 978-5-9677-3429-8.

Версия издания от 08.04.2024.

Электронный аналог издания "Решение специальных прикладных задач в «1С:Предприятии 8»"
(ISBN978-5-9677-1611-9, М.: ООО "1С-Паблишинг", 2024; артикул печатной книги по прайс-листу фирмы "1С": 4601546092694; по вопросам приобретения печатных изданий издательства "1С-Паблишинг" обращайтесь к партнеру "1С", обслуживающему вашу организацию, или к другим партнерам фирмы "1С".)

---

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

© ООО «1С-Паблишинг», 2024
© Оформление. ООО «1С-Паблишинг», 2024

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

---

Фирма "1С"
123056, Москва, а/я 64, Селезневская ул., 21.
Тел.: (495) 737-92-57.
1c@1c.ru, http://www.1c.ru/
Издательство ООО "1С-Паблишинг"
127434, Москва, Дмитровское ш., д. 9.
Тел.: (495) 681-02-21.
publishing@1c.ru, http://books.1c.ru/

Введение

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

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

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

При подготовке материала были использованы различные источники информации:

• опыт преподавания на учебных курсах по платформе и прикладным решениям «1С:Предприятия 8»;
• опыт внедрения прикладных решений;
• опыт, накопленный разработчиками фирмы «1С»;
• материалы информационно-технологической поддержки (ИТС);
• материалы форума партнеров-разработчиков на сайте http://partners.v8.1c.ru;
• общение на партнерских семинарах, проводимых фирмой «1С».

Глава 1. Механизм бизнес-процессов

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

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

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

Другим примером может являться операция продажи товара оптовому покупателю. В данной операции можно выделить следующие этапы:

• выписка заказа покупателя,
• получение оплаты за товар,
• сборка заказа на складе,
• отгрузка товара.

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

Компания стремительно набирает обороты (огромное спасибо сотрудникам отдела рекламы). Для того чтобы рост организации в какой-то момент не остановился, необходимо заранее подумать о своевременном наборе (и обучении) сотрудников, расширении штата. И вот он сам вопрос: «Кого набирать?». Набрать сотрудников в отдел рекламы… Но если не хватает персонала на выписке счетов, то это может привести не к росту, а, наоборот, к падению оборотов компании (за организацией может закрепиться репутация «не желающих даже счет выписать»). Набрать менеджеров по выписке счетов… Но если сотрудники склада не будут справляться с задачей своевременной подготовки товара к отгрузке, это также может привести к плачевному результату. Что же делать? Спросить у персонала?

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

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

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

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

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

Первое знакомство

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

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

Точка маршрута отражает определенный этап жизненного цикла бизнес-процесса и обычно связана с выполнением какой-либо операции (ручной или автоматической).

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

Опишем цепочку продажи товара с точки зрения введенных терминов.

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

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

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

Карта маршрута

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

Рис. 1.1. Редактирование карты маршрута

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

Рис. 1.2. Панель «Вставка элементов схемы»

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

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

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

На рис. 1.3 приведен пример карты маршрута с жесткой маршрутизацией.

Рис. 1.3. Пример карты маршрута с жесткой маршрутизацией

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

На рис. 1.4 приведен пример карты маршрута с условной маршрутизацией.

Рис. 1.4. Карта маршрута бизнес-процесса с условной маршрутизацией

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

К условному виду маршрутизации данная карта относится из-за отсутствия параллельных (сходящихся) ветвей. К параллельному виду маршрутизации можно отнести карту следующего вида (рис. 1.5).

Рис. 1.5. Пример карты маршрута бизнес-процесса с параллельной маршрутизацией

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

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

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

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

Листинг 1.1. Пример отображения карты маршрута

В результате, например, можно увидеть следующую картину (рис. 1.6).

Рис. 1.6. Пример отображения карты маршрута

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

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

Листинг 1.2. Пример отображения карты маршрута в форме обработки

Результат будет таким же, как и в предыдущем случае.

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

Точки маршрута

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

Существует несколько точек маршрута:

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

У точек некоторых видов есть специфические свойства и события. Например, свойство Групповая есть только у точки действия, а событие ПроверкаУсловия – только у точки условного перехода.

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

Рассмотрим точки маршрута подробнее.

Точка старта, точка завершения

Схематическое изображение данных точек показано на рис. 1.7.

Рис. 1.7. Точка старта и точка завершения

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

Рис. 1.8. Карта бизнес-процесса продажи товара с демонстрацией

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

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

Завершение бизнес-процесса производится либо при покупке товара (продажа состоялась), либо при отказе после демонстрации.

Более подробно особенности работы с данными точками (их событиями) описаны в разделах «Старт бизнес-процесса», и «Завершение бизнес-процесса».

Точка действия

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

Схематическое представление точки действия на карте маршрута имеет следующий вид (рис. 1.9).

Рис. 1.9. Точка действия

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

Можно выделить два вида адресации (адресной маршрутизации), реализованной в платформе:

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

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

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

Рис. 1.10. Структура регистра сведений

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

В табл. 1.1 приведен пример заполнения регистра сведений.

Таблица 1.1. Пример заполнения регистра сведений

Сотрудник	Роль исполнителя	Подразделение
Иванов		Отдел продаж
Петров	Бухгалтер	Администрация
Сидоров	Кладовщик	Оптовый склад
Федоров	Руководитель отдела	Отдел продаж

Привязка системы адресации (регистра сведений) к бизнес-процессу осуществляется через объект Задача (при конфигурировании бизнес-процесса в нем указывается ссылка на объект конфигурации Задача). В самой задаче на закладке свойств Адресация определяется ссылка на используемый регистр сведений, и кроме этого необходимо определить используемые реквизиты адресации (рис. 1.11).

Рис. 1.11. Установка свойств задачи

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

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

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

Рис. 1.12. Свойства реквизита адресации

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

• Выбрать ссылку на регистр сведений.
• Добавить реквизиты адресации.
• Выбрать основной реквизит адресации.

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

Рис. 1.13. Свойства точки действия карты маршрута бизнес-процесса

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

Если в группе свойств Адресация точки действия установлены значения, показанные на рис. 1.13, то при переходе бизнес-процесса к данной точке будет создана одна задача (если иного не определено программно). В соответствующих ее реквизитах адресации будут автоматически записаны указанные при конфигурировании значения (РольИсполнителя = Кладовщик и Подразделение = ОтделПродаж).

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

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

Рис. 1.14. Свойства точки маршрута бизнес-процесса

Таблица 1.2. Данные регистра сведений

Сотрудник	Роль исполнителя	Подразделение
Иванов		Отдел продаж
Петров	Бухгалтер	Администрация
Сидоров	Кладовщик	Оптовый склад
Федоров	Руководитель отдела	Отдел продаж

Таблица 1.3. Значения реквизитов адресации

Сотрудник	Роль исполнителя	Подразделение
Иванов		Отдел продаж
Федоров	Руководитель отдела	Отдел продаж