gifts2017

Решение проблемы с открытием периода ТиС

Опубликовал Виктор Земсков (zemskov) в раздел Администрирование - Тестирование и исправление

Способ решения проблемы с открытием периода в конфигурации "Торговля и склад" версии 7.7 (вызванной регистром "Книга продаж")

Довелось столкнуться с такой вот ситуацией: более 10 лет используется конфигурация "Торговля и склад". Очень даже успешно используется, была немного доработана, работает быстро, делает что нужно. В общем, идиллия. Но ничто не длится вечно...

В один "прекрасный" день, а точнее в ночь на первое число как обычно в монопольном режиме попытался открыть период, и вот тебе раз:

Ошибка при открытии периода

Очень даже не вовремя. Первое число выпало на среду, нужно работать, а никак. База довольно большая, поэтому тестирование и исправление не помогло ни в каких вариантах. За первую ночь ничего не решил. Единственным выходом было установить рабочую дату на последний день прошлого месяца и работать таким образом. Здесь необходимо отметить, что этот вариант следует использовать только в качестве крайней меры, так как все сопутствующие документы также придётся заводить этой датой. В первую очередь это касается документов поступления. Чтобы не возникло путаницы, в будущем мы договорились в комментарии документов указывать реальную дату и ручками после решения проблемы вернуть всё на круги своя.

Итак, полумеры были приняты, взялся за дело. Так что же такое за "Error #: -120"? Выяснить не составило особого труда. Эта ошибка возникает, когда размер файла dbf превышает 2Gb. Не буду утверждать на 100%, но это вроде как не только проблема базы данных 1С версии 7.7, но и всех DBF в целом. Отсортировал все файлы в базе данных по размеру и действительно: удивительно, поразительно. Он единственный такой большой, следующий по величине в три раза меньше.

Первым делом посмотрел файл 1Cv7.DD, который содержит описание всех таблиц информационной базы. Оказалось, что это регистр "Книга продаж"

#===============================================================================
#==TABLE no 157    : Регистр КнигаПродаж
# Name    |Descr                         |Type[A/S/U]|DBTableName|ReUsable  
T=RG4343  |Регистр КнигаПродаж           |A          |RG4343     |1         
#-----Fields-------
# Name      |Descr               |Type|Length|Precision
F=PERIOD    |Period Registr      |D   |8     |0        
F=SP4336    |(P)КредДокумент     |C   |13    |0        
F=SP4337    |(P)СтавкаНДС        |C   |9     |0        
F=SP4365    |(P)ВидДолга         |C   |9     |0        
F=SP4338    |(P)СуммаНДС         |N   |16    |2        
F=SP4339    |(P)СуммаРуб         |N   |16    |2        
F=SP4340    |(P)СуммаНП          |N   |16    |2        
#----Indexes------
# Name     |Descr         |Unique|Indexed fields                                              |DBName     
I=PROP     |PERIOD+PROP   |0     |PERIOD,SP4336,SP4337,SP4365                                 |PROP       
#

Первое, что пришло в голову, это ещё раз попробовать сделать тестирование и исправление со следующей комбинацией галок:

