Качество данных, попадающих в учетную систему на платформе 1С - один из важных факторов эффективного использования системы. Как обеспечить это качество за разумные средства?
Отчасти эту задачу решает сама система. Например, Управление производственным предприятием не позволит вам купить услугу на склад - спасибо ему за это. Но легко позволит отнести товар, например, на бухгалтерский счет 69.06.3 "Взносы в ФОМС" - как и на любой другой балансовый счет.
А дело тут вот в чем.
Во-первых, большинство программ 1С - очень доверчивые. И чем больше и сложнее программа, тем больше она доверяет пользователю.
Во-вторых, почти все внутренние проверки конфигураций предназначены для грубой, черновой проверки данных, и правильность анализируется с точки зрения разработчика, а не с точки зрения методиста или заведующего учетом предприятия-клиента. Цель таких проверок, в основном - чтобы программа работала, а не чтобы учет корректный был.
В-третьих, в конфигурациях нет единого механизма контроля качества данных. Есть небольшие, локальные "проверяльщики" с непохожими друг на друга механизмами настройки.
Работа пользователей реального предприятия в учетной системе требует принципиально иного подхода к контролю качества данных. Одна из главных особенностей такого контроля - он должен работать к данным системы.
Например:
- Если мы продаем со счета 10.01, то счет доходов должен быть 91.01, иначе - 90.01;
- В требовании-накладной на основное производство, если номенклатура из папки "Металл", то статья затрат должна быть "Металлы основного производства";
- В заказе покупателя обязательно должен быть указан грузополучатель и его адрес;
- Если в плане ДДС указано подразделение "Отдел продаж", то расход денег может быть только наличный.
- И т.д.
Если поручить программисту реализовать такие проверки, то он сразу заскучает. И будет писать код, за который потом самому будет стыдно - искать данные по коду или наименованию, добавлять константы или какие-нибудь регистры для хранения этих самых "металлов" и "отделов продаж".
В большинстве случаев остаются только старые средства офлайн-проверки - консоль отчетов, групповая обработка справочников и документов, небольшие специализированные отчеты, заточенные под конкретные ошибки. Решение тоже достаточно грустное, хотя и выхода обычно нет.
Но теперь есть повод для радости - появилось решение Проверка данных.
Если кратко, то это настраиваемая в пользовательском режиме проверка документов и справочников.
Основные возможности и особенности:
- Проверять можно любой справочник или документ, который есть в вашей программе на платформе 1С;
- Работает в любой конфигурации на платформе 1С, начиная с версии 8.2.16;
- Проверка выполняется при записи. Если проверка не прошла - записать не даст;
- Настраивать - не сложнее, чем делать отбор в отчетах;
- При желании и соответствующих навыках, для реализации проверки можно писать произвольный запрос через СКД;
- Можно на время отключить проверки для определенных пользователей. Например, для группового перепроведения документов;
- Можно массово проверить старые справочники и документы по новым проверкам (а не только при записи);
- Замер производительности - оценит, насколько увеличилось время записи/проведения при включении проверки;
- Разные варианты исполнения проверок с точки зрения производительности.
В итоге, с помощью Проверки данных вы создадите обучаемую систему контроля для своей учетной системы.
Вы сами научите ее, что правильно, а что нет, как нужно делать а как - не стоит. Вам понравится.
Производительность
При разработке продукта особое внимание мы уделили производительности. Искали и пробовали различные варианты, общались с партнерами и разработчиками 1С, проводили тесты на реальном предприятии в течение нескольких месяцев.
В итоге мы получили результаты, которыми гордимся.
Первое и главное - мы научили систему делать несколько проверок одним запросом. Запрос - это самая "тяжелая" часть проверки, когда идет обращение к базе данных.
Например, на картинке, приведенной ниже, показано, что при записи заказа поставщику будет выполнено 4 проверки - и все одним запросом.
Второе, не менее важное - мы реализовали несколько вариантов исполнения проверки.
Наличие нескольких режимов - результат нашей борьбы за производительность. Универсального способа сделать проверку быстро и красиво, увы, платформа нам не дает. Поэтому мы использовали все возможности, лазейки, обходные пути и нетривиальные решения, чтобы не нагружать вашу систему.
Простой вариант
В этом варианте запрос и все его параметры заполняются автоматически.
Вы лишь настраиваете отборы и пишете тексты сообщений - также, как это делается в типовых отчетах.
Но и в простом варианте нашлось место оптимизации - если установить флаг "Проверять объект непосредственно", то обращения к базе данных не будет происходить вообще.
Это самый оптимальный способ исполнения, для несложных проверок - но таких, по нашему опыту порядка 30 %.
У этого, первого способа исполнения, есть особенность: если в проверке использовать вложенные поля, то производительность начинает снижаться. Так происходит потому, что вложенное поле - это т.н. "разыменование ссылки", т.е. неявный запрос к базе данных. Наша система эту особенность знает, и честно вас предупредит об использовании вложенных полей - выдаст рекомендацию поменять вариант.
Если флаг "Проверять объект непосредственно" снять, то получится второй способ исполнения - выполнение запроса. Это самый распространенный режим исполнения, в котором работают примерно 40 % проверок. Его производительность несколько ниже, чем у первого способа.
Сложный вариант
Сложный вариант отличается тем, что становится доступно редактирование схемы компоновки, которая исполняется при проверке. Такой вариант используется, когда для проверки справочника/документа нужно знать нечто большее, чем его реквизиты. Например, остатки или какие-либо настройки. Этот вариант используется, как правило, только программистами, т.к. требует специализированных знаний.
Сложный вариант имеет три способа исполнения.
Первый способ - самый "тяжелый" с точки зрения производительности, т.к. при проверке будет исполняться схема целиком. На практике применяется редко, когда нужна архисложная проверка - не более 2 %.
Второй способ - преобразование схемы в макет компоновки. Формирование макета компоновки - самый длинный этап программного выполнения схемы. Но на это обращают внимание не все разработчики - и мы в числе тех, кто не сразу заметил, что макет компоновки можно создать заранее, а потом просто выполнять. И что бы вы думали - время выполнения готового макета в 4 раза меньше, чем выполнение схемы целиком. Мы не могли упустить такую возможность для оптимизации, и этот способ исполнения нашел отражение в продукте.
Подготовленный заранее макет почти ничем не отличается по функциональности от схемы - работают вычисляемые поля, внешние функции, функции вычисления параметров... Но ложка дегтя все-таки есть: в макете нельзя использовать стандартные периоды (Начало сегодняшнего дня, Начало предыдущего месяца и т.д.). При компоновке макета эти периоды вычисляются, и запоминаются уже конкретные даты. На практике такой способ исполнения применяется, но с учетом ограничения - примерно 5 % проверок.
Третий способ - преобразование схемы в запрос. В таком режиме из схемы компоновки "добываются" только текст запроса и значения параметров - и этого, как правило, достаточно. Отдельно отмечу, что текст запроса берется не тот, который написал разработчик, а тот, который формирует сама схема при компоновке. В него, к примеру, включаются все сделанные в схеме отборы (в виде условий).
Не используются вычисляемые поля, внешние функции, но это не страшно - практика показала, что для целей проверки данных эти возможности нужны крайне редко.
Практика показала, что такой режим используется примерно в 20-25 % случаев.
Для контроля производительности, оценки и выбора подходящего режима мы разработали отдельное средство.
Замер производительности
Зная о любви программистов к экспериментам - мы и сами такие - включили в продукт средство измерения производительности проверок.
Суть его проста. Вы указываете конкретный документ или элемент справочника, который хотите проверить, система его записывает и измеряет два показателя:
1. Сколько всего ушло времени на запись;
2. Сколько ушло времени конкретно на проверки.
Результат замера - насколько увеличилось время записи из-за применения проверки:
На скриншоте, например, видно, что проведение заказа поставщику увеличилось на 1.4 - 3.5 %.
19.11.2014 г. - вышла обновленная версия.
Что нового:
1. Исправлен ряд скрытых недочетов;
2. Добавлена возможность создания проверок, которые будут действовать только для новых объектов. Например, при добавлении элементов справочников.
04.03.2016 г. - вышла обновленная версия.
Добавлен учет срабатывания проверок. Когда срабатывает какая-либо проверка, то информация об этом записывается в регистр сведений.
Сохраняется дата срабатывания, имя пользователя и текст сообщения.
Для анализа срабатывания проверок за период добавлен отчет "Эффективность проверок". Отчет показывает, какие проверки, у каких пользователей срабатывали в течение периода.
В отчете два предопределенных варианта - "По проверкам" и "По объектам".
Отчет может использоваться для разных целей.
Например, можно вычислять пользователей, которые натыкаются на одни и те же грабли и ничему их жизнь не учит.
Или проанализировать, на каких объектах (документах, справочниках) проверки срабатывают чаще всего и понять, почему так происходит - возможно, объект проверки слишком сложен для пользователей, и ошибки при его заполнении неизбежны.
17.08.2017 г.
Конфигурация и инструкция теперь в одном файле, по минимально возможной стоимости (1 sm).
