История реализации проекта по системе контроля обязательной отчетности ЦБ
Те, кто знаком с процедурами подготовки, проверки и сдачи обязательной банковской отчетности в ЦБ, не понаслышке знают, что такое вовремя сдать и не пропустить ни одну циферку в оных. А еще они знают, что такое KLIKO, ПТК-ПСД, Обвед, и прочие «шедевры» от ЦБ. Так вышло, что уже много лет я являюсь одним из этих «знатоков».
В определенный момент времени, когда наша филиальная сеть достаточно расширилась, а объемы сдаваемой отчетности возросли и стали все сложнее, возник резонный вопрос – а нельзя ли как-то автоматизировать тяжелый этап контроля, который далеко не всегда полностью реализован в штатных ЦБ-шных программах подготовки? И вопрос был адресован мне. Я ответил, что надо подумать, и направление это весьма интересное. Так начался этап проектирования системы, которая позволила бы не пропускать ни одну мелочь во взаимосвязанных данных отчетов, а также являлась бы хранилищем копий при возможных «разборах полетов», ежели что…
Зная любовь ЦБ к постоянным изменениям требований по формам отчетности, и представляя, как часто пришлось бы патчить таблицы базы, а так же понимая, что необходимо сохранять историю этих изменений, нарисовал я себе достаточно монструозную картину хранилища. А затем пришла спасительная мысль – что, если хранить отчетность не в жестких таблицах, а в бинарных BLOB-полях? Определиться с базовым форматом, и вливать в базу файлы в неизмененном виде, а другие форматы сначала конвертировать в базовый, и затем тоже вливать как есть. Базовым форматом был выбран стандарт KLIKO, т.к. мы используем именно его. Филиалы работают в альтернативных ПТК и обвед, для них – преконвертация. Идея состояла в том, чтобы грузить, проверять и хранить конечные файлы, которые подготовлены на отправку, дабы свести возможность последующей правки данных к нулю. Следует разъяснить, что собой представляет формат KLIKO: Это текстовый файл в кодировке 866, состоящий из строк, в которых каждый элемент данных обрамлен двойными кавычками и разделен запятой. Вот так! В свое время много «добрых» слов было высказано и еще больше произнесено мысленно в адрес такой прекрасной задумки, но некуда деться с «подводной лодки» — имеем, что имеем. Следующий этап состоял в создании универсальной координатной функции извлечения данных из такого массива по указанным параметрам поиска. Обычно в таких файлах первым – вторым элементом массива было нечто определяющее, вроде балансового счета, признака – актив/пассив, символа доходов/расходов, ОКАТО и т.д. Функция получала параметры в виде алиаса отчета, значений ключевых полей поиска с применением масок, их позиции и позицию поля, которую необходимо вернуть в результате. Затем был разработан прекомпилятор/интерпретатор скрипт-языка, на котором описывается полный цикл проверки: ресурсы языка позволяют открывать любые загруженные отчеты, присваивая им алиасы, объявлять динамические переменные, организовывать условия ветвления и вложенные циклы с динамической подстановкой элементов циклов в тело скрипт-блоков. Имеются опции прекомпилятору, позволяющие скрипту самомодифицироваться, размножая внутри себя указания на открытие группы загруженных отчетов и элементов скрипт-блоков, ссылающихся на эту группу по критерию активных на дату проверки филиалов. Скрипт-блоки являются законченной единицей вычислений, состоящей из произвольного количества вызовов координатной функции и динамических переменных с применением арифметических правил к ним, как к единицам данных. Скипт-блоки различаются по типам – либо простой блок, возвращающий результат в лог или динамическую переменную, либо сложный блок, состоящий из двух половинок, между которыми проставлен знак сравнения с возможностью введения погрешности. Сложный блок также возвращает значение логического типа True/False в динамическую переменную, либо при пустом вызове и False результате – выставляется глобальная переменная неудачной проверки. Все скрипт-блоки опционально условные. Можно указать в заголовке блока логическое выражение, определяющее выполнение/пропуск блока. Все динамические переменные могут использоваться в вычислениях и опциях выполнения всех скрипт-блоков, устанавливая между ними зависимости.
Так появился достаточно гибкий и скрупулезный механизм проверки отчетов внутри самих себя и между разными формами, либо сводных отчетов и отчетов филиалов, который не раз выручал и выискивал такие тонкие детали, которые вручную очень непросто отследить.
Естественно, большое внимание при проектировании было уделено эргономике системы и очевидности процессов. Так, чтобы пользователь не смог «опрокинуть» систему неосторожным изменением параметров. Конечно же, параллельно была спроектирована подсистема тотального аудита и подсистема контроля доступа, позволяющая ограничивать пользователей по типам отчетности и вариантам действий с нею. Было сложно, но очень интересно создавать это все, «от» и «до» собственными силами, не пользуясь никакими сторонними или стандартными библиотеками. Это позволяло создать и саму систему и скрипт язык именно таким, каким я их задумывал. Собственноручно написанный парсинг, модуль прекомпиляции и интерпретатор скрипт-кода позволял разработать модель удобную именно для программирования контроля отчетности.
Теперь, если ЦБ в очередной раз меняет формат отчета, ответом становится небольшая правка кода в теле скрипта проверки этого отчета и… все!
В определенный момент времени, когда наша филиальная сеть достаточно расширилась, а объемы сдаваемой отчетности возросли и стали все сложнее, возник резонный вопрос – а нельзя ли как-то автоматизировать тяжелый этап контроля, который далеко не всегда полностью реализован в штатных ЦБ-шных программах подготовки? И вопрос был адресован мне. Я ответил, что надо подумать, и направление это весьма интересное. Так начался этап проектирования системы, которая позволила бы не пропускать ни одну мелочь во взаимосвязанных данных отчетов, а также являлась бы хранилищем копий при возможных «разборах полетов», ежели что…
Зная любовь ЦБ к постоянным изменениям требований по формам отчетности, и представляя, как часто пришлось бы патчить таблицы базы, а так же понимая, что необходимо сохранять историю этих изменений, нарисовал я себе достаточно монструозную картину хранилища. А затем пришла спасительная мысль – что, если хранить отчетность не в жестких таблицах, а в бинарных BLOB-полях? Определиться с базовым форматом, и вливать в базу файлы в неизмененном виде, а другие форматы сначала конвертировать в базовый, и затем тоже вливать как есть. Базовым форматом был выбран стандарт KLIKO, т.к. мы используем именно его. Филиалы работают в альтернативных ПТК и обвед, для них – преконвертация. Идея состояла в том, чтобы грузить, проверять и хранить конечные файлы, которые подготовлены на отправку, дабы свести возможность последующей правки данных к нулю. Следует разъяснить, что собой представляет формат KLIKO: Это текстовый файл в кодировке 866, состоящий из строк, в которых каждый элемент данных обрамлен двойными кавычками и разделен запятой. Вот так! В свое время много «добрых» слов было высказано и еще больше произнесено мысленно в адрес такой прекрасной задумки, но некуда деться с «подводной лодки» — имеем, что имеем. Следующий этап состоял в создании универсальной координатной функции извлечения данных из такого массива по указанным параметрам поиска. Обычно в таких файлах первым – вторым элементом массива было нечто определяющее, вроде балансового счета, признака – актив/пассив, символа доходов/расходов, ОКАТО и т.д. Функция получала параметры в виде алиаса отчета, значений ключевых полей поиска с применением масок, их позиции и позицию поля, которую необходимо вернуть в результате. Затем был разработан прекомпилятор/интерпретатор скрипт-языка, на котором описывается полный цикл проверки: ресурсы языка позволяют открывать любые загруженные отчеты, присваивая им алиасы, объявлять динамические переменные, организовывать условия ветвления и вложенные циклы с динамической подстановкой элементов циклов в тело скрипт-блоков. Имеются опции прекомпилятору, позволяющие скрипту самомодифицироваться, размножая внутри себя указания на открытие группы загруженных отчетов и элементов скрипт-блоков, ссылающихся на эту группу по критерию активных на дату проверки филиалов. Скрипт-блоки являются законченной единицей вычислений, состоящей из произвольного количества вызовов координатной функции и динамических переменных с применением арифметических правил к ним, как к единицам данных. Скипт-блоки различаются по типам – либо простой блок, возвращающий результат в лог или динамическую переменную, либо сложный блок, состоящий из двух половинок, между которыми проставлен знак сравнения с возможностью введения погрешности. Сложный блок также возвращает значение логического типа True/False в динамическую переменную, либо при пустом вызове и False результате – выставляется глобальная переменная неудачной проверки. Все скрипт-блоки опционально условные. Можно указать в заголовке блока логическое выражение, определяющее выполнение/пропуск блока. Все динамические переменные могут использоваться в вычислениях и опциях выполнения всех скрипт-блоков, устанавливая между ними зависимости.
Так появился достаточно гибкий и скрупулезный механизм проверки отчетов внутри самих себя и между разными формами, либо сводных отчетов и отчетов филиалов, который не раз выручал и выискивал такие тонкие детали, которые вручную очень непросто отследить.
Естественно, большое внимание при проектировании было уделено эргономике системы и очевидности процессов. Так, чтобы пользователь не смог «опрокинуть» систему неосторожным изменением параметров. Конечно же, параллельно была спроектирована подсистема тотального аудита и подсистема контроля доступа, позволяющая ограничивать пользователей по типам отчетности и вариантам действий с нею. Было сложно, но очень интересно создавать это все, «от» и «до» собственными силами, не пользуясь никакими сторонними или стандартными библиотеками. Это позволяло создать и саму систему и скрипт язык именно таким, каким я их задумывал. Собственноручно написанный парсинг, модуль прекомпиляции и интерпретатор скрипт-кода позволял разработать модель удобную именно для программирования контроля отчетности.
Теперь, если ЦБ в очередной раз меняет формат отчета, ответом становится небольшая правка кода в теле скрипта проверки этого отчета и… все!
0 комментариев