Приветствую господа!

Как мы знаем - Ключи аналитики просто справочник.
Информация о нём - в Соответствующих регистрах.
Имеем РИБ, много узлов.

Ситуация - в разных узлах в производство списывают Доски, первый раз в жизни базы.
Ключа такого нет, он формируется новый. В обоих базах свой ключ, но одинаковый по сути.
Идут обмены, в итоге запись в регистре есть только об ОДНОМ ключе, а в движениях РАУЗа 2 ключа

Если ещё раз списать доски в узле - подхватит ключ о котором есть запись в регистре, т.е. второй ключ.
Имеем в РАУЗ 2 записи одинаковые по смыслу (и визуально одинаковые), но с разными ключами.

Если перед расчетом себестоимости провести все доки - всё выровняется, но это просто нереально на больших объёмах, причем собственно и одно из достоинств РАУЗа - не надо ничего перепроводить
Обработка ТИИ ключей - не исправляет данную ситуацию.

Кто думал о такой ситуации вобще? Как бороться по феншую чтоб?

(83) уволится?)

(80) верю (с)

и решение ТС-у надо искать архитектурное

возможно не передавать Рг РАУЗ в центр совсем

и узнать это можно только из целей консолидации

На существующих типовых объектах УПП вряд ли что-то получится.  Как вариант: отключить обмен справочниками Ключи аналитик и регистрами Аналитики учета. В переферии перед обменом изменившиеся Ключи аналитики сливать в дубль-справочник, значения регистров Аналитик в дубль-регистры. Закачиваем дубль-справочники и дубль-регистры в центр, после отого запускаем постобработку по соединению справочников и регистров в типовые справочники Ключи аналитик и типовые регистры Аналитик учета.

(85) в систему заложен постулат что не должно быть разницы между узлами и данными в центре, т.е. проведение дока в центре должно благополучно отразится и на узле, поведение системы должно быть одинаково в рамках всех узлов РИБа

(84) это полумера. передай получение ключа на md5 и все. можно даже оставить эти грабли с РС. Главное, чтобы гиуд ключа (ссылка на объект) в любой точке была одинаковой.

(88) передай -> переделай

(88) да, интересная идея, буду брать в расчет

>>проведение дока в центре должно благополучно отразится и на >>узле
писец

(88) а одинаковой она может быть толко с хеш-функцией и все.

(91) почему?

(90) при этом ты даже не нужно делать какие-то быстрые обены этими ключами. Ну нету в узле этого ключа, так он сделает его с аналогичным гуидом и при обменах все пройдет гладко.

Даже если сотня узлов одновременно сделает этот ключ, он все равно будет одинаковый.

Как будешь отрабатывать ситуацию по одновременному проведению дока по одинаковым аналитикам в центре и на переферии?

(70) к сожалению не нашел в закромах такой старый релиз. Но по описанию уже и так понял как это сделано в этой редакции.

(про себя, молча) А ведь истиную проблему возникновения дублирования ключей так и не озвучили. Если убрать все наслоения - то имеем классическое "Хаос невозможно автоматизировать"(с) Решение - административное.

(95) РИБ делаёт это за нас, т.е. вариант центра при обмене будет истинный.
Это не значит что в центре сидим проводим за всех, просто есть такая возможность

(94) да, я оценил уже подход

100

(97) решение на уровне платформы а не административное.
Так как дубли ключей могут появиться, если одновременно провести два документа с отсутствующими ключами с системе.

(99) теперь когда ты оценил, ты понимаешь что все остальное это просто полумера.

(97) какое именно? на примере (76) не вижу административного решения...

(103) добавлю, что на больших базах специально выносят упр. расчеты на отдельный узелю

(102) две полумеры ведут к гарантии, т.е. 1.быстрые обмены + 2. замена ссылок. Но делать конечно геморней

(105) оцени доработки двух костей и их последующее администрирование.

(105) особенно в части замени. так как после замены потребуется перерасчет.

В любом случае перепроведение открытого периода перед РСВ мне кажется полезным.

(106) хм, MD5 получается сразу подходит для генерации ссылки по гуиду?

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

(110) уже проверил?

(111) нет, пока умозаключения, ибо мы делаем свой порядок генерации ссылки. Кто гарантирует что такой уже нет? МД5 как раз подходит для гуида, 32 символа в виде 16-чном.

