1с 7 пересчет регистров
Данная методика проверена на тестовой базе, размер которой за месячный период составил 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 <= А
delete from 1sconst where objid <> ' 0 ' and date <= А and iddoc <> ' ' Вообще полезно удалить периодические реквизиты независимо от того записываются они из документов или нет. Это можно сделать так:4) Удаляем ссылки между подчиненными и документами и значения граф отбора. Эти данные находятся в таблице 1SCRDOC. В графе CHILDID находятся ссылки на документы, который после их удаления будут недействительными. Поэтому нужно выполнить такой запрос: delete from 1scrdoc where childdate <= Аdelete from 1sconst where objid <> ' 0 ' and date <= А
Данная операция может быть выполнена вместе с пересчетом итогов (галочка "Пересчет служебных данных"), но опять же "ручной" способ будет быстрее поскольку никаких пересчетов делать не надо
4. Пакуем таблицы, в которых удаляли записи. Здесь тоже быстрее будет воспользоваться не-1С методами. Данный метод можно использовать только для формата DBF: pack 1soperpack 1sentry
pack 1sconst
pack 1scrdoc
Если вы удаляли записи из таблиц документов, то данный оператор нужно вызвать для всех этих таблиц и для таблицы 1SJOURN (п. 9 тогда можно пропустить).
5. Переносим проводки и операции сделанные датой Б + 1 на дату Х Update 1sentry set date = А where date = Б + 1Update 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. Сворачивание базы оперативного учета
Я попутался, или действительно - графы журналов пересчитывает до принятия изменений, а пересчет итогов после?
да.. это ежели через ТиИ делать.. Через журнал - только итоги двигает.
Нет, изменен регистр, и при сохранении пошел пересчет. я думаю - я принял изменения и могу спокойно идти домой, или сидеть дожитаться окна с вопросом о принятии?
о блин.. я за другое подумал.. По-любому, нужно дождаться окошка принятия изменений..
+4 пока не нажмешь - данные не сохранятся.. Он же всё в папку newstru копиряет..
(4,5) Так вроде пересчет регистра идет ПОСЛЕ принятия. я блин не помню, было окно, нажимал принятие. Или нет. База SQL.
В начале идет реорганизация данных - потом запрос на сохранение - потом запись всего.. Посмотри, что щас пишет в строке состояния. через confstat
вообще, пересчет идёт до (в дбф по крайней мере) потом просто копирование табличек
ну.. почти всегда, если что-то есть в строке состояния..
+11 Хотя, тут это лишнее - "запроса о сохранении (принятия изменений)" еще не было.
Как не было? Я практически уверен что было :) Я плюнул и уехал, сказал чтоб завтра, если вопроса об сохранении всё-таки не было, ответили на него положительно.
Вообще вроде там был до дезактивации окна пересчет итогов, и вроде всё-таки после ответа на вопрос о принятии изменений.
Опять торможу - если я ставлю на документ (ранее не проводимый) галку - разрешить проведение документа. Я при сохранении получу пересчет итогов или нет?
Спасибо, запустил. Нафига она все документы обрабатывает :(
Неа, не спрашивал, но судя по тому что начали с утра работать без проблем - пересчет итогов начался после вопроса. Итого 12 минут на копии в которой половина базы, на рабочей будет 25 минут. Хреново.
Узнал - пересчет итогов (или может что еще она делала полтора часа) было после вопроса о сохранении.
странно.. в дбф не так - в начале лопатит, подготавливает все таблички, которые нужно изменить - потом тупо копирует их в раб каталог после вопроса о принятии изменений.
Есть другой вариант - время занал не пересчет итогов, а переиндексация итогов и движений. Особенно движений - была добавлена галка "отбор движений" на одном измерении регистра.
В данной статье будет описана реализация обЪекта "Регистр" в системе 1С:Предприятие 7.7. Подробно будут рассмотрены все возможности, влияющие на структуру и производительность работы с обЪектом "Регистр". Будет проведен анализ текущей реализации и представлен мой взгляд на то какой она должна быть.
Итак обЪект "Регистр", что же он из себя представляет? Если отвлечься от физической реализации, то это таблица состоящая из полей нескольких видов:
1. Измерения - ключевые поля. По умолчанию ключ составляется из всех полей данного типа конкатенацией их в порядке задания в конфигурации.
2. Ресурсы - числовые поля, для каждого из которых определены несколько функций
3. Реквизиты - аналог поля Измерения, с ограничением на функции по Ресурсам.
Однако регистр это не обычная таблица. К нему можно применить термин функциональная таблица, то есть содержимое таблицы зависит от некоторых переменных. В случае с регистром это период, то есть две переменные: начало периода, конец периода. В новой версии системы 1С 8.0 такую таблицу называют виртуальной.
В зависимости от типа регистра: остаточный или оборотный, изменяется набор функций. В первом случае это четыре функции: НачОст, Приход, Расход, КонОст, во втором: только одна - Сумма. Для остаточного регистра функции НачОст, КонОст для полей типа реквизит не определены.
Рассмотрим теперь физическую реализацию обЪекта "Регистр" в системе 1С:Предприятие 7.7. Описание будем проводить для 1С:Предприятие 7.7 SQL версии 18 релиз.
Реализуется с помощью двух таблиц: RGxxx и RAxxx.
Первая таблица содержит значения функции НачОст на начало каждого периода указанного в меню системы "Операции - Управление оперативными итогами" в секции "Периодичность сохранение остатков". Значение данной функции может хранится на начало каждой пятидневки, десятидневки, на начало каждых пятнадцати дней, на начало каждого месяца. Для каждого регистра данная опция действует одинаково, таким образом нет возможности установить разную периодичность для разных регистров.
Замечу, что кроме функции НачОст можно также получить и функцию КонОст, так как остаток на начало текущего периода является остатком на конец предыдущего. Если вам нужно получить остаток на начало какого-то периода, то для поля PERIOD вы должны указать значение начала предыдущего периода (то есть НачОст(01.01.2002)
Таблица имеет индекс по умолчанию PERIOD + (конкатенация измерений в порядке следования их в конфигурации). Поэтому вы должны учитывать, последовательность расположения измерений. Первым должно следовать измерение, по которому наиболее часто будет задаваться условие для выборки и так далее. Кроме того имеется возможность создать дополнительные индексы для каждого измерения кроме первого (и это правильно так как индекс для первого измерения уже задан). Для этого в конфигураторе зайдите в свойства измерения на закладку "Дополнительные" и поставьте галку "Отбор итогов". Задать индекс для произвольного набора измерений невозможно.
Вторая таблица содержит все движения записанные документов в модуле проведения. В поле IDDOC содержится идентификатор документа, которому принадлежат эти движения в поле DEBKRED содержится знак движения (0 - приход, 1 - расход). Таким образом данная таблица служит для расчета функций Приход и Расход за выбранный период. Замечу, что поля типа "Реквизит" хранятся только в этой таблице, поэтому для них возможно вычисление только данных функций.
По умолчанию вычисление этих функций производится при помощи соединения с таблицей журналов документов (_1SJOURN) по идентификатору документа (при этом учитываются только проведенные документы, имеющие движения по данному регистру - эти условия указываются по полям CLOSED и RFxxx таблицы журналов). Соединение с таблицей журналов необходимо так как только там содержится дата документа, по которой можно определить входит движение в выбранный период или нет. Согласитесь, что это не есть хорошо. При вычислении оборотов скажем за месяц необходимо просканировать ВСЕ документы в таблице журналов за месяц. Однако данный недостаток можно устранить. Для этого предназначена галка "Быстрая обработка движений" в свойствах регистра. При этом в таблице движений появляется дополнительное поле DATE_TIME_IDDOC и индекс по нему, что позволяет не обращаться к журналу документов. Однако в 18 релизе данная возможность используется системой как-то странно: при получении остатков соединения с таблицей журналов уже нет, но для вычисления оборотов по прежнему идет соединение с таблицей журналов. Причем вычисление оборотов выполняется не просто с помощью отдельного запроса, а при помощи курсора.
По умолчанию в таблице присутствует только индекс по идентификатору документа (включающий также в себя номер строки документа и номер движения). Кроме этого можно добавить дополнительный индекс по измерению или по реквизиту. Для этого нужно в свойствах измерения или реквизита на закладке "Дополнительные" установить галку "Отбор движений". При этом создается индекс по этому реквизиту + либо идентификатор документа, либо поле DATE_TIME_IDDOC (если есть).
Вот так реализованы регистры в системе 1С. Надеюсь вы поняли как на самом деле это должно быть - в конце почти каждого абзаца были указаны недостатки. Суммируем их в рекомендации:
1. Возможность установки периодичности хранения остатков для каждого регистра отдельно.
2. Возможность определения произвольных индексов для таблицы итогов, движений. Возможность отключения индекса по умолчанию
3. Исправление ошибки и оптимизация при вычислении функций Приход и Расход
Хотел бы заметить еще один важный момент в реализации остаточных регистров. Судя по их названию они должны использоваться в основном для получения остатков, но зачастую их используют и для получения оборотов (различные ведомости). Однако вычисление оборотов при помощи регистров совершенно не оптимально. Мало того, что имеется уже описанная выше ошибка, но самое главное - чем больше период для получения оборотов тем дольше будет их вычисление и никакая оптимизация тут уже не поможет. В бухгалтерской подсистеме это сделано лучше - вместе с остатком там хранятся обороты по периодам. Конечно можно использовать для вычисления оборотов оборотные регистры, но зачем для этого заводить еще одну таблицу, когда можно сделать все в одной? Поэтому я считаю, что нужная еще одна рекомендация:
Возможность указания (может быть даже для каждого ресурса в отдельности) хранить итоговые обороты.
В целом реализация оборотного регистра аналогична остаточному регистру. Оборотный регистр также состоит из таких же двух таблиц. Таблица движений полностью аналогична таблице движений остаточного регистра. Таблица итогов содержит не значение функции НачОст, а значение функции Сумма. Состав индексов у таблиц и их смысл такой же как у остаточного регистра. Для оборотного регистра уже учтено замечание 1 - периодичность можно устанавливать для каждого регистра отдельно. Периодичность оборотного регистра отличается от регистра остатков: день, неделя, декада, месяц, квартал, год. Итоги в таблице итогов по периодам хранятся нормально, то есть чтобы получить значение функции Сумма за целый период, поле период нужно приравнять началу выбранного периода (желательно указать условие на нахождение м/у началом и концом выбранного периода).
К реализации оборотных регистров имеется дополнительная рекомендация. Дело в том, что в документации написано, что для записи движений в оборотный регистр можно пользоваться только методом ДвижениеВыполнить. Однако методы ДвижениеПриходВыполнить и ДвижениеРасходВыполнить не запрещены - их применение не вызывает никакой ошибки при использовании. Причем самой системой предусмотрено суммирование итогов с учетом знака движения (в одной их хранимых процедур, связанных с пересчетом таблиц итогов). В то же время при выполнении запроса это (то есть знак движения) уже не учитывается. Поэтому применение функции Сумма за нецелый период приводит к неправильному результату. Применение функций Приход и Расход в запросе также не приводит к ошибке и скорее всего корректный результат достигается путем суммирования движений по таблице движений, что очень медленно. Отсюда следует, что:
1. При выполнении запроса за нецелый период в функции Сумма, нужно учитывать знак движения
2. Необходимо ввести дополнительный признак - разделять или нет значения функций Приход и Расход для каждого ресурса (или регистра в целом). При этом если данный признак стоит, то использование ДвижениеПриходВыполнить/ ДвижениеРасходВыполнить и функций Приход/Расход не должно вызывать ошибку и наоборот.
Надеюсь, что данная статья была для вас интересной и главное полезной, а для разработчиков системы послужит руководством к действию для внесения изменений в следующие релизы и версии системы 1С.
Читайте также: