Не зависит от конкретной конфигурации.
Для восстановления документа:
1. Выбираем тип восстанвливаемого документа из списка
2. Из строки «<Объект не найден> (86:abd5001e0bc5080e11de80e5f65c854a)»
вырезаем только «abd5001e0bc5080e11de80e5f65c854a»
и вставляем в поле «Идентификатор»
3.Нажимаем «Выполнить», и видим вновь созднанный документ с нужным нам
UID. дальше его уже можно заполнить как надо, или просто сохранить пустым
для последующего корректного удаления.
P/S
Большое спасибо автору с «1c.proclub.ru» по чьим следам и была написана
данная внешняя обработка, т.к. в его решении предлагалось встроить процедуру
непосредственно в документ в конфигураторе.
А сможешь без выбора типа документа?
(1) как-то не задумывалась…
надо попробовать
Хорошая вещь.
надо развивать и для справочников.
Извините, но в чем ценность? в том, чтобы отсутсвующую ссылку превратить в псевдоживую? без информационного наполнения «созданного» документа…? типа пустышки…? ну так это вредно может быть.. висящие ссылки еще как-то можно найти, проанализировать что и почему хоть чуть-чуть.. а если такой док сделан — то потом его не выкусишь для анализа.. — хотя бы в коммент пихайте типа «восстановлен из висящей ссылки».
.но как инструмент, наверное, пригодится…
вот если бы искать умела…
(4) в случае единичного критичного восстановления уже известно откуда «ноги растут» и документ заполняется нужными данными, основываясь на том, где на него вообще существует ссылка. либо в нем и не нужны данные, если стоит задача убрать по нему движения.
а для массового исправления — это уже «тестирование и исправление» в конфигураторе…
(5) ну, если потеря данных — случай регулярный, то тут не механизмы исправления, а саму систему совершенствовать надо.
(3) как-то со справочниками везло больше (тьфу-тьфу), будет минутка — сделаю.
Самое хитрое — сопоставить «(86:» и таблицу данных (тип). Я пока не встречал решенияю