Сравнение объектов в JavaScript. Механизм сопоставления данных при обмене через универсальный формат Варианты идентификации объектов при получении

Печать (Ctrl+P)

Механизм сопоставления данных при обмене через универсальный формат

Механизм сопоставления данных предназначен для решения задачи синхронизации данных между базой источника и базой приемника при обмене

Внутренние идентификаторы объектов

В идеальном случае данные синхронизируемых приложений могли бы сопоставляться по уникальным внутренним идентификаторам объектов (GUID). Но для этого необходимо, чтобы добавление данных, подлежащих синхронизации, осуществлялся только в одном приложении, а в другом эти данные появлялись исключительно в результате синхронизации. В этом случае GUID в двух приложениях у одинаковых объектов будут одинаковыми, и по ним можно будет однозначно сопоставить объекты.

На практике соблюдать данное требование не всегда возможно, особенно в случае настройки синхронизации между приложениями, работа в которых велась независимо. Это связано с тем, что у двух одинаковых объектов, созданных параллельно в каждом приложении, будет два разных GUID.

В некоторых случаях данные не могут быть сопоставлены по GUID по причине его отсутствия (особые случаи, которые не рассматриваются в данной статье).

Публичные идентификаторы объектов

Для успешного сопоставления объектов с разными GUID должно быть место для хранения информация об их соответствии. Таким местом является регистр сведений Публичные идентификаторы синхронизируемых объектов (далее РПИ ).

Рис. 1 Регистр сведений Публичные идентификаторы синхронизируемых объектов

Структура регистра представлена в таблице:

Для сопоставления данных двух программ предназначена в БСП 2.3 обработка “Сопоставление объектов информационных баз” для непосредственного использования при синхронизации данных

Рис 2. Основная форма обработки “Сопоставление объектов информационных баз”

Список открывается по команде Выполнить сопоставление на странице Сопоставление данных Помощника интерактивной синхронизации данных. Также можно дважды щелкнуть мышью по строке, в которой обнаружены проблемы сопоставления данных.

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

В поле Выводить можно выбрать, какие данные показывать в списке. По умолчанию выводятся Несопоставленные данные .

Сопоставление объектов

Нажмите Сопоставить автоматически (рекомендуется), выберите поля для сопоставления с помощью флажков. Некоторые поля выбраны программой по умолчанию. Для того чтобы подтвердить свой выбор, нажмите Выполнить сопоставление . После поиска программа выводит на просмотр сопоставленные ею данные. Для подтверждения нажмите Применить .
После автоматического сопоставления можно оставшиеся объекты сопоставить вручную или изменить сопоставление объектов. Выделите нужные объекты двух баз, нажмите Отменить соответствие , для того чтобы попытаться сопоставить объекты вручную, нажмите Установить соответствие для того чтобы сопоставить объекты.
Для подтверждения нажмите Записать и закрыть .

Настройка полей таблицы сопоставления

Нажмите Колонки , чтобы добавить поля в колонки списка. С помощью флажков можно отметить дополнительные поля, для подтверждения нажмите Применить .

Получение данных из другой программы

Порядок сопоставления объектов

Рекомендуется выполнять сопоставление и загрузку данных с учетом ссылочных связей. Особенно, если поле используется для сопоставления объектов.
Например, в конфигурации имеется справочник договоров контрагентов, который подчинен справочнику контрагентов. Сопоставление договоров контрагентов выполняется по справочнику-владельцу, т.е. по справочнику контрагентов. Следовательно, для правильного сопоставления данных необходимо сначала сопоставить и загрузить справочник контрагентов, а затем – справочник договоров контрагентов.
В противном случае поля таблицы сопоставления могут содержать фиктивные ссылки вида:
<Объект не найден> (26:a0b9001b24e002fe11dfba347dd41412).
Фиктивная ссылка указывает на объект в текущей информационной базе, который еще не был загружен из сообщения обмена.

Записи в РПИ создаются и на стороне отправителя при подтверждении получения данных корреспондентом через механизм квитирования. В поле Идентификатор в таких записях устанавливается исходный идентификатор объекта. Регистрация таких записей необходима для того, чтобы при получении других данных от корреспондента можно было понимать, что данный объект должен быть исключен из процедуры поиска по полям и по уникальному идентификатору.

Варианты идентификации объектов при получении

