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

[trud]

Цитата:

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

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

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

[EVGL]

Цитата:

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

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

Разработчику, наверное, мало дает. А консультанта заставляет D365. Формат SEPA обязателен во всем Европейском Союзе и в пределах его внешнего влияния, реализован исключительно на ER, хочешь или не хочешь, но учить придется.

А еще безысходность и отчаяние перед экраном Sandbox или Production при залоченном Table browser, отсутствие entities. Я уже до чего только не доходил при импорте данных: http://erconsult.eu/blog/copy-paste-...cel-to-d365fo/ Но я знаю: справиться с импортом project milestones они же on-account transactions я смогу только с помощью ER, поскольку это последний инструмент, который может писать данные в произвольную таблицу. Скажете "щас запрограммируем", но я имею дело с клиентом, который программирует только то, что сам считает нужным, а предложенные консультаном доработки из принципа подвергает дотошной критике. Доходит до маразма: я сам предоставил забесплатно (!) готовый код сущности для проектных предложений (совершенно верно, забыли сделать в стандарте), но заставить отдел разработки клиента заимпортировать мой проект на практике невозможно, поскольку они считают своим долгом поставить наинизший приоритет с прицелом на 2021 год.

С одной стороны, это - крик души, а с другой - смена парадигмы. Еще встречаются не вполне адекватные партнеры и/или клиенты, которые всерьез думают написать целый ISV-модуль за полгода, но их уже меньшинство. Low-code techniques - это уже не только маркетинг, но суровая правда внедрений D365.

[wojzeh]

Цитата:

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

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

жизнь!

а если серьёзно, то напомни-ка, когда в последний раз на проектах внедрения кто-то вспоминал о "преимуществах для разработчика"?

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

Т.е. Вы сознательно искажаете то, что я пытаюсь сказать. Не случайность, значит. Ну, ок. Не вижу смысла в дальнейшей дискуссии...

[axm2017]

Международный проект. Стажёры (сейчас уже статус новичков, на которых можно свалить рутину) понятно российские.
Типовые проблемы для меня имхо:
Крайне неудобный интерфейс прежде всего.
Не знаю про автотесты.
Неустоявшаяся методология (часть полученных принципов были не совсем корректны) .
Отсутствие нормальной учебной документации, даже на уровне hello world или как сделать отчёт за пять минут, что и приводит к дисскуссиям слепых мудрецов о слоне по тактильным ощущениям.

Это коротко, помимо обычных рабочих моментов.

Попытаюсь чуть позже развернуть ответы.

[mnt_dx]

Цитата:

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

Международный проект. Стажёры (сейчас уже статус новичков, на которых можно свалить рутину) понятно российские.
Типовые проблемы для меня имхо:
Крайне неудобный интерфейс прежде всего.
Не знаю про автотесты.
Неустоявшаяся методология (часть полученных принципов были не совсем корректны) .
Отсутствие нормальной учебной документации, даже на уровне hello world или как сделать отчёт за пять минут, что и приводит к дисскуссиям слепых мудрецов о слоне по тактильным ощущениям.

Это коротко, помимо обычных рабочих моментов.

Попытаюсь чуть позже развернуть ответы.

Противоречить самому себе у вас в компании/на проекте норма?

Из консультантов в России я кое-как знаком только с одним человеком, который более менее разбирается в ER. По-моему это показатель, что ER инструмент для очень-очень продвинутых консультантов, которые легко сделают отчет в SSRS, поправят view за разработчиком и прочее.

[axm2017]

Цитата:

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

...
Из консультантов в России я кое-как знаком только с одним человеком, который более менее разбирается в ER. .

Это лишь говорит о вашем круге общения. Не более.

[EVGL]

P.S. Ваш "ComExcelDocument_RU" принципиально в облаке работает не может. Так что это еще вопрос, кто что искажает.

[mazzy]

Цитата:

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

реализован исключительно на ER, хочешь или не хочешь, но учить придется.

Прям "исключительно"? И ни в какой другой системе? Серьезно?
Типичный подход "а куда они от нас денутся"

Цитата:

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

А еще безысходность и отчаяние перед экраном Sandbox или Production при залоченном Table browser, отсутствие entities.
...принципиально в облаке работает не может.

Это были плюсы для ER или минусы для всей Аксапты в целом?
Стокгольмский синдром какой то.

[sukhanchik]

Цитата:

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

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

К сожалению, заставляет переходить сам Microsoft. Когда-то этот вопрос я задавал своим друзьям "что меня может заставить начать программировать под Windows и перестать программировать под DOS?". Сейчас этот вопрос кажется смешным.
Прямое написание кода в D365 в условиях реальной работы системы настолько усложнено, что ER как ни странно - это действительно выход, хотя внешне и получается, что сначала Microsoft ставит барьеры (усложняя разработку), а потом героически их преодолевает (выпуская ER).

Цитата:

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

Разработчику, наверное, мало дает. А консультанта заставляет D365.
...
Low-code techniques - это уже не только маркетинг, но суровая правда внедрений D365.

Именно так.

Цитата:

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

Типичный подход "а куда они от нас денутся"

К сожалению, такой подход продолжает еще работать . Как бы все громко не кричали об отказе от доллара - сей корабль еще не утонул. Так и тут. Т.е. как бы кажется очевидно, что смена парадигмы с легкого кодинга на тяжелую настройку - неудобна, но по факту народ смиряется и переходит. Когда-то конечно может случиться критическая ситуация и всё рухнет, но тут как с долларом - никто не знает когда, а главное - все понимают, что лет 5 - для ИТ-шного мира - это вечность и всё может измениться за это время.

[axm2017]

-Неудобный интерфейс прежде всего.
Про крайне неудобную при большом объеме работ дизайн раб инструментов уже высказывался, но выскажусь еще раз: устаревшие и порой крайне неудобны с учетом что сейчас 19 год. Ни подсветки ни чего пока нет. Надеюсь MS снизойдет и сделает возможность расширения инструментов работы.

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

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

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

Отсутствует инструмент тестирования совместимости версий что не good как по мне.
Чуть попозже попробую проиллюстрировать примером.

ЗЫ кстати на всякий случай уточню что ER при всех недостатках мне нравится и выглядит предпочтительнее чем SSRS ( который к тому же вроде скоро умрет) в силу простоты, скорости и гибкости.

[axm2017]

Цитата:

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

..
Чуть попозже попробую проиллюстрировать примером.
..

Так как уровень читателя неизвестен то иногда прокомментирую что такое ER в моем понимании.

Начну с основы

ER - система подготовки отчетности.
Держится она на трех китах:
Любой отчет это прежде всего какой то формат представления данных:word, excel, xml и т п. Поэтому один из китов - это формат отчетности.

В отчете пользователь хочет увидеть какие то данные: например имя и идентификатор кого то. Представление пользователя о данных называют моделью.

Понятно что модель и реальные данные системы это разные вещи порой и их надо как то соотносить. Для этого есть mapping.

[axm2017]

Вот пришел ко мне пользователь ака консультант и выдал традиционное:
axm2017 нужно срочно завтра-вчера сделать отчет в котором хочу увидеть:
- имя пользователя
-идентификатор пользователя
а так как ты земляной червячок, в сравнении со мной, то твори это все сам.

Задание модели
1 шаг
Придумаем осмысленное название и создадим

2 шаг
Далее жмем Designer и попадаем в режим просмотра/разработки модели, где создаем корневую структуру.

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

4 шаг
Укажем что у каждой записи есть два поля Идентификатор и Имя создав соответствующие свойства в пользователе


Итого получим что то типа


Сохраняем изменения скомплектовав модель (Change status)


Ура мы создали тестовую модель.
PS небольшие комментарии: надписи задаем либо как надписи либо метками. Метки у ER свои что позволяет задавать/исправлять перевод без лишних телодвижений.

[axm2017]

Цитата:

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

...то по mapping у нас была неправильная рекомендация стараться жить с одним mapping лишь дорабатывая его. Как показала практика жить на одном mapping пытаясь не сломать существующее модифицировать основываясь на других источниках данных крайне сложно и не стоит усилий. Проще сделать новый mapping...
Чуть попозже попробую проиллюстрировать примером.

Проиллюстрирую возникающую проблему с рекомендацией.
Предположим у нас есть все из примера 1 и это всем нравится до такой степени что китайские сотрудники попросили запилить почти такой же отчет.
Ок. Не вопрос. Делаем почти такой же формат.
Но китайские товарищи к примеру начинают хотеть порой свое уникальное значение в поле идентификатор так как мое их не устроило (из другого источника данных связанного с табличкой).
Попытки решить подобное изначально в рамках одного mapping (типа добавим поле IdFromChine и прочее) оказались крайне неудобными. Отчеты и модели жили своей жизнью росли, покрываясь расчетными функциями и прочим и это же касалось mapping (где надо было помнить еще и о китайцах) в итоге поддержка подобной уникальности оказалась трудозатратной.

Проще оказалось сделать новый mapping хотя изначально рекомендовалось жить в одном маппинге.

[belugin]

Цитата:

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

Попытки решить подобное изначально в рамках одного mapping (типа добавим поле IdFromChine и прочее) оказались крайне неудобными.

Чем?

[axm2017]

Цитата:

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

Чем?

По факту у нас есть ID для китайских и отдельно для обычных людей.

Какие есть варианты действий?

1. Добавить в модель поле китайский ID.
А потом индийский. А потом выслушать обвинение в расизме от консультанта почему китайский ID идет отдельно (типа ты их за людей не считаешь?).

2. Добавить заполнение ID на маппинге для китайцев свое, а для обычных свое. Ок вводим функцию определитель страны и в зависимости от нее заполняем ID. Но так как в реальности появляется куча наворотов + еще и индийцы то все становится тяжелым и не все помнят о существовании китайских коллег. Есть высокая вероятность что кто то сломает им все, правя для себя. В общем пришли к тому что надо разделять маппинги.

[belugin]

Цитата:

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

1. Добавить в модель поле китайский ID.
А потом индийский. А потом выслушать обвинение в расизме от консультанта почему китайский ID идет отдельно (типа ты их за людей не считаешь?).

Это реальный кейз уже были такие претензии? Почему именно китайский идентификатор не такой как у всех? Если это требование какого-то стандарта типа IBAN, то вполне можно назвать его ID_<название стандарта>. Например, в ISO20022 к банкам привязано множество пар (схема идентификации, значение), где схема идентификации - это как раз разновидность такого стандарта.

Стандарты можно не считать за людей

[Libovs]

Может ли кто-то подсказать, почему при настройке формата я не могу сопоставить xml-элемент с полем записи? Связывается только со Списком записей.
В сформированном xml-документе табличная часть должна представляться
<Номенклатура ROWNUM="1">Стол</Номенклатура>
<Номенклатура ROWNUM="2">Стул</Номенклатура>
<Цена ROWNUM="1">200.00</Цена>
<Цена ROWNUM="2">120.00</Цена>

В конструкторе форматов добавляю xml-элементы Номенклатура и Цена; в каждом из них - xml-атрибут ROWNUM.
В Сопоставлении атрибут ROWNUM связывается с полем LineNum, а элементы Номенклатура и Цена не могу связать с ItemName и SalesPrice - кнопка Связать неактивна.
Что я делаю не так?

[EVGL]

Я так понимаю, что <Номенклатура/> должна быть включена в Sequence, Sequence связывается со списком, а тогда отдельное поле в формате можно связать с полем записи.

[axm2017]

Цитата:

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

...
Что я делаю не так?

Проверьте типы: integer можно связать с Integer, строчку связать со строчкой а вот integer со строчкой уже не факт.