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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 28.05.2018, 09:39   #1  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,252 / 4247 (146) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
D365FO: Организация разработки - слияние модификаций
Цитата:
Сообщение от trud Посмотреть сообщение
Кстати интерестный момент, а как вы ведете меточные файлы при нескольких разработчиках? у каждого разработчика свой файл или все пишут в один файл, потом решают конфликты?
я просто сам задумывался как называть метки и пока решил называть их так же как в ах2012, просто последовательным номером, закрепив за собой диапазон, но с тулзой наверное удобнее будет как-то по другому
еще бы на гитхаб ее
Я почему-то просто решил создавать по меточному файлу на каждую модификацию. (Возможно - один меточный файл на несколько тесно связанных доработок - например разных доработок печатных форм по заказам на продажу). Пока проблем не было. Более того - я даже думаю на следующих проектах применить такой же подход к моделям. То есть - любая более или менее независимая доработка делается в отдельной модели.

sukhanchik: Тема выделена из Создание меток для AX7

Последний раз редактировалось sukhanchik; 30.05.2018 в 10:56.
За это сообщение автора поблагодарили: sukhanchik (3).
Старый 28.05.2018, 10:08   #2  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,157 / 2331 (86) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
После перехода на символьные, а не числовые метки, меточный файл сливается так же легко, как и любой другой файл исходников. Если использовать kdiff3 как merge tool, независимые добавления сливаются вообще полностью автоматически.
Старый 28.05.2018, 10:13   #3  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,157 / 2331 (86) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Цитата:
Сообщение от AlexSD Посмотреть сообщение
Наверно, стандартный редактор меток был (есть) слишком тормознутный и/или модальный по отношению к остальной студии.
Сейчас редактор такая же вкладка студии как и все остальные. Ее можно придочить, вынести на дополнительный монитор и т.д.

Упс. Есть два редактора - если открыть меточный файл это вот так. Если вызвать из меню диалог find labels это другое, модальное.

Цитата:
Его нужно было открывать мышкой из меню (шорткат вроде есть, но я его не осилил запомнить, возраст ) вместо alt-tab.
Еще можно Cltr+Q и набрать label.
Старый 28.05.2018, 10:17   #4  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,157 / 2331 (86) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Цитата:
Сообщение от AlexSD Посмотреть сообщение
Я хочу интерфейс с WinForms переделать на Electron, отрефакторить код, добавить плагины, добавить создание меток из исходного текста по проекту. Или попробовать встроить в студию. Хотя пока мне нравится, что можно по alt-tab переключаться.
Если хочется встроить в студию, то надо делать UserControl на WPF мне не очень понятны достоинства электрона с учетом того, что разработка не кроссплатформена.
За это сообщение автора поблагодарили: skuull (1).
Старый 28.05.2018, 13:19   #5  
trud is offline
trud
Участник
Лучший по профессии 2017
 
