Я много раз убеждался на практике, насколько значимую роль в учете играют ошибки. Отрицательную роль, разумеется. Наверное, потому, что когда-то сильно увлекался темой управления качеством.
Если ошибку исправить сразу, а не откладывать на потом, то проблем «потом» будет значительно меньше. Если же оставить ошибку, надеясь, что «потом» будет куча времени на ее исправление, то почти всегда наступает разочарование. «Потом» свободного времени будет ровно столько же, сколько и сейчас – поток текучки ведь никуда не девается, даже если на дворе отчетный период. Ошибки исправляются, конечно – как попало, лишь бы закрылось.
В кризисные моменты цейтнота кажется, что вот теперь-то, как только потушим пожар, мы начнем жить по-другому. Будем следить за качеством первички, отрицательными остатками, незакрытыми авансами и помеченными на удаление корректировками. Конечно будем! Ведь мы столько ночей не спали, столько валидола выпили, пока всё это исправляли, когда на носу висели НДС и налог на прибыль!
Но кризис проходит, и все возвращается на круги своя. Стимул-то пропадает. Получается замкнутый круг: пока есть стимул, нет времени, а когда появляется время, пропадает стимул.
Чтобы разорвать этот замкнутый круг, я придумал «Проверку ведения учета», которая позже стала Консилиумом. А потом – «Проверку данных». Первая должна была проверять данные массово, за большой период и по множеству критериев. Вторая – не давала записывать совсем уж корявые первичные документы.
Со второй всё получилось еще в 2015 году, она разошлась огромными тиражами и до сих пор доступна в интернете. Потом попала в Flowcon, где получила дальнейшее развитие.
А вот с «Проверкой ведения учета» поначалу как-то не складывалось. Мир 1Сников, узнав о сборе проверок для массового инструмента, откликнулся с энтузиазмом, начались обсуждения и предложения. А у меня началась работа. Работоспособный вариант инструмента я сделал, но переступить через порог в 10 проверок так и не смог.
Хотя тандем намечался шикарный, чем-то похожий на антивирус.
Есть сканер – «Проверка ведения учета», который проверяет, по сути, всю информационную базу на все виды ошибок – так же, как это делает антивирус, ищущий признаки наличия вирусов из своей базы в файлах на компьютере.
Есть монитор, или фильтр – «Проверка данных», который не дает ошибке появиться на свет, так же, как антивирус-монитор не дает сохранить заражённый файл из интернета или с внешнего носителя.
Ну и в методическом плане сканер и монитор разделяются прекрасно.
«Проверка данных» - это инструмент для кастомизации на месте, т.е. для реализации проверок, специфичных для конкретного предприятия. Можно запретить запись справочника или документа в любой комбинации фильтров, хоть в зависимости от фазы луны.
«Проверка ведения учета» - это проверка информационной базы по критериям, собранным со всего нашего 1Сного мира. Что важно – здесь могут проверяться не конкретные объекты, вроде справочников и документов, а все возможные комбинации. Например, отрицательные остатки, одновременное сальдо, незакрытые регистры и т.д. Такие проверки невозможно реализовать на уровне записи документа. Во-первых, контекст не подходящий. Во-вторых, они никак не связаны с конкретным документом.
Но, как ни были хороши мои планы, «Проверку ведения учета» я забросил на отметке в 10 проверок. Сначала на партнерской конференции 1С, потом на Инфостарте. Эти 10 проверок стали психологическим порогом, который я в течение нескольких лет не мог преодолеть.
Однако, появился Консилиум.
Консилиум
Долго рассказывать не буду, есть большая статья на тему Консилиума. Кратко изложу суть, чтоб вам два раза не вставать. Консилиум – это отчет, который при формировании скачивает из интернета проверки для конфигурации, выполняет их и показывает результат. Отчет внешний, работает в любой конфигурации, начиная с платформы 8.2. Не для всех конфигураций уже есть проверки, но психологический порог в 10 штук преодолеть удалось давно.
Была в Консилиуме одна бяка – я обещал, что часть проверок будут бесплатными, а часть – по подписке, за деньги. Эдакая маркетинговая какашка, которая портит всё настроение.
Несмотря на эту заморочку, Консилиум разошёлся весьма неплохо. Отчет скачивают, пишут вопросы, предлагают новые проверки. Кто-то в виде словесного описания ошибочных ситуаций, некоторые присылают готовые запросы или схемы компоновки. Идет дело, короче.
Чтобы шло ещё быстрее и интереснее, я решил выкинуть ту самую ложку дёгтя. Отныне Консилиум – полностью бесплатный проект, безо всяких подписок. Отчет работает, как и прежде – ползёт в интернет, скачивает подходящие для конфигурации проверки, выполняет их, сохраняет и показывает статистику. Я даже выкинул оттуда авторизацию – зачем она нужна, если можно работать под анонимом?
Так что пользуйтесь на здоровье и в удовольствие. А я продолжу пополнять базу проверок, на сколько хватает сил и времени.
Проблемы
В процессе эксплуатации тандема «Проверка данных» + «Консилиум» наметились несколько проблем. Ну, не то, чтобы критичных, но довольно неудобных. Первая и главная – куда и как добавлять свои массовые проверки? Фильтры на запись объектов – понятно, вставляются в «Проверку данных». А как быть, если человек хочет проверять все документы разом на соответствие каким-то критериям? Или не документы, а регистры или их комбинацию?
Теоретически, в «Проверке данных» есть режим массовой проверки, но он – корявый. Система просто выбирает все объекты одного типа, и поочередно применяет к каждому из них проверку. С точки зрения производительности – так себе решение, классический запрос в цикле. Вероятно, поэтому таким режимом мало кто пользуется.
В итоге реализуется один из трех сценариев. Либо человек создает проверки в виде внешних отчетов или сохраненных запросов в консоли, либо создает какой-то контейнер для хранения проверок, либо вообще на занимается проверками, оставляя качество данных в неуправляемом состоянии.
Но так жить неудобно – приходится смотреть результаты проверок, как минимум, в двух местах – Консилиуме и каком-то своем. Своих проверок, наверняка, больше, они лучше и качественнее, поэтому, когда встает вопрос о выборе «одного окна», Консилиум однозначно проигрывает.
Вторая проблема – в самом Консилиуме, это отсутствие настроек. Доступны всего три – период, организация и включение/выключение проверки вообще.
Если запустить Консилиум только для того, чтобы «позырить», то проблемы нет – все формируется, показывается и кликается. Но в реальной практике быстро возникает потребность в настройке. Хочется отфильтровать номенклатуру, или не видеть помеченные на удаление документы, не считать ошибкой документы прошлых периодов и т.д.
Третья проблема, традиционная для всех подобных инструментов – как обеспечить исправление ошибок? Ну есть отчет, который их показывает. Посмотрел главбух, увидел, ужаснулся, сказал исправить – это Лене, это Гале, это самому программисту. Дальше что? Каждый день заходить и проверять?
Немного спасает статистика – можно смотреть динамику ошибок по дням, например. Но что из этого должна исполнить Лена, а что – Галя?
Ну и четвертая проблема – сама необходимость куда-то заходить, что-то проверять, за кем-то следить. Представьте, что вы установили антивирус, который очень много о себе мнит. Он знает, что у вас появились вирусы, но скажет вам об этом только после того, как вы пороетесь в меню «Пуск», найдете ярлык, запустите приложение, чего-то поднастроите и немного подождёте. Скучно ведь. Раз зайдешь, другой – и бросишь. Поставишь другой антивирус, который сам сообщит, что обнаружил проблему.
Решения
Мне очень захотелось решить обозначенные проблемы. Сначала хотел реализовать всё это в самом Консилиуме, но столкнулся с ограничениями.
Во-первых, Консилиум – внешний отчет, со всеми вытекающими последствиями. Никакого вмешательства в конфигурацию он делать не может.
Во-вторых, Консилиум не может стать расширением, т.к. в конфигурациях с режимами совместимости такие штуки не работают.
В-третьих, пришлось бы реализовать в Консилиуме парочку универсальных механизмов, которые я уже сделал в другом месте. Где?
В Flowcon, разумеется. Надо просто разделить Консилиум на две части, сохранив максимум общего. В первую очередь – базу проверок.
Встроенный Консилиум
Итак, в последнем релизе Flowcon появился встроенный Консилиум. Это буквально два объекта – справочник «Проверки Консилиум» и отчет «Консилиум».
Про отчет рассказывать не буду – он почти полностью повторяет своего бесплатного собрата, только проверки берет из базы, а не из интернета.
А вот справочник интереснее. По сути, это – ваша база проверок. Но составляете вы ее не в одиночку, а вместе со всем миром.
Красным цветом обвел кнопку, которая загружает проверки из интернета. Раньше этот делал сам отчет при выполнении, теперь эти проверки хранятся в вашей базе. Система автоматически определяет, какие новые проверки есть для вашей конфигурации, и загружает их, а изменившиеся – обновляет. Проверки, загруженные из сервиса, помечаются специальным флагом, чтобы вы их случайно не испортили.
Первое, чем можно похвастаться – возможность настройки. Из интернета скачивается схема компоновки, из нее берутся стандартные настройки (поля, отборы, группировки и т.д.), а дальше – дело за вами.
Можете настраивать, как вам угодно, и при выполнении проверки ваши настройки будут учтены.
Вторая приятная мелочь – теперь можно разложить проверки по папкам. В интернете они лежат плоским списком, и загружаются в справочник так же, но вы можете понаделать групп и растолкать по ним проверки. При загрузке/обновлении иерархия не трогается.
Третья фишка - уже совсем не мелочь. Раз проверки теперь – это справочник, то вы можете создавать их сами. В том числе, копируя загруженные из сервиса. Больше не нужны внешние отчеты, обработки, файлы в консолях и непонятные контейнеры. Все проверки лежат в одном месте, с четким разделением на «наши» и «ихние». А выполняются в одном отчете «Консилиум».
Четвертое – как по мне, так чуть ли не самое главное – возможность быстрого создания простых схем компоновки для тех, кому лень или вообще не понятно, что такое «схема компоновки».
Идея взята из «Проверки данных». Там, если помните, достаточно выбрать тип документа или справочника, который хочется проверить, и сразу можно настраивать отборы. Теперь и здесь почти так же.
Появилась в проверках Консилиума такая чудесная кнопочка:
которая открывает маленькое, приятное окошечко:
где мы выбираем нужный тип объекта для проверки
и схема компоновки создаётся сама, а нам остается лишь настроить нужные отборы, сказав Консилиуму, какие объекты считать ошибочными. Справится не только программист, но и продвинутый пользователь. Собственно, как они справляются с «Проверкой данных».
Ну, а кому хочется делать схемы руками – ради Бога, кнопка вызова редактора есть, развлекайтесь.
Теперь вы можете собрать все свои проверки в одном месте, объединив их с нашими.
Консилиум + Автозадачи
Во-первых – да, в последнем релизе Flowcon появились автозадачи. Пока – почти такие же, какими вы их видели раньше. Но с одной очень прикольной фишкой, о которой расскажу чуть ниже.
Идея объединить проверку качества данных с автозадачами – не моя. Ее как-то высказал один толковый программист на переговорах по распространению Консилиума, за что ему большое спасибо.
Итак, всё просто. Автозадачи, если помните, это просто результат выполнения схемы компоновки, которая говорит, что надо сделать – согласовать какой-то заказ, разместить продукцию у поставщика, добавить пользователя в базу, поздравить клиента и т.д. Проверка – это просто результат выполнения схемы компоновки, которая говорит, какие есть ошибки, но не говорит, что и кому с ними надо делать.
Получается, инструменты очень похожи и стоят на одном базисе – выполнении схемы компоновки. Дальше сами догадываетесь.
Приделываем к проверке Консилиума небольшую логику адресации, как в автозадачах:
Собственно, всё. Теперь с периодичностью, указанной в поле «Расписание», проверка будет выполняться и, если есть ошибки, создастся соответствующая автозадача.
В расшифровке автозадачи будет вся необходимая информация для ее решения - та же, которую выдает Консилиум, только в плоском виде, без группировок.
Но главное – это ведь автозадача! Когда человек исправит часть ошибок, она пересчитается и уменьшится, а если упрётся и устранит все проблемы – автозадача закроется. Сюда же добавьте принцип Айсберг, лежащий в основе автозадач – будут видны и дата появления ошибок, и реальный срок устранения, и история убывания остатка.
При разработке был большой соблазн сделать неудобно – просто как-нибудь соединить автозадачи с проверками, через ссылку, и заставить пользователя мучиться с настройкой не самого простого справочника «Параметры автозадач». Но этот бред, конечно же, я отбросил – там ведь потребовалось бы дублирование схемы компоновки в двух местах.
Поэтому я просто доработал процедуры формирования автозадач, чтобы они брали информацию из двух источников. Поэтому с настройкой автозадач под проверки Консилиума теперь справится пользователь. Единственное непонятное поле – расписание.
Расписания
Расписание выполнения регл.задания в виде справочника? Баг? Нет, фича.
Я много лет сам пользовался автозадачами, переводя на них большинство рутинных и понятных процессов предприятия. Всё мне в них нравилось, кроме одного – формирования всех автозадач разом, в рамках одной сессии регл.задания.
Во-первых, это плохо по производительности. Когда автозадач много, они могут формироваться несколько минут. Значит, нужно всё время расширять расписание – раз в минуту уже не поставишь, регл.задание никогда не завершится.
Во-вторых, автозадачи объективно надо обновлять с разной частотой, которая зависит от частоты изменения соответствующих данных.
Вот есть, например, автозадача вроде «Указать у пользователя физ.лицо» (чтобы запросом получать его контактную информацию, должность и т.д.). Новые пользователи и физ.лица появляются не часто – раз в неделю, а то и раз в квартал. Кажется, было бы достаточно актуализировать автозадачу раз в день.
А есть автозадачи вроде «Согласовать заявку на оплату». Некоторые платежи могут подождать, но есть и такие, что не терпят отлагательства. Значит, неплохо бы их раз в несколько минут обновлять.
А регл.задание-то одно, и расписание у него одно. Вот она и мучилась, пересчитывая всё подряд каждые несколько минут.
Можно, конечно, создать несколько экземпляров регл.задания, но мне такой подход не нравится. Эти демоны не отличаются стабильностью и предсказуемостью, и я каждый раз испытываю трепет, заходя в консоль заданий.
Решение нашлось неожиданно. У объекта типа «РасписаниеРегламентногоЗадания», оказывается, есть такой метод – ТребуетсяВыполнение. Заметьте – у расписания, а не у регл.задания. Расписание, как объект, может существовать само по себе, даже если никакого регл.задания нет и в помине. К тому же, оно сериализуется.
Ну а дальше всё просто. Создал справочник «Расписания», который хранит эти самые расписания. Создаем, настраиваем, записываем, используем.
Еще раз обращаю внимание – без привязки к регл.заданиям. Одно и то же расписание может приняться в автозадачах, проверках Консилиума и, вообще, где угодно.
Дальше – привязка к конкретным объектам. Мы ведь хотим, чтобы разные автозадачи и проверки выполнялись с разной частотой? Не вопрос – просто добавил реквизит в соответствующие справочники. На скриншоте выше показал расписание в проверке Консилиума, а вот оно же в «Параметрах автозадач»:
Дальше всё просто. Есть одно, старое регл.задание «АвтоЗадачи». Ставим ему выполнение через короткие промежутки времени – например, раз в минуту. Только теперь оно не сразу автозадачи формирует, а сначала проверяет, кого пора обрабатывать, а кто может еще подождать. Тем самым методом ТребуетсяВыполнение.
Берет каждую пару «Проверка Консилиум» + «Раписание» и «Параметры автозадач» + «Расписание», смотрит дату последнего выполнения для этой пары, и принимает решение. Если рано – обходит стороной. Если пора – делает, что нужно, и запоминает дату выполнения.
Ну разве не прелесть?
Резюме
Теперь победа над ошибками стала на шаг ближе. Хотя, абсолютной, разумеется, она не будет. Есть ведь еще и вредители, которые делают ошибки сознательно.
Но надежда есть. Главная – на то, что чуть больше людей станут следить за качеством данных, если слежение станет проще, удобнее и интереснее. Собственно, ради этого и старался.
Знаешь вопиющую ошибку, понятную с первого взгляда и никак не допустимую? Не дай ей появиться на свет, настрой фильтр в «Проверке данных».
Знаешь ошибку, которую сразу не разглядишь, потому что она создается комбинацией разных данных? Да, она появится, как тихий паразит, надеясь, что никто не заметит ее появления. Но ты не дай ей такого шанса – настрой проверку в Консилиуме, и не забудь подключить автозадачу. Узнаешь о появлении ошибки в тот же день, или даже минуту.
Не знаешь, какие еще неприятности могут таиться в сложной, но такой интересной типовой конфигурации? Загрузи проверки из сервиса, они помогут найти самых экзотических червяков и букашек, о которых ты, возможно, и не подозревал.
Есть еще несколько идей по управлению качеством данных, так что ждите новых релизов Flowcon.
