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

[belugin]

Цитата:

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

Вообще говоря, такое предположение у меня было. Но тогда непонятно, почему в конструкторе форматов доступны кнопки Добавить корень / Добавить - Добавить источник данных и можно выбрать любой объект - таблицу, класс, записи таблицы и т.п.
Если в конструкторе форматов можно ТОЛЬКО сопоставлять поля/теги шаблона с элементами модели, то почему все эти кнопки/функции доступны на форме?

Технически их можно сделать, это должно работать так же как как и в меппинге моделей. Это не рекомендуется. Насколько я помню, если не хочется их видеть, можно убрать у соответствующего пользователя роль разработчика ER оставив роль функционального консультанта или выключить Show Details - будет упрощенный режим.

Цитата:

И такой вопрос: в природе существует какая-то документация кроме
https://docs.microsoft.com/ru-ru/dyn...onic-reporting ?
Тут более-менее информативны только разделы связанные с администрированием, а по созданию моделей и форматов только "нажмите кнопку - введите значение". Почему именно эту кнопку нажимать? Почему именно это значение выбирать? Что будет если выбрать другое значение?
И это позиционируется как инструмент для не-программиста?

Я не знаю других источников. Там есть разделы как обще-информативного характера и 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).

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

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

[Libovs]

Цитата:

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

Технически их можно сделать, это должно работать так же как как и в меппинге моделей. Это не рекомендуется. Насколько я помню, если не хочется их видеть, можно убрать у соответствующего пользователя роль разработчика ER оставив роль функционального консультанта или выключить Show Details - будет упрощенный режим.

Вопрос не в "не хочется их видеть". Я бы сформулировал так: не хочется трогать базовую модель. На одной модели реализуется десятки-сотни конкретных документов/отчетов. И если для построения конкретного отчета в модели не хватает каких-то данных, то при настройке формата конкретно этого документа добавить недостающий источник данных (таблицу), "увязать" ее с корневым элементом модели и использовать при выводе в отчет.
Это в принципе возможно? Есть смысл "методом тыка" пытаться в этом разобраться или это априори бесперспективно?

[belugin]

Цитата:

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

Я бы сформулировал так: не хочется трогать базовую модель.

Рекомендуемый способ для этого использовать свою модель и меппинг (см derive) yна основе существующей.

Нерекомендуемый способ: Технически возможно использовать источники данных на меппинге формата, только там нету источников данных с меппингов модели а только результат - сама модель.

Если вы можете использовать данные модели, то можно отбирать данные из источников с помощью функции FILTER: FILTER(MyTable, MyTable.AssetBookID = model.AssetBookID )

[Libovs]

Цитата:

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

Рекомендуемый способ для этого использовать свою модель и меппинг (см derive) yна основе существующей.

Нерекомендуемый способ: Технически возможно использовать источники данных на меппинге формата, только там нету источников данных с меппингов модели а только результат - сама модель.

Если вы можете использовать данные модели, то можно отбирать данные из источников с помощью функции FILTER: FILTER(MyTable, MyTable.AssetBookID = model.AssetBookID )

А что в данном контексте имеется в виду под MyTable? Системное имя таблицы?
Попробовал вычисляемое поле с такой формулой:
FILTER (LedgerJournalTrans_Asset, LedgerJournalTrans_Asset.AssetID = model.FixedAssets.General.Identification.Number)
В ответ - "Неверная ссылка "LedgerJournalTrans_Asset". Т.е. фактическое имя таблицы не может использоваться в формулах, только внутренние метки (алиасы)?

[belugin]

Цитата:

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

А что в данном контексте имеется в виду под MyTable? Системное имя таблицы?

Имя источника данных типа table records. Непосредственно в языке формул нельзя обращаться к таблицам, только создавая источники данных. Имя источника данных можно сделать любым, в том числе и совпадающим с именем таблицы.

[Libovs]

Цитата:

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

Имя источника данных типа table records. По непосредственно в языке формул нельзя обращаться к таблицам, только создавая источники данных. Имя источника данных можно сделать любым, в том числе и совпадающим с именем таблицы.

Т.е. попробовать сначала добавить элемент типа table records, а потом уже добавить вычисляемое поле с такой формулой, используя заданное имя (метку) этого элемента? Сейчас попробую...

[Libovs]

Цитата:

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

Имя источника данных типа table records. Непосредственно в языке формул нельзя обращаться к таблицам, только создавая источники данных. Имя источника данных можно сделать любым, в том числе и совпадающим с именем таблицы.

Вот смотрю я на модель ОС от официального поставщика. В источниках данных определены три таблицы – AssetTable, AssetTaxDepr_LV типа записи таблицы и CompanyInfo типа таблица. Таблица AssetBook как источник данных не описана, соответственно ER-имени (внутреннего алиаса) у этой таблицы нет.

Теперь смотрю на маппинг модели. В нем 3 корневых элемента, где Fixed asset сопоставлен с источником данных AssetTable.

В этот корневой элемент добавлено поле $Books вычисляемое по формуле

$Books:Вычисляемое поле =
IF(ISEMPTY(AssetTable.'<Relations'.'AssetBook.AssetTable_AssertId'), EMPTYLIST(AssetTable.'<Relations'.'AssetBook.AssetTable_AssertId'), AssetTable.'<Relations'.'AssetBook.AssetTable_AssertId')
В этой формуле используется имя AssetBook, которое не является ER-именем источника данных, а системным именем таблицы. Это предположение я делаю исходя из того, что (см. выше) источник данных с таким именем не описывался и в выражении AssetTable используется без кавычек (ER-имя), а AssetBook взято в кавычки.
И эта модель с такой формулой работает, на ней построено десятка два форматов.
Для «чистоты эксперимента» выгрузил модель с маппингом в xml-файл и поиском проверил, что строка ‘AssetBook’ нигде, кроме этого выражения не встречается.

И я возвращаюсь опять к вопросу: может ли в формуле использоваться системное имя таблицы? Почему возникает ошибка валидации при сохранении абсолютно идентичной формулы для таблицы LedgerJournalTrans_Asset
$LedgerJournalTrans_Asset:Вычисляемое поле = IF(ISEMPTY(AssetTable.'<Relations'.'LedgerJournalTrans_Asset.AssetTable_AssertId'), EMPTYLIST(AssetTable.'<Relations'.'LedgerJournalTrans_Asset.AssetTable_AssertId'), AssetTable.'<Relations'.'LedgerJournalTrans_Asset.AssetTable_AssertId')

Предположение о том, что правила написания формул в модели и формате разные, мне кажется невероятным. Более вероятным может быть, что методы валидации для форм конструктора модели и формата реализованы разным кодом (в разных классах), но тогда в одном из них ошибка?

Или я все-таки чего-то не понимаю или неверно трактую? Что неправильно в моих рассуждениях и/или выводах?

[EVGL]

Цитата:

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

Или я все-таки чего-то не понимаю или неверно трактую? Что неправильно в моих рассуждениях и/или выводах?

Многое
Одинарные кавычки появляются тогда, когда есть специальные символы или точки. К примеру, "AssetBook.AssetTable_AssertId" - это не таблица, а relation.
Действительно, в явном виде надо объявлять только "корневые" таблицы, если с них начинается поиск. Если же до другой таблицы можно добраться через 1:N или N:1 от корневой, то их эксклюзивно объявлять не надо.

[belugin]

Цитата:

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

Вот смотрю я на модель ОС от официального поставщика. В источниках данных определены три таблицы – AssetTable, AssetTaxDepr_LV типа записи таблицы и CompanyInfo типа таблица. Таблица AssetBook как источник данных не описана, соответственно ER-имени (внутреннего алиаса) у этой таблицы нет.

Это не все записи таблицы, а записи отобранные по relation.

Тут нет идентификатора AssetBook - есть идентификатор 'AssetBook.AssetTable_AssertId' (одинарные кавычки означают, что дальше до следующей кавычки продолжается один и тот же идентификатор)

ER оперирует виртуальными записями.

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

Означает: из записи AssetTable взять поле <Relations потом оттуда взять поле AssetBook.AssetTable_AssertId:

- Поле <relations это виртуальная запись со всеми входящими relations
- поле AssetBook.AssetTable_AssertId это список записей выбранных по конкретному relation из текущей записи AssetTable (а не вся таблица AssetBook).

Цитата:

И я возвращаюсь опять к вопросу: может ли в формуле использоваться системное имя таблицы?

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

Если удалить все источники данных, то данная формула перестанет работать.

Цитата:

Почему возникает ошибка валидации при сохранении абсолютно идентичной формулы для таблицы LedgerJournalTrans_Asset
$LedgerJournalTrans_Asset:Вычисляемое поле = IF(ISEMPTY(AssetTable.'<Relations'.'LedgerJournalTrans_Asset.AssetTable_AssertId'), EMPTYLIST(AssetTable.'<Relations'.'LedgerJournalTrans_Asset.AssetTable_AssertId'), AssetTable.'<Relations'.'LedgerJournalTrans_Asset.AssetTable_AssertId')

Вероятно, потому, что в AssetTable нет таких полей. Или сам источник данных AssetTable не добавлен - попробуйте не копировать формулу а выбрать поле из дерева источников данных.

Цитата:

Предположение о том, что правила написания формул в модели и формате разные, мне кажется невероятным. Более вероятным может быть, что методы валидации для форм конструктора модели и формата реализованы разным кодом (в разных классах), но тогда в одном из них ошибка?

Ссылки на поля описываются путями через точку (идентификатор.ижентификатор2.идентификатор3 и так далее).

Если что-то взято в одинарные кавычки, то это один идентификатор.
идентификатор.ижентификатор2.идентификатор3 - это цепочка из трех идентификаторов
'идентификатор.ижентификатор2.идентификатор3' - это один идентификатор в который входит символ "." (без кавычек только буквы и цифры начиная с буквы).

Какие именно поля - зависит от вида источника данных. Для аксаптовских таблиц есть два вида источника данных Table Records - список всех записей и table - статические методы.

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

Для каждого отношения (relation) генерируется имя вида 'Таблица.{название поля или отношения>}', значением которой является список записей.

Все доступные поля можно получить раскрывая дерево источников данных. Никакие другие поля недоступны - надо либо добавлять новые источники данных либо менять приложение (например добавить extension метод на таблицу и тогда появится новое геровское поле для этого метода).

[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) только быстрее).