|
23.10.2019, 15:20 | #1 |
Участник
|
см также докуметацию
2 вида пользователей: разработчик и функциональный консультант. Разработчик может сконфигурировать модель данных и добавить новые виды источников данных (например, написать специальный класс, чтобы работало быстро). Функциональный консультант может сконфигурировать как выводить эти данные в каком-то формате. Консультант также может вносить небольшие правки в том, что сконфигурировано разработчиком, делать модели и простые меппинги на структуру данных. Есть специальные роли для обоих видов пользователей, чтобы можно было разграничить доступ. Цитата:
Ну т.е. вы по сути создали свою среду разработки с собственной версионностью, компонентами тестирования, профайлинга и т.п. в браузере. Выглядит конечно круто, но если пользователь - это консультант - то после фразы "Этот компонент используется в качестве источника данных в следующей компоненте в формате. Формат-это компонент который содержит в себе описание структуры документа.." - будет замечание что это too technical
Цитата:
Если разработчик - какое преимущество перед X++? Т..е подобные интеграции о которых тут рассказывали стандартно разрабатывают в Х++ и непонятно зачем переходить на ER.
Microsoft поддерживает 37 стран, отчеты запускаются более чем в 90 странах. Цитата:
Вообще конечно интерестно кто был автором идеи и кто разрабатывал интерфейс. ну т.е. на первый взгляд мне кажется очень сложным и непонятным, даже посмотрев семинар я по памяти не настрою выгрузку о которой там рассказывалось, очень много неочевидных кликов и действий. Показывали ли вы это не-программистам из западного мира, как они на это смотрели/что говорили?
Цитата:
Бухгалтерская отчетность - тоже вызывает вопросы.
Откуда в этих сделанных отчетах берутся данные? Если напрямую запросы к проводкам, это же перестанет работать на миллионах/десятках миллионах записей Т.е. чувствительные к быстродействию части отчета можно реализовать на X++. |
|
23.10.2019, 17:29 | #2 |
Участник
|
Цитата:
Сообщение от belugin
2 вида пользователей: разработчик и функциональный консультант.
Разработчик может сконфигурировать модель данных и добавить новые виды источников данных (например, написать специальный класс, чтобы работало быстро). Функциональный консультант может сконфигурировать как выводить эти данные в каком-то формате. Консультант также может вносить небольшие правки в том, что сконфигурировано разработчиком, делать модели и простые меппинги на структуру данных. Изменения там не сказать что были элементарные, т.е. потребовалось лезть в таблицы SpecTrans, как-то замороченно вычислять суммы, вычислять итоговые строки, т.е. писать код. Это как-бы стандартная задача, на каком этапе тут возникает ER? Ну т.е. расчитывать что типичный консультант не знающий структуры данных будет что-то конфигурировать нельзя, ему нужен уже готовый файл платежа. Как разработчику зачем мне выбирать для разработки ER рискуя налететь на то, что какое-то требование/запрос трудно или нельзя реализовать в ER? |
|
23.10.2019, 19:48 | #3 |
Участник
|
Цитата:
Сообщение от trud
А зачем они это будут делать? Ну т.е. я вот к примеру делал один из бесконечных вариантов выгрузки платежей
... Ну т.е. расчитывать что типичный консультант не знающий структуры данных будет что-то конфигурировать нельзя, ему нужен уже готовый файл платежа. Как разработчику зачем мне выбирать для разработки ER рискуя налететь на то, что какое-то требование/запрос трудно или нельзя реализовать в ER? а так-то ты прав, конечно, на кой чёрт тратить время на изучение такого инструмента, не оч понятно
__________________
Felix nihil admirari |
|
23.10.2019, 21:50 | #4 |
Banned
|
С любым интерфейсом приходится делать и переделывать. Быстрее, чем в ER я еще нигде не мог переделать, поэтому даже самостоятельно переписал формат перевода NACHA с класса (который остался в D365FO в виде исключения) на ER. Клиент, наверное, не раз мысленно благодарил: я видел, как они вносили изменения после go-live.
|
|
23.10.2019, 22:06 | #5 |
Участник
|
Если завтра банк вдруг решит изменить структуру файла например переставил местами поля или изменив названия каких либо тегов, уменьшить /увеличить точность числа или куча ещё подобных оформительских причуд, либо бухгалтер захочет складировать все запросы в банк виде бумажек екселя с человеческими словами помимо цифирок у себя в папочке и много много чего еще то при реализации в ер разработчик уже возможно не потребуется. Формат может поменять/ создать и консультант.
|
|
23.10.2019, 19:54 | #6 |
Участник
|
фу-у-у-ух... а то я уж испугался, что скоро без работы останусь!
__________________
Felix nihil admirari |
|
23.10.2019, 22:12 | #7 |
Banned
|
Цитата:
Если критиковать всерьез, то по связанной теме Electronic messaging. Это - чудовище Франкенштейна, какой-то безумный конгломерат настроек, электронных отчетов, пишущих в обе стороны, ненужного включения ссылок на объекты X++ в настройках при наличии ER. Ни документации, ни готовых настроек под страну - ничего. Ноль. Я имел удовольствие наблюдать, как одному консультанту пришлось одному из первых настроить передачу испанских счетов. Я все удивлялся: о чем можно беседовать с поддержкой MSFT в течении ПОЛУГОДА? А потом мне весной достался итальянский ESTEROMETRO и я все понял. Это был один из немногих случаев в моей карьере, когда я хотел сдаться от безнадеги и в переносном смысле "вернуть деньги" клиенту. Но повезло добраться до базы данных другого клиента с типовыми настройками. |
|
24.10.2019, 04:21 | #8 |
Участник
|
Ну это как было задумано. Но по факту все же это будет не консультант, а или 3 вполне определенных консультанта(EVGL, Ties Philippi или Ludwig Reinhard) или если у вас их нет, задачу просто кинут в разработку
Цитата:
Сообщение от EVGL
Справедливости ради, я слышу замечание "too technical" (именно так, слово в слово) каждый раз. Что и позволило в одном только 2019 году заработать ~10 kEUR только на ER, поскольку клиентам приходится искать кого-то, для кого это "not technical enough", а таких людей в настоящий момент в Европе действительно можно пересчитать по пальцам на одной руке.
А что заставляет клиентов пытаться настроить ER, а не кодировать как раньше? |
|
24.10.2019, 06:36 | #9 |
Участник
|
|
|
24.10.2019, 07:07 | #10 |
Участник
|
Цитата:
К тому же требование как правило будет звучать не просто "поменять местами поля" а - "для контрагентов валюта которых не равна валюте компании поменять местами поля, для остальных оставить так-же". Т.е. это надо писать какие-то условия(не знаю формат это или нет) |
|
24.10.2019, 07:59 | #11 |
Участник
|
Цитата:
Цитата:
В формате тоже можно скорее всего там: уровень недо Excel. |
|
24.10.2019, 09:09 | #12 |
Участник
|
Можно продублировать одно из полей и поставить на них свойство enabled, чтобы выводить с разным порядком по условиям.
В принципе, мы на EXCEL очень сильно ориентировались - большинство функций языка формул старались скопировать из него и синтаксис по максимуму. |
|
24.10.2019, 09:05 | #13 |
Участник
|
|
|
24.10.2019, 10:31 | #14 |
Banned
|
Мое мнение тут мало что значит. Мне-то как раз все кажется простым. А вот другие получают шок и сразу сдаются. У меня тут летом был опыт, что меня привлекли в Сан-Франциско, поскольку целый ряд (!) программистов (!) Avanade (!) не мог поднять формат на новую версию derived model, поскольку это банально невозможно сделать в пользовательском интерфейсе, а только через редактирование XML-файла.
|
|
Теги |
generic electronic reporting, ger |
|
|