1.
smirnovserg.s@gmail.com
17.05.21 13:54 Сейчас в теме
Добрый день!
Сделал изменение в типовых правилах обмена из базы-источника "Управление торговлей для Казахстана редакции 2.2"(аналог российской УТ 10) отключив поиск справочника Контрагенты по GUID и установив поля поиска: Код, Наименование, ЭтоГруппа, ИдентификационныйКодЛичности.
После этого при загрузке нового контрагента в Бухгалтерию происходит его задваивание.
Создаются 2 идентичных объекта с отличием в том, что в одном из созданных объектов заполнены только поля поиска, все остальные поля не заполнены.
Структура файла, содержащего объект выгрузки во вложении.
Если отсечь все лишнее она выглядит так:
Объект - контрагент
Ссылка1
Свойство - код
<Значение>000004352</Значение>
Свойство2 - ГоловнойКонтрагент
Ссылка
Свойство - код
<Значение>000004352</Значение>
Свойство3 - ОсновнойДоговор
Ссылка
Свойство - Владелец
Ссылка
Свойство - код
<Значение>000004352</Значение>
Объект - ДоговорКонтрагента
Ссылка4
Свойство - Владелец
Ссылка
Свойство - Код
<Значение>000004352</Значение>
Показать
При удалении свойств ГоловнойКонтрагент или ОсновнойДоговор из xml - загрузка проходит без задваивания.
Т.е. как только новый объект, который загружается в базу имеет ссылки на самого себя более чем в одном месте, происходит его задваивание. Аналогичный обмен из УТ 2.2(УТ 10) в старую Бухгалтерию 2 - подобных задваиваний не имел, при этом в файле выгрузки свойство Ссылка у Объекта Контрагент, имело аттрибут нпп=<номер_ссылки>, скорее всего из-за которого повторная запись объекта не происходила.
Удавалось ли у кого-нибудь изменить правила обмена поменяв поиск с GUID на поля поиска избежав дублирования элементов при обмене УТ 10 -> БП 3?
Версия конфигурации Бухгалтерия для Казахстана "3.0.39.3"
Версия БСП этой конфигурации 3.1.2.306
Версия платформы 8.3.15
А зачем удалить поиск по GUID?
При создании нового объекта GUID записывается в регистр, что облегчает его последующий поиск.
Если по GUID не найдено и найдено по полям поиска, аналогично соответствие разных GUID записывается в регистр.
Потом при обмене не полными данными, а только ссылкой и ключевыми полями облегчается поиск объекта.
который загружается в базу имеет ссылки на самого себя более чем в одном месте, происходит его задваивание
ничего подобного, одно и тоже правило может использоваться неограниченное количество раз, зависит от структуры метаданных.
Ошибка в правиле, вроде в начале сам написал что в базе используется только 2 из 3 указанных для поиска поля, в этом и проблема, обьекты не идентичны поэтому создается новый
а удалением обмена в другом месте Вы просто убираете вызов правила, оно просто не вызывается ниразу
7.
smirnovserg.s@gmail.com
17.05.21 14:35 Сейчас в теме
(6)
Да,
а наименование 50 и там и там
ИдентификационныйКодЛичности - там и там строка 12.
Оба справочника иерархические.
Код обработчика ПоляПоиска
Если СвойстваПоиска["ЭтоГруппа"] = Истина Тогда
СтрокаИменСвойствПоиска = "Код, Наименование, ЭтоГруппа";
Иначе
СтрокаИменСвойствПоиска = "Код, Наименование, ИдентификационныйКодЛичности, ЭтоГруппа";
КонецЕсли;
Флаг поиска установлен на аналогичных полях у ПКО Контрагенты
Проходил отладчиком - в момент выполнения события ПередЗаписью для Контрагента во вторую итерацию в базе уже существует записанный элемент справочника Контрагенты с заполненными полями поиска, но с пустыми прочими полями.
(16) то есть смотри ситуация складывается, у тебя обменивается контрагент, первое свойство его Головной (это неправильно), так как по рекурсии оно уходит на указанное правило, это снова Контрагент, происходит зацикливание, на втором шаге есть пустой уже и он ставится
(16) сорри, точно там нет Ссылка, все логично, ты ищешь по свойству которое по этому же правилу обменивается будет бесконечная рекурсия всегда, не прокатит
(23) значит добавь) серьезно, включи и добавь в поиск, значит все как раз наоборот чем то как я написал выше, просто проблема явно с головным, я подумал по нему поск не может отработать, возможно его как раз не хватает
28.
alex_bitti
13917.05.21 17:00 Сейчас в теме+0.6 $m
я поискал у тебя аналогичная проблема, все таки поиск по владельцу не проходит, я был прав ранее, но и его же не хвататет, то примерно решение передавать через Входящие данные, структурой
https://forum.infostart.ru/forum15/topic121941/
(29) если совсем получаться не будет есть вариант попроще но менее изящный, предварительно делать обмен (совсем свой отдельный) только по контрагентам причем с отбором по Головным, то есть без подчиненных, думаю все будет работать. задача чтобы на момент обмена подчиненного элемента головной уже был в базе
32.
smirnovserg.s@gmail.com
18.05.21 09:49 Сейчас в теме
залез в отладку и это происходит так:
Читается узел Объект
у него есть свойство ОсновнойДоговорКонтаргента - у которого есть свойство Владелец.
Исходный объект контрагента ещё не записан в базу, но при чтении свойства Владелец у основного договора контрагента происходит создание и запись аналогичного объекта справочника контрагенты - с пустыми значениями прочих полей.
(32) нет, договор контрагента не причем, это простая рекурсия, если обьекта нет то переносится сначала он. проблема в самом правиле переноса контрагента, ты убрал перенос по уид и теперь обмену не хватает набора полей для обеспечения уникальности записи, грубо говоря ты неправильно выбрал поля. в частности "плохое" поле Головной контрагент. Можешь сам сгенерить такую же ситуация с другим полем ЭтоГруппа, если убрать из поиска ЭтоГруппа будет создаваться 2 элемента, один с таким признаком другой без, потому что по нему не будет Поиск, но с ним проще он примитивного типа и по нему работает поиск. Тебе надо в какое-нибудь событие типа ПередЗаписью элемента вставить логику с учетом этой ситуации, алгоритм надо придумать самому, вариантов куча
(32) можно попробовать сделать то что я написал выше в пределах одного обмена, например ПередЗаписью Если ГоловнойКонтрагент пустой, а он не должен быть таким чтобы это узнать надо Перед обменом записать свойство в парамтр из источника, и позже последовательно вызывать в нужной последовательности одно и тоже ПКО
36.
smirnovserg.s@gmail.com
18.05.21 12:33 Сейчас в теме
(34)
если я правильно понял, то для всех случаев, когда есть ссылка на ещё не записанный объект, поиск которого происходит не через GUID, нужно каким то образом сделать отдельные ПКО.
Очень громоздкий вариант, по идее должен быть какой то механизм кэширования в модуле обмена на случай, когда GUID не используется.
(36) не совсем так, отключая обмен по гуид разработчик берет на себя ответственность по обеспечению ссылочной целостности, поля выбранные для поска должны однозначно идентифицировать обьект, поэтому не важно включено это поле в обмен или нет, по нему должна быть обеспечена уникальность а ее нет, я нашел у себя такой обмен только у меня российские конфигурации но все указанные свойства есть, я попробую сделать сам
35.
smirnovserg.s@gmail.com
18.05.21 12:30 Сейчас в теме
(33)
я повторно отключил поле ГоловнойКонтрагент. По нему не происходит поиск. его нет в файле выгрузки.
Запустил отладку на загрузку в бухгалтерии
Объект контрагента с не до конца заполненными полями создаётся на этапе обработки свойства ОсновнойДоговорКонтрагента.Владелец.
т.е. после обработки этого свойства цикл по полям объекта Контрагент идёт дальше, при этом, по окончанию этого цикла, контрагент записывается заново игнорируя то, что ранее он уже был фактически создан при обработке вложенного свойства.
(41) суть в том что выбранные поля для поиска это "Составной внешний ключ -индекс" в терминах БД, тебе надо выбрать галочками Поиск все поля в совокупности которые будут обеспечивать уникальность, ЭтоГруппа, ИИН (у вас налоговый идентификатор), признак Юр лица или Физ, все важно, иначе будет двоиться
(44) не обеспечивают, ты немного путаешь то что тебе нужно с тем что содержат метаданные, для конфы уникальность обеспечивается еще полем Обособленное подразделение, что она тебе демонстрирует, она может создать два таких как тебе нужны элемента при этом изменив те поля которые ты не учел
(44) я написал простой обмен только справочника контрагентов, выбрал поиск ИНН( ваш ИИН) ЭтоГруппа, ЮрФизЛицо и Обособленное подразделение, у меня 190 контрагентов ни одного задвоения в пустую торговлю, уже все варианты перебрал
(49) возможно проблема не в правилах обмена, попробуй убрать поиск по гуид у Договра, если создаст второй договор, при этом поля поиска договора тоже будут уникальны, значит проблема не в правилах.... обмен как происходит через узел?
53.
smirnovserg.s@gmail.com
19.05.21 15:38 Сейчас в теме
(51)
да обмен происходит через стандартный план обмена.
Правила обмена были стандартные после этого у некоторых справочников поиск изменен с GUID на поля поиска, так как это было в правилах обмена до обновления бухгалтерии с редакции 2.0 на редакцию 3.0. Это было сделано в связи с тем, что гуиды справочников между базами отличаются.
Договор тоже ищется по полям поиска среди которых есть поле Владелец, которое также является контрагентом.
Это вторая плохая ситуация.
После анализа процедуры ПрочитатьСвойство() у модуля объекта обработки КонвертацияОбъектовИнформационныхБаз мне удалось подогнать ситуацию к такой, когда при загрузке нового контрагента - он не дублируется.
Добился этого я вручную отредактировав файлик - заменил узел ссылка на узел нпп(не аттрибут!)
это неправильно, но мне нужно понять как, использовав стандартные средства конвертации, добиться такого же результата.
Скрин того, что я поменял во вложении.
В результате я получил следующую проблему - некорректно создаётся договор контрагента.
Т.е. т.к. я его выгружаю не как отдельный узел-объект - он выгружается как ссылка.
1) При этом у него нет всех свойств - например Наименования, которое не участвует в поиске
2) У него не проставляется по итогу владелец-контрагента, то есть то, что я поменял узел Ссылка на Нпп выше по тексту - смысла большого не имело.
Как положительный эффект - не дублируется контрагент, но этого недостаточно.
Должно быть какое то общее решение на тот случай, когда выгружаешь справочник с циклическими ссылками.
Почему я так думаю? Потому, что в предыдущей версии обмена между торговлей 2.2 и Бухгалтерией 2.0 - как то работало.
При этом даже в сам файл обмена выгружалось по сути то же самое за исключением служебного свойства <Свойство Имя="{КлючПоискаВИБИсточнике}"> - скрин с примером выгрузки тоже во вложении
(53) я хотел написать что проблема в "Правилах регистрации объектов" возможно а не в самих правилах, 1С не может сопоставить обмененные ранее обекты, хотя они польностью соответствуют условиям поиска и создается новый косячный обьект, если это так, то вот этот новый обьект постоянно быдет учавствовать в обмене по новым правилам и создаваться при удалении. То что при смене ссылки узла начинает находить подтверждает это предположение. Решение очень простое, нужно попробовать создать новый обмен, то есть полностью создать заново узел и настроить заново по новым правила, привязки к ранее обмененным объектам потеряются и все заработает
(53) еще один вариант протестить сами правила, обменять через обработку УниверсальныйОбменДаннымиXML, можно выбрать к обмену только проблемные Справочники, что то мне кажется так все будет ок, тогда точно проблема с устаревшими настройками и кешами обмена
Сейчас "выкрутился" тем, что вернул поиск по ГУИД +добавил продолжить поиск по полям.
Т.к. проблема только с новыми элементами, то все старые будут искаться по полям, а все новые будут создаваться с использованием GUID без дублей. Но этот ооочень не правильно, должна быть возможность обмена без использования гуидов
(57) должна у меня 8 лет с нуля написанный мной обмен Бух -Бух обменивает без гуидов поиск всех справочников и документов и остального только по полям, но тут принципиальная разница этот обмен полностью мной написан и изначально не был написан как типовой
уид это сквозной индекс тем более скрытый от пользователя, сквозной, и обеспечивает гарантированную уникальность записи, теперь ты им не пользуешься и должен исключить все дублирующие комбинации, но их не много, это перечисленные мной, обязательно обособленное подразделение и юр физ лицо