Чего не хватает из аналитической информации?

[ollu]

Приветствую честной народ!

Вопрос скорее к профессиональным пользователям Акзапты: при выборе нового ЕRP решения, возник вопрос о возможностях системы в предоставлении аналитической информации. Продавцы (внедренцы) в один голос твердят, что есть ВСЁ, но меня интересует ЧЕГО НЕТ. Может кто-то сталкивался с тем, что нельзя сделать или можно, но с огромными затратами времени на копирование ЕКСЕЛей, ручной поиск и "склеивание" и т.д.

Заранее благодарю!

[lev]

а по каким модулям вас интересует аналитическая информация?
какую версию Аксапты вы рассматриваете?

[mazzy]

Цитата:

Сообщение от ollu

Вопрос скорее к профессиональным пользователям Акзапты: при выборе нового ЕRP решения, возник вопрос о возможностях системы в предоставлении аналитической информации. Продавцы (внедренцы) в один голос твердят, что есть ВСЁ, но меня интересует ЧЕГО НЕТ. Может кто-то сталкивался с тем, что нельзя сделать или можно, но с огромными затратами времени на копирование ЕКСЕЛей, ручной поиск и "склеивание" и т.д.

ВСЕ - нехорошее слово.
Как только появляется слово ВСЕ - жди логической ошибки.

ВСЕГО в аксапте конечно же нет.
но анализировать то, что введено можно. и даже с удобствами.

из того, что сделать можно, но с огромными затратами, можно отметить анализ по таблицам, связь между записыми которых n:n. Например, LedgerTrans, TaxTrans, BankTrans, CustTrans, VendTrans и, конечно же, InventTrans связаны неоднозначным отношением n:n. И если не предпринимать специальных мер, то связывать записи между этими таблицами - сущий гемор. Т.е. запрос "дайте оборотку по 62 счету в разрезе клиентов" реализуется непросто, если заранее не предпринять предупредительных мер по ограничению аксаптовского функционала (хотя бы потому, что проводки по клиенту могут пойти и на 76).

Но зато запрос "дайте оборотку в разрезе любимых клиентов" делается на ура.
или запрос "дайте анализ какие клиенты какой товар купили" тоже реализуется быстро.

[ollu]

Рассматриваем обе 4 и 5 (больше склоняемся к 4-й, наверное спецов больше). Есть большая разница? Ориентируемся на стандартный пакет, охватывающий :
1. Sales
2. Failed Orders
3. Purchases
4. Purchase Orders
5. Distribution (between organization units)
6. Internal Operations (inside organization)
7. Stock
8. Raw materials
9. Raw material analysis and inspection
10. Production
11. GLOperations
12. GLAssetOperations

Из аналитики интересуют всякие нестандартные срезы, например: консолидированная информация по нескольким предприятиям по основным средствам.

[mazzy]

Цитата:

Сообщение от ollu

12. GLAssetOperations

как интересно... это сознательный выбор? а почему модуль буржуйских ОС, а не российский модуль?

Цитата:

Сообщение от ollu

Из аналитики интересуют всякие нестандартные срезы, например: консолидированная информация по нескольким предприятиям по основным средствам.

Будет информация в системе, можно будет получить срез.

Обратите внимание, что консолидированная отчетность отличается от простого суммирования тем, что из консолидированной отчетности после суммирования удалены внутренние обороты. В Аксапте есть инструменты для маркировки внутренних оборотов. Но будете ли вы этой маркировкой пользоваться? Не знаю. Будете ли сами вводить какой-то свой маркер внутренних оборотов? тоже не знаю.

В общем, суммированную по разным компаниям отчетность вы получите легко. А вот получите ли консолидированную? Ответ будет зависеть от того, как именно вы будете вводить информацию.

[ollu]

Цитата:

как интересно... это сознательный выбор? а почему модуль буржуйских ОС, а не российский модуль?

Иностранная компания.

Цитата:

из того, что сделать можно, но с огромными затратами, можно отметить анализ по таблицам, связь между записыми которых n:n. Например, LedgerTrans, TaxTrans, BankTrans, CustTrans, VendTrans и, конечно же, InventTrans связаны неоднозначным отношением n:n. И если не предпринимать специальных мер, то связывать записи между этими таблицами - сущий гемор. Т.е. запрос "дайте оборотку по 62 счету в разрезе клиентов" реализуется непросто, если заранее не предпринять предупредительных мер по ограничению аксаптовского функционала (хотя бы потому, что проводки по клиенту могут пойти и на 76).

