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

[Libovs]

Ну и уже от безисходности решил посмотреть, работает ли "штатный" формат на тестовой компании USMF.

Похоже, что результат тот же - не отрабатывает маппинг, просто в этом формате первым вычисляется переменная с именем файла

[Libovs]

Резюме - два ключевых вопроса знатокам:
1. Почему в лукап настройки управления печатью расходной накладной "попадают" только форматы, производные от "базового" формата? Что кроме Определения (во всех случаях это SalesInvoce) используется для фильтрации?
2. Почему не выполняется маппинг модели?

[axm2017]

Цитата:

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

Резюме - два ключевых вопроса знатокам:
1. Почему в лукап настройки управления печатью расходной накладной "попадают" только форматы, производные от "базового" формата? Что кроме Определения (во всех случаях это SalesInvoce) используется для фильтрации?
2. Почему не выполняется маппинг модели?

1 посмотрите в форматах свойства. Они ниже окна версий.
Там разгадка в виде пары-тройки типов про документы инвойс и прочую хрень.
2 базовые корректно открываются?

[Libovs]

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

[Libovs]

По второму - не отрабатывает ни один формат. На первом же вычисляемом значении вылетает.

[axm2017]

Хз где информация.
Нам повезло общаться по старым связям с коллегами.
Принцип что это замена ssrs фреймворка. Нюансов немного и касаются в основном параметров и знания
SSRS фреймворка в общих чертах.

По второму попробуйте последние версии. Там номера вроде выше 174 Просто интересно.

[Libovs]

Самому "интересно". Все модели, с которыми я до сих пор разбирался, модель и маппинг модели содержали в одной конфигурации. А в этой - в разных.
Хотя конфигурация с маппингом одна-единственная и чекбокс "Значение по умолчанию" включен и по номерам версий увязаны - но по "косвенным" признакам модель не маппится с источниками данных. Причем не отдельные поля, а вообще ничего.

[axm2017]

Цитата:

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

Самому "интересно". Все модели, с которыми я до сих пор разбирался, модель и маппинг модели содержали в одной конфигурации. А в этой - в разных.
Хотя конфигурация с маппингом одна-единственная и чекбокс "Значение по умолчанию" включен и по номерам версий увязаны - но по "косвенным" признакам модель не маппится с источниками данных. Причем не отдельные поля, а вообще ничего.

Ну это несложно проверить.
Зайдите в формат и запустите там проверку.

Была как минимум одна сбойная версия модели. Но номер не помню. Может вам повезло.

[Libovs]

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

[axm2017]

На формате не только синтаксис: позволяет понять по warning что в mapping что то не так.

[Libovs]

Обновился до последней версии. На стандартном формате Sales invoice (Excel): Проверить - ни ошибок ни предупреждений; Выполнить - пустая форма

заполнено только поле текущей даты, которое берется не из модели.

[axm2017]

Прикольно.
А как вызываете отчёт?

[Libovs]

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

Или класс-провайдер ничего не выдает, соответственно не вычисляются внутренние переменные

Но как это проверить без дебаггера я не представляю.

[Libovs]

Настраиваю здесь

выполняю отсюда

[Libovs]

Там в лукапе доступен SalesInvoice_UA.Report - то наш ssrs-ный отчет портированный с АХ2012. Сам по себе он кривоват, но выполняется нормально, т.е. класс-провайдер ему выдает данные по текущей записи журнала.
По идее ER-ный маппинг должен получать "на вход" тоже, что и ssrs-ный отчет.

[axm2017]

Цитата:

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

Там в лукапе доступен SalesInvoice_UA.Report - то наш ssrs-ный отчет портированный с АХ2012. Сам по себе он кривоват, но выполняется нормально, т.е. класс-провайдер ему выдает данные по текущей записи журнала.
По идее ER-ный маппинг должен получать "на вход" тоже, что и ssrs-ный отчет.

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

[Libovs]

Пробовал и "Просмотр копии" и "Просмотр оригинала" и "Управление печатью" - результат один - исключение на первом же вычисляемом значении.
Я делал производную конфигурацию с моделью. Хочу попробовать в этой же конфигурации создать и маппинг, просто скопировав стандартный "внутрь". И под этой конфигурацией - формат. Тут уж "не увидеть" маппинг невозможно.
Путь конечно дурацкий, но больше идей нет.

[soad]

Приветствую!

Разбираюсь с электронной отчетностью на D365, никак не могу понять как можно реализовать один момент.
Сделал такую модель и ее сопоставление с источниками данных, сейчас она позволяет указать на входе номенклатуры и модель соберет данные о физических запасах в разрезе складов, ячеек и партий.



Далее пытаюсь для каждой агрегированной записи запасов определить физическую дату самой поздней складской проводки по номенклатуре.
Что уже попробовал:
1. Добавить к источнику данных «GroupInventSum» подчиненное вычисляемое поле, которое делает выборку из InventTrans по условию совпадения номенклатуры в InventTrans – это получается, проводки отбираются верно. Далее при помощи еще одного подчиненного вычисляемого поля пробую при помощи сортировки (ORDERBY, REVERSE) и отбора первой записи (FIRSTORNULL) отобрать наиболее позднюю проводку – не работает.

2. Добавить к источнику данных «GroupInventSum» подчиненное вычисляемой поле, которое делает выборку из InventTrans по условию совпадения номенклатуры в InventTrans – это получается, проводки отбираются верно. Далее при помощи еще одного подчиненного источника данных с типом «Группировать по» делаю группировку отобранных проводок по номенклатуре с типом «Агрегации» = «Максимум» по физ. дате проводок - тоже не получается.

Кто-то может подсказать, как верно определить физ. дату последней проводки в данном контексте?
P.S. Вопрос производительности решения пока не стоит, хотелось бы понять как в принципе подобную задачу можно решить в ER.

[belugin]

Цитата:

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

P.S. Вопрос производительности решения пока не стоит, хотелось бы понять как в принципе подобную задачу можно решить в ER.

По тексту сообщения непонятно, что значит "не получается". Я бы сделал так:
1. Добавил источник Table Records на invent trans в корень
2. Добавил вычислимое поле внутрь filteredinventsum
$inventTrans = FILTER(InventTrans, xxxx = @.yyyy)
3. Добавил внутрь FillteredInventSum группировку filteredinventsum.$inventTrans без группировки в вычислением максимальной даты.

[soad]

Цитата:

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

По тексту сообщения непонятно, что значит "не получается". Я бы сделал так:
1. Добавил источник Table Records на invent trans в корень
2. Добавил вычислимое поле внутрь filteredinventsum
$inventTrans = FILTER(InventTrans, xxxx = @.yyyy)
3. Добавил внутрь FillteredInventSum группировку filteredinventsum.$inventTrans без группировки в вычислением максимальной даты.

Спасибо за обратную связь!
Что именно не получается, смогу описать подробнее позднее.
Попробовал предложенный вариант, в группировке $GrInventTrans вычисляется всегда последняя проводка в целом по всем номенклатурам, а не по соответствующей Пробовал и без группировки по itemId и с ней, результат одинаковый.

Верно понял предложенную идею?

Скрины модели и источников данных (это другая тестовая модель, но смысл тот же, что в исходном сообщении):