В продолжение темы "Идеи числового тестирования" .

Аццкий динамический OLAP-анализатор БД с функцией сравнительного анализа множеств записей

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

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

Тема реально актуальная. Хороший пример:
1. Эталонный отчет - оборотка FI по счетам выручки
2. Самописный отчет - отчет по выручке на основе логистических таблиц VBRK/VBRP.

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

Виктор, можно поподробнее описать смысл последнего окошка в скриншоте?
Не очень понятна логика его формирования.

Посмотрел в системе структуру и содержимое таблицы SFLIGHT - понял логику последнего окна.

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

Возможные значения:
1.) Записи совпадают;
2.) Только в ITAB1;
3.) Только в ITAB2;
4.) Записи отличаются.
В дальнейшем планирую добавить возможность настройки этих текстов пользователем.
"Записи отличаются" - значит, записи есть (т.е. значения их ключевых полей совпадают) и в ITAB1, и в ITAB2, но отличаются значениями каких-либо неключевых полей.

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

Кстати, возвращаясь к моему примеру.
Часто эталонный отчет - это "черный ящик", который по сути своей сложнее одного запроса к таблице БД.
Все что мы можем - это сформирровать этот эталонный отчет и выгрузить его в excel или еще куда-нибудь.

Это я к тому, что инструмент будет гораздо более полезен, если в качестве источника данных можно будет указать не только таблицу в БД SAP, но и табличку в Excel.

Да, согласен, думаю над этим. Честно говоря - изначально так и задумывал. Чтобы можно было дернуть внутреннюю табличку прямиком из другой программы. Только пока не додумал, как сделать, поэтому для начала решил сделать попроще.


Кстати да, отличная идея.
И сделать можно просто и быстро (как раз ведь свою тулзу для Ёкселя недавно выложил). Прикручу сегодня-завтра.

Придумал "биплатное" альтернативное решение при помощи сводных таблиц в Excel.

http://slil.ru/26646420

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

Конечно, если речь идет о Ритейл системе с миллионами строк в каждой таблице, то Excel не потянет.
А вот сравнить первоначальные остатки в Excel, с результатами их же загрузки в САП - очень даже.

Я подобный анализ тоже делал, с помощью стандартных Екселевских формул. К сожалению, подобное средство ничем не поможет в случае, если исходный массив данных можно получить только с помощью сложных запросов с использованием OUTER JOIN, агрегатных функций и т.п., а программа, которая может выбрыть эти данные и выгрузить их в Excel, еще не написана.