Добрый день. Стоит 1С УПП.
Различаются остатки по счету БУ 68.02 на конец 2 квартала и начало третьего.
Причем если делать с 2 апреля по 30 июня, то тогда совпадает с остатками на начала 1 июля. А вот если с 1 апреля делать по 30 июня, тогда уже отличаются.

Вопрос, тут только итоги могут быть виноваты и надо с апреля пересчитать или ещё что то может на это повлиять?
(итоги пока не могу пересчитать)

(0)[итоги пока не могу пересчитать]
дык копию сними

(1) прав нет, админы только с утра будут уже, поздно))) С утра то запрошу и проверю в копии сразу.

(0) Посмотрите, были ли движения на конец периода 23:59:59, если есть, то переделайте их на 23:59:58 или просто смотрите на начало периода

(3) так проблема не в конце периода, а чуть ли не в начале. Вообще сам документ, на сумму которого различается, сделан 18 апреля.  Но почему то если делать оборотку с 18 апреля по 30 июня, то всё хорошо. Косячит лишь если сделать с 1 апреля по 30 июня.

Как вообще документ от 18 апреля влияет на 1 апреля интересно...там ни корректировок ничего нет...

А если подробно делать, с 1ого апреля в оборотке документа вообще нету? а с 18ого он появляется? или вы только различие по сумме видите?

(4) если с 1 на 2 апреля. Это 100% итоги. Других варантов нет.
Поэтому дальнейшие рамышления бесполезны.

(6) а просто ради интереса, как документ от 18 апреля влияет на итоги 1 апреля? Ладно бы с 1 мая косяк был.

Как то никогда не заморачивался итогами, за все 13-14 лет работы всего несколько раз глюки были с итогами, всё норм обычно работает.

(7) период с 1 апреля по 30 апреля   - у вас задействованы итоги на 1 апреля и на 1 мая.

период с 2 апреля по 30 апреля   - у вас задействованы итоги только 1 мая.

вот и вся разница

(7) а что итоги на каждый день хранятся, что у вас они как-то влияют с разницей 1 день?

(9) итоги хранятся помесячно. Но если сбиваются, то только 2-числа. По другому никак.

Вы не поверите, но тут все разжевано:
https://its.1c.ru/db/metod8dev/content/2726/hdoc

(8) (10)  Понял, спс за инфу. Завтра на копии проверю тогда.

Итоги можно из режима предприятия посчитать.
Поставь рассчитанные итоги на 1 июня и рассчитай, потом верни обратно

(13) ну монопольный режим то всё равно требует

(14) нет

(8) (10) сомнительное утверждение...
Вообще логика применения итогов достаточно проста.
Как пример, почему у автора в одном случае работает, а в другом нет. Скорее всего действительно итоги.
К какому месяц ближе начало периода формирования отчета, те итоги и выбираются.
2 апреля ближе к 1 апреля, поэтому берутся итоги 01.04.18
18 апреля ближе к 01.05.18.
Все остальное рассчитывается по таблице движений до ближайших рассчитанных итогов или конца периода отчета
Но, чтобы за 1 месяц применились итоги взятые за 2 месяца это нечто

можно попробовать включить - выключить проводки у проблемного документа, програмно

(16) итоги всегда с конца. 2 апреля считается от итогов 1 мая. Не знаете так не говорите. В 7.7 прямо видно внизу как этот делается.

(16), (18) Оба правы и неправы

(19) жги =)

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

Просто иногда вы видите ошибки, но чаще всего - нет.

(21) вот в этом и дело, фиг знает когда такая ошибка вылезет. И ладно если заметили, а если глюк тянется и тянется, а никто не обращает внимания...

(23) Единственно, что радует, так это то, что ошибки не накапливаются. И ошибки касаются только остатков на определенный момент времени

(21) (23) https://images.ua.prom.st/1221140881_w800_h640_1c_5big.jpg

(16), (18), (20)
Обратите внимание на
"CAST(SUM(T2.Fld24Balance_ + T2.Fld24Turnover_)
|        AS NUMERIC(35, 8)) AS Fld24FinalBalance_
|                                // КонечныйОстаток"

http://1sprogress.ru/anatomiya-registra-nakopleniya-virtualnaya-tablica-ostatkiioboroty.html

(10) а можно вопрос - как сбить итоги?

(27) Я подозреваю, что виртуальная таблица остатков сбивается при непосредственном удалении объектов. ТИпа при Документ.Удалить()  движения чистятся, а виртуальная таблица остатков - нет, либо чистится криво.

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

(28) У меня было пару недель назад. Сбивались в БП итоги на 51 счете (остальные счета были нормальные). А 51 выписка, там нет в типовой непосредственного удаления

(29) это типа массового проведения документов что ли?

(28) а такое делают??? )))) Удалить()

(31) Лично мною это неоднократно было замечено при записи движений в режиме загрузки, особенно в нескольких параллельных сеансах. При проведении такой режим записи (загруза = истина) исключен, и в этом случае какого-то гемора в ОСВ замечено не было

(33) ну тогда обмены, но там нагрузка совсем мелкая в этой базе.

P.S. не ожидал, что нафлудим даже 10 сообщений тут...

(18) "итоги всегда с конца" // Не всегда: зависит от того, рассчитан ли месяц, в который входит параметр (граница среза), и включены ли текущие итоги

Было такое подобное... еще на 8.3 старых старых реакций...
Помогал пересчет итогов, а даже как то выгрузка/загрузка ИБ в DT

Гарантированно помогает только пересчет итогов из пофигуратора. И, увы, это будет пересчет всех регистров, т.к. там выборочно нельзя его сделать.
Другое дело, что никогда не знаешь, что у тебя с итогами настала *опа...