(112) тьфу, т.е. не подходит немного)

(113) и что не подходит?

затронута похожая тема

http://partners.v8.1c.ru/forum/thread.jsp?id=1089379

ответ 1с:
Мы рассматривали такую идею в самом начале, но нам не удалось найти приемлемого решения. Преобразование гуидов по математическим формулам не может дать 100% гуид.

(116) у кого доступа нет - ответ был на вопрос:

а не хотите-ли вы генерировать гуид ключа на основании значений ключа
например: гуид партнера + гиуд организации + гуид контрагента - md5 = гуид ключа.
тогда можно будет и в РИБе это использовать.
(с)

правда я сам не понял пока почему мы не получим 100% гуид.

хотя может и понял...

Если у двух строк хеш-коды разные, строки гарантированно различаются, если одинаковые — строки, вероятно, совпадают. (с) вики

т.е. одинаковый

(119) + одинаковый хэш-код возможен у разных входных данных

а вот и Bober пришёл)
на партнёрке тоже обсуждали, йс отказалась от идеи короче, хоть и красиво, но не 100%

(121) не знаю, почему отказались, делал. работает.

(122) работать будет, но нет гарантии просто. Теоретически возможна бяка, когда один гуид сгенерится на разные данные

(120) да, такое возможно, но вероятность маленькая. Еще как вариант написать свою хеш-фукнцию и спасть спокойно.

а 1с ничего не делает, если нет 100% уверенности, допущений не допускают, и делают по своему через опу

(123) зато сейчас гарантий полно -)

(125) делает, поэтому мы и обсуждаем как это переделать.

(126) ну разгребать овно в РИБе они разрешают самим...

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

(129) короче великие наши внедренцы последовали совету 1с так не делать. будем мучатся с комплексом затычек: быстрые обмены, замена ссылок, перепроведение

вот как делал MD5(НРЕГ(СтрЗаменить(XMLСтрока(Ключ.знч1) + XMLСтрока(Ключ.знч2) + XMLСтрока(Ключ.знч3)), "-", "")). Далее все это в ссылку. Полет нормальный.

PS
- Если значение ключа составной тип, то обязательно добавлять  гуид тип объекта и следить за тем, чтобы значение было
заполнено.
- если значение ключа пустое, то все рано передавать гуид (00000000-0000-0000-000000000000).
- если количество аналитики меняется, то потребуется все переделывать.

(131) можешь поделится функцией MD5? для себя

(132)
http://infostart.ru/public/96713/

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

с генерацией ключа?

(135) для генерации гуида

(136) + тупой вопрос, дефисы вставить только)

(137) нужно подождать, сейчас пример сделаю.

(137) тебе всю мини конфу или только кусок кода?

(137) накатал пример

ТекстДляКлюча = НРег(СтрЗаменить(XMLСтрока(Объект.Номенклатура) + XMLСтрока(Объект.Характеристика) + XMLСтрока(Объект.Склад), "-", ""));
   ХешТекста = ОбработкаОбъект.MD5(ТекстДляКлюча);
   
   ГуидТекст = Сред(ХешТекста, 1, 8) + "-" + Сред(ХешТекста, 9, 4) + "-" + Сред(ХешТекста, 13, 4) + "-" + Сред(ХешТекста, 17, 4) + "-" + Сред(ХешТекста, 21, 12);
   Объект.КлючАналитики = XMLЗначение(Тип("СправочникСсылка.КлючАналитики"), ГуидТекст);
   
   //идет в транзакции для блокировки спр
   НачатьТранзакцию();
   ЗаблокироватьСправочникПоСсылке(Объект.КлючАналитики);
   Если Не КлючСоздан(Объект.КлючАналитики) Тогда
       СоздатьКлючАналитики(Объект.КлючАналитики, Объект.Номенклатура, Объект.Характеристика, Объект.Склад);
   КонецЕсли;
   
   ЗафиксироватьТранзакцию();

(140) мини конфу на мыло можно, если не трудно)
впринципе понятно конечно

Я не тупой или упрямый, я - упорный :)

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

(142) всмысле? какой пример?

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

(142) пример - АналитикаУчетаЗатрат, там запросто

(144) тоже как вариант, только ТИИ ключей убъёт их, ибо они не используются

