Были коллизии при обмене УТ-Розница.
Заключаются в том что допустим есть непроведенный документ Д.
Он отправляется из УТ в Розницу, но обмен из Розницы в УТ слетает, соответсвтенно УТ не получает подтверждения, что документ передан.

В это время документ в розницы корректируют и проводят.

И тут еще одна серия обменов с УТ и документ опять распроводится.

Вопрос - как не меняя приоритета УТ, избавиться от таких коллизий.

Решение простое.

(32) При загрузке в приёмнике сравнивать то, что прилетело, с последней записью в типовом РС ВерсииОбъектов. При полном совпадении - игнорировать загрузку. Правда, встаёт вопрос в реализации сравнения

(9) "Да, ложь и неопределено" гыгыгы))))

(38) Хотя не, фигня. На месте могли и изменить

(36) я не выключал, коллизии - классическая задача, решение одно - кто то должен быть главным. Анализ версии объекта не спасёт

в один документ в одно время в Рознице поставили одну номенклатуру в ТЧ, в УТ - другую. Кто прав? Эту задачу решай, а не анализом номера версии в версионировании при сбое обменов

(42) это тупо человеческий фактор

(43) дак серёжа хочет его автоматизировать, ибо ситуация часто такая, а не мифические сбои обменов. По факту объекта 2 получается, надо сделать выбор о правильном

Ладно, че томить, в принципе уже придумали.
Дарую пиплу свой метод, изучайте.

В УТ и Рознице добавляем дополнительный реквизит: Версия.
включаем в правила обмена.

соответственно в УТ триггер ПередЗаписью версию увеличивает на единичку.

Теперь при загрузке из УТ берем версию в Рознице и если она равна версии в УТ, то не грузим. Зачем одну и ту же версию повторно передавать?

(43) не человеческий, а сбой обменов.

так версия и так же есть

Ну так и думал, в итоге крики юзеров - я вот тут заполнила ТЧ на 10 тысяч строк номенклатуры, а они не попали в розницу...

И о номере версии данных Гений не слышал...

(45) и как это поможет разрулить (42)?

+(49) по твоей схеме в рознице будут одни данные, а в УТ другие

(49) да никак, он не о коллизиях вобще говорил, а о сферическом сбое обмена в вакууме, не обращая внимания на содержание объектов, ибо менять могут с обоих сторон

(49) а у меня нет проблем из (42), гыггыы. Я решаю не общую задачу, а частную

(47) где есть? в регистрах обмена?

(53) Версия данных, стандартное поле ссылочных объектов в 8.2

(51) если в УТ поменяют, версия будет уже не 1, а 2.

(54) у меня 81

(54) это типа GUID? как вариант, да.

обновись, будь мужиком

(0) У настоящих гуру таких проблем просто нет.

тогда задача решается просто.
в Рознице храним версию из УТ в регистре сведений.
и если версия совпадает, повторно не грузим.

(58) 100 000 на обновление выделишь? (цена ИТС на 40 узлов РИБ)

(61) зп свою пожертвуй

(61) нищеброды. 40 узлов (читай филиалов) и подпискку оформить не могут. бугага)

(55) это не панацея, могу придумать ситуацию когда это хрень не сработает у тебя сходу

(61) при 40 узлах риб нет 100к? как же они тебе платят??????

хотя версия не передается при обмене

когда обмен настроится, то изменения в Рознице ведь все равно пропадут?

(65) точно? кстати не проверял.
Вобще в сериализованом объекте (в xml-ке обеновской) это поле есть. сохраняется ли оно надо кстати проверить

(66) Пропадут конечно

(67) только что проверил

но у Гения частный случай =)

(66) да, коллизия не разрешена, последствия непредсказуемы

(67) как раз в сериализованном его уже нет

(68) зачем тогда их пытаться защищать?

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

(72) ыть, ага, согласен

(74) нету никаких продаж, дядя.
еще раз - это защита от повторной передачи версии объекта, которая уже передана. Греха нет, наоборот универсально и позитивно.

т.е. принцип такой - если объект один раз передан, то эта версия повторно не передается. нормалек такое решение.

(45) в УТ дважды перезаписали объект, в Рознице дважды перезаписали объект (частая тема распровести-провести).
Обмен по логике проигнорирует все это.

а как вообще может прийти документ с тем же номером версии то???

