Поводом для написания этой статьи стал очередной звонок бухгалтера с паникой перед сдачей отчетности по НДС. В прошлом квартале потратил много времени на уборку дублей контрагентов. И вновь они, те же самые и новые. Откуда?
Решил потратить время, и разобраться с причиной, а не следствием. Ситуация с основном актуальна при настроенных автоматических выгрузках через планы обмена из управляющей программы (в моем случае УТ 10.3) в бухгалтерию предприятия (в моем случае 2.0).
Несколько лет тому назад были установлены эти конфигурации, и настроен автоматический обмен между ними. Столкнулись с проблемой своеобразности ведения справочника контрагентов отделом продаж, которые начали заводить дубли контрагентов (с тем же ИНН/КПП/Наименованием) по тем или иным причинам (одного и того же контрагента они раскидывали по разным группам). Бухгалтерия высказала свое "фи", и постановила — нам не важно, что там у них, объединяйте карточки при загрузке в одну. Пришлось вмешаться в процесс переноса объектов правилами обмена. Убрали для контрагентов поиск по внутреннему идентификатору, и оставили поиск по ИНН+КПП+Наименование. Однако и тут всплыли свои подводные камни в виде любителей переименовывать наименования контрагентов (в результате создаются дубли в БП уже самими правилами). Собрались все вместе, обсудили, решили, убедили, что в УТ у нас дубли недопустимы, убрали их, вернулись к стандартным правилам.
Вот только после "причесывания" дублей в УТ и в БП — внутренние идентификаторы у многих контрагентов различались. А так как типовые правила обмена осуществляют поиск объектов исключительно по внутреннему идентификатору, то с очередной порцией документов в БП прилетал и новый дубль контрагента (в случае, если эти идентификаторы различались). Но универсальный обмен данными XML не был бы универсальным, если бы эту проблему обойти было невозможно. Т.к. идентификатор существующего объекта штатными средствами изменить невозможно, то можно обойти эту ситуацию при помощи специального регистра сведений "Соответствие объектов для обмена", который имеется во всех типовых конфигурациях от 1С.
Для того, чтобы не возникало новых дублей алгоритм уборки дублей стал следующим:
1. В БП при помощи обработки "Поиск и замена дублирующихся элементов" (она типовая, ее можно взять из конфигурации Управление торговлей или на диске ИТС, либо выбрать наиболее подходящую среди множества вариаций на самом Инфостарте) нахожу дубль, определяю верный элемент, нажимаю выполнить замену.
2. Получаю внутренний идентификатор единственного (после замены) объекта нашего дубля (набросал специально простенькую обработку для этого, чтобы внутренний идентификатор автоматически копировался в буфер обмена).
3. Открываю в УТ регистр "Соответствие объектов для обмена", делаю отбор по собственной ссылке.
4. Заменяю значение ссылки в другой ИБ для нашего узла обмена с БП значением, полученным в п. 2.
Собственно говоря, вот и все, после этого новые документы по контрагенту прилетают как положено, новых дублей не создается. Возможно статья будет кому-то полезна 🙂
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
А почему нельзя просто почистить РС «Соответствия объектов для обмена»?
при очередном обмене этот РС заново начнет заполняться по правилам поиска в правилах обмена
Мы с контрагентами проще сделали. Заставили клиентов в таких дубляж заполнять головного контрагента и в правилах поставили замену на головного контрагента если он есть. И управленцы и клиенты довольны.
(1) 3.14159, потому что с его помощью мы настраиваем соответствие одного и того же контрагента с различными внутренними идентификаторами в наших базах.
(2) thenroach, интересное решение, возьму на заметку 🙂
(3) вручную чтоли настраиваете? o_0
я всегда думал, что он при обменах сам заполняется
(5) 3.14159, все верно, заполняется он изначально автоматически. Но если что-то идет не так в дальнейшем (появление дублей, уборка дублей), в результате чего идентификаторы объектов начинают различаться, в этом регистре может содержаться некорректная информация. Ситуация в большинстве случаев не типовая. Привел решение как раз для случая, если вдруг придется столкнуться с проблемой.
Еще бывают случаи, когда один контрагент (номенклатура, договор и т.п.) при выгрузке встает на другой элемент справочника. При помощи описанных действий можно разобраться «где собака зарыта».
(6) в консоли запросов (способ выгрузки дерево:) можно сразу поискать все «проблемные собакой зарытые»
ВЫБРАТЬ
СоответствиеОбъектовДляОбмена.УзелОбмена,
СоответствиеОбъектовДляОбмена.СобственнаяСсылка,
ТИПЗНАЧЕНИЯ(СоответствиеОбъектовДляОбмена.СобственнаяСсылка) КАК ТипЗначенияСобственнойСсылки,
СУММА(1) КАК КолВо
ПОМЕСТИТЬ СоответствиеОбъектов
ИЗ
РегистрСведений.СоответствиеОбъектовДляОбмена КАК СоответствиеОбъектовДляОбмена
СГРУППИРОВАТЬ ПО
СоответствиеОбъектовДляОбмена.СобственнаяСсылка,
СоответствиеОбъектовДляОбмена.УзелОбмена
;
ВЫБРАТЬ
СоответствиеОбъектов.УзелОбмена КАК УзелОбмена,
СоответствиеОбъектов.ТипЗначенияСобственнойСсылки КАК ТипЗначенияСобственнойСсылки,
СоответствиеОбъектов.СобственнаяСсылка КАК СобственнаяСсылка,
СоответствиеОбъектов.СобственнаяСсылка.Код,
СУММА(СоответствиеОбъектов.КолВо) КАК КолВоДублей
ИЗ
СоответствиеОбъектов КАК СоответствиеОбъектов
ГДЕ
СоответствиеОбъектов.КолВо > 1
СГРУППИРОВАТЬ ПО
СоответствиеОбъектов.УзелОбмена,
СоответствиеОбъектов.СобственнаяСсылка,
СоответствиеОбъектов.СобственнаяСсылка.Код,
СоответствиеОбъектов.ТипЗначенияСобственнойСсылки
УПОРЯДОЧИТЬ ПО
УзелОбмена,
СобственнаяСсылка
ИТОГИ
СУММА(КолВоДублей)
ПО
УзелОбмена,
ТипЗначенияСобственнойСсылки
(7) 3.14159, и что вы увидите этим запросом? 🙂 Двойные записи для одного объекта? Их может и не быть.
(9) 3.14159, уточню, если не ошибаюсь конечно, регистр Соответствие объектов для обмена заполняется либо при начальной настройке обмена (т.н. ПервыйОбмен = Истина), либо в случае, если поиск элемента происходит не только по внутреннему идентификатору, но и по полям поиска. Однако поиск соответствия по этому регистру происходит при загрузке всегда, несмотря на настройку поиска объекта, установленную в правилах обмена.
Если правила типовые, то для вновь создаваемых новых объектов данные в этот регистр уже записываться не будут, т.к. поиск у нас по внутреннему идентификатору происходит. Однако если мы вручную укажем сопоставление, то обработка обмена данными ее учтет при загрузке.
(10) если правила написаны нормально, то можно смело грохнуть дубли, при следующем обмене соответствие запишется опять
(11) 3.14159, понятное дело, если мы договариваемся с пользователем о полях поиска, и он у нас идеально заводит карточки номенклатуры, контрагентов, без ошибок, сто раз перепроверяя перед записью… Однако не всегда бывает все идеально — бардак не запрограммировать 🙂
Господа! Позвольте подлить намного воды в диалог по поводу контроля обмена.
Во -первых. Обработка полезна.
Во-вторых, потеоретизирую на тему.
лично я с подобной проблемой столкнулся не только с контрагентами, а и с партнёрами в УТ11 — БП 2.0 и УТ11 и Розница 2.0. ( ну про партнёров в УТ 11 разговор отдельный. но и с номенклатурой. И если контрагентов пара тройка сотен, то номенклатуры под 20 000.
Какие возникают проблемы?
1. обмен бывает двухсторонний и односторонний. Если мы просто сливаем инфу из УТ в БП, то решение » много к одному» можно найти. Если есть обратная выгрузка ( например банковских платежей или кассы) то возникает проблема
» один ко многим» а её решить уже гораздо труднее.
В обмене же номенклатурой между УТ и РТ( розницей) желательна полная идентичность справочника номенклатура.
Теперь о проблемах в самом обмене и регистре «Соответствие обмена».
их можно выделить пять:
1. Уже упомянутая проблема «один ко многим» и «многие к одному».
2. просто дубляжи ( при первичной синхронизации ли, при одновременном заведении в двух базах, дубляж в одной базе и тираж на другую с обменом) Здесь автор как раз предлагает решение
3.Нет записи в регистре соответствия. Элемент справочника есть, а записи в регистре нет. Возникает, например при неудачной «ручной» чистке. Или при завале процесса синхронизации при обмене. Тут необходима обработка по элементам справочника и поиску записи в регистре и последующей принудительной выгрузкой незадействованных элементов. Естественно в случае необходимости.
4.Неправильное соответствие. Наиболее вероятно при любимом занятии менеджеров и прочих юзеров переименовывать Существующие карточки товаров. т.к. соответствие в регистре уже есть, и идентификаторы не изменились правила обмена могут пропустить данный кульбит и вы вместо спичек в одной базе будете иметь бульдозер в документах другой. Обмен вроде должен контролировать этот момент, но не факт. Особенно если обмен односторонний, а переименование в подчинённой базе. «Лечиться», во первых, жёстким контролем работы с карточками, а во-вторых… Я так понимаю нужно сравнение регистра соответствия из двух баз. Куда то вываливать и сравнивать. выводя расхождения.
5. Элемент удалён, запись в регистре осталась. По идее тестирование должно эту проблему решить.
Ну и последняя из мною выявленных проблем. Грамотное удаление объектов в обоих базах. Признак » объект не найден» в той или иной базе.
Подчеркну на последок. Это моё видение проблем и ошибок в обменах. Комплексных решений у меня пока нет. Одно из них нашёл автор данной обработки.
(12) «бардак не запрограммировать :)» экая точная формулировка!
(13) skuratov_ab, спасибо за столь развернутый комментарий. Действительно при использовании автоматических обменов (одно-, двусторонних) бывает много различных нюансов, и нет единственно правильного решения. Зачастую приходится контролировать какие-то моменты вручную.
Есть идея написания обработки сопоставления и настройки регистра соответствия объектов для обмена двух баз (через COM-соединение), как это умеют делать мастера первоначальных настроек обменов (например в БП 3.0), но с более развернутыми возможностями и для уже настроенных соответствий. Думаю было бы хорошим продолжением статьи 🙂
(13) skuratov_ab, а пункт 3 точно проблема?? по-моему, пункт 3 лишний
(16) 3.14159, 3 пункт проблема, если используются свои правила, в которых поиск осуществляется по полям поиска… Хотя при следующей синхронизации и удачном поиске объекта запись соответствующая в регистр занесется обработкой обмена данными.
(17) «кривые» правила — это проблема:) а пункт 3 — не проблема
если свои правила, то в КД есть Обработчик событий «Поля поиска»
Обработчики «Правила конвертации объектов»
Поля поиска
Условия возникновения события
Только для платформы V8.
Событие выполняется при поиске элемента ссылочного типа. Если установлен поиск по уникальнму идентификатору и программа нашла элемент, то поиск прекращается. Если поиск по уникальному идентификатору не дал положительного результата и указано, что нужно продолжить поиск в этом случае или поиск по уникальному идентификатору не проводился, то программа пытается найти элементы по свойствам поиска. В обработчике нужно установить список полей через запятую по которым нужно проводить поиск. Если очередная попытка дала положительный результат, то поиск прекращается.
Поиск возможен только по тем полям у которых на этапе выгрузка был установлен флаг поиска данных!!!
Параметры:
НомерВариантаПоиска — число. Номер попытки поиска. Попыток поиска может быть не больше 10.
т.е. возможно 10 попыток найти ссылку на объект в приемнике 🙂
(18) 3.14159, я прекрасно знаю, что такое поля поиска, но только вот переход от поиска по идентификатору к полям поиска может вызвать определенные проблемы (связаны они с переименовываниями, изменениями кодов пользователями). Вот даже в случае ниже умудрялись появляться дубли (хотя вроде предусмотрели все, что можно), либо наоборот заменяться другие элементы справочников.
Показать
Поиск по реквизитам хорош для справочников-классификаторов например. Или для случая, когда данные заведенные раз ни при каких обстоятельствах не изменяются пользователями (по крайней мере поля поиска). Во всех остальных ситуациях его конечно лучше не допускать (оставшись лишь на поиске по идентификатору).
Но очень часто всплывают задачи настройки обменов между базами, учет и в первой и во второй в которых ведется уже давно. Тут конечно же поиск по идентификатору невозможен.
(19) поиск по полям происходит после поиска по УИДу, если объект в приемнике не найден по УИД
(20) 3.14159, можно и после, можно и вместо. Уточню — ситуации бывают различные. Одно дело когда у нас есть УТ и мы создаем первый обмен с базой БП (пустой). Другое дело — когда в БП уже ведется учет и нам необходимо настроить обмен с текущими данными. А бывают ситуации к примеру, когда есть 2 базы (вторая создана путем копирования первой с переименовыванием организации и других справочников), и нужно настроить выгрузку из этих баз в одну (назовем ее консолидированной). Как видите в последнем случае поиск по внутреннему идентификатору нужно уже исключать (иначе данные из одной программы будут перетираться данными другой).
тогда это уже «свои» правила и каким боком тут РС Соответствия объектов для обмена, если не идет поиск по УИД?
(22) 3.14159, как каким? Если по правилам успешно находится объект по полям поиска — соответствующая запись создается в регистре соответствия объектов для обмена, чтобы в следующий раз на поиск время не тратить.
(23) в следующий раз в бардачной базе опять что-нибудь переименуют и опять будет «кривая» запись РС Соответствий обмена))
надо что-то менять в «консерватории»
У нас решено было ввести запрет для переименования контрагентов (в управляющей программе, в вашем случае в ут) для обычных пользователей, если есть движения по взаиморасчетам. Плюс при записи контрагента идет проверка уникальности связки ИНН + КПП.
С введением такого правила сильно пищали обычные пользователи, но потом смирились и теперь бардак в контрагентах сведен к минимому.
(16) 3.14159, в данной теме затронута одна проблема обменов — задвоение. А часто возникает вторая — » объект не найден» пункт 3 относиться больше к данной проблеме. Я утверждать не могу. досконально не копался в этом ещё. Но возникает например с подчинёнными справочниками. Соответствие номенклатур есть, но почему то теряется соответствие единиц измерения. В результате, после обмена в принимающей базе по полям ед. измерений стоит » объект не найден»
(16) 3.14159, к примеру, гибнет файл или пакет обмена с новыми элементами справочника. При этом в посылающей базе соответствие уже есть, а в принимающей не возникло. В дальнейшем обмен элементы справочников уже не выгружает. т.к видит соответствие у себя. а у принимающей стороны соотетствия нет — и является как раз » объект не найден». Тоже возникает при НЕ синхронной чистке баз. когда в одной элемент уже удалили и он соответственно ушёл и из регистра, а в другой этот элемент использовали в документе.
Хотя утверждать что именно пункт 3 виноват в этом не стану. Что эта проблема именно в отсутствии записи элемента в регистре соответствия одной и той же базе.
(26) skuratov_ab, РС Соответствие тут ни при чем. если
, значит не передался сам объект ед.измерений, хотя ссылка на него в Номенклатуре есть
про
тоже не понял, есть же механизм «квитанции о приеме» при обменах. если <Объект не найден>, опять же есть у него УИД, что мешает его найти в базе-источнике и «ручками» поставить на обмен??
Господа, а просветите по такому скользкому пункту. Когда я лазил по регистру соответствия, мне показалось что он состоит из 2 частей. «На вход» и » на выход». Т.е. «на выход» слева гуид данной базы, справа принимающей. а где-то ниже такое же соответствие, но наоборот. Гуид входящей — гуид текущей. В идеале, данные обеих строк должны быть идентичны. Я верно понял структуру регистра или мне показалось? Прошу прощения, конечно, у всех, тема реально одна из важнейших, но в данный момент нет возможности включиться в исследования
(27) skuratov_ab,
в посылающей базе соответствия нету, пока обратно обмен не придет от приемника. пока подтверждения о приеме от источника не придет, тупо будет опять выгружаться при обмене. в принимающей стороне «объект не найден» — по причине отсутствия самого объекта — ссылка на обеъкт есть — а объекта нету. как в анекдоте по словарь русского языка — «.опа есть, а слова нету»
(28) 3.14159, в принципе, ничего не мешает. признаю, в 8 опыт ещё не богатый. Хотя озвученные проблемы возникли и в восьмёрке. по опыту 7.7 когда на ТиС крутилось 60 магазинов, и соответственно в одном обмене уходило 60 пакетов искать «ручками» я Вас умоляю. когда одна УТ — одна розница или БП, можно конечно и каждую запись вылезать. Когда сеть… ну может я чего не догоняю… пардон, не бог и не создатель. Будем учиться и изучать.
Я постарался в своём большом посте озвучить круг проблем обмена с которыми реально столкнулся. С той целью, чтобы совместными усилиями создать инструментарий админов для контроля и управления обменом.
Естественно, одну две позиции единиц измерения можно вылечить перезаписав элемент в исходящей базе. он придёт и в принимающую. А если их сотня -другая по 5-6 базам, да и вылезают они только когда в документ попадают… Будем ручками править или доверять самой 1с исправлять?
(30) 3.14159, Верите , ли сударь, не исправляется. Обмены гоняются, всё нормально проходит, а » объект не найден» как были так и остаются. Т.е. идеальные конструкции заложенные в саму программу не срабатывают. Вот такое противоречие книг-инструкций и опыта эксплуатации. Нужен инструментарий админа. А то что руки у меня кривые — и спору нет, кривые.
(31) skuratov_ab, если лень ручками искать и на обмен целиком все справочники нереально поставить (по причине объемов файла выгрузки в xml), пишутся «обработки» для поиска ссылок на <объект не найден>, из базы-приемника запись в текст УИДов (dbf,excel,xml — не важно), в базе-источнике — поиск объектов по УИД и регистрация в плане обмена
как искать <Объект не найден> в регистрах и справочниках — всем известно
(26) skuratov_ab, проблема подчиненных элементов вообще очень больная. Настраивал правила обмена, вроде все красиво для единиц измерения прописано в правилах. И выгрузки тестовые делал все как надо. Но — когда объемы стали превышать тысячи карточек номенклатур при выгрузке за раз, начали непонятные вещи проскакивать в виде «Объект не найден» для единиц измерения номенклатуры.
Долго боролся, и правила менял, и поля поиска (поиск по GUID в принципе не подходил, т.к. 1 база обменивалась с 10-ью разными, в которых учет уже велся, и номенклатура могла заводится и там и там), проблема не решалась. В результате решение было найдено… В ПКО именно единиц измерения ставим галочку «Не запоминать выгруженные объекты». В результате объем выгрузки несколько возрастает, но сами объекты единиц измерения никуда не теряются.
Аналогично решилась проблема с договорами.
И опять же — вроде на начальном этапе все хорошо, и на небольших порциях, но когда на обмен летят огромные порции, и поиск осуществляется не только по GUID, но и по полям поиска — начинают всплывать подводные камни.
(32) skuratov_ab, согласитесь, что у вас «объект не найден» — это единичные случаи в результате каких-то сбоев. если нет, то нужно в первую очередь смотреть механизмы регистрации объектов в планах обмена, тем более если не РИБ, а через com-соединение и по правилам обмена, возможно это «косяки» в правилах или в коде
(33) 3.14159, кстати нередко подобного рода ошибки возникают при совместной доработке конфигурации группой программистов. Очень часто программисты просто не знают технологии обменов (ну допустим он специализируется на написании отчетов/обработок и никогда не разбирались в обменах в принципе) и в проверках перед записью не ставят «загрушки» в виде:
(35) 3.14159, Да я согласен, что единичный, если у меня по номенклатуре 20000 позиций и из них кривых 15 — 20, в 3-4 разных базах, то конечно это единичный случай, но когда в самый неподходящий момент раздаётся визг или писк оператора или манайгера, что …. и надо срочно это исправить, то тогда извините е….вашу ..ть на всю эту конструкцию. Дело не в количестве. проблема есть, надо решать.
(37) skuratov_ab, писал недавно «инструментарий» для сравнения ссылочных типов данных между базами РИБ через xml — отмечаются выбранные объекты метаданных (из состава выбранного плана обмена), выгружаются в xml. В базе-источнике ищется по УИД. Справочники, документы ищутся по ссылкам на наличие/отсутствие (сравнение по содержимому справочников и документов пока не допиливал), регистры накопления/сведений сравниваются наборами записей с отбором по всем возможным измерениям
все «различия» можно зарегистрировать по выбранному плану обмена. Обработка получилась универсальной,работает на стороне главного и на стороне подчиненного узла
как будет время и желание, оформлю в виде статьи
(38) 3.14159, Во, это дело! Риба нет пока, но будет. Готов буду оттестировать
(38) 3.14159, не забудьте в статье описать о вреде полных прав пользователей, когда они любят запускать обработки поиска и удаления помеченных объектов… Ведь база убаленная РИБ может обмениваться только по одной организации, и не иметь множества документов, которые будут ссылаться на помеченную на удаление допустим номенклатуру. В результате удаления (с контролем как положено) в этой удаленной базе удаляться элементы, ссылки на которые есть в центральной базе. И мы легко от таких действий пользователей получим «Объект не найден», т.к. в центральной базе объект будет удален обменом без контроля ссылочной целостности.
(40) про вред полных прав писать не буду 🙂 обработка только ищет разницу и регистрирует объекты в плане обмена
«гранаты» пользователям с большим радиусом кривизны рук и удаление документов в главной при обмене с периферийной базой — это другое
(41) 3.14159, ясно 🙂 Увы, многие имея обмены по риб даже и представления не имеют, что ссылочная целостность в периферийной базе и в центральной — две большие разницы, и уж тем более если периферийная только по определенной организации/подразделению/складу обменивается.
Хорошо бухгалтер там… но многие «программисты» не раз обращались с проблемой, и все говорили ничего не делали, а объекты пропали. Благо журнал регистрации никогда не врет, ну и бэкапы были, они и спасали 🙂
(42) удаление объекта в «приемнике» при обмене в журнал регистрации не пишется), в журнале регистрации можно поискать только в «источнике»
(43) 3.14159, в базе А (центральная) имею кучу «Объект не найден» в справочнике Номенклатуры, открываю журнал регистрации, делаю отбор только по удалению, вижу, что Автообмен (имя пользователя, под которым обмен проходит) удалил элементы справочника допустим 27.12.2013 в 13:00…
Перехожу в базу Б (периферийная), открываю журнал регистрации, делаю отбор только по удалению, вижу пользователь Иванов сделал удаление объектов 27.12.2013 в 12:15 (позже выясняется, что он запускал обработку удаления помеченных объектов).
Не до конца понятно, что не пишется в журнал регистрации?
(44) если база РИБ, то при обмене при удалении объекта в базе-«приемнике» событие в ЖР не пишется. В вашем случае у вас не РИБ, а универсальный обмен данными, хотя в (42) вы про РИБ писали. РИБ и универсальный обмен данными — это не одно и то же.
(45) 3.14159, может у вас настройки журнала специфические для уменьшения объема? Специально удалил пару внешних обработок в центральной базе. Прогнал обмен (РИБ) — в периферийной базе в журнале имею:
В данном споре соглашусь с insurgut. вот именно так и бывает. И в журнал именно это и пишется. Уже и по 8 такие расследования вёл с жестокой покрой любителей » навести порядок в базе»
(46) какая у вас конфигурация?
(46) вы правы! событие в ЖР при удалении объектов при обмене пишется
фигня какая-то.
у себя сделал просто.
при записи нового контрагента — всегда проверка на уникальность ИННКПП.
полный и безоговорочный запрет на создание контрагентов с незаполненым ИННКПП.
в резудтате проблема практически исчезла.
(50) CheBurator, увы, но в реалиях нашего региона — у разных контрагентов могут быть одинаковые ИНН/КПП 🙂
Надо