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

[Libovs]

Цитата:

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

Вероятно вы импортируете из дерева конфигураций а не из дизайнера формата:

Упс.. действительно так. Спасибо.
С одной строкой получилось. Попробую фрагмент реального файла.

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

Еще раз спасибо.

[belugin]

Цитата:

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

Попытки решить подобное изначально в рамках одного mapping (типа добавим поле IdFromChine и прочее) оказались крайне неудобными.

Чем?

[axm2017]

Цитата:

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

Чем?

По факту у нас есть ID для китайских и отдельно для обычных людей.

Какие есть варианты действий?

1. Добавить в модель поле китайский ID.
А потом индийский. А потом выслушать обвинение в расизме от консультанта почему китайский ID идет отдельно (типа ты их за людей не считаешь?).

2. Добавить заполнение ID на маппинге для китайцев свое, а для обычных свое. Ок вводим функцию определитель страны и в зависимости от нее заполняем ID. Но так как в реальности появляется куча наворотов + еще и индийцы то все становится тяжелым и не все помнят о существовании китайских коллег. Есть высокая вероятность что кто то сломает им все, правя для себя. В общем пришли к тому что надо разделять маппинги.

[belugin]

Цитата:

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

1. Добавить в модель поле китайский ID.
А потом индийский. А потом выслушать обвинение в расизме от консультанта почему китайский ID идет отдельно (типа ты их за людей не считаешь?).

Это реальный кейз уже были такие претензии? Почему именно китайский идентификатор не такой как у всех? Если это требование какого-то стандарта типа IBAN, то вполне можно назвать его ID_<название стандарта>. Например, в ISO20022 к банкам привязано множество пар (схема идентификации, значение), где схема идентификации - это как раз разновидность такого стандарта.

Стандарты можно не считать за людей

[axm2017]

Цитата:

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

Это реальный кейз уже были такие претензии?

Это адаптированный под тестовый пример вариант проблемы. Но проблема практическая.

Цитата:

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

Почему именно китайский идентификатор не такой как у всех?

Это риторический вопрос? Мог быть индийский, итальянский и далее по вкусу. Тараканы у всех свои. Это хорошо заметно если модифицировать ssrs отчёты.

[belugin]

Цитата:

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

Это адаптированный под тестовый пример вариант проблемы. Но проблема практическая.

Мне из адаптированного тестового примера непонятно, чем именно неудобно добавить дополнительное поле.

Цитата:

Это риторический вопрос?

Нет.

Цитата:

Мог быть индийский, итальянский и далее по вкусу. Тараканы у всех свои. Это хорошо заметно если модифицировать ssrs отчёты.

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

[axm2017]

Цитата:

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

Мне из адаптированного тестового примера непонятно, чем именно неудобно добавить дополнительное поле.

Оно будет региональным. По смыслу это идентификатор и альтернативное заполнение нужно только китайцам. Но в реальной ситуации где кроме китайцев есть куча других альтернативщиков можно идти только вариантами как см. выше. Расширение модели консультант считает перебором так как таких полей может быть много для каждой страны, а усложение маппинга уже я считаю перебором.

Цитата:

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

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

В конкретном случае в 1 варианте количество полей в модели увеличилось в 1.5 раза а во втором выросла сложность и снизилась надёжность.

В общем приняли решение чаще делать маппинги а не усложнять. Хотя как понял якобы по канону стремление к уменьшению меньше маппингов должно быть. Чем оно вызвано не ясно.

[Libovs]

Может кому-то уже знакома эта проблема - использую функцию преобразования даты в строку DATEFORMAT(model.InvoiceBase.Date, "dd.mm.yyyy") - на выходе получаю "18.00.2019", т.е. dd и yyyy отрабатывают, а mm - нет.
Что у меня неправильно?

[Ace of Database]

Попробуйте задать формат "dd.MM.yyyy" - укажите заглавные буквы MM

PS: Если заработает, то это будет мой первый в жизни ответ по DFO365, а еще лет через 7 наверное я в ней буду уже работать

[Libovs]

Цитата:

Сообщение от Ace of Database

Попробуйте задать формат "dd.MM.yyyy" - укажите заглавные буквы MM

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

[belugin]

Цитата:

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

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

Это стандартный формат даты/времени в .NET : mm означает минуты.MM месяцы.

https://docs.microsoft.com/ru-ru/dot...format-strings

[Ace of Database]

Цитата:

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

Это стандартный формат даты/времени в .NET : mm означает минуты.MM месяцы.

https://docs.microsoft.com/ru-ru/dot...format-strings

Я за 8 лет работы в АХ2009-АХ2012 так и не запомнил, когда надо от UTCDateTime отнимать смещение, а когда прибавлять. Поэтому каждый раз, когда сталкиваюсь с импортом-экспортом UTCDateTime, заново пишу джобы для тестирования. У меня уже набралась куча джобов по UTCDateTime. Бывает, что я запоминаю поведение UTCDateTime, но если сделать перерыв в 1 месяц, то опять все забываю.

А в DFO365 напридумали еще кучу граблей.

[Libovs]