550 / 428 (16) +++++++
Регистрация: 07.06.2003
Цитата:
Сообщение от belugin Посмотреть сообщение
После перехода на символьные, а не числовые метки, меточный файл сливается так же легко, как и любой другой файл исходников.
так а где гарантия что кто-то не создаст одинаковые метки для разных текстов(из за излишних сокращений или спец символов типа ?)
Вообще конечно работа с метками это наиболее простой показательный пример в различиях в работе МС и Дамгарда.
т.е. в оригинале каждый аспект работы был продуман(типа несколько языков в одной форме, создание сразу из объекта, отображение в сво-вах именно значения, а не метки).
все же интерестно как они решили тратить на это время, думаю при гораздо скромных бюджетах чем МС
Старый 28.05.2018, 13:25   #6  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,157 / 2331 (86) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Цитата:
Сообщение от trud Посмотреть сообщение
так а где гарантия что кто-то не создаст одинаковые метки для разных текстов(из за излишних сокращений или спец символов типа ?)
Вот не знаю. Пока с таким не сталкивался. Наверное тот, кто будет мерджить получит отлуп при компиляции.
Старый 28.05.2018, 17:22   #7  
sukhanchik is offline
sukhanchik
Moderator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,591 / 2029 (73) +++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от fed Посмотреть сообщение
Я почему-то просто решил создавать по меточному файлу на каждую модификацию. (Возможно - один меточный файл на несколько тесно связанных доработок - например разных доработок печатных форм по заказам на продажу). Пока проблем не было. Более того - я даже думаю на следующих проектах применить такой же подход к моделям. То есть - любая более или менее независимая доработка делается в отдельной модели.
Да, именно так и делаю. Каждому разработчику по своей модели (одна задача - одна-две модели; смена задачи - смена моделей). Каждой модели - свой меточный файлик. Проблем с конфликтами нет.
Единственное, что - могут возникать проблемы разделения кода по моделям - что писать в одной модели, а что в другой. Но в целом - проблемы решаются и даже иногда получается очень удобно (когда некий базовый код удается собрать в одной модели, на которую ссылается несколько моделей)
__________________
Возможно сделать все. Вопрос времени
Старый 29.05.2018, 00:11   #8  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
466 / 478 (16) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Да, именно так и делаю. Каждому разработчику по своей модели (одна задача - одна-две модели; смена задачи - смена моделей). Каждой модели - свой меточный файлик. Проблем с конфликтами нет.
Единственное, что - могут возникать проблемы разделения кода по моделям - что писать в одной модели, а что в другой. Но в целом - проблемы решаются и даже иногда получается очень удобно (когда некий базовый код удается собрать в одной модели, на которую ссылается несколько моделей)
По одной модели или по одному пакету?
Старый 29.05.2018, 00:22   #9  
sukhanchik is offline
sukhanchik
Moderator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,591 / 2029 (73) +++++++++
Регистрация: 13.06.2004
Адрес: Москва
Модели. Пакет (я правильно понимаю, что пакет = deployable package?) в себе может конечно содержать несколько моделей, но только если они не ссылаются друг на друга.

Нет смысла делать единый меточный файл на пакет - все равно файл же в модели создается.

Если модель будет в себе содержать относительно независимую область, то можно будет по моделям делить модификации. Модификаций может быть и несколько на одну модель. Например, все модификации по заявкам на закупки могут быть сделаны в одной модели. А по справочнику клиентов - по другой. И меточные файлы между ними совершенно не обязаны иметь формат вида @ХХХ12345. Пусть у них будут разные файлы.
__________________
Возможно сделать все. Вопрос времени
Старый 29.05.2018, 00:28   #10  
AlexSD is offline
AlexSD
Microsoft Dynamics
Сотрудники Microsoft Dynamics
 
228 / 226 (8) ++++++
Регистрация: 14.10.2003
Цитата:
Сообщение от belugin Посмотреть сообщение
Если хочется встроить в студию, то надо делать UserControl на WPF мне не очень понятны достоинства электрона с учетом того, что разработка не кроссплатформена.
Это пока мой учебный проект. Поскольку сама идея простая, можно попробовать использовать различные технологии сразу получив рабочий инструмент. Электроном меня Бирюлин соблазнил. Это не пренос ответственности, просто для истории

Электрон меня заинтересовал с того времени, как я узнал что на нем сделана VS Code, Slack, Postman и т.д. (https://electronjs.org/apps). Капнув его немного оказалось, что я быстрее могу с ним разобраться, чем с WPF.

Upd: т.е., с HTML и Node.js легче разобраться, чем с WPF.

Последний раз редактировалось AlexSD; 29.05.2018 в 00:33.
Старый 29.05.2018, 01:14   #11  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
466 / 478 (16) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Модели. Пакет (я правильно понимаю, что пакет = deployable package?) в себе может конечно содержать несколько моделей, но только если они не ссылаются друг на друга.
Вы уверенны что именно модели ссылаются на модели ? Т.е., по вашему, возможна ситуация когда у меня есть deployable package A с 2мя моделями: АА и АБ, где АА ссылаеться на AppSuite, а АБ - нет ?
Старый 29.05.2018, 09:04   #12  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,157 / 2331 (86) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Модели ссылаются на пакеты AKA модули
Старый 29.05.2018, 14:25   #13  
sukhanchik is offline
sukhanchik
Moderator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,591 / 2029 (73) +++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от skuull Посмотреть сообщение
Вы уверенны что именно модели ссылаются на модели ? Т.е., по вашему, возможна ситуация когда у меня есть deployable package A с 2мя моделями: АА и АБ, где АА ссылаеться на AppSuite, а АБ - нет ?
Ээээ... Что-то Вы меня смутили )))
Ситуация. Имеем порядка 20 моделей, каждая из которых создавалась, как Create new package (выбирался этот режим в мастере при создании модели).
Эти модели могут ссылаться на разные модели, в т.ч. кто-то может ссылаться на AppSuite, а кто-то нет. Помимо AppSuite есть еще Directory, ContactPerson и еще куча мелких моделей, на которые уж точно не все модели ссылаются.
Кроме стандартных моделей они могут ссылаться друг на друга (циклические ссылки исключены). Т.о. у меня получилось 5 уровней пакетов. 1-й уровень - модели, ссылающиеся на стандартные модели, 2-й уровень - модели, ссылающиеся на стандартные модели и модели 1-го уровня; 3-й уровень - модели ссылающиеся на стандартные модели и модели 1-го и 2-го уровней и т.д. Само собой одна моя модель принадлежит какому-то одному уровню.

