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

Итоги-то корректные? ошибок нет?

УРБД?

"не хвататет остатков в регистре остатков товаров"
2. на момент ошибки - программа стопорнулась. Анализ соответсвия по отчету Остатки ТМЦ (возможно и по Ведомость по остаткам ТМЦ) и Ведомость по партиям проведен?
после пересчета итогов аналогично как по п.1 - берем и смотрим сравнивамем то, что было и то что есть (возможно придется проследить историю движений по остаткам и партиям по проблемному товару какому-нить одному) - вфявляем где сменилось ситуация с наличием проблемы и ее отсутсвием. Исследуем, делаем выводы.

по УРБД могли прийти движения по регистрам из ПБ, а там данные могли разъехаться с ЦБ.
после пересчета итогов ситуация нормализуется.
как вариант.

(2) Да

(3) проведен по партиям

(4) в ЦБ никаких манипуляций , кроме как отчеты формируют, не выполняют, только в переферийке вводят и правят документы

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

(8) пришедшие по обмену УРБД записи регистров?
например, пришли по обмену запси из таблицы движений, 1ска их тупо вставила, но только движения, а итоги не пересчитала.
(ноя некомпенгаген в УРБД, может ересь несу)

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

(9) так ведь движения создаются в переферийке и уходят в центр ... односторонняя миграция изменений идет

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

(11) ну так вот движения уходят в центр, а итоги в центре как актуализируются при получении движений из ПБ?

(13) проблема в перепроведения у переферийной базы

+(14) по идее от центра обратно ни остатки ни движения никакие не приходят

ТС, переходи от общего к частному. Нашёл документ, гдн не хватает остатков - разбирайся с ним.

(16) ну нашел , в регистре партий есть остаток , в регистре остатков нет . Пересчитали итоге , документ провелся ...

(12) иди в [з]ад. УРБД работает практически безукоризненно. В т.ч. даже извращенно изогнутая - всякими снежинками, выборочной миграцией и т.п.

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

(19) после пересчета итогов остатки в регистре остатков и регистре партий становится одинаковыми и документ проводится

(18) возвращайся, ты нам так нужен) инструментом можно зарабатывать, а можно и грестись до упора. а, ну да, "я ж программист"))

(21) Если у тебя руки из опы - приходится грестись
А я просто работал

(17) Сравните в с копией где остатка нет. В чем разница.

СКЛ-ДБФ? в дбф такое было когда файл больше 1.2 мб становился то при одновременной записи и чтении могли вылазить левые значения.

(12) так, ради интереса... а за чей счет был банкет написания своего обмена? ))))

(20) ну так определяй, какой документ дает/не дает нужный остаток,типа см.(23).
а дальше смотреть.

(0) дядька, ща за семеру отдвухсоттыщщщ не найти ...

(24) SQL, дык ошибка не при каждом перепроведении вылезает .
(26) в основном пересортица (один товар списывается, другой ставится не приход)

(28) нк так что меняется при пересчете?

(28) На прямую в скл ниче не пишите?

(28) То есть движения у документа есть (пришли по УРБД), а в итогах не отразились?

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

это основная беда ТиС семерки... да и не только ее

(30) Нет

(31) отразились , все в переферийке проводится

(33) в разрезе партий никто при проведении задницей - не контролирует. в снеговике тоже. Только наличие/резервы.
Был Пит, который грозился решить эту задачу без восстановления последовательности, да запропал...

(36) в части контроля это решается, я делал, работает.

(35) ну так вы разберитесь где что не сходится. Сравните периферийную с ЦБ. Сравните в ЦБ историю движений при наличии проблемы и последнее исправления. Ну рассказали же выше всё.
А то так в шаманский бубен можно без конца бить.

В модулях проведения ничего не дописывали нештатного?

(37) руками-то доделать можно...
(38) зачем базы-то сравнивать? надо сравнить до пересчета итогов, и после.

