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

[trud]

Ну это как я понял какой-то сложный отчет с 2 строковыми секциями. Какие данные в диалоге вводит пользователь?
Стандартно такой начинается от недели разработки(плюс описание, плюс тест). А за счет чего достигается скорость по сравнению с X++? все запросы все равно надо реализовать

[EVGL]

Цитата:

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

Ну это как я понял какой-то сложный отчет с 2 строковыми секциями. Какие данные в диалоге вводит пользователь?
Стандартно такой начинается от недели разработки(плюс описание, плюс тест). А за счет чего достигается скорость по сравнению с X++? все запросы все равно надо реализовать

Данные в диалоге - это выбор кода проекта.

Я тоже считаю, что на разработку в SSRS уйдет неделя + deployment каждой версии (!) после работы над ошибками. Таких версий у меня оказалось штук 15. Разработка в PowerBI невозможна из-за отсутвия сущностей, их тоже надо программировать и добавить в оценку, ну и потом делать и переделывать UNION в "PowerQuery M", еще то удовольствие.

Так вот, сделано было за 34 рабочих часа.

Скорость достигается за счет мгновенной проверки и быстрого тестирования (не нужно компилировать), а также практически мгновенного развертывания. Кроме того, не нужно создавать временных таблиц.

[axm2017]

Цитата:

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

..
Стандартно такой начинается от недели разработки(плюс описание, плюс тест)...

Кстати из общения как понял что стандартный фреймворк для использования вместо
SSRS отчета GER отчёта существует и вполне работает (коллеги из мс раша наверное могут подтвердить или опровергнуть этот слух) для большинства случаев.

Поэтому оценка сверху по сложности для ер отчёта без собственно формата отчёта сводится к оценке времени ssrs отчёта без дизайна.
Excel дизайн по мне так набросать гораздо проще чем ssrs дизайн.

А вот тестирование ссрс отчётов для меня тёмный лес: как понял опять же из общения сейчас опять же по слухам трэшевый тренд на авто тесты.

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

[EVGL]

Цитата:

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

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

Это уже изначально так было в семействе классов CustVendOutPayment: содержание было абстрагировано от модуля (клиент/поставщик) и направления платежа (входящий/исходящий).

Действительно, формат SEPA (ISO20022) практически не отличается для credit transfer (исходящий платеж поставщику, модуль AP) и direct debit (инициированное поставщиком автоматическое списание со счета клиента по выданному тем мандату, модуль AR).

Так что есть вполне себе внятное бизнес-обоснование.

Для справки: https://ru.wikipedia.org/wiki/%D0%9F...BD%D0%B8%D0%B5

[mazzy]

Цитата:

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

Цитата:

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

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

Так что есть вполне себе внятное бизнес-обоснование.

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

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

----
вот так мы жили,
вот так и живем.
и будем так жить
пока не помрем.

и если мы живем вот так
значит так надо!

[EVGL]

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

Где я извратил ваши доводы?

[mazzy]

Цитата:

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

Вы написали, что требование было "сделать систему, которая берет данные откуда угодно".
У меня такой информации нет.
...
Более того, это решение в этой форме существовало уже лет 10 (соотв. классы для абстракции появились где-то в AX2009).

Где я извратил ваши доводы?

можно я просто оставлю эту цитату.
можно я не буду обсуждать где именно вы извратили.

а просто процитирую свой текст:

Цитата:

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

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

[EVGL]

Ну то есть ушли от ответа. Тоже вариант, можно конечно.

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

Вы, однако, сформулировали это так, что модель и не нужна бы (я могу ошибаться, но это был конструктивный посыл в вашей критике). Предположим так, те же CustVentOutPaym классы сущестовали 20 лет назад в форме, где не было абстракций. Только сразу возникает вопрос: если работать напрямую и только с объектами системы, то DBadmin был бы необходим при каждом использовании инструмента. При использовании же связки DB -> Model -> Format в 50% случаев по факту можно обойтись работой с только форматом. Т.е. настройщик должен знать "лишь" уровень абстракции Model.

Это - лишнее, говорят читатели форума. Ок, у меня тоже сносит крышу, когда я пытаюсь вспомнить кто такой будет Debtor в конкретном случае, поэтому я и написал самому себе памятку http://erconsult.eu/blog/electronic-...g-er-cookbook/. От класса CustVendPaym, который был предтечей, мне тоже сносило крышу.

Мы сделаем все на PowerBI, говорят читатели форума. Только PowerBI near-realtime и не поддерживает страницы. Т.е. инвойс на нем принципиально не напечатать. А сколько стоит сделать новый SSRS layout, мы знаем. Наверное, не одна продажа сорвалась из-за этого: "Чтоооо!!?? Две недели на счет?! Он же должен быть в стандарте!"

[fed]

Я, пожалуй, не буду пока высказывать оценку ER в целом. Просто вспомнил, как в далеком 2001ом году я видел список резюме потенциальных разработчиков на X++, с пометками директора по консалтингу. На паре резюме было написано что-то типа "Звезд с неба не хватает. Готов/Готова лепить отчеты".
А теперь пишут:

Цитата:

опытный программист или функциональный онсультант с опытом 10+ вроде Ties Philippi или Ludwig Reinhard.

[mnt_dx]

Цитата:

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

Я, пожалуй, не буду пока высказывать оценку ER в целом. Просто вспомнил, как в далеком 2001ом году я видел список резюме потенциальных разработчиков на X++, с пометками директора по консалтингу. На паре резюме было написано что-то типа "Звезд с неба не хватает. Готов/Готова лепить отчеты".
А теперь пишут:

Этот директор из тех, кто с гордостью говорит, что в их решении от стандартной АХ ничего не осталось?

[fed]

Цитата:

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

Этот директор из тех, кто с гордостью говорит, что в их решении от стандартной АХ ничего не осталось?

Вообще-то он году в 2005ом ушел в клиентские Айтишники и хотя аксаптой там время от времени занимается, вряд ли он о "нашем решении" говорит. Так что - вероятно путаешь с кем-то.

[belugin]

см также докуметацию

Цитата:

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

А кто предполагается как пользователь этого ER модуля?

2 вида пользователей: разработчик и функциональный консультант.
Разработчик может сконфигурировать модель данных и добавить новые виды источников данных (например, написать специальный класс, чтобы работало быстро). Функциональный консультант может сконфигурировать как выводить эти данные в каком-то формате. Консультант также может вносить небольшие правки в том, что сконфигурировано разработчиком, делать модели и простые меппинги на структуру данных.

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

Цитата:

Ну т.е. вы по сути создали свою среду разработки с собственной версионностью, компонентами тестирования, профайлинга и т.п. в браузере. Выглядит конечно круто, но если пользователь - это консультант - то после фразы "Этот компонент используется в качестве источника данных в следующей компоненте в формате. Формат-это компонент который содержит в себе описание структуры документа.." - будет замечание что это too technical

Мне не очень понятно какой именно слово тут техническое - компонент, структура, формат? Там нет регистров процессора или чего-то типа этого, я думаю, это общечеловеческие слова.

Цитата:

Если разработчик - какое преимущество перед X++? Т..е подобные интеграции о которых тут рассказывали стандартно разрабатывают в Х++ и непонятно зачем переходить на ER.

Выше уже что-то написали, я могу добавить что мы видим что многие предпочитают делать свои отчеты, хотя есть возможность сделать что-то на X++, powerbi, DIXF и так далее.

Microsoft поддерживает 37 стран, отчеты запускаются более чем в 90 странах.

Цитата:

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

Перед выпуском мы делали UX тестирование именно на западных пользователях. Кому-то было понятно, кому-то нет, кое-что мы по результатам поправили.

Цитата:

Бухгалтерская отчетность - тоже вызывает вопросы.
Откуда в этих сделанных отчетах берутся данные?
Если напрямую запросы к проводкам, это же перестанет работать на миллионах/десятках миллионах записей

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

Т.е. чувствительные к быстродействию части отчета можно реализовать на X++.

[belugin]

Цитата:

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

Макс Белугин показывал ранний прототип - логичная и привычная штука.

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

Я присоединил один из ранних документов со скриншотами вычистив персональные данные (прототип на Ax2012).

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

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

[belugin]

Цитата:

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

При использовании же связки DB -> Model -> Format в 50% случаев по факту можно обойтись работой с только форматом. Т.е. настройщик должен знать "лишь" уровень абстракции Model.

В принципе изначально идея была в том, чтобы model был просто классом, который писал X++ программист, а формат был как движок шаблонов. Потом, решили сделать это тоже конфигурируемым для простых случаев и мелких правок программист ну нужен. Слой model нужен чтобы:

1. Скрыть от функционального консультанта сложности модели данных AX
2. При изменениях модели данных разные виды отчетов оставались совместимыми
   (вспомните, например, что произошло при переходе с Ax2009 на Ax2012 - понятие счета ГК осталось, но способ получения их разный)
3. То, про что сказал Маззи - возможность добавлять принципиально другие источники данных

[trud]

Цитата:

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

2 вида пользователей: разработчик и функциональный консультант.
Разработчик может сконфигурировать модель данных и добавить новые виды источников данных (например, написать специальный класс, чтобы работало быстро). Функциональный консультант может сконфигурировать как выводить эти данные в каком-то формате. Консультант также может вносить небольшие правки в том, что сконфигурировано разработчиком, делать модели и простые меппинги на структуру данных.

А зачем они это будут делать? Ну т.е. я вот к примеру делал один из бесконечных вариантов выгрузки платежей в банк(по моему похожее на класс CustVendChequeUS). Т.е. изначально пользователи запросили выгрузку в текстовый файл определенной структуры. Передали ее консультанту. Он разработал дизайн, что нужен текстовый файл, и как эти поля заполнять. Этот дизайн передали в разработку. Я задублировал текущий класс, сделал свои исправления. Передал на тест. Они в форматах платежа выбрали этот класс, протестировали. Консультант совсем не горел желанием "вносить небольшие правки" т.е. файл утверждается банком и не меняется.
Изменения там не сказать что были элементарные, т.е. потребовалось лезть в таблицы SpecTrans, как-то замороченно вычислять суммы, вычислять итоговые строки, т.е. писать код.
Это как-бы стандартная задача, на каком этапе тут возникает ER?
Ну т.е. расчитывать что типичный консультант не знающий структуры данных будет что-то конфигурировать нельзя, ему нужен уже готовый файл платежа. Как разработчику зачем мне выбирать для разработки ER рискуя налететь на то, что какое-то требование/запрос трудно или нельзя реализовать в ER?

[wojzeh]

Цитата:

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

А зачем они это будут делать? Ну т.е. я вот к примеру делал один из бесконечных вариантов выгрузки платежей
...
Ну т.е. расчитывать что типичный консультант не знающий структуры данных будет что-то конфигурировать нельзя, ему нужен уже готовый файл платежа. Как разработчику зачем мне выбирать для разработки ER рискуя налететь на то, что какое-то требование/запрос трудно или нельзя реализовать в ER?

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

а так-то ты прав, конечно, на кой чёрт тратить время на изучение такого инструмента, не оч понятно

[wojzeh]

Цитата:

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

2 вида пользователей: разработчик и функциональный консультант.

фу-у-у-ух... а то я уж испугался, что скоро без работы останусь!

[EVGL]

Цитата:

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

Это как-бы стандартная задача, на каком этапе тут возникает ER?

С любым интерфейсом приходится делать и переделывать. Быстрее, чем в ER я еще нигде не мог переделать, поэтому даже самостоятельно переписал формат перевода NACHA с класса (который остался в D365FO в виде исключения) на ER. Клиент, наверное, не раз мысленно благодарил: я видел, как они вносили изменения после go-live.

[axm2017]

Цитата:

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

... Как разработчику зачем мне выбирать для разработки ER рискуя налететь на то, что какое-то требование/запрос трудно или нельзя реализовать в ER?

Если завтра банк вдруг решит изменить структуру файла например переставил местами поля или изменив названия каких либо тегов, уменьшить /увеличить точность числа или куча ещё подобных оформительских причуд, либо бухгалтер захочет складировать все запросы в банк виде бумажек екселя с человеческими словами помимо цифирок у себя в папочке и много много чего еще то при реализации в ер разработчик уже возможно не потребуется. Формат может поменять/ создать и консультант.

[EVGL]

Цитата:

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

Цитата:

...too technical...

Мне не очень понятно какой именно слово тут техническое - компонент, структура, формат? Там нет регистров процессора или чего-то типа этого, я думаю, это общечеловеческие слова.

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

Если критиковать всерьез, то по связанной теме Electronic messaging. Это - чудовище Франкенштейна, какой-то безумный конгломерат настроек, электронных отчетов, пишущих в обе стороны, ненужного включения ссылок на объекты X++ в настройках при наличии ER. Ни документации, ни готовых настроек под страну - ничего. Ноль.
Я имел удовольствие наблюдать, как одному консультанту пришлось одному из первых настроить передачу испанских счетов. Я все удивлялся: о чем можно беседовать с поддержкой MSFT в течении ПОЛУГОДА? А потом мне весной достался итальянский ESTEROMETRO и я все понял. Это был один из немногих случаев в моей карьере, когда я хотел сдаться от безнадеги и в переносном смысле "вернуть деньги" клиенту. Но повезло добраться до базы данных другого клиента с типовыми настройками.