Так вот - при апгрейде кода с 7.2 PU10 на 8.0 PU15 была создана в облаке чистая среда (не проапгрейдена, а именно создана с нуля), в которой были только стандартные модели. На нее было последовательно залито 5 deployable package, каждый из которых соответствовал уровню пакета (а в пакете было само собой несколько моделей). Т.о. были залиты все 20 моделей.
Пакет (package) тут вообще ни причем. Ссылки идут на модели. И нельзя заливать пакет, в котором находятся модели, ссылающиеся друг на друга. А вот по уровням - пожалуйста. И совершенно без разницы - есть ли в где-то в одной модели ссылка на AppSuite или ее нет
__________________
Возможно сделать все. Вопрос времени
За это сообщение автора поблагодарили: trud (2).
Старый 30.05.2018, 00:16   #14  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
466 / 478 (16) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Ээээ... Что-то Вы меня смутили )))
Ситуация. Имеем порядка 20 моделей, каждая из которых создавалась, как Create new package
Вот вы и ответили на мой вопрос. Вы создаете 1 пакет на 1 модель. Модели, насколько я понимаю, существуют только в дизайне и потом всё равно все билдится по-пакетно. Т.е. как писал выше belugin пакеты = модули которые ссылаются на что-то. В одном пакете (не deployable, это я не правильно спросил, просто пакете) может быть много моделей которые ни на что не ссылаются, посмотрите на AppSuite пакет, там много моделей.

Зачем я все это спрашиваю ? Просто МС активно на яммере пишет, что если вы не ISV то больше 1 пакета вам не надо. В вашем случае мне интересно что вы выиграли от этого? Ведь пакет с 3го уровня нельзя выдернуть и использовать отдельно без первого и второго уровня. Имея 20 меточных файлов можно попасть в ситуацию когда в каждом из них есть метка "Конь" и если вы решили переименовать ее в "Сфера" то придётся создавать 20 новых меток вместо одной.

Еще появляется сложность из-за того что из нижних пакетов не видно объектов из верхних, т.е. придётся иногда двигать код между ними. Это наверно все хорошо и правильно с точки зрения разделения, модульности и бла-бла, но добавляет сложности без видимого для меня преимущества (если вы не ISV, а просто лабаете моды)

Последний раз редактировалось skuull; 30.05.2018 в 00:21.
За это сообщение автора поблагодарили: sukhanchik (6).
Старый 30.05.2018, 07:54   #15  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,157 / 2331 (86) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
belugin пакеты = модули которые ссылаются на что-то.

Модели из дескрипторов ссылаются на модули. Ну и модули посредством их.
Старый 30.05.2018, 09:28   #16  
trud is offline
trud
Участник
Лучший по профессии 2017
 
