gifts2017

Борьба с дублями (номенклатуры, контрагентов) или чем полезен внутренний идентификатор объекта

Опубликовал Анянов Михаил (insurgut) в раздел Администрирование - Чистка базы

Ситуация. Звонит бухгалтер и говорит, что у него опять "задвоилась" карточка контрагента, но ведь мы ее успешно объединили в прошлый раз (месяц, квартал) при помощи обработки поиска и замены дублирующихся элементов. Сколько можно объединять? Почему дубли появляются вновь и вновь?

Поводом для написания этой статьи стал очередной звонок бухгалтера с паникой перед сдачей отчетности по НДС. В прошлом квартале потратил много времени на уборку дублей контрагентов. И вновь они, те же самые и новые. Откуда?

Решил потратить время, и разобраться с причиной, а не следствием. Ситуация с основном актуальна при настроенных автоматических выгрузках через планы обмена из управляющей программы (в моем случае УТ 10.3) в бухгалтерию предприятия (в моем случае 2.0).

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

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

Для того, чтобы не возникало новых дублей алгоритм уборки дублей стал следующим:

1. В БП при помощи обработки "Поиск и замена дублирующихся элементов" (она типовая, ее можно взять из конфигурации Управление торговлей или на диске ИТС, либо выбрать наиболее подходящую среди множества вариаций на самом Инфостарте) нахожу дубль, определяю верный элемент, нажимаю выполнить замену.

 Шаг1_1

Шаг1_2

2. Получаю внутренний идентификатор единственного (после замены) объекта нашего дубля (набросал специально простенькую обработку для этого, чтобы внутренний идентификатор автоматически копировался в буфер обмена).

Шаг2

3. Открываю в УТ регистр "Соответствие объектов для обмена", делаю отбор по собственной ссылке.

 Шаг3

4. Заменяю значение ссылки в другой ИБ для нашего узла обмена с БП значением, полученным в п. 2.

Шаг4

 

Собственно говоря, вот и все, после этого новые документы по контрагенту прилетают как положено, новых дублей не создается. Возможно статья будет кому-то полезна :)

Скачать файлы

Наименование Файл Версия Размер
Внутренний идентификатор объекта 74
.epf 6,64Kb
24.12.13
74
.epf 6,64Kb Скачать

См. также

Подписаться Добавить вознаграждение
Комментарии
1. Павел И. (3.14159) 24.12.13 17:21
А почему нельзя просто почистить РС "Соответствия объектов для обмена"?

при очередном обмене этот РС заново начнет заполняться по правилам поиска в правилах обмена
2. Никита Привалов (thenroach) 24.12.13 17:44
Мы с контрагентами проще сделали. Заставили клиентов в таких дубляж заполнять головного контрагента и в правилах поставили замену на головного контрагента если он есть. И управленцы и клиенты довольны.
3. Анянов Михаил (insurgut) 24.12.13 17:55
(1) 3.14159, потому что с его помощью мы настраиваем соответствие одного и того же контрагента с различными внутренними идентификаторами в наших базах.
4. Анянов Михаил (insurgut) 24.12.13 17:56
(2) thenroach, интересное решение, возьму на заметку :)
5. Павел И. (3.14159) 24.12.13 18:40
(3) insurgut, вручную чтоли настраиваете? o_0

я всегда думал, что он при обменах сам заполняется
6. Анянов Михаил (insurgut) 24.12.13 20:11
(5) 3.14159, все верно, заполняется он изначально автоматически. Но если что-то идет не так в дальнейшем (появление дублей, уборка дублей), в результате чего идентификаторы объектов начинают различаться, в этом регистре может содержаться некорректная информация. Ситуация в большинстве случаев не типовая. Привел решение как раз для случая, если вдруг придется столкнуться с проблемой.

