Остатки по регистру накопления не соответствуют движениям по этому регистру

1С:Предприятие 8.3 (8.3.13.1644)
УТ10.3, SQL
База большая, движений МНОГО
Простейший регистр накопления
Измерения: Склад, Номенклатура
Ресурсы: Количество, СуммаПродажная
Иногда обнаруживается, что остатки по регистру не соответствуют движениям по этому регистру.
   К примеру на конец месяца Остаток = 0 по каким-то измерениям. Движений по этим измерениям не было. Остаток на начало следующего месяца не равен 0!!!
   Полный пересчет итогов исправляет ситуацию. Это же ЖЕСТЬ

Заранее не известно, какие остатки не верные. Наблюдали такое поведение на разных платформах. И на разных регистрах.

Более того ужа обсуждали на Мисте подобное поведение платформы. С чем связано не поняли.

Волнуюсь...

(2) продолжай наблюдение (с)

8.3.13 в топку.
В типовой УТ 11 в описании к релизу ее не рекомендуют использовать.

(5) Мы и на 8.2 такое наблюдали.

(5) разве она при обновлении не требует как раз 8.3.13?

Это ты еще фантомные записи не видел, которые никакие ТиИ не исправляет

(7) не ниже 8.3.12.1685

Механизм регистров Остатки - это базовый механизм 1С. Если они за 20 лет "развития" платформы не отработали этот механизм, это значит, что что-то не ладно в этом королевстве

(10) Вероятно, добавили разделение итогов по базам и "зацепили"

в 7.7 такое же было ошибка в итогах регистра - как поправить
родовой баг

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

Вот обсуждали Различаются остатки по 68.02 на конец дня и начало следующего
И я писал
Я думаю, что это фича 1с83. Заключается она в том, что по неизвестной пока причине, остатки в виртуальной таблицы остатков на дату считаются некорректно.
Только сегодня я столкнулся с этой проблемой. Классический регистр остатков товаров в УТ10. Остатки на начало и конец  01.09 равны нулю. Движений за 02.09 не было. Остатки на конец 02.09 не равны нулю. При этом в отчете для интервала 01.09 - 02.09 остатки равны 0. Для интервала 02.09 - 02.09 остатки не равны 0.
   После пересчета регистров все встает на свои места.
   Раньше я сталкивался с подобным в партионном учете.
  Самое обидное, что нет гарантии, что вы получаете всегда корректные остатки.

Видите там все существенно хуже. Движений нет, а Остатки
1. На конец месяца равны 0
2. На начало месяца = 0
3. На 2 число НЕ РАВНЫ 0
4. На 3 число опять равны 0.

такой момент неплохо бы поймать скуль-профайлером и руками покрутить, что и как он там считает.

(15) В физической таблице итогов на скуле смотрел? Что там лежит?

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

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

Я не смотрел таблицу остатков но запрос типа
ВЫБРАТЬ * Из РегистрОстатков.ХХХ.Остатки(&ДатаСреза) дает остатки, а запрос
ВЫБРАТЬ * ИЗ регистрОстатки.ХХХ ГДЕ Период >=&ДатаСреза не дает движений

(19) Как могли интеграторы попортить виртуальную таблицу Остатки?

(21) Она не виртуальная.

(22) С точки зрения 1с - виртуальная. Т.е. программист не имеет прямого доступа к этой таблице

(17) >> В физической таблице итогов на скуле смотрел?

Судя по (15), ничего он там не увидит. Т.к. на начало и на конец месяца остатки нулевые. Значит по данным измерениям записей на интересующий период там не будет.

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

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

+ к (24) В таблице движений на скуле засели какие-то кривые записи. Из обычных случаев такое можно вспомнить, когда у записей стоит Активность = Ложь. В Остатках и Оборотах таких записей не будет. В движениях будут.
Тут может быть что-то похожее.

Думаю, когда в следующий раз увижу эту ошибку напишу запрос на сравнение движений и остатков на/по 2 число. Сейчас я уже исправил ошибку путем пересчета итогов регистров за 2018 год. А то менеджера уже почти закопали в лесу из-за "недостачи"

в 8.2 еще понятно, там в отчетах грязное чтение, но в 8.3 ...

каковы периоды рассчитанных итогов?

(23) Точно. Которая Остатки+Движения

(29) Итоги были рассчитаны по 01.01.2019 а остатки смотрелись по 02.12.2018

(28) ровно то же самое
(27) смотреть такое на уровне скуля надо а не 1С

Если бы этого не было, зачем был нужен пересчет итогов... Проблема целостности и работоспособности присуща любой сложной системе.

(33) например для "сжатия" итогов

у меня для платформы из сабжа обнаружены 3 бага

1. не работает в конфигураторе остановка поиска по Ctrl+Break
2. при работе с деревом при скролинге полностью свернутого дерев иногда происходит сдвиг текста полей
3. для помеченых на удаление БП не работает право "Разрешить удалять помеченые", в результате обработки удаления не видят помеченные БП... приходится давать право непосредственного удаления, что не верно...

(35) все три бага довольно неприятные...

(35) 1. Не работает только в терминале. Локально работает. Проверено на .12 и .13

(37) у меня не работает везде... и не только у меня, у всего отдела...

(38) + 1
Ни в каком виде не работает

(38) (39) Ну не знаю, у меня работало. На вин10 причём.

(40) тоже буквально вчера дома на вин 10 обожмакался  Ctrl+Break при поиски. ТАк и не смог прервать

(35)
8.3.13.1690 - поиск в пофигураторе прерывается
ЗЫ: проверено со снегопатом.
Могу и на чистом пофигураторе проверить

и это в терминале

ЗЫ: проверил на чистом пофигураторе - тоже прерывается.