Могу допустить, что при групповом проведении и интерактивном/по одному может быть разное поведение.
Во-первых, оно может быть задано программно методом "ГрупповаяОбработка()";
Во-вторых, не уверен про 27й релиз, но когда-то столкнулся с ситуацией, что ПривязыватьСтроку() работает при групповом проведении как будто в едином контексте. То есть если в расходной накладной использовался ПривязыватьСтроку(НомерСтроки), то в следующем документе (приходной накладной) все движения по этому регистру шли с также привязкой к последнему номеру строки расходной накладной. А при интерактивном проведении приходной накладной привязки номера строки не происходит. Долго же я тогда пытался понять, откуда и в какой момент происходит привязка - оказалось при групповом перепроведении. С тех пор всегда в конце делаю ПривязыватьСтроку(0) после вызовов ПривязыватьСтроку(НомерСтроки).
Если конфигурация нетиповая ТиС, возможно обращение к остаткам сделано не через атрибуты переменной СоздатьОбъект("Регистры"), а через отдельные переменные типа СоздатьОбъект("Регистры.Остатки"). В таком случае также допускаю, что где-то что-то упущено из четвёрки Актуальность(1), ИтогиАктуальны(), ВременнныйРасчет(), РассчитатьРегистрыНа().

(40) ну так ждем, когда ТС сравнит до и после

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

Тогда просьба модератору закрыть ветку! надо будет - ТС откроет новую, посодержательнее ;-)

(42)а чего сравнивать-то, на момент перепроведения документа не хватате в регистре остатки количества . на момент проведения , раз провелся - хватало.

(45) всё сравнивать. Если после пересчета итогов хватает - значит, проверять, какиеитоги изменились

(46) ну изменились конкретно по одному товару , который был в пересортице .... партии почему не изменились , вот в чем вопрос собственно

(47) почему изменились, если итоги были верными?

(47) когда итоги были правильными - до пересчета, или после? с какого периода они изменились?

(48) Кто же его знает ? изменились итоги только в регистре остатки , в регистре партии итоги верные.
(49) до пересчета итоги по регистру остатки не верные , так как документ не перепроводится , а после пересчета итоги в регистре остатки и партии совпадают и документ перепроводится

(50) "до пересчета итоги по регистру остатки не верные , так как документ не перепроводится" - наверное наоборот? Отчетами-то эти остатки сверяли?

(51) почему наоборот ? В регистре парии-то есть остаток , а после пересчета итоги в регистре остатки = итогам в регистре партии . какими отчетами остатки сверять ?

(50)"до пересчета итоги по регистру остатки не верные , так как документ не перепроводится">> то, что "не перепроводится" - не показатель правильности или неправильности
я спрашивал про  ПРАВИЛЬНОСТЬ ИТОГОВ в контексте https://infostart.ru/public/61025/
В конце концов, сделай контроль итогов до перепроведения., и при остановке по ошибке - если в начале все итоги верные, а при остановке неверные - значит, кто-то ломает итоги. Тогда буду советовать, что делать дальше....

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

(53)(54) тут все прозаичнее , есть продуктовый магазин . Ведут на ТИС, после изменения какого-нибудь документа задним числом, делают групповое перепроведение начиная  с даты изменения документа. Никто остатки ежедневно не снимает . Периодически при перепроведении останавливается на документах возвратах или пересортице и дальше не проводится. Начинаем разбираться , не хватает в регистре остатки по товару остатков (пардон за тавтологию), в регистре партии все хватает.Делаем пересчет итогов , начинает хватать и в регистре остатков , проводим дальше ...

(55) Регламентный пересчет итогов ночью и забить :)

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

(56) как вариант

(56) "лучше день потерять, а потом за час долететь"©КНХ
Впрочем, та моя обработка как раз для контроля и выборочного пересчета итогов (по выбранному регистру и выбранному измерению за период начиная с, без монопольного режима и всё такое)  и предназначена. (55) дык этта... контроль итогов до и после (и перепроведения, и пересчета итогов) - делал или нет?

(55) и речь не про "ежедневные остатки", а про какие-нибудь зафиксированные остатки. на дату позднее точки перепроведения. чтобы быть уверенным, что остатки не плывут при перепроведении.

ТС нагло динамит. Выясняется, всё просто. Ведомость движения по остаткам и ведомость движения по партиям. Всё. Но посмотреть на этот отчёт по проблемному товару при ступоре проведения и после пере проведения которое исправляет ситуацию ТС принципиально не делает. Либо он немкопенгаген либо ему похрен. Так что и ветка себя изжила.
Причина почти стопудово с урбд связана. И смотрет ведомости как выше написал надо по одному и тому де товару если он повторно в ступор выпадает. ТС даже сообщения ступорные не привёл.