Еще бывают случаи, когда один контрагент (номенклатура, договор и т.п.) при выгрузке встает на другой элемент справочника. При помощи описанных действий можно разобраться "где собака зарыта".
7. Павел И. (3.14159) 24.12.13 21:15
(6) insurgut, в консоли запросов (способ выгрузки дерево:) можно сразу поискать все "проблемные собакой зарытые"

ВЫБРАТЬ
СоответствиеОбъектовДляОбмена.УзелОбмена,
СоответствиеОбъектовДляОбмена.СобственнаяСсылка,
ТИПЗНАЧЕНИЯ(СоответствиеОбъектовДляОбмена.СобственнаяСсылка) КАК ТипЗначенияСобственнойСсылки,
СУММА(1) КАК КолВо
ПОМЕСТИТЬ СоответствиеОбъектов
ИЗ
РегистрСведений.СоответствиеОбъектовДляОбмена КАК СоответствиеОбъектовДляОбмена

СГРУППИРОВАТЬ ПО
СоответствиеОбъектовДляОбмена.СобственнаяСсылка,
СоответствиеОбъектовДляОбмена.УзелОбмена
;
ВЫБРАТЬ
СоответствиеОбъектов.УзелОбмена КАК УзелОбмена,
СоответствиеОбъектов.ТипЗначенияСобственнойСсылки КАК ТипЗначенияСобственнойСсылки,
СоответствиеОбъектов.СобственнаяСсылка КАК СобственнаяСсылка,
СоответствиеОбъектов.СобственнаяСсылка.Код,
СУММА(СоответствиеОбъектов.КолВо) КАК КолВоДублей
ИЗ
СоответствиеОбъектов КАК СоответствиеОбъектов
ГДЕ
СоответствиеОбъектов.КолВо > 1

СГРУППИРОВАТЬ ПО
СоответствиеОбъектов.УзелОбмена,
СоответствиеОбъектов.СобственнаяСсылка,
СоответствиеОбъектов.СобственнаяСсылка.Код,
СоответствиеОбъектов.ТипЗначенияСобственнойСсылки

УПОРЯДОЧИТЬ ПО
УзелОбмена,
СобственнаяСсылка
ИТОГИ
СУММА(КолВоДублей)
ПО
УзелОбмена,
ТипЗначенияСобственнойСсылки

8. Анянов Михаил (insurgut) 24.12.13 21:19
(7) 3.14159, и что вы увидите этим запросом? :) Двойные записи для одного объекта? Их может и не быть.
9. Павел И. (3.14159) 24.12.13 21:20
10. Анянов Михаил (insurgut) 24.12.13 21:32
(9) 3.14159, уточню, если не ошибаюсь конечно, регистр Соответствие объектов для обмена заполняется либо при начальной настройке обмена (т.н. ПервыйОбмен = Истина), либо в случае, если поиск элемента происходит не только по внутреннему идентификатору, но и по полям поиска. Однако поиск соответствия по этому регистру происходит при загрузке всегда, несмотря на настройку поиска объекта, установленную в правилах обмена.

