kurthatlevik: Great stuff on the D365 roadmap

[Blog bot]

Источник: https://kurthatlevik.wordpress.com/2...-d365-roadmap/
==============

What we currently see is that more and more power user functionality is introduced step-by-step to make Dynamics 365 ready for the next natural technological step; to become a true SaaS solution built as a Azure service fabric. Check out this video from Microsoft for what I hope is the future and architecture direction for Dynamics 365. But before we get there, there have to be a natural transition of making Dynamics 365 more configurable and less dependent on creating your own customizations and extensions.

Now and then I try to keep an eye on the D365 roadmap for signs on this transition, and today I found these nice features that I think will be highly valuable. I have copied the descriptions from the roadmap, and the release date is not clear, but I look forward to present these great enhancements to my customers.

1. Power users can add custom fields to forms without developer customization


Many application customizations involve adding one or more fields to existing tables and including them in application forms. Most of your customizations may be comprised of adding fields.

Customizations are expensive because they require developer intervention for development, test, and code life cycle management. Customizations also need to be managed and migrated from one environment to another.

We are making it easier to add custom fields to forms in Dynamics 365 for Finance and Operations, Enterprise edition. No longer will developer customization be needed. Instead, a power user will be able to add a custom field to a table and then place that field on the form using personalization. An IT administrator will then be able to share the personalization with others in your organization.

2. Product lifecycle state


The product lifecycle state will be introduced for released products and product variants. You can define any number of product lifecycle states by assigning a state name and description. You can select one lifecycle state as the default state for new released products. Released product variants inherit the product lifecycle state from their released product masters. When changing the lifecycle state on a released product master, you can choose to update all existing variants that have the same original state.

To control and understand the situation of a specific product or product variant in its lifecycle, it is a best practice in Product lifecycle management solutions (PLM) to associate a lifecycle state with a variable state model to products. This capability will be added to the released product model. The main purpose of this extension is to provide a scalable solution that can exclude obsolete products and product variants, including configurations, from master planning and BOM-level calculation.

Impact on master planning – The product lifecycle state has only one control flag: Is active for planning. By default, this is set to Yes for all product lifecycle states. When the field is set to No, the associated released products or product variants are:

• Excluded from Master planning
• Excluded from BOM level calculation

For performance reasons, it is highly recommended to associate all obsolete released products or product variants to a product lifecycle state that is deactivated for master planning, especially when you work with non-reusable product configuration variants.

Find obsolete released products and products variants – You can run an analysis to find and update obsolete released products or product variants.

If you run the analysis in a simulation mode, the released products and product variants that are identified as obsolete will be displayed on a specific page for you to view. The analysis searches for transactions and specific master data to find the released products or product variants that have no demand within a specific period. New released products that are created within the specific period can be excluded from the analysis.

When the analysis simulation returns the expected result, you can run the analysis by assigning a new product lifecycle state to all the products that are identified as obsolete.

Default value during migration, import, and export


When migrating from previous releases, the lifecycle state for all released products and product variants will be blank.

When importing released products through a data entity, the default lifecycle state will be applied.

When importing released product variants through a data entity, the product lifecycle state of the released product master will be applied.

Note, the ability to set individual product lifecycle states using the data entities for released products or product variants is not supported.

3. Users can pin PowerApps to forms and share with peers to augment functionality


Have you built a PowerApp that uses or shows data from Dynamics 365 for Finance and Operations, Enterprise edition? Or have you been using a PowerApp built by someone in your organization? Would you like to use PowerApps to build last-mile applications that augment the functionality of Finance and Operations?

Your users can build PowerApps without having to be expert developers to extend ERP functionality. PowerApps developed by yourself, your organization, or the broader ecosystem can now be used to augment ERP functionality by including them within the Finance and Operations client.

Your users will be able to pin PowerApps to pages in Finance and Operations. After they’ve been added, these changes can be shared with peers in your organization as personalizations.

 

Disclaimer: The opinions and views expressed in this blog are those of the author and do not necessarily state or reflect those of Microsoft, my employer <a href="https://global.eg.dk/" />EG or other parties.





Источник: https://kurthatlevik.wordpress.com/2...-d365-roadmap/

[trud]

Цитата:

1. Power users can add custom fields to forms without developer customization

Ух. хранить интересно в SysLastValue будут?

[ax_mct]

Цитата:

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

Ух. хранить интересно в SysLastValue будут?

Цитата:

