Вебинар по функциональности Электронной отчетности (Electronic reporting) и Электронных сообщений (Electronic messages)

[Libovs]

Цитата:

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

Я не знаю других источников. Там есть разделы как обще-информативного характера и step-by-step.

Вот пример раздела первого типа, где содержится описание рекомендуемого подхода:

документация:

Although GER allows for direct mapping of format components to database artifacts (tables or data entities), we don't recommend this approach, because it's likely that multiple formats will be maintained in some business domain areas that use the same data sources. Whenever the structure of such database artifacts is changed, the format mapping to the database artifacts must also be changed, and the cost of these changes will be multiplied by the number of maintained formats. Therefore, we recommend that you work through the data model as the abstract description of the domain-specific data structure, and that you use the direct binding of format elements to database components only for simplification and for coverage for specific customizations (for example, to refer to custom tables when these references are required in a limited number of maintained formats).

Некоторые шаги во разделах второго типа содержат пояснения.

Мы работаем над реструктуризацией документации, но я не могу сказать, когда вы сможете увидеть результаты этого.

Я добросовестно прочитал все, что нам есть, честно. Но реальной пользы не вижу.
Пару простых вопросов:
- в каких случаях использовать "Добавить корень", а в каких "Добавить"?
- в чем отличие "Таблица" и "Записи таблицы" как источника данных?
- что такое "Поиск" среди источников данных
- нужно ли каждую таблицу добавлять как источник данных или только "корневую", а все связанные через relations определяются как "Вычисляемое поле"?
- где можно выполнять фильтрацию записей - только в модели или это можно сделать и в формате?

Вот пример вопросов, которые в первую очередь возникают у меня как не-программиста (хотя и с 30-летним опытом программирования, но в прошлом), на которые хотелось бы видеть ответы в документации - пусть одним-двумя абзацами, чисто концептуально.
А сейчас единственный доступный мне путь - изучать уже загруженные модели/форматы и пытаться понять, как оно работает.

[axm2017]

Цитата:

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

- в каких случаях использовать "Добавить корень", а в каких "Добавить"?

Это касательно чего? Важен контекст.

В модели.
Root это корневая структура с которой собственно и можно организовывать mapping.

Для остального добавить в корень или так с ходу кроме логического удобства как правило не несет сильной смысловой нагрузки (хотя могут быть ньюансы).

Цитата:

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

- в чем отличие "Таблица" и "Записи таблицы" как источника данных?

Если глянуть их в реальности то
В первом случае это лишь набор static методов таблицы


во втором реальный запрос записей со всеми вытекающими (обычно используется с наложением фильтров через calculated field их кстати принято именовать как понимаю с префиксом $ так как это сулит удачу)

Цитата:

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

- что такое "Поиск" среди источников данных

То же что и поиск в других местах. Реально при большом числе объектов и ужасном рабочем дизайне поиск выручает (хотя он тоже реализован кривовато)

Цитата:

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

- нужно ли каждую таблицу добавлять как источник данных или только "корневую", а все связанные через relations определяются как "Вычисляемое поле"?

Как вам удобно. Мне удобнее через вычисляемые поля так как логика выборки порой меняется по результатам тестов и менять ее везде утомительно а в одном месте проще.

Цитата:

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

- где можно выполнять фильтрацию записей - только в модели или это можно сделать и в формате?

Как удобнее имхо. Какие то custom вещи только для конкретного отчета по мне так удобнее может и на формате.

Цитата:

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

А сейчас единственный доступный мне путь - изучать уже загруженные модели/форматы и пытаться понять, как оно работает.

Вопрос документации актуален да. Но по моим прикидкам повторюсь это месяц работы стажера имхо и видимо малореально так как MS загружено. Все жду когда они среду сделают удобной или хотя бы анонсируют.

[Libovs]

Цитата:

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

Как вам удобно. Мне удобнее через вычисляемые поля так как логика выборки порой меняется по результатам тестов и менять ее везде утомительно а в одном месте проще.

