двоятся записи в регистрах накопления #125309

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

Что то первый раз об таком слышу, конфигурация какая?

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

конфигурация УПП: 1.1.4.4

Та-же байда на релизе УТ 10.2.5.4 + Платформа релиз 8.0.12.21 Диагностике не поддается совершенно! В документах тоже в разных бывает (в том числе нетронутых - типовых). Из регистров - чаще всего "ТоварыНаСкладах" и "ЗаказыПоставщикам". Двоение происходит в геометрической прогрессии, т.е. при одной позиции в документе, его движения могут иметь: 1, 2, 4, 8, 16, 32.............. записей. Это видно по полю период. Грешим на реализацию РБД в этой базе, но уже сомневаемся, т.к. проблема не отлавливается совсем и не удается установить закономерность. В течение дня может быть несколько сотен однотипных документов конкретного вида, и только 1-2 из них содержат такие задвоенные записи... Что посоветуете? Куда копать? А я вот много раз об этом слышал, НО до 9 релиза платформы... и думал что больше о таком не услышу, а вот теперь не знаю че и думать :(

да есть такая болезнь у меня на раних релизах была (рел "движка" 8,9). Думал 1с это выличила на позних релизах, ан нет. Как я понял, это происходит когда пользователь пытается провести докт а таблица к.л. заблокирована, транзакция хреново откатывается. На линии поддержки посоветовали перед проведением принудительно очищать движения

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

Народ! Посоветуйте че-нить! Как попробовать смоделировать такую ситуацию? Уж там бы что-нибудь придумали - только-бы отловить! Как принудительно заблокировать таблицу и надолго?

А задвоение когда происходит? При перепроведении? Если да, то попробуйте перепроводить так: - Провести.

Ждем 13-й движек, к томуже его в сентябре обещали, так и нету.

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

есть еще способ, откатиться на 11-й движек, на нем вроде такого нет, хотя не уверен.

вы не первые:

кстати, я последние два месяца на 11 релизе, вроде "дублирования не замечалось"

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

попробуй при проведении использовать модально открытые формы

мож у тя сервант нормально настроен?

Может, и так

Если б только знать когда оно происходит! :( Как раз при интерактивном перепроведении все встает на свои места. Впрочем если программно (обработкой) тоже... Такой вариант не пойдет - на основании, например, такого глючного Заказа поставщику пользователи вводят Поступление, со всеми вытекающими последствиями... Количество повторов может доходить до 9 и более, что при количестве строк в документе, скажем = 37 дает порядка 9500 строк в движениях !!! 8-/ Причем сами виды документов не удается выявить однозначно - до вчерашнего дня думали, что этот список примерно такой : "Поступление ТиУ", "Заказ поставщику, Реализация". А вчера к ним прибавился документ "Списание товаров", который на 99.99% типовой по составу реквизитов и на 100% - типовой по движениям. Наиболее вероятным сейчас представляется следующий сценарий: 1) Пользователь пытается провести (может перепровести) интерактивно документ. 2) Параллельно идет обмен РБД, который на данный момент выполняется в единой транзакции (в ближайшее время будем пробовать другой шаг). 3) У пользователя выскакивает ошибка ожидания захвата таблицы. Как следствие документ не проводиться до конца. 4) Пользователь повторяет попытку провести документ, причем делает это 1, 2, 3... раз, до тех пор пока обмен не "отпустит" все нужные таблицы. 5) При N-ной попытке документ успешно проводится, но видимо с продублированными движениями. Попытки воспроизвести такой сценарий, даже при блокировках не привели к появлению дублей :(

может попробывать как в ?

Да написали уже давно :/ Правда пока в режиме отчета. Может зделаем обработку, только как часто ее запускать? Каждый раз после обмена? Что-то не очень я бы доверился полученным результатам :( Нагрузка на ИБ и так огромная - более 1000 заказов покупателя в день, около 100 поступлений товара. Итак регламентных обработок хватает, а такой отчет надо будет запускать довольно часто, и то нет гарантии, что с момента окончания обмена, до момента этой обработки, никто не успеет на основании глючного заказа ввести такое-же глючное поступление, только уже с количеством в 9 раз большим чем в заказе. Это все только на ОДНОМ из нескольких складов!!! (пока идет режим тестовой эксплуатации и помимо центральной базы, работает только 1 большой склад) Все равно всем БАЛШОЕ человеческое спасибо за участие! Мне очень важны все советы и мнения, т.к. сам я уже иссяк :( Жду еще предложений. А с обработкой - наверное попробуем...

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

Предлагаете ввести это в регламент в виде приказа? А если операторов несколько? А если проблема не только в заказах, а еще и в других документах? Всего не отследишь. Железо вполне справляется. По скорости пока нет претензий. Сервера 1С и SQL - разнесены на разные машины. Железо на  2*Xeon 3400 + 4Гб оперативки. Да и проблема видимо в платформе, либо в реализации настроек и количеством серверов думаю не решится. Я просто в предыдущем своем посте хотел сказать, что не дело - каждую проблему, причины которой не ясны закрывать  обработкой - сначала надо понять причины. Спасибо.

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

У 1С - один ответ, - "не воспроизводится" :(