21.10.2019, 18:12 | #21 |
Участник
|
Ну это как я понял какой-то сложный отчет с 2 строковыми секциями. Какие данные в диалоге вводит пользователь?
Стандартно такой начинается от недели разработки(плюс описание, плюс тест). А за счет чего достигается скорость по сравнению с X++? все запросы все равно надо реализовать |
|
21.10.2019, 18:32 | #22 |
Banned
|
Цитата:
Я тоже считаю, что на разработку в SSRS уйдет неделя + deployment каждой версии (!) после работы над ошибками. Таких версий у меня оказалось штук 15. Разработка в PowerBI невозможна из-за отсутвия сущностей, их тоже надо программировать и добавить в оценку, ну и потом делать и переделывать UNION в "PowerQuery M", еще то удовольствие. Так вот, сделано было за 34 рабочих часа. Скорость достигается за счет мгновенной проверки и быстрого тестирования (не нужно компилировать), а также практически мгновенного развертывания. Кроме того, не нужно создавать временных таблиц. Последний раз редактировалось EVGL; 21.10.2019 в 18:35. |
|
21.10.2019, 20:53 | #23 |
Участник
|
Цитата:
SSRS отчета GER отчёта существует и вполне работает (коллеги из мс раша наверное могут подтвердить или опровергнуть этот слух) для большинства случаев. Поэтому оценка сверху по сложности для ер отчёта без собственно формата отчёта сводится к оценке времени ssrs отчёта без дизайна. Excel дизайн по мне так набросать гораздо проще чем ssrs дизайн. А вот тестирование ссрс отчётов для меня тёмный лес: как понял опять же из общения сейчас опять же по слухам трэшевый тренд на авто тесты. Как сделать автотест для ссрс слабо представляю, возможно по причинам слабого знания предмета. |
|
22.10.2019, 10:16 | #24 |
Banned
|
Цитата:
Действительно, формат SEPA (ISO20022) практически не отличается для credit transfer (исходящий платеж поставщику, модуль AP) и direct debit (инициированное поставщиком автоматическое списание со счета клиента по выданному тем мандату, модуль AR). Так что есть вполне себе внятное бизнес-обоснование. Для справки: https://ru.wikipedia.org/wiki/%D0%9F...BD%D0%B8%D0%B5 Последний раз редактировалось EVGL; 22.10.2019 в 10:29. |
|
22.10.2019, 11:30 | #25 |
Участник
|
Цитата:
в которой говорится не про требование, а о том что с этим требованием модель и датасорс стали различными полностью уверен, что человек умеет читать тексты и четко осознает что там написано. но приписывает другой смысл, с которым эффективно спорит. ---- вот так мы жили, вот так и живем. и будем так жить пока не помрем. и если мы живем вот так значит так надо! |
|
22.10.2019, 12:11 | #26 |
Banned
|
Вы написали, что требование было "сделать систему, которая берет данные откуда угодно". У меня такой информации нет (хотя я могу просто чего-то не знать), но я привел пример, где решение с абстракцией внутреннего представления от модели БД проистекает из задачи поставленной к одной системе. Более того, это решение в этой форме существовало уже лет 10 (соотв. классы для абстракции появились где-то в AX2009).
Где я извратил ваши доводы? Последний раз редактировалось EVGL; 22.10.2019 в 12:15. |
|
22.10.2019, 12:17 | #27 |
Участник
|
Цитата:
можно я не буду обсуждать где именно вы извратили. а просто процитирую свой текст: |
|
22.10.2019, 12:45 | #28 |
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, мы знаем. Наверное, не одна продажа сорвалась из-за этого: "Чтоооо!!?? Две недели на счет?! Он же должен быть в стандарте!" |
|
23.10.2019, 10:03 | #29 |
Moderator
|
Я, пожалуй, не буду пока высказывать оценку ER в целом. Просто вспомнил, как в далеком 2001ом году я видел список резюме потенциальных разработчиков на X++, с пометками директора по консалтингу. На паре резюме было написано что-то типа "Звезд с неба не хватает. Готов/Готова лепить отчеты".
А теперь пишут: Цитата:
опытный программист или функциональный онсультант с опытом 10+ вроде Ties Philippi или Ludwig Reinhard.
|
|
|
За это сообщение автора поблагодарили: Vadim Korepin (12). |
23.10.2019, 12:52 | #30 |
Участник
|
Цитата:
Сообщение от fed
Я, пожалуй, не буду пока высказывать оценку ER в целом. Просто вспомнил, как в далеком 2001ом году я видел список резюме потенциальных разработчиков на X++, с пометками директора по консалтингу. На паре резюме было написано что-то типа "Звезд с неба не хватает. Готов/Готова лепить отчеты".
А теперь пишут: |
|
23.10.2019, 13:08 | #31 |
Moderator
|
Вообще-то он году в 2005ом ушел в клиентские Айтишники и хотя аксаптой там время от времени занимается, вряд ли он о "нашем решении" говорит. Так что - вероятно путаешь с кем-то.
|
|
23.10.2019, 15:20 | #32 |
Участник
|
см также докуметацию
2 вида пользователей: разработчик и функциональный консультант. Разработчик может сконфигурировать модель данных и добавить новые виды источников данных (например, написать специальный класс, чтобы работало быстро). Функциональный консультант может сконфигурировать как выводить эти данные в каком-то формате. Консультант также может вносить небольшие правки в том, что сконфигурировано разработчиком, делать модели и простые меппинги на структуру данных. Есть специальные роли для обоих видов пользователей, чтобы можно было разграничить доступ. Цитата:
Ну т.е. вы по сути создали свою среду разработки с собственной версионностью, компонентами тестирования, профайлинга и т.п. в браузере. Выглядит конечно круто, но если пользователь - это консультант - то после фразы "Этот компонент используется в качестве источника данных в следующей компоненте в формате. Формат-это компонент который содержит в себе описание структуры документа.." - будет замечание что это too technical
Цитата:
Если разработчик - какое преимущество перед X++? Т..е подобные интеграции о которых тут рассказывали стандартно разрабатывают в Х++ и непонятно зачем переходить на ER.
Microsoft поддерживает 37 стран, отчеты запускаются более чем в 90 странах. Цитата:
Вообще конечно интерестно кто был автором идеи и кто разрабатывал интерфейс. ну т.е. на первый взгляд мне кажется очень сложным и непонятным, даже посмотрев семинар я по памяти не настрою выгрузку о которой там рассказывалось, очень много неочевидных кликов и действий. Показывали ли вы это не-программистам из западного мира, как они на это смотрели/что говорили?
Цитата:
Бухгалтерская отчетность - тоже вызывает вопросы.
Откуда в этих сделанных отчетах берутся данные? Если напрямую запросы к проводкам, это же перестанет работать на миллионах/десятках миллионах записей Т.е. чувствительные к быстродействию части отчета можно реализовать на X++. |
|
23.10.2019, 15:29 | #33 |
Участник
|
Мне кажется хорошо бы отделить в твоих сообщениях наблюдаемые факты от логических заключений. А то непонятно, про что ты точно знаешь, а про что догадываешься.
Я присоединил один из ранних документов со скриншотами вычистив персональные данные (прототип на Ax2012). Надо заметить, что там нет дерева конфигураций а только грид, но источники данных - это дерево и они никогда по другому не отображались. Так же можно заметить что контроль версий уже был и все внутри дизайнеров было похоже на то, что сейчас. |
|
|
За это сообщение автора поблагодарили: EVGL (3). |
23.10.2019, 15:37 | #34 |
Участник
|
Цитата:
|
|
23.10.2019, 17:29 | #35 |
Участник
|
Цитата:
Сообщение от belugin
2 вида пользователей: разработчик и функциональный консультант.
Разработчик может сконфигурировать модель данных и добавить новые виды источников данных (например, написать специальный класс, чтобы работало быстро). Функциональный консультант может сконфигурировать как выводить эти данные в каком-то формате. Консультант также может вносить небольшие правки в том, что сконфигурировано разработчиком, делать модели и простые меппинги на структуру данных. Изменения там не сказать что были элементарные, т.е. потребовалось лезть в таблицы SpecTrans, как-то замороченно вычислять суммы, вычислять итоговые строки, т.е. писать код. Это как-бы стандартная задача, на каком этапе тут возникает ER? Ну т.е. расчитывать что типичный консультант не знающий структуры данных будет что-то конфигурировать нельзя, ему нужен уже готовый файл платежа. Как разработчику зачем мне выбирать для разработки ER рискуя налететь на то, что какое-то требование/запрос трудно или нельзя реализовать в ER? |
|
23.10.2019, 19:48 | #36 |
Участник
|
Цитата:
Сообщение от trud
А зачем они это будут делать? Ну т.е. я вот к примеру делал один из бесконечных вариантов выгрузки платежей
... Ну т.е. расчитывать что типичный консультант не знающий структуры данных будет что-то конфигурировать нельзя, ему нужен уже готовый файл платежа. Как разработчику зачем мне выбирать для разработки ER рискуя налететь на то, что какое-то требование/запрос трудно или нельзя реализовать в ER? а так-то ты прав, конечно, на кой чёрт тратить время на изучение такого инструмента, не оч понятно
__________________
Felix nihil admirari |
|
23.10.2019, 19:54 | #37 |
Участник
|
фу-у-у-ух... а то я уж испугался, что скоро без работы останусь!
__________________
Felix nihil admirari |
|
23.10.2019, 21:50 | #38 |
Banned
|
С любым интерфейсом приходится делать и переделывать. Быстрее, чем в ER я еще нигде не мог переделать, поэтому даже самостоятельно переписал формат перевода NACHA с класса (который остался в D365FO в виде исключения) на ER. Клиент, наверное, не раз мысленно благодарил: я видел, как они вносили изменения после go-live.
|
|
23.10.2019, 22:06 | #39 |
Участник
|
Если завтра банк вдруг решит изменить структуру файла например переставил местами поля или изменив названия каких либо тегов, уменьшить /увеличить точность числа или куча ещё подобных оформительских причуд, либо бухгалтер захочет складировать все запросы в банк виде бумажек екселя с человеческими словами помимо цифирок у себя в папочке и много много чего еще то при реализации в ер разработчик уже возможно не потребуется. Формат может поменять/ создать и консультант.
|
|
23.10.2019, 22:12 | #40 |
Banned
|
Цитата:
Если критиковать всерьез, то по связанной теме Electronic messaging. Это - чудовище Франкенштейна, какой-то безумный конгломерат настроек, электронных отчетов, пишущих в обе стороны, ненужного включения ссылок на объекты X++ в настройках при наличии ER. Ни документации, ни готовых настроек под страну - ничего. Ноль. Я имел удовольствие наблюдать, как одному консультанту пришлось одному из первых настроить передачу испанских счетов. Я все удивлялся: о чем можно беседовать с поддержкой MSFT в течении ПОЛУГОДА? А потом мне весной достался итальянский ESTEROMETRO и я все понял. Это был один из немногих случаев в моей карьере, когда я хотел сдаться от безнадеги и в переносном смысле "вернуть деньги" клиенту. Но повезло добраться до базы данных другого клиента с типовыми настройками. |
|
Теги |
generic electronic reporting, ger |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|