Кратко: Обработка отбирает документы "Перемещения товаров" в одной базе, подключатеся через COM-соединение к другой базе и сравнивает их по нескольким реквизитам. Если находит различие - ругается и выдает списко "кривых" или "подозрительных" документов.
Переделать эту обработку под другой вид документов - минутное дело, изменить список сравниваемых параметров документов - тоже.
Теперь разверутый пример из жизни
Предмет: организация использует на главном складе совместно конфигурации "Управление торговлей 10.3" и "Розница 1.0". Розница в свою очередь является центральной базой РИБ. Товар приходуется, назначаются цены, формируются перемещения в УТ, потом данные выгружаются в центральный узел Розницы, потом обмен с удаленными розничными точками. Розничные точки могут в свою очередь тоже формировать перемещения между собой.
Проблема: при такой сложной схеме неизбежно возникает ситуация, когда остатки в базах не совпадают вследствие того что криворукие и не очень пользователи правят документы не той в базе, где они были созданы, а в конечных базах. И не только поэтому. Заведующий склада ставит задачу: "Выровнять остатки и предусмотреть возможность быстого находжения отличающихся между собой документов".
Описание самой обработки
В конфигурациях УТ и Розница есть регистр сведений "Соответствие объектов для обмена". Он содержит соответствие между ссылками на объекты (документы, справочники и пр.) в текущей базе (например УТ) и во внешней базе, с которой он обменивается (Розница). Соответствие хранится в виде ссылок GUID на объекты. GUID (уникальный идентификатор) представляет из себя случайный набор символов (букв и цифр) типа "0ce964df-1351-c11e-:a6b-cf7387ca0737"
Это полбеды. Разработчики зачем-то (видимо чтобы никто не догадался:)) части этого GUID в регистре перемешали, перставили местами и добавили еще кучу служебных символов. Поэтому просто вытащить ссылку из регистра не получится, нужно расшифровывать.
В обработке формируется запрос в этот регистр по документам "ПермещениеТоваров" (с отбором по интервалу дат) и получаются уже "выпрямленные" ссылки на эти же документы в другой базе (в Рознице в нашем случае). Помимо ссылок получаем данные документов для сравнения: номер, дату, статус проведения, склад-отправитель, склад-получатель.
Коннектимся к другой базе (для использования обработки под 8.1 достаточно в этой строке заменить "V82.COMConnector" на "V81.COMConnector"):
cntr = Новый COMObject("V82.COMConnector");
connection = cntr.Connect("File="""+СтрокаПодключения+""";Usr="""+Пользователь+""";");
Перебираем в цикле результат запроса с GUID документов в другой базе, и сравниваем документы по необходимым параметрам (фрагмент):
Если Не Выборка.СкладОтправитель.Код = connection.Документы.ПеремещениеТоваров.ПолучитьСсылку(connection.NewObject("УникальныйИдентификатор",Строка(ГУИД))).СкладОтправитель.Код Тогда
Сообщить ("Отличается Склад-отправитель перемещения №"+Выборка.Номер+ " от " + Выборка.Дата);
КонецЕсли;
При желании можно доработать под любые документы, сравнивать по разным параметрам. Данные в регистре "Соответствие объектов для обмена" в УТ и Рознице шифруются чуть по разному, поэтому в начале прверяется из метаданных версия конфигурации и менятеся тип запроса (если нужно запустить из Ут в Розницу - один запрос, а если из Розницы в УТ - чуть другой)
Также можно доработать и не только сравнивать данные, но и изменять их.
По подобию этой обработки были написаны обработки, которые "вытаскивали" артикул из базы УТ и присваивали его номенклатуре в базе Бухгалтерии (когда-то, до релиза 2.0.25 в типовой бухглатерии реквизита "артикул" не было вообще... ). Или унифицировали коды номенклатуры между базами Ут и Розницы: в типовых правилах обмена между этими конфигруациями нет поля "Код" в номенклатуре и поэтому при одна и та же номенклатура в разных базах имеет разный код - очень неудобно.
