Показать сообщение отдельно
Старый 12.05.2018, 22:10   #4  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от 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; 12.05.2018 в 22:20.
За это сообщение автора поблагодарили: belugin (10), trud (5), NetBus (3).