AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Прочие вопросы
DAX
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 14.03.2018, 11:24   #61  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Vadik Посмотреть сообщение
sukhanchik, тысяча извинений - отредактировал Ваше сообщение вместо того чтобы процитировать
без паники.

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

сообщение можно восстановить.
не ошибается только тот, кто ничего не делает.
Миниатюры
Нажмите на изображение для увеличения
Название: 0.PNG
Просмотров: 448
Размер:	41.0 Кб
ID:	11855   Нажмите на изображение для увеличения
Название: 1.PNG
Просмотров: 471
Размер:	164.4 Кб
ID:	11856  

__________________
полезное на axForum, github, vk, coub.
За это сообщение автора поблагодарили: Vadik (1), belugin (5).
Старый 14.03.2018, 18:23   #62  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от trud Посмотреть сообщение
т.е. на практике это выглядит так(задача пусть та-же)
...
Ну т.е. в этом модели работы время программиста вообще ничтожно, будет там полчаса или 4. Если сравнить в этом ключе, то возможно D365 будет более прозрачна и быстрее
Не согласен. На практике пример 1 c лукапом будет идти как дополнительное пожелание и просто добавиться к чему-то большему. Никто в здравом уме не будет деплойить такое на PROD отдельно. То есть собственной процедуры деплоймента у подобных задач считай что нет.

Если взять AX2012 и AX2009 то затраты на деплоймент очень сравнимы. На моей текущем проекте AX2012 полное развертывание на PROD (5 серверов) занимает у меня 2 часа старым классическим способом через XPO (Это не значит что мы не умеем готовить модели, просто нет нужды). Да и с моделями затраты на деплоймент будут те же что и в AX2009.

Никакой непрозрачности нет, c AX2012 можно деплойить так же прозрачно и быстро как и с AX2009, AX2004.

Не хочешь XPO, а хочешь по модному как в D365O? Team Foundation Server в руки. Для D365O TFS обязателен, а для AX2012 опционален.

Коэффициент стоимости разработки 8 раз видется вполне реалистичным, то что как минимум 4 раза - не вызывает сомнений. Деплоймент же в D365O никак не может быть прозрачней и быстрей чем в AX2012. Так как единственно за счет чего это может быть - TFS, но он прекрасно предназначен и для AX2012.

При рассмотрении стоимости разработки мы не учитываем стоимость и риски автоматических обновлений D365O при наличии кастомизаций. Extensions не означает совместимость, а означают невидимость несовместимости. И тут как раз по "правильной модели" каждое такое обновление - это новый проект тестирования совместимости каждые пол-года и соответственно увеличение стоимости каждой кастомизации каждые пол-года.
Старый 14.03.2018, 20:33   #63  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Согласен на 100%.
__________________
Ivanhoe as is..
Старый 15.03.2018, 22:55   #64  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,273 / 3466 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Прошу прощения, что пропал - не было возможности ответить по существу.

Цитата:
Сообщение от trud Посмотреть сообщение
Что-то мне кажется вы сделали допущение что у вас в данный момент есть кто-то кто знает как это делать плюс свободен, кроме того опустили момент развертывания
...
Ну т.е. в этом модели работы время программиста вообще ничтожно, будет там полчаса или 4. Если сравнить в этом ключе, то возможно D365 будет более прозрачна и быстрее
Во-первых я оставил за скобками бюрократию сознательно, потому что считаю, что любая бюрократия всегда может "съесть" любую разработку ("Сколько нужно программистов чтобы поменять лампочку?"). При наличии такой бюрократии - уже неважна система Все равно любое обновление будет идти "по процедуре".
Во-вторых это допущение применимо как только заказчик захочет иметь своего человечка для разработки и этому человечку дадут команду "сделать", т.е. он обучится как это делать, плюс будет свободен (ему выделят время), плюс он будет заниматься развертыванием (по крайней мере контролировать процесс).
В-третьих из представленной схемы с партнером никак не следует, чем все-таки работа с D365 отличается от работы с AX2012. Наличие облака совершенно не связано с тем, что клиент не захочет контролировать содержимое обновления и не попросит присылать ему модели. Локальная установка системы совершенно не связана с тем, что клиенту обязательно нужно контролировать содержимое обновления и он не может дать доступ партнеру на свой терминальный сервер для проведения обновления.

