1с очистить таблицу итогов

Обновлено: 06.07.2024

Дисклеймер! Политика 1С не разрешает никакие манипуляции с данными напрямую средствами СУБД, только средствами платформы! Поэтому качать, смотреть, думать, а уж тем более запускать эту обработку категорически нельзя. (или можно, но только ночью, обязательно завесив окна, выключив свет и закрывшись на семь замков). Шутка, конечно же. Просто в случае безвозвратной потери данных виноваты будете Вы и только Вы. Минздрав предупредил.

Цель написания обработки единственная: создание БД для разработчика в максимально короткие сроки путем обрезки базы до минимума, необходимого для работы. Никакая целостность не проверяется и не гарантируется. Возможно, кто-то уже сталкивался с проблемой в больших компаниях, когда база 1С весит сотни гигов (по несколько млн документов в год), и развернуть каждому программисту в отделе по отдельной копии просто физически невозможно. И не рентабельно. Лучшее решение - обрезать базу, оставив в ней данные лишь за небольшой период. Но удаление большого числа объектов средствами 1С занимает очень много времени.

В качестве статистики приведу пример. 1С у меня удаляет данные со скоростью

25 000 объектов/час, Обработка -

2 000 000 объектов за 20 минут. Разница налицо, как говорится.

Как пользоваться обработкой?

Аутенфикация

Некоторые данные для аутенфикации подтягиваются автоматически из строки соединения с ИБ, но они совсем не всегда совпадают. Поэтому необходимо ввести имя именно своего сервера SQL.

Для проверки корректности данных есть кнопочка "Проверить подключение".

Тайм-ауты можно оставить как есть. 30 сек для подключения, 1ч на выполнение запроса в СУБД. Если в процессе удаления появится ошибка "(Microsoft OLE DB Provider for SQL Server): Query timeout expired", значит, необходимо увеличить тайм-аут выполнения запроса, т.к. слишком много данных, и СУБД не успела их почистить.

Удаление

Удаление возможно частичное или полное.

Обработка позволяет очищать следующие объекты:

Документы,
Журналы документов,
Регистры сведений,
Регистры накопления,
Регистры бухгалтерии.

Полное удаление выполняется быстро через команду TRUNCATE TABLE.

Частичное удаление производится путем выбора периода удаляемых данных (отбор по полю _Period в БД).

Для Документов также автоматически очищаются таблицы, содержащие данные табличных частей документов.

Для Регистров накопления и бухгалтерии есть возможность выбора действия обработки виртуальных таблиц (Итоги, Обороты. ). По хорошему, в идеале лучше всего виртуальные таблицы очищать полностью, после чего из Конфигуратора запускать Тестирование и исправление с галкой "Пересчет итогов".

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

Команда "Очистить всё" последовательно проходит по всем страницам обработки и выполняет действия в зависимости от выбранных параметров.

Ведь все знают, что убрать лишнее всегда легче, чем добавить всё необходимое.

Именно в данном вопросе и поможет обработка «очистка регистра на дату».

«Выб регистр» - указываем, с каким регистром мы работаем.
«Дата остатков» - дата получения остатков по регистру.
«Дата создаваемого движения» - дата записи движения, в котором будет произведено списание с остатка
«Документ корректировка» - ссылка на документ, в который производилась запись при списании остатков. Заполнять не обязательно, если указываете — пишет в этот документ, не указываете, создаёт новый и ссылку кидает в это поле.

«Списать остатки с указанного регистра» - спишет !безусловно все! остатки с регистра.
«Списать остатки по отбору» - спишет остатки с регистра по установленному отбору (если их найдёт, конечно же)
«Показать записи по отбору» - покажет (теоретические движения) записи, которые могли бы быть списаны по отбору в таблице «Результат».

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

P.S.: Добавлена модифицированная обработка для Бухгалтерии 3.0

Далее Для обычных неуправляемых форм.

Подойдёт для любой конфигурации в которой присутствует документ «КорректировкаЗаписейРегистров».

Функционально форма разбита на 3 закладки : Настройки и отборы, Таблица редактирования записей, Таблица просмотра записей.

На закладке "Настройки и отборы" необходимо выбрать регистр, а также указать даты получения остатков и дату записей(сгенерированых движений). Красная кнопка напротив документа корректировка регистра - очистит все движения указанного документа (если вы передумали или ошиблись).

Кнопка "Списать остатки по отбору" - Создаст документ или заполнит выбранный - движениями списания остатков по отбору указанному в таблице, если отбор не указан то спишется всё.

Кнопка "Перенести в таб. для редактирования" - получит записи по отбору и перенесет эти записи в таблицу на второй закладке для последующего редактирования вручную.

Кнопка "Показать записи" заполнит табличный документ на третьей закладке для наглядного представления этих записей.