Вот это уже интереснее. Может ещё какие примеры?


Ещё один ньюанс: база большая (поэтому и Аксапта), планируется или "чужой" DWH или "свой" ОЛАП. Никто не может сказать где граница когда ОЛАП не справится с задачей (ограничение по времени) или что-то ещё?

Что думаете про ОЛАП кубы? Почему-то иносранцы их любят, а мы нет, может пользоваться не умеем?

[mazzy]

Цитата:

Сообщение от ollu

Иностранная компания.

а... это хорошо. значит таких безумных запросов типа "дайте оборотку по 62 в разерезе клиентов" у вас будет значительно меньше.

Цитата:

Сообщение от ollu

Ещё один ньюанс: база большая (поэтому и Аксапта), планируется или "чужой" DWH или "свой" ОЛАП. Никто не может сказать где граница когда ОЛАП не справится с задачей (ограничение по времени) или что-то ещё?

Что думаете про ОЛАП кубы? Почему-то иносранцы их любят, а мы нет, может пользоваться не умеем?

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

А использовать ОЛАП на Аксапте (или на других проклятобуржуинских программах) - милое дело.

ОЛАП не даст вам оперативных данных. По определению.
А в остальном - нормально.

[mazzy]

Цитата:

Сообщение от ollu

Вот это уже интереснее. Может ещё какие примеры?

Да, и еще.

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

Поищите, этот вопрос обсуждался неоднократно на форуме.
Но если у вас "иносранцы", то для них это привычная схема работы и вопросов должно быть существенно меньше, нежели у наших бухов.

[ollu]

Цитата:

Сообщение от mazzy

а... это хорошо. значит таких безумных запросов типа "дайте оборотку по 62 в разерезе клиентов" у вас будет значительно меньше.

Помоему наоборот. Бывают попытки проследить совершенно нелогические связи, особенно, когда в Хранилище есть данные из других систем.

Цитата:

Сообщение от mazzy

ОЛАП не даст вам оперативных данных. По определению.
А в остальном - нормально.

Точно всё нормально? А построение ОЛАПов - дело простое\дешевое? Я, теоретически, понимаю что можно вытянуть все данные, грамотно их обработать и подать на блюдечку пользователю. Но если пользователь - аналитик, причём желающий знать ВСЁ и со всех сторон - то мне хотелось бы сразу ему сказать: "Сорри, надо было думать сначала, а то система уже выбрана, внедрена, а запросы на изменения\дополнения стоят сумашедших ресурсов!!!"

Поэтому и возникают вопросы: что нельзя сделать в малокастомизированной аксапте?

[mazzy]

Цитата:

Сообщение от ollu

Бывают попытки проследить совершенно нелогические связи, особенно, когда в Хранилище есть данные из других систем.

Цитата:

Сообщение от ollu

Точно всё нормально? А построение ОЛАПов - дело простое\дешевое?

По-моему, да.
причем, по-моему, гораздо проще построить запросы руками, нежели пользоваться стандартным модулем связи с ОЛАПом.

Обратите внимание, что стандартный модуль связи с ОЛАПом будет решать вопросы, связанные с валютами и их курсами (но по-моему, проще руками запрос сделать).

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

Кроме того, как всегда с ОЛАПом возникает вопрос корретного drill Down к исходным данным, которые вдобавок находятся в другой программе. Но это типовая для ОЛАПа проблема.

В общем, по-моему, особых проблем нет.
Есть технические проблемы, типичные для всех ОЛАПов: связи N:N, курсы валют, витруальные компании, права доступа и drill down.

Пару лет назад один участник пытался продать набор ОЛАП отчетов для Аксапты. Но у него продажи не очень пошли поскольку заинтересованные лица считали, что проще сделать нежели покупать. В результате он выложил набор отчетов в бесплатный доступ. Поищите.

[ollu]

Цитата:

Сообщение от mazzy

По-моему, да.
причем, по-моему, гораздо проще построить запросы руками, нежели пользоваться стандартным модулем связи с ОЛАПом.

Обратите внимание, что стандартный модуль связи с ОЛАПом будет решать вопросы, связанные с валютами и их курсами (но по-моему, проще руками запрос сделать).

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

mazzy, Вы всё время говорите, проще сделать запрос руками !!! В этом отличие иносранного пользователя - аналитика (не говорю про супер умных) - пользоватся только тем что есть в системе!!! Если хочешь дёрнуть ИТ, то нужно обоснование и если это одноразовый запрос, то приоритет № последний...