Если правила типовые, то для вновь создаваемых новых объектов данные в этот регистр уже записываться не будут, т.к. поиск у нас по внутреннему идентификатору происходит. Однако если мы вручную укажем сопоставление, то обработка обмена данными ее учтет при загрузке.
11. Павел И. (3.14159) 24.12.13 21:40
(10) insurgut, если правила написаны нормально, то можно смело грохнуть дубли, при следующем обмене соответствие запишется опять
12. Анянов Михаил (insurgut) 24.12.13 21:47
(11) 3.14159, понятное дело, если мы договариваемся с пользователем о полях поиска, и он у нас идеально заводит карточки номенклатуры, контрагентов, без ошибок, сто раз перепроверяя перед записью... Однако не всегда бывает все идеально - бардак не запрограммировать :)
13. Андрей Скуратов (skuratov_ab) 26.12.13 09:31
Господа! Позвольте подлить намного воды в диалог по поводу контроля обмена.
Во -первых. Обработка полезна.
Во-вторых, потеоретизирую на тему.
лично я с подобной проблемой столкнулся не только с контрагентами, а и с партнёрами в УТ11 - БП 2.0 и УТ11 и Розница 2.0. ( ну про партнёров в УТ 11 разговор отдельный. но и с номенклатурой. И если контрагентов пара тройка сотен, то номенклатуры под 20 000.
Какие возникают проблемы?
1. обмен бывает двухсторонний и односторонний. Если мы просто сливаем инфу из УТ в БП, то решение " много к одному" можно найти. Если есть обратная выгрузка ( например банковских платежей или кассы) то возникает проблема
" один ко многим" а её решить уже гораздо труднее.
В обмене же номенклатурой между УТ и РТ( розницей) желательна полная идентичность справочника номенклатура.
Теперь о проблемах в самом обмене и регистре "Соответствие обмена".
их можно выделить пять:
1. Уже упомянутая проблема "один ко многим" и "многие к одному".
2. просто дубляжи ( при первичной синхронизации ли, при одновременном заведении в двух базах, дубляж в одной базе и тираж на другую с обменом) Здесь автор как раз предлагает решение
3.Нет записи в регистре соответствия. Элемент справочника есть, а записи в регистре нет. Возникает, например при неудачной "ручной" чистке. Или при завале процесса синхронизации при обмене. Тут необходима обработка по элементам справочника и поиску записи в регистре и последующей принудительной выгрузкой незадействованных элементов. Естественно в случае необходимости.
4.Неправильное соответствие. Наиболее вероятно при любимом занятии менеджеров и прочих юзеров переименовывать Существующие карточки товаров. т.к. соответствие в регистре уже есть, и идентификаторы не изменились правила обмена могут пропустить данный кульбит и вы вместо спичек в одной базе будете иметь бульдозер в документах другой. Обмен вроде должен контролировать этот момент, но не факт. Особенно если обмен односторонний, а переименование в подчинённой базе. "Лечиться", во первых, жёстким контролем работы с карточками, а во-вторых... Я так понимаю нужно сравнение регистра соответствия из двух баз. Куда то вываливать и сравнивать. выводя расхождения.
5. Элемент удалён, запись в регистре осталась. По идее тестирование должно эту проблему решить.
Ну и последняя из мною выявленных проблем. Грамотное удаление объектов в обоих базах. Признак " объект не найден" в той или иной базе.
Подчеркну на последок. Это моё видение проблем и ошибок в обменах. Комплексных решений у меня пока нет. Одно из них нашёл автор данной обработки.

14. Тимофей Шантин (ShantinTD) 26.12.13 09:33
(12) insurgut, "бардак не запрограммировать :)" экая точная формулировка!
15. Анянов Михаил (insurgut) 26.12.13 09:40
(13) skuratov_ab, спасибо за столь развернутый комментарий. Действительно при использовании автоматических обменов (одно-, двусторонних) бывает много различных нюансов, и нет единственно правильного решения. Зачастую приходится контролировать какие-то моменты вручную.

Есть идея написания обработки сопоставления и настройки регистра соответствия объектов для обмена двух баз (через COM-соединение), как это умеют делать мастера первоначальных настроек обменов (например в БП 3.0), но с более развернутыми возможностями и для уже настроенных соответствий. Думаю было бы хорошим продолжением статьи :)
16. Павел И. (3.14159) 26.12.13 10:01
(13) skuratov_ab, а пункт 3 точно проблема?? по-моему, пункт 3 лишний
17. Анянов Михаил (insurgut) 26.12.13 10:05
(16) 3.14159, 3 пункт проблема, если используются свои правила, в которых поиск осуществляется по полям поиска... Хотя при следующей синхронизации и удачном поиске объекта запись соответствующая в регистр занесется обработкой обмена данными.
18. Павел И. (3.14159) 26.12.13 10:12
(17) insurgut, "кривые" правила - это проблема:) а пункт 3 - не проблема

если свои правила, то в КД есть Обработчик событий "Поля поиска"

