Конечно можно
. И в личке необязательно даже.
Система обновления призвана была упростить процесс тиражирования версий (объектных и настроечных) в компании с большим кол-вом баз НАВ.
Умеет она вот что:
1. Программная загрузка объектов системы (некая эмуляция фоб-файла).
2. Последовательный запуск некоего количества "шагов обновления".
3. Централизованное обновление настроечных таблиц (тип General Ledger Setup).
4. Очистка рабочей БД от "лишних" объектов.
5. Возможность запуска SQL-скриптов на БД НАВ (а вдруг понадобится
)
Это, так сказать, "конторонезависимые" фичи системы, т.е. они работают, в принципе, на любой БД. Есть еще некоторые фичи, которые привязаны к функционалу конкретной компании (ну типа обновления справочников, типовых операций и регламентной отчетности) - их описывать нет смысла, так как не у всех есть функционал.
Все настройки (что и как обновлять) передаются через пул текстовых файлов спец. формата.
по пункту 1 - это
НЕ заливка фоба. Это модель
. Т.е. результат тот же, но другим способом. К сожалению, некоторые вещи он не обрабатывает (но они не работают и в стандартном средстве заливки фоба
). Об этом я писал где-то в этом разделе
.
по пункту 2 - под "шагом" понимается запуск объекта типа Отчет, Датапорт, Репорт, XML порт, либо Кодъюнит. Т.е. можно настроить как перечень запускаеиых при обновлении системы объектов, так последовательность их выполнения, настройки (типа использовать ли принтер и форму, коммитить по выполнению, логировать время запуска и окончания работы). Вот именно работа именно этого пункта планировалась как то, над чем работаете Вы, ведь если можно было бы передать в REPORT.RUNMODAL RecRef - этот код мона было бы сделать гораздо более гибким, а в текущем состоянии он весьма ограничен. В частности, выполняемые ПЗ должны не иметь входящей Реки как параметра...
по пункту 3 - теоретически, этим механизмом можно обновить (т.е. запись в таблице должна существовать) ЛЮБОЕ поле в ЛЮБОЙ таблице. Это актуально, например, для блокировки значений измерений, простановки всяких галочек в настроечных таблицах. Но этот механизм тоже не идеален, так как не позволяет передавать БЛОБ поля. Об этом я писал в другом топике здесь же, в этом разделе.
Система писалась под NAV3.70B, в которой платформенно нет некоторых полезных фич, кои есть в NAV40 или NAV50 (например, в пятерке мона дописать код по пункту 3, чтобы он мог передавать БЛОБ-поля), посему, вероятно, в более старших версиях ее можно будет докрутить и оптимизировать
. Вот такая штука...
P.S. Насчет "контрозависимых" фич - система будет работать, например, на типовом решении под НАВ для страховых компаний
.