v8: 1с82 УРБД: Некорректный обмен #623661

Всем добрый! Народ подскажите в ситуации: Есть 2 информационные базы на 1с82. Одна - это центральный узел, находится в центральном офисе; Вторая - это подчиненный узел, находится непосредственно на объекте, где идет производство. Таким образом самая правильная и актуальная информация о деятельности в подчиненной базе. В один "прекрасный" момент на неделю отвалился обмен по техническим причинам (не было интернета). После восстановления соединения произошел обмен в результате которого в подчиненной базе "поплыли" остатки - обмен произошел не правильно, данные загрузились с приоритетом центрального узла - это не правильно! Пришлось восстанавливать ИБ подчиненного из .dt, обмен встал... Как выполнить обмен между базами с приоритетом той информации, которая в подчиненной базе, т.к. там производство и т.о. правильная и актуальная информация

бред

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

снитмай регистрацю изменений в центральной базе. и после загрузки доков из переферийки ставь датц запрета + по пальцам молотком

снова бред, ибо регистрация происходит только при записи

очевидно что не только открывали

а на самом деле у вас воруют, а отсутствие обмена обнажила скрытый механизм

to    kotletka: пользователи закрывают документы обычно кнопкой "ОК", следовательно вот вам обработка проведения...

kotletka снять регистрацию изменений в узле ЦБ программно очистить? В конфигурации из обработок тока список узлов в форме списка планов обмена и обработка, которая выполняет обмен

Снятие регистрации вот как-то так? ПланыОбмена.УдалитьРегистрациюИзменений(ТекущийУзел);

есть еще обработка РегистрацияИзмененийДляОбмена

операции -> обработки-> Регистрация изменений для обмена

тока не всё снимай

А когда отменили ПриПолученииДанныхУзлаОтГлавного?

1С:Предприятие 8.2 (8.2.13.219) 1С-Рарус: Комбинат питания, редакция 1 (01.0.10.01) Нашел обработку РегистрацияИзмененияОбъектов Если не все снимать, то что? - Документы посредством которых поплыли остатки?

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

Опять трава?

В настоящий момент не могу выполнить обработку - конфигурация Рарус и имеет свой аппаратный ключ защиты на конфу, ключ в сервере, подключится не могу. Завтра предстоит

вазелин не забудь

А вот про регистрацию изменений: с помощью имеющейся обработки в конфе "РегистрацияИзмененияОбъектов" снимать регистрацию объектов надо в ЦБ - и т.о. образом обмен произойдет с приоритетом подчиненного, или нужно в обоих ИБ снимать регистрацию? Какой порядок обмена после снятия регистрации? to   DrShad: :)

а почему ко мне? я вообще против этого варианта

Вопрос ко всем. штатную ситуацию руками оборабатывать?

так ведь штатная ситуация кроется в неверной первичке и обмен тут ни при чем

???

ну а как обмен мог испортить остатки? да еще и полный

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

и? как это испортило остатки?

Все чинится с помощью обработки ВыгрузкаЗагрузкаДанныхХМЛ.епф, да будут блогословенны ее создатели... Из периферии выгружаем  пул документов (тех, которые зарегистрированны в центре). И все

Читай и СП.

в полнейший бред в части того что обмен испортил остатки, а СП тут вообще не поможет

+ я могу 100 000 раз перепровести документ и обменяться с перефирией и ничего в остатках не измениться, если только я в нем что-то не изменю

+ и тут обмен ничем не поможет

2 а если ты в центре просто отменишь проведении некоторых документов прихода и заведешь вместо них новых? а перрепроводить как раз ничего не станешь...

Ты правда внимательно читал они документы и движения перезатерли. Вопросы.?

тогда в перефирии появятся новые и некоторые старые станут непроведенными и снова с остатками будет все ОК

2 нет, не станет. Потому что расходные будут расходовать партии, которых нет.

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

но ведь в центре и в перефирии одинаково, а по сему остатки буду кривыми и там и там и отличаться, т.е. плыть не будут

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

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

Ты не "решил проблему", а получил кучу новых.

Созданием новой ЦБ из переферийной? какие?

Что я такого ужасного то сделал, все вроде красиво. Какие бывают последствия?

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

99% проверок все упиралось в людской фактор.