Автозадачи

Управление - Бизнес-процессы

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

Итак, дошла очередь до Автозадач. После доклада "Кастомизация на лету" многие коллеги обращались с просьбами опубликовать какие-нибудь решения. Особенно часто упоминали автозадачи.

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

Самый простой и востребованный пример - отложенное исправление ошибок (когда ошибку сразу не видно или нельзя исправить). Например, бухгалтер забыл сделать выписку и у исходящих платежек не стоит признак Оплачено. Или возникли отрицательные остатки по товарам в бух.учете. Или числится одновременное сальдо на 60.01 и 60.02. И т.д.

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

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

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

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

Теперь уберем слово "ошибка", заменим словом "задача". Нам нужно, чтобы человек что-то сделал - неважно, исправил ли ошибку, согласовал ли заявку, оформил ли перемещение, создал ли бюджет, совершил ли 10 звонков, и т.д. Как автоматизировать управление такими задачами?

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

Автозадачи значительно упрощают этот процесс:

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

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

Программирование автозадач

АЗ программируются в справочнике «.Параметры автозадач» - это вроде как типы АЗ.

Центральное место в программировании АЗ занимает составление схемы компоновки. В чем ее суть:

  1. Схема должна описывать, при каких условиях есть задача. Например, схема возвращает платежку исходящую, которая проведена, но в ней не стоит флаг Оплачено. Это будет задача – сделать выписку, чтобы в 1С списались деньги;
  2. В то же время, когда человек выполнит задачу, схема должна вернуть пустую выборку – это будет означать, что задача выполнена;
  3. Ну т.е. должно быть четкое понимание при разработке схемы, при каких условиях задача есть, а при каких она выполнена. Это одно из основных отличий АЗ от прочих подобных механизмов – АЗ не привязаны к событиям системы, нет понятий «возникновение задачи» или «закрытие задачи»;
  4. Одна из аналогий АЗ – отчеты, которые пользователь настраивает сам себе, чтобы понять, что ему еще надо сделать. В примере из п.1 это будет отчет «Неоплаченные исходящие платежи»: если отчет что-то показал – есть задача, если вышел пустой – все в порядке, задачи нет.

Требования к схеме компоновки:

Схема компоновки должна обязательно содержать два поля:

  1. КлючЗадачи – любого типа. Должно быть всегда, в разделе «Выбранные поля» схемы;
  2. ТекущийОстаток – числового типа. Должно быть всегда, в разделе «Выбранные поля» схемы;
  3. Исполнитель – типа «Справочник.Пользователи» или «Справочник.итРолиПользователей». Должен быть в зависимости от типа определения исполнителя (см. раздел ниже).

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

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

Если вернуться к примеру с платежками, то варианты могут быть такие:

  1. Ключ задачи – платежка. В этом случае задач будет ровно столько, сколько неоплаченных платежек. В задаче при этом будет ссылка на одну эту платежку. Срок выполнения при этом надо будет определять исходя из знаний об этой платежке – например, дата платежки + сутки;
  2. Ключ задачи – начало дня платежки. В этом случае задач будет ровно столько, сколько разных дней есть в неоплаченных платежках. Например, если есть неоплаченные платежки за сегодня и за вчера, то автозадач будет две. Срок выполнения при этом можно вычислять исходя из ключа задачи – например, ключ задачи + сутки, или ключ задачи + 8 часов.
  3. Ключ задачи – пустой, или какое-то постоянное значение (типа «», 1, истина, «ключ»). В этом случае задача будет одна, и в ней будут все неоплаченные платежки. Когда настанет момент, что все платежки будут оплачены, задача закроется. Когда вновь возникнут неоплаченные платежки, создастся новая задача. Ну это вообще общее правило АЗ – если задача закрылась, она уже не откроется – всегда будет создана новая.

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

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

Также, внутри автозадачи есть история изменения текущего остатка, в виде табличной части. Это для тех задач, которые могут выполняться поэтапно. В примере с платежками это варианты ключа задачи 2 и 3. Например, было 10 документов – тек. остаток будет 10. Человек сделал выписку, 2 дока оплатились – текущий остаток будет 8. И т.д., до нуля.

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

Определение исполнителя

Исполнитель задачи определяется двумя способами:

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

Группировки схемы компоновки

