Вообщем столкнулся с такой вещью:

Имеем расчет в марте 2019:

ХВС 8
ГВС 5,1667

ВО расчитываем базой от этих услуг и получаем 13,1667

Все верно.

Имеем перерасчет за март в апреле 2019

ХВС 8
ХВС -8 сторно
ГВС 5,1667
ГВС -5,1667 сторно

ВО 13,1667
ВО -13,1667 сторно

Все верно.

Имеем перерасчет за март в мае 2019 (вдруг оказалось что период действия надо разбить на два с 01-21 марта и с 22-31 марта, больше ничего не изменилось)

ХВС 5,7931 01-21
ХВС 2,2069 22-31
ХВС -8 сторно

ГВС 3,7414 01-21
ГВС 1,4253 22-31
ГВС -5,1667 сторно

ВО 18,4539 01-21
ВО 7,8795 22-31
ВО -13,1667 сторно

И вот тут огромная проблема. По ГВС и ХВС все верно. А вот ВО 18,4539 + 7,8795 = 2 * 13,1667. Не пойму где ошибся и как бороться. При этом если сразу считать без сторнирования все считает правильно.

При этом путем нехитрых вычислений получается что цифра за период с 22-31 по ВО расчитано следующим образом 13,1667 * 10/31 + 1,4253 + 2,2069 = 7,8795. Т.е. при расчете базы не учитывается сторнирование.
---
Вообщем я самостоятельно разобрался в данном вопросе. Ситуация заключается в следующем:

Кроме участвующих в расчете базы измерений с марта в конфигурацию было внесено дополнительное измерение. Заполняется оно при проведении документов в данный регистр на основе реквизитов измерения "Лицевой счет". Т.о. возникла ситуация при которой у сторно записи данное измерение было заполнено, а у первичной записи, сделанной ранее нет. Это и повлекло данную ошибку. После заполнения ошибка ушла. Хотя странно. Данное измерение в запросе базы не участвует.
---
ХВС 5,7931 01-21 + ГВС 3,7414 01-21 =9,5345, ПОЧЕМУ 18,4539?
---
этот вопрос меня и тревожит
---
Так нужно посмотреть расчет - где, как и сколько. Что за конфигурация, каким документом проводится расчет. Без отладчика не обойтись.
---
Моя конфигурация. Запрос базы по регистру расчета возвращает данную цифру. Отладчиком видно результат запроса. Не более. Данная проблема возникает при двойном сторнировании. Во вложении записи регистра расчета в файле Ошибка базы. В файле РезультатЗапроса собственно следующего запроса:

 Запрос.Текст = "ВЫБРАТЬ
                | ЕСТЬNULL(ОсновныеНачисленияБазаОсновныеНачисления.ПотреблениеФактБаза, 0) КАК ПотреблениеФактБаза,
                | ОсновныеНачисленияБазаОсновныеНачисления.РегистраторРазрез КАК РегистраторРазрез,
                | ОсновныеНачисленияБазаОсновныеНачисления.ПериодРегистрацииРазрез КАК ПериодРегистрациРазрез,
                | ОсновныеНачисленияБазаОсновныеНачисления.ВидНачисленияРазрез КАК БазовыйВидНачисления,
                | ОсновныеНачисленияБазаОсновныеНачисления.НомерСтроки КАК НомерСтроки
                |ИЗ
                | РегистрРасчета.НачисленияУслуг.БазаНачисленияУслуг(
                | &парамИзмеренияОсновногоЛицевойСчет,
                | &парамИзмеренияБазовогоЛицевойСчет,
                | &РазрезБазы,
                | ПериодРегистрации = &ПериодРегистрации
                | И Строение = &Строение
                | И Регистратор = &Регистратор
                | И НомерСтроки В
                | (ВЫБРАТЬ
                | ВТ_НомераСтрокЛицевойСчет.НомерСтроки
                | ИЗ
                | ВТ_НомераСтрокЛицевойСчет)
                | И НЕ Сторно) КАК ОсновныеНачисленияБазаОсновныеНачисления
                |ГДЕ
                | НЕ ОсновныеНачисленияБазаОсновныеНачисления.РегистраторРазрез ССЫЛКА Документ.КорректировкаНачисленияКоммунальныхУслуг
                | И (НЕ ОсновныеНачисленияБазаОсновныеНачисления.ВидНачисленияРазрез = ЗНАЧЕНИЕ(Перечисление.ВидыНачисленияУслуг.ОДН)
                | ИЛИ ОсновныеНачисленияБазаОсновныеНачисления.ПериодДействия >= ДАТАВРЕМЯ(2013, 6, 1, 0, 0, 0))
                |
       |
                |УПОРЯДОЧИТЬ ПО
                | НомерСтроки,
                | ПериодРегистрациРазрез,
                | РегистраторРазрез";
---
Надо смотреть расчет сторнирования. В этой ситуации мне кажется, что нужно сторнировать базу, а расчетные данные сторнируются как-то в автомате.
---
Круто , где тока зуп не применяют! С измерениями / разрезами косяков нет?
---
Ну тут не ЗУП а регистр расчета все же. Да и при начислении коммунальных услуг это очень логично поскольку очень похоже на расчет зарплаты. В том то все и дело что визуально все красиво. И измерения и разрезы. Но вот расчет базы возвращает ерунду. Причем возвращает ерунду при наличии сторно в разных периодах регистрации. Такое ощущение что он забывает про одну из записей сторно. Как будто схлопывает.
---
там потом еще база для льгот с какими то прибамбахами была ( по крайней мере у нас :-))
---
Я конечно могу на собственный запрос для формирования базы переписать. Но как же хочется сделать по человечески то. Причем с подобным косяком я в ЗУПе сталкивался. Тоже при многократном пересчете одного сотрудника. Вот думаю как победить. Льгот нет у меня. Соцзащита сама возмещает.
---
Выглядит как глюк платформы, но по моему вряд ли 1с это поправит в обозримом будущем?
---
благодаря вашему сообщению я начал думать в нужном направлении и проверять заполненность измерений записей регистров. Там и была ошибка. 0.5 ваши)))
---
Я Очень рад за Вас. И спасибо за подарочек!
---
Вообщем я самостоятельно разобрался в данном вопросе. Ситуация заключается в следующем:

Кроме участвующих в расчете базы измерений с марта в конфигурацию было внесено дополнительное измерение. Заполняется оно при проведении документов в данный регистр на основе реквизитов измерения "Лицевой счет". Т.о. возникла ситуация при которой у сторно записи данное измерение было заполнено, а у первичной записи, сделанной ранее нет. Это и повлекло данную ошибку. После заполнения ошибка ушла. Хотя странно. Данное измерение в запросе базы не участвует.