Пересчёт итогов

   При просмотре файла выяснилось следующее: в колонке "Period Registr" стоял 2005 год и записей было очень много, потом 2006, 2007 и так далее. Так как эти записи относились к более ранним периодам, а документы в журнале начинались с 2011 года, соответственно было сделано предположение, что кто-то сворачивал базу, может и неоднократно, но вероятно, немножко кривыми ручками. Предполагалось, что после пересчёта итогов лишние записи уберутся и останется только изящно запустить тестирование и исправление ещё раз, но уже только с одной галкой "Упаковка таблиц информационной базы".

   На это была убита ночь со среды на четверг, но к огромному огорчению, к открытию магазина процесс не завершился, пришлось всё останавливать, доставать базу из архива и работать опять на 31 числе прошлого месяца. К сожалению, я не смог придумать никакого способа хотя бы примерно оценить время выполнения данной операции, а в данном случае эта оценка весьма бы пригодилась для принятия решения.

   Ситуация начинала уже раздражать. Всегда неприятно ощущать бессилие перед программой. Попросив пользователей ещё денёк поработать на 31 числе на ночь с четверга на пятницу была предпринята попытка свернуть информационную базу за 2 года в надежде сократить размер злополучного файла.

   Как только завершился рабочий день, разумеется сделав архив, запустил свёртку базы на 1.01.2013 года, так как документы там были с января 2011 года. Утром с огорчением увидел, что процесс ещё во всю идёт, а уже нужно начинать работать. Опять попросил уже изрядно нервных пользователей потерпеть, и стал думать, ЧТО ЖЕ ДЕЛАТЬ???!!!!

   Слава Богу, суббота и воскресенье выходной и соответственно и плечо раззудится, и рука размахнётся. В пятницу после завершения рабочего дня, быстренько сделал архив и снова запустил свёртку на мощном сервере. Но для надёжности взял домой базу, чтобы не класть все яйца в одну корзину.

   Пока сервер мощно гонял электроны по многочисленным ядрам своих процессоров и усердно жужжал дисками, свёртывая базу, было решено решить проблему кардинально. Разумеется, было страшно, не натворю ли я дел? Поэтому было решено вспомнить об устройстве этого регистра.

   Пришлось порыться в документации. Основное назначение регистра "Книга продаж" — оперативное ведение учета НДС по каждому покупателю. Залез в конфигурацию, просмотрел, как он работает:

Книга продаж

Нажал на волшебную кнопочку "Описание" и узнал всё, чо нужно:

Регистр "Книга продаж" предназначен для ведения учета НДС, выставленного
покупателям в расходных документах. Движение приход регистра производится при
проведении документов реализации ТМЦ и услуг покупателям и движение расход - при
включении сумм в книгу продаж (документами "Формирование книги продаж" и
"Запись книги продаж"). По этому регистру производится построение отчета "Книга
продаж".

СТРУКТУРА РЕГИСТРА "КНИГА ПРОДАЖ"

ИЗМЕРЕНИЯ

КредДокумент
Здесь проставляется значение документа, которым были реализованы ТМЦ или услуги
покупателю.

СтавкаНДС
Ставка НДС.

ВидДолга
Вид долга, может принимать значения из перечисления "Виды долга". Практически
означает бухгалтерский счет, на котором ведется учет выставленного покупателю НДС.

РЕСУРСЫ

СуммаРуб
В этом ресурсе ведется учет суммы продаж всего, включая НДС и НП, в валюте
бухгалтерского учета.

СуммаНДС
В этом ресурсе ведется учет суммы НДС продаж, в валюте бухгалтерского учета.

СуммаНП
В этом ресурсе ведется учет суммы НП продаж, в валюте бухгалтерского учета.

РЕКВИЗИТЫ

КодОперации
Код хозяйственной операции движения.

ДокументОплаты    
Документ оплаты задолженности. Документ оплаты, по которому произошло
включение в книгу продаж. Проставляется при формировании движения по
включению сумм в книгу продаж.

СтавкаНП
Ставка НП продажи. Проставляется при проведении документов реализации. 

Возможно, кому-то это регистр крайне необходим, но похоже, это не наш случай, и я подумал, раз десять лет этот регистр горько не был никому нужен, то и дальше не понадобиться. А что если удалить из него все записи?

   А дальше как в песне, "как легко на плоской карте стрелку начертить, а потом идти придётся через горы и овраги....". Нужен был инструмент для выполнения данной операции. Так как я не любитель копаться в dbf, взял то, что подсказал Яндекс. И был это DBF Commander. Обалденная программа, на 20 дней выдаётся бесплатно. Разумеется, можно было взять любую другую, но зачем тратить время, если она позволяет добиться результата. Повторюсь, ни в коем случае не рекламирую эту программу, подойдёт любая, позволяющая удалять записи из DBF и паковать его, даже Visual FoxPro.

   Открыл при помощи DBF Commander файл RG4343.DBF, там оказалось почти 25000000 записей!!! Открывался файл минуты три. В меню "Правка" оказался очень удобный пункт "Удалить все записи", им я и воспользовался. Commander жевал файл почти час, уже готов был испугаться, но наконец-то все записи покраснели. Осталось только выбрать следующий пункт "Паковать таблицу".

   После этой процедуры файл из многотонного бегемота больше двух гигов превратился в пушинку 257 байт. Не забыв удалить индексный файл RG4343.CDX, запустил программу в монопольном режиме. Индекс моментально перестроился и вышло приглашение открыть новый период.

   С замиранием сердца я ждал результат. И вот он сладкий миг победы!!! Период открыт! Причём очень быстро. Попробовал перепровести несколько реализаций, всё хорошо. Они вызывают записи в RG4343.DBF, но с нулями в колонках.

   На всякий случай обратился ещё раз к 1Cv7.DD:

#===============================================================================
#==TABLE no 158    : Регистр (Дв.) КнигаПродаж
# Name    |Descr                         |Type[A/S/U]|DBTableName|ReUsable  
T=RA4343  |Регистр (Дв.) КнигаПродаж     |A          |RA4343     |1         
#-----Fields-------
# Name      |Descr               |Type|Length|Precision
F=IDDOC     |ID Document's       |C   |9     |0        
F=LINENO    |LineNo              |N   |4     |0        
F=ACTNO     |Action No           |N   |6     |0        
F=DEBKRED   |Flag Debet/Kredit   |N   |1     |0        
F=SP4336    |(P)КредДокумент     |C   |13    |0        
F=SP4337    |(P)СтавкаНДС        |C   |9     |0        
F=SP4365    |(P)ВидДолга         |C   |9     |0        
F=SP4338    |(P)СуммаНДС         |N   |16    |2        
F=SP4339    |(P)СуммаРуб         |N   |16    |2        
F=SP4340    |(P)СуммаНП          |N   |16    |2        
F=SP4341    |(P)КодОперации      |C   |9     |0        
F=SP4342    |(P)ДокументОплаты   |C   |13    |0        
F=SP5345    |(P)СтавкаНП         |C   |9     |0        
#----Indexes------
# Name     |Descr         |Unique|Indexed fields                                              |DBName     
I=IDLINE   |of IDDOC+LineN|0     |IDDOC,LINENO,ACTNO                                          |IDLINE     
#

   Это движения того же самого регистра. Он содержал около 350000 записей. На всякий случай зачистил и его. В результате получил значительное ускорение работы всей базы.

   Возможно, у проблемы было и другое решение. Если интересно, давайте обсудим.

   Зачем я всё так подробно описал? А потому, что ситуации у всех разные и не нужно, возможно, стрелять из пушки по воробьям. Может, кому-то поможет тестирование и исправление, а может просто прочтение этого материала натолкнёт на спасительную мысль.

   Надеюсь, моя статья кому-то поможет.

См. также

Подписаться Добавить вознаграждение

Комментарии

