Electronic Reporting (ER), model mapping, структура заголовок/строки, импорт файла

[rDenis2]

Добрый день,

Ситуация:
Попытка через ER (Bank statement model, bank statement mapping to destination, camt.053 format) импотировать стандартный банковский файл в новые таблицы (header/lines).
Различие со стандартными таблицами банковских выписок в том что в новой таблице (header) указан не период (даты с - по) а одна дата.
И загвоздка в том что надо statement (header) узлы из XML надо разбивать по уникальным датам транзакций (lines).

вопросы следующие:
1. Как (можно ли) сделать следующее - добыть уникальные даты из линий в каждом statement, и потом запустить каждый statement в цикле из дат и создать столько headerov сколько уникальных дат и соотвественно линий под header только с этими датами.

Например:
-Header (01.12.2022 - 10.12.2022)
--Line1: 02.12.2022
--Line2: 02.12.2022
--Line3: 03.12.2022
--Line4: 09.12.2022
--Line5: 09.12.2022

При импорте в стандартные таблицы так и будет 1 header/5 lines.

Желаемый результат:
-Header1: 02.12.2022
--Line1: 02.12.2022
--Line2: 02.12.2022

-Header2: 03.12.2022
--Line3: 03.12.202

-Header3: 09.12.2022
--Line4: 09.12.2022
--Line5: 09.12.2022

2. Вопрос. Можно ли в ER при импорте, как Destinations указать две таблицыю Где в первую импортируются данные из модели а во вторую фильтрованные данные из первой.

Например:
model.RecordList > Table1 binding
$Filter(Table1,....): RecordList > Table 2 binding
тоесть при одном иморте создать записи в одной таблице и сразу же на основе их записи в другой, как указать последовательность действий (если возможно)?

[EVGL]

1. Это называется group by: https://learn.microsoft.com/en-us/dy...y-data-sources
При этом
Header := $YourName_GroupByLinesByDate
Header.Date := $YourName_GroupByLinesByDate.grouped.YourDate
Line := $YourName_GroupByLinesByDate.lines

2. нет. Destinations не могут зависеть друг от друга, но только от источника (источников данных). А вот последние могут зависеть друг от друга.

[rDenis2]

Спасибо за быстрый ответ, буду пробовать

[rDenis2]

Цитата:

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

2. нет. Destinations не могут зависеть друг от друга, но только от источника (источников данных). А вот последние могут зависеть друг от друга.

По поводу второго вопроса.

Я создаю два Destination: Table1 и Table 2
и
Два Datasource: 1. оригинальная модель/list. model.RecorList; и
2. Table1 records и из него делаю Calculated field с фильтром по Table1 records чтобы найти только записи созданные для первого Destination.

Тоесть первый биндинг:
model.Recordlist > Table1:RecordList, при импорте записи создаются в Table1

Table records и calculated field:
Table1: Table 'Table1' records - datasource
$FilteredTable1records = Filter(Table1 datasource, ....) находятся записи созданные в первом биндинге

Второй биндинг:
$FilteredTable1records> Table2:Records list, записи создаются в Table 2 на основе Table1 записей.

Destination Table1 и Table2 связаны только через datasource. Возможно ли это?

[MorpheusX]

Цитата:

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

Различие со стандартными таблицами банковских выписок в том что в новой таблице (header) указан не период (даты с - по) а одна дата.
И загвоздка в том что надо statement (header) узлы из XML надо разбивать по уникальным датам транзакций (lines).

вопросы следующие:
1. Как (можно ли) сделать следующее - добыть уникальные даты из линий в каждом statement, и потом запустить каждый statement в цикле из дат и создать столько headerov сколько уникальных дат и соотвественно линий под header только с этими датами.

Я бы не создавал кастомные таблицы, а импортировал в стандартные с одинаковым значением полей "С даты" и "По дату".

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

[EVGL]

Цитата:

записи создаются в Table 2 на основе Table1 записей

Это невозможно.

[rDenis2]

Цитата:

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

Я бы не создавал кастомные таблицы, а импортировал в стандартные с одинаковым значением полей "С даты" и "По дату".

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

Таблицы уже используются для другого банковского решения, поэтому импортировать надо в них.

[rDenis2]

Цитата:

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

1. Это называется group by: https://learn.microsoft.com/en-us/dy...y-data-sources
При этом
Header := $YourName_GroupByLinesByDate
Header.Date := $YourName_GroupByLinesByDate.grouped.YourDate
Line := $YourName_GroupByLinesByDate.lines
(источников данных). А вот последние могут зависеть друг от друга.

Получилось сгрупировать если в XML 1 header если больше одного берется только первый.

XML:
Header1 (id1)
--line1: date1
--line2: date2
Header2 (id2)
--line1: date3
Header3 (id3)
--line1: date1

mapping:
Datasource структура:

model
-$GroupedByDate=GroupBy(model.header.lines; model.header.lines.date, model.header.lines.headerId) - сгруппировал линии по дате/header id
--$SelectedStatement=where(model.header, model.header.id=$GroupedByDate.grouped.headerId) - это я бинжу к таблице header (destination)
--grouped
---date
---headerId
-header
--lines
---date
---headerId

В дебуггере в узле header показывает 3 записи (header1, header2, header3). А в узле $GroupedByDate - 2 записи из header 1(id1, date1; id1, date2). остальные header игнорируются

[EVGL]

Вообще-то переменной where(model.header, model.header.id=$GroupedByDate.grouped.headerId) быть не должно. Если уже есть присвоение чего-то к $GroupedByDate (чего я в вашем представлении не вижу, и меня это настораживает: группировка должна ведь какому-то итератору, какой-то последовательности записей на выходе соответствовать?), то из текущего $GroupedByDate[i] всегда можно добраться до header (типа $GroupedByDate.lines.header).

Если же есть WHERE, то ему, наверное, придется скармливать ALLITEMS($GroupedByDate), поскольку как объяснял один ныне уволенный коллега из Майкрософт, внутри Electronic Reporting идет "ленивый поиск": если источник данных ничему не присвоен, то этот источник данных и не читается. Стало быть, если что-то итерируемое никакой последовательности не присвоен, то он и не итерируется. Аналогия: курсор FETCH в T-SQL.

Противодествует такому поведению функция ALLITEMS, которая формирует список, состоящий заведомо из всех возможных записей. Аналогия: копия таблицы в памяти, где все записи извлечены и представлены по значению.

[MorpheusX]

Цитата:

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

Таблицы уже используются для другого банковского решения, поэтому импортировать надо в них.

Я бы реализовал копирование импортируемых строк из стандартных таблиц в кастомные в методах insert() стандартных таблицы. Такое решение проще чем глубокая модификация ER сущностей и последующее их тестирование и поддержка на протяжении всего их жизненного цикла.