Всем привет.
Есть огромный блок дилерской конфигурации, встроенный в 1С Торговля. Все главные методы написаны на клиенте.
Смысл следующий: чтобы обновить данные по документу необходимо зайти в документ и нажать кнопку обновить. Это очень не удобно. Я написал обработку которая это делает для всех документов. Но хотелось бы повесить на регламентное задание, чтобы раз в час выполнялось.
Но проблема: чтобы это сделать необходим чисто серверный код. Мне чтобы это все переписать пол месяца уйдет + будут дальнейшие огромные проблемы по сопровождению, так как придется две ветки кода отслеживать.
Есть ли какие-либо варианты все-таки в данной ситуации используя костыли все-таки как-нибудь выкрутиться или нет?
Огромное спасибо.
---
Модуль УправляемогоПриложения, ПриНачалеРаботыСистемы():

```1c
    ПодключитьОбработчикОжидания("ВызовВашегоКодаНаКлиенте", 60*60);
```
---
Т.е. как-то необходимо по регламентному заданию запустить процедуру которая написана &НаКлиенте
---
Я уже только что не смотрел.
На ИТС есть Выполнение регламентных заданий на клиенте - но это не совсем то что нужно
Думал обработчик ожидания использовать - но они забывают в начале дня запускать обработку все-равно.
---
Сделать в Windows регламентное задание, которое запускает 1С с вашей обработкой на клиенте?
---
Модуль УправляемогоПриложения, ПриНачалеРаботыСистемы():

```1c
    ПодключитьОбработчикОжидания("ВызовВашегоКодаНаКлиенте", 60*60);
```
---
"Ну или так" (С). Но в этом случае надо обязательно проверять на пользователя (те ли права) и не запущен ли уже обработчик.
---
Большое спасибо, это я думаю то что нужно. есть свои сложности - но в целом довольно просто реализуется. К регламентному заданию Windows не хотел привязываться из-за распределенной базы данных - лишние проблемы, потом можно забыть и т.д.
Спасибо всем)))
---
сделать батник с вызовом 1с параметром
/Execute [имя файла внешней обработки] — предназначен для запуска внешней обработки в режиме 1С:Предприятие непосредственно после старта системы.

в шедулере виндовс настроить вызов батника
---
А батник нафига? Можно же напрямую в шедулере прописать этот однострок.
---
либо как в (7), либо поставить типа jenkinsa и там запускать
---
"Кациусы господи" (С)
https://wonderland.v8.1c.ru/blog/peredacha-informatsii-s-servera/

надо подробностей?
---
Если честно пытался разобраться но не совсем смог...
---
"Надо, Федя. Надо" (С) Потому-что это и есть решение вашей проблемы. Без костылей, без "о прикинь я придумал велосипед", без извращений, без нагрузки на клиента, без нагрузки на сервер, и такое можно продолжать....
---
Серьезно? Внешняя зависимость на отдельный программный продукт, который под собой имеет много всего и требующий отдельного сопровождения (в идеале на отдельном сервере/кластере) ради того, чтобы сэкономить децил накладных расходов на нечастый опрос с клиента из кода 1С - это "без извращений", "без костылей" и "без нагрузки на сервер"?
Система взаимодействий - крутая штука. Но любой инструмент, какой бы прекрасный он ни был, нужно применять в нужном месте и в нужное время.
Есть ситуации, когда СВ - наилучшее решение из всех возможных и меньшее из зол. Но это явно не тот случай. Не говоря уже о том , что основную проблему запуска клиентского кода СВ не решает никак. Это просто система обмена сообщениями с удобными плюшками для конкретных вариантов использования.
---
У всех фломастеры разные, и когда у тебя 500 клиентов каждые 60 секунд долбятся в сервер запрашивая одно и тоже.... отличные накладные расходы

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

"Не говоря уже о том , что основную проблему запуска клиентского кода СВ не решает никак."
RTFM. Очень внимательно раздел "Основные возможности и сценарии".

ПС: Согласен что есть риски в системе и в поддержании отдельного сервиса, тут я с вами согласен на 100%. Больше сервисов, больше хлопот. Но если сервис установлен, обслужен и валидирован - никаких проблем не будет
---
"Не говоря уже о том , что основную проблему запуска клиентского кода СВ не решает никак."
RTFM. Очень внимательно раздел "Основные возможности и сценарии".
Так для этого нужно чтобы клиент уже был :) Это и есть основная проблема запуска клиентского кода по расписанию.
А прилетит ли тебе событие или ты сам о нем узнаешь путем опроса - это уже семечки.
Реальные проблемы с опросом возникают только когда он дорогой или нужен часто и много. Даже если 500 клиентов раз в минуту будут делать простой опрос - они не смогут создать хоть сколько-нибудь значимую нагрузку на сервер.