We are making it easier to add custom fields to forms in Dynamics 365 for Finance and Operations, Enterprise edition. No longer will developer customization be needed. Instead, a power user will be able to add a custom field to a table and then place that field on the form using personalization. An IT administrator will then be able to share the personalization with others in your organization.

Это все можно и в AX2012 к примеру. Или они просто аннонсируют с таким апломбом что старая фича перенесена в новую версию?

В нормальных версиях AX мы сохраняем конкретный список переменных в SysLastValue в том случае если данная форма реализует явно методы этого интерфейс вместе с pack/unpack. То есть вы указываем явно какие переменные мы храним в упаковочном списке.

К контролам как таковым SysLastValue отношения не имеет.

Если же о том что web-контрол хранит значение между обновлениями страницы, то это свойство общее и не имеет отношение к SysLastValue.

[trud]

Цитата:

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

Это все можно и в AX2012 к примеру. Или они просто аннонсируют с таким апломбом что старая фича перенесена в новую версию?

В смысле можно? - Instead, a power user will be able to add a custom field to a table and then place that field on the form

в 2012 пользователи не могут добавить поле в таблицу без доступа к разработке

[ax_mct]

Цитата:

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

В смысле можно? - Instead, a power user will be able to add a custom field to a table and then place that field on the form

в 2012 пользователи не могут добавить поле в таблицу без доступа к разработке

Согласен с аргументом, да, новая крутая фича. From $210 per user/month

[Stitch_MS]

Интересно, какой процент кастомизированных полей нужен просто для хранения данных, т.е. не должен протаскиваться бизнес-логикой куда-то ещё?

[fed]

Цитата:

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

Интересно, какой процент кастомизированных полей нужен просто для хранения данных, т.е. не должен протаскиваться бизнес-логикой куда-то ещё?

Это очень полезная фича, позволяющая при продаже Axapta заранее выявить и идентифицировать всех проблемных сотрудников клиента. Всех пользователей, которым эта фича понравилась, желательно изолировать и исключить от участия в проекте

[trud]

т.е. похоже технически это будет таблица с полями TableRefId, TableRecId и плюс по 20-30 полей каждого типа(20 строк, 20 real, 20Int) которая будет джойнится к основной таблице формы. ну и плюс какая то настроечная форма, где можно будет задавать лейбл полей в зав-ти от формы.
по идеи такое несложно сделать и для 2012, только нафиг никому не нужно. ну и да, при продаже наверное будет неплохо смотреться
забавно будут смотреться модификации, когда попросят поле с номером 14, вывести в отчет или что-нибудь делать в зав-ти от него

[TasmanianDevil]

Цитата:

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

по 20-30 полей каждого типа

Скорее всего по одному полю на каждый тип, но использоваться будет только одно из N., либо вообще N таблиц (для каждого типа) с одним значимым полем (кроме ссылок на запись-владельца и ссылки на описатель самого поля, конечно же ) И вот уже в build-time будут собираться сведения о том, какие доп. поля доступны для таблиц, которые задействованы в качестве источников данных на форме, создавать для этих полей N-ное кол-во экземпляров источников данных, при-join'енных к исходным источникам данных формы, а в дизайне - создаваться контролы новых полей, завязанные на новые источники данных.

Вполне реально выглядит...

[EVGL]

Цитата:

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

Это очень полезная фича, позволяющая при продаже Axapta заранее выявить и идентифицировать всех проблемных сотрудников клиента. Всех пользователей, которым эта фича понравилась, желательно изолировать и исключить от участия в проекте

Подход "custom field through a configuration" активно используется во внедрениях Dynamics CRM и Oracle E-Business Suite. У пользователей и консультантов, пришедших с этих продуктов, необходимость программировать на каждый чих в AX всегда вызывала недоумение. Посему праведное возмущение не разделяю.

[trud]

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

[fed]

Цитата:

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

Подход "custom field through a configuration" активно используется во внедрениях Dynamics CRM и Oracle E-Business Suite. У пользователей и консультантов, пришедших с этих продуктов, необходимость программировать на каждый чих в AX всегда вызывала недоумение. Посему праведное возмущение не разделяю.

Просто консультанты и пользователи сначала создают дикое количество пользовательский полей, а потом начинают хотеть по ним отчеты строить или запросы запрашивать. По моему предыдущему опыту, каждый раз когда кто-то использует модель Entity View Attribute, это кончается ОЧЕНЬ большими проблемами на внедрении. Просто потому что идет попытка решать задачи системного уровня с помощью наколенного инструмента.