(145) Для новой номенклатуры ключ создаётся при первом поступлении(оприходовании) в организацию. Как ключ ухитряется дублироваться? Вы сразу на нескольких узлах поступление(оприходование) вбиваете?

(146) Запуск ТиИ ключей можно зарегламентировать - запускать не тогда, когда хочется, а тогда - когда можно :)
  В алгоритм можно внести условия(ограничения) по удалению неиспользуемых ключей.

(141)

http://rusfolder.com/33871746

(147) номенклатура - там десятки тыщ наименований. заветси её могут давно заранее, когда запланируют

(148) спс. заценю на днях

(142) (147) детсад какой-то.

(147) убрать эту функцию из обработки можно конечно... но, как ты себе это представляешь? на ВСЕ сочетания номенклатур, характеристик, статей, серий, качество и т.д. создавать ключи? боюсь распухнет справочник до неприличных размеров

У меня, наверное, какая-то неправильная УПП: для позиции номенклатуры пара-тройка записей, ну максимум 5-6 в аналитике учета затрат.

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

Вообще-то я имел ввиду, говоря про "набор", что это не всевозможные варианты. Например: "набор" основные производственные материалы. Статья затрат - определена и не изменяется. Качество - новое или брак (допустим). Пришло на склад - ушло в производство. Всё.

(155) характеристики, серии и т.д.? чтоб не было кучи дублей - надо при поступлении создавать сразу и аналогичные производственные. А если сразу после поступления списали в производство до обменов? получаем (0) опять)

Ладно, уговорил. Не универсальное решение.

Другая идея: специально выделенный план обмена только по этим справочникам и регистрам. Обмен по событию (по мере надобности - по факту добавления новой записи в справочник). Как тебе это?

(157) да, еще костыльков да побольше. вот кто будет весь этот зоопарк админить.

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

(158) самое смешное что это фпнач-внедренец у нас делает, т.е. ему лишь бы сделать, кто поддерживать будет - не их проблема

*франч

(161) бррррр. звери а не люди

(159) Ну, в принципе... новая запись справочника может быть только "спусковым курком" - сам обмен начнется через несколько секунд допустим. Одна или куча записей туда войдет уже не важно. Тот кто не успеет - вновь взведет курок.

(163) как организовать не суть, смысл предложения - обмениваться быстрей. к сожалению Гарантии тоже не даёт, приходится совмещать с другими костылями

Bober, кстати, мне твоя идея тоже нравится. Можно генерировать уникальный идентификатор по уникальному наименованию. В риб-базах будет исключено дублирование наименований так, как при обмене это будет одна единственная запись.

(165) ответ 1с на такой подход в (116), и наши франчи согласились с ним( хотя в реальной жизни вероятность совпадения стремится к 0. Но раз "может" такое быть - значит нельзя

Я в курсе. Всё дело в вероятности. Точнее - насколько она низкая :)

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

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

делают костыли чтоб была гарантия 100%. хз чо у них получится

(168) если генерить другой - то по какому алгоритму? и другая база должна знать что ты в узле1 сменил алгоритм

(170) посмотри, сколько сейчас ключей в базе

(171) каких именно? затрат?

Всех различных

Ключи аналитики вида учета    10 136
Ключи аналитики распределения затрат    4 705
Ключи аналитики учета затрат    170 868
Ключи аналитики учета партий    71 211
Ключи аналитики учета прочих затрат    2 541

такая петрушка

Группа риска как раз "Ключи аналитики учета затрат"

(170) Если есть один, общий для всех, генератор - почему бы у него не может быть другого, запасного алгоритма - тоже общего для всех? :)

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

(176) Это если обмен уже прошёл. А если между обменами создадим элемент1 и при попытке создать 2-й - токая же ссылка - то вернёмся к (0) :)

это всё на самом деле ОЧЕНЬ маловероятно. и легче сделать один из вариантов, чем пытаться делать АБОСЛЮТНО гарантированную систему

(177) Не согласен. Вероятность повторной генерации - очень низкая(но есть). А повторной генерации номеров в период между обменами - стремится к 0.000(0)

(179) дак и по MD5 - стремится к 0 вероятность... но возможно :(

Возможно? "Будь мужиком"(с) - сделай так и докажи обратное :)

я - афк, бб.

(181) теоретически возможно. опровергать логику я не научился