1. andrewks 05.06.16 21:16
жесть какая, и это вместо того, чтобы просто удалить два dbf и два cdx и запустить в монопольном режиме
vbuots; AlexLM75; apatyukov; const000; NoRazum; KRJ; +6 Ответить
2. Виктор Земсков (zemskov) 05.06.16 22:01
Не поленился, проверил. Действительно получилось. Где же вы раньше были?
Я думал, что 1С только индексы умеет восстанавливать. Теперь буду знать. Спасибо.
3. Vladimir Polyakov (spectre1978) 05.06.16 22:17
10 лет и быстро работает? Документооборот, видимо, небольшой. У меня после пяти лет начали довольно чувствительно щекотать блокировки при обращении к журналу документов, даже с учетом того что юзеров около 10. Пришлось удалять доки и переносить остатки. А по существу - да, можно удалять DBF и она их пересоздаст. Я обычно всегда так и очищал файловую семерку - удалял регистровые и документные dbf и cdx и часть справочников по вкусу. Потом ТИИ и здрасте, чистая база с заполненными справочниками.
AlexLM75; +1 Ответить
4. Vladimir Polyakov (spectre1978) 05.06.16 22:22
(2) zemskov, не поверите - можно создать чистую папку и положить туда dd и md от вашей конфигурации. Затем запустить семерку монопольно, указать ей эту папку - и она создаст там полностью готовую к работе программу! Почти готовую - не будет файлов прописей, v7plus, внешних печатных форм и т.д. плюшек. Но зайти и начать работать можно будет, да.
5. Виктор Земсков (zemskov) 05.06.16 22:32
Спасибо за комментарии. Я это уже понял. С 7.7 дружу уже 15 лет, дописывал конфигурации "Комплексная" и "ЗиК", но вот этого, представляете, не знал, хотя можно было догадаться. DD - это видимо Data Description, а MD разумеется MetaData
6. Сергей (Che) Коцюра (CheBurator) 05.06.16 22:35
Автору тотальное два в первую очередь за незнание предметки
Многие доки в тисе двигают книгу продаж в плюс
То есть грубо говоря исчисляют ндс с которым надо рассчитаться с государством
Если вы не делали регламентные документы каждый месяц формирования книги продаж и покупок - которые минусовали накопленные плюсы - то вы с государством не рассчитывались
Об этом свидетельствует огромный размер файла итогов - который должен быть в штатной ситуации во много раз меньше файла движений
А так все записи за все предыдущие месяцы каждвй раз клонировались на каждый следующий месяц что и привело к бяке вашей

Насчет удаления файлов уже сказали

А так чтобы не чистить каждый раз - достаточно в коде где идет запись в книги продаж покупок просто поставить сразу после входа в соответствующие процедуры возврат и все, и в паре мест закомментировать где идет без вызова процедур. Таким образом кучу лет занулил у себя книги продаж и покупок, регистр кассы и банкаи забыл про них
AlexLM75; const000; +2 Ответить
7. Сергей (Che) Коцюра (CheBurator) 05.06.16 22:40
То есть на следующий период можно сказать в штатном случае переносятся только итоги по незакрытому документообороту, незакрытого документооборота обычно намного меньше чем полного документооборота
В этом случае открытие периода практически не зависит от размера базы
Если вы наблюдаете различимое на глаз увеличение открытия периода с каждым месяцем - то скоро но случится

Как говорится
1сник и жнец и швец и пи..ц
8. Виктор Земсков (zemskov) 05.06.16 22:47
Я эту базу обслуживаю только 4 месяца, бывший программер откланялись...
Если внимательно статью почитать, то я не сразу решился книгу продаж грохнуть, магазин работает на упрощёнке, без НДС, так что он и не нужен. Насчёт зануления я тоже думал, но ещё руки не дошли, так, наверное и сделаю.
9. Сергей (Che) Коцюра (CheBurator) 06.06.16 01:56
10. Владимир (perforator) 08.06.16 08:30
(8) После правки кода снова грохни записи регистра, которые сейчас снова записываются, а то эти хвосты так и будут тянуться, если не перепровести документы, которые сейчас набивают.
AlexLM75; +1 Ответить
11. Виктор Земсков (zemskov) 08.06.16 10:41
Обязательно. Пока они не сильно раздуваются, ещё ничего не делал.
12. Александр (МимохожийОднако) 13.06.16 09:49
Неплохой рассказ для застолья одинэсников
13. Виктор Левченко (lvictor58) 16.06.16 00:44
У нас в Калининграде тоже 90% фирм на упрощенке сидят. Не знаю как сейчас со вступлением в ВТО будет... Но разработчики ТиС как то эту тему проигнорировали насчет того, что упрощенцам и книга продаж и книга покупок нах.. не нужна. Как и кому либо еще. Вряд ли найдется кто-то, кто сидя на общем режиме рискнет формировать ее только по данным торговых операций. Наиболее полная и достоверная информация по отчетности по НДС всегда ведется в бух. учете!
14. Vladimir Polyakov (spectre1978) 27.06.16 23:23
(13) lvictor58, ТиС не имеет полноценной поддержки уже очень давно, поэтому каждый, кто ее использует, должен понимать соответствующие риски и уметь решать вопросы, возникающие при подобных изменениях извне. А если нужно чтобы все происходило само собой - тогда только УТ11 и ИТС...
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа