Axapta Report Designer vs. Something

[komar]

Говорят, в 3 версии с отчетами по многим компаниям станет намного легче. Хорошо бы!

[Aleck]

А что руководствоваться слухами?
Запустил 3.0 и проверил

[mazzy]

А что уже есть нормальная версия?

Вроде пока только бета была. В которой у объектов еще 2.5 в качестве автора указана...

[Aleck]

Да нет Сергей,

Посмотрел, стоит 3.0 в авторе...

[mazzy]

Круть...

Тогда, похоже, у меня старая бета.
Эх, жаль не успеваю посмотреть по-человечески.
Ладно, жду 15 сентября. А там сам бог велел время выбрать для 3.0

[komar]

Цитата:

Изначально опубликовано Aleck
А что руководствоваться слухами?
Запустил 3.0 и проверил

Тебе, Саша, хорошо, тебе больше делать нечего. Хоть бы сказал, так это, али нет.

[Aleck]

Мне то как раз есть чего

В репортах я такого не заметил, елси ты имел в виду intercompany trading, то, думаю эта фича тебя разочарует.

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

[stranger]

говорят, в 3-й ахапте будет гораздо более дружественный интерфейс. может быть.

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

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

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

Касательно отчетов - я думаю выскажу мнение всех программеров - что это самая слабая нынче часть системы.

Я вижу несколько выходов:
1. Самый простой - использовать внешние генераторы отчетов. Они имеют дружественный интерфейс, мощную функциональность для построения и анализа кубов. Кроме того, можно хорошо сэкономить - не приобретая функциональность по отчетам и заплатив несколько сот долларов за какой-нить Crystal или Cognos. Опять же будут сэкономлены нервы программеров, которые не будут страдать.:-))

Но мы то не ищем легких путей Отсюда второй вариант :
2. Переписать логику отчетов. Известно что параметризованные запросы работают в 5-6 раз быстрее - это раз. Запросы типа select автоматически преобразовываются в select for update - соответственно возникают локи, которые замедляют запросы - выход - использовать динамические запросы. На самом деле очень приятная штука, если разобраться что и к чему.:-)

3. Если со всей энергией подойти к делу переписывания логики отчетов - то скорее всего, рано или поздно - Вы прийдете к выводу - что с самого начала надо было писать свой отчет с самого начала. Вот Вам и третий способ - написать свои отчеты со своей логикой и со своими запросами.

вооот...

[ViGo]

Системы типа Crystal или Cognos тоже стоят не дешево.
Кстати... Кто знает - сколько они стоят?

Где-то слышал, что одно пользовательское место Cognos-а стоит 1500$.
Crystal целиком стоит 5000$. По его пользовательским местам информацией не владею.

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

Вижу пока один выход - процентах в 90 писать новые отчеты.

[undercover]

Поиск скачиваемой полной версии кристал репортс в интернете занимает от 10 мин до 2 часов, в зависимости от способностей к формализации запросов для поисковых систем. Понятно, что имплементаторам это не интересно, но конечным пользователями и девелоперам для общего развитися было бы интересно получить рабочую версию. Было время, когда CR входил в поставку MS VB (5.0 по моему).

Смогут ли конечные пользователи пользоваться этими продуктами, зависит от того, располагают ли они достаточными разработческими ресурсами.
К слову, закодировать экспорт данных в CR можно довольно красиво - через COM интерфейс. С динамической настройкой запроса через стандартное или кастомизированное окно формирования отчета Аксатпа. Изнт ит?

[stranger]

Цитата:

Изначально опубликовано ViGo
Где-то слышал, что одно пользовательское место Cognos-а стоит 1500$.
Crystal целиком стоит 5000$. По его пользовательским местам информацией не владею.

Даже если эти системы обойдутся предприятию в 5-10 тысяч условных единиц - то подумай - час разработки стоит в среднем 50 этих самых единиц , час консультанта где-то также.
На написание дизайна самого простого отчета уходит в среднем 3-5 часов, плюс разработка - 5-10 часов.
Получаем стоимость отчета в среднем - 8-15 часов.

В результате при самых оптимистичных раскладах - клиент который потратит эти самые 5-10 тысяч на разработку отчетов - получит 10-15 отчетов.
и все... и больше ничего...

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

