Платформа 1C 8.3.15.1830. Бухгалтерия 3.0. Клиент-серверный вариант, SQL SERVER. Две организации. Я - системный администратор компании. Договори ИТС имеется. Много лет я обновляю релизы 1С самостоятельно. Делаю это всегда одновременно для двух, релизы одинаковые. Конфигурации находятся на поддержке с возможностью обновления. Внесены небольшие изменения (только добавления - дополнительные регистры сведений и 2 подключенные обработки, никаких изменений в конфигурации поставщика). Веду журнал обновлений, где отмечаю когда, с какого на какой релиз прошло обновление и результат. Но время от времени возникают какие-то ошибки при установке - и тогда я приглашаю специалиста - франчайзи. Он как обычно делает какие то магические пассы и решает проблему. Но меня каждый раз напрягает источник возникновения проблемы. Тем более что в последние времена частота таких случаев возросла. На примере последнего случая хочется разобраться подробнее и научится устранять такие проблемы самостоятельно.
Итак пример - обновляю конфигурацию 3.0.79.21 на 3.0.81.25 - удачно для обеих организаций, сразу же - с 3.0.81.25 на 3.0.83.25 - неудачно для обеих! До этого была еще попытка с 3.0.77.106 на 3.0.79.21 - удачно и с 3.0.79.21 - на 3.0.81.30 - неудачно. Т.е. тут дело не в конкретном релизе. Ошибка происходит на этапе объединения основной конфигурации с конфигурацией БД. Скриншот прилагаю. На этапе сравнения конфигураций видно что объект от поставщика с такими именем и объект в основной конфигурации - это два разных объекта. И насколько я понимаю объект от поставщика пытается вставиться в основную конфигурацию. Но там уже такой есть! Вот и первый вопрос: как такое может произойти? У нас в режим конфигурации захожу только я. Конечно, есть главбух с правами, ну может кто-то еще, кто случайно зашел. Но даже если и случайно (или даже неслучайно!) что-то изменили - я что-то даже в воспаленной фантазии не представляю как туда можно попасть. Какая то чепуховая обработка по справке СПАРК-рисков, да еще и макет справочной страницы! Тем не менее она заставляет меня приглашать настройщика, а компании платить деньги. Вариант второй - ошибка конфигурации у поставщика? Опять же таки непонятно как такое могло произойти. Насколько я читал, соответствие объектов основной конфигурации и конфигурации поставщика осуществляется через внутренние ID, которые в случае полной поддержки идентичные, а в случае поддержки с изменениями - могут быть разными, но где то эти соответствия запоминаются. Как могла получится картинка 1. Основная конфигурация: <Объект отсутствует> - Конфигурация поставщика: Обработка.СправкаСпарк... 2.Основная конфигурация: Обработка.СправкаСпарк... - Конфигурация поставщика:<Объект отсутствует> ? Ну и второй вопрос - последовательность действий - как от этого избавиться. Надо, как я понимаю удалить объект из основной конфигурации и добавить его из конфигурации поставщика с поддержкой. Я попробовал такой вариант. 1. Снял с поддержки объект в основной конфигурации. 2. Удалил его в основной конфигурации. 3. Меню Конфигурация - Поддержка - Обновить конфигурацию. В результате действий объект в основной конфигурации исчез. Как то через сравнение и объединение это делается... Извиняюсь за много слов. Ответ может быть кратким, если у кого есть желание ответить.

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

Никогда никаких констант и прочего я не отмечаю. Ситуация стабильно стабильная - существует конфигурация, да с небольшими добавлениями. Никаких новых изменений в конфу не происходит. Одно обновление, другое, третье, пятое и т.д. И вдруг - опа! Какой то лишний объект. Причем один и тот же сразу в двух конфигурациях (две разные организации)! Ведь я их обновляю параллельно! Кроме меня доступ к конфигурации - сегодня специально проверил - был у одного пользователя - главбуха. Но зачем это ей - зайти в двух конфигурациях в одно и тоже место и что то там поменять? Вернее даже не так - в двух конфигурация - разные пользователи. Во второй тоже главбух - дедушка, который до сих пор в 7.7. сидит. А 8.3 - у него только для просмотра. Значит эти самые главбухи сговорились и давай вносить несанкционированные изменения в свои конфигурации... Шутка. Нет тут никакой логики. Но в чудеса я тоже, как опытный программист не верю. Поэтому и пытаюсь понять причину. Тем более что статистика мне показывает - такие происшествия учащаются. За последние 2 года мне уже три раза пришлось настройщиков вызывать. Компании это обходится в лишние деньги. В данной ситуации я на ее стороне и хочу уменьшить ее расходы (и доходы франчей, увы!). За ссылку спасибо. Стандартное обновление особых умений не требует, чем я и пользовался многие годы. Но уже этого недостаточно, а то так скоро на каждое обновление надо будет Вия вызывать....

В итоге так и сделал - после объединения основной конфигурации с конфигурацией поставщика но до сохранения конфигурации образовалось два объекта с одинаковым названием. Это был макет в этой справке СПАРКРИСКИ. Один на поддержке, другой - без. Удалил второй, дальше все пошло без запинки. Но проблема источника неприятностей остается открытой. В журнале регистрации поискал события, связанные с обновлением ИБ за последний год, но что то ничего такого не нашел. Может как то по другому искать надо - не знаю.