[mazzy]

угу.

Цитата:

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

Просто консультанты и пользователи сначала создают дикое количество пользовательский полей

причем разные поля для одних и тех же показателей.

Цитата:

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

а потом начинают хотеть по ним отчеты строить или запросы запрашивать

причем отчеты непременно единые - "у вас же ERP система"

[ax_mct]

Цитата:

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

В смысле можно? - Instead, a power user will be able to add a custom field to a table and then place that field on the form

в 2012 пользователи не могут добавить поле в таблицу без доступа к разработке

Я кстати затупил так как думал что речь о персонализации грида, а не о добавлении новых полей в таблицу.

Наверное потому что это для меня полная тупость?
К каждой строке мы можем прикрепить запись или документ.
В чем смысл добавления полей пользователем в таблицу - я не понимаю.
Суперстар?

Цитата:

We are making it easier to add custom fields to forms in Dynamics 365 for Finance and Operations, Enterprise edition. No longer will developer customization be needed. Instead, a power user will be able to add a custom field to a table and then place that field on the form using personalization. An IT administrator will then be able to share the personalization with others in your organization.

Уверены что это не опечатка? Это же бред. Мне все же сдается что под table по смыслу подразумевается grid так как "add custom fields to forms", "personalization".

[belugin]

А в чем принципиальная разница между программистами насоздававшими полей, консультантами насоздававшими полей и пользователями насоздававшими, скажем, номенклатур? Если не следить будут дубли.

[mazzy]

Цитата:

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

А в чем принципиальная разница между программистами насоздававшими полей, консультантами насоздававшими полей и пользователями насоздававшими, скажем, номенклатур? Если не следить будут дубли.

в такой постановке - ни в чем.

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

дополнительный бизнес-функционал подразумевает, что:
1. пользователи (или другой функционал/скрипт/демон) могут вводить куда-то значения дополнительных параметров (или система сама сможет забирать значения откуда-нибудь)
2. система с этими параметрами что-то делает
3. пользователи получают результаты работы системы (отчеты, другие документы, автоматический вызов чего-нибудь и т.п.)

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

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

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

ну и по таким полям нет никакой валидации, поиска, нормальной сортировки (в виду отсутствия индексов), логирования, экспорта/импорта, настройки прав доступа и прочего такого привычного административного функционала.

)))

в общем, фича которая наглядно демонстрирует насколько разработчики не в курсе того, что на самом деле нужно пользователям.
да, некий ментальный фильтр - ослиный мостик. тут полностью согласен с fed.

[belugin]

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

Прямо сейчас мы можем с тобой наблюдать как в TFS люди пользуются полями UserFieldN вполне себе фильтруя, группируя и строя сводные таблицы по ним. Конечно же сделать доработку которая бы делала это все с валидацией и прочим было бы круто, но для каких-то случаев это впролне себе рабочий компромисс между функционалом и стоимостью доработки. А в твоем опыте не было такого, чтобы просто добавить поле и куда-то его вывести было good enough?

[EVGL]

Цитата:

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

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

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

[fed]

Цитата:

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

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

If you want X, you know where to find it.

[mazzy]

Цитата:

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

было несколько доработок

очень правильное утверждение. "было", "несколько", "доработок".

и ради этого делают фичу. которая НЕИЗБЕЖНО потребует изменения в администрировании, экспорте/импорте, индексах и прочее. )

как будто в аксапте других проблем нет.

Цитата:

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

Прямо сейчас мы можем с тобой наблюдать как в TFS люди пользуются полями UserFieldN вполне себе фильтруя, группируя и строя сводные таблицы по ним.

Да, да! да!!! отлично.

бывают системы, где вводимые и значимые данные совпадают.
это целый класс систем.

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

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

)))
В условиях такого подхода, применять фичу "из TFS"... это просто не знать аксапту

Цитата:

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

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

Ой, господи. Какая подмена понятий. Пожалуйста приведите цитату, в которой я утверждал что что-то не нужно пользователям.


Да, есть системы, где пользовательский ввод вполне допустим.
Это системы в которых пользователь вводит данные непосредственно в итоговые таблицы. TFS, CRM, аксфорум ))) и многие другие.

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

Аксапта - не такая )
Это не хорошо и не плохо. Это просто по-другому.

Не понимать разницу... И пытаться "тыкать носом" в...
Как скажете.

Цитата:

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

Как именно это будет решено, мы не знаем.

Именно!