Цитата:
Сообщение от Vadik Посмотреть сообщение
sukhanchik, тысяча извинений - отредактировал Ваше сообщение вместо того чтобы процитировать
Это восстановимо, да и я не контролирую какие слова пропали

Цитата:
Сообщение от Vadik Посмотреть сообщение
Из лично Вашей практики - каковы были трудозатраты и длительность проектов по обновлению версий, накату сервис-паков, хотфиксов, расширенной функциональности распространяемой в фиде хотфиксов в 2012. Если были таковые, разумеется. Спасибо
Тут я признаюсь честно - таких проектов именно на AX 2012 у меня не было. Я судил по проектам в АХ 2009, предполагая, что в 2012 процедура усложнилась пересборкой CILа, получением хотфиксов через LCS и нормализованной структуры данных. По AX 2009 обычно это 2-4 человеко-недели на подъем кода (в зависимости от количества пересечений и сложности тестирования; половина времени отнимает непосредственно подъем кода и половина - тестирование) и 1-2 человеко-месяцев на подготовку обновляющих скриптов, инструкции и тестовых прогонов (разброс сильно зависит от объема БД и количества обновляемых таблиц; я не рассматриваю классы ReleaseUpdate*, в роли держателей скриптов, т.к. они хорошо работают только для небольшого объема данных и повторяют свою работу в каждой компании, в то время как для некоторых скриптов можно сэкономить и запускать обновляющий скрипт всего один раз по всем компаниям)

В маленьких базах (15 пользователей) весь подъем вообще можно сделать за человеко-месяц (из опыта).
В больших базах (больше 100 пользователей) только подготовка данных может занять 3 месяца работы нескольких человек (также из опыта)
Все вышеперечисленное относится к подъему на один или два сервис-пака (т.е. нечто глобальное)

Однако, тут надо сделать одну очень существенную оговорку. Объективно нет смысла обновляться, если в новой версии нет нового функционала, ради которого происходит обновление. За исключением, когда обновляться заставляют технические причины (к примеру, Windows 10 не поддерживает приложения, написанные для DOS ))
А если обновление производится ради функционала, то этот функционал нужно внедрить и, вполне вероятно, сделать пересмотр использование существующего функционала (давно-давно у меня была ситуация, когда я программировал функциональность на 4.0, которая впоследствии в очень сильно похожем варианте появилась в AX2009 в виде причин возврата в заказах на возврат. В этом случае нужно было бы выбросить мое "творение" и подкорректировать стандарт, если бы он не подошел напрямую). Т.о. по сути глобальное обновление должно сопровождаться мини-внедрением, а это уже целый проект и как ты не крути, программируя с прошлой версией и заботясь о будущем апгрейде, но перевнедрение превратит прошлую версию всего-лишь в систему-источник информации, какой является 1С или какая другая система, когда на предприятие приходит AX / D365. И перетягивание информации из одной системы в другую сведется к написанию таких же классов-загрузчиков данных в новой версии.

Поэтому очень сложно корректно сравнить в общем случае потенциальные затраты на обновление системы с потенциальными затратами на перевнедрение. Если, к примеру, смотреть на АХ2012 - D365, то лично мое мнение, что здесь нужно делать именно перевнедрение, а не обновление. Т.е. усложнять разработку ради потенциального облегчения обновления конкретно на этой смене нет экономического смысла
__________________
Возможно сделать все. Вопрос времени

Последний раз редактировалось sukhanchik; 16.03.2018 в 07:29.
За это сообщение автора поблагодарили: Pustik (10).
Старый 16.03.2018, 09:52   #65  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
По моему опыту самое сложно в 2012 было перевести с R2 на R3, и то это считалось в человеко-месяцах, даже не десятках. А накат промежуточных фиксов - обычная работа технической поддержки.

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

Все остальные переходы в моей практике AX 3.0 > AX 4.0, AX 4.0 > AX 2009, AX 4.0 > AX 2012 были реальными перевнедрениями. Работать с предыдущей версией конечно удобнее и в части сопоставления начальных данных, и подходов, даже какие-то куски кода можно взять. Но это все равно было перевнедрение. Почему должны измениться при D365 я не понимаю. Вот когда D365 станет совсем паблик облаком без выделенных инстансов - ну тогда и поговорим, но это совсем другой продукт будет.
__________________
Ivanhoe as is..
За это сообщение автора поблагодарили: sukhanchik (6).
Старый 16.03.2018, 19:25   #66  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от Vadik Посмотреть сообщение
Из лично Вашей практики - каковы были трудозатраты и длительность проектов по обновлению версий, накату сервис-паков, хотфиксов, расширенной функциональности распространяемой в фиде хотфиксов в 2012.
Я лично не накатывал на 12-ку крупные обновления, врать не буду. Но был случай накатывания, кажется, нового формата электронной декларации по НДС (KB3042242). Там изменений - с гулькин нос, но по зависимостям включено еще очень много чего. Так вот, судя по проектным записям, на установку обновления ушло что-то около 4 часов на нескольких разных средах, поскольку приложение дорабатывалось "по фен шую", с минимальным overlayering'ом. А потом еще около 25 часов ушло на разгребание ошибок, вылезших на рабочей системе в расчете сумм налогов по строкам заказов на продажу, чего от этого обновления никто не ожидал.
За это сообщение автора поблагодарили: sukhanchik (6).
Старый 16.03.2018, 20:06   #67  
Pustik is offline
Pustik
Участник
 
807 / 372 (14) ++++++
Регистрация: 04.06.2004
Можно я влезу, может не совсем с логичным вопросом, но все таки
А зачем вообще переходить на новую версию, если и так все достаточно неплохо работает.
Попрошу оптимистов грязными тапками в меня не кидаться. Для меня 2009 -лучшая версия. Но есть то, что меня пугает. А не скажет ли Microsoft потом, когда то, что Windows новой версии, уже не будет поддерживать вашу Старую систему. А скажет : Вы обновитесь до новой и все у вас будет ок
__________________
-Ты в гномиков веришь?
-Нет.
-А они в тебя верят, смотри, не подведи их.
Старый 16.03.2018, 23:57   #68  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
AX2012R3 CU9 -> CU10 -> CU11 не слышал проблем на текущих проектах, все накатывалось по сути тех-поддержкой.
Установочная программа мержит код и показывает зеленым в коде что было что стало. Конфликты же за счет оverlayering легко определяются тем же установщиком и визуальны для программиста.

Обновления типа CU для D365O при отсутствии оverlayering - даже не знаю как определять наличие конфликтов.
Старый 17.03.2018, 00:55   #69  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
699 / 752 (27) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Цитата:
Сообщение от Pustik Посмотреть сообщение
Можно я влезу, может не совсем с логичным вопросом, но все таки
А зачем вообще переходить на новую версию, если и так все достаточно неплохо работает.
Попрошу оптимистов грязными тапками в меня не кидаться. Для меня 2009 -лучшая версия. Но есть то, что меня пугает. А не скажет ли Microsoft потом, когда то, что Windows новой версии, уже не будет поддерживать вашу Старую систему. А скажет : Вы обновитесь до новой и все у вас будет ок
Тут даже не МС, прийдёт какой-нибудь GDPR, МС для 12ки и 7ки напилит что-то, а для 9ки нет и что вы будите делать ?
Старый 17.03.2018, 04:51   #70  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
По моему опыту самое сложно в 2012 было перевести с R2 на R3, и то это считалось в человеко-месяцах, даже не десятках. А накат промежуточных фиксов - обычная работа технической поддержки.

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

