Распроведение документов при обмене РИБ #363180

1С:8.1 УПП Распределенная база. Созданы и проведены документы ППВходящее в дочернем узле. Пришли в центральную базу. Через некоторое время в дочернем узле перепровели эти документы. В центральную базу документы пришли непроведенными. Подскажите, в чем может быть причина?

Перепроведение документов выполняли через Операции-Проведение документов

?

Объясните кто-нибудь поподробнее, как происходит перепроведение через Операции-Проведение документов?

версия платформы?

8.1.11.67

а после этого отправляли обмен в дочерний? там остались проведенными?

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

в дочерней остались проведенными. В центре никто документы не трогал

Причины (на вскидку): настройка плана обмена (обмен документами без обмена регистрами) - проверить планы обмена; изменения документов в центральном узле "отвергают" изменение (проведение) в дочернем узле (проверить по журналу регистрации ЦУ); проведение документов позже сеанса обмена (проверить содержимое сообщения обмена); Глюки платформы (проверить повтором проведения), глюки базы (ТиИ)

Обычно приоритет при обмене - за центральной базой, поэтому если документы пришли в центр. базу, но еще не прошел ответ из ЦБ в дочерние базы о том, что док-ты получены, то что бы с ними не делали в дочерних базах (исправляли, перепроводили и т.д.) - все это бесполезно и затрется в них "ответом" из централки. Как с этим бороться - я не знаю.:(((

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

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

Любые изменения (меж сеансами обмена, естественно) - будут переданы в ЦУ с очередным обменом. Естественно, если в ЦУ "терпения" не хватит и они сами исправят документ, то  изменение поступившее с очередным обменом будет "отвергнуто" ЦУ. Выход из этой ситуации один - делать более частые обмены и иметь возможность производить обмен "по требованию".

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

Все эти обмены проходят ночью, когда никто не работает. Правда, на ночь иногда запускают Операции-Перепроведение документов. Это монопольно. Но запуск обмена происходит через другую базу, которая паодключает объект 1С текущей базы и запускает обмен. Может в таком случае он игнорирует монопольный доступ?

в смысле, изменения не зарегистрируются?

При чем в ДУ на эти документы в журнале регистрации есть записи , что повреждение журнала

"Экперементировали" юзверы и не раз (как прием или увольнение - так сразу "лихарадит") - ничего "не теряется". Очередные изменения приходят (просмотр сообщений обмена это поддтверждает). Банальная несогласованность действий :( Одно время меня "достали" жалобы что изменения "теряются". Проверка показала: новая работница имела "дурную" привычку, просматривая документы, выходить из них через кнопку "Ок"...

Вот последовательность действий, при кот. изменения не регистрируются: Создали Док1 в дочернем узле. Отправили обмен в централку, в централке получили Док1. В дочернем узле решили поменять Док1 (например, удалить какую-ниб. позицию товара). ЦУ послал обмен в дочерний узел, дочерний его прочитал - ВСЕ, изменения, сделанные в предыдущем пункте - потеряны. Плюс к этому я наблюдала и путаницу в регистрах - при перепроведении документов при подобных обменах. Выход, видимо, один - более частые обмены. Если бы в дочерний узел ответ из централки пришел сразу же - то все было бы нормально! Не претендцю на истину - просто долго наблюдала за поведением распределенки.

Не верно! ЦУ пошлет документ в дочерний - если только он будет исправлен в ЦУ !!!

<Плюс к этому я наблюдала и путаницу в регистрах> - Вам ТиИ надо делать и срочно :(

Нет, ЦУ посылает документ в дочерний не только, если он исправлен в ЦУ. Он считает НОВЫЙ документ как исправленный! А тестирование я регулярно делаю, т.к. если в дочерней создать документ, провести его, а между обменами удалить - в централке в регистрах сохраняются записи с ссылками на удаленные объекты.

Не сочтите это как проявление недоверия к Вашим словам, но за три года обменов (несколько раз в сутки) - ни одного "необъяснимого" случая. Правила обмена простые и ясные. Да, обмен имеет свои "тонкости" которых он бы лучше не имел :) И это приходится учитывать. Даже если Вы начнете обмениваться каждые 15 минут, - Ваши "проблемы" уменьшатся, но не исчезнут... Всю "черновую" работа (перепроведение, удаление помеченых и т.д.) лучше делать на ЦУ и нигде более...

С проблемой, когда остаются записи в регистрах после удаления регистратора, - не разу не сталкивался... Вы случайно не "проповедуете" непосредственное удаление? У меня удаление монопольной обработкой только через пометку удаления, а у Вас?

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

Нет, непосредственное удаление везде закрыто.

Наверно из-за возможностей различной настройки планов обменов, новый документ в подчиненном узле может "вести" себя по другому, чем в ЦУ. Поэтому в  ЦУ он "считается" измененным. Не проверял (ей богу) этот аргумент.

Кстати, вот еще насчет "глюков" в распределенке - в справочнике Номенклатура решили переместить товары из одной папки в другие. Ну и соответственно - удалили эту ставшую ненужной папку (через пометку на удаление, все как положено). После того,как прошли обмены - исчезла и папка, и товары, которые в ней были. Остались лишь битые ссылки. Оказалось, что узел получл сначала инфу об удалении папки и не нашел ничего лучшего, как удалить и все лежащие в ней товары. А информация о перемещении товаров в другие папки - была ниже по тексту. Правда, это было еще на 8.0. Так что со всем этим механизмом надо быть осторожнее. Отрабатывает не всегда так, как хочется.

Поплачусь в жилетку: у меня кадровики так "бодаются". Хотя чего проще: "чей" работник - там и документы на него готовить. Так ведь нет! Центральный офис считает своей вотчиной "казнить и миловать" - и формирует приказы об увольнении и изменении окладов... Замучали меня с описанием прав и изменением нумерации своих документов...

Согласен на все 100% Наученный горьким опытом, - я никогда не спешу с удалением. Сначало пометка на удаление - потом несколько сеансов обмена (вдруг "передумают"!) и лишь потом "само" удаление (ночью: обмен-удаление-обмен)...

C'est la vie!(Такова жизнь!) :(

+1 кратко, лаконично и полно...

Сорри, Анна, мы так мило поговорили в "чужой" ветке - что перед автором не удобно :)

Тем не менее, спасибо, вроде все по делу!:)))

Если есть еще вопросы или еще что-то хотите обсудить - всегда пожалуйста :)

да, общение пошло))) Я тут отвлкаюсь, пришла, тут целые письмена)

Можно и продолжить - если Вы не устали читать :)

Можно и продолжить. Ваши тексты мне тоже интересны. Но пока причину проблемы так и не нашла

Ну а что тут поделать? Эти документы - перепровести в централке, все должно на место встать. А чтобы разобраться с причиной - надо повторно попытаться смоделировать эту ситуацию и посмотреть на результат. Если будет то же самое, то копать дальше в обмене. А заодно и с нами поделиться результатами...:))

Не надо ничего моделировать - все данные у Вас на руках: Журнал регистрации - что и когда "было" по данному документу; Соообщение обмена - что пришло/что ушло. Этого достаточно. Да, много времени потеряете, - но зато столько "нового" для себя "узнаете" :)

Там в автор пишет, что повреждение журнала...

По моему я советовал проверить базу... или еще нет? :)

Да, можно протестировать. Только журнал от этого не восстановится, по-моему.

У меня из-за глюка в РИБ-базе (SQL-файловая) начала "потихоньку, не спеша крыша едет, тихо шифером шурша". Файловая версия содержит ошибки (мамой клянусь - есть!) - а ТиИ "говорит" все нормально. Наверное месяц промучился... потом SQL-база тоже "поплыла". Да, впрочем сами почитайте мои метания

Сорри, "прозевал": какой журнал?

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

Журнал документов - с ошибками? Так это же "мой" случай :) С этой проблемы все и началось... См. в самоотчете посты 17-18 Я "очистил" командой TRUNCATE TABLE таблицу которая давала ошибку...

поподробнее, плиз, где глянуть

посты 17-18 Внешние проявления "сбойного" журнала: 1) Документы, который помечены как "непроведенные", - в самом деле проведены. Проверка: откройте документ - в заговке "... проведен" и есть движения по регистрам (через кнопку Перейти - Движения по регистрам...) 2) При "сканировании" журнала клавишей "стрелка вниз" - невозможно добраться до конца журнала: просмотр журнала "закольцовывается" на какой-то последовательности документов... 3) Колонки в журнале не соответствуют значениям в документе или, вообще, открывается "не тот" документ...

Но эти проявления начились позже. Сначало юзверы начали "жаловаться" что измененные документы начали "самовосстанавливаться" к предыдущему состоянию. В самом деле это была "работа" битых ссылок: в ЦУ меняли один документ, а в ДУ "менялся" другой документ :(

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

Спасибо, посмотрю

Сорри, уже уходя, прощаясь: Битые ссылки в журнале легко проверить: напишите запрос по журналу документов, что бы он вернул для всех документов какое-либо значение через ссылку к документу (например: ...Ссылка.Номер). Если вылетит ошибка - вы "поймали" битые ссылки :)

Этот прием я знаю) спасиб

Попыталась я я повторить ситуацию действительно отрабатывает сейчас корректно. Но точно было, только давно - может механизм в стандартного обмена в 1С подправили? Специально года 3 назад сидела, разбиралась. Но вот что у меня происходит - если какой то документ в ЦУ или ДУ помечается на удаление, то в др. базе все движения по регистрам по нему сохраняются. А если помеченный на удаление при этом удалить, то в регистрах появляются "битые" ссылки. Спасает только ТиИ. Что же получается тогда? Если все помеченные объекты удалять в ЦУ, то в дочках тогда пойдут некорректые остатки по регистрам, если тестирование там не делать??? Вот это проверила несколько раз на тестовых базах. У всех так же?

Попробую вынести этот вопрос отдельной темой...