Обработчики "Правила конвертации объектов"
Поля поиска
Условия возникновения события
Только для платформы V8.
Событие выполняется при поиске элемента ссылочного типа. Если установлен поиск по уникальнму идентификатору и программа нашла элемент, то поиск прекращается. Если поиск по уникальному идентификатору не дал положительного результата и указано, что нужно продолжить поиск в этом случае или поиск по уникальному идентификатору не проводился, то программа пытается найти элементы по свойствам поиска. В обработчике нужно установить список полей через запятую по которым нужно проводить поиск. Если очередная попытка дала положительный результат, то поиск прекращается.
Поиск возможен только по тем полям у которых на этапе выгрузка был установлен флаг поиска данных!!!

Параметры:
НомерВариантаПоиска - число. Номер попытки поиска. Попыток поиска может быть не больше 10.

т.е. возможно 10 попыток найти ссылку на объект в приемнике :)
19. Анянов Михаил (insurgut) 26.12.13 10:28
(18) 3.14159, я прекрасно знаю, что такое поля поиска, но только вот переход от поиска по идентификатору к полям поиска может вызвать определенные проблемы (связаны они с переименовываниями, изменениями кодов пользователями). Вот даже в случае ниже умудрялись появляться дубли (хотя вроде предусмотрели все, что можно), либо наоборот заменяться другие элементы справочников.

УстанавливатьУОбъектаВсеСвойстваПоиска = Истина;

//+27.06.2012 не допускаем дублей групп!
ЭтоГруппа = СвойстваПоиска.Получить("ЭтоГруппа");
Если ЭтоГруппа Тогда
	Если НомерВариантаПоиска = 1 Тогда
		СтрокаИменСвойствПоиска = "Наименование, Код, ЭтоГруппа";
	ИначеЕсли НомерВариантаПоиска = 2 Тогда
		СтрокаИменСвойствПоиска = "Наименование, ЭтоГруппа";
	КонецЕсли;
//-27.06.2012
Иначе
//+12.07.2012, добавим строгий поиск по ИНН+КПП+Наименование для контрагентов с одинаковым ИНН/КПП и разным наименованием
	Если ПараметрыОбъекта.Получить("ПоискПриОбменеПоНаименованию") = Истина Тогда
		СтрокаИменСвойствПоиска = "ИНН, КПП, Наименование,ЭтоГруппа";
	Иначе // иначе, ищем как обычно!
		Если НомерВариантаПоиска = 1 и ЗначениеЗаполнено(СвойстваПоиска["ИНН"]) Тогда
			СтрокаИменСвойствПоиска = "ИНН, КПП,ЭтоГруппа";
		ИначеЕсли НомерВариантаПоиска = 2 и значениезаполнено(СвойстваПоиска["ИНН"]) Тогда
			СтрокаИменСвойствПоиска = "ИНН, Наименование,ЭтоГруппа";
		//+09.07.2012, было:
		//ИначеЕсли НомерВариантаПоиска = 3 и значениезаполнено(СвойстваПоиска["ИНН"]) тогда
		//стало:
		ИначеЕсли НомерВариантаПоиска = 3 и значениезаполнено(СвойстваПоиска["ИНН"]) и СвойстваПоиска["ЮрФизЛицо"] = Перечисления.ЮрФизЛицо.ФизЛицо тогда
			СтрокаИменСвойствПоиска = "ИНН, ЮрФизЛицо,ЭтоГруппа";
		ИначеЕсли НомерВариантаПоиска = 4 и СвойстваПоиска["ЮрФизЛицо"] = Перечисления.ЮрФизЛицо.ФизЛицо тогда
		СтрокаИменСвойствПоиска = "Наименование, ЭтоГруппа";
		//Бухгалтер сказал, что у них очень много контрагентов с разным инн и одинаковым названием
		ИначеЕсли НомерВариантаПоиска = 5 Тогда
			СтрокаИменСвойствПоиска = "Наименование, Код, ЭтоГруппа";
		КонецЕсли;
	КонецЕсли;
КонецЕсли;
...Показать Скрыть


Поиск по реквизитам хорош для справочников-классификаторов например. Или для случая, когда данные заведенные раз ни при каких обстоятельствах не изменяются пользователями (по крайней мере поля поиска). Во всех остальных ситуациях его конечно лучше не допускать (оставшись лишь на поиске по идентификатору).
Но очень часто всплывают задачи настройки обменов между базами, учет и в первой и во второй в которых ведется уже давно. Тут конечно же поиск по идентификатору невозможен.
20. Павел И. (3.14159) 26.12.13 10:35
(19) insurgut, поиск по полям происходит после поиска по УИДу, если объект в приемнике не найден по УИД
21. Анянов Михаил (insurgut) 26.12.13 10:41
(20) 3.14159, можно и после, можно и вместо. Уточню - ситуации бывают различные. Одно дело когда у нас есть УТ и мы создаем первый обмен с базой БП (пустой). Другое дело - когда в БП уже ведется учет и нам необходимо настроить обмен с текущими данными. А бывают ситуации к примеру, когда есть 2 базы (вторая создана путем копирования первой с переименовыванием организации и других справочников), и нужно настроить выгрузку из этих баз в одну (назовем ее консолидированной). Как видите в последнем случае поиск по внутреннему идентификатору нужно уже исключать (иначе данные из одной программы будут перетираться данными другой).
22. Павел И. (3.14159) 26.12.13 11:04
А бывают ситуации к примеру, когда есть 2 базы (вторая создана путем копирования первой с переименовыванием организации и других справочников), и нужно настроить выгрузку из этих баз в одну (назовем ее консолидированной). Как видите в последнем случае поиск по внутреннему идентификатору нужно уже исключать (иначе данные из одной программы будут перетираться данными другой)


тогда это уже "свои" правила и каким боком тут РС Соответствия объектов для обмена, если не идет поиск по УИД?
23. Анянов Михаил (insurgut) 26.12.13 11:07
(22) 3.14159, как каким? Если по правилам успешно находится объект по полям поиска - соответствующая запись создается в регистре соответствия объектов для обмена, чтобы в следующий раз на поиск время не тратить.
24. Павел И. (3.14159) 26.12.13 11:09
(23) insurgut, в следующий раз в бардачной базе опять что-нибудь переименуют и опять будет "кривая" запись РС Соответствий обмена))

надо что-то менять в "консерватории"
25. Вера Белевич (integragirl) 27.12.13 08:04
У нас решено было ввести запрет для переименования контрагентов (в управляющей программе, в вашем случае в ут) для обычных пользователей, если есть движения по взаиморасчетам. Плюс при записи контрагента идет проверка уникальности связки ИНН + КПП.
С введением такого правила сильно пищали обычные пользователи, но потом смирились и теперь бардак в контрагентах сведен к минимому.
26. Андрей Скуратов (skuratov_ab) 27.12.13 08:21
(16) 3.14159, в данной теме затронута одна проблема обменов - задвоение. А часто возникает вторая - " объект не найден" пункт 3 относиться больше к данной проблеме. Я утверждать не могу. досконально не копался в этом ещё. Но возникает например с подчинёнными справочниками. Соответствие номенклатур есть, но почему то теряется соответствие единиц измерения. В результате, после обмена в принимающей базе по полям ед. измерений стоит " объект не найден"
27. Андрей Скуратов (skuratov_ab) 27.12.13 08:39
(16) 3.14159, к примеру, гибнет файл или пакет обмена с новыми элементами справочника. При этом в посылающей базе соответствие уже есть, а в принимающей не возникло. В дальнейшем обмен элементы справочников уже не выгружает. т.к видит соответствие у себя. а у принимающей стороны соотетствия нет - и является как раз " объект не найден". Тоже возникает при НЕ синхронной чистке баз. когда в одной элемент уже удалили и он соответственно ушёл и из регистра, а в другой этот элемент использовали в документе.
Хотя утверждать что именно пункт 3 виноват в этом не стану. Что эта проблема именно в отсутствии записи элемента в регистре соответствия одной и той же базе.
28. Павел И. (3.14159) 27.12.13 08:51
(26) skuratov_ab, РС Соответствие тут ни при чем. если
после обмена в принимающей базе по полям ед. измерений стоит " объект не найден"
, значит не передался сам объект ед.измерений, хотя ссылка на него в Номенклатуре есть