Вторая закладка в свою очередь подразделяется на 2 закладки: Таблица редактирования , Выполнение запроса.

На закладке "таблица редактирования" присутствуют кнопки "Очистить таблицу"- очищает таблицу и кнопка "Перенести в документ списания" - переносит все движения отмеченные галочкой в документ "Корректировка регистров".

На закладке "Выполнение запроса" - можно написать свой запрос заполнения таблицы редактирования. Корректность и наличие необходимых полей полей конечно же в данном случае вы обеспечиваете сами.

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

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

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

Сразу же рождается решение, удалять записи регистра порциями, что я изначально и делал:

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

Очистив записи, нужно пересчитать итоги, а объем таблицы итогов обычно в разы больше, чем размер очищенного регистра. При использовании стандартного механизма пересчета итогов, опять возникает проблема нехватки места на диске.

Для этого я реализовал следующую процедуру:

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

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

Для этого я написал простенькую функцию, которая после очистки очередной порции подсчитывает размер лога и сравнивает его с заданным значением, и если размер лога вырос подключается к базе (MSSQL) и выполняет команду

После такой реализации можно спокойно запускать полученную обработку и идти домой, зная что место на диске не кончится.

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

Для увеличения скорости удаления записей, я узнал название таблицы в базе MSSQL, зашел в базу и очистил данную таблицу, следующей командой

, где "_AccumRg1923" мой регистр. После чего я вызвал вышеописанную обработку и почистил итоги.

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

Ну и в конце статьи хочу сказать про функции УстановитьИспользованиеИтогов() , УстановитьИспользованиеТекущихИтогов(). Ими стоит пользоваться, когда ты точно уверен, что размер лога не заполнит весь объем свободного пространства на диске.

Данная методика проверена на тестовой базе, размер которой за месячный период составил 67 Мб. Эта часть той базы, о которой ведется речь в статье. Остатки переносились на середину месяца. К сожалению проверить на большой базе пока не удалось поскольку ранее переданная статья содержала ошибки, и поэтому первая попытка оказалась неудачной. Будем пробовать еще раз. Теперь осталось выяснить только то сколько времени займет данный процесс.

З.Ы. При проверке не пользовался обработкой clear.ert - все делал ручками. Так что смотрите внимательно!

Сворачивание периода известно в 1С:Кругах под разными названиями какой из них вам ближе решайте сами. Мне известны следующие:

1. Перенос остатков
2. "Урезание" базы
3. Закрытие периода

И так далее. Смысл термина в следующем. В течение длительного периода работы информационная база (любая, будь-то бухгалтерия, торговля или смешанная - з/п и компоненту расчет не рассматриваем) имеет тенденцию увеличиваться в размере по вполне понятным причинам. Думаю их вам обЪяснять не надо. Заметим только, что скорость роста для разных баз различается и зависит от обЪема документов вносимых в базу в единицу времени (например, за день), а также от количества и размера аналитических таблиц (так назовем регистры, бухгалтерские итоги вместе с планом счетов). Чем меньше единица учета (в количественном выражении) и чем больше обороты фирмы, тем больше количество вносимых документов, чем сложнее отчеты получаемые в системе, чем больше их количество, тем больше размер аналитических таблиц.

При проектировании информационной системы ее подразделяют на две составляющие: транзакционную и аналитическую. Первый тип систем предназначен для ввода большого обЪема информации в реальном режиме времени, второй тип предназначен для проведения анализа данных полученных в транзакционных системах. Какая же связь такого разделения с темой статьи? Самая непосредственная - процедура свертки периода, является частью процесса по переводу данных из транзакционной системы в аналитическую. Дело в том, что обычно в транзакционных системах обЪем информации хранится за небольшой текущий период (например, месяц - все зависит от интенсивности ввода). Чем больше размер информационной базы, тем менее комфортной становится работа в такой системе - замедляется ввод документов, формирование отчетов также замедляется. В случае с 1С особенно это заметно в DBF формате, меньше в SQL, но все равно и здесь имеется некоторое замедление. Рост базы также приводит к ее более частому "падению", опять же это больше характерно для DBF формата. Поэтому периодически данные из транзакционной системы необходимо передавать в аналитическую систему, удаляя при этом лишние данные. Сегодня у всех на слуху технологии OLAP - как раз-то они и предназначены для создания таких (аналитических) систем. В том числе данные технологии активно применяются в связке с 1С. Но статья не об этом.

Итак, после того как данные будут переданы в аналитическую систему, нам необходимо удалить их из нашей транзакционной системы. Что ж, неплохо было бы если фирма 1С предоставила такой инструмент в составе своей системы. Но! Как всегда НО. Имеющиеся средства не подходят для обработки больших баз. Подчеркиваю БОЛЬШИХ. Большой я считаю базу размером не менее 500 Мб (вместе с индексами), даже ближе (и больше) к 1 Гб. Но именно для таких баз обычно необходима процедура свертки периода. Почему же не подходят стандартные средства? Уточнюсь, что под ними я понимаю обработку wrap.ert, которая позволяет произвести "свертку" бухгалтерских итогов (для оперативного учета, таковой нет). Итак:

