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

[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, т.е. не расшифрованный текст с сигнатурой. Чистой воды баг.