Comments 16
с несбалансированными иерархическими справочниками нормально работает?
да и вообще, почему бы не открывать окно сводной сразу в 1с?
ну, как в клюшках с десяток лет назад?
да и вообще, почему бы не открывать окно сводной сразу в 1с?
ну, как в клюшках с десяток лет назад?
0
с несбалансированными иерархическими справочниками нормально работает?:
— иерархии все гуд: функцию пишем сама себя вызывает, получается любое количество ветвлений…
да и вообще, почему бы не открывать окно сводной сразу в 1с?
ну, как в клюшках с десяток лет назад?:
— в OLAPе мы получаем отдельную БД освобождающую от нагрузки транзакционную базу и удобную структуру для формирования отчетности.
Спасибо!
— иерархии все гуд: функцию пишем сама себя вызывает, получается любое количество ветвлений…
да и вообще, почему бы не открывать окно сводной сразу в 1с?
ну, как в клюшках с десяток лет назад?:
— в OLAPе мы получаем отдельную БД освобождающую от нагрузки транзакционную базу и удобную структуру для формирования отчетности.
Спасибо!
0
так ничего не мешает формировать отдельный куб, а показывать его внутри 1с.
типа так
0
- Негибко
- Нужно отделять мух от котлет. Пытаться подтянуть все в одну систему, пусть даже она является чисто интерфейсной, в данном случае, — плохая практика. Сбор данных из куба в Excel или PowerBI, со всеми их доп. возможностями, не то же самое, что просматривать их в ProClarity
Если речь идет о статическом отчете, а куб используется для быстроты получения данных, то здесь еще можно понять, однако при таком раскладе нужно учитывать затраты на разработку и поддержку этой модели, а также на затраты по оборудованию, допуск по временному лагу на пополнение куба и т.д.
0
UFO just landed and posted this here
Есть же решения для ТСД с похожей схемой взаимодействия.
0
А разве наше законодательство не превращает этот пункт соглашения в ничто?
0
OData — что мешает использовать?
0
Способ конечно интересный, но в чем реальный профит, по сравнению с выгрузкой данных из 1С в виде огромной простыни, которую пользователь будет самостоятельно крутить в EXCEL, если уж ему так принципиально использовать именно его?
Ну т.е. конечно, то что «в 1С сложно создавать отчеты известно всем», кроме возможно меня и других разработчиков знакомых с 1С, но вы в примере сделали простейший отчет, который делается в 1С минут за 10, при этом для этого вам понадобилось сделать частичную копию базы, которую придется регулярно актуализировать (что может привести к проблемам, при изменении структуры таблиц в 1С), а сам отчет строите по данным из документов (что с точки зрения идеологии 1С не верно).
Ну т.е. конечно, то что «в 1С сложно создавать отчеты известно всем», кроме возможно меня и других разработчиков знакомых с 1С, но вы в примере сделали простейший отчет, который делается в 1С минут за 10, при этом для этого вам понадобилось сделать частичную копию базы, которую придется регулярно актуализировать (что может привести к проблемам, при изменении структуры таблиц в 1С), а сам отчет строите по данным из документов (что с точки зрения идеологии 1С не верно).
0
но в чем реальный профит, по сравнению с выгрузкой данных из 1С в виде огромной простыни, которую пользователь будет самостоятельно крутить в EXCELпрофит в постоянной готовности данных к формированию, без нагрузки на транзакционную БД, пользователь может формировать любой длинны простыню, не мешая напр. внесению данных.
В остальном скажу что на github в исходниках лежит проект с загрузкой данных по регистрам в том числе.
В данном примере не делаются конкретные отчеты, а предоставляются возможности для пользователя в виде набора показателей, которые можно накидывать в эксельке как нравится и сохранять у себя на рабочем столе, открыли и обновили данные.
0
По поводу законности доступа к базам 1С я думаю можно сильно не переживать, лет 5 назад мы писали сходный продукт «Корпоративная аналитика для 1С», который закрыт уже давненько, так он носил гордую табличку «1C-Совместимо» :)
Там подход был чуть другой: описание базы выгружалось в XML, на него натравливалась программа на C## которая строила DTSX пакеты для создания хранилища и OLAP кубов, потом эти пакеты запускались и все делали. Ну и структура того что надо было получить описывалась в справочниках 1С. Оно там конечно более развито было, но и писалось около 5 лет двумя людьми. А в этом решении есть смысл подумать о использовании дополнительного плана обмена для регистрации изменений. Тогда есть шанс получить инкрементальную выгрузку за короткое время.
Там подход был чуть другой: описание базы выгружалось в XML, на него натравливалась программа на C## которая строила DTSX пакеты для создания хранилища и OLAP кубов, потом эти пакеты запускались и все делали. Ну и структура того что надо было получить описывалась в справочниках 1С. Оно там конечно более развито было, но и писалось около 5 лет двумя людьми. А в этом решении есть смысл подумать о использовании дополнительного плана обмена для регистрации изменений. Тогда есть шанс получить инкрементальную выгрузку за короткое время.
0
программисты что угодно смогут сделать! :)
главное все документировать и создавать код по стандартам!
0
Sign up to leave a comment.
Создание системы отчетности для 1С:ERP на базе OLAP и Excel