про
гибнет файл или пакет обмена с новыми элементами справочника
тоже не понял, есть же механизм "квитанции о приеме" при обменах. если <Объект не найден>, опять же есть у него УИД, что мешает его найти в базе-источнике и "ручками" поставить на обмен??
29. Андрей Скуратов (skuratov_ab) 27.12.13 08:51
Господа, а просветите по такому скользкому пункту. Когда я лазил по регистру соответствия, мне показалось что он состоит из 2 частей. "На вход" и " на выход". Т.е. "на выход" слева гуид данной базы, справа принимающей. а где-то ниже такое же соответствие, но наоборот. Гуид входящей - гуид текущей. В идеале, данные обеих строк должны быть идентичны. Я верно понял структуру регистра или мне показалось? Прошу прощения, конечно, у всех, тема реально одна из важнейших, но в данный момент нет возможности включиться в исследования
30. Павел И. (3.14159) 27.12.13 09:01
(27) skuratov_ab,
При этом в посылающей базе соответствие уже есть, а в принимающей не возникло. В дальнейшем обмен элементы справочников уже не выгружает. т.к видит соответствие у себя. а у принимающей стороны соотетствия нет - и является как раз " объект не найден".


в посылающей базе соответствия нету, пока обратно обмен не придет от приемника. пока подтверждения о приеме от источника не придет, тупо будет опять выгружаться при обмене. в принимающей стороне "объект не найден" - по причине отсутствия самого объекта - ссылка на обеъкт есть - а объекта нету. как в анекдоте по словарь русского языка - ".опа есть, а слова нету"
31. Андрей Скуратов (skuratov_ab) 27.12.13 09:03
(28) 3.14159, в принципе, ничего не мешает. признаю, в 8 опыт ещё не богатый. Хотя озвученные проблемы возникли и в восьмёрке. по опыту 7.7 когда на ТиС крутилось 60 магазинов, и соответственно в одном обмене уходило 60 пакетов искать "ручками" я Вас умоляю. когда одна УТ - одна розница или БП, можно конечно и каждую запись вылезать. Когда сеть... ну может я чего не догоняю... пардон, не бог и не создатель. Будем учиться и изучать.
Я постарался в своём большом посте озвучить круг проблем обмена с которыми реально столкнулся. С той целью, чтобы совместными усилиями создать инструментарий админов для контроля и управления обменом.
Естественно, одну две позиции единиц измерения можно вылечить перезаписав элемент в исходящей базе. он придёт и в принимающую. А если их сотня -другая по 5-6 базам, да и вылезают они только когда в документ попадают... Будем ручками править или доверять самой 1с исправлять?
32. Андрей Скуратов (skuratov_ab) 27.12.13 09:09
(30) 3.14159, Верите , ли сударь, не исправляется. Обмены гоняются, всё нормально проходит, а " объект не найден" как были так и остаются. Т.е. идеальные конструкции заложенные в саму программу не срабатывают. Вот такое противоречие книг-инструкций и опыта эксплуатации. Нужен инструментарий админа. А то что руки у меня кривые - и спору нет, кривые.
33. Павел И. (3.14159) 27.12.13 09:14
(31) skuratov_ab, если лень ручками искать и на обмен целиком все справочники нереально поставить (по причине объемов файла выгрузки в xml), пишутся "обработки" для поиска ссылок на <объект не найден>, из базы-приемника запись в текст УИДов (dbf,excel,xml - не важно), в базе-источнике - поиск объектов по УИД и регистрация в плане обмена

