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

[trud]

Наконец-то осилил семинар. Напишу отзыв
Во первых, спасибо, материал и примеры просто отличные, нет маркетинга, все по делу, но в связи с этим вопрос - можно ли это видео куда-нибудь скачать или выложить на тот-же youtube чтобы при вопросах можно было пересматривать? (текущая запись наверняка имеет ограниченный срок жизни)
По самому контенту:
А кто предполагается как пользователь этого ER модуля? Ну т.е. вы по сути создали свою среду разработки с собственной версионностью, компонентами тестирования, профайлинга и т.п. в браузере. Выглядит конечно круто, но если пользователь - это консультант - то после фразы "Этот компонент используется в качестве источника данных в следующей компоненте в формате. Формат-это компонент который содержит в себе описание структуры документа.." - будет замечание что это too technical
Если разработчик - какое преимущество перед X++? Т..е подобные интеграции о которых тут рассказывали стандартно разрабатывают в Х++ и непонятно зачем переходить на ER. Ну т.е. я с ходу назову только недостатки(отсутствие нормальной контроля версий со всеми бранчами, усложнение развертывания - если выгружаем новое поле к примеру, то надо будет как-то синхронизировать новую версию ER и новую версию приложения с этим полем, сложность настройки и т.п.). Может быть и сейчас есть преимущество что формат можно изменить без остановки системы, но как только MS сделает возможность установки пакетов без остановки, по сути весь модуль потеряет это главное преимущетсво
Т.е. текущая политика Микрософта - что приложения где не требуется кодить делаются в PowerApps - и Микрософт это сильно продвигает(Людвиг вон видео пишет, где тоже файлы загружает-выгружает в XML), где надо - в X++. Какое место тут у ER, непонятно.
Вообще конечно интерестно кто был автором идеи и кто разрабатывал интерфейс. ну т.е. на первый взгляд мне кажется очень сложным и непонятным, даже посмотрев семинар я по памяти не настрою выгрузку о которой там рассказывалось, очень много неочевидных кликов и действий. Показывали ли вы это не-программистам из западного мира, как они на это смотрели/что говорили?

К Николаю - во время рассказа очень много слов-паразитов "соответсвенно" и "э..", это немного отвлекает от сути

Бухгалтерская отчетность - тоже вызывает вопросы.
Откуда в этих сделанных отчетах берутся данные?
Если напрямую запросы к проводкам, это же перестанет работать на миллионах/десятках миллионах записей
Для подобных отчетов стандарт предлагает использовать PowerBI(в варианте DW или BYOD) или Financial reporting, они конечно тоже перестанут работать работать на каком-то объеме данных, но это будет на порядок больше чем прямые запросы к проводкам. Рассматривались ли такие варианты?

[mazzy]

Цитата:

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

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

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

тут интересна история этого модуля:
1.
изначально это было расширение русских финансовых отчетов.
Макс Белугин показывал ранний прототип - логичная и привычная штука. Да, без отладчика и без профайлера. Собственно те же финансовые отчеты. Только больше, ширше, лучше. Работает с аксаптовскими данными, в обычном аксапта-интерфесе, формы с гридами, реализован обычными аксаптовскими объектами, модель и датасорс совпадают.

2,3,4.
я не знаю последовательности, в которой произошли эти события. я застал ER когда в нем уже присутствовали три концепции:

• объекты в ER должны выглядеть в виде дерева
• ER должен работать не только с аксаптовскими данными, но и с NAV, CRM, CDM и прочие дела
• настройка ER должна быть не в X++ коде, а внешним файлом. что позволит вывести настройки за производственный цикл программистов: код-ревью-перевод-коммит-юнит.тестирование-фриз.перед.релизом-новая.версия.Аксапты

======
с деревом все понятно - пропал поиск, работа только через мышку, дерево тормозит на огромном числе объектов из АОТ - нужно делать динамическую подгрузку/выгрузку и т.п.
В общем, с деревом жизнь настройщика усложнилась на порядок - такое ощущение смотришь на глобус через подзорную трубу и каждый момент времени видишь маленький кусочек.

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

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

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

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

бог с ним с маркетингом. главное следствие - не делается никаких инструментов для облегчения совместной жизни DBadmin и powerUser. Партия сказала - там один могучий пользователь.

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

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

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

====

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

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

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

но этот инструмент уже был выведен из общего производственного цикла внутри МС.
разработчики функционала не учитывали ER в своей разработке.
а разработчики отчетов получили свой производственный контур. со своим бюджетом, своим ФОТом, с возможностью творить не согласуя с другими.

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

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

по крайней мере так было года 2-3 назад.

Цитата:

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

Для подобных отчетов стандарт предлагает использовать PowerBI(в варианте DW или BYOD) или Financial reporting, они конечно тоже перестанут работать работать на каком-то объеме данных, но это будет на порядок больше чем прямые запросы к проводкам. Рассматривались ли такие варианты?

это ж надо работать с другими отделами. причем с более мощными внутри МС.

я где-то говорил и повторю: народ внутри МС очень толковый. и очевидные варианты рассматривались.
но свои внутренние задачи имеют повышенный приоритет. и повсеместный подход "а куда эти пользователи денутся".

Цитата:

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

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

а это снова подход "а куда эти пользователи денутся"

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

[EVGL]

Цитата:

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

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

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

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

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

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

[belugin]

Цитата:

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

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

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

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

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

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

[axm2017]

Цитата:

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

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

По факту продвинутый консультант либо разработчик (в смысле пользования как создание отчетов).

Цитата:

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

Если разработчик - какое преимущество перед X++?

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

Потенциально сделали достаточно крутую вещь, которую традиционно для России (?) пока не довели до состояния конфетки, увы.

Цитата:

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

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

Как понимаю ответы такие же как в SSRS.

[belugin]

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

Цитата:

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

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

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

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

Цитата:

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

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

Цитата:

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

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

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

Цитата:

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

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

Цитата:

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

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

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

[trud]

Цитата:

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

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

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

[wojzeh]

Цитата:

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

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

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

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

[EVGL]

Цитата:

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

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

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

[axm2017]

Цитата:

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

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

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

[wojzeh]

Цитата:

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

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

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

[EVGL]

Цитата:

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

Цитата:

...too technical...

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

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

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

[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.

[belugin]

Цитата:

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

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

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

[EVGL]

Цитата:

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

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

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