Собственно, вот: http://dl.dropbox.com/u/4517049/13.png
Проблема в том, что в отчетах выводится первый документ (который совсем пуст при открытии, т.е. реквизиты не заполнены, кроме даты и номера) с реквизитами от второго.
В поиске ссылок на объект по первому документу выводится второй, поэтому и удалить его не получается.
Друзья, как-то можно пациента вылечить?

Может скопировать документы (им новый ИД присвоится), провести замену ссылок и оба косячных удалить

(1) документы оба в прошлом периоде, второй из них (на рисунке первый, с префиксом АСПТ) - правильный. Требуется как-то убрать из ИБ информацию о первом (с префиксом А), т.к. 1С в отчетах выводит ссылку как раз на него.
Копировать документы трудоемко (у АСПТ в структуре подчиненности с десяток других документов), а как осуществляется процесс замены ссылок?
Нашел лишь метод УстановитьСсылкуНового(<Ссылка>), но там аргумент "не может равняться ссылке какого-либо из имеющихся в базе данных объекта данного типа. Уникальность ссылки проверяется при записи объекта" (из СП).

(2) Копировать = нажать кнопочку "скопировать". Замена ссылок, это стандартные обработки на ИТСе.

Лезешь в базу ручками и правишь гуид

(3) нежелательно, период закрыт, последовательности съедут, движения могут стать другими; за вариант благодарю, реализую если не придумаем другой
(4) ручками в данном случае будет выступать код некой обработки?

(5) Ручками - это значит лезешь на sql-сервер сторонней тулзой и правишь нужную таблицу. Нарушая лицензионное соглашение, но кто об этом узнает?)

(6) Почему на уровне sql  нет проверки на уникальность значения поля этой колонки?

(6) подсказать можешь, какой софтиной например?
(7) потому что это не ошибка базы/платформы, встречал использование этой возможности в обменах.

(8) MS SQL Server Management Studio

Вообще-то, насколько я понмю, в скуле ссылка (поле IdRef) является PrimaryKey

Интересно а что при этом возвращает?
Документы.РеализацияТоваровИУслуг.ПолучитьСсылку(Новый УникальныйИдентификатор("этот-длинный-гуид"))

Да вообще фейк какой то, а если я сейчас документ с таким гуидом запишу, кто из них перезапишется?

+ 10, так что прежде чем удалять я бы предложил разобраться - как подобная ситуация возникла (вообще-то стандартными 1с средствами не создашь вторую запись с такой же ссылкой этого же элемента метаданных. Другой тип - можно)
Похоже на косяк со скулем

(10) Если это разный вид документов (а автор мог сделать второй документ с одной латинской буквой), то это уже не будет примари кей

(11) Насколько помню - при попытке создать элемент с таким же гуидом выпадет по ошибке - вставка записи с неуникальным значением ссылки

(14) Нет, такая попытка переписывает существующий элемент с таким же гуидом

+1 за фейк... не верю

(0) Сравни в табло эти две строки - одинаковые?
Напиши что-то вроде: ЗначениеВСтркуВнутр(Ссылка1) = ЗначениеВСтркуВнутр(Ссылка2)

(15) Поробовал. Не дал записать с ошибкой.
Делал так:
получаю гуид справочника,
создаю новый элемент этого же справочника с этим гуидом (через получить ссылку + установить ссылку нового).
При попытке записать ругается - вставка записи с неуникальным значением ссылки.

Больше не придумал, как убедить, что это не фейк: http://dl.dropbox.com/u/4517049/14.png
Но хотя и здесь есть где сомневаться. Может, у (16) есть идеи, как же так написать в табло? :)
Может, мне показать вам кусок скульной бд (если скажете, где и как это найти в Management Studio)?
(17) будет истина, но от фейка это не спасет (а народ сомневается).

+ (19) вы сами-то попробуйте написать то что в табло - у меня при любом номере документа одинаковый гуид возвращает :)

(20) /при любом номере документа одинаковый гуид возвращает

гуид, это тот что нулями обозначен? по моему это означает что эти документы не найдены. :)

(20)
Блин, напиши в табло по человечески
Документ.НайтиПоНомеру("такойто").УникальныйИдентификатор()

(22) нули выдает (как в Предприятии, так и в отладке Конфигуратора). Неужто в табло нельзя узнать ГУИД?

Вот вам из демобазы: http://dl.dropbox.com/u/4517049/15.png

для документов нужно еще дату указывать, тогда найдет. =)

v8: Найти по номеру документ

(25) благодарю! Теперь видно, что ГУИДы разные: http://dl.dropbox.com/u/4517049/15%20(2).png
Однако проблема остается: нельзя удалить первый (префикс А) из базы, т.к. при поиске ссылок выдается, что на него ссылается второй документ (префикс АСПТ).
Что-нибудь кроме создания нового документа и удаления этих обоих (мне непонятно чем связанных) можно попробовать для решения проблемы?

http://dl.dropbox.com/u/4517049/16.png

на документ реализации ссылается другой документ реализации чтоли? оО
а не заказ ли покупателя?  =)