как искать <Объект не найден> в регистрах и справочниках - всем известно
34. Анянов Михаил (insurgut) 27.12.13 09:18
(26) skuratov_ab, проблема подчиненных элементов вообще очень больная. Настраивал правила обмена, вроде все красиво для единиц измерения прописано в правилах. И выгрузки тестовые делал все как надо. Но - когда объемы стали превышать тысячи карточек номенклатур при выгрузке за раз, начали непонятные вещи проскакивать в виде "Объект не найден" для единиц измерения номенклатуры.
Долго боролся, и правила менял, и поля поиска (поиск по GUID в принципе не подходил, т.к. 1 база обменивалась с 10-ью разными, в которых учет уже велся, и номенклатура могла заводится и там и там), проблема не решалась. В результате решение было найдено... В ПКО именно единиц измерения ставим галочку "Не запоминать выгруженные объекты". В результате объем выгрузки несколько возрастает, но сами объекты единиц измерения никуда не теряются.
Аналогично решилась проблема с договорами.
И опять же - вроде на начальном этапе все хорошо, и на небольших порциях, но когда на обмен летят огромные порции, и поиск осуществляется не только по GUID, но и по полям поиска - начинают всплывать подводные камни.
35. Павел И. (3.14159) 27.12.13 09:21
(32) skuratov_ab, согласитесь, что у вас "объект не найден" - это единичные случаи в результате каких-то сбоев. если нет, то нужно в первую очередь смотреть механизмы регистрации объектов в планах обмена, тем более если не РИБ, а через com-соединение и по правилам обмена, возможно это "косяки" в правилах или в коде
36. Анянов Михаил (insurgut) 27.12.13 09:24
(33) 3.14159, кстати нередко подобного рода ошибки возникают при совместной доработке конфигурации группой программистов. Очень часто программисты просто не знают технологии обменов (ну допустим он специализируется на написании отчетов/обработок и никогда не разбирались в обменах в принципе) и в проверках перед записью не ставят "загрушки" в виде:
Если ОбменДанными.Загрузка = Истина Тогда
Возврат;
КонецЕсли;
37. Андрей Скуратов (skuratov_ab) 27.12.13 09:32
(35) 3.14159, Да я согласен, что единичный, если у меня по номенклатуре 20000 позиций и из них кривых 15 - 20, в 3-4 разных базах, то конечно это единичный случай, но когда в самый неподходящий момент раздаётся визг или писк оператора или манайгера, что .... и надо срочно это исправить, то тогда извините е....вашу ..ть на всю эту конструкцию. Дело не в количестве. проблема есть, надо решать.
38. Павел И. (3.14159) 27.12.13 09:47
(37) skuratov_ab, писал недавно "инструментарий" для сравнения ссылочных типов данных между базами РИБ через xml - отмечаются выбранные объекты метаданных (из состава выбранного плана обмена), выгружаются в xml. В базе-источнике ищется по УИД. Справочники, документы ищутся по ссылкам на наличие/отсутствие (сравнение по содержимому справочников и документов пока не допиливал), регистры накопления/сведений сравниваются наборами записей с отбором по всем возможным измерениям

все "различия" можно зарегистрировать по выбранному плану обмена. Обработка получилась универсальной,работает на стороне главного и на стороне подчиненного узла

как будет время и желание, оформлю в виде статьи
39. Андрей Скуратов (skuratov_ab) 27.12.13 10:02
(38) 3.14159, Во, это дело! Риба нет пока, но будет. Готов буду оттестировать
40. Анянов Михаил (insurgut) 27.12.13 10:24
(38) 3.14159, не забудьте в статье описать о вреде полных прав пользователей, когда они любят запускать обработки поиска и удаления помеченных объектов... Ведь база убаленная РИБ может обмениваться только по одной организации, и не иметь множества документов, которые будут ссылаться на помеченную на удаление допустим номенклатуру. В результате удаления (с контролем как положено) в этой удаленной базе удаляться элементы, ссылки на которые есть в центральной базе. И мы легко от таких действий пользователей получим "Объект не найден", т.к. в центральной базе объект будет удален обменом без контроля ссылочной целостности.
41. Павел И. (3.14159) 27.12.13 10:30
(40) insurgut, про вред полных прав писать не буду :) обработка только ищет разницу и регистрирует объекты в плане обмена