Поэтому и ищу ответ на вопрос: чего нет (и не может быть) в мало модифицированной системе?

[mazzy]

Цитата:

Сообщение от ollu

mazzy, Вы всё время говорите, проще сделать запрос руками !!!

Не. пользователи не должны делать запросы.
запрос должен подготовить аналитик/программист.
пользователи должны пользоваться подготовленными.

просто для аналитика/программиста есть два способа создания: 1) встроенный модуль business analisys, 2) создать запрос (и сам куб) руками непосредственно инструментарием ОЛАП системы.

после того, как аналитик/программист создаст запрос (и соответственно куб), то пользователю будет абсолютно все равно как он создан. использовать его будут одинаково.

на что надо обратить внимание, я уже ответил.

[mazzy]

Цитата:

Сообщение от ollu

пользоватся только тем что есть в системе!!!

что-то у меня закралось нехорошее предчувствие, что вы поиском не пользуетесь

Вы бы посмотрели кубы которые уже есть в стандартной Аксапте.
начните отсюда
Microsoft Dynamics AX 2009 White Paper: Configure the Default OLAP Cubes

и далее
Дрилл в OLAP-отчетах
Ax 2009 OLAP
Вопросы по OLAP в DAX2009
Slava09: Microsoft Dynamics AX 2009. Что нового?
OLAP: Главная книга - Журнал налоговых регистров
OLAP in AX4
и далее в поиск.

[greenfin]

[QUOTE=mazzy;192797]
Muzzy, неверное замечание в части: "запрос "дайте оборотку по 62 счету в разрезе клиентов" реализуется непросто, если заранее не предпринять предупредительных мер по ограничению аксаптовского функционала (хотя бы потому, что проводки по клиенту могут пойти и на 76)."

А как же профиль разноски, в котором задается синтетический счет для учета задолженности по клиенту. Не доработка профиля разноски - отсутствие периодичности. Хотя решается плодением новых профилей разноски в случае изменения синтетического счета в будущем.

А в части недостатков по аналитике, (имею ввиду финансовую аналитику, Dimension), несколькими предложениями:
-нет возможности указания разных аналитик (для дебета и кредита) в одной проводке;
-финансовые аналитики, предлагаемые в стандартном функционале НИКАК не вяжутся с аналитикой синтетического счета, которую хотят видеть бухгалтера РФ.
Данную аналитику можно пользовать только в управленческом учете.
Получать информацию (действительно необходимую) в разрезе аналитик, используя таблицу "Ledgertrans" и не заставляя при этом пользователя дублировать её ввод - без доработки не обойтись.

[mazzy]

Цитата:

Сообщение от greenfin

А как же профиль разноски, в котором задается синтетический счет для учета задолженности по клиенту. Не доработка профиля разноски - отсутствие периодичности. Хотя решается плодением новых профилей разноски в случае изменения синтетического счета в будущем.

я про это и говорю - сначала думать надо.

Цитата:

Сообщение от greenfin

А в части недостатков по аналитике, (имею ввиду финансовую аналитику, Dimension), несколькими предложениями:
-нет возможности указания разных аналитик (для дебета и кредита) в одной проводке;

FAQ: используйте многострочную проводку

Цитата:

Сообщение от greenfin

-финансовые аналитики, предлагаемые в стандартном функционале НИКАК не вяжутся с аналитикой синтетического счета, которую хотят видеть бухгалтера РФ.

Потому что бухгалтера просят у вас "субконто", а финансовая аналитика - похожа на "разделитель учета". FAQ и в поиск. обсуждалось раз 20.

Цитата:

Сообщение от greenfin

Данную аналитику можно пользовать только в управленческом учете.

Конечно же нет.

Цитата:

Сообщение от greenfin

Получать информацию (действительно необходимую) в разрезе аналитик, используя таблицу "Ledgertrans" и не заставляя при этом пользователя дублировать её ввод - без доработки не обойтись.

конечно же обойтись. только не надо из фин.аналитики делать "субконто".
воспринимайте ledgertrans как проводки по синтетическому плану счетов (но с разделителями учета), а аналитическую информацию берите из модулей-регистров. (В предыдущем предложении использовалась 1Совская терминология). Только учитывайте, что связи между ledgerTrans и прочими могут быть как многие-ко-многим при некоторых допущениях, учитывайте и настраивайте допущения. (В этом предложении использовалась Аксаптовская терминология). В общем, сначала думать надо.

