RecordRef & Report

[Sancho]

допустим, у меня есть уже подготовленный RecordRef, уже на нужной записи, уже с SETRECFILTER...
а еще у меня есть номер отчета (ReportID), который надо запустить на этой записи.

очень хотелось бы написать:
REPORT.RUNMODAL(ReportID,FALSE,FALSE,RecordRef);

но отчет не ест RecordRef, а просит конкретную Rec

следовательно, приходится писать что-то типа
RecordRef.SETTABLE(SalesHeader);
SalesHeader.SETRECFILTER;
REPORT.RUNMODAL(ReportID,FALSE,FALSE, SalesHeader);

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

как сделать красиво? отцепить отчет от конкретной записи?

(кроме варианта открывать отчет через гиперссылку)

[prefreitor]

Как вариант: Перед запуском отчета передать в него RecRef. Отчет построить на Integer c использованием временной буферной таблицы.

[Sancho]

спасибо, но отчеты-то как раз надо запускать стандартные

[Fordewind]

Цитата:

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

спасибо, но отчеты-то как раз надо запускать стандартные

не совсем понятно, как отчеты стандартные, а вызов нет...

[Sancho]

например, табличка 77 требует выбора Формы ID из безумного но тем не менее ограниченного списка.
а вдруг я какой новый документ создал? приходится дорабатывать эту табличку, опшн расширять...
а хочется сделать аккуратную настройку, которую дорабатывать не надо будет.

вот как-то так.

[foxsoft2005]

В свое время столкнулся с подобной задачей в своей системе обновления. Причем даже не с "подобной", а прям с такой же. К сожалению, решить подобную задачу (именно в том виде, как Вы ее обозначили) нельзя.

Думаю, проще будет перечислить Реки. Хотя, конечно, в свете самого наличия механизма RecRef и FieldRef такое извращение кажется моветоном

Добавил
Насчет отцепления отчета от конкретной реки - да, это вариант . Но тока, вероятно, придется оочень много отчетов отцеплять. К тому же, это не избавит от необходимости "перечислить все реки". Мона еще обертку написать, которая будет вызывать конкретный отчет с нужной рЕкой по входящей RecRef.

[Sancho]

Цитата:

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

В свое время столкнулся с подобной задачей в своей системе обновления. Причем даже не с "подобной", а прям с такой же...

спасибо.
а можно чуть подробнее о Вашей системе обновлений? зачем? что умеет? тут или в личку.

[foxsoft2005]

Конечно можно . И в личке необязательно даже.

Система обновления призвана была упростить процесс тиражирования версий (объектных и настроечных) в компании с большим кол-вом баз НАВ.

Умеет она вот что:

1. Программная загрузка объектов системы (некая эмуляция фоб-файла).
2. Последовательный запуск некоего количества "шагов обновления".
3. Централизованное обновление настроечных таблиц (тип General Ledger Setup).
4. Очистка рабочей БД от "лишних" объектов.
5. Возможность запуска SQL-скриптов на БД НАВ (а вдруг понадобится )

Это, так сказать, "конторонезависимые" фичи системы, т.е. они работают, в принципе, на любой БД. Есть еще некоторые фичи, которые привязаны к функционалу конкретной компании (ну типа обновления справочников, типовых операций и регламентной отчетности) - их описывать нет смысла, так как не у всех есть функционал.

Все настройки (что и как обновлять) передаются через пул текстовых файлов спец. формата.

по пункту 1 - это НЕ заливка фоба. Это модель . Т.е. результат тот же, но другим способом. К сожалению, некоторые вещи он не обрабатывает (но они не работают и в стандартном средстве заливки фоба ). Об этом я писал где-то в этом разделе .

по пункту 2 - под "шагом" понимается запуск объекта типа Отчет, Датапорт, Репорт, XML порт, либо Кодъюнит. Т.е. можно настроить как перечень запускаеиых при обновлении системы объектов, так последовательность их выполнения, настройки (типа использовать ли принтер и форму, коммитить по выполнению, логировать время запуска и окончания работы). Вот именно работа именно этого пункта планировалась как то, над чем работаете Вы, ведь если можно было бы передать в REPORT.RUNMODAL RecRef - этот код мона было бы сделать гораздо более гибким, а в текущем состоянии он весьма ограничен. В частности, выполняемые ПЗ должны не иметь входящей Реки как параметра...

по пункту 3 - теоретически, этим механизмом можно обновить (т.е. запись в таблице должна существовать) ЛЮБОЕ поле в ЛЮБОЙ таблице. Это актуально, например, для блокировки значений измерений, простановки всяких галочек в настроечных таблицах. Но этот механизм тоже не идеален, так как не позволяет передавать БЛОБ поля. Об этом я писал в другом топике здесь же, в этом разделе.

Система писалась под NAV3.70B, в которой платформенно нет некоторых полезных фич, кои есть в NAV40 или NAV50 (например, в пятерке мона дописать код по пункту 3, чтобы он мог передавать БЛОБ-поля), посему, вероятно, в более старших версиях ее можно будет докрутить и оптимизировать . Вот такая штука...

P.S. Насчет "контрозависимых" фич - система будет работать, например, на типовом решении под НАВ для страховых компаний .

[foxsoft2005]

Плюс ко всему выше - система делает более гибким версионный контроль баз НАВ (ну например, версия текущей рабочей БД 1.1 и так везде, во всех других БД).

[Константин!]

незнаю поможет нет, но на mibuso.com был совет как менять номер rec переменной через текстовый фаил в NAV Tips & Tricks вроде.

задача: есть список таблиц, надо запустить связаную с таблицой форму оператором form.runmodal(0,rec);

решение в прикрепленном файле

в вашем слушае из recref берем id
потом представленым способом меняем пременную rec1 в коде юнете на нужный нам id
запускаем функцю код юнита передавая в нее recordref, reportid

RecordRef.SETTABLE(rec1);
rec1.SETRECFILTER;
REPORT.RUNMODAL(ReportID,FALSE,FALSE, rec1);

[attachment=952:RunAnyForm.fob]
[attachment=953:RunAnyForm.txt]

[foxsoft2005]

а rec1 - это конкретная река, не правда ли?

А если требуется запускать N отчетов с РАЗНЫМИ реками на входе? Получается, что в этом самом кодюните надо перечислить N переменных типа record, что, в принципе, аналогично описанному в первом посте коду... Т.е. этот подход не отменит необходимости перечислить все реки. А если не отменит - то зачем такие сложности?

[Alterant]

Цитата:

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

а rec1 - это конкретная река, не правда ли?

А если требуется запускать N отчетов с РАЗНЫМИ реками на входе? Получается, что в этом самом кодюните надо перечислить N переменных типа record, что, в принципе, аналогично описанному в первом посте коду... Т.е. этот подход не отменит необходимости перечислить все реки. А если не отменит - то зачем такие сложности?

Там фишка в том, что кодъюнит генерируется (точнее немного исправляется) на лету и перед запуском в систему импортируется версия кодъюнита уже с нужной таблицей. Интересно только насколько это надежно работает в многопользовательской среде ...

[foxsoft2005]

Цитата:

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

Там фишка в том, что кодъюнит генерируется (точнее немного исправляется) на лету и перед запуском в систему импортируется версия кодъюнита уже с нужной таблицей. Интересно только насколько это надежно работает в многопользовательской среде ...

Вот и проверю...

[foxsoft2005]

Цитата:

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

Там фишка в том, что кодъюнит генерируется (точнее немного исправляется) на лету и перед запуском в систему импортируется версия кодъюнита уже с нужной таблицей. Интересно только насколько это надежно работает в многопользовательской среде ...

Докрутил систему обновления, шоб она использовала эту доработку. Будем тестить на людях . О результатах отпишусь...

[foxsoft2005]

Хотя... Может и прокатит

[Константин!]

ниче перечислять ненадо канкретная река меняеться на лету на нужную и запускайте хоть тучу отчетов в цикле

[foxsoft2005]

Дык я ж написал . "Хотя, может и прокатит"

[Sancho]

кошмар!
это ж невиданные перспективы динамического перепрограммирования Navision!

вот уж действительно, голь на выдумки хитра!..

к тому же лицензия разработчика "динамическому перепрограммисту" может не понадобиться...
спасибо, парни! скачал, пошел смотреть!

[Sancho]

вах!
есть решение! в 5-ке работает!
в функции создается пареметр типа Variant, а передается ей не RecordRef, а Rec! правда предварительно отсекресфильтренный

вызов функции
Rec.SETRECFILTER;
PrepareReport(Rec);

PrepareReport(Rec : Variant)
...// тут зашита вся бизнес-логика, которую лень писать в каждой таблице отдельно.
PrintReport(RecordID,Rec);

PrintReport(RecordID : Integer;Rec : Variant)
REPORT.RUNMODAL(RecordID,FALSE,FALSE,Rec);

работает!
очередной раз коллективный разум победил Navision!

будет ли работать в 4-ке и 3-ке? не знаю, надо проверить...

[foxsoft2005]

Я рад