Предварительные выводы о переходе с AX2009 на AX2012

[Pustik]

Добрый вечер, Уважаемые Коллеги.
Я вижу, что многие уже начинают изучать, тестировать и знакомиться с новой версией АХ2012. Если будет время, не могли бы Вы, кто уже достаточно плотно поработал, в пока еще не локализованной, но уже существующей новой версии описать Ваше мнение по трудностям/нюансам перехода на нее, допустим с AX2009? Где ожидаются самые сложные моменты? Есть ли места, где не помогут релиз-апдейты и будут ли(возможны ли) они вообще? Где, по Вашему мнению, предвидится самый большой объем работ? Как переход повлияет на переучивание пользователей? Где стоит более внимательно подойти к вопросу целостности базы данных? и т.д.
Я понимаю, что это предварительное мнение. Просто интересно узнать его именно относительно перехода.
Спасибо.

[Pustik]

А в ответ тишина...

[EVGL]

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

[Pustik]

А меня больше всего пугает идея LedgerDim(ранее слышал об этом), Вы об этом?

[EVGL]

А в чем проблема? У вас много своих отчетов по LedgerDim?

[Pustik]

Нет, просто слышал на форуме, что финансовую аналитику собираются сделать аналогом складской т.е. InventDim и LedgerDim

[oip]

Про финансовую аналитику в AX 2012 давно уже можно почитать:
http://technet.microsoft.com/en-us/l.../hh272858.aspx

Краткое резюме есть и тут:
http://www.microsoft.com/downloads/d...0-47d4ebbaf4a6

[konopello]

Quote:

в гридах по умолчанию запрещено.

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

[EVGL]

Quote:

Originally Posted by konopello

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

Да, у меня для одного клиента тоже так сделано. Но пользователей все равно переучивать придется.

[Pustik]

Quote:

Originally Posted by EVGL

Да, у меня для одного клиента тоже так сделано. Но пользователей все равно переучивать придется.

Не понимаю зачем так сильно закручивать гайки? Для чего?
Еще пугают суррогатные ключи (типа сущности) , которые, насколько я понял, вяжутся по RecId. Чем хуже обыкновенный ID? Вопросов много, но точно знаю, что переход на новую версию со временем неизбежен, поэтому и спрашиваю.

[db]

Quote:

Originally Posted by Pustik

Не понимаю зачем так сильно закручивать гайки? Для чего?

Чтобы не было, например, таких ситуаций
Суперрастворитель

имхо отдельный режим редактирования несомненный плюс

[Pustik]

Quote:

Originally Posted by db

Чтобы не было, например, таких ситуаций
Суперрастворитель

имхо отдельный режим редактирования несомненный плюс

Увеличение трудоемкости для пользователей. Если человек накосячил в стандартной форме, не факт , что он не накосячит и в Вашей удобной форме для редактирования.
Поверьте, если обычному человеку в какой-либо системе будет тяжело, он не будет этой системой восхищаться. Напротив, если у пользователя все просто и легко получается он будет думать, что эта система супер, и он в ней хозяин, незаменимый работник, если хотите.
PS : кратко словами известного человека

[sukhanchik]

Quote:

Originally Posted by Pustik

Увеличение трудоемкости для пользователей.

Палка о двух концах.
Есть доля ошибок пользователей, которые они делают не столько от собственного незнания, сколько от неаккуратности.
К примеру - перед тем как разносить журнал ГК - можно внимательно все посмотреть и подумать (на худой конец запустить предварительный просмотр проводок). Поэтому косяки, после которых требуется сторнировать журнал - не относятся к неаккуратности.

А в данном примере - это стандартный косяк, когда запись случайно (непреднамеренно) правится. Кстати, в этом плане уже в АХ 2009 уже начали двигаться, создав такие формы (Места). И они с т.з. пользователей - оказались весьма востребованными. Только жалко, что их мало, да и при локализации "ни одна из форм не пострадала" (с).

Так что считаю - что это как раз прогресс.

Сравнение финаналитик перенесено в отдельную ветку (плюсы и минусы изменений в работе с фин.аналитиками в AX 2012) по просьбе участников данной ветки

[gl00mie]

Quote:

Originally Posted by Pustik

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