Я так и рассуждал. Выше я описал конкретный пример, который пытаюсь реализовать.
В модели ОС корневой элемент AssetTable, а связанные записи таблицы AssetBook определены как вычисляемое поле
$Books:Вычисляемое поле = IF(ISEMPTY(AssetTable.'<Relations'.'AssetBook.AssetTable_AssertId'), EMPTYLIST(AssetTable.'<Relations'.'AssetBook.AssetTable_AssertId'), AssetTable.'<Relations'.'AssetBook.AssetTable_AssertId'): Список записей: DataContainerList (): DataContainerList ()

Хочу полностью аналогично добавить таблицу LedgerJournalTrans_Asset.AssertId. Добавляю
$LedgerJournalTrans_Asset:Вычисляемое поле = IF(ISEMPTY(AssetTable.'<Relations'.'LedgerJournalTrans_Asset.AssetTable_AssertId'), EMPTYLIST(AssetTable.'<Relations'.'LedgerJournalTrans_Asset.AssetTable_AssertId'), AssetTable.'<Relations'.'LedgerJournalTrans_Asset.AssetTable_AssertId')
- а не работает. Почему - не понимаю.

[axm2017]

Цитата:

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

..
- а не работает. Почему - не понимаю.

Для начала бы попробовал без всяких IF посмотреть, а потом аккуратно добавлять составляющие так, как в силу кривого интерфейса пропуск какой-нибудь скобочки легок и непринужден.

[belugin]

Цитата:

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

(ISEMPTY(AssetTable.'<Relations'.'AssetBook.AssetTable_AssertId'), EMPTYLIST(AssetTable.'<Relations'.'AssetBook.AssetTable_AssertId'), AssetTable.'<Relations'.'AssetBook.AssetTable_AssertId'): Список записей: DataContainerList (): DataContainerList ()

Эта формула эквивалентна просто исходному списку:

AssetTable.'<Relations'.'AssetBook.AssetTable_AssertId'

Возможно, вы хотите FIRSTORNULL(AssetTable.'<Relations'.'AssetBook.AssetTable_AssertId')

[Libovs]

Цитата:

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

Эта формула эквивалентна просто исходному списку:

AssetTable.'<Relations'.'AssetBook.AssetTable_AssertId'

Возможно, вы хотите FIRSTORNULL(AssetTable.'<Relations'.'AssetBook.AssetTable_AssertId')

Это не моя запись, строка из стандартной модели Fixed assets model

Я понимаю так, что к одной корневой записи AssetTable vможет быть несколько (или ни одной) записей в таблице AsssetBook.
В этой формуле реализуется проверка на наличие связанных записей и возвращается их список; но если записей нет - возвращается не null, а EMPTYLIST. Видимо, чтобы тип данных был всегда одинаковый.

[belugin]

Цитата:

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

EMPTYLIST. Видимо, чтобы тип данных был всегда одинаковый.

Он и так одинаковый - null в программистском понимании в ER отсутствует. FIRSTORNULL в случае пустоты списка возвращает пустую запись. Наверное правильнее было бы назвать FIRSTOREMPTY (аналогично (IF(ISEMPTY(x), EMPTYRECORD(x), x) только быстрее).

[Libovs]

Цитата:

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

Он и так одинаковый - null в программистском понимании в ER отсутствует. FIRSTORNULL в случае пустоты списка возвращает пустую запись. Наверное правильнее было бы назвать FIRSTOREMPTY (аналогично (IF(ISEMPTY(x), EMPTYRECORD(x), x) только быстрее).

Еще раз замечу, что эту формулу не я писал. А по сути - FIRSTORNULL тут не годится, т.к. реально для обработки нужна не первая, а все имеющиеся связанные записи. В данном контексте каждая операция с ОС может выполняться по нескольким моделям (книгам) учета: по бухучету одна проводка, по налоговому другая, по управленческому третья и т.п.