Вебинар по функциональности Электронной отчетности (Electronic reporting) и Электронных сообщений (Electronic messages)

[trud]

Цитата:

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

Формат может поменять/ создать и консультант.

Ну это как было задумано. Но по факту все же это будет не консультант, а или 3 вполне определенных консультанта(EVGL, Ties Philippi или Ludwig Reinhard) или если у вас их нет, задачу просто кинут в разработку

Цитата:

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

Справедливости ради, я слышу замечание "too technical" (именно так, слово в слово) каждый раз. Что и позволило в одном только 2019 году заработать ~10 kEUR только на ER, поскольку клиентам приходится искать кого-то, для кого это "not technical enough", а таких людей в настоящий момент в Европе действительно можно пересчитать по пальцам на одной руке.

Ну так же можно сказать что текущая реализация ER позволяет разработчикам быть загруженными на порядок больше, если бы сделали user friendly реализацию, так как задачи начинают кодить.
А что заставляет клиентов пытаться настроить ER, а не кодировать как раньше?

[axm2017]

Цитата:

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

Ну это как было задумано. Но по факту все же это будет не консультант

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

[trud]

Цитата:

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

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

Ну а кто еще? т.е. вы лично сколько знаете человек которые не могут программировать в X++, но умеют менять формат ER? Я вот всех знакомых спрашиваю, пока все говорят что это очередная неработающая вещь
К тому же требование как правило будет звучать не просто
"поменять местами поля" а -
"для контрагентов валюта которых не равна валюте компании поменять местами поля, для остальных оставить так-же".
Т.е. это надо писать какие-то условия(не знаю формат это или нет)

[axm2017]

Цитата:

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

Ну а кто еще? т.е. вы лично сколько знаете человек которые не могут программировать в X++, но умеют менять формат ER?

Да. Причем они не программисты а консультанты.

Цитата:

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

Я вот всех знакомых спрашиваю, пока все говорят что это очередная неработающая вещь.

Ну у меня навыки экселя к примеру так себе. Однако бухгалтерша тетя Маша в нем творит крайне серъезные расчеты и формулы. Т.е из моего опыта не следует что ексель слабая вещь.

Цитата:

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

Т.е. это надо писать какие-то условия(не знаю формат это или нет)

В формате тоже можно скорее всего там: уровень недо Excel.

[Stitch_MS]

Мне кажется, изначально ER создавался для стандартных форматов электронного обмена сообщениями, это потом добавили столько гибкости, что возникли вопросы. У меня недавно задача была закодить выгрузку датского счета фактуры в XML формате через ER в сторонний Azure Blob Storage. Этот формат уже был в репозитарии. Благодаря удобной точке расширения в коде ER и возможности настроить имя файла по формуле, времени потратил совсем немного.

[belugin]

Цитата:

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

Справедливости ради, я слышу замечание "too technical" (именно так, слово в слово) каждый раз.

Мне было бы интересно услышать ваши мысли что там too technical с вашей точки зрения.

[belugin]

Цитата:

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

В формате тоже можно скорее всего там: уровень недо Excel.

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

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

[Logger]

Может в документации недостаточно примеров как сделать то или иное? И людям кажется что проще закодировать. Собрать бы такие типовые случаи.
По результату можно дать примеры How to do
Или доработать движок
Или...

[axm2017]

Цитата:

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

Может в документации недостаточно примеров как сделать то или иное?

Для начала неплохо бы эту документацию сделать.
По факту есть информация но ее структура не позволяет за часик разобраться и начать ваять.

Учебник с примитивными примерами, позволяющими через час приступить к разработке (Hello word) был бы в самый раз но увы этого от МС не видел.

[EVGL]

Цитата:

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

Мне было бы интересно услышать ваши мысли что там too technical с вашей точки зрения.

Мое мнение тут мало что значит. Мне-то как раз все кажется простым. А вот другие получают шок и сразу сдаются. У меня тут летом был опыт, что меня привлекли в Сан-Франциско, поскольку целый ряд (!) программистов (!) Avanade (!) не мог поднять формат на новую версию derived model, поскольку это банально невозможно сделать в пользовательском интерфейсе, а только через редактирование XML-файла.

[trud]

По поводу - too technical. А вы видели презентацию Николая? ну т.е. он рассматривает выгрузку одной простейшей таблицы, и для этого надо совершить кучу действий и понимать все концепции модуля целиком.
Зачем и для чего так сделано непонятно.
Ну т.е. как я вижу нормальную реализацию этой задачи - нужно выгрузить таблицу. В меню должен быть пункт - новая выгрузка.
Должна быть какая-то основная форма в которой 2 обязательных поля - имя таблицы, формат. Вводим эти 2 поля, выгрузка сразу готова к работе.
можно ее запустить сразу, посмотреть что в ней.
далее уже в этой выгрузке кнопки - настроить формат, настроить данные и т.п.
Где уже можно детально что-то сделать.
В такой концепции это хоть как-то можно будет показывать пользователям.

[axm2017]

Цитата:

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

.. и для этого надо совершить кучу действий и понимать все концепции модуля целиком.
Зачем и для чего так сделано непонятно.

Может это проблема изложения а не системы?

Цитата:

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

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

В таком изложении вы по сути DMF хотите ака Entity это несколько разные вещи с отчетностью.

Если же отчетность то должно быть понимание
-какие данные мы хотим получать (собственно модель) по сути пользовательское описание, которую может накропать консультант кстати.

-откуда сопоставление модели с источниками данных так называемый model mapping) и тут возможно потребуется разРаб.

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

То есть все несколько иначе.

[belugin]

Цитата:

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

По поводу - too technical. ....
В такой концепции это хоть как-то можно будет показывать пользователям.

Я так понял, что жалоба скорее "непонятный интеррфейс" и "слишком много действий" а не too technical. Т.е. причина непонятности необязательно требование технических знаний а избыточная логическая сложность?

[trud]

Ну можно сказать и так. Вообще в MS вроде бы проводят юзер тесты, я лично в одном учавствовал. Т.е. вам рассказывают задачу - в семинаре рассказывается выгрузка простой таблицы, пусть будет к примеру она. Далее показывают интерфейс и спрашивают - куда бы вы тут нажали. Думаю в текущей реализации ER никто не справится.
Можете также показать перед этим таск рекординг по ER и попросить по памяти сделать следующее. думаю процент фейлов тоже будет большим

[AlexSD]

Цитата:

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

Я так понял, что жалоба скорее "непонятный интеррфейс" и "слишком много действий" а не too technical. Т.е. причина непонятности необязательно требование технических знаний а избыточная логическая сложность?

Too technical - понятие индивидуальное. У каждого этот порог - свой.
Но, по моему личному впечатлению, средний мировой уровень консультантского "too technical", находится где-то в районе 4-х математических операций + - * /. Все, что нельзя сложить, вычесть, умножить или поделить - too technical.
Другими словами, вопрос, ответ на который находится в первой ссылке Гугла - too technical.
Я бы добавил еще одно наблюдение, что мысль, "а не поискать ли в гугле решение проблемы" посещает далеко не каждого разработчика Dynamics 365 for Finance and Operations.

[Ace of Database]

Цитата:

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

Too technical - понятие индивидуальное. У каждого этот порог - свой.
Но, по моему личному впечатлению, средний мировой уровень консультантского "too technical", находится где-то в районе 4-х математических операций + - * /. Operations.

Даже операция деления - это уже too technical.

[Владимир Максимов]

Честно говоря, я не осилил до конца всю презентацию. Через час отключаюсь Поэтому тезисно, вкратце

1. "Обычный" пользователь это использовать не сможет. Ни в каком виде. Ни при каких условиях

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

3. Реально - это инструмент разработчика, но для очень специфических, даже не отчетов, а задач по выгрузке информации. Хотя, скорее всего, если не будет прямого приказа, разработчик это тоже использовать не будет...

В моей практике обычно просят выгрузить отчет в Excel. Поэтому все генераторы отчетов (не важно какие) для меня - это лишний посредник. Поэтому восторги по поводу, что ER лучше, чем SSRS, PowerBI и т.д. и т.п. я просто не понимаю. Я то рассматриваю в сравнении с прямой выгрузкой в Excel и вижу лишь усложнение без какой-либо выгоды для меня, как разработчика.


PS: Ну, это очередная попытка сделать нечто "универсальное" под девизом "однотипных операций". Вы что, действительно не замечаете, что даже просто описание этого инструмента требует несколько часов (!) вдумчивого изучения?

Собственно, это все та же тема: Интеграция - использовать стандарт или писать на коленке ?

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

"Что-то в консерватории надо подправить" (с) Вы уже просто не замечаете чрезвычайного усложнения инструмента. "Своя ноша не тянет"

[Stitch_MS]

К сожалению, документация тоже выглядит примерно вот так, т.е. без скриншотов, и изучать это без одновременного кликания в Аксапте затруднительно:

[axm2017]

Цитата:

Сообщение от Владимир Максимов

1. "Обычный" пользователь это использовать не сможет. Ни в каком виде. Ни при каких условиях

Что значит ее не может использовать пользователь?
На нашем проекте вполне себе использует. Жмет кнопку - получает результат. Не вижу причин не использовать и другим.
Более того по мне так это гораздо удобнее чем SSRS где как раз проблем слегка больше.

Цитата:

Сообщение от Владимир Максимов

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

Формулы Excel тоже не простая вещь. не всякий осилит. С учетом что в ER формулы слизаны с Excel сложность освоения +- одинакова.

Цитата:

Сообщение от Владимир Максимов

3. Реально - это инструмент разработчика, но для очень специфических, даже не отчетов, а задач по выгрузке информации. Хотя, скорее всего, если не будет прямого приказа, разработчик это тоже использовать не будет...

Без прямого приказа разработчик вообще работать увы не будет. ER выглядит удобнее чем SSRS мне как разработчику в разы: снимает с меня часть нагрузки, по шаблонам, мелкие ошибки могу править не я и все это делается на лету без перезапуска системы, долгих компиляций и прочих ритуальных плясок.

Цитата:

Сообщение от Владимир Максимов

В моей практике обычно просят выгрузить отчет в Excel. Поэтому все генераторы отчетов (не важно какие) для меня - это лишний посредник. Поэтому восторги по поводу, что ER лучше, чем SSRS, PowerBI и т.д. и т.п. я просто не понимаю. Я то рассматриваю в сравнении с прямой выгрузкой в Excel и вижу лишь усложнение без какой-либо выгоды для меня, как разработчика.

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

Цитата:

Сообщение от Владимир Максимов

Вы что, действительно не замечаете, что даже просто описание этого инструмента требует несколько часов (!) вдумчивого изучения?

Это проблема описателя а не инструмента. Excel на самом деле тоже не простая система и предмет вдумчивого изучения даже не дней.

Цитата:

Сообщение от Владимир Максимов

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

Эмм.. у меня регулярно для тестов возникают вопросы и варганю по этой причине подобное. Но отнимает это действительно несколько минут. В ER. Что делаю не так?

[Владимир Максимов]

axm2017 Я надеюсь, Вы честно не поняли, что именно я написал, а не сознательно исказили смысл, для удобства фальсификации разбив на маленькие кусочки Поэтому попробую повторить еще раз, но более сжато


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

"Порог вхождения" - это объем знаний, которым должен обладать сотрудник для возможности работы с данным инструментом. И я не имею в виду только возможности самого инструмента. Нужно еще много чего знать "вокруг"


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

В младших версиях Axapta для генерации отчетов существовал объект Report. Чтобы создать "с нуля" простейший отчет необходимо сделать следующее

1. Создать новый объект Report
2. В узел Data Source добавить нужную таблицу-источник
3. Выполнить генерацию дизайна
4. Перетащить из Data Source нужные поля в секцию Body

Все. Простейший отчет можно запускать. Для сравнения, попробуйте просто перечислить действия, которые нужны для этого в ER.


Программный вариант выгрузки в Excel. Также в простейшем варианте

static void test(Args _args)
{
    InventItemGroup         InventItemGroup;
    int                     row;
    ComExcelDocument_RU     excel;
    ;

    excel = new ComExcelDocument_RU();
    excel.newFile('', false);
    while select InventItemGroup
    {
        row++;
        excel.insertValue(strFmt("A%1", row), InventItemGroup.Name);
    }
    
    excel.visible(true);
    
    info('End');
}

А вот теперь, объясните, какие преимущества мне, как разработчику, дает использование дополнительных посредников в виде SSRS, PowerBI, ну или вот нового инструмента ER ? Что может заставить меня перейти на эти инструменты, вместо прямого написания кода?