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

Принципы сопоставления объектов при обмене данными 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. Возможно сопоставление документов и справочников

© Борис Балясников, март 2017г., последние изменения март 2018г.

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

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

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

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

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

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

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

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

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

To properly display this page you need a browser with JavaScript support.

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

Обработка "Сопоставление и исправление объектов" применяется, если для ранее сопоставленных объектов было изменено сопоставление в Управление дистрибуцией. Тогда в форме обработки для загрузки данных от дистрибьютора появится ссылка для исправления документов, содержащих измененные данные (Рис. 7.16 ) .

Обработка может быть запущена двумя способами:

из подсистемы "Данные дистрибьюторов" для изменения сопоставления непосредственно через обработку;

Для отбора данных по дистрибьютору укажите наименование дистрибьютора в поле "Дистрибьютор" и нажмите кнопку "", чтобы отобразить данные, загруженные из УС дистрибьютора.

Рассмотрим сопоставление номенклатуры в качестве примера.

Рис. 7.13. Обработка "Сопоставление и исправление объектов"

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

Соответствие указывается из справочника "Номенклатура ". Это можно сделать вручную или при помощи кнопки "Найти похожие ". Поиск может быть осуществлен по артикулу (если включена настройка "Отображать артикул") или по наименованию. Если при поиске не найдено полное соответствие, то будет подставлена номенклатура с частичным соответствием артикула или наименования.

Измененное, но несохраненное сопоставление выделяется жирным шрифтом .

Флажок "Отображать артикул " регулирует отображение артикула товара дистрибьютора и сопоставляемого товара.

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

Для исправления документов нужно:

Вот мое прокомментированное решение в 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 автоматическими тесты как часть тестового набора проектов