Парсить dd-файл. Там все есть.
Есть и парсеры готовые наверняка.
Есть и информация по тому, как время понять.
Но это все - на ресурсах по 1С, т.к. это чисто 1С-овские вопрсы.

Здесь я тебе посоветовал бы выгружать данные из 1С в промежуточное хранилище и делать куб на его основе. На этом пути есть варианты :)

Хотя уважаемый г-н Иванов со мной не согласится

разные базы, разные конфы... не парь мозги. Выгружай средствами 1С в специально подготовленную базу.
Придется подумать о состыковке измерений - товары, контрагенты, склады...
Остальное - элементарно.

У меня такая база (из 5 баз 1С, две - на основе 1С-овской конфы 9-й редакции, отличаются друг от друга слегка, остальные - принципиально другая самописная конфигурация) работает почти год уже. Данные выгружаются в Акцессную БД (этого мне хватает, но можно и SQL использовать, почти ничего менять не надо). Для разных баз - отдельные таблицы фактов с одинаковой структурой (просто для удобства) и на основе этих таблиц фактов - свои партиции.
Инфа дополняется ночью, автоматически. Погружается с замещением начиная с самого раннего измененного документа и по последний. Разумеется, только из актуальной базы.
С состыковкой контрагентов и номенклатуры пришлось повозиться, но вроде справился.

Сделано все на основе первой версии Акселератора Любимова. Можно сделать самостоятельно на основе свободной информации, находящейся на его сайте http://www.1bi.ru , надо только влезть в старую версию.

Есть и другой вариант - купить у него новую версию :) Сурово, но универсально.

Товарищ Владимир Иванов, если я не ошибаюсь, это именно меня Вы приняли за Деда Мастдая. Ошибочка вышла - мы с ним совсем даже и не похожи.

Отвечая на поставленный вопрос - да, Любимов.
А теперь предложите другой вариант, исходя из следующих условий:
1. База 1С - в формате dbf и на sql переход даже сейчас не планируется.
2. Используется терминальный сервер.
3. Лишнего сервера нет.
4. OLAP-сервер легко и непринужденно ставится на терминал и спокойно на нем работает.
5. SQL-сервер может быть установлен на терминал, но с некоторым геморроем, и делать такое не рекомендуется.
6. Access на терминале установлен и работает без проблем.
7. Производительности Access-а достаточно - выгрузка происходит ночью, времени хватает, используется MOLAP - так что при построении запросов хранилище не задействовано.
8. Я - ярый сторонник построения OLAP-кубов на основе промежуточного хранилища, а не на OLTP-базе (это - типа религии. Одни верят в одно, другие - в другое, и спорить бесполезно )

Итак, если вариант с Access-ом не оптимальный - укажите лучший.

Я ничего не имею против дискуссии на форуме - вопрос вполне в тематике, но если Вы предпочитаете дискуссию мылом - тоже никаких возражений.

Не надо решать свои проблемы за мой счет :) Вы конкурируете с Любимовым - и ладно. Конкуренция - это хорошо. Но утверждать без всяких оснований, что он поставил мне пиратское ПО - нехорошо.
Для ясности - не ставил. Наша организация купила у него только модуль выгрузки, шаблоны кубов и лицензионного клиента.

Даже имея лицензию на MS SQL вовсе не обязательно переводить на него базу 1С. Особенно если dbf вполне хватает. MS SQL может иметь в организации и совсем другие области применения :)

Я не спорю с тем, MS SQL лучше, чем Access. Просто для нас Access-а вполне достаточно. Последнее обновление данных заняло 8 минут 34 секунды. ИМХО оптимизация не оправдана :)

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

P.S. Как "встроенный" программист подчиненный начальнику IT-отдела, я смело отсекаю все вопросы о лицензионности нашего ПО. Не мой уровень компетенции :)
Есть у нас лицензии на самом деле.

2 Владимир Иванов

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

Кубы дорабатываются нечасто. При нашей скорости обновления кубов ускорение понадобилось бы только в случае 3-4-х модификаций в день... реально - раз в 3-4 месяца. Или реже. Что называется, сделал и забыл - все работает само.
Drill Through не используется... хотя, возможно, его использование могло бы быть полезным.

Если бы Вы внимательно читали мои посты, то знали бы, что выгружаются данные из торговли, и что делается дозагрузка данных. В идеале - за один день, это если не было исправлений задним числом. 400 000 движений за один день у нас не бывает - так уж получилось, мы - скорее средние, чем крупные :)

Сейчас я делаю новый вариант, в котором будут объединяться данные 3-х наших организаций. SQL использоваться будет, в основном из-за наличия DTS - этот сервис понадобится. Опять же будет хранилище, даже несколько - по одному на каждую базу плюс общее, куда будут сливаться данные. OLTP-базы физически находятся в разных местах. В разных городах, точнее. Уж тут-то необходимость в хранилище очевидна, надеюсь

2 Владимир Иванов

Я не дед, я дядя :)

Имелась в виду дозагрузка в хранилище. Процессинг делается для для всей базы. Как уже упоминалось - мы средние :)
Кроме того, первоначальная обработка проводится в момент подготовки хранилища, так что данные находятся в нужном виде (схема "звезда", практически нет нормализации) и лишних данных нет.

Так как кубы строятся не для финансовой отчетности, а для анализа продаж, при изменеии задним числом делается замещение информации. Этого достаточно (в нашем случае).