1С77 - обороты и остатки по общей ОСВ и ОСВ по счету не совпадают
 

1с77 комплексная, нетиповая. Говорим о компоненте бух.
Такая ситуация.
1.Делаю ОСВ (общую) за один день 31/01/2008. По субсчету-группе 90.9 (АП) есть обороты и остатки, причем субсчета 90.9.1, 90.9.2 - пустые. Соответственно, по двойному клику открытая карточка счета из общей ОСВ - пустая.
ОСВ конкретно по группе 90.9 и счетам 90.9.х - пустая.
2. Включаю проводки единственной в этом дне операции, двигающей 90.9.х. В ОСВ по счету эти проводки корректно отображаются, в общей ОСВ эти проводки добавляются плюсом к проводкам группы 90.9, а при открытии карточки счета из общей ОСВ - данные как в ОСВ по счету, т.е. верные.
Вроде как проводки по счету-группе сделать нельзя, но выходит, что они вроде как есть.
Что делал:
0. Заменил общую ОСВ на общую ОСВ из типовой бух 538 - не помогло.
1.Делал отчетик с проверкой
Если Опер.Дебет.Счет = СчетПоКоду("90.9") Тогда Сообщить("Да!")
и
Если Опер.Кредит.Счет = СчетПоКоду("90.9") Тогда Сообщить("Да!")
Никакого "ДА!" в окне сообщений не появилось ни при включенных проводках операции, ни при выключенных.
2. Пересчитывал итоги - не помогло.
3.Удалял 1SBKTTL*.*, пересчитывал итоги - не помогло.
4.Делал выгрузку-загрузку - не помогло.

Где рыть?
Спасибо даже тем, кто дочитал :))

может, какие настройки ОСВ глючат? cfg сносил?

зы: да и попутно cdx тоже физически снести никогда не помешает.. хотя это вряд-ли причина..

(0) если база dbf посмотри максимальные размеры файлов (есть ли приближающиеся к 1Гбайту, например 1SENTRY.DBF)

1-Блондинка в шок > cfg не сносил. Попробую. Индексы физически удаляются каждую ночь при рез.копировании.
2-Write > База dbf, 1sentry.dbf 0.5Гб.

