Имя: Пароль:
1C
1C 7.7
v7: Оборотка по 51 счету
,
0 okeahchik
 
02.10.12
18:33
Добрый день.
Ситуация следующая:
База самописная на основе ПУБ 77. Файловый режим (вся база весит около 6 ГБ, знаю, что нужен SQL).
Кодовая страница (+ текущая системная установка).
Периодичность хранения остатков - месяц.

ОСВ по 51 счету (и карточка счета) показывает неверные сальдо и обороты за день.
Пример:
За период с 01.09 по 12.09 сальдо и обороты отображаются верно.
Строю отчет с 12.09 по 12.09 - неверно.
С 1 по 13 - верно.
С 13 по 13 - неверно.
и т.д.
(со 2 по любое число тоже неверно, и т.д.)

При неверном отображении сальдо по счету отображается отрицательные миллионы. А верные остатки порядка десятков тысяч.

Пробовал:
-ТиИ со всеми включенными галочками (кроме сжатия таблиц).
-Полный пересчет бух итогов
-Удаление файлов dbf и cdx(accsel,1SBKTTL,1SBKTTLC,1ssbsel) с последующим полным пересчетом бух итогов.
-Распровел все документы с 31.08. Провел одно поступление ДС от 12.09 для контроля. С 1 по 12 отчет верный. С 12 по 12 - неверный (т.е. ничего не изменилось)
-Искал в файле 1SENTRY через viewer зависшие проводки по 51 счету (т.е. без существующих документов). Нашел только бух.операцию, введеную вручную от 31.08.12. Удалил ее из файла 1SENTRY, удалил операцию из 1С, пересчитал бух итоги в режиме предприятия - не помогло.

Сейчас:
Анализирую архивы с 01.09 на каждый день. Хочу локализовать день, с которого все сбилось.

Прошу советов и рекомендаций.
1 Нуф-Нуф
 
02.10.12
18:53
1. анализируй архивы
2. переходи на 8ку
2 okeahchik
 
03.10.12
12:59
Определил по архивам, что началось все с 24.09.12.
Т.е. архив за 23.09 нормально формирует ОСВ.

Удалил файл 1SENTRY:
ОСВ формируется 01.09 по любое число месяца верно.
Начиная со 2-го - нет проводок (вроде все логично).
Сформировал заново проводки за сентябрь регламентным документом "Формирование проводок" - ничего не изменилось.

Ищу дальше.
3 okeahchik
 
03.10.12
19:37
1) Удалил все файлы cdx, восстановил монопольно - не помогло
2) Удалил файл 1sjourn - не помогло
3) Загрузка - выгрузка не помогла, хотя база стала на 2 гига меньше весить

Ищу дальше
4 НикДляЗапросов
 
03.10.12
19:48
сверни базу
5 hhhh
 
03.10.12
22:03
(3) зачем ты файлы удаляеншь? просто сделай пересчет итогов.
6 Эльниньо
 
03.10.12
23:35
1SBKTTLC.dbf скока весит?
7 Эльниньо
 
03.10.12
23:36
+(6) 1SBKTTLC = 1SBKTTL
8 Dolly_EV
 
04.10.12
16:05
Если 1SBKTTLC, 1SBKTTL больше 1Гб, то все шаманства с удалением/пересчетом/передвижкой взад-вперед итогов помогут ... или ненадолго, или совсем не помогут)).. можешь не рыть архивы, и не догонять день "когда все сбилось". "С 01 по 01 - верно, с 01 по 02 - красно" - до боли знакомая тема)))

два варианта:
1. SQL
2. резать базу

ну еще альтернативный вариант: http://infostart.ru/public/15211/

Но, имхо, если базе светит жить долго, то чем быстрее переберешься на СКЛЬ + прямые запросы, тем меньше геморроя наживешь))
9 Он
 
04.10.12
16:16
(8) Это самые популярные грабли.
10 okeahchik
 
04.10.12
16:37
Всем спасибо, проблема решилась.
Проблемную базу загрузили в SQL - все итоги сошлись, все работает.
11 Dolly_EV
 
05.10.12
04:55
(10) Что сказали юзеры по поводу скорости работы на СКЛь?)))