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

[konopello]

Цитата:

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

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

[EVGL]

Цитата:

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

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

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

[Pustik]

Цитата:

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

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

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

[db]

Цитата:

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

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

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

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

[Pustik]

Цитата:

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

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

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

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

[sukhanchik]

Цитата:

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

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

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

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

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

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

[Pustik]

Цитата:

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

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

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

[gl00mie]

Цитата:

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

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

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