Всем привет.

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

По сути:
1. Все равно надо писать программу печати, которая запустит выборку данных на основе DAQ;
2. Все равно придется рисовать свою печатную форму для того чтобы переложить данных из DAQ в шаблон;

В чем тогда профит когда САП предложил еще один велосипед к генерации отчетов? Вижу только один: XML.

Как это вижу я.
DAQ-приложение в отчетах это то же самой, что схема расчета заработной платы в программе расчета зарплаты. В программе расчета зарплаты нет бизнес-логики расчета, все находится в схеме. Схема расчета заработной платы по сути написана на языке схем и правил, что позволяет достаточно гибко настраивать детали расчета не прибегая к правкам на языке программирования.
DAQ-приложения делают тоже самой в отношении отчетов – бизнес-логика задана языком настроек DAQ-полей, что позволяет в определенных пределах производить настройки не производя правки в тексте самого отчета на языке программирования. Сам отчет при этом превращается в сугубо технический движок, который умеет запускать DAQ-приложение.
Профит – возможность настройки без правки текста программы. Все остальное хуже – сложность разработки – выше, производительность – ниже.

Это да, никто не спорит, но я удивляюсь тому что надо настраивать и DAQ-движок и писать саму программу печати, которая его запустит. Вот если смотреть на реализованные приказы в РФ локализации (T60, T61), что кадровые приказы в украинской локализации (П-1, П-3) все равно для каждого приказа своя программа печати .

Если с драйвером расчета все понятно, он один, а схем много, то с DAQ ситуация совершенно другая... да и многого там не настроишь с нуля. По сути очень прикольно, если есть однотипные поля для разных приказов, к примеру, название подразделения, то глобально вот так их сходу не найти, реализация то через ФМы, списка которого нет, и все равно для каждой формы надо делать отдельно структуры данных, которые надо заполнять через программу печати... как-то очень САП замутило в этом плане.

Согласен на 100%.
Если прога стандартная, то иногда еще можно где-то обойтись настройкой. А если Z, то вовсе нет смысла юзать дак.

Если программа использованна в нескольких сопровождаемых вами системах, тогда не так очевидно, что выгодней.
Одна программа с разными настройками или несколько разных версий программ.

Не могли бы Вы привести пример Z-разработки с DAQ-полями, которую удобно поддерживать изменением настроек DAQ, не меняя кода ФМов. Я имею ввиду краткую постановку задачи, не исходный код

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

Я на практике использовал только свои коды видов оплаты (HRPAYRUT7RUN), которые использовались в специфическом отчете (специфика - не постоянное количество колонок).

Сам на DAQ полях z-отчеты не делал.
Те кто делал, говорят, что проще писать свою выборку данных без использования технологии daq-полей

мы сделали для локализации Беларуси все приказы на DAQ - одна программа, отличаются только ФМники выборки данных, в принципе можно добавлять поля и прописывать свои ФМники. Удобно. В принципе можно выделить в отдельный продукт.
Теперь думаю сделать миллион справок о доходах для банков и посольств тоже либо через одну программу в DAQ либо через HRForms.

Уважаемые знатоки DAQ!
Серия и номер паспорта выводятся в таком виде: <ID_NO>ss ssnnnnnn</ID_NO>
Как вставить пробел между серией и номером, т.е. нужно: <ID_NO>ss ss nnnnnn</ID_NO>