К слову, Mad Maxx. Если можно поясни вот какие моменты.
Обычно для построения OLAP-отчетности для 1С достаточно сделать 2-5 относительно сложных view на регистры и проводки, и примерно 10-20 фактически одинаковых view на справочники.
Написать view на справочники из 2х строк не сможет только полный идиот.

Я согласен, что в принципе с технической точки зрения это элементарная операция. Но достаточно трудоемкая - ведь чтобы сделать вью на каждый из 10-20 справочников надо для каждого найти его описание в dds файле и ручками перенести его в энтерпрайз менеджер. Наше же средство дает возможность просто поставить галочки против необходимых Вам справочников.

Далее. Интересно как Вы выгружаете перечисления. Ведь они хранятся в md файле. Наша утилита создает для них таблицы. А Вы, как я понимаю, перебиваете их ручками.



Сделать view вынимающие фактом можно в готовом виде только для стандартных конфигураций, но для этого "генератор" не нужен. У клиентов в нише "1С + SQL" обычно несколько разных баз и в разной структуре, плюс свои заморочки. Поэтому приходится делать довольно сложный SQL-запрос для вытягивания данных. Сгенерировать его автоматом для реальных систем фактически невозможно. Еще более сложно сопровождать такой генерированный запрос. Если это view, то даже в самых сложных случаях можно проблему победить через SQL-запрос.
Я согласен, что для сложных и нетиповых случаев необходимо писать запрос вручную, но для типичных случаев в этом нет необходимости. Ведь принципы хранения данных для всех регистров одинаковы. Более того, если разработчик хочет написать вью руками, это ему никто не мешает сделать - можно воспользоваться только частью функционала Adelite:ETL и выгрузить только справочники и перечисления. Причем можно выгрузить подчиненные справочники в виде уровней в справочнике, которым они подчинены. И сделать на этой таблице удобное измерение.


Например, мой клиент производящий "Помарин" и прочую косметику (АленМак) столкнулся с проблемой разной структуры номенклатуры в своих конфигурациях. 1 час отладки и удалось склеить номенклатуры с разными деревьями.
Эта проблема решается с помощью введения уникальных кодов и таблиц соответствия.


Делать хранилища для такой простой системы как 1С, на мой взгляд в большинстве случае неправдано. Только тормоза добавляет.



На мой взгляд, генератор SQL-запросов может быть полезен корп. разработчикам, которые не состоянии сделать простейший select ... from и не желают повышать свою квалификацию в SQL.
Но много ли таких? Мне кажется нет, корп. разработчики не идиоты, в это я точно верю.
Совершенно не согласен. Есть вещи которые однозначно имеет смысл делать с помощью визуальных средств, тем более что это не исключает возможности использования низкоуровневых. Для примера - интерфейсы в программе пищут на Visual Basic, а драйвер на ассемблере или C. И делается это не от того, что разработчики не в состоянии написать интерфейс на С. Просто для каждого случая выбирается наиболее адекватное средство.