Опять же: в FAQ и в поиск. Обсуждалось тыщу раз.

И наконец,

Цитата:

Сообщение от greenfin

А в части недостатков по аналитике...

greenfin, вы исходный вопрос читали? "Чего не хватает из аналитической информации?"
Вы разницу между "аналитикой" и "аналитической информацией" понимаете?


В сторону: как же задолбали 1Сники, которые делают свою 1С из любой программы. И ведь сам таким был. Невыносимо...

[Vadik]

Цитата:

Сообщение от mazzy

Обратите внимание, что стандартный модуль связи с ОЛАПом будет решать вопросы, связанные с валютами и их курсами

Все верно, решает, только таким затратным способом (таблица OlapAmount, что начиная с более-менее значительных объемов данных (когда по идее прелести OLAP-а в виде быстрой реакции на тяжелые аналитиеские запросы только-только становятся очевидны) поддерживать ЭТО становится слишком накладно.
Пример - стандартный (идущий в поставке) куб с Sales margin. Средствами аксапты один экземпляр куба обновляется около 4 часов, самодельный T-SQL запрос отрабатывает за 30 секунд. Ну и нафига спрашивается козе баян?
Дальше.. Dimensions аксаптовский OLAP обновлять не умеет без повторного пересоздания куба, которое в свою очередь похерит пользовательские роли.
В общем, IMHO для демонстрации на пресэйлах в стиле "как можно за 5 минут построить с ноля гламурную сводную таблицу" - то что надо, а для использования в production - пилить и пилить

[Vals]

Цитата:

Пару лет назад один участник пытался продать набор ОЛАП отчетов для Аксапты. Но у него продажи не очень пошли поскольку заинтересованные лица считали, что проще сделать нежели покупать. В результате он выложил набор отчетов в бесплатный доступ. Поищите.

Да, это был набор настроенных отчётов (достаточно большой) - AxOlap.

[TasmanianDevil]

Цитата:

Сообщение от mazzy

FAQ: используйте многострочную проводку

В журналах ОС и складских журналах ?

[greenfin]

Mazzy: "вы исходный вопрос читали? "Чего не хватает из аналитической информации?"
Вы разницу между "аналитикой" и "аналитической информацией" понимаете?"

Что бы получать аналитическую информацию для этого в базе должна быть информация о хоз.операциях с детализацией не меньше чем это требуется для выполнения АХД и принятия решений. В своем сообщении рассматривал только «кусок» в части отражения на синтетических счетах («LedgerTrans»).

Mazzy:"конечно же обойтись. только не надо из фин.аналитики делать "субконто".
воспринимайте ledgertrans как проводки по синтетическому плану счетов (но с разделителями учета), а аналитическую информацию берите из модулей-регистров. (В предыдущем предложении использовалась 1Совская терминология). Только учитывайте, что связи между ledgerTrans и прочими могут быть как многие-ко-многим при некоторых допущениях, учитывайте и настраивайте допущения. (В этом предложении использовалась Аксаптовская терминология). В общем, сначала думать надо."

Из Dimension никто не делает субконто. В ledgertrans не хватает аналитики, используемой конкретным синт.счетом. А для получения информации с учетом аналитики используемой счетом предлагаете джойнить таблицы, содержащие данную информацию. Согласен, но только если база не больших размеров. А если в базе делается запись только в одном InventTrans за месяц примерно 1,5 – 2 млн.строк (учел только в финн.статусе), тогда отчет в on-line режиме «не дождаться». Для закрытых периодов используем хранилище по сгруппированным аналитическим срезам.

Mazzy:"используйте многострочную проводку..."

Это не удобно и времени занимает больше, нежели если была бы возмжность раздельного ввода. На другие недостатки указали уже другие участники.

[AlexeyS]

Цитата:

Сообщение от mazzy

а... это хорошо. значит таких безумных запросов типа "дайте оборотку по 62 в разерезе клиентов" у вас будет значительно меньше.


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

А использовать ОЛАП на Аксапте (или на других проклятобуржуинских программах) - милое дело.

на 1с тоже делают олап, видел давненько какую-то фирму, брала по 1000 долларов за кубик. правда прошло много времени, могу немного ошибаться

Цитата:

Сообщение от mazzy

ОЛАП не даст вам оперативных данных. По определению.
А в остальном - нормально.

можно сделать инкрементное обновление раз в час или чаще. хоть каждые пять минут, вполне оперативно.