28.02.2022, 16:51 | #1 |
Участник
|
Настройка одного из форматов ER Payment model D365FO
Импортировал из репозитория ER модель Payment model и формат DTAZV Foreign payment (DE). При этом автоматически были импортированы несколько мэппингов (см. изображение ниже). Как понять, какой мэппинг используется форматом DTAZV Foreign payment (DE)? Или все импортированые мэппинги используются одновременно?
К сожалению не смог найти подчеркнутые красной линией артефакты (см. изображение ниже), отображаемые в дизайнере формата, ни в модели Payment model ни в мэппингах. Откуда они берутся? |
|
28.02.2022, 16:58 | #2 |
Banned
|
|
|
28.02.2022, 17:16 | #3 |
Участник
|
Спасибо за ответ!
Где самостоятельно можно найти в модуле ER связь формата и мэппига? Что в дизайне мэппинга (см. изображение ниже) означает $notSentTransactions? Где определен этот артефакт? |
|
28.02.2022, 17:39 | #4 |
Banned
|
Связи как таковой нет. Маппинг формат пытается найти сам. Есть связь формат и модели, а для модели может быть в теории даже несколько маппингов. При такой многозначности в дереве конфигураций надо установить, какой из них Default.
$notSentTransactions - это т.н. Calculated field. В данном случае он имеет тип списка записей, а именно строк журнала, где LJT.PaymentStatus < Sent, т.е. строк, которые еще не вошли в другой файл. Последний раз редактировалось EVGL; 28.02.2022 в 17:42. |
|
28.02.2022, 18:13 | #5 |
Участник
|
Цитата:
К сожалению не смог найти определение $notSentTransactions ни в Payment model ни в Payment model mapping 1611. |
|
28.02.2022, 18:20 | #6 |
Участник
|
|
|
01.03.2022, 12:17 | #7 |
Участник
|
В определении переменной $notSentTransaction виден список полей. Почему этот список не отображается в RecordList(е) после присвоения переменной $notSentTransaction RecordList(у).
|
|
01.03.2022, 12:59 | #8 |
Banned
|
Потому, что задача mapping - связать (Bind) физические поля слева с логическими полями модели справа. Начните открывать узлы справа, чтобы увидеть, как заполняются поля. Имейте в виду, что узлы типа Debtor не обязательно должны быть связаны. Стоит в модели заполнить поле, как и сама родительская запись появляется в результате (результат - заполненная модель - похож на XML по своей структуре, и может быть выведен на экран как оный для тестирования, для этого на предыдущем экране есть кнопка Run).
Присвоение на уровне Payment - это чтобы сказать системе, что будет итерироваться, сколько записей будет, а не каких. Последний раз редактировалось EVGL; 01.03.2022 в 13:02. |
|
01.03.2022, 14:08 | #9 |
Участник
|
Цитата:
Сообщение от EVGL
Потому, что задача mapping - связать (Bind) физические поля слева с логическими полями модели справа. Начните открывать узлы справа, чтобы увидеть, как заполняются поля. Имейте в виду, что узлы типа Debtor не обязательно должны быть связаны. Стоит в модели заполнить поле, как и сама родительская запись появляется в результате (результат - заполненная модель - похож на XML по своей структуре, и может быть выведен на экран как оный для тестирования, для этого на предыдущем экране есть кнопка Run).
Присвоение на уровне Payment - это чтобы сказать системе, что будет итерироваться, сколько записей будет, а не каких. |
|
01.03.2022, 16:10 | #10 |
Участник
|
Цитата:
Последний раз редактировалось MorpheusX; 01.03.2022 в 16:14. |
|
01.03.2022, 17:05 | #11 |
Banned
|
Camt.054 - это входящий формат банковской выписки. Кстати, один и тот же "строительный блок" может попадаться в нескольких местах одной и той же модели. Я постарался это здесь описать:
https://erconsult.eu/blog/electronic...-5-references/ |
|
01.03.2022, 17:32 | #12 |
Участник
|
Что делать? |
|
01.03.2022, 17:36 | #13 |
Banned
|
В случаях моделей может быть необходимо перевести версию из Draft в Complete. В любом случае, я бы так не делал. Если чего-то не хватает, то гораздо проще найти неиспользуемое поле в модели, для которого нет binding, и сделать только свою версию mapping, а потом сказать, что она Default.
|
|
01.03.2022, 18:36 | #14 |
Участник
|
Цитата:
Сообщение от EVGL
В случаях моделей может быть необходимо перевести версию из Draft в Complete. В любом случае, я бы так не делал. Если чего-то не хватает, то гораздо проще найти неиспользуемое поле в модели, для которого нет binding, и сделать только свою версию mapping, а потом сказать, что она Default.
|
|
01.03.2022, 18:41 | #15 |
Banned
|
Потому, что в модели может быть много "входов", начальных узлов. Каждый формат и каждый маппинг ссылается на нужный из многих возможных. Вы явно ссылаетесь на "вход" для импорта (!) банковской выписки. Все неправильно. Что вам нужно на самом деле?
|
|
01.03.2022, 18:55 | #16 |
Участник
|
Необходимо в формат DTAZV Foreign payment (DE) добавить поле из таблицы LedgerJournalTrans.
|
|
01.03.2022, 19:01 | #17 |
Участник
|
А необходимые узлы из модели в мэппинге определяются вручную про создании мэппинга? Как найти соответствие узла из мэппинга излу из модели?
|
|
01.03.2022, 19:04 | #18 |
Banned
|
1 Добавить маппинг-дитя существующего 1611
2 Открыть CT (Credit transfer!) Найти в нем неиспользуемое поле из модели под узлом Payment или ниже 3 Сопоставить с нужным полем. 4 Complete mapping 5 Set default 6 Создать формат-дитя от DTAZV 7 Сопоставить нужную ветку слева этому ранее неиспользуемому полю справа 8 Можно начать тестировать уже в режиме Draft: https://erconsult.eu/blog/electronic...m-the-kitchen/ 9 Выбрать или просто скопировать имя своего формата, вставить его в метод платежа 10 Тестировать |
|
|
За это сообщение автора поблагодарили: MorpheusX (1). |
01.03.2022, 19:31 | #19 |
Участник
|
|
|
01.03.2022, 19:38 | #20 |
Banned
|
Да, а теперь в своем производном маппинге надо поискать поле, которое еще не "черное", т.е. в модели есть, а данными не заполнятся. И переориентировать его под свои цели.
|
|
|
|