Все остальные переходы в моей практике AX 3.0 > AX 4.0, AX 4.0 > AX 2009, AX 4.0 > AX 2012 были реальными перевнедрениями. Работать с предыдущей версией конечно удобнее и в части сопоставления начальных данных, и подходов, даже какие-то куски кода можно взять. Но это все равно было перевнедрение. Почему должны измениться при D365 я не понимаю. Вот когда D365 станет совсем паблик облаком без выделенных инстансов - ну тогда и поговорим, но это совсем другой продукт будет.
И хотфиксы и обновления функционала неизбежны во всех версиях D365O. Другое дело кто-то раньше кто-то позже но все равно неизбежно. On-premises это вид развертывания облака, концепции это не меняет.



Standard and targeted platform releases
https://docs.microsoft.com/en-us/dyn...eview-releases

Тут по ходу можно записаться в тестеры
https://aka.ms/CAAPNomination

Цитата:
Сообщение от skuull Посмотреть сообщение
Тут даже не МС, прийдёт какой-нибудь GDPR, МС для 12ки и 7ки напилит что-то, а для 9ки нет и что вы будите делать ?
GDPR - это очень хороший пример. Но одно дело предоставлять проекты/решения в доступ и другое дело накатывать неумолимо в виде "1..100, кто не убежал, я не виноват". Зачем к примеру RU клиентам вливание логики по автоматическому удалению записей клиентской базы или исторических данных если GDPR это директива EU? Ну и всякий там бразильский функционал и прочий мусор со всего мира.

Нужен ли типичному бизнесу сети российских магазинов или авто-дилеров все эти горы международного мусора в качестве неизбежных обновлений?

Если ту же AX2012 можно зафиксировать под ногу в качестве платформы разработки со всеми этими наваленными в SYS локализациями всех стран, то в D365O это все индийское, бразильское и итальянское будет обновляться и обновляться со стороны вендора в качестве платформы для обновлений. Очень необходимая вещь для автосалона в Питере.

Этот "One size fits all" это больше для мультикорпораций с офисами по всему миру и стандартными бизнес-процессами. Хотя тоже глупость на самом деле. Но хоть как-то подходит для такого бизнеса.

Ладно бы существовала версия D365O RU в качестве форка (независимой версии) и которую бы обновляло российское представительство или Российская компания. Но зачем автосалону в Питере GDPR?
Старый 17.03.2018, 07:57   #71  
Pustik is offline
Pustik
Участник
 
807 / 372 (14) ++++++
Регистрация: 04.06.2004
Цитата:
Сообщение от skuull Посмотреть сообщение
Тут даже не МС, прийдёт какой-нибудь GDPR, МС для 12ки и 7ки напилит что-то, а для 9ки нет и что вы будите делать ?
Да, и этого тоже надо опасаться, скорей всего это более правдоподобно. По сути все те, кто приобрел ERP систему сели на иглу.
__________________
-Ты в гномиков веришь?
-Нет.
-А они в тебя верят, смотри, не подведи их.
Старый 17.03.2018, 10:49   #72  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
699 / 752 (27) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Цитата:
Сообщение от ax_mct Посмотреть сообщение
Ладно бы существовала версия D365O RU в качестве форка (независимой версии) и которую бы обновляло российское представительство или Российская компания. Но зачем автосалону в Питере GDPR?
Тут ответ очевиден и его никто не скрывает. Слишком дорого иметь одну версию для россии вторую для бразилии, третью для китая, а кто-то ведет бизнес везде и поставит все 3. В итоге бедному МС поддерживать весь этот зоопарк, а так меньше бранчей - меньше мержить!
За это сообщение автора поблагодарили: ax_mct (2).
Старый 17.03.2018, 13:16   #73  
oip is offline
oip
Axapta
Лучший по профессии 2014
 
2,564 / 1416 (53) ++++++++
Регистрация: 28.11.2005
Записей в блоге: 1
Цитата:
Сообщение от Pustik Посмотреть сообщение
А не скажет ли Microsoft потом, когда то, что Windows новой версии, уже не будет поддерживать вашу Старую систему. А скажет : Вы обновитесь до новой и все у вас будет ок
Обязательно когда-нибудь скажет. Например, мы наткнулись на то, что Axapta 4.0 не поддерживает TLS 1.2, а у клиента по внутренним политикам он стал обязательным. Ну и MS ничем помочь уже не может - версия-то не поддерживается.
__________________
С уважением,
Олег.

Последний раз редактировалось oip; 17.03.2018 в 13:19.
За это сообщение автора поблагодарили: ax_mct (2), Logger (1).
Старый 17.03.2018, 16:25   #74  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от skuull Посмотреть сообщение
Тут ответ очевиден и его никто не скрывает. Слишком дорого иметь одну версию для россии вторую для бразилии, третью для китая, а кто-то ведет бизнес везде и поставит все 3. В итоге бедному МС поддерживать весь этот зоопарк, а так меньше бранчей - меньше мержить!
Цитата:
Сообщение от oip Посмотреть сообщение
Обязательно когда-нибудь скажет. Например, мы наткнулись на то, что Axapta 4.0 не поддерживает TLS 1.2, а у клиента по внутренним политикам он стал обязательным. Ну и MS ничем помочь уже не может - версия-то не поддерживается.
Дорого желание заграбастать все в одни руки, при децентрализации и бранчах, делегировании локальным компаниям, MS мог бы получить больше. А так он теряет рынок в той же России так как нашему условному автодилеру в Питере не нужны обновления по директивам EU, а нужны свои локальные обновления. Вовремя и по делу.

Ожидать же их от МС вовремя при такой мировой централизации - неразумно.
И если с AX2012 добавить свое локальное - это одно, то с D365O - совсем другое.

Это я к тому что если у российской компании нет работающих подразделений под юрисдикцией других стран, то рассматривать D365O в качестве новой версии ERP или альтернативы AX2012 - глупо
.

Или у нас на форуме есть монстры программирования в Российском MS которым кажется что все не так? 3-5 человек которые способны покрыть нужды автодилера в Питере по российской специфике?
Может я чего не так понимаю.
За это сообщение автора поблагодарили: gl00mie (5).
Старый 04.04.2018, 11:45   #75  
bio_unit is offline
bio_unit
Участник
Аватар для bio_unit
Сотрудники компании GMCS
Ex AND Project
 
119 / 77 (3) ++++
Регистрация: 21.04.2004
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Пример 2. Хочу добавить раскраску строк на форме. Пусть это бантик, но ... опять-таки в контексте гибкости изменений - это нормальное желание. Система технически не предоставляет возможности это сделать без оверлеинга либо дублирования формы. Дублирование формы чревато тем, что если к ней были сделаны экстеншены, то их нужно будет склеивать в нашу новую форму. Что влечет за собой дополнительные расходы. Ну и надо понимать, что дублирование формы предполагает встраивание ее в меню, во всякие иные вызовы и т.д. Опять-таки, при несложном критерии раскраски - с оверлеингом или своей формой задача решается за 0,5-1 час (со всей бюрократией). Дополнительные работы с учетом тестирования и прочей бюрократией опять могут дотянуть до 4-х часов.
Вас услышали:
Platform Update 15: https://docs.microsoft.com/en-us/dyn...form-update-15

Ability to color grid rows without overlayering via FormDataSource OnDisplayOptionInitialize event
The ability to color grid rows without overlayering is now possible via the OnDisplayOptionInitialize event on FormDataSource.
За это сообщение автора поблагодарили: sukhanchik (4), ax_mct (3).
Теги
внедрение, как правильно

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
jaestevan: Descubre la nueva Dynamics AX 2012 R3 Entity Store Blog bot DAX Blogs 0 23.06.2016 18:11
DAX: A Shift to Effective Demand Forecasting With Microsoft Dynamics AX 2012 R3 Blog bot DAX Blogs 0 16.11.2013 02:13
DAX: Official Dynamics AX 2012 R2 Content (update) - Where is it, and how can you find out about updates? Blog bot DAX Blogs 0 03.12.2012 11:11
emeadaxsupport: New Content for Microsoft Dynamics AX 2012 : October 2011 Blog bot DAX Blogs 0 27.10.2011 17:11
axinthefield: Dynamics AX Event IDs Blog bot DAX Blogs 0 01.03.2011 22:11
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

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

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 12:19.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.