Термины и сокращения.
Схемы работы решений, которые вы встретите в статье, нарисованы достаточно схематично, и при этом используются следующие аббревиатуры:
- СКД – это схема компоновки данных;
- Если после СКД стоит двоеточие и что-то в квадратных скобках написано, это значит, что схема компоновки данных вернула какую-то таблицу, объект, диаграмму или что-то еще;
- ПП – это пользовательское поле. Пользовательские поля – это одна из главных фишек системы компоновки данных, которую я использовал;
- ИБ – это информационная база 1С;
- И МД – это метаданные.
Архитектура всех решений
Все решения, про которые я буду рассказывать, имеют примерно одну и ту же архитектуру. Они состоят из следующих блоков:
- Метаданные для создания и хранения схем компоновки данных.
- Метаданные и код вспомогательных данных
- Некий центр обработки данных (или интегратор)
- Ну и, собственно, выходные формы.
Несмотря на то, что архитектура всех представленных решений завязана на использовании схем компоновки данных, ни одно из них внутри самих себя схем не содержит. Все схемы настраиваются исключительно в пользовательском режиме. В этом и заключается кастомизация. И если вы сейчас возьмете любое из этих решений, внедрите его в свою конфигурацию, а потом запустите в режиме предприятия, ничего не произойдет: не начнут работать никакие проверки, не появится никакой информации на экране, никакие электронные письма и SMS уходить не будут. Но вы, не возвращаясь в конфигуратор, сможете все это себе настроить.
Предыстория (с чего все начиналось).
Я думаю, что всем вам знакомы эти два окна. Это «Групповая обработка справочников и документов» и «Консоль отчетов». Именно эти инструменты легли в основу тех решений, о которых я буду говорить. Какова их роль?
- «Групповая обработка справочников и документов» нужна не только для того, чтобы перепроводить документы и исправлять какие-то реквизиты, она также умеет очень быстро искать ошибки. Как это происходит?
Допустим, вы закрываете месяц и обнаруживаете, что у вас совсем не закрывается 25-й счет. Когда счет совсем не закрывается – это хорошо, значит, что есть какая-то одна большая глобальная ошибка (допустим, банально, статья затрат не та стоит в «Поступлении товаров и услуг»). И мы помощью «Групповой обработки справочников и документов» можем настроить фильтр и сразу увидеть все документы, в которых такая ошибка была допущена. - Далее - «Консоль отчетов». Как она стала прародителем инструментов?
«Консоль отчетов» позволяет быстро получить данные, которые недоступны в типовых отчетах. Наверняка вам это знакомо.
Карта решений
Инструменты, про которые пойдет речь, можно условно разделить на 6 групп по направлениям использования. Всего решений 14. И сейчас я про каждое из них расскажу.
Проверка ведения учета
Итак, «Проверка ведения учета». Несколько лет назад я на партнерской конференции 1С создал тему, которая вызвала бурные дискуссии. Мы хотели создать универсальный бесплатный инструмент, некий «антивирус», который можно было бы запустить на любой базе УПП, чтобы он показал все допущенные ошибки учета (например, вывел бы все документы, в которых указаны не те счета учета и т.д.)
Архитектура решения очень простая. В УПП есть справочник «Произвольные отчеты», который используется для разных целей, в частности, там можно просто держать схемы компоновки данных (они там внутри хранятся). Мы создаем несколько схем компоновок, каждая из которых осуществляет какую-то определенную проверку, и записываем их в справочник «Произвольные отчеты» в виде отдельных элементов. Например:
- одна проверка ищет незаполненное субконто;
- другая – неправильные счета учета;
- третья – не те статьи затрат;
- четвертая – несоответствие статьи затрат и счета учета;
- и т.д.
И есть некий «контейнерный выполнитель», который просто выполняет по порядку все эти схемы компоновки и выводит все ошибки в одну большую таблицу. Он работает по следующему принципу: если схема компоновки данных на входе передала ему отчет, значит, ошибки есть, а если ничего не вернула, значит, ошибок нет.
И на выходе получается сгруппированный по типам ошибок отчет, где показаны документы, в которых были найдены ошибки (или справочники – в зависимости от того, какая там была ошибка).
Проверка данных при записи.
Суть инструмента «Проверка данных при записи» – очень простая. Она заключается в том, что мы не хотим, чтобы в нашу базу данных попадали «неправильные» документы и справочники.
Допустим, мы знаем, какие документы должны считаться правильными, а какие – нет. В качестве примера можно взять любой товарный документ, в котором важно соблюдать соответствие номенклатуры и прописанного для нее счета учета. Для получения такого соответствия мы можем попросить наших бухгалтеров составить табличку, где было бы указано: все, что лежит в папке «Материалы», должно приходить на счет 10.01, а все, что в папке «Прочие материалы» – на счет 10.06 и т.д. И проверку на соответствие этой табличке мы можем внести, опять же, в схему компоновки данных, которая должна срабатывать при записи нашего документа, и сообщать: «Такая-то строка заведена неправильно – такая-то ошибка».
Решение – проще некуда, но в нем применена «фишка» с пользовательскими полями СКД. В чем заключается эта «фишка»?
Представьте, что у вас есть документ «Поступление товаров и услуг» и вам надо применить к нему 10 разных проверок. Как это сделать? Как узнать, какая именно проверка прошла, а какая нет?
Использовать для этого обычный отбор, который есть в схеме компоновки данных, не очень удобно. Либо придется делать этот отбор очень сложным (с группами ИЛИ), либо под каждое условие надо будет писать отдельное поле в запросе (например, одно поле будет возвращать информацию о том, правильно ли указан счет учета, другое – есть ли там единица измерения, третье – еще что-нибудь).
А с пользовательскими полями эта задача решается гораздо удобнее, потому что при добавлении пользовательского поля выбора мы можем задать для него соответствие различных фильтров и их значений: например, указать, что если сработал этот фильтр, возвратилось одно значение, а если сработал другой фильтр – другое значение. Используя этот механизм, к одному запросу можно приделать бесконечное количество различных проверок. Конечно, при выполнении этой схемы процессор системы компоновки данных преобразует ее пользовательские поля в сложные конструкции запроса, но нам это уже не важно, главное, чтобы человеку было удобно и понятно.
Автоопределитель
«Автоопределитель» появился как логическое продолжение «Проверки данных». Его идею придумал Анатолий Андюкин, бывший начальник отдела разработки УПП, если кто знает.
Идея «Автоопределителя» заключается в том, что если программа такая умная и может определить, какое значение в данном случае должно быть правильным, а какое нет (например, если она знает, что для номенклатуры в папке «Материалы» должен стоять счет 10.01), то его подстановка происходит автоматически.
Принцип ровно тот же самый. Даже интерфейсно решения очень похожи. Человек выбирает: «Поступление товаров и услуг», табличная часть «Товары», если выбрана номенклатура из папки «Материалы», подставь счет 10.01. Все.
Используется тот же принцип работы на схеме компоновки данных. Единственное, что сама схема отличается, потому что (я думаю, программисты поймут) «Проверку данных» можно делать при записи, а «Автоопределение» надо делать перед записью. А если объект новый, то его ссылки у нас еще нет, поэтому весь объект помещается в таблицу знаний, которая передается в схему компоновки данных в качестве внешнего источника. При этом отборы работают точно так же, потому что типы значений полей в этой таблице остаются такими же, как и у объекта.
Информатор
«Информатор» – это одно из самых старых и до сих пор успешно работающих решений. Его задача простая – он должен информировать пользователей о наступлении того или иного события.
На любом предприятии есть куча народу, которые вплотную с 1С не работают – они не бухгалтеры, не экономисты, а менеджеры. А мы при внедрении заставляем этих людей чаще проводить время за компьютером: учим их работать с отчетами, чтобы узнавать из них, например, пришли ли деньги от клиента.
Как вообще в типовой УПП можно узнать о поступлении денег? Единственный способ – это заходить и каждый день просматривать. Либо бухгалтеру звонить и спрашивать: «пришли мои деньги или нет?»
Чтобы отвести от системы вот такие типовые запросы людей, и был создан «Информатор» (чтобы не Магомет шел к горе, а наоборот, гора посылала сигналы Магомету).
Работает это очень просто – два варианта срабатывания:
- Первый вариант – при записи какого-нибудь документа.
Например, проводится платежка, в которой указана реализация. При ее проведении у нас выполняется схема компоновки данных, которая перекладывается в текст письма, и это письмо уходит на электронную почту менеджера.
Все, ему за этим процессом больше следить не надо. Как только появилась платежка, в которой заполнена реализация, и он в этой реализации указан ответственным менеджером, ему уходит письмо (или, на выбор, Skype/SMS). Правда,Skype не любит интеграцию, поэтому это тупиковая ветка, но SMS нормально работают – с постановкой GSM-модема все без проблем отправляется. - Второй вариант – это отправка отчетов по расписанию. В этом случае информационное письмо уходит не в момент какого-то события в системе, а просто по расписанию.
Например, уже три года наш собственник бизнеса получает по утрам SMS о том, сколько у него денег на расчетных счетах. Это очень просто – сами понимаете, запрос, который вернет перечень расчетных счетов и сколько на них денег, написать несложно. А потом эта информация тупо ложится в текст, который уходит по SMS.
Собственник бизнеса осталсядоволен, за три года ни разу замечаний не высказал.
Консолидированные отчеты
«Консолидированные отчеты» – это очень простой инструмент, который родился «на лету».
Ситуация банальная: есть несколько информационных баз в структуре холдинга – у кого-то УПП, у кого-то «Бухгалтерия Предприятия». Надо получить несколько консолидированных отчетов в 1С:Документообороте 2.0. «Консолидацию» покупать ради этого не хочется, она сейчас очень дорого стоит. Нашли простое и быстрое решение:
- Мы не стали соединять базы никакими обменами, мы просто добавили в каждую базу простейший справочник для хранения в нем схем компоновки, каждая из которых должны выдавать данные в нужном формате (например, данные о движении денег за произвольный период).
- А в Документооборот мы добавили:
- Обработку, которая умеет соединяться со всеми этими базами COM-соединением,
- Регистр сведений, куда складываются полученные от этих баз данные.
- А также написали простейший отчет (построенный, опять же, на схеме компоновки), который «сгребает» из всех этих баз нужные данные, кладет их в регистр сведений и из него строит консолидированный отчет.
Таким образом, мы где-то за неделю получили все отчеты, которые нам были нужны: по движению и по остаткам денег, по бюджетам и т.д.
Слайдер
Решение«Слайдер», конечно, тупиковое, но забавное. Наши директоры целой делегацией съездили на какое-то предприятие смежного профиля, и им очень понравилось, что там по всему предприятию висели телевизоры, на которых демонстрировались различные показатели деятельности: объем продаж, рейтинг менеджеров с начала месяца, список сотрудников, которые находятся в командировке и т.д.
У них, конечно, это было сделано не очень правильно – там просто висел большой Excel-файл, который кто-то раз в день обновлял вручную. Но все равно наши директоры решили сделать что-то похожее и у нас.
Самое простое, что приходит в голову – это просто вывести на монитор тонкого клиента 1С, и запустить там какие-нибудь диаграммы (потому, что инфографику читать интереснее). Но вы сами знаете, как выглядят диаграммы в 1С, особенно, если их растянуть на 55 дюймов.Даже при наличии сглаживания и эффектов анимации, которые появились в новых версиях 8.3, выглядеть это будет очень скучно. Намного интереснее выглядят графики в Microsoft Office. Например, в Power Point. Хотя они там и рисуются с помощью Excel.
Как работает решение? Опять же, очень просто, примерно, как и предыдущее:
- В каждую информационную базу, которая должна выдавать данные, добавляется простейший справочник для хранения схем компоновки данных. Эти схемы предназначены для получения различной информации – например, мы можем записать туда схему для получения процента выполнения плана продаж.
- Дополнительно в каждой базе запускается обработка, которая по регламентному заданию раз в минуту запускает нужные схемы на выполнение и результирующие данные складывает в html-файл, который лежит у нас в сети.
- А сами графики рисуются в Excel. Если помните, там есть закладка «Данные», на которой можно импортировать данные из разных источников, в частности из таблиц HTML. Мы можем там выбрать наш файл HTML, выделить на нем мышкой импортируемую таблицу и нажать кнопку «Импортировать». После этого у нас появится возможность использовать табличку из нашего html-файла в качестве источника для визуализации данных – например, можем нарисовать себе любойграфик, разукрасить его и т.д. К тому же она там автоматически раз в минуту сама обновляется.
- И в результате мы с интервалом в две минуты получаем красивую картинку (раз в минуту 1С ее выложила, и раз в минуту Excel ее прочитал и график обновил).
Получается очень интересно. Фишка в том, что информационных баз много, а нам банально надо было вывести процент выполнения плана продаж по всему холдингу. А чтобы собрать весь холдинг, надо несколько баз прошерстить, потому что интегрирующей базы нет. И вот каждая база выкладывает данные в свой файл HTML, а потом все файлы собираются на одной страничке Excel – для этого нужно просто мышкой нужную область данных выделить и вывести ее на график. Получается очень красиво.
Рабочий стол
«Рабочий стол» – это такая формочка, на которую выведено только то, что нужно пользователю, не больше и не меньше. Туда можно выводить отчеты в виде табличных документов, динамические списки, диаграммы, наборы ссылок, кнопки и ссылки на метаданные. Это решение работает у меня уже очень давно – с 2012 года.
Интересна история его появления. Как-то собственник бизнеса решил вникнуть в 1С, чтобы получать данные непосредственно оттуда. Он пошел в бухгалтерию и попросил показать ему, что такое «оборотка» – ему показали. Потом он попросил экономистов, чтобы они ему показали, что такое типовые отчеты, и объяснили, как их настраивать. В общем, его хватило на несколько дней, а потом ему стало скучно. Он говорит: «А можно мне сделать так, чтобы у меня на одном экране все это вылезало в визуальном виде (в виде диаграмм)? Я – визуал».
Сами понимаете, диаграммы нарисовать несложно, это отлично делает схема компоновки данных, но по умолчанию она их рисует только в табличный документ. А показывать 10 диаграмм в табличном документе – это кошмар, потому что сразу по бокам появляются скроллы из-за того, что размер диаграммы в табличном документе не регулируется.
Но если вывести диаграмму на форму, ее размер автоматически «подстроится» под отведенное для нее место – значит, нужно выводить сразу на форму. Оказалось, это совсем несложно. С помощью схемы компоновки данных выводим диаграмму в табличный документ, а из табличного документа ее полностью копируем с помощью метода ЗаполнитьЗначенияСвойств(): копируются все серии, точки, цвета, свойства этих точек, свойства осей.
В результате получается красивая диаграмма. Почему красивая? Потому что когда мы ее выводим на форму, там еще автоматически создаются разделители, которые можно двигать, и при этом размер диаграммы меняется. Выглядит забавно, если мышкой поиграться.
Изначально, когда это решение появилось, оно было предназначено только для собственника бизнеса. Правда, потом он все равно захотел, чтобы этот отчет ему раз в день приходил на электроннуюпочту (потому что человек все время куда-то ездит, ему не до 1С).
Потом решение получило развитие:
- Там появились ссылки на метаданные, чтобы человек мог быстро открыть нужные ему документы и справочники, отчеты и т.д.
- Там появились отчеты в виде табличного документа. Но от этого пути очень быстро отказались, потому что какой смысл говорить человеку: «я тебе все выведу на рабочий стол», и выводить туда табличный документ, который тут же скроллом надо куда-то мотать.
- Потом попробовали выводить туда динамические списки, и от этого тоже быстро отказались, потому что управлять отображением динамических списков неудобно.
- В результате появился так называемый «Набор ссылок». Это такой «недоотчет», который решает конкретную практическую задачу. Например, есть у нас снабженец, который заводит в систему заказы поставщикам, и ему за ними надо следить, чтобы они пришли ровно в ту дату, которую он указал в заказе. Как только эта дата проходит, мы пишем простейшую схему компоновки данных:
ВЫБРАТЬЗаказПоставщику,
ГДЕ Дата <ТекущаяДата() И Ответственный = &ТекущийПользователь.
И выводим ему эти гиперссылки на экран. Он их получает и видит, что у него, допустим, просрочен заказ. Зашел в этот заказ, поправил дату, закрыл – и эта гиперссылка у него с рабочего стола исчезает.
Вот несколько скриншотов возможного использования «Рабочего стола»:
Гаджет «Состояние производства» – базовый элемент рабочих столов. Содержит небольшой набор узконаправленной информации, предназначенной конкретному пользователю.
«Живая лента»– гаджет с различной разнородной информацией.
«Рабочий стол бухгалтера по ТМЦ»– пример безгаджетного рабочего стола, содержащего только ссылки на документы/справочники/отчеты.
«Рабочий стол директора БП 3.0»–«классический» рабочий стол директора, который в основном заходит, чтобы понаблюдать. Все диаграммы – интерактивные. Как вы видите, возможна работа в тонком клиенте и Бухгалтерии предприятия 3.0.
Ну и, наконец, пример набора гаджетов, содержащего все данные, которые нужны снабженцу для работы.
Все элементы на этих рабочих столах интерактивны: где-то открывается объект, где-то расшифровка, где-то сразу что-то запускается.
Интересная особенность реализации: получение данных из информационной базы на «Рабочий стол» выполняется асинхронно, чтобы не блокировать интерфейс пользователя при открытии. Потому что если на рабочем столе расположены 15 отчетов, то при его открытии выполняются 15 схем компоновки данных, а это долго, можно до минуты ждать. Поэтому схемы выполняются в фоновом задании: человек нажимает «Обновить», и у него рисуются картинки: «подождите, сейчас отчет сформируется», а потом картинки начинают по одной появляться. При этом интерфейс не блокируется, можно полноценно пользоваться базой данных.
Прототип этой технологии опубликован на Инфостарте, называется «Асинхронное формирование отчетов». Если интересно, можете посмотреть.
Универсальный механизм отчетности.
«Универсальный механизм отчетности» – это вообще «свежачок», который буквально сейчас продолжает у нас внедряться.
Все вы знаете, что в типовых конфигурациях 1С есть такая штука, как «регламентированные отчеты». Это большой табличный документ, в котором много цифр расставлено по строго определенным местам. Если вы залезали внутрь, то знаете, какой там кошмар творится: каждая цифра собирается каким-то страшным запросом, в который передается множество параметров. Особенно отчеты по зарплате, ПФР – там запросы на несколько листов, по 25 объединений.
К сожалению, в нашей организации тоже есть внутренние регламентированные отчеты. Например, «Отчет о прибылях и убытках». Наверняка многие с ним сталкивались – это такой маленький листочек A4 и в нем в строго определенных местах стоят циферки: по затратам, по выручке, по маржинальной прибыли и т.д.
Встал вопрос - как рисовать такой отчет? Мы не стали идти по пути типовой конфигурации, а пошли по нормальному пути и построили свой аналог получения «регламентированных отчетов», опять же, через получение схемы компоновки данных (причем, двухуровневое). Второй уровень нам нужен был для того, чтобы не делать все самим, а привлечь к настройке результирующей схемы специально обученных для этого людей, которых мы называем «методистами». Это могут быть, например, экономисты – они отлично умеют настраивать отчеты.
Поэтому мы делаем так:
- Программист создает специальный макет отчетной формы и пишет шаблоны для каждого из нужных показателей. Для этого он создает укрупненную схему компоновки данных – она должна быть без всяких отборов, по всей аналитике, которая доступна. Например, для отчета «Продажи» нужна схема компоновки, которая выдает одну большую сумму продаж.
- А методист обращается к этим шаблонам как к источникам данных, и с помощью отборов получает оттуда нужные ему показатели. Например, разбивает эту сумму по организациям; или, допустим, у него на входе есть «Сумма затрат общая», которую он разбивает на разные затраты (транспортные, зарплата, еще какие-то). Он делает это прямо в интерфейсе, элементарно, с помощью отборов.
А потом мы даем ему макет отчетной формы в режиме редактирования, чтобы он выбрал, куда подставить значения этих показателей: этот показатель сюда, а этот – сюда.
В результате вот такой двухуровневой обработки получается готовый отчет, завязанный на 10-15 шаблонов СКД. Там достаточно просто нажать кнопку «Сформировать»,минуты три подождать, и отчет сформируется. Все расшифровки работают, все красиво. Можно в PDF сохранить и отправить собственнику.
Универсальный механизм планирования
«Универсальный механизм планирования» – это инструмент, который позволяет запланировать обеспечение любых потребностей из любых доступных ресурсов любым возможным способом. При этом соединяются три схемы (СКД потребностей, СКД ресурсов и СКД способов сопоставления). Главное здесь – это то, как они соединяются.
Допустим, если вы в типовом помощнике планирования попытаетесь взять потребности, отминусовать из них ресурсы и получить план закупок, то они у вас соединятся только по номенклатуре (или по контрагенту). А у нас они могут соединиться, например:
- С учетом аналогов. По аналогам в типовой конфигурации вообще ничего нельзя сопоставить, там есть только обработка подбора по аналогам. А тут можно. Мы знаем, что у этой номенклатуры есть аналог, и она, соответственно, смотрит, какие есть аналоги на складе, и что-то из них выбирает. Но, разумеется, только после того, как попробует поискать точное совпадение номенклатуры.
- Или с учетом того, что позиция сборочная. Например, если нашему клиенту требуется сборочная позиция, которая состоит из 250 деталей, то программа ищет все эти 250 деталей и пытается их сопоставить с потребностью.
Когда мы работали с типовым помощником планирования УПП, у нас была проблема – было очень сложно собрать «дефицитку» (перечень дефицитных материалов, которых нам реально сейчас не хватает). Эта проблема возникала из-за того, что у нас много источников потребностей:
- Это и заказы покупателей напрямую;
- И заказы покупателей на производимое оборудование, комплектующие которого попадают в потребности.
- Также у нас используется метод определения потребностей по теории ограничения систем «барабан-буфер-веревка» – это целевые уровни номенклатуры, которые должны быть на складе.
- И другие – источников потребностей, которые надо пополнять, очень много.
И ресурсов тоже много, и их нельзя раздавать всем подряд. Например, у нас есть один VIP-клиент, под которого выделен целый склад. Его заказы могут размещаться на этом складе, а заказы всех остальных клиентов не могут размещаться на этом складе. Типовая конфигурация этого, к сожалению, не позволяет, поэтому мы и реализовали свое решение.
Один товарищ из 1С сказал, что это – как танцплощадка. Потребности – это такие партнеры, мужчины, их несколько. Ресурсы – это дамы, их обычно меньше. И мы пишем порядок сопоставления.
Например, у нас есть потребности (заказы VIP-клиента, всех остальных клиентов, потребности производства и «барабан-буфер-веревка»). И для этих потребностей мы сами можем настраивать порядок:
- Допустим, сначала VIP-клиенты забирают со склада VIP-клиента;
- Потом VIP-клиент забирает с основного склада;
- Потом VIP-клиент забирает из заказов поставщикам
- И т.д. Это как порядок «кто с кем танцует»: сначала VIP-клиент со всеми потанцевал, потом все остальные потанцевали. И вот так по очереди все и распределяется.
На выходе получаются:
- Потребности, которые не удовлетворены.
- Ресурсы, которые забраны полностью.
- Невостребованные ресурсы, которые автоматически переносятся в неликвиды (но это уже другая процедура).
«Фишка» в том, что «танцевать» они могут не только по совпадению номенклатуры, а вообще по произвольному совпадению. Например, по аналогам или с учетом разузлования продукции до конечных деталей.
И все это можно вывести в различные отчеты, в том числе составить «шахматку», где:
- по строчкам идут заказы номенклатуры;
- в колонках идут склады, заказы поставщикам;
- И в ячейках получается:
- 10 штук отсюда возьми;
- 20 штук отсюда возьми;
- 30 штук тебе через неделю приедут;
- а вот 50 штук у тебя ничем не обеспечены, делай что хочешь.
И ответственному снабженцу автоматически выводится на «Рабочий стол» срочная задача: «VIP-клиенту надо 50 штук таких-то головок».
Расчет структуры затрат
Вы, наверное, видели на Инфостарте мою обработку «Структура затрат», я ее делал в 2009 году. Там довольно несложная реализация, все на запросах. А «Расчет структуры затрат» – это новый инструмент, решающий ту же самую задачу, но только он получает структуру затрат с помощью схем компоновки. Он работает чуть дольше, но зато хранит остатки, умеет учитывать прошлые периоды. Правда, до конца он еще не готов.
Автозадачи
Что такое «Автозадачи»?
Помните, я рассказывал про «Рабочий стол», где снабженец мог увидеть, какие у него есть «косяки»? Поначалу этого было достаточно, чтобы все их с энтузиазмом исправляли, но это длилось недолго, потому что люди есть люди. Потому что даже если у снабженца на рабочем столе есть «косяки», его начальник об этом не знает – ему выводится отдельный рабочий стол с его собственными «косяками», которых, допустим, нет.
Поэтому мы решили сохранять все«косяки» в базе данных. Решение очень простое:
- Мы пишем схему компоновки, которая возвращает «косяк». Если в результате ее выполнения что-то возвращается, мы сохраняем этот «косяк» в базу данных – создаем новую «автозадачу» со ссылкой на объект, который вызвал проблему (например, на просроченный заказ).
- У нас запущено фоновое задание, которое раз в три минуты все эти «косяки» заново перебирает и проверяет их состояние. Если «косяк» исчез, его задача закрывается (она потому и названа «автозадачей»).
- «Автозадача» – это справочник, поэтому его элементы сохраняются в базе данных. У «автозадачи» есть дата создания, срок выполнения и условия закрытия, где написано, например: «на исправление ситуации дано два дня – звони поставщику, договаривайся о переносе поставки и т.д.». Как только эти условия будут выполнены, «автозадача» закроется.
- Основанием «автозадачи» может быть что угодно. Например, когда люди делают платежки, там есть флажок «Оплачено». Все знают, что если этот флажок не стоит, то деньги не уходят – они с одного регистра в другой переписываются, но продолжают при этом чиститься у нас на балансе.
Например, по основному расчетному счету (который в Сбербанке) бухгалтер обычно не забывает делать выписку, а по неосновным – иногда забывает. С утра зашел, платежку сделал и забыл. В результате у нас через день директор получает SMS-ку, в которой написано, что платежка не прошла по банку, и те 3 миллиона, про которыеон вчера давал команду заплатить с ВТБ, не были отправлены по назначению.
Проверку данных здесь не поставишь, потому что платежка без установленного флажка – это нормально, она в течение нескольких часов такая и будет. А автозадачу сделать – это самое то. Соответственно,через минуту после того, как человек проводит платежку, ему создается задача: «не забудь поставить признак «Оплачено»». И эта «автозадача» будет висеть до тех пор, пока такой флажок не будет поставлен.Причем никаким другим образом автозадачу закрыть нельзя, поскольку ее инициатором является система, а с ней договориться невозможно. Система говорит: «исправь» и не закрывает эту задачу, пока человек не исправит.
Автозадачи на самом деле – это мегавещь, удобная даже для меня. Я, допустим, очень долго не делегировал полномочия по созданию пользователей (потому что программистам не доверял) и создавал пользователей сам. А когда создаешь пользователя, для того, чтобы ему приходили информаторы, надо обязательно указать физлицо, где должна быть прописана контактная информация (e-mail, skype и телефон). А я, естественно, иногда об этом забывал. И получается, что человеку, допустим, должно прийти письмо о том, что ему согласовали платеж о получении денег в подотчет, а письмо висит, не уходит. Поэтому я сделал себе автозадачу, которая следит за тем, чтобы я не забывал указывать физлицо для пользователя. И если не указал, она мне автоматически вылезает.
Система восходящего реагирования и объективный контроль
Когда мы внедрили «автозадачи», у нас опять был взрыв энтузиазма.Все увидели свои косяки, косяки подчиненных – увидели, что косяков много. Но потом этот энтузиазм быстро прошел, потому что в подразделениях подчиненные со своим начальником уж как-нибудь договорятся, раз директор в это не вмешивается.
Чтобы решить эту проблему, мы с директором решили реализовать систему восходящего реагирования.
Что это такое? Например, висит задача на менеджере по снабжению. Если проходит день, и по ней нет движения – она переходит на начальника. Если опять проходит день, и нет движения – на главного инженера, на директора и на собственника.
Этот подход был апробирован, когда мы настраивали у себя очередь переадресации телефонных звонков. Например, нам люди звонят, а офис-менеджер не берет трубку, после этого звонок переадресуется на отдел продаж, и, если там тоже не отвечают,важные клиенты не могут дозвониться. Директор расстроился, говорит: «Поставьте переадресацию на мой телефон в конец очереди звонков». Теперь если кто-то не дозванивается, он автоматически попадает на мобильный телефон директора. Пару раз попали и все, больше такого нет.
Также работает и «Система восходящего реагирования»: есть задача, над ней вся цепочка вертикали власти, и задача поднимается по этой вертикали.
В итоге мы эту систему для директора вывели в специальный отчет, который назвали «Объектный контроль». Туда аккуратненько перерисовали квадратиками все бизнес-процессы в подразделениях по ISO9001, и там для каждого квадратика выводится: сколько в этом бизнес-процессе задач на данный момент, сколько из них просрочено, сколько не просрочено. Можно тыкать, проваливаться. Еще и фотографии туда вывели, кто за какой процесс отвечает.
Приемы оптимизации
Что касается производительности этих решений, то там реализовано три уровня оптимизации:
- В процессе разработки мы обнаружили, что если выполнять не схему, а сериализованный макет, производительность возрастает приблизительно вдвое. Я имею в виду, что если скомпоновать макет, сериализовать его, положить в хранилище значения и потом оттуда выполнять, он будетвыполняться в два раза быстрее. Единственное, что сериализованный макет не умеет работать с параметрами типа «стандартная дата» (начало месяца, конец месяца и т.д.).
- Второй уровень – мы не поленились, написали полностью трансформацию схемы компоновки в текст запроса. Это самый быстрый вариант оптимизации, он используется в «Проверке данных».
- И третий вариант (он используется в «Рабочем столе»): мы выполняем схемы компоновки данных фоновыми заданиями. Это позволяет получать нужную информацию асинхронно.
Заключение
Почему во всех этих решениях использовалась именно схема компоновки?
- Во-первых, чтобы человек на экране видел удобный красивый отбор. Потому что отбор схемы компоновки – это самый лучший отбор по сравнению с тем же построителем запроса, построителем отчета, обычным запросом
- Во-вторых, схема компоновки позволяет использовать стандартные периоды
- В-третьих, я уже говорил про пользовательские поля и то, как их удобно использовать для наложения большого количества условий
- Далее – внешние функции, выражения расчета параметров – очень удобные возможности
- А также сериализация схемы компоновки целиком в одно хранилище значения, которая позволяет оптимизировать ее выполнение
И разделение схемы и компоновщика с возможностью иметь несколько компоновщиков.
****************
Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2015 CONNECTION 15-17 октября 2015 года.
Приглашаем вас на новую конференцию INFOSTART EVENT 2019 INCEPTION.