"Я книгу не читал, но осуждаю..." Т.е. я лично пока не заморачивался вопросами перехода, только читал документацию: что нового для разработчиков, что нового в функционале, какие вещи выкинуты и забыты и т.д. У меня лично сложилось впечатление, что в свете российских реалий если кастомизации 4.0 и даже 3.0 можно было перенести на 2009-ю практически как есть и заставить работать грубой силой, то тут уже - без вариантов: только полное перевнедрение, перенос данных сальдовками и запуск с чистого листа.

Quote:

Originally Posted by EVGL

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

Ну тут-то все понятно: у людей есть свое вертикальное решение, которое рано или поздно придется продавать на базе 2012-й, а не 2009-й, поэтому на вопрос "переходить или нет" тут ответ лишь один.
Но в целом... примерно с начала этого года на форуме начало появляться сравнительно много вакансий в компаниях, которые работают на 2.5 или 3.0 и хотят перейти на 2009-ю (а, может, кто-то и не хочет). Напомню, что 3.0 RTM вышла в 2002-м году - 9 лет назад. Представим себе типовую российскую компанию, работающую на 4.0 или, тем более, 2009-й: зачем бы ей вдруг понадобилось переходить на 2012-ю? Мне кажется, именно на этот вопрос нужно в первую очередь найти ответ, а не на вопросы технического или организационного плана - "какие подводные камни", "как дописывать скрипты конвертации данных", "сильно ли придется переучивать пользователей" и т.п. Мне лично это отчасти напоминает ситуацию с 1с 8.1 на фоне появления 8.2: с одной стороны, специалистам обычно интересно работать с последними версиями ПО, а с другой, компаниям, которые уже внедрили предыдущую версию и которых она устраивает, на переход могут подвигнуть либо серьезные проблемы масштабируемости/производительности, либо серьезный дефицит специалистов, желающих работать с "позавчерашней" версией системы.

[Pustik]

Quote:

Originally Posted by sukhanchik

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

Это и напрягает )))))

[gl00mie]

Quote:

Originally Posted by sukhanchik

С финаналитиками (то, что они будут как складские, плюс счет ГК будет являться одной из аналитик) - тоже изменение поддерживаю.
Теперь можно будет взять и добавить аналитику Клиент / Проект / Договор / Юрлицо - ссылаяся напрямую на справочник (а-ля субконто в 1С). Также как это сделано в складских аналитиках.

Тут я бы попросил администраторов выделить сообщение в отдельную тему С моей точки зрения, проблема с теми же финансовыми аналитиками (по крайней мере, в контексте поля-массива аналитик в версиях до 2009-й включительной) не в том, что их мало, а в том, каковы алгоритмы их заполнения и контроля их взаимосвязей - в чем-то схоже с темой Необходимое количество номенклатурных аналитик.

[Pustik]

Quote:

Originally Posted by gl00mie

У меня лично сложилось впечатление, что в свете российских реалий если кастомизации 4.0 и даже 3.0 можно было перенести на 2009-ю практически как есть и заставить работать грубой силой, то тут уже - без вариантов: только полное перевнедрение, перенос данных сальдовками и запуск с чистого листа.

боже как это пугает )))

[sukhanchik]

Quote:

Originally Posted by gl00mie

Тут я бы попросил администраторов выделить сообщение в отдельную тему

Не вопрос . А в какую? И что выделить?
Название темы: Предварительные выводы о переходе с AX2009 на AX2012
Далее идет обсуждение "новых фич", типа как запрет редактирования в гриде или новая структура финаналитик. Может еще какая фича будет обсуждаться.
Или хочется разделить обсуждение по фичам ? Типа про аналитики грид в одной теме, про аналитики в другой теме .
Я ж не против . Просто хочу понять, что делить.

[Raven Melancholic]

Нововведения в 2012 достаточно интересные, но (только по этой ветке, не говорю уже по другим):

• пугают суррогатные ключи
• можно будет в качестве аналитики использовать конкретный справочник
• запрет редактирования в гриде
• а-ля 1С

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

[gl00mie]

Quote:

Originally Posted by sukhanchik

А в какую? И что выделить? Название темы: Предварительные выводы о переходе с AX2009 на AX2012

Не, все банальнее: плюсы и минусы изменений в работе с фин.аналитиками в AX 2012.