Первые впечатления от программирования в D365FO

[EVGL]

Ну что же, на этой неделе запрограммировал свою первую полноценную фичу: модификацию импорта не прошедших 'SEPA Direct debit' клиентских платежей на основе существующей конфигурации camt.054 в Electronic Reporting (все как обычно: вроде, все в стандарте есть, но на деле ни хрена не работает).
Сходу пришлось использовать chain on command, создавать entity, но требование все делать через extensions особых проблем не создало.

Убивает скорость набора кода (это притом, что работаю в метре от сервера с весьма внушительной производительностью; те рахитичные виртуальные машины, что коллеги из Хайдрабада используют, по ощущениям слабее), отладки, компиляции, сборки, а также параноидальные best practices. Да, build занимает около 12 секунд, но само web-приложение перезапускается вдвое дольше. Мука. По ощущениям, производительность сокращается вдвое.

[Pustik]

Евгений, если не претендовать на точные цифры, то примерно на сколько больше занимает по времени задача, в 7-ке, по отношению к другим версиям?

[belugin]

Цитата:

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

вроде, все в стандарте есть, но на деле ни хрена не работает

Можно ли узнать, что именно?

Цитата:

Убивает скорость набора кода (это притом, что работаю в метре от сервера с весьма внушительной производительностью; те рахитичные виртуальные машины, что коллеги из Хайдрабада используют, по ощущениям слабее),

Сам по себе набор по моему опыту особо не тормозит (хотя у меня специфический опыт - я в отдельном модуле не зависящем от application suite в основном).

Компиляция (в том числе фоновая) и intellisense (особенно если var используется) гораздо медленнее чем в Ax6.

Цитата:

отладки, компиляции, сборки, а также параноидальные best practices.

Best practice можно отключать - как конкретные так и проверку при сборке.
Отладку можно настраивать - какие символы загружать и какие нет и загружать по требованию.

Цитата:

Да, build занимает около 12 секунд, но само web-приложение перезапускается вдвое дольше. Мука. По ощущениям, производительность сокращается вдвое.

Я на новых виртуалках посматриваю в resmon - иногда получается, что defender начинает проверять то, что компилируется или саму аксапту - можно добавить в exclusions.

[EVGL]

Цитата:

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

Можно ли узнать, что именно?

Проблема в постановке задачи и отсутствия общего видения процесса. Не работает end-to-end: pain.008 уходит из журнала платежей клиента, camt.054 с транзакциями без покрытия возвращается обратно.

1) Создаем SEPA direct debit в формате pain.008. Пусть код счета за продажу FTI-0000006. В системе CustTrans.PaymtId никогда не заполняется кроме Бельгии и Финляндии, и, стало быть, никогда, ни в каких условиях кроме этих двух стран не печатается на счете и клиент никогда не узнает, который уникальный номер нужно указать в платеже, чтобы наша система смогла его распознать. Совершенно элементарная задача для любой европейской самописной системы, но в супер-пупер D365FO никто о таких мелочах, как уникальный код платежа, не заботится.

Хорошо, модифицируем систему и начнем заполнять это поле. Создаем файл direct debit, счет кодируется в Creditor Reference как RFxxFTI0000006. Разносим журнал, получается платеж и закрытый этим платежом счет.

2) Приходит обратно выписка в формате camt.054. Она особая и содержит только ошибки, т.е. дебеты которые по той или иной причине отфутболиваются обратно. Реализация импорта camt.054 в журнале клиентских платежей сделана в D365FO из расчета на то, что выписка camt.054 содержит переводы-кредиты, инициированные клиентом, хотя на практике полноценная выписка импортируется из MT940 и обработка ее происходит в модуле банка, advanced reconciliation. Напротив, в журнале платежей на практике импортируются ответы из банка (direct debit notification) только для "плохих" транзакций в виде "анти-платежа", его возврата. Система пытается сопоставить с оригинальным счетом, но счет закрыт. На самом деле, надо рассопоставить оригинальный direct debit платеж и сопоставить ее с новым "анти-платежом" из camt.054. Тем самым первоначальный счет становится опять открытым: оплата не прошла.

3) В заимпортированной проводке LedgerJournalTrans.PaymId получает значение RFxxFTI0000006, т.е. не расшифрованный текст с сигнатурой. Чистой воды баг.

[EVGL]

Цитата:

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

Евгений, если не претендовать на точные цифры, то примерно на сколько больше занимает по времени задача, в 7-ке, по отношению к другим версиям?

Мне кажется, что по сравнению с AX2012 времени на 50%-75% процентов больше, а по сравнению с AX2009 - как минимум на 100%, вдвое. Я еще не учитываю работу отдельного человека-администратора, которые только и занимается тем, что тиражирует все это как минимум в три среды. Ранее это мог реально сделать один человек-пароход, но эти времена ушли.

[ax_mct]

Цитата:

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

Мне кажется, что по сравнению с AX2012 времени на 50%-75% процентов больше, а по сравнению с AX2009 - как минимум на 100%, вдвое. Я еще не учитываю работу отдельного человека-администратора, которые только и занимается тем, что тиражирует все это как минимум в три среды. Ранее это мог реально сделать один человек-пароход, но эти времена ушли.

Подозреваю что вдвое это время чистого кодирования. Насколько безопасно партнеру/подрядчику использовать коэффициент два при оценке трудоемкости?

А если надо ловить некую багу в режима саппорта?
А если надо тестировать, а тестировать надо всегда и желательно в дебаггере?