Для модели Customer invoice model у которой источник Записи таблицы "CustInvoiceJour" настроил два формата - xls и xml.
Затем пошел в настройки Управление печатью для замены стандартного SSRS-отчета на ER. Но в настройках документа Накладная клиента созданных форматов не увидел. Методом "тыка" нашел их в настройках документа Накладная с произвольным текстом.
И вот вопрос: в системе есть
- форма CustFreeInvoice на таблице CustInvoiceTable; печатается документ Накладная с произвольным текстом (SSRS-отчет FreeTextInvoice.Report)
- форма CustInvoiceJournal на таблице CustInvoiceJournal; печатается документ Накладная клиента (SSRS-отчет SalesInvoice.Report)
Исходя из предположения, что если для модели источником данных является CustInvoiceJournal (а не CustInvoiceTable), то созданные для этой модели форматы будут применяться для документа Накладная клиента (а не Накладная с произвольным текстом), но предположение оказалось ошибочным.
Может ли кто-то подсказать, как определяется связь модели/формата с документом? Как определить для какого документа используется модель? Или обратная задача - как в репозитарии определить модель для конкретного документа, для которого нужно разработать локальную печатную форму?
На docs.microsoft.com не нашел даже никаких намеков об этом.

[Libovs]

И еще одно: кто-нибудь делал форматы для PDF? В каком ПО, кроме Adobe Acrobat, можно создавать PDF-шаблоны?

[Libovs]

Цитата:

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

Это стандартный формат даты/времени в .NET : mm означает минуты.MM месяцы.

Не всегда очевидно, где заканчивается код АХ и начинается .NET.

В АХ2012 при настройке отчетов ГФО / Электронный документ для форматирования даты применялись макросы, реализованные в методе класса самой АХ.

[belugin]

Цитата:

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

Не всегда очевидно, где заканчивается код АХ и начинается .NET.

Вот тут есть описание доступных функций.

Некоторые описания содержат ссылку на поддерживаемые форматы.

[axm2017]

Цитата:

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

Для модели Customer invoice model у которой источник Записи таблицы "CustInvoiceJour" настроил два формата - xls и xml.
Затем пошел в настройки Управление печатью для замены стандартного SSRS-отчета на ER. Но в настройках документа Накладная клиента созданных форматов не увидел. Методом "тыка" нашел их в настройках документа Накладная с произвольным текстом.

А в версии какой модели вы работаете?

Цитата:

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

Исходя из предположения, что если для модели источником данных является CustInvoiceJournal (а не CustInvoiceTable),

Модель это "пользовательское" представление. То есть о таких тонкостях как CustInvoiceJournal или CustInvoiceTable он не особо в курсе и это правильно.

Цитата:

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

Может ли кто-то подсказать, как определяется связь модели/формата с документом?
.

Для начала надо определится что вы делаете. Есть серия уже подготовленных отчетов. Вы можете модифицировать их. Их вызов уже определен какой то логикой и возможно кодом написанным за вас.

Либо вы с нуля пишите отчет. Но это другая история.

[belugin]

Цитата:

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

Может ли кто-то подсказать, как определяется связь модели/формата с документом? Как определить для какого документа используется модель? Или обратная задача - как в репозитарии определить модель для конкретного документа, для которого нужно разработать локальную печатную форму?
На docs.microsoft.com не нашел даже никаких намеков об этом.

К сожалению, сейчас нет единого места где документированы все точки интеграции ER в приложение. Для каких-то мест есть документация, но там нет описания моделей.

Программист может посмотреть как именно интегрируется, например выпадающий список форматов в настройки (см использование методов ERObjectsFactory::createFormatMappingTableLookup*) обычно там записано имя модели.

[Libovs]

Цитата:

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

А в версии какой модели вы работаете?

Информация о версии
2019 release wave 2
Установленная версия продукта: Finance and Operations (10.0.6)
Установленная версия платформы: Update30 (7.0.5407.35455)

Что касается целевой задачи - реализовать как можно большее количество печатных форм документов в соответствии с регламентированной (или традиционно принятой) формой, на государственном языке. Т.е. формы реализованные для АХ2012 в рамках локализации как SSRS-отчеты, в 365FO попытаться настроить в ER. И желательно основываясь на стандартных моделях Майкрософт. Хотя я считаю, что это утопия, т.к. в этих моделях априори отсутствует ряд традиционно используемых реквизитов, таких как договор, куча кодов налоговых регистраций - ЕГРПОУ, ИНН, № свидетельства плательщика НДС и т.п. Думаю, что без создания своей модели поверх стандартной, обойтись не получится.

[Libovs]

Цитата:

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

Есть серия уже подготовленных отчетов. Вы можете модифицировать их. Их вызов уже определен какой то логикой и возможно кодом написанным за вас.

Вот в этом то и суть вопроса. Вижу, например, в Управлении печатью документ "Отборочная накладная заказа на продажу", вижу что стандартно используется SSRS-отчет SalesPackingSlip.Report.

Как мне определить стандартную модель, для которой делать локализованный формат, чтобы заменить этот отчет?