(28) да, при поиске ссылок на первую РТУ выдает вторую РТУ. В структуре подчиненности первой РТУ пусто, в подчиненных второй

РТУ первой нет.

При ВыгрузкеЗагрузкеXML и проставленной галке "При необходимости" у всех метаданных и добавлении косячной А-реализации (РТУ с префиксом А) выгружается только один объект, что говорит о том что ничего другого он не тянет за собой. Но поиск ссылок на объект упорно выдает мне порядочную АСПТ-реализацию (РТУ с префиксом АСПТ) и не дает удалить косячную.

/при поиске ссылок

что за поиск? через операции- поиск ссылок?

Я бы попробовала выгрузить и загрузить ИБ. А можно сделать тестирование и исправление

Насколько я понимаю, при удаление документ становится невидимым, но физически не удаляется. А при выгрузке загрузке, невидимые элементы не переносятся. Таким образом и физически существующие, но невидимые не потянутся и ошибка исчезнет

(32) да, Операции - Поиск ссылок на объект, либо при удалении он то же самое выполняет. И там и там А-РТУ и АСПТ-РТУ связаны.
(33) попробую.

+ (35) для (32) - при удалении помеченных объектов. Что типовым, что с ИТС (без монопольного режима).

два одинаковых ПУСТЫХ гуида????

(37) да нет же =) см. (27)

(37) название ветки уже неправильное, пардон за ввод вас в заблуждение.
Скопировал через ВыгрузкуЗагрузкуXML этот пустой А-РТУ в бекап базы. В бекапе этого паразитного документа (А-РТУ) нет. Когда он загрузился, на него стала ссылаться правильная АСПТ-РТУ

Друзья, как-нибудь можно выяснить, почему на одну РТУ ссылается другая РТУ? Где хранится эта связь и какого она рода?
Щас полезу в обработку удаления с ИТС, как она там ссылки ищет.

А Тестирование и исправление базы делал?

(37) +1

(38) два гуида разные.

(41) база скульная, бекап будет на выходных, там и попробую.
Оказывается поиск ссылок на объект - встроенная функция НайтиПоСсылкам()

гуид ссылки одинаковый.. гуид объекта разный.

(44) А что, прямо сейчас архив не сделать? О_о

это одинаковые гуиды объекта СтрокаВнутренн или чего там..

(41) вдогонку: если ТиИ с опцией "Очищать пустые" поможет, то как избирательно это потом проделать на рабочей базе? Сцыкотно для всей базы запускать, бекап скуля весит под 50 гигов.
(45) все разное, уже убедились. Изначально совпадали потому что объект не находился вообще, т.е. это были гуиды для пустых ссылок.
(46) компания работает круглосуточно, в выходные с этим полегче обстоят дела.

(48) тогда ВОПРОС ЗАКРЫТ

(48) бекап можно сделать средствами скуля при работающих пользователях.
/если ТиИ с опцией "Очищать пустые" поможет
выбирайте опции удалять объекты и ссылки, тогда ТИИ все сама сделает.
давно наверное тестирование не делали?
только вначале бекап.

(49) оказывается не закрыт: http://dl.dropbox.com/u/4517049/18.png
(50) давно не делали и пока не собираемся: как потом гарантировать отсутствие косяков в базе, вернее как их _все_ выявить?

(49) чтоб глаза не портил: ГУИДы на ссылки разные, на объекты - одинаковые.

Значит что то с индексом. Переиндексируй Базу

(51) "давно не делали и пока не собираемся: как потом гарантировать отсутствие косяков в базе..." - достойна удивления сия позиция :( Она "гарантирует" наличие косяков :)

Хотя бы, сделайте только тестирование, без внесения изменений...

PS: сорри, за резкость замечания

(29) Смотри какие поля могут иметь искомый тип и их исследуй

Для одинаковых типов ЗначениеВстрокуВнутр для объектов выдает один и тотже результат.

2(19) вот-вот, за гуиды доков принял гуиды вида документа.

(54) не по фен-шую поступаем, да.
(56) прав, благодарю!
(55) Причину связи двух РТУ установил: РН "Взаиморасчеты по документам расчетов", у правильной РТУ присутствуют левые движения.
На тестовой базе проверил - достаточно перепровести первичный (правильный) документ, и левые движения исчезают. Документ не относится к разряду тех, у которых могут измениться проводки при перепроведении (4 регистра двигает, цифра берется из документа), т.к. там только реализация услуги; т.е. перепровести можно безболезненно, записи в регистрах не изменятся, а косячные удалятся (что и требуется).
Варианта два:
1) делать корректировку записей регистров;
2) перепровести документ + передвинуть границу партий программно + исключить из обмена этот объект.
Насколько Я понимаю, разница будет только в том, что косяк либо совсем уйдет, либо уйдет начиная с даты документа корректировки записей регистров. А как поступаете вы в таких случаях (когда найден косяк в закрытом периоде)? Перепроводите или трудитесь по пункту 2?

А, кажется Я даже немного прогнал: РТУ с услугами партии не двигают, поэтому и граница последовательности партионного учета не сдвинется. Ща проверю на тестовой базе.