Bankir.Ru
3 декабря, суббота 01:23

Объявление

Свернуть

Третья ежегодная конференция-консилиум «ИТ-бюджет банка - 2017»

Показать больше
Показать меньше

Принципы реализации отчетности

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • Принципы реализации отчетности

    Предлагаю обсудить общие принципы технической реализации отчетности в АБС и не только, обязательной (ЦБ) и не только, и т.п.
    Различие подходов фирм-разработчиков, служб атоматизации и пользователей отчетов.

    Для начала тема первая.

    Чтобы не описывать долго суть, приведу два примера реализации одного и того же отчета ЦБ "Форма NNN".
    Начало одинаковое: автоматически формируется итоговая печатная форма с данными, рассчитаными на основе информации, хранящейся в Системе.
    Далее, если пользователь хочет проверить результаты (показатели), отраженные в форме, то он:
    1. пользуясь профессиональными знаниями, знанием алгоритмов построения отчета, знанием возможносте
    *Д.Ж*

  • #2
    Ой, палец сорвался... Продолжу мысль.

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

    2. в интерактивном режиме кликает мышкой на требуемом показателе (прямо на экранной форме отчета) и получает на экране подробную расшифровку (список объектов и их реквизитов), однозначно показывающую на основе каких данных этот показатель был рассчитан.

    Вопросы:
    - какой из вариантов реализации хотелось бы видеть?
    - какой используется на самом деле? почему?
    *Д.Ж*

    Комментарий


    • #3
      dj_nsk По-моему, Вариант 2. - из области "полу-реальной фантастики"...
      Есть ещё...
      Вариант 0. Когда "Готовая" отчётная форма выводится в текстовый файл, а потом в неё подставляются недостающие реквизиты, которые аналитик находит пользуясь профессиональными знаниями, знанием алгоритмов построения отчета, знанием возможностей Системы
      Именно этот - такой вариант чаще встречается в Банках...
      Да пребудет с Тобою Великая Сила! ©

      Комментарий


      • #4
        dj_nsk
        Безусловно первый вариант используется в подавляющем количестве случаев, т.к. он проще в реализации. Для проверки иногда вместе с отчетом выводится протокол, по которому и идет выверка.
        Второй вариант чаще используется для получения аналитической отчетности, т.е. на условно постоянных данных. При этом применяются спец. методы: либо OLAP кубы, либо спецшаблон, в котором клик на показателе вызывает отдельный запрос к источнику (в упрощенном виде это может быть сводная таблица EXCEL)
        Обязательная отчетность у нас в основном делается по первому варианту, причем делаем специальные несводные (детальные) отчеты для проверки сводных. По второму варианту делаем аналитическую отчетность, причем используем все три опимсанных мной варианта.
        Технические аспекты: если вы делаете сводный отчет SQL запросом, то вы в принципе не будете иметь расшифровок сводных данных. Для OLAP куба надо формировать таблицу фактов и перегружать куб, что для быстроизменяющихся оперативных данных долго и неудобно. Шаблон с дополнительными ссылками/запросами сложнее в реализации автоматизаторами. Но надо честно признать, что этот вариант макимально удобен пользователям. При этом можно использовать HTML, но лучше сделать его в EXCEL (любят они его )

        Комментарий


        • #5
          К_Маркелов Именно этот - такой вариант чаще встречается в Банках - ой, только не надо подтверждать мои собственные мрачные мысли
          Хочется увидеть передовой опыт или, хотя бы, идеи...

          А то я еще вариант "-1" могу предложить. Аналитик набивает в MultiEdit'е печатную форму отчета, берет все бумажные документы и ...
          *Д.Ж*

          Комментарий


          • #6
            dj_nsk Видите, не всё так мрачно... Кроме "мрачного" меня, есть ещё передовой arcадий!!!
            arc Как я понимаю, второй вариант ВЫ САМИ реализовали поверх АБС "Кворум". Как я понимаю, хранилище (с OLAP кубами) тоже Банком написано?
            Да пребудет с Тобою Великая Сила! ©

            Комментарий


            • #7
              К_Маркелов
              есть ещё передовой ... спасибо за комплимент.
              Как я понимаю, хранилище (с OLAP кубами) тоже Банком написано?
              Вы все правильно понимаете Если бы не текучка, то можно было бы много хороших вещей на благо родному банку сделать

              dj_nsk
              Хочется увидеть передовой опыт или, хотя бы, идеи...
              Да боюсь, что все светлые идеи уже реализованы или как минимум описаны. Аналитику по моему наиболее реально делать на собственном Хранилище Данных (а строить его можно с любой помощью). Из инструментария можно посмотреть Actuate www.actuate.ru , а можно просто написать обычное свое приложение, которое делает запрос к источникам и выбрасывает результат в EXCEL, а все остальное написать на VBA. Хороший инструментарий системно лучше, но дороже , своя программа вроде как дешевле, но тоже требует серьезного подхода к своей архитектуре если вы хотите, чтобы из готового отчета вызывались другие отчеты - здесь не обойтись без применения сервера приложений.
              Для обязательной отчетности необходим обычный репортер и хранимая процедура для подготовки данных. Выверять правильность данных в БД можно с помощью аналитических отчетов по каждой предметной области.

              Комментарий


              • #8
                arc
                Спасибо. Идеи я понял.
                Странно, что ответов мало - из Разработчиков, например, никто не отозвался. Подозреваю, это потому, что все они склоняются к варианту 1, как к более простому в реализации.

                Следующая интересная тема:
                Предположим, что вы получили готовый отчет (в любом из описанных вариантов). Проверили его и нашли ошибку, вызванную некорректным отражением операций в АБС.
                Что должен делать ответсвенный за сдачу этого отчета:
                а) имея соответствующие полномочия, заставить допустившего ошибку пользователя исправить ошибочно отраженную операцию?
                б) непосредственно исправить результат формирования отчета, сохранить где-то и учитывать исправления при последующих расчетах?
                *Д.Ж*

                Комментарий


                • #9
                  dj_nsk
                  Вариант б) может быть рассмотрен только в том случае, когда отчетность например за год составляется из сохраненных отчетов за месяцы (кварталы) - только тогда можно править отчет. Если же отчетность получается каждый раз из БД, то безусловно вариант а). Я ввобще полагаю, что вариант а) при любом раскладе самый правильный

                  Комментарий


                  • #10
                    dj_nsk ВАриАнт А) = АднАзнАчнА...
                    Да пребудет с Тобою Великая Сила! ©

                    Комментарий


                    • #11
                      arc вариант а) при любом раскладе самый правильный
                      К_Маркелов ВАриАнт А) = АднАзнАчнА

                      Ага, а теперь попробуйте сказать, что делать, если ошибка была сделана в балансе позапрошлой недели, а обнаружена за пол-часа до того момента, когда уже необходимо сдавать в ЦБ?
                      И при ответе поставьте себя на место того, кто этот отчет должен сдать - какими механизмами он сможет быстро заставить сделать исправления прошлой датой сотрудника не своего подразделения?
                      *Д.Ж*

                      Комментарий


                      • #12
                        dj_nsk
                        Ну, уважаемый, вы привели пример, который не очень относится к инструментарию. Таких форс-мажоров можно привести сколько угодно и под каждый функциональности инструментария не напасешься. Обсуждение все таки идет по ламинарной ситуации.

                        Комментарий


                        • #13
                          dj_nsk ... и роту автоматчиков (с)...
                          Тогда - отчёт править вручную и ... телегу вверх по банковским инстанциям во избежание недопущения впредь...
                          ... Прадва, ещё надо понять, какие именно отчётные формы "поползут"... Иногда проще отправить с ошибкой, но одинаковой, чем в одном месте исправить, а про другие забыть...
                          Насколько мне известно, за несоответствие в отчётности бьют сильнее, а такую, как Вы написали, ошибку можно найти лишь при аудите.
                          А ЕСЛИ СЕРЬЁЗНО, ТО ДЕЛАЕТЕ СТОРНО-ПРОВОДКУ... И тогда никаких законов не нарушаете...
                          Ой! В бухгалтерию потянуло...
                          Да пребудет с Тобою Великая Сила! ©

                          Комментарий


                          • #14
                            arc Ну, уважаемый... - да ладно, это была небольшая провокация
                            Просто я попытался привести те доводы, против варианта а), которые приводят мне.
                            Ответ, на мой взгляд, прост. Если допущенная ошибка настолько очевидна, что ее может увидеть специалист по отчетности, не сильно-то и разбирающийся в тонкостях конкретных банковских операций, причем за пол-часа до сдачи отчета, значит надо лишь организовать процедуры своевременного контроля (оповещения) для таких ошибок и оргмеры по быстрому их исправлению.

                            Очень длинное предложение получилось, но суть, надеюсь, понятна.
                            *Д.Ж*

                            Комментарий


                            • #15
                              К_Маркелов А ЕСЛИ СЕРЬЁЗНО, ТО ДЕЛАЕТЕ СТОРНО-ПРОВОДКУ
                              - не проходит. Во-первых, "сторно-проводку" не может сделать тот, кто формирует отчет (а зачастую даже и тот, кто ошибку допустил, тоже сделать не может), значит придется еще искать и уговаривать соответствующего сотрудника. Во-вторых, могут быть различные ограничения из-за давности срока (это же не во вчерашнем дне править), например, технические.
                              *Д.Ж*

                              Комментарий


                              • #16
                                dj_nsk
                                А какие могут быть технические ограничения на то, чтобы сделать сторнирующую проводку?

                                еще искать и уговаривать
                                А че его уговаривать? Они у Вас там дикие что-ли все?
                                Вы сдаете "неправильный" отчет, вам в итоге (вполне возможно) выставляют штрафные санкции, т.о. персонаж, не уговорившийся сделать сторно автоматически подставляет банк на бабки, которые у него благополучно вычитаются из чего-нибудь Думаю при таком подходе его особо не надо будет уговаривать

                                Идея надо лишь организовать процедуры своевременного контроля (оповещения) для таких ошибок и оргмеры по быстрому их исправлению сама по себе замечательна, но возможна только в случае полной формализованности операций Если есть операция, допускающая хоть какую вариативность, это уже сложнее

                                Комментарий


                                • #17
                                  dj_nsk - у нас много чего из отчетности = вариант 1), если бы даже и был вариант 2) я и его бы проверяла как вариант1)

                                  Зато такая отчетность как баланс (оборотка) позволяет с ним работать именно в таком режиме - клик на экран - проваливаешься в оборотку по нужным балансовым, выписку по любому лицевому, из выписки в документ. Поэтому ф.603, ф.501, можно сказать, могу проверять как вариант 2)

                                  а) ага, попробуй исправить ошибку в квартальном отчете, если ф.101 уже сдана)))). Никакой правки))))). Тока сторно и факт наличия недостоверного отчета)))). Или ежедневная ф.634))))), там такая графа "сумма активов", коснесси ее - получишь недостоверку)))).

                                  vsv А какие могут быть технические ограничения на то, чтобы сделать сторнирующую проводку? - тока временные))))).

                                  Комментарий


                                  • #18
                                    vsv А че его уговаривать - ну, как ДОЛЖНО быть, я и сам понимаю так же ясно, как ясно вижу (уже не в первом банке), какэто бывает на самом деле... И что самое интересное, обычно виновата оказывается автоматизация

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

                                    Buzik Зато такая отчетность ... позволяет - ну такие простые варианты рассматривать не интересно, т.к. в них это реализовать достаточно легко.

                                    Ну почему же разработчики молчат...
                                    *Д.Ж*

                                    Комментарий


                                    • #19
                                      dj_nsk Это фантастика©

                                      Нефига - не фантастика. Бисквит отчетность формирует так как описано в п.2 сабжа.

                                      Именно ОЛАП, формирование цифры можно посмотреть, также можно посмотреть формулу, связанные классы, используеммые данные... есть история формул и история данных. Они взаимосвязанны и пересчет старых данных(если потребовалось) идет на основании старых формул.

                                      ЗЫЖ Может я и преукрасил - но стремились они(БИСовцы) именно к этому.
                                      Подавая сигналы в рог будь всегда справедлив, но строг. ©

                                      Комментарий


                                      • #20
                                        Вот сдес http://www.bis.ru/bq2.htm#olap они что-то описали. Мне понравилось:
                                        Принципы построения многомерной АБД

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

                                        Реализацию АБД можно назвать моделью "Вложенных Гиперкубов". Здесь жестко определен один внешний гиперкуб с измерениями "Подразделение" (субъект учета) и "Время" (дата или период отчетности). В каждой ячейке, ограниченной этими измерениями, может существовать любое количество гиперкубов ("классов данных"), каждый из которых, в свою очередь, определен измерениями, указанными для него в словаре данных АБД.

                                        Данная схема является лишь частным случаем многомерной модели данных. Она ни в чем не противоречит принципам построения такой модели, но дает большие преимущества в объемных характеристиках, позволяя избежать необходимости хранения показателей с неопределенными значениями, которые неизбежно возникают в случае полной равноправности всех измерений показателя в классической модели.
                                        Серьёзнейшая формулировка!
                                        Подавая сигналы в рог будь всегда справедлив, но строг. ©

                                        Комментарий


                                        • #21
                                          dj_nsk ну такие простые варианты рассматривать не интересно, т.к. в них это реализовать достаточно легко. - когда полностью справишьси с ф.401 - напиши)))))).

                                          Комментарий


                                          • #22
                                            Romsan Канонический подход к многомерной организации данных основывается Хороший текст, как раз для привлечения клиентов-покупателей
                                            Дальше там про отчетность написано и нет ни намека на вариант 2).
                                            Т.е., как я понимаю, в OLAP мы постыпаем так: простые цифирки закачиваются в базу, на их основе всяческими агрегатами расчитываются более сложные и тоже сохраняются в базе (вот тут-то их и можно детальн расшифровать). А уж отчет (формирование выходной формы) их просто берет и вставляет куда надо. Так?

                                            Buzik справишьси с ф.401 - напиши Да я уже своими руками почти ничего не делаю
                                            А так - справился бы, куда б делся...
                                            Я вообще считаю, что всю обязательную отчетность в принципе можно автоматизировать (на то у нее и второе название есть - "строгая"). Просто сложности возникают даже не с технической стороны (что нам стоит пару реквизитов в БД добавить?), а с чисто организационной (как теперь пользователей заставить эти реквизиты вовремя и корректно заполнять).
                                            Только не надо ответов вида "зачем заставлять? они должны это делать!" - плавали, знаем
                                            *Д.Ж*

                                            Комментарий


                                            • #23
                                              dj_nsk пачти так.
                                              Первичные данные формируются одновременно с "закрытием дня"(условная опирация ограничения возможности вносить изменения). Фактически в ОЛАП кладется весь баланс. Есть несколько состояний хранения данных - вплоть до принудительной фиксации с невозможностью пересчитать.
                                              Далее уже можно считать отчеты, ибо механизм построен на схеме взаимосвязей, и расчет ФОРа прежде всего вызовет расчет нормативов(условно говоря). В зависимости от статуса исходных и промежуточных данных можно заставить их пересчитаться, при этом результат будет сохранен(или не сохранен) для всей цепочки. Сам отчет, как лист бумаги или файл заданного формата - вопрос третий и практически не конфликтный.

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

                                              Комментарий


                                              • #24
                                                dj_nsk
                                                Только не надо ответов вида "зачем заставлять? они должны это делать!" - плавали, знаем
                                                Тогда не надо задавать глупых вопросов

                                                Отвечу так: Это не наша забота
                                                Мы предоставляем механизм, корректная работа которого требует от пользователей определенного набора действий Мы, конечно, должны свести его к разумному минимуму, но вряд ли есть у нас в банках полные идиоты, которые искренне верят, что они будут приходить на работу нажимать одну кнопочку (желательно большую и красную) и им из дисковода будет зарплата вылазить
                                                Так ведь?

                                                dj_nsk
                                                А так - справился бы, куда б делся...
                                                А я пишу... И ф. 401 - не такая тривиальная и "строгая", как может показаться

                                                dj_nsk
                                                Т.е., как я понимаю, в OLAP мы постыпаем так:...
                                                Ага
                                                Зачем 20 раз пересчитывать уже готовый отчет?
                                                Вот ежели будут какие-то изменения... Но если делать все корректно, т.е. как пример исключить правку в архиве и работать исключительно сторнирующими, тогда вроде как и проблем особых нет

                                                Комментарий


                                                • #25
                                                  vsv вряд ли есть у нас в банках - ну, настолько, наверное, и нету. Но тенденция отслеживается... Неужели это только мне не везет? Почему-то уже не раз приходилось доказывать бизнесу, что для того чтобы показать какуюто информацию в АБС (в данном случае - в отчете) необходимо, что бы кто-то как-то туда эту информацию внес.
                                                  Неужели у других все не так? "Тогда мы идем к вам!"

                                                  ф. 401 - не такая тривиальная и "строгая", как может показатьс - Перенимая Ваш подход из предыдущего абзаца (я, кстати, согласен, что он правильный, только не жизненный :0) - это не наши проблемы, а проблемы отчетников, которые не могут достаточно точно формализовать постановку задачи. Сами-то они как-то этот отчет получают? А описать не могут? Вот...

                                                  Ладно, я основные ответы на свои вопросы получил (или не получил, что тоже имеет значение ). Спасибо всем участникам.
                                                  *Д.Ж*

                                                  Комментарий


                                                  • #26
                                                    dj_nsk
                                                    Сами-то они как-то этот отчет получают? А описать не могут? Вот...
                                                    Именно

                                                    Неужели у других все не так?
                                                    Собственно для этого (среди прочего) и существуют ТЗ Но это уже немного другая тема

                                                    Комментарий


                                                    • #27
                                                      Здравствуйте Уважемые,

                                                      Могу предложить следующую концепцию постоения отчетности.

                                                      1. Отчетность ЦБ и управленческая есть две большие разницы и рассматирать их необходимо отдельно друг от друга.
                                                      2. Управленческая отчетность стоится на основании данных информационной системы по варианту 1. Т.е. корректорвка данных после выполнения запроса не предполагается. Возможность проваливаться в агрегатный показатель - укарашательство и может рассматриваться отдельно и потом.
                                                      3. Отчетность для контролирующих органов, в т.ч. ЦБ необходимо хранить в информационной системе в сформированном виде.
                                                      4. Проблема "подгонки" и т.п. решается введением таблицы корректировок для каждого хранимого значения.
                                                      5. Хранимые данные используются для формирования отчетов более высокого уровня с учетом корректировок.
                                                      6. Хранить в ИС модель иерархии отчетных форм.
                                                      7. Реализовать состояния отчетных форм. "подготовка", "на подписи", "утверждено"
                                                      8. Реализовать функцию отката состояний в формах высокого уровня при изменении форм низших уровней.

                                                      Что нам это дает.
                                                      1. Адекватность управленческой отчетности.
                                                      2. Гибкость формирования отчетности ЦБ.
                                                      3. Распредение процесса подготовки форм по подразделениям банка.
                                                      4. Персональную отвественность составителей за формы.
                                                      5. Перенос составления отчетности в информационную систему, т.е. безбумажную технологию!!!
                                                      С Уважением
                                                      Blender

                                                      Комментарий


                                                      • #28
                                                        Blender
                                                        Со многим согласен, но часть - очень спорная, а спорить пока не хочется

                                                        Только один вопрос - это в какой-то степени уже реализовано или только идея?
                                                        *Д.Ж*

                                                        Комментарий


                                                        • #29
                                                          Уважаемый D.J.

                                                          Я не разработчик ИС.
                                                          Приведенные утверждения есть изложение накопленного опыта как программиста (в т.ч. и по отчетости), в прошлом, так и бухгалтера (потребителя и составителя отчетности) в настоящем.
                                                          С Уважением
                                                          Blender

                                                          Комментарий


                                                          • #30
                                                            В жизни не видела автоматизированной ф.401, так что не выпендривайтесь со своими концепциями))))))).
                                                            ФОР и тот глючит у большинства периодически, так что...))))))))))))))

                                                            Про концепции - это вы можете начальству заливать...

                                                            Комментарий

                                                            Пользователи, просматривающие эту тему

                                                            Свернуть

                                                            Присутствует 1. Участников: 0, гостей: 1.

                                                            Обработка...
                                                            X