v8: коллизии при обмене ут-розница. #658494

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

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

выгнать гения и наладить обмен?

нет, есть решение, которое даже в случае сбоев обмена автоматом разруливает такие коллизии.

но первая часть надеюсь в силе?

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

типа для этого вида документа поменять приоритет

мы же все знаем, что все неправы, кроме тебя! зачем эта ветка? чтобы ты еще раз для себя это утвердил?

помню я была ветка, мол "Ускорить создание узла с 8(иль 4) часов до 2-х... Гнитальное решение выдало - держать под рукой актуальную базу псевдо-узел, чтоб быстро скопировать. Вопрос и ответ никак не связаны были, так и тут будет

который год гений сидя во франче доит клиента так и не разобравшись с обменами на инфостарте, что не ветка гения - про обмены никак не разберется

Странная задача. А если условие дополнить. Что будет? А если в УТ документ изменили и повели. А в Рознице просто провели.

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

мое решение и тут будет работать.

для любителей интересных задачек. это ж гуру-тест

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

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

как вариант снять регистрацию в ут

перечитай условие задачи. Внимательно!

это сложно. без подтверждения от розницы не снимется, а откуда мы знаем, прошел обмен или нет. Есть решение проще.

ну настучать девочкам по голове, которые эти документы распроводят и в розницу не отзваниваются. Не оно?

Один из вариантов борьбы с коллизиями - записывать объекты пересекающиеся в регистр, чтобы потом Человек принимал решение какой объект правильный, автоматизировать это нельзя в принципе, нет гарантий

Гуру-тест на тему как управлять приоритетом? И что тут сложного? Без проблем. Даже если это будет РИБ.

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

ну и что? у меня есть способ "распределеного проведения документов", когда документ синхронизируется по тому узлу, где происходит действие и проводится одновременно в нескольких узлах РИБ...

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

Это сложно, а есть простое решение. Банальное как пять копеек, думай. можно, включай мозг, думай.

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

не томи

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

Версионирование?

умница, а теперь детали - какой простейший способ? не спорю, но я про простые решения.

На ум приходит только отдельный РС ВерсииПереданныхОбъектов

это сложно и не очень надежно. давай решать для одного конкретного вида документа, например ПеремещениеТоваров.

Если честно - то даже напрягаться чтобы понять ТС - нет желания. В - обмен "слетает" и изменение, соответсвенно не поступает, а в - "та же версия, которая уже была передана". ТС, ты уж определись с какой стороны смотреть на медаль - орел или решка.

я тебя не напрягаю, мимо проходи

да при чем тут версионирование? Проблему выбора "правильного" объекта, который был изменён в обоих базах по разному не решить никаким версионированием, ты просто выберешь один из вариантов, на основании своих умозаключений. Чито может привести к выбору неправильного объекта

мозг включи.

в общем случае нет, но в данном конкретном случае есть вариант.

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

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

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

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

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

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

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

Ладно, че томить, в принципе уже придумали. Дарую пиплу свой метод, изучайте. В УТ и Рознице добавляем дополнительный реквизит: Версия. включаем в правила обмена. соответственно в УТ триггер ПередЗаписью версию увеличивает на единичку. Теперь при загрузке из УТ берем версию в Рознице и если она равна версии в УТ, то не грузим. Зачем одну и ту же версию повторно передавать?

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

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

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

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

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

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

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

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

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

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

у меня 81

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

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

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

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

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

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

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

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

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

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

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

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

только что проверил

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

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

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

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

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

ыть, ага, согласен

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

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

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

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

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

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

а как же

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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