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

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

Цитата:

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

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

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

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

[belugin]

Цитата:

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

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

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

[EVGL]

Цитата:

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

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

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