Тяжело исследовать альтернативно одаренную конфу, не видя ее, но вывод "[em]Вроде как проводки по счету-группе сделать нельзя, но выходит, что они вроде как есть[/em]" - не обоснован: одно дело [b]сделать проводку[/b] по счету-группе, совсем другое [b]получить движения[/b] по счету-группе. Первое - низзя, второе - обычное дело.
Так что суть претензий непонятна.
P.S. Лучше использовать метод [em]ПринадлежитКГруппе()[/em] или конструкцию [em]Если (Найти(строка(Опер.Дебет.Счет) ,"90.9")=1 Тогда[/em]

+4 И зачем делать за день (или после каждой операции?) (а счет 90.9 - [b]итоговый[/b], формируется Закрытием месяца) - знают только альтернативно одаренные бухгалтера.

(3) это самый большой DBF?
Попробуй пересчет сделать следующим образом:
1. Установи итоги на период когда нет движений в базе.
2. Затем поквартально ручками меняй период (поглядывая в общую ОСВ) и так до текущего периода.

cfg снес - не помогло.
5-VZ > Перевариваю ...

я бы ТиИ - на копии прогнал , шоб так сказать ...

Нефиг тут гонять, разве что 1Сника ссаной тряпкой.

В типовой комплексной 90.9 - [b]не группа[/b]. Так что все вопросы к тому, кто изменил вид счета в конфигураторе, не позаботившись предварительно об изменении существующих проводок. То есть, к "нетиповому" программисту.

7-Asvel >Ну, а чО здесьсложного-то... Счет 90 - финансовые [b]результаты[/b], не оперативный учет. Обнаруживаются вовсе не равномерно: 90.1 - сразу при продаже; 90.2 - когда становится известной себестоимость (а в общем случае - это не только стоимость покупки), затраты на оплату труда, всякую шелупонь, вроде покраски забора - в конце месяца обычно, и т.д. Т.е., сводную картинку (баланс деятельности по деньгам) на сей момент ("к обеду в пятнице") получить никак не можно.
Потому получаем (обычно) в конце периода (месяц), подбивая все данные по расходам.
Потому и вызвала удивление фраза "ОСВ по счету 90.9 за [b]день[/b]"...

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

6-Write > Да, самый большой
8-101 > Делал ТиИ
9-Ткачик > Возразить нечего, не помню, может, именно я не позаботился. А может и до меня.
10-VZ > ОСВ делал за день, т.к. все равно одна операция, двигающая 90.9.1
11-Гена > Не развод. Общей ОСВ бухгалтер не пользовалась, а ОСВ по счету "показывала" правильно.
з.ы.
У меня просьба: давайте не будем обсуждать прав был ли программист в 2001-2007 г.г. или бухгалтер, которая не пользовала ОСВ. Я вроде как не кичусь своими знаниями и не говорю, что кто-то виноват, а не я. Можете - помогите, нет - спасибо за участие в теме...

Сделал запрос с корректировкой по предложению VZ. Действительно, в окне сообщений задвоенные записи по сравнению с теми, что вижу в операции. Именно в удвоение идет по группе 90.9 в сравнении с 90.9.1.

(12) То есть, ты просто не знаешь что делать? Тогда подсказываю: можно поискать в Инете специализированную обработку для подмены счетов в проводках, а можно воспользоваться и стандартной UChoice.ert, если способен ее настроить.

Помнится, я в подобной ситуации обходился именно UChoice, обрабатывая ею объекты типа "Операция".

К (13): лоханулся в отчете: два раза сообщить() ...
14-Ткачик > Подменить счет в проводке я смогу без UChoice, я не могу найти эту проводку ...

Буду пробовать как Write в (6) рекомендовал.

16-Asvel >Не поможет. Ситуация весьма похожа на впиндюривание субсчета, начхав на то, то остались движения по преобрахованному счету. Помнится, было описание на Т1С этого варварского способа в режиме "Предприятие".
Надо чинить обороты. ТиИ здесь не поможет. Обормотка по этому делу - да, справится.

(17) а просто полный пересчёт итогов или снос cdx ?

18-Гена > Пересчет есть пересчет: изменяются итоги, а движения бережно и трепетно остаются в исходном состоянии.
Индексы вообще не при делах: это просто инструмент сортировки записей при чтении.

(15) Я бы в таком случае залез в DBF.

18-Гена > Делал
17-VZ >VZ, вы правы, в принципе и мои догадки подтвердились. Нашел операцию от 31.01.2008, в которой в качестве счета выступает группа. Но КАК? Спрашиваю КАК, потому что в 2007 году есть проводки на 90.9.1 ...

а если сначала стандартно убрать субсчета с 90.9, а потом стандартно опять завести?

(21) меняли после заведения данной операции
ЗЫ возможно даже напрямую в дбф

21-Asvel >Как, как... Есть альтернативно одаренные ломать все, что в поганые ручки попалось. "Защита от дурака" не всегда срабатывает: разработчику зачастую не приходит в голову возможность диких и алогичных желаний юзеров ;)
22-Гена > Мнится, что надо исправлять не "где наткнулись", а подойти серьезно, проанализировать в целом, а потом просеять движения по всей базе.
При наличии обормотки я могу просеять и исправить за десять лет в течении получаса.

я вот не понимаю - ну ЗАЧЕМ лепить субсчета в типовом ПС? ну лепите новое субконто, если приспичило...

23-101 > Т.е. глюканула конкретно эта операция? Ведь в 2007 году все нормально. Напрямую в дбф нет, так как был уже я, а такого я делать не умею.
24-VZ > Обжегжись несколько раз, всегда стараюсь делать аккуратно.

Сейчас сделаю с ВыбратьОперацииСПроводками

Опер = СоздатьОбъект("Операция");
Опер.ВыбратьОперацииСПроводками(ВыбНачПериода,ВыбКонПериода,"90.9");
Пока Опер.ПолучитьПроводку() = 1 Цикл
Сообщить(Опер.Дебет.Счет);
КонецЦикла;
Отлавливает счета-группы в проводках. Буду знать.

23-101 >Не обязательно. Достаточно дать возможность бухгалтерам править операции документа - оне такого наворотят... И фиг отследишь.
Потому первое, что делаю, беря на сопровождение базу, это запрещаю запись а ПС, и правку операций напрямую.

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

+ чисто теоретически может и "сбой" как бэ , но мнится мне что данные казусы еще и при УРБД возможны ... тоже весч в себе - она (УРБД) пишет движения регистров и прочую составляющую сразу в таблицы - и проверяет таблицы а не признаки ...

Отключил проводки "злосчастной" операции - все пошло.
Причину происхождения этой операции так и не понял.

Всем спасибо за помощь, в особенности VZ.

29-101 >Петя описывал, как дает ;) Именно через Предприятие, и конфа не пищщит...

(32) нада проверить будет, что то такого эффекта не добивался ;)) видимо не хотел изначально добиться , будем пробовать