Тут всего два варианта:

  1. Если исполнитель определяется в параметрах автозадачи, то группировка должна быть одна - <Детальные записи>. Все остальные поля – в выбранных полях;
  2. Если исполнитель берется из схемы, то первой должна идти группировка «Исполнитель», в ее иерархии - <Детальные записи>. Все остальные поля – в выбранных полях.

Сроки выполнения автозадач

Срок выполнения автозадачи определяется исходя из самой автозадачи. Вычисление срока реализуется на встроенном языке платформы, с помощью произвольной формулы. В формуле доступны все конструкции языка, а также доступна формируемая задача (типа СправочникОбъект.итАвтозадачи). Имя переменной – Источник. Результат вычисления по формуле должен быть помещен в переменную Результат.

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

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

Результат = Источник.КлючЗадачи.Дата + 3600 * 24.

Если не сутки, а конец того дня, когда был создан документ, то формула будет такой:

Результат = НачалоДня(Источник.КлючЗадачи.Дата) + 3600 * 17.

Если ключом задачи является, например, дата (сама задача при этом содержит несколько документов), то формулы будут такие:

Результат = Источник.КлючЗадачи + 3600 * 24, или Результат = НачалоДня(Источник.КлючЗадачи) + 17 * 3600.

Также, при вычислении срока доступны все реквизиты задачи. Например, у задачи есть реквизит ДатаПостановки – он равен дате создания задачи, его тоже можно использовать. Формула будет такой, к примеру:

Результат = НачалоДня(Источник.ДатаПостановки) + 17 * 3600.

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

Для себя я сделал отдельную функцию в общих модулях, типа ПолучитьСрокЗадачи(ДатаНачала, КоличествоРабочихДней). В нее передаю дату, от которой отсчитывать срок, и количество рабочих дней.

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

Написание текста и заголовка задачи

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

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

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

Вычисляемый кусок в тексте оформляется квадратными скобками, например:

[Формат(ТекущаяДата(), «ДФ=dd.MM.yyyy») + « г.»]

Если в примере с платежками, то примерно так:

  1. Для варианта, когда ключом задачи является платежка, можно сделать такое краткое представление:
    1. «Оплатите платежку [Задача.КлючЗадачи]!!!»
  2. Для варианта, когда ключом задачи является дата платежки, можно написать так:
    1. «Надо сделать выписку и оплатить платежки от [Формат(Задача.КлючЗадачи, «ДФ=dd.MM.yyyy») + « г.»]»

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

Расшифровка автозадачи

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

Расшифровка бывает двух типов:

  1. В виде табличного документа – применяется, когда автозадача содержит несколько объектов для обработки;
  2. В виде ключа задачи – когда объект один.

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

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

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

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

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

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

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

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

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

Чтобы пользователь видел ключ, надо в параметрах задачи поставить флаг «Показывать ключ».

Остальные реквизиты настройки

  1. Ответственный – можно указать пользователя или роль человека, который отвечает за выполнение задачи. Это вроде как ответственный за процесс, или просто начальник исполнителя задачи. Используется для группировки потом. Можно не указывать;
  2. Единица измерения остатка – строковое поле, которое добавляет к текущему остатку по задаче. Например, «док.» или «руб.»;
  3. Количество знаков после запятой – для форматирования вывода текущего остатка автозадач;
  4. Закрывать по окончании срока – если флаг установлен, то задача будет автоматически закрываться по окончании срока выполнения. При этом в задаче будет стоять признак «Закрыта»;
  5. Закрывается вручную – это для задач, у которых нельзя запросом отследить, что они выполнены. У меня одна такая задача – удаление пользователей из домена/почты при увольнении. Возникновение задачи отследить можно, исполнение – нет. Для ручных задач в форме появляется кнопка «Отметить выполнение», и пользователь должен ее нажимать сам;
  6. Дополнительные исполнители – таблица, где можно указать, кто еще может выполнить эту задачу. Я использовал эту таблицу для RLS, чтобы доп.исполнители видели эту задачу;
  7. Степень влияния исполнителя на результат – доп.аналитика задач, я ее использовал при оценке состояния задач. Есть задачи, где человек сам все сделать может, есть такие, где нужна помощь других людей. Вот этим реквизитом оно и разделяется;
  8. Кто видит задачу – таблица, где можно перечислить зрителей. Я использовал для RLS.

Формирование автозадач

Для формирования автозадач используется регл.задание итФормированиеАвтозадач.

Что оно делает:

  1. Выполняет все схемы компоновки их параметров задач, в которых стоит признак «Активная»;
  2. Формирует таблицу новых актуальных задач;
  3. Формирует таблицу старых актуальных задач (которые не выполнены и не закрытые);
  4. Сравнивает таблицы новых и старых актуальных задач;
  5. Если задача совсем новая – создает, если уже была такая – обновляет. Сравнение идет по полям «КлючЗадачи» и «Исполнитель». Это означает, к примеру, что при изменении исполнителя в параметрах автозадач все ранее поставленные задачи будут перепоставлены новому исполнителю;
  6. Закрывает старые задачи, которые стали не актуальными;
  7. Закрывает задачи, у которых вышел срок и стоит флаг «Закрывать по окончании срока».

Расписание регл.задания я ставлю через консоль. Сначала ставил раз в минуту, потом увеличил до 5 минут, т.к. задач стало много. Сервер у меня слабый, выполнение всех схем занимает 2-3 минуты.

Для отладки на файловых базах я добавил обработку ФормированиеАвтоЗадач – там одна кнопка, которая делает ровно то же, что и регл.задание.

Инструкция по внедрению.

Непосредственно к автозадачам (АЗ) относятся объекты:

  1. Общие модули итАвтозадачи и итАвтоЗадачиПривилегированный;
  2. Регламентное задание итАвтоЗадачи;
  3. Справочники итПроизвольныеФормулы, итРолиПользователей, итАвтоЗадача, итПараметрыАвтоЗадач;
  4. Документ итНазначениеРолейПользователей;
  5. Перечисление итВидыДействийНачатьПрекратить;
  6. Обработка ФормированиеАвтозадач;
  7. Регистры сведений итНазначениеРолейПользователей и итРасшифровкиАвтозадач.

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

  1. Справочник Пользователи (оставил только сам справочник, убрал формы и модули);
  2. Параметр сеанса ТекущийПользователь;

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

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

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

Если таких объектов у вас нет, то надо переделать ссылки с моих объектов на ваши – пишите, если нужна помощь.

Демобаза

Приложил маленькую демонстрационную базу, с той же конфигурацией.

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

Что дальше

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

Скачать файлы

Наименование Файл Версия Размер
Конфигурация Автозадачи
.cf 95,58Kb
01.08.17
9
.cf 95,58Kb 9 Скачать
Демобаза Автозадачи
.dt 107,80Kb
01.08.17
27
.dt 107,80Kb 27 Скачать

См. также

Комментарии
1. Валерий Волошин (VVi3ard) 38 01.08.17 11:57 Сейчас в теме
На мой взгляд интересная разработка, относительно простая для понимания и полезная после внедрения.
2. Геннадий Николаев (genayo) 01.08.17 23:09 Сейчас в теме
Сама идея далеко не нова, изюминка в использовании для всего этого СКД.
3. Иван Белокаменцев (1c-intelligence) 993 02.08.17 09:56 Сейчас в теме
(2) у вас есть ссылки на материалы, где упомянута такая идея, или описана реализация?
Не в качестве доказательства, просто интересно.

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

Что точно не ново, так это реализация - несколько человек независимо от меня реализовали подобный механизм, когда узнали идею.
4. Иван Белокаменцев (1c-intelligence) 993 02.08.17 09:57 Сейчас в теме
(1) не сомневайтесь, она и правда очень простая и полезная.
Я пользовался ей в реальном внедрении 3 года.
5. Артем Артеменко (dock) 25 02.08.17 10:30 Сейчас в теме
в демо базе поправьте режим совместимости интерфейса :)
что-то вообще какая-то странная демо-база... вроде как все под УФ, а пришлось пошаманить для правильного запуска
6. Иван Белокаменцев (1c-intelligence) 993 02.08.17 10:53 Сейчас в теме
(5) там все правильно вроде. Режим совместимости интерфейса такой же, как в УПП, в которой автозадачи разрабатывались изначально.
7. Геннадий Николаев (genayo) 02.08.17 11:10 Сейчас в теме
(3) ДО2 это совсем другая тема, задачи там таки существуют как сущность и закрыться сами могут далеко не всегда.
Относительно похожая подсистема есть в одной WMS родом из начала 2010-х, только там все кодом без СКД, и кроме рассылки почтой иных способов доставки "задач" нет. Ваша подсистема конечно гораздо более продвинутая и удобная.
8. Иван Белокаменцев (1c-intelligence) 993 02.08.17 12:04 Сейчас в теме
(7) я видимо неправильно акцентировал внимание в публикации - здесь задачи тоже существуют как сущность. Это справочник.
9. Геннадий Николаев (genayo) 02.08.17 12:09 Сейчас в теме
(8) Я имел в виду объект платформы Задача.
10. Иван Белокаменцев (1c-intelligence) 993 02.08.17 12:11 Сейчас в теме
(9) Понятно. Ну это вроде не так важно.
11. Геннадий Николаев (genayo) 02.08.17 12:20 Сейчас в теме
(10) Использование объектов задача - это скажем так более классический подход, и накладывает определенные ограничения на функциональность, в отличии от вашего решения.
12. Иван Белокаменцев (1c-intelligence) 993 02.08.17 12:25 Сейчас в теме
(11) я за 12 лет несколько раз смотрел на ветку "Задачи" в дереве метаданных, но каждый раз что-то останавливало от их использования. Ну нет там ничего такого интересного, существенно выделяющего их на фоне справочников и документов.

Возможно, это просто мертворожденный тип объектов метаданных. Равно как и железобетонные бизнес-процессы, карты которых рисуются в конфигураторе.
13. Геннадий Николаев (genayo) 02.08.17 12:33 Сейчас в теме
(12) Вы видимо близко не смотрели ДО2, там все на задачах, бизнес-процессах и справочниках. И бизнес-процессы в конфигураторе там уже давно не рисуются, в последней версии даже сделана попытка обеспечить графический интерфейс создания новых бизнес-процессов в режиме предприятия.
Кстати, сейчас ДО2 внедряется на Почте России, и по результатам внедрения обещают новую прорывную версию :)
14. Иван Белокаменцев (1c-intelligence) 993 02.08.17 12:42 Сейчас в теме
(13) ладно, хрен с ними, с задачами этими :)
15. Артем Артеменко (dock) 25 02.08.17 15:55 Сейчас в теме
(6) да, всё верно. Просто уже привык к УФ (даже не к УФ, а Такси) и мои необоснованные ожидания были не оправданы....
16. Ирли Бёрд (EarlyBird) 1 02.08.17 17:16 Сейчас в теме
У меня один вопрос: зачем конфигурацию и демо-базу выкладывать двумя разными архивами, почему не объединить в один?
Они что, весят по гигу?
17. Иван Белокаменцев (1c-intelligence) 993 03.08.17 07:36 Сейчас в теме
(16) даже не знаю, что ответить. Не мелькнула такая мысль в голове.
18. Anton Klymov (antoklio) 04.08.17 17:00 Сейчас в теме
Получается, что на любую конфигурацию можно накатить? например, мне нужно на УТ10.3 и на Розницу 2.1.
19. Иван Белокаменцев (1c-intelligence) 993 04.08.17 18:22 Сейчас в теме
(18) на УТ 10.3 и Розницу точно встанет.
А вообще - да, на любую, кроме самописанных - там минут 10 рихтануть придется.
Будут трудности - пишите.
20. Иван Белокаменцев (1c-intelligence) 993 07.08.17 07:51 Сейчас в теме
Друзья, кто скачал, удалось попробовать сделать автозадачи?
Трудности есть?
21. Anton Klymov (antoklio) 14.08.17 17:12 Сейчас в теме
накатил на Розницу.
При добавлении нового элемента в справочник "Параметры автозадач" ошибка преобразования данных ХДТО: НачалоСвойства: {http://v8.1 бла-бла -бла} settingsVariant
Форма: Элемент
Тип:{http://www.w3 бла-бла-бла}

Версия Розницы 2.1.8.16, доработанная.
Платформа 8.3.6.2237

PS. Кажется, ошибка возникает в тонком клиенте. В Толстом нормально....
22. Иван Белокаменцев (1c-intelligence) 993 14.08.17 17:25 Сейчас в теме
(21) да, так и должно быть - в тонком клиенте 8.3.6 нет конструктора схемы компоновки.
Схемы рисуйте в толстом, сами задачи в тонком нормально работают.
Оставьте свое сообщение