1. Если перенос остатков осуществляется не на последнюю рабочую дату (то есть дата, после, которой нет проводок), то при переносе остатков задним числом производится пересчет остатков.

2. Отмена проведения / пометка на удаление документов также приводит к пересчету остатков.

3. Удаление документов по одному, с внесением изменений в индексы очень медленно. Даже применение транзакций спасает слабо.

Возможно это не все причины, но перечисленные выше - основные. Таким образом необходимо избавиться от недостатков, которые несет за собой применение стандартных методов. Хочу добавить, что все это не теория (то есть пп. 1-3) - у наших клиентов имеется база размер, которой уже близок к 2 Гб, попытки использования стандартных методов не увенчались успехом (не дождались завершения обработки, попытка запуска ее на домашнем компьютере привела к его зависанию). Пришлось искать обходные методы в результате чего и появилась данная методика.

База формата DBF. Дата (А), на которую необходимо перенести бухгалтерские остатки, а также удалить все лишние документы до данной даты. Конец текущего расчетного периода (Б).

1С:Предприятие 7.7, доработанная обработка переноса остатков 1C wrap.ert, любое приложение для выполнение SQL запросов для DBF баз (MS Query, DB Explorer из поставки Delphi). В качестве приложения для выполнения SQL запросов можно использовать ВК ToySQL (или Rainbow, ODBCSQL или технологию ADO), просто подключаясь к обрабатываемой базе из другой базы (см. ссылку на обработку в конце статьи).

0. Делаем копию базы.

1. Переносим остатки. Обычным образом создаем ручные операции, но дату операции устанавливаем не А, а Б + 1, при этом пометку на удалению документов не производим. Таким образом мы избавляемся от ненужного пересчета. На дату Б + 1 не должно быть ни документов, ни операций. Здесь в принципе можно использовать любую дату из будущего периода. Точнее чтобы не было пересчета, то дата должна находится за пределами текущего расчетного периода.

2. Удаляем все индексные файлы, а также файлы бухгалтерских итогов: 1SACCSEL.DBF, 1SBKTTL.DBF, 1SBKTTLC.DBF, 1SSBSEL.DBF. Начиная с данного этапа прекращаем пользоваться стандартными методами

3. Выполняем следующие запросы:

1) Делаем пометку на удаление документов.

Update 1sjourn set ismark='*', closed=4 where date <= А

Если можно удалить все (!) документы сразу (то есть в будущем периоде нет ссылок на документы из прошлого), что бывает очень редко, то можно удалять сразу

Delete from 1sjorun where date <= А

При этом сначала нужно удалить записи из связанных таблиц документов (dh*, dt*)

Delete from dh* d from 1sjourn j where d.iddoc = j.iddoc and j.date <= А

Так для каждой таблицы документа и его табличной части. Для SQL Server можно написать скрипт перебирающий таблицы документов и выполняющий данный запрос для каждой из них.

delete from 1sentry where date <= А
delete from 1soper where date <= А

3) Если в вашей конфигурации есть периодические реквизиты, которые изменяются документами (с помощью метода УстановитьРеквизитСправочника), то можно (точнее нужно) удалить значения этих реквизитов:

delete from 1sconst where objid <> ' 0 ' and date <= А and iddoc <> ' ' Вообще полезно удалить периодические реквизиты независимо от того записываются они из документов или нет. Это можно сделать так:

delete from 1sconst where objid <> ' 0 ' and date <= А

4) Удаляем ссылки между подчиненными и документами и значения граф отбора. Эти данные находятся в таблице 1SCRDOC. В графе CHILDID находятся ссылки на документы, который после их удаления будут недействительными. Поэтому нужно выполнить такой запрос: delete from 1scrdoc where childdate <= А

Данная операция может быть выполнена вместе с пересчетом итогов (галочка "Пересчет служебных данных"), но опять же "ручной" способ будет быстрее поскольку никаких пересчетов делать не надо

4. Пакуем таблицы, в которых удаляли записи. Здесь тоже быстрее будет воспользоваться не-1С методами. Данный метод можно использовать только для формата DBF: pack 1soper
pack 1sentry
pack 1sconst
pack 1scrdoc

Если вы удаляли записи из таблиц документов, то данный оператор нужно вызвать для всех этих таблиц и для таблицы 1SJOURN (п. 9 тогда можно пропустить).

5. Переносим проводки и операции сделанные датой Б + 1 на дату Х Update 1sentry set date = А where date = Б + 1
Update 1sentry set date = А where date = Б + 1
Update 1sjourn set date = А where date = Б + 1

Здесь важно чтобы на дату Б + 1 не было документов кроме созданных ручных операций. Иначе эти документы также перенесутся на дату Х.

6. Все. Теперь у нас практически рабочая база. Можно опять взяться за стандартные методы. Нужно восстановить индексы - просто запускаем 1С-ку монопольно.

7. Итоги можно пока не пересчитывать. Запускаем поиск удаленных обЪектов. Если вы удалили документы сразу как было описано в п. 3, то этот пункт можно пропустить.

8. Пересчитываем итоги. Хорошо бы пересчет итогов по колонкам был бы в разделе "Пересчет служебных данных", но уж что имеем :(. Все! База готова. Остается сверить получившуюся базу с ее копией (надеюсь ее-то вы не забыли сделать - мало ли что ;).

9. Упс. Забыл ради чего мы это все затевали. Если посмотреть на размер базы, то он уменьшился не на столько на сколько хотелось бы (скорее всего). Почему? Правильно! В DBF формате записи не удаляются непосредственно, а помечаются на удаление. У нас остались лишние данные в таблице 1SJOURN и в таблицах документов (файлы проводок и операций мы упаковали сами). Что же нужно сделать? Правильно запустить упаковку данных. Впрочем данный пункт не стоит делать отдельно - просто обЪедините его с п. 8, поставив галочку "Упаковка таблиц информационной базы", когда будете пересчитывать итоги в режиме конфигуратора. Вот теперь точно все! Уффф.

Даты в DBF формате записываются в виде

Используемое в статье собственное и доработанное ПО:

1. Модифицированная обработка wrap.ert, позволяющая переносить остатки на другую дату, не удаляя документы. В обработке предусмотрен вызов функции для установки дополнительных реквизитов операции как документа (УстановитьФирму).

2. Обработка по удалению документов, проводок из базы с помощью компоненты ToySQL

3. Компонента ToySQL

Как упражнения вам

1. Внести небольшие изменения для SQL версии
2. Сворачивание базы методом формирования помесячных оборотов
3. Сворачивание базы оперативного учета

Приветствую, коллеги! В данной статье мы подробно рассмотрим системную утилиту «Тестирование и исправление информационной базы» в 1С 8.3 и особенности её использования.

Рисунок 1 Режимы тестирования и исправления информационной базы Рисунок 1 Режимы тестирования и исправления информационной базы

Режим тестирования и исправления вызывается в конфигураторе системы 1С 8.3 выбором меню «Администрирование → Тестирование и исправление».

Если у Вас возникла необходимость провести процедуру тестирования и исправления информационной базы 1С:

· во-первых, следует создать копию базы данных (если это возможно, т.к. иногда структура базы становится настолько «покалечена», что отсутствует даже возможность создать резервную копию).

· во-вторых, после создания резервной копии следует открыть «Конфигуратор → Администрирование → Тестирование и исправление…»

Проверки и режимы

В этом окне указывается список необходимых проверок и режимов, которые будут произведены в результате работы утилиты. Рассмотрим каждую галочку подробнее:

Процедура позволяет выбрать проверки и режимы, которые должны быть выполнены для текущей информационной базы.

· Реиндексация таблиц – это перестроение индексов таблиц, направленное на повышение быстродействия работы базы.

· Проверка логической целостности – это целое множество проверок логики базы данных

· Проверка ссылочной целостности – это подмножество проверки логической целостности базы данных, существующее для отдельной работы с «битыми» ссылками. Конкретнее будет объяснено ниже по тексту.

· Пересчет итогов – расчет итогов таблиц регистров накопления.

· Сжатие таблиц информационной базы – данный пункт отвечает за уменьшение размера базы после тестирования. Объяснить уменьшение размера базы можно, например, так: когда из базы удаляется объект, он, по сути, остается в базе внутри, но невидимым для конечного пользователя. Сделано это для того, чтобы объект все-таки можно было восстановить уже после полного удаления из базы (хотя мы с таким не сталкивались). А сжатие таблиц убирает информацию об удаленных уже объектах из базы данных. От этого таблицы становятся меньше (это всего лишь один пример, как работает сжатие). Действие «Сжатие таблиц информационной базы» доступно только для файлового варианта. Остальные варианты работают и в файловом и в серверном режиме.

· Реструктуризация таблиц – пример можно привести такой: берется таблица № 1, создается копия ее структуры, например, Таблица № 2, и данные из таблицы № 1 копируются порциями в таблицу № 2.

Имеется возможность выполнять только тестирование или тестирование с исправлением.

Пункты настроек по обработке ошибок базы становятся доступными для выбора при варианте обработки «Тестирование и исправление», а также режиме «Проверка ссылочной целостности информационной базы».

Читайте также: