|
21.10.2019, 15:52 | #1 |
Участник
|
По факту продвинутый консультант либо разработчик (в смысле пользования как создание отчетов).
Сейчас скоростью разработки, как минимум. Если бы не убогость интерфейса, то вполне имеет смысл рекомендовать юзерам, так как гораздо менее тяжелая вещь чем SSRS в Axapta. Потенциально сделали достаточно крутую вещь, которую традиционно для России (?) пока не довели до состояния конфетки, увы. Как понимаю ответы такие же как в SSRS. Последний раз редактировалось axm2017; 21.10.2019 в 15:54. |
|
|
За это сообщение автора поблагодарили: EVGL (10). |
23.10.2019, 15:20 | #2 |
Участник
|
см также докуметацию
2 вида пользователей: разработчик и функциональный консультант. Разработчик может сконфигурировать модель данных и добавить новые виды источников данных (например, написать специальный класс, чтобы работало быстро). Функциональный консультант может сконфигурировать как выводить эти данные в каком-то формате. Консультант также может вносить небольшие правки в том, что сконфигурировано разработчиком, делать модели и простые меппинги на структуру данных. Есть специальные роли для обоих видов пользователей, чтобы можно было разграничить доступ. Цитата:
Ну т.е. вы по сути создали свою среду разработки с собственной версионностью, компонентами тестирования, профайлинга и т.п. в браузере. Выглядит конечно круто, но если пользователь - это консультант - то после фразы "Этот компонент используется в качестве источника данных в следующей компоненте в формате. Формат-это компонент который содержит в себе описание структуры документа.." - будет замечание что это too technical
Цитата:
Если разработчик - какое преимущество перед X++? Т..е подобные интеграции о которых тут рассказывали стандартно разрабатывают в Х++ и непонятно зачем переходить на ER.
Microsoft поддерживает 37 стран, отчеты запускаются более чем в 90 странах. Цитата:
Вообще конечно интерестно кто был автором идеи и кто разрабатывал интерфейс. ну т.е. на первый взгляд мне кажется очень сложным и непонятным, даже посмотрев семинар я по памяти не настрою выгрузку о которой там рассказывалось, очень много неочевидных кликов и действий. Показывали ли вы это не-программистам из западного мира, как они на это смотрели/что говорили?
Цитата:
Бухгалтерская отчетность - тоже вызывает вопросы.
Откуда в этих сделанных отчетах берутся данные? Если напрямую запросы к проводкам, это же перестанет работать на миллионах/десятках миллионах записей Т.е. чувствительные к быстродействию части отчета можно реализовать на X++. |
|
23.10.2019, 17:29 | #3 |
Участник
|
Цитата:
Сообщение от belugin
2 вида пользователей: разработчик и функциональный консультант.
Разработчик может сконфигурировать модель данных и добавить новые виды источников данных (например, написать специальный класс, чтобы работало быстро). Функциональный консультант может сконфигурировать как выводить эти данные в каком-то формате. Консультант также может вносить небольшие правки в том, что сконфигурировано разработчиком, делать модели и простые меппинги на структуру данных. Изменения там не сказать что были элементарные, т.е. потребовалось лезть в таблицы SpecTrans, как-то замороченно вычислять суммы, вычислять итоговые строки, т.е. писать код. Это как-бы стандартная задача, на каком этапе тут возникает ER? Ну т.е. расчитывать что типичный консультант не знающий структуры данных будет что-то конфигурировать нельзя, ему нужен уже готовый файл платежа. Как разработчику зачем мне выбирать для разработки ER рискуя налететь на то, что какое-то требование/запрос трудно или нельзя реализовать в ER? |
|
23.10.2019, 19:48 | #4 |
Участник
|
Цитата:
Сообщение от trud
А зачем они это будут делать? Ну т.е. я вот к примеру делал один из бесконечных вариантов выгрузки платежей
... Ну т.е. расчитывать что типичный консультант не знающий структуры данных будет что-то конфигурировать нельзя, ему нужен уже готовый файл платежа. Как разработчику зачем мне выбирать для разработки ER рискуя налететь на то, что какое-то требование/запрос трудно или нельзя реализовать в ER? а так-то ты прав, конечно, на кой чёрт тратить время на изучение такого инструмента, не оч понятно
__________________
Felix nihil admirari |
|
23.10.2019, 21:50 | #5 |
Banned
|
С любым интерфейсом приходится делать и переделывать. Быстрее, чем в ER я еще нигде не мог переделать, поэтому даже самостоятельно переписал формат перевода NACHA с класса (который остался в D365FO в виде исключения) на ER. Клиент, наверное, не раз мысленно благодарил: я видел, как они вносили изменения после go-live.
|
|
23.10.2019, 22:06 | #6 |
Участник
|
Если завтра банк вдруг решит изменить структуру файла например переставил местами поля или изменив названия каких либо тегов, уменьшить /увеличить точность числа или куча ещё подобных оформительских причуд, либо бухгалтер захочет складировать все запросы в банк виде бумажек екселя с человеческими словами помимо цифирок у себя в папочке и много много чего еще то при реализации в ер разработчик уже возможно не потребуется. Формат может поменять/ создать и консультант.
|
|
23.10.2019, 19:54 | #7 |
Участник
|
фу-у-у-ух... а то я уж испугался, что скоро без работы останусь!
__________________
Felix nihil admirari |
|
23.10.2019, 22:12 | #8 |
Banned
|
Цитата:
Если критиковать всерьез, то по связанной теме Electronic messaging. Это - чудовище Франкенштейна, какой-то безумный конгломерат настроек, электронных отчетов, пишущих в обе стороны, ненужного включения ссылок на объекты X++ в настройках при наличии ER. Ни документации, ни готовых настроек под страну - ничего. Ноль. Я имел удовольствие наблюдать, как одному консультанту пришлось одному из первых настроить передачу испанских счетов. Я все удивлялся: о чем можно беседовать с поддержкой MSFT в течении ПОЛУГОДА? А потом мне весной достался итальянский ESTEROMETRO и я все понял. Это был один из немногих случаев в моей карьере, когда я хотел сдаться от безнадеги и в переносном смысле "вернуть деньги" клиенту. Но повезло добраться до базы данных другого клиента с типовыми настройками. |
|
24.10.2019, 04:21 | #9 |
Участник
|
Ну это как было задумано. Но по факту все же это будет не консультант, а или 3 вполне определенных консультанта(EVGL, Ties Philippi или Ludwig Reinhard) или если у вас их нет, задачу просто кинут в разработку
Цитата:
Сообщение от EVGL
Справедливости ради, я слышу замечание "too technical" (именно так, слово в слово) каждый раз. Что и позволило в одном только 2019 году заработать ~10 kEUR только на ER, поскольку клиентам приходится искать кого-то, для кого это "not technical enough", а таких людей в настоящий момент в Европе действительно можно пересчитать по пальцам на одной руке.
А что заставляет клиентов пытаться настроить ER, а не кодировать как раньше? |
|
24.10.2019, 06:36 | #10 |
Участник
|
|
|
24.10.2019, 09:05 | #11 |
Участник
|
|
|
24.10.2019, 10:31 | #12 |
Banned
|
Мое мнение тут мало что значит. Мне-то как раз все кажется простым. А вот другие получают шок и сразу сдаются. У меня тут летом был опыт, что меня привлекли в Сан-Франциско, поскольку целый ряд (!) программистов (!) Avanade (!) не мог поднять формат на новую версию derived model, поскольку это банально невозможно сделать в пользовательском интерфейсе, а только через редактирование XML-файла.
|
|
21.10.2019, 17:57 | #13 |
Banned
|
Я две недели назад соорудил вот такое:
Вы мне сначала оцените, сколько это займет в PowerBI или SSRS (я в целом представляю, но хотел бы услышать стороннюю оценку), а потом я скажу вам, за сколько я его сделал. За сколько развернул, это уже понятно: 0 дней. Источники данных:
P.S. Для получения лучшей оценки еще пара аспектов для справки: для ReqTrans, ReqTransCov, ProjBudgetLine, ProjTransPosting не существует сущностей. Верхняя таблица - это тройной UNION с группировкой по проектной категории. Отвечая на исходный вопрос trud: рекламируется как инструмент для пользователя, а по факту - опытный программист или функциональный онсультант с опытом 10+ вроде Ties Philippi или Ludwig Reinhard. Последний раз редактировалось EVGL; 21.10.2019 в 18:17. |
|
21.10.2019, 18:12 | #14 |
Участник
|
Ну это как я понял какой-то сложный отчет с 2 строковыми секциями. Какие данные в диалоге вводит пользователь?
Стандартно такой начинается от недели разработки(плюс описание, плюс тест). А за счет чего достигается скорость по сравнению с X++? все запросы все равно надо реализовать |
|
21.10.2019, 18:32 | #15 |
Banned
|
Цитата:
Я тоже считаю, что на разработку в SSRS уйдет неделя + deployment каждой версии (!) после работы над ошибками. Таких версий у меня оказалось штук 15. Разработка в PowerBI невозможна из-за отсутвия сущностей, их тоже надо программировать и добавить в оценку, ну и потом делать и переделывать UNION в "PowerQuery M", еще то удовольствие. Так вот, сделано было за 34 рабочих часа. Скорость достигается за счет мгновенной проверки и быстрого тестирования (не нужно компилировать), а также практически мгновенного развертывания. Кроме того, не нужно создавать временных таблиц. Последний раз редактировалось EVGL; 21.10.2019 в 18:35. |
|
21.10.2019, 20:53 | #16 |
Участник
|
Цитата:
SSRS отчета GER отчёта существует и вполне работает (коллеги из мс раша наверное могут подтвердить или опровергнуть этот слух) для большинства случаев. Поэтому оценка сверху по сложности для ер отчёта без собственно формата отчёта сводится к оценке времени ssrs отчёта без дизайна. Excel дизайн по мне так набросать гораздо проще чем ssrs дизайн. А вот тестирование ссрс отчётов для меня тёмный лес: как понял опять же из общения сейчас опять же по слухам трэшевый тренд на авто тесты. Как сделать автотест для ссрс слабо представляю, возможно по причинам слабого знания предмета. |
|
22.10.2019, 11:30 | #17 |
Участник
|
Цитата:
в которой говорится не про требование, а о том что с этим требованием модель и датасорс стали различными полностью уверен, что человек умеет читать тексты и четко осознает что там написано. но приписывает другой смысл, с которым эффективно спорит. ---- вот так мы жили, вот так и живем. и будем так жить пока не помрем. и если мы живем вот так значит так надо! |
|
22.10.2019, 12:11 | #18 |
Banned
|
Вы написали, что требование было "сделать систему, которая берет данные откуда угодно". У меня такой информации нет (хотя я могу просто чего-то не знать), но я привел пример, где решение с абстракцией внутреннего представления от модели БД проистекает из задачи поставленной к одной системе. Более того, это решение в этой форме существовало уже лет 10 (соотв. классы для абстракции появились где-то в AX2009).
Где я извратил ваши доводы? Последний раз редактировалось EVGL; 22.10.2019 в 12:15. |
|
22.10.2019, 12:17 | #19 |
Участник
|
Цитата:
можно я не буду обсуждать где именно вы извратили. а просто процитирую свой текст: |
|
22.10.2019, 12:45 | #20 |
Banned
|
Ну то есть ушли от ответа. Тоже вариант, можно конечно.
Я не отрицаю наблюдений о том, что нужен многосторонне одаренный человек, чтобы все это обслуживать, более того, я подтвердил это. Вы, однако, сформулировали это так, что модель и не нужна бы (я могу ошибаться, но это был конструктивный посыл в вашей критике). Предположим так, те же CustVentOutPaym классы сущестовали 20 лет назад в форме, где не было абстракций. Только сразу возникает вопрос: если работать напрямую и только с объектами системы, то DBadmin был бы необходим при каждом использовании инструмента. При использовании же связки DB -> Model -> Format в 50% случаев по факту можно обойтись работой с только форматом. Т.е. настройщик должен знать "лишь" уровень абстракции Model. Это - лишнее, говорят читатели форума. Ок, у меня тоже сносит крышу, когда я пытаюсь вспомнить кто такой будет Debtor в конкретном случае, поэтому я и написал самому себе памятку http://erconsult.eu/blog/electronic-...g-er-cookbook/. От класса CustVendPaym, который был предтечей, мне тоже сносило крышу. Мы сделаем все на PowerBI, говорят читатели форума. Только PowerBI near-realtime и не поддерживает страницы. Т.е. инвойс на нем принципиально не напечатать. А сколько стоит сделать новый SSRS layout, мы знаем. Наверное, не одна продажа сорвалась из-за этого: "Чтоооо!!?? Две недели на счет?! Он же должен быть в стандарте!" |
|
Теги |
generic electronic reporting, ger |
|
|