"гранаты" пользователям с большим радиусом кривизны рук и удаление документов в главной при обмене с периферийной базой - это другое
42. Анянов Михаил (insurgut) 27.12.13 10:39
(41) 3.14159, ясно :) Увы, многие имея обмены по риб даже и представления не имеют, что ссылочная целостность в периферийной базе и в центральной - две большие разницы, и уж тем более если периферийная только по определенной организации/подразделению/складу обменивается.
Хорошо бухгалтер там... но многие "программисты" не раз обращались с проблемой, и все говорили ничего не делали, а объекты пропали. Благо журнал регистрации никогда не врет, ну и бэкапы были, они и спасали :)
43. Павел И. (3.14159) 27.12.13 11:00
(42) insurgut, удаление объекта в "приемнике" при обмене в журнал регистрации не пишется), в журнале регистрации можно поискать только в "источнике"
44. Анянов Михаил (insurgut) 27.12.13 11:17
(43) 3.14159, в базе А (центральная) имею кучу "Объект не найден" в справочнике Номенклатуры, открываю журнал регистрации, делаю отбор только по удалению, вижу, что Автообмен (имя пользователя, под которым обмен проходит) удалил элементы справочника допустим 27.12.2013 в 13:00...
Перехожу в базу Б (периферийная), открываю журнал регистрации, делаю отбор только по удалению, вижу пользователь Иванов сделал удаление объектов 27.12.2013 в 12:15 (позже выясняется, что он запускал обработку удаления помеченных объектов).

Не до конца понятно, что не пишется в журнал регистрации?
45. Павел И. (3.14159) 27.12.13 11:55
(44) insurgut, если база РИБ, то при обмене при удалении объекта в базе-"приемнике" событие в ЖР не пишется. В вашем случае у вас не РИБ, а универсальный обмен данными, хотя в (42) вы про РИБ писали. РИБ и универсальный обмен данными - это не одно и то же.
46. Анянов Михаил (insurgut) 27.12.13 13:45
(45) 3.14159, может у вас настройки журнала специфические для уменьшения объема? Специально удалил пару внешних обработок в центральной базе. Прогнал обмен (РИБ) - в периферийной базе в журнале имею:
Данные. Удаление Зафиксирована 27.12.2013 15:29:30 (1100911829) Справочник. Внешние обработки <Объект не найден> (30:842d003048d961b811e2b0b22d37bbbb)
47. Андрей Скуратов (skuratov_ab) 27.12.13 13:54
В данном споре соглашусь с insurgut. вот именно так и бывает. И в журнал именно это и пишется. Уже и по 8 такие расследования вёл с жестокой покрой любителей " навести порядок в базе"
48. Павел И. (3.14159) 27.12.13 15:38
(46) insurgut, какая у вас конфигурация?

49. Павел И. (3.14159) 27.12.13 18:13
(46) insurgut, вы правы! событие в ЖР при удалении объектов при обмене пишется
50. Сергей (Che) Коцюра (CheBurator) 27.12.13 21:47
фигня какая-то.
у себя сделал просто.
при записи нового контрагента - всегда проверка на уникальность ИНН\КПП.
полный и безоговорочный запрет на создание контрагентов с незаполненым ИНН\КПП.
в резудтате проблема практически исчезла.
51. Анянов Михаил (insurgut) 28.12.13 21:21
(50) CheBurator, увы, но в реалиях нашего региона - у разных контрагентов могут быть одинаковые ИНН/КПП :)