А использование внешних генераторов дает систему, в которой можно создавать n-ное количество отчетов. А также кучу сэкономленных нервов внедренца и клиента.

воот...

[ViGo]

Ага... :-)

Видел тут недавно, как одному клиенту сказали, что, мол, лучше для его сложных отчетов использовать Cognos.
Был получен в ответ вопрос: "А зачем мы тогда такую дорогую систему покупаем, если к ней нужно еще какую-то программу покупать?"

Правда тот же клиент совершенно спокойно отнесся к построению отчетов и выходных форм из Аксапты в Ворд и Эксель.

Интересно... А есть у кого-нибудь опыт использования внешних генераторов на проектах?

[komar]

На аксаптовских проектах - не знаю, а вот с чудами типа Платинума он точно использовался. Ибо отчеты навааянные на внешних генераторах включались в стандартную поставку системы.
Что касается "зачем покупали", то можно тогда пойти еще дальше, и спросить, зачем покупать еще и SQL-сервер. Есть системы для обработки информации, есть СУБД, есть генераторы отчетов. Та же Аксапта может включать в себя сводную таблицу, из Екселя сдернутую, или использовать Ёксель для формирования отчетов, и никто не спрашивает, зачем. Хотя Ёксель тоже денег стоит. И ответ только один - специализированные системы всегда решают свою задачу лучше, чем универсальные.

[Andrew Lyskov]

Есть обкатанные на проектах решения, позволяющие строить сложные отчеты и производить анализ данных, разумно загружая систему.
И стоит _это_ (инструментарий + проект) существенно меньше, чем регулярное, нескончаемое "задрючивание" программеров/консультантов на тему построения "новеньких критически важных в эту секунду отчетов".

Кстати, мне кажется, что это уже не тема ERP-форума... СППР (системы поддержки принятия решений) - это несколько больше, глобальнее.

[mazzy]

Приветствую тебя, lbs.
Давай, ты будешь Аксаптовским Любимовым

[ViGo]

И я приветствую lbs!
Правда не знаю, кто это. :-)

Мне кажется, что эту тему мы закрыли. Здесь все очень точно всё высказали.
Понятно, что у многих был опыт использования разных внешних по отношению к нашей девушке приложений, и не только генераторов отчетов.

Были бы руки, а приложение им найдется! :-)

[Andrew Lyskov]

Цитата:

Интересно... А есть у кого-нибудь опыт использования внешних генераторов на проектах?

ты спросил - я ответил.

мы на своих проектах используем COGNOS и BUSINESS OBJECTS. Плюс, решения по цеплянию к БД, для того чтобы обойти проблему совместимости с изменяющейся БД (разработки, новые версии).

[ViGo]

Спасибо, что ответил.
Интересно же, кто и что делает.

[MironovI]

Connection Con = new Connection();
Statement Stmt = Con.createStatement();
ResultSet R = Stmt.executeQuery('Select inventtrans.ItemId, InventTable.ItemName From inventTrans, InventTable where InventTrans.ItemId = InventTable.ItemId');

while ( R.next() )
{
print R.getString(1);
}

К вопросу писать отчеты через Connection - лучше через ODBCConnection - в этом Connection, как я выяснил пол-ночи с ни протанцевав нельзя практически все - нельзя два раза сделать .GetString(1) допустим - буть как бобр сохрани в переменную и ее пользуй. Еще до кучи нельзя получать поля не по порядку, допустим GetString(2) а потом GetString(1) приведет к ошибке. Нельзя вложенные подзапросы делать, хоть убейся, хоть новый Connection создавай, все равно пока хоть одна выборка не закрыта второго запроса не выполнишь и т.д.. А что самое веселое - вложенные подзапросы (это уже про ODBCConnection ) выводят пургу, причем каждый раз разную без логики.. Иногда правильная цифра появляется если по коду пройти в режиме отладчика, а без отладчика кривизна.. ахтунг короче..

[Yprit]

Цитата:

Изначально опубликовано MironovI
нельзя вложенные подзапросы делать, хоть убейся, хоть новый Connection создавай, все равно пока хоть одна выборка не закрыта второго запроса не выполнишь и т.д..

Ага, и еще интереснее, когда включен мониторинг запросов SQL...