Выделенная роль DevOps в тиме и настроенный по уму TFS это я понимаю что неизбежность.
Я кстати наблюдаю появление такой интересной специализации.

[Logger]

Цитата:

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

Мне кажется, что по сравнению с AX2012 времени на 50%-75% процентов больше, а по сравнению с AX2009 - как минимум на 100%, вдвое. Я еще не учитываю работу отдельного человека-администратора, которые только и занимается тем, что тиражирует все это как минимум в три среды. Ранее это мог реально сделать один человек-пароход, но эти времена ушли.

Ну а хоть в чем-нибудь выигрыш есть ?

[belugin]

Цитата:

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

Ну а хоть в чем-нибудь выигрыш есть ?

Теперь среда разработки - visual studio. Со всеми плюсами и минусами (тут замучаеншься перечислять - от нормальных табов до дебаггера с условными точками останова и трейспоинтами. Правда, например, перекрестные ссылки победнее стали и поиск по солюшенам не до конца удобно работает - издержки того, что формат хранения отличается от формата представления).

Еще X++ немножко доточили (например очень удобно определять переменные по месту первого использвания).

Удобно, что исходники хранятся в файлах на диске - раньше при работе с системой контроля версий была рассинхронизация, так же можно их обрабатывать при помощи powershell, например.

[Logger]

Спс. А то все один негатив был.
Надо бы сбалансировать впечатление

[pitersky]

Цитата:

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

Еще X++ немножко доточили (например очень удобно определять переменные по месту первого использвания).

когда-то именно это называли главным негативным свойством бейсика, которое мешает готовить хороших программистов
вот и думай теперь - то ли тогда врали, то ли мс под двоечников прогнулся...

[belugin]

Цитата:

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

когда-то именно это называли главным негативным свойством бейсика, которое мешает готовить хороших программистов

Кто, когда и почему называл? Это уже настолько общее место в современных языках программирования, что уж не помню, когда это критиковали.

[EVGL]

Цитата:

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

когда-то именно это называли главным негативным свойством бейсика, которое мешает готовить хороших программистов, вот и думай теперь - то ли тогда врали, то ли мс под двоечников прогнулся...

Нет, действительно удобно. В языке C это было с самого начала c 80-x годов, если не ошибаюсь.

[pitersky]

Цитата:

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

Кто, когда и почему называл? Это уже настолько общее место в современных языках программирования, что уж не помню, когда это критиковали.

ну вот когда я изучал в школе Паскаль, то во всех учебниках одним из главных его декларируемых преимуществ над Бейсиком была именно описательная часть. Мол, в правильных языках программирования все переменные сначала описываются в заголовке, а уже потом где-то в теле применяются.
Не так уж и давно это было

[EVGL]

Давно. 30 лет назад. )

[belugin]

Сейчас вроде пришли к тому, что явно обзявлять надо, но необязательно в каком-то отдельном месте. То есть в js, наприммер можно вот так:

x = 1

но рекомендуют вот так:

var  x = 1;

[pitersky]

Прям бейсик как он есть))))))

[dech]

Цитата:

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

ну вот когда я изучал в школе Паскаль, то во всех учебниках одним из главных его декларируемых преимуществ над Бейсиком была именно описательная часть. Мол, в правильных языках программирования все переменные сначала описываются в заголовке, а уже потом где-то в теле применяются.
Не так уж и давно это было

Это был как раз раздел VAR. Суммируя объем переменных в разделе можно было определить размер области стека, в которой и размещались локальные переменные. Там же вроде как и параметры были. В Х++ сделали такой раздел "до точки с запятой". Ну а теперь вроде бы можно объявлять переменные в любой локальной области, будь то цикл или if. Теперь все как в Java.

[belugin]

Цитата:

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

Прям бейсик как он есть))))))

В джаваскрипте много всяких несуразностей (в качестве примера можно зайти на сайт http://www.jsfuck.com/ который превращает строчку на js в строчку только из скобочек, которая, тем не менее делает то же самое).

НО X++ скорее наследует концепции из C#:

• строгая статическая типизация
• обязательное декларирование переменных

Более того, начиная с Ax2012 его сделали строже, в том, что касается наследования и привидений типов, в 7 он примерно на уровне C# (бесит, что есть неявное приведение типов при присваивании и передаче параметров и динамические вызовы, но это совместимость)

[ax_mct]

Цитата:

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

В джаваскрипте много всяких несуразностей
...
в 7 он примерно на уровне C# (бесит, что есть неявное приведение типов
...

То есть к примеру приведение int к boolean, 0 к false?

Я могу простить все недостатки среде программирования и языку только за то что можно работать локально на макбуке 7-8 летней давности. C понтом, в старбаксе

Вот что лично меня бесит это все увеличивающееся количество требуемого железа для программирования. Есть чувство что это неестественно. Так не должно быть.

Цитата:

Убивает скорость набора кода (это притом, что работаю в метре от сервера с весьма внушительной производительностью; те рахитичные виртуальные машины, что коллеги из Хайдрабада используют, по ощущениям слабее), отладки, компиляции, сборки, а также параноидальные best practices. Да, build занимает около 12 секунд, но само web-приложение перезапускается вдвое дольше. Мука.

[belugin]

Цитата:

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

То есть к примеру приведение int к boolean, 0 к false

Это-то ладно, а вот callInventTrans(custTrans) считает что надо скастить касттранс к инвенттранс, а не ругнуться + нету каста на лету:

((CustTrans)common).accountNum