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

[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

Рекомендуемый способ для этого использовать свою модель и меппинг (см 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

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

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

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

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

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

[Libovs]

Цитата:

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

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

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

[Libovs]

Вот и очередная непонятка: на форме создания источника данных типа записи таблицы есть галочка "Запросить запрос". Зачем она? На что влияет? Включать?
Без документации - ну ни как... Извините за нытье

[belugin]

Цитата:

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

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

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

[belugin]

Цитата:

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

Вот и очередная непонятка: на форме создания источника данных типа записи таблицы есть галочка "Запросить запрос". Зачем она? На что влияет? Включать?
Без документации - ну ни как... Извините за нытье

Эта штука просит вызывающего предоставить аксаптовский запрос. Стандартное поведение - вывод его в диалог запроса параметров запуска - там можно будет наложить какие-то источники данных, но его может и программно заполнить вызыващий код X++

[Libovs]

Цитата:

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

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

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

[axm2017]

Цитата:

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

Еще раз замечу, что эту формулу не я писал...

Если правильно помню чистых тестеров в MS нет....

[Libovs]

Цитата:

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

Эта штука просит вызывающего предоставить аксаптовский запрос. Стандартное поведение - вывод его в диалог запроса параметров запуска - там можно будет наложить какие-то источники данных, но его может и программно заполнить вызыващий код X++

Вот одна фраза - и по сути понятно. Дождаться бы документации хотя бы с таким объемом информации.
Я понимаю, сколько прошло времени с выпуска АХ2012 и сколько с D365. По АХ2012 на docs.microsoft.com все-таки расписана каждая форма, кнопка и поле на форме, пусть конспективно и не всегда понятно на что влияет, но хоть что-то...

[Libovs]

Цитата:

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

Если правильно помню чистых тестеров в MS нет....

Я даже не об этом...
Формула в частности и формат в целом - работает. Качество (производительность) - для меня пока вопрос не второй и даже не пятый.
Просто не вижу другого пути изучить функционал и промоделировать свои задачи кроме поиска в готовых моделях/форматах прямых аналогий для своих потребностей.

[belugin]

Цитата:

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

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

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

[Libovs]

Цитата:

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

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

Возможно, тот кто писал эту формулу не рискнул мирится с Предупреждением. При выполнении проверки при сохранении на все возвращаемые списки выдается сообщение типа:

В списке "model/FixedAssets/LedgerJournalLines" не выполняется проверка того, является ли он пустым, что может привести к ошибке во время выполнения. Добавьте соответствующую проверку.

А если это же выражение "завернуть" в любую функцию типа ALLITEMS, FIRSTORNULL, ISEMPTY ... то то валидация не вякает. Но это мое предположение.

[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]

Цитата:

Сообщение от 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, но пока никак не получается написать корректное выражение где с одной стороны поле добавленной таблицы (источника данных), а с другой – поле элемента модели данных.