(2)Т.е. при создании объекта он проверяет доступность всех процедур? Нужно сделать все экспортными и проверить на использование методов в них не доступных на сервере?
(3) Нет. Он у тебя либо просто не компилируется на сервере, либо валится именно секция инициализации, если верить сообщению об ошибке (посмотри код вне процедур, обычно в самый низ пихают). Еще можно в конфигураторе запустить синтаксическую проверку модулей, на предмет возможности работы на сервере. Есть там такая опция, если в настройках порыться. Тогда для твоего модуля он скорее всего четко скажет, что ему не нравится.
(3) экспортных делать не надо. Это тут лишнее. Скорее всего в стандартных обработчика модуля объекта используются интерактивные вызовы. Обычно это Предупредить, Сообщить и т.д. Их убрать или обернуть в команды препроцессора компиляции.
(6) то что Сообщить() работает на сервере, не означает, что это работает в регламентном задании. Регламентное задание запускается не с клиента и сервер не знает, куда это потом Сообщать...
(7) всё прекрасно работает. Открой для себя ПолучитьСообщенияПользователю().
испытай его.
Посмотри на его реализацию в портативных инструментах разработчика.
попробуй у себя.
Потом открой коньяк и выпей за моё здоровье и мои умные советы.
(11) Справедливости для - началось с того, что "Сообщить" было упомянуто как возможная причина сбоя. На что последовало справедливое возражение. "Сообщить" не может являться причиной сбоя при исполнении на сервере, в т.ч. в фоновом задании.
(14) справедливости для... Причиной было указано "Скорее всего в стандартных обработчика модуля объекта используются интерактивные вызовы."
Далее перечислены интерактивные вызовы.
Возможно именно Сообщить() ошибку и не даст, но и не место его в модуле объекта. В крайнем случае для УФ используется СообщениеПользователю, так как это уже не прямой интерактивный вызов.
Даже рекомендация от 1С имеется: Ограничение на использование метода Сообщить
(15)
1. Сообщить() не является интерактивным вызовом, так как не требует реакции пользователя.
2. Сообщить() не вызовет ошибку при компиляции модуля для сервера и даже для внешнего соединения.
Это трудно понять, это нужно запомнить и с этим смириться.
А не строить теорий даже не на песке, а на Ньютоновой жидкости.
(15) Не "возможно", а "совершенно точно не даст". Доступность: "сервер". Да и практикой проверено.
То, что на сервере это атавизм - это уже оффтопик.
Что касается классификации - это несомненно интерактив. Но тоже "не прямой", как вы выразились.
Поясню почему ошибка.
У вас конфигурация на ОФ явно. Потому что на УФ вы бы и так видели эти ошибки.
Вам выдало ошибку на модуль, потому что регламентное задание выполняет инициализацию на сервере, а не на клиенте. Да-да сервер тоже есть и на ОФ! Поэтому обращайте внимание на то что пишется в справке (сервер, клиент и т.д.).
Всем большое спасибо. Выявил методом исключения. Закоментировал весь модуль и по одной процедуре раскоментировал. Оказалось как и говорилось использовалось Предупреждение. Но зачем это делать в экспортной процедуре модуля объекта. Вставил проверку на препроцессор, заработало. Всем спасибо.