550 / 428 (16) +++++++
Регистрация: 07.06.2003
Цитата:
Сообщение от skuull Посмотреть сообщение
Еще появляется сложность из-за того что из нижних пакетов не видно объектов из верхних, т.е. придётся иногда двигать код между ними. Это наверно все хорошо и правильно с точки зрения разделения, модульности и бла-бла, но добавляет сложности без видимого для меня преимущества (если вы не ISV, а просто лабаете моды)
Основное преимущество думаю в этом заключается. вместо того чтобы лабать код, вы занимаетесь разделением, модульностью и другими интересными вещами(т.е. занимаете должность архитектора, а не просто программиста)
За это сообщение автора поблагодарили: Ivanhoe (1).
Старый 30.05.2018, 09:42   #17  
sukhanchik is offline
sukhanchik
Moderator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,591 / 2029 (73) +++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от skuull Посмотреть сообщение
Вот вы и ответили на мой вопрос. Вы создаете 1 пакет на 1 модель. Модели, насколько я понимаю, существуют только в дизайне и потом всё равно все билдится по-пакетно. Т.е. как писал выше belugin пакеты = модули которые ссылаются на что-то. В одном пакете (не deployable, это я не правильно спросил, просто пакете) может быть много моделей которые ни на что не ссылаются, посмотрите на AppSuite пакет, там много моделей.
Все понятно, большое спасибо.

Цитата:
Сообщение от skuull Посмотреть сообщение
Зачем я все это спрашиваю ? Просто МС активно на яммере пишет, что если вы не ISV то больше 1 пакета вам не надо. В вашем случае мне интересно что вы выиграли от этого? Ведь пакет с 3го уровня нельзя выдернуть и использовать отдельно без первого и второго уровня. Имея 20 меточных файлов можно попасть в ситуацию когда в каждом из них есть метка "Конь" и если вы решили переименовать ее в "Сфера" то придётся создавать 20 новых меток вместо одной.
В моем случае все просто. Как начали создавать пакеты, так и дальше продолжили не задумываясь о последствиях. Так что тут искать глубокого смысла не стоит, тем более, что яммер - штука в явном виде не сильно открытая и большими красными буквами в заголовке там не пишут, что требуется всего один пакет - надо быть достаточно активным читателем яммера ) (хотя я его и просматриваю периодически).
Но решение продолжить так работать в моем случае подкрепилось скоростью билда. Я вот смотрю на AppSuite (на папку в PackagesLocalDirectory) и пока не особо вижу большого количества там подпапок, да и dll-ка там получается одна на пакет и достаточно большая (интересно, долго ли она билдится?)
Название: Снимок1.JPG
Просмотров: 84

Размер: 35.2 Кб
Нажмите на изображение для увеличения
Название: SNAG_Program-0052.png
Просмотров: 21
Размер:	98.1 Кб
ID:	11932
По поводу конкретно меток я вообще не переживаю, т.к. с одной стороны хорошо конечно использовать одну метку в разных местах, как идеологически подавалось в прошлых версиях, а с другой стороны... потребность переименования метки по большому счету - не регулярный процесс по сравнению с разработкой. Т.е. если сравнить затраты на регулярный поиск существующей метки и экономию затрат на ее переименование (с учетом того сколько раз мы ищем существующую метку и сколько раз мы переименовываем ее, с осознанием того, сколько мест в системе затронется) - то на мой взгляд затраты перевешивают экономию. В этом плане я сильно порадовался в D365, что наконец-то можно уйти от меток вида SYS12345, а писать осмысленный текст в коде метки. А этот факт исключает по сути смысл переименования.

Цитата:
Сообщение от skuull Посмотреть сообщение
Еще появляется сложность из-за того что из нижних пакетов не видно объектов из верхних, т.е. придётся иногда двигать код между ними. Это наверно все хорошо и правильно с точки зрения разделения, модульности и бла-бла, но добавляет сложности без видимого для меня преимущества (если вы не ISV, а просто лабаете моды)
Это да, по сути получается как разработка на разных слоях. Но вот если у Вас был опыт разработки в одном пакете и разных моделях - то как сильно увеличилось время билда в таком режиме? В моем понимании - dll-ка должна создаваться одна на пакет, а не на модель в наших с Вами терминах.

У меня все просто - билд достаточно быстрый, т.к. по сути одна модификация=одна модель=один пакет=одна dll. Конечно уже появились "тяжелые" модели, но это скорее исключение, т.к. тоже приходилось пробовать различные варианты для понимания как организовывать разработку.

Из плюсов моего подхода у меня пока выявился один (не считая скорости билда). Возможно есть еще (а также есть минусы), я просто не сравнивал свой подход с каким-либо другим.
Я делал импорт различных данных из Sharepoint и я смог разделить свой код на 2 части. Одну, которая подключается к Sharepoint, авторизуется и получает данные и вторую, которая эти данные обрабатывает. В результате я создал несколько моделей - одну для работы с Sharepoint и другие, которые ссылаются на эту модель (как будто у меня получилось мини-ISV-решение для импорта из Sharepoint).
Билд модели, которая связана с Sharepoint был усложнен наличием дополнительной dll-ки, написанной на C#. А билд моделей-обработчиков ничем не усложнен и выполняется быстро. В результате получилась ситуация "забилдил и забыл", что очень упрощает дальнейшую разработку в сторону Sharepoint-а

В общем - было бы интересно, с какими плюсами и минусами столкнулись те, кто пошел по пути одного пакета и нескольких моделей в одном пакете.
__________________
Возможно сделать все. Вопрос времени

Последний раз редактировалось sukhanchik; 30.05.2018 в 09:46.
Старый 30.05.2018, 10:39   #18  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
466 / 478 (16) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Кто-нибудь унесите это все в другую тему, а то мы отошли от темы меток. (sukhanchik: Выделено)

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

Пример с SharePoint идеальный для отдельного пакета, т.к. его можно использовать на множестве проектов. Опыт же разделения какстомизаций по моделям у меня отрицательный, т.к. нет ни времени ни бюджета играться в архитектуру. Клиенту нужны простые и кривые моды которые автоматизируют его простые и кривые бизнес процессы. Иногда они настолько неожиданные что о таком и не подумаешь, это заставляет переносить все в один пакет или лепить абстракции там где они не нужны чтобы избавиться от перекрёстных ссылок. Добавляют проблем коллеги которые в модули играться не хотят, а хотят как было в 4ке\9ке\12ке - лепить все в кучу.

Последний раз редактировалось sukhanchik; 30.05.2018 в 10:57.
Старый 30.05.2018, 11:05   #19  
sukhanchik is offline
sukhanchik
Moderator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,591 / 2029 (73) +++++++++
Регистрация: 13.06.2004
Адрес: Москва
Не.. это все понятно. Вопрос не в этом. Я бы тоже хотел лепить все в кучу для экономии времени разработки. Вот разработчику дали задачку - добавить поле на форму. Он должен сбилдить свой проект, чтобы все запустилось. Если он не билдит свой проект, то как он отлаживается? Если он билдит - то как долго? (Ему ж надо весь App Suite перебилдить?)

С хотфиксами ситуация достаточно простая - их необязательно ставить каждые два часа. Вполне достаточно накопить их и оптом (допустим в конце недели) поставить. Ну и организационно добиться того, чтобы их не ставили бесконтрольно. Да и разве Ваши собственные модификации (имеются в виду модификации всей проектной команды) не выходят (выпускаются разработчиком для теста) чаще МСовских? Если уж клиент хочет все в кучу
__________________
Возможно сделать все. Вопрос времени
Старый 30.05.2018, 11:27   #20  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
466 / 478 (16) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Так а при чем тут App Suite ? Вы создаете себе свою модель в своем пакете который имеет ссылку на App Suite. Дальше каждый разработчик создает себе по проекту на модификацию в этой моделе\пакете, это проект билдит и синхронизирует когда ему надо. А билд сервер уже билдит ваш пакет создает из него deployable и вы его накатуете когда куда вам надо накатить. VS прекрасно (почти всегда) умеет билдить 1 проект без надобности билдить всю модель.
За это сообщение автора поблагодарили: sukhanchik (6).
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
instructorbrandon: April 12th, One Hour D365UG Training Webinar on Undocumented Technique for Performance Tuning D365FO Blog bot DAX Blogs 0 11.04.2018 03:42
cleverax: D365FO: Using Bar codes, External codes and GTIN in Warehouse app to identify an item. Blog bot DAX Blogs 0 03.02.2018 21:13
cleverax: D365FO: Manual inbound load rating Blog bot DAX Blogs 0 03.02.2018 21:13
cleverax: D365FO: Fulfilment policies Blog bot DAX Blogs 0 03.02.2018 21:13
axforum blogs: Трудности перехода: опыт переноса модификаций с AX 3.0 SP5 EE на AX 2009 SP1 RU5 EE Blog bot DAX Blogs 0 19.07.2011 03:14
Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

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