Показатель, которого нет вне отчёта: как страховая отдала маржу в BI

У этой задачи обманчиво простая формулировка: “отдайте в нашу аналитическую платформу показатель из 1С”. Руководство хочет видеть ключевые цифры компании на дашборде, а не просить бухгалтерию “сформировать и прислать”.

Для страховой компании из нашей практики таким показателем была фактическая маржа платёжеспособности - величина, за которой следит регулятор. И тут выяснилась неприятная особенность: показателя… не существует. Точнее - он существует только внутри интерактивного отчёта: пользователь открывает форму, задаёт дату, нажимает “Сформировать” - и на экране появляется строка с цифрой. Не нажал - цифры нет ни в какой таблице, ни в каком регистре. Она нигде не хранится, она каждый раз вычисляется.

А платформа дёргает сервис сама, по расписанию, и человека с кнопкой в этой схеме нет.

Три пути - и почему два из них плохие

Путь 1: робот, нажимающий кнопку. Регламентное задание формирует отчёт по расписанию и складывает результат в таблицу, сервис читает из таблицы. Работает, пока не спросят цифру на дату между запусками - а её нет. Плюс в базе появляется хранилище промежуточных результатов, которое надо чистить, версионировать и объяснять аудитору.

Путь 2: новые объекты в конфигурации. Завести регистр “Показатели для BI”, дорабатывать закрытие периода, чтобы он заполнялся. Основательно - и несоразмерно: ради одного числа появляется новая учётная сущность, которую надо сопровождать вечно. Заказчик сформулировал требование прямо: “не плодить объекты в конфигурации ради одного числа”.

Путь 3: считать “в моменте”. Разобраться, как именно отчёт вычисляет показатель, и перенести расчёт в код HTTP-сервиса. Запрос пришёл - сервис посчитал по данным учёта на запрошенную дату - отдал. Ничего не хранится, ничего не формируется заранее, новых объектов нет.

Мы пошли третьим путём, и почти вся сложность оказалась не в программировании.

Где на самом деле была работа

Найти правильный источник. В конфигурации оказалось два отчёта с похожими названиями, считающих по-разному. Ошибиться в выборе - значит отдавать в BI цифру, которая не совпадает с той, что уходит регулятору, и обнаружить это в самый неподходящий момент. Разбор “какой из отчётов - тот самый и почему” занял заметную часть работы, и это была самая важная её часть.

Разложить формулу. Нужная строка считалась как разность трёх других строк отчёта, каждая - по своим счетам. Это хорошая новость: показатель воспроизводим из данных учёта напрямую, без обращения к “внутренностям” отчёта.

Совпасть копейка в копейку. Отдельно выверялись даты (на какой момент берутся остатки) и округление. Критерий приёмки один: сервис и интерактивный отчёт на одну дату дают одинаковую цифру. Любое “почти совпадает” означало бы, что в компании появились две версии правды - на дашборде одна, у регулятора другая.

Результат

Сервис отдаёт фактическую маржу платёжеспособности на любую запрошенную дату, работает в продуктиве, объектов в конфигурации не прибавилось. Руководство видит показатель на дашборде тогда, когда хочет, - а не тогда, когда у бухгалтерии дошли руки.

Если у вас похожая задача - три вопроса перед стартом

1. Показатель хранится или вычисляется? Если вычисляется - “выгрузить его” нельзя, можно только воспроизвести расчёт.
2. Какой отчёт - эталонный? Если форм с похожими названиями несколько, сверьтесь с той, из которой цифра уходит регулятору или руководству.
3. Как будете доказывать совпадение? Критерий “сервис = отчёт, копейка в копейку, на нескольких датах” стоит зафиксировать до начала работ.

HTTP-сервисы для BI и аналитических платформ (со строгой проверкой параметров на входе) - одно из основных направлений нашего сопровождения страховых компаний: за четыре месяца на них ушло 80 из 400 часов кейса. Если ваша платформа ждёт цифру, которой “нет”, - напишите в чат, разберём вашу схему.

Проверяйте итог на той детализации, для которой задано правило

Для кросс-таблицы нужен отдельный контроль строк, групп и общего результата. В разборе расхождения итога СКД с суммой строк приведён маленький набор для такой проверки, включая отсутствующий предыдущий период. Это помогает отделить неверную формулу от другого бизнес-смысла показателя.