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

[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 от корневой, то их эксклюзивно объявлять не надо.

[Libovs]

Цитата:

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

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

А есть ли какие-то различия в использовании в формулах одинарных или двойных кавычек?
И как быть если relation не у корневой на подчиненную, а наоборот? Т.е. корневая таблица «не знает» о существовании таблиц, которые на нее ссылаются?
В примере, с которым я разбираюсь, у корневой таблицы AssetTable нет relation на таблицы AssetBook и LedgerJournalTrans_Asset. Эти таблицы ссылаются на AssetTable.
У AssetBook relation AssetTable_AssertId
AssetBook.AssertId == AssetTable.AssertId
а у LedgerJournalTrans_Asset relation AssetTable_AssertId
LedgerJournalTrans_Asse.AssertId == AssetTable.AssertId

Правильно ли я понимаю, что о "направлении" связи говорит знак ">" или "<"? В первом случае - это relation корневой таблицы на подчиненную, а во втором - наоборот?

И такой пример из той же модели:
У таблицы AssetTable есть relation WorkerContactName_FK
AssetTable.WorkerContactName == HcmWorker.RecID
В модели есть поле с такой формулой
FIRSTORNULL(AssetTable.'>Relations'.WorkerContactName)
Раз ссылка на RecID, то это связь 1:1, WorkerContactName это имя поля, а не relation (там еще _FK и WorkerContactName вне кавычек) и данное выражение возвращает единичную запись из таблицы HcmWorker. Правильно?

Выражение (опуская IF и проверку на пустой список)
AssetTable.'<Relations'.'AssetBook.AssetTable_AssertId'
Связь 1:N, AssetTable_AssertId это relation таблицы AssetBook (а не AssetTable) и данное выражение возвращает список записей таблицы AssetBook, но не всех, а только связанных с текущей записью AssetTable. Правильно?

И, все равно не понимаю, чем выражение
AssetTable.'<Relations'.' LedgerJournalTrans_Asset.AssetTable_AssertId'
отличается от предыдущего.

Единственное, что приходит на ум, это то, что первое используется в маппинге модели и там можно добраться до любой связанной таблицы без ее эксклюзивного объявления, независимо от «направления» relation.

А в маппинге формата можно добраться только до элементов модели, но не до таблицы. Но если в формате ее добавить как источник данных, то можно записи из нее использовать – это я уже попробовал. Вот только связать ее с корневой таблицей модели так же не получается. Надо ссылаться на ER-метку и с отбором по relation что-то не получается. Пробую использовать FILTER, но пока никак не получается написать корректное выражение где с одной стороны поле добавленной таблицы (источника данных), а с другой – поле элемента модели данных.

[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

AssetTable.'<Relations'.'AssetBook.AssetTable_AssetId'.

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

Большое спасибо за такой подробный ответ. Кое-что вроде становится понятней, но буду еще по вашему тексту пробовать на живых примерах.

Но по выделенной фразе есть вопросы:
у таблицы AssetTable нет Relations на AssetBook; и, как мне кажется об этом "говорит" знак "<". Если в выражении используется Relations таблицы AssetTable то будет знак ">".

Я пока не разбираюсь в синтаксисе выражения, но понимаю физический смысл, т.к. смотрел эти таблицы в AOT-е.
У таблицы AssetBook есть поле AssetId и есть Relations с именем AssetTable_AssetId и выражением
AssetBook.AssertId == AssetTable.AssertId
а приведенное выше выражение возвращает все записи таблицы AssetBook, которые по Relations AssetBook.AssetTable_AssertId ссылаются на текущую запись AssetTable.

Как раз с синтаксисом направления ссылок мне пока непонятно. Т.е. физический смысл понимаю, а как написать корректное выражение - пока нет.

[belugin]

Цитата:

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

Как раз с синтаксисом направления ссылок мне пока непонятно. Т.е. физический смысл понимаю, а как написать корректное выражение - пока нет.

Если есть таблицы t1 и t2 и relation r1 определенный на t1 то

Ds1.>relations.r1 даст записи t2 которые соответствуют текущей записи из источника данных ds1 при условии что это table records по таблице t1

Ds2.<relations. 'T1.r1' это то же самое но с другого конца - записи t1 которые соответствуют текущей записи t2 от условии что ds2 это table records по таблице t2.

Если вы идете от какой-то таблицы то >relations это отношения определенные на ней, а <relation это отношения определенные на других таблицах на нее

Одинарные кавычки это идентификатор (имя поля, например) а двойные кавычки - это строковый литерал.

Например, если определить user input parameter с именем "hello, world" то 'hello, world' вернёт эго значение (то что пользователь ввел) а "hello, world"
саму строчку "hello, world"

[Libovs]

Цитата:

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

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

Правильно ли я понимаю, что при добавлении источника данных типа Записи таблицы для него создается виртуальная запись ER, в которой столько (виртуальных) полей, сколько:
полей в исходной таблице +
relations в исходной таблице +
методов в исходной таблице +
"дочерних" таблиц, у которых есть relations на исходную таблицу?

И значений этих полей содержат ссылки, вызов которых позволяет получить соответственно:
значение поля
список записей дочерней таблицы, связанных с текущей записью исходной
результат выполнения метода
список записей дочерней таблицы, связанных с текущей записью исходной

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

Как-то так, если не вдаваться в детали реализации?

[belugin]

Цитата:

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

Как-то так, если не вдаваться в детали реализации?

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

[Libovs]

Цитата:

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

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

Ну если не пытаться этим инструментом реализовывать сложные аналитические отчеты, а только печатные и/или xml-файлы документов и простенькие отчеты типа плоских таблиц, максимум с промежуточными итогами, то "ленивость" не должна стать существенной проблемой.
Я по-крайней мере, вижу применение именно для реализации локализованных форм при переходе с АХ2012, где они реализованы на SSRS, на DFO 365. А их таки немало.