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

[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. А их таки немало.