Порядок автоматического сопоставления объектов при получении, содержится в правилах конвертации объектов (ПКО), предназначенных для получения данных. Правила ПКО находятся в общем модуле

Рис 3 Разделы общего модуля МенеджерОбменаЧерезУниверсальныйФормат

Отметим, что в общем модуле МенеджерОбменаЧерезУниверсальныйФормат находятся все компоненты (правила обработки данных, правила конвертации объектов и т.д.), определяющие прикладную логику обработки данных в процессе их получения, либо отправки. Программный код этого модуля создается автоматически с помощью приложения “Конвертация данных, редакция 3.0” на основе настроенных правил обмена. Программный код модуля можно создавать вручную, но требует от разработчика большого мастерства.

Вариант автоматического сопоставления (идентификации) объектов при получении задается с помощью свойства ВариантИдентификации ПКО

Рис 4. Настройки идентификации в модуле менеджера

Существуют 3 варианта (3 значения) идентификации объекта

ПоУникальномуИдентификатору – идентификация по GUID,
СначалаПоУникальномуИдентификаторуПотомПоПолямПоиска – идентификация по GUID и полям поиска,
ПоПолямПоиска – идентификация по полям поиска,

Еще одним свойством, определяющим логику сопоставления, является массив полей поиска, определяемый в свойстве ПоляПоиска ПКО.

Алгоритм поиска по полям

Происходит последовательное применение вариантов поиска, заданных в свойстве ПоляПоиска ПКО, используемого при загрузке объекта.

Ограничение.
При сопоставлении на этапе анализа данных применяется только 1-й вариант поиска – ПоУникальномуИдентификатору

Переход к следующему варианту осуществляется в двух случаях:

У загружаемого объекта не заполнено какое-либо из полей, которое указано в варианте поиска.
Вариант поиска не дал результата.

Если в загружаемом объекте есть информация об исходном GUID и вариант идентификации для объекта “По GUID” или “По GUID и полям поиска”, то поиск выполняется среди всех объектов заданного типа, кроме тех, для которых в РПИ уже установлены соответствия.

В остальных случаях поиск осуществляется среди всех объектов информационной базы соответствующего типа.

Особенности.
При сопоставлении на этапе анализа данных у загружаемых объектов не проверяется заполнение полей, участвующих в поиске.

На этапе анализа данных соответствие будет установлено только в том случае, когда для одного объекта отправителя был найден один объект получателя.

На этапе загрузки данных соответствие будет установлено и в том случае, когда для одного объекта отправителя нашлось несколько объектов получателя. В такой ситуации соответствие будет установлено с одним из них.

На этапе загрузки данных вариант поиска Номер + Дата для документов работает следующим образом: номер искомого документа проверяется на точное соответствие, дата определяет интервал, в котором проводится поиск по номеру. Сам интервал определяется как период уникальности номеров документа, в который входит указанная дата. Например, если номера документов уникальны в пределах месяца и задана дата 10 декабря 2001 года, то поиск будет проводиться в интервале с 01 по 31 декабря 2001 года.
На этапе анализа данных этот вариант поиска будет работать как обычно: оба поля будут проверяться на точное соответствие.

Вот мое прокомментированное решение в ES3 (подробности после кода):

Object.equals = function(x, y) { if (x === y) return true; // if both x and y are null or undefined and exactly the same if (! (x instanceof Object) || ! (y instanceof Object)) return false; // if they are not strictly equal, they both need to be Objects if (x.constructor !== y.constructor) return false; // they must have the exact same prototype chain, the closest we can do is // test there constructor. for (var p in x) { if (! x.hasOwnProperty(p)) continue; // other properties were tested using x.constructor === y.constructor if (! y.hasOwnProperty(p)) return false; // allows to compare x[ p ] and y[ p ] when set to undefined if (x[ p ] === y[ p ]) continue; // if they have the same strict value or identity then they are equal if (typeof(x[ p ]) !== "object") return false; // Numbers, Strings, Functions, Booleans must be strictly equal if (! Object.equals(x[ p ], y[ p ])) return false; // Objects and Arrays must be tested recursively } for (p in y) { if (y.hasOwnProperty(p) && ! x.hasOwnProperty(p)) return false; // allows x[ p ] to be set to undefined } return true; }

Разрабатывая это решение, я особенно внимательно посмотрел на угловые случаи, эффективность, но пытаясь дать простое решение, которое работает, надеюсь, с некоторой элегантностью. JavaScript допускает, что у нулевых и неопределенных свойств и объектов есть прототипы, которые могут привести к очень разному поведению, если не проверены.

Сначала я решил расширить Object вместо Object.prototype , главным образом потому, что null не может быть одним из объектов сравнения и что я считаю, что null должен быть действительным объектом для сравнения с другим. Есть и другие законные проблемы, отмеченные другими в отношении расширения Object.prototype относительно возможных побочных эффектов для другого кода.

Необходимо проявлять особую осторожность, чтобы разрешить JavaScript, чтобы свойства объекта могли быть установлены как неопределенные , т.е. Существуют свойства, значения которых установлены как неопределенные . Вышеприведенное решение подтверждает, что оба объекта имеют одинаковые свойства, которые не определены для сообщения о равенстве. Это может быть достигнуто только путем проверки существования свойств с использованием Object.hasOwnProperty(property_name) . Также обратите внимание, что JSON.stringify() удаляет свойства, которые установлены как неопределенные , и поэтому сравнения с использованием этой формы будут игнорировать свойства, установленные для значения undefined .

Функции должны считаться равными, только если они используют одну и ту же ссылку, а не только тот же код, потому что это не будет учитывать прототип этих функций. Поэтому сравнение строки кода не работает, чтобы гарантировать, что у них есть один и тот же объект-прототип.

Оба объекта должны иметь одну и ту же цепочку прототипов , а не одни и те же свойства. Это может быть проверено только кросс-браузером, сравнивая конструктор обоих объектов для строгого равенства. ECMAScript 5 позволит проверить их фактический прототип с помощью Object.getPrototypeOf() . Некоторые веб-браузеры также предлагают свойство __proto__, которое делает то же самое. Возможное улучшение вышеуказанного кода позволит использовать один из этих методов всякий раз, когда это возможно.

Использование строгих сравнений здесь имеет первостепенное значение, потому что 2 не следует считать равным "2.0000" , а false должно считаться равным нулю , неопределенным или 0 .

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

Не более двух циклов требуется, первый для проверки свойств из левого объекта, второй для проверки свойств справа и проверки только существования (не значения), чтобы поймать эти свойства, которые определены с неопределенным значением.

В целом этот код обрабатывает большинство угловых случаев только в 16 строках кода (без комментариев).

Обновление (8/13/2015) . Я реализовал более эффективную версию, так как функция value_equals() работает быстрее, обрабатывает правильные угловые случаи, такие как NaN и 0, отличные от -0, необязательно применяя порядок и тестирование свойств объектов для циклических ссылок, поддерживаемых более чем 100 автоматическими тесты как часть тестового набора проектов

Когда правила конвертации свойств и значений созданы, можно указать принципы сопоставления (поиска) объектов по их свойствам. Если говорить упрощенно, то пока мы умеем сообщать системе какой тип в какой должен преобразовываться. Например, документ "Реализация товаров и услуг" в источнике должен преобразовываться в документ "Реализация товаров и услуг" в приемнике. Но пока не знаем как системе сообщить, что документ в источнике "Реализация товаров и услуг" c номером 0001 и датой 01.01.2008 должен заменять документ в приемнике "Реализация товаров и услуг" с тем же номером.

Нам нужно сообщить программе принципы поиска соответствующих объектов в приемнике. Это делается очень просто. Для свойств, по которым необходимо производить поиск объектов для их изменения, необходимо установить флажок поиск в соответствующем правиле конвертации свойств. Это можно сделать самостоятельно для каждого типа объектов. Если поиск установлен по нескольким реквизитам, то в информационной базе приемнике объект будет искаться на совпадение всем реквизитам объекта источника (то есть условия поиска объединяются логической операцией "И").

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

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

При нажатии на кнопку "Установить правила поиска" программа установит поиск по выбранным свойствам.

Если все необходимые правила конвертации объектов, свойств и значений созданы, установлены поля поиска объектов, то практически все готово к тому, что бы воспользоваться правилами и выполнить обмен данными между информационными базами.

Сопоставление объектов в конфигурациях на базе конфигурации "Библиотека стандартных подсистем" (БСП).

Сопоставление объектов в обменивающихся конфигурациях на базе БСП имеет свои особенности. Для сопоставления объектов используется специальный инструмент – помощник интерактивного обмена данными, который позволяет выполнять сопоставление в автоматическом, полуавтоматическом и в ручном режиме.
Поля поиска влияют на отображение полей в таблице сопоставления объектов в помощнике интерактивного обмена данными – порядок полей в таблице сопоставления помощника совпадает с порядком полей поиска в правиле конвертации объектов. Отдельно следует отметить тот факт, что в таблице сопоставления помощника одновременно может быть отображено не более пяти полей. Отсюда рекомендация – количество полей поиска следует задавать не большим пяти.
В режиме автоматического сопоставления объектов система сначала выполняет сопоставление по уникальным идентификаторам ссылок. Для объектов, для которых сопоставление по уникальным идентификаторам не дало положительного результата, выполняется сопоставление по всем полям поиска, которые указаны в правиле конвертации.
В полуавтоматическом режиме сопоставления объектов, пользователь может изменять набор полей сопоставления.

С уважением, Владимир Милькин (преподаватель и разработчик ).

Сопоставление объектов в карбонатных коллекторах с объектами терригенного девона дает возможность сказать, что разработка первых ведется более высокими темпами. Темпы разработки по объектам карбонатного девона не отличаются от объектов карбонатных отложений среднекаменноугольной системы.
Сопоставление объектов экологической экспертизы на федеральном уровне и уровне субъекта Российской Федерации представлены в табл. 8.1. Анализ этой таблицы показывает, что объекты экологической экспертизы на федеральном уровне и уровне субъекта Российской Федерации в пределах своей компетенции похожи. Однако ряд объектов экологической экспертизы присутствует только на федеральном уровне.
Первая цель вызовет сопоставление объектов X в Y, и, если X и Y солоставямы, возможно, приведет к конкретизации каких-либо переменных в этих объектах.
Назовем среди изучаемых приемов и сопоставление объекта и фона по тональному контрасту: контраст тонов помогает выявлению главного объекта изображения. Фото 5 показывает нам, как отчетливо рисуется освещенный, переданный светлыми тонами объект на темном, неосвещенном фоне.
Эта формула может быть рекомендована при сопоставлении объекта изобретения с имеющимися аналогами.
Принятый в большинстве стран метод квалификации нарушений основывается на сопоставлении объекта с патентной формулой изобретения, толкуемой с учетом оценки значимости указанных в ней признаков, а также охвата ею эквивалентов.
В последнем случае может понадобиться нормировка переменных, так чтобы сопоставление объектов включало псевдооднородный набор данных и было до некоторой степени облегчено. Для реализации этого возможны различные преобразования.
Кроме того, такой выбор L оказывается за рамками геометрического подобия сред для сопоставления объектов.
Часто процессы селекции и симплификации осуществляются параллельно. Им предшествуют классификация, ранжирование объектов и специальный анализ перспективности и сопоставления объектов с будущими потребностями.
Процессы селекции и симплификации осуществляются параллельно. Им предшествуют классификация и ранжирование объектов и специальный анализ перспективности и сопоставления объектов с будущими потребностями. Так, при разработке первого ГОСТа на алюминиевую штампованную посуду были классифицированы по вместимости выпускаемые в тот период кастрюли. Анализ показал, что номенклатуру можно сократить до 22 типоразмеров, исключив дублирующие емкости.
Автомат Мили с асинхронными выходами. Оба вида содержат в своем теле набор последовательных операторов, которые задают совокупность действий, исполняемых после вызова этой подпрограммы. Процедура возвращает результаты либо путем непосредственного преобразования объектов, определенных в вызывающей программе (глобальных сигналов или переменных), либо за счет сопоставления объектов через список соответствий. Функция же определяет единственное значение, используемое в выражениях, в которые включен вызов этой функции.
Коэффициенты регрессии (см. главу 5), выражающие степень влияния отдельных геолого-промысловых факторов на нефтеотдачу, могут быть использованы для сравнительной оценки эффективности процесса вытеснения нефти на исследованных объектах и сходных с ними по геологическому строению. При этом все факторы, действующие на нефтеотдачу, следует разделить на две группы: природные, отражающие объективные возможности залежи, и технологические, отражающие особенности систем и методов регулирования разработки. Из-за преобладающего влияния природных факторов на нефтеотдачу оценить влияние технологических факторов на нее затруднительно. В связи с этим можно предположить, что методические трудности, возникающие при изучении влияния технологических факторов на эффективность разработки, были бы значительно уменьшены, если бы при сопоставлении объектов разработки удалось каким-либо образом исключить суммарное влияние природных факторов.
Кривые ответов испытуемого в исследовании влияния контекста. По горизонтали. А - соответствующий контекст. N - нет контекста. Is - несоответствующий контекст, сходный объект. и 1Ь - несоответствующий контекст, непохожий объект. Адаптировано из. Ru-melhart 1977 по данным Palmer (1975bj.
В нашем случае с распознаванием паттернов человеком эталон - это некоторая внутренняя структура, которая при ее сопоставлении с сенсорными стимулами позволяет опознать объект. Согласно такому представлению о распознавании, в процессе приобретения жизненного опыта у нас образуется огромное количество эталонов, каждый из которых связан с некоторым значением. Так, зрительное опознание формы, например, геометрической фигуры, происходит следующим образом: световая энергия, исходящая от этой фигуры, воздействует на сетчатку глаза и преобразуется в нервную энергию, которая передается в мозг. Осуществляется поиск среди имеющихся эталонов. Если находится эталон, который соответствует нервному паттерну, человек опознает этот паттерн. После сопоставления объекта с его эталоном может происходить дальнейшая обработка информации и интерпретация объекта.
Сами алгоритмы удаления невидимых линий и поверхностей до сих пор не оптимальны, в каждом из них имеются недостатки, неэффективно реализованные элементы и ошибки. Однако основные качества этих алгоритмов могут быть со временем обобщены единым пониманием сущности процесса удаления невидимых поверхностей. В обоих алгоритмах исследуются области экрана, выбираются объекты, размещенные в этих областях; затем для определения видимых объектов все объекты внутри каждой области сортируются по глубине. Используются различные методы сортировки: в алгоритме Уоткинса объекты сортируются по координате Y на 1024 группы, затем производится сортировка (методом пузырька) отрезков по координате X и, наконец, поэлементное сравнение глубины объектов внутри интервала для установления видимости. В алгоритме Варнока сортировка объектов по значениям координат X и Y выполняется с помощью блока просмотра с очень сложной процедурой сопоставления объектов и областей экрана; объекты внутри области сортируются по глубине поэлементным сравнением. В алгоритме используется сортировка по составному признаку с основанием 41) по координатам X и - У; при разделении области все объекты, имеющие пересечение с этой областью, сортируются в одной или нескольких из четырех меньших областей. X и Y, сортировка по составному признаку на 1024 группы и сортировка отрезков методом пузырька на сканирующей линии) выполняется быстрее. Из этих замечаний следует, что неотъемлемой частью удаления невидимых линий является сортировка объектов по координатам X, Y и Z, поэтому для разработки эффективных алгоритмов необходимо исследование различных приемов и методов сортировки.
Но и этот единичный пример демонстрирует нам несколько приемов, с помощью которых фотограф получает в кадре желаемый акцент. Подведем итог, перечислив эти приемы. Отдадим должное также правильному выбору крупности плана, масштаба изображения фигур и предметов, образующих смысловой центр картины. Назовем еще правильное сопоставление объекта и фона по степени резкости и, наконец, важнейшее акцентирующее средство - свет, световой рисунок кадра.
Аналог в случае выполнения процедуры определения потребности проектирования к моменту составления технического задания уже определен. Если же эта процедура не выполнилась, то следует обратиться к базе данных по существующим образцам в соответствующей области техники. Основой для выбора аналога помимо функционального назначения служит главный параметр. Под ним понимается показатель от величины которого зависит наибольшее число других основных параметров. Так, для одноковшового экскаватора главным параметром считается вместимость ковша. При наличии нескольких аналогов для сравнения выбирается лучший из них по комплексному обобщенному показателю. Если же аналога нет, то сопоставление объекта проектирования ведется по показателям качества перспективного образца. Под перспективным образцом понимается параметрическое и структурное описание наиболее вероятного варианта машины, составленное на основе сценария развития объектов в данной области техники.

Принципы сопоставления объектов при обмене данными 1С

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

Рассматривать решение поставленной задачи для наглядности будем на примере переноса данных из программы 1С Комплексная автоматизация в 1С Бухгалтерия 8 (КА 1.1 => БП 3.0 ) с использованием правил переноса, созданных по технологии Конвертации данных 2.0 . Все сказанное относится к любым правилам переноса, написанным по указанной технологии.

Начну с пояснения того, можно ли решить рассматриваемую проблему в рамках типовых конфигураций с использованием обработки УниверсальныйОбменДаннымиXML . Нет, нельзя. Эта обработка не обладает функциональными возможностями сопоставления объектов различных информационных баз.

Поэтому мы будем рассматривать обработку максимально похожую по функционалу, позволяющую загрузить данные из файла, сформированного предварительно в базе-источнике с помощью все той же обработки УниверсальныйОбменДаннымиXML , но позволяющую перед загрузкой просмотреть и при необходимости отредактировать соответствия объектов двух баз.

Сразу об ограничениях. Соответствие объектов - это пара уникальных идентификаторов (УИД) объекта источника и объекта приемника (если таковой имеется). Поэтому задать соответствие можно только для тех объектов, у которых в файле загрузки есть уникальные идентификаторы, т.е. для тех объектов, для которых правилами синхронизации задан поиск с использованием УИД. Это не значит, что при этом невозможен поиск по реквизитам. Это значит, что заданный правилом обмена поиск объекта осуществляется либо только по УИД, либо сначала по УИД, а затем по реквизитам. Если поиск осуществляется только по реквизитам, то в файле загрузки УИД отсутствует. Для таких объектов сопоставление невозможно.

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

Рис.1 Документ выгружаемый из источника

Обработка для загрузки Перенос_данных_с_сопоставлением_УФ_v1_1.epf имеет по сравнению с типовой обработкой две дополнительные закладки: Типы данных сопоставления и Сопоставление данных . На первой из них необходимо отметить те типы данных, которые будут участвовать в сопоставлении объектов. Это вспомогательный сервис, повышающий удобство пользования, чтобы не интересующие нас данные не отражались в окне соответствий. В нашем случае мы будем работать пока только с номенклатурой, поэтому отметим только этот тип метаданных (см. рис.2).

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

Рис.2 Отметка типов метаданных для сопоставления

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

Рис.3 Пример таблицы соответствий объектов

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

Если мы сейчас выберем команду Загрузить данные , то произойдет заполнение базы приемника. Но результат ничем (почти ничем, об этом "почти" расскажу ниже) не будет отличаться от типовой загрузки, поскольку соответствия установлены автоматически и не изменены.

Теперь создадим в приемнике еще один элемент справочника Номенклатура с наименованием Телевизор JVC (без кавычек) и отредактируем таблицу соответствий: установим загружаемому объекту Наименование=Телевизор "JVC"... в соответствие этот новый элемент. Т.е. мы осуществили подмену объекта приемника, найденного правилами конвертации, другим объектом. То же самое можно было сделать например для элемента Телевизор "SHARP" : выбрать существующий элемент и поставить его в соответствие загружаемому объекту. Теперь загрузим данные и посмотрим на результат (см. рис.4).

Рис.4. Результат загрузки данных с ручным сопоставлением объектов

Как видим, в документе присутствует элемент справочника, который мы поставили в соответствие вручную. Напоминаю, я изменил соответствие перед загрузкой. Для наглядности на рис. 4 показано, что в справочнике есть два похожих по наименованию элемента, оба были созданы в приемнике вручную. Элемент Телевизор "SHARP" появился в результате переноса. Причем, этот новый элемент находится в папке Бытовая техника , точно как в источнике и точно по правилам синхронизации.

А вот теперь обещанное выше пояснение "почти". Обратите внимание на колонку Зам (Замещать свойства объекта, существующего в базе, свойствами загружаемого объекта). Галочки в ней нет, значит свойства объекта приемника не будут перезаписаны, что и произошло. Если галочку установить и вновь загрузить данные, Телевизор JVC переместится в папку Бытовая техника , но и наименование у него поменяется на Телевизор "JVC" (наименование это ведь тоже свойство). Надеюсь этого достаточно для пояснения назначения флага Зам : если нужно подменить загружаемый объект на существующий и не изменять существующий объект, флаг не устанавливаем. Если нужно заполнить свойства существующего объекта значениями загружаемого (наименование, код, ставка НДС и т.п.), флаг устанавливаем.

Я рекомендую флаг устанавливать. И вот почему. Как уже было сказано, при загрузке данных в непустую базу существует проблема: объекты разных баз, отражающие одни и те же сущности, имеют разные уникальные идентификаторы и не совпадающие значения реквизитов. Выставив соответствия вручную, мы можем избежать дублирования. Но что если при следующем сеансе обмена мы забудем это сделать. Тогда база будет испорчена. Если же перезаписать ключевые реквизиты объекта приемника, реквизиты поиска, то при следующих загрузках соответствие загружаемому объекту будет выставлено автоматически по реквизитам. Разумеется при условии, что в правилах конвертации задан поиск по реквизитам.

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

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

Рис.5 Выбор узла обмена, для которого созданы соответствия

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

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

Рис.6 Соответствие указано вручную

Отмечу, что флаг замещения реквизитов существующих объектов снят. После нажатия Загрузить данные в приемнике появится новый документ, но контрагент и договор в нем будут заменены на существующие (см. рис.7), новых контрагента и договора из документа создано не будет. Поясню, на рис. 6 виден еще один договор (с кодом 00078). Он никакого отношения к документу не имеет, переносится потому, что указан как основной договор у контрагента. Поскольку мы для него соответствия не указали, он запишется в базу-приемник без изменений, причем помеченным как основной договор. У Существующего контрагента таким образом будет два договора: Существующий договор и новый. Новый договор принадлежит именно Существующему контрагенту , так как контрагент Фирма "LIGHT " в процессе загрузки подменен, в том числе и там, где он является владельцем.

Рис.7 Результат переноса документа

Если установить флаг замещения реквизитов существующих объектов, то реквизиты Существующего контрагента и Существующего договора будут изменены (включая наименование). Таким образом Существующий контрагент "превратится" в Фирму "LIGHT " . Важно понимать, что это ни в коем случае не новый контрагент, а уже существующий, но с перезаписанными (если конечно это позволяют правила переноса) реквизитами.

Оба варианта являются примерами правильной конвертации. Придраться тут не к чему. А теперь о "неправильностях". Предположим, что выставлено соответствие только для договора, т.е. все так же как на рис. 6, но нет соответствия Существующий контрагент . При этом замена реквизитов у договора Существующий договор также не производится. После загрузки в документе будет указан контрагент Фирма "LIGHT " и договор Существующий договор , который принадлежит другому контрагенту.

Это может быть расценено как ошибка переноса, хотя никакой ошибки конечно нет, все сделано в точном соответствии с настройками: контрагент оригинального документа сохранен, договор подменен, реквизиты существующего договора не изменены, а значит не изменен и владелец существующего договора. Если установить флаг замены реквизитов для Существующего договора , то документ будет более корректным. При записи Существующего договора изменится его владелец, он будет принадлежать отныне контрагенту Фирма "LIGHT " , а также его наименование, т.е. его будет "трудно узнать". Это все тот же существующий договор, но изменивший абсолютно все реквизиты, включая наименование и своего владельца - контрагента.

С учетом сказанного можно рекомендовать связанные объекты сопоставлять существующим объектам также в связке, а если уж указывать соответствие без соответствия для владельцев, родителей (групп), то устанавливать флаг замены реквизитов. Но в последнем случае нужно помнить, что существующий объект может оказаться где угодно: "переехать" в другую группу справочника, принадлежать другому объекту-владельцу.

Что же касается конвертации владельцев без указания соответствий для подчиненных справочников (или регистров сведений например), то здесь никаких особенностей нет. Как уже было показано выше на примере основного договора контрагента, подчиненный справочник будет привязан к другому контрагенту, если существует такое соответствие.

В версии 2.1 появилась возможность сопоставления планов счетов. Рассмотрим на примере как и в каких случаях это можно использовать. На рис.8 показан документ, в котором используется добавленный в режиме ведения учета субсчет к счету 68. Т.е. это нетиповой, отсутствующий в типовой конфигурации счет. При переносе данных в другую информационную базу его можно также добавить к типовому плану счетов, но это не всегда правильно. Очень часто бухгалтеры злоупотребляют созданием всевозможных субсчетов, а когда понимают к каким последствиям это приводит, бывает уже поздно что-то менять.

Рис.8 Пример использования добавленного счета плана счетов в источнике

Предположим, при обмене мы захотели исправить эту ситуацию и заменить добавленный в источнике счет 68.16 на типовой счет 68.10 , уже имеющийся в приемнике. Для этого при загрузке в приемник нужно установить соответствие счета 68.16 счету 68.10 как показано на рис.9. Заодно еще раз показано, как можно заменить значение справочника, в данном случае справочника Организации . Такая же необходимость может возникнуть при объединении данных из нескольких информационных баз в одну, когда возникает задача синхронизации планов счетов в источниках, которые не совпадают.

Рис.9 Установлено соответствие счетов

Результат загрузки в базу приемник показан на рис.10. Видно, что счет 68.16 заменен на 68.10 . Счет 68.16 в таком варианте загрузки в приемнике вообще не будет создан. Произведена и подмена организации. Поскольку в данном случае мы записываем операцию, введенную вручную, то вместе с документом Операция производится создание набора записей регистра бухгалтерии. При этом замена организации произошла как в самом документе, так и в его движениях, что можно увидеть например с помощью консоли запросов. Что, впрочем, уже не так важно, поскольку всегда можно перезаписать документ и получить обновленные движения.

Рис. 10 Результат переноса документа

Важно . Следует подчеркнуть, что если с сопоставлением производятся многократные загрузки информации в одну и ту же базу, то нужно сохранять соответствия объектов, для чего использовать узел обмена, как показано выше. И нельзя забывать выбирать нужный узел при повторных загрузках. Если узел обмена не будет указан, то и соответствия, созданные ранее, не будут задействованы. Рекомендую всегда загружать и просматривать соответствия прежде чем нажать кнопку Загрузить данные .

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

Рис.11 Конвертация документов Поступление товаров и услуг

В список полей поиска включим реквизит СуммаДокумента для того, чтобы иметь возможность не просто искать в базе приемника документ нужной даты и с нужным номером но и проверить совпадение суммы документа с документом источника. Для удобства введем параметр Поиск по сумме и реализуем алгоритм поиска вот так:
Если Параметры.ПоискПоСумме Тогда
СтрокаИменСвойствПоиска = "Дата, Номер, СуммаДокумента";
Иначе
СтрокаИменСвойствПоиска = "Дата, Номер";
КонецЕсли;
Т.е. при установке параметра в значение Истина ("Да") поиск будет осуществляться по дате, номеру и сумме, иначе только по дате и номеру.

Теперь при заполнении соответствий, если синхронизация по сумме и суммы документов в источнике и приемнике совпадают, документ в приемнике будет найден и соответствие установлено (см. рис.12)

Рис.12 Результат поиска (сопоставления) по реквизитам при совпадении суммы

Если же суммы не совпадают, документ в приемнике найден не будет. Замечу, что реквизит СуммаДокумента есть не во всех но во многих документах типовых конфигураций.

Важно . Обратите внимание на параметр Отключить поиск документов по УИД . Он появился в версии 3.1 и служит как раз для сверки документов. Если синхронизация документов осуществляется по УИД, то в том случае, если документ найден по УИД, поиск по реквизитам производиться не будет. Таково типовое поведение обработки при загрузке. Нам же нужно не просто убедиться в наличии в приемнике документа, но и проверить на совпадение с источником его реквизитов (в нашем примере суммы документа). Для этого мы отключаем поиск по уникальному идентификатору, поиск таким образом всегда будет продолжаться (осуществляться) по заданным реквизитам.

Вы можете приобрести описанную выше обработку, которая применима в конфигурациях, имеющих в своем составе обработку Универсальный обмен данными в формате XML редакции 2.1.8, т.е. работающих в режиме управляемого приложения, таких как Бухгалтерия предприятия ред.3.0, Комплексная автоматизация ред.2.0, Управление торговлей ред.11 и т.п. Вы можете также приобрести эту обработку в различных комплектах, в составе пакетов из обработок и правил обмена на нашем сайте . В составе комплектов это будет существенно дешевле.

Сравнение версий :

10.03.2018 - версия 3.1. Добавлена возможность отключения поиска документов по УИД для сопоставления документов по реквизитам

06.02.2018 - версия 2.1. Добавлена возможность сопоставления планов счетов

05.02.2018 - версия 1.2. Исправлена ошибка в режиме работы на клиенте

01.03.2017 - версия 1.1. Возможно сопоставление документов и справочников