(77) очень индивидуальное решение, часто объекты ставят снова на обмен по тех. потребностям (изменили движения, запись объекта шла в режиме обменДанными). Такое никак нельзя рекомендовать к применению.

Я не понял, зачем менять в УТ документ пришедший из Розницы? и наоборот, разве что дозаполнить, но тогда его не надо передавать из УТ в Розницу, а если его повторно поменяли в Рознице, то он один в один должен попасть в УТ. Т.е. по реализации главнне Розница. Надо исправить документ - меняй в Рознице, а не в УТ. ИМХО конечно.

(77) а как же (66)

(77) аналог номер сообщения в таблицах регистрации это, передан или нет. Только у тебя он с другой стороны - принимать или нет. Где это даёт защиту? милисекунды при записи объекта, мол пожалеем базу? А если изменили, номера твоих версий увеличились, какой в итоге объект будет в реале существовать? боюсь что разные в разных базах

(78) дядя, в рознице версия не меняется.

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

(81) читай условие внимательно.
в УТ создают драфт (заявление на возврат товаров) в рознице смотрят, что из этого реально есть и заполняют, проводят.
но бывает, что из-за сбоев обмена (нет подтверждения от розницы при обмене), документ повторно передается из УТ и затирает тот документ, который был уже создан в рознице.

Мое решение универсально, в любом направлении можно юзать

(85) лучшее - враг хорошего. Не стремимся к идеалу.

(83) речь не об экономии времени, а о защите изменений, сделанных в рознице

(86) здесь "странность" в  том, что изменения идут в самом документе, а не идет через связанный документ.
А если заявку изменили полностью, то тогда нужно перезаписывать?

(0) Указание места создания объекта с запретом редактирование.  Врое даже в типовых видел.

(89) Проще поправить перемещение, чем городить связные документы.

(90) не поможет. Обмен затрет все изменения

(88) я бы сделал это либо через связанный документ. Либо в событии при загрузке делал анализ (есть флаг - документ из розницы в приоритете или еще какой-нибудь).

(92) Лол. Думай еще над словами.

>>Вопрос - как не меняя приоритета УТ...
ты понимаешь что ты его и изменил, только програмно?
Я бы на твоём месте просчитал возможные варианты, варианты изменения этого документа в обоих базах, разное количество раз, и наверняка увидишь рассинхронизацию данных. Нелья закладывать в алгоритм то, сколько раз нажмёт юзер кнопку записать. У него тик нервный может, а твои версии меняются

короче ты взял Абсолютно частный случай. Но реализовал так, что влияет на все случаи

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

Каждый объект должен быть привязан к базе возникновения иначе ни какие коллизии не разгребешь.

Жаль нет банов - За глупость!

(100) 100 Ну и Наф-Наф отдыхает.

(94) я подумал. мне не нужно запрещать редактирование. не в кассу
(95) что тебе не понятно? суть в том, что если версия объекта уже передана, повторно ее не передавать. Просто и универсально. Это ломает твой мозг?

(96) ничуть не частный. решение универсально. Если объект передавали, повторно не передаем, чтобы случайно не затереть изменения в приемнике. Абсолютно универсально.

(97) в этом есть здравое зерно, я не спорю. но придется ломать документооборот устоявшийся.

(99) а в чем глупость то?

(101) >>(94) я подумал. мне не нужно запрещать редактирование. не в кассу

Компромиссов не существует.

(101) объект может повторно выгружать из УТ в розницу (или еще куда-нибудь) и это нормально. Раз УТ-Розница, то наверное идет обмен через конвертацию. Раз так, то могут быть изменения в правилах, которые потребуют перегрузку объектов. Поэтому тема с по номерами в объектах очень частная и индивидуальная.
Более того, что ты делаешь когда идет запись в режиме ОбменДанными, тоже меняешь версию?

(103) Сравнивать версии , это моразм. тут даже не стоит обсуждать.

у меня нет уже сил доказывать что это неправильно, остаюсь при своём мнение, так делать нельзя. Частный случай, влияющий из-за кривизны реализации на всё

(105) В этом весь "Гений 1С".

(101)
>>придется ломать документооборот устоявшийся
Лучше день потерять, зато за пять минут долететь (c)

(105) а я остаюсь при своем

(107) да, кстати. предложу копировать шаблон в новый документ. Тогда и правила менять не придется.

(109) кстати, ты так и не ответил, чем тебя ПланыОбмена.ИзменениеЗарегистрировано() не устраивает при загрузке из УТ-> Розница?

А в чем проблема проверить на признак изменения документа в текущей базе перед записью?

(111) Просто кто то не знает платформу v8.

(101) и в УТ, и в рознице один и тот же документ, с одной и той же версией, пусть равной 1. идентичные.
Затем в рознице его дополнили - добавили еще 120 строк, версия изменилась на 2,а в УТ пользователь сначала поставил в комментарии документа точку после какого-нибудь сокращения, а потом просто пару раз открывал документ на посмотреть и закрывал через записать. так что в УТ версия будет уже 4. и чо?

(113) да, колхозное решение. но похоже у ТС не было другой темы для троллинга.

Юзеры у Гения Святые, они не жмут лишних кнопок, никогда. И попадут в рай 1с 100%. Сам нуралиев будет их превествовать там...
А в это время рассинхронизация данных, вопли юзерах о мистике в программе и т.д.

Его уже нет с нами, пора закрывать очередную "гениальную" тему (надоб их нумировать)

(110) ты видел, как работает схема обмена УТ-Розница по правилам обмена? Тогда бы не задавал таких странных вопросов.

(112) намекаешь что (111) плохо изучал правила обмена?

(113) для военных напоманию, что в Рознице версия не меняется при записи.

(117) для гениев исправляю (113) - в рознице версия 1, но в УТ уже 4, и т.к. версия не равна версии розницы - принимаем. В итоге затираем 120 строк

Довожу любую ситуацию до абсурда :)

у ТС типичная, классическая ситуация - между сеансами обмена для объекта зарегистрированы изменения в обеих узлах.

И независимо от того, хочет он признавать это или нет, всё упирается в приоритет изменений.

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

PS: Прикол ситуации, над которой бьётся тс, о так называемой "защите изменений" в том, что никто не мешает пользователю, чьи изменения отвергнуты, повторить свои действия позже вновь. И все труды тс накрылись медным тазом :))

(0) Я - Гуру. У меня не бывает коллизий при обменах.

У ТС абсурдных ситуаций не бывает у него только частные

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

(122) у нас версионирование кстати так доработано, узео изменения добавлен, но при разборе коллизий это не поможет никак, решение о правильном объекте не принять

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

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

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

Уж если допустить такую коллизию, что из источника объект выгружен, попал в приемник, после чего и там и там объект был изменен - и вот надо отказаться от загрузки его в приемник, так? Есть решение куда надежней и оптимальней. Создать свой, отдельный план обмена в приемнике и в нем управлять регистрацией измененных объектов. То есть, объект был изменен в приемнике - попал в узел БазаИсточник плана ПроверочныйПлан. При загрузке проверять по ГУИДУ, не содержится ли там загружаемый объект, если содержится - значит не загружать. А очистку регистрации в этом плане/узле написать в правилах обратной выгрузки, из приемника в источник.

Да уж, версионирование, поразительно просто!

(126) "Рубик-джан! Ты только не обижайся, но я тебе один умный вещь скажу. Твой машина стоит в соседнем дворе. Я так думаю!"

От частного - к общему.

В принципе, и не только для решения проблем с обменом, легко можно реализовать функционал, согласно которому пользователь "А" получит сообщение от пользователя "Б", который изменяет объект, ранее измененый пользователем "А".

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

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

(128) в УПП регистр есть "КоллизииПриОбмене", всё уже реализовано

(129) Интересно, что для версии объекта они хранят в ХранилищеЗначения с сжатием, то в КоллизииПриОбмене они решили хранить строкой.

(130) ну основа есть, допилить чуток)

(129) "всё уже реализовано", не спорю, но юзибилити там хромает на обе ноги, имхо. И у коллизий, и у версионирования.
А в (128) - мнение, что не сложно в общем-то реализовать "оболочку", надстройку с интеграцией сообщений пользователей, регистров коллизий и версионирования.

(132) конечно, типовое почти всё хромает с юзабилити, хочешь сделать хорошо - сделай сам)

(131) не надо допиливать. моя схема и так на автомате позволит разруливать часть проблем

(134) Ну и к чему пришел?

(135) лень менять схему, убедю создавать заявку-шаблон и на его основании уже заявку реальную

(136) Ну так по сути это и будет вариантом КоллизииПриОбмене