1с свернуть регистр накопления
Обновлено: 04.07.2024
Детективная история
Сразу покажу на небольшом примере почему это так важно.
Пусть у нас есть начисление заработной платы за январь:
В начале февраля мы создаём ведомость на выплату зарплаты из кассы и нажимаем кнопку "Заполнить":
И получаем следующее:
Но ведь за январь:
- Начисление 50 000 рублей
- НДФЛ 6 500 рублей
- Итого к выплате 43 500 рублей
Где закралась ошибка? Что пошло не так? Неужели теперь всегда вводить сумму к выплате вручную?
Опытный бухгалтер тут же сделает оборотно-сальдовую ведомость по 70 счёту:
И будет в ещё большем недоумении, потому что по данным отчёта к выплате выходят всё те же 43 500! И откуда же взялись лишние 5 000 рублей?
Причём такая ситуация (с любыми расчётами) может произойти как в "тройке", так и в "двойке".
Сегодня я попытаюсь приоткрыть завесу тайны - почему же иногда программа ведёт себя так странно. Я расскажу как в таких случаях находить и устранять ошибку. Ближе к концу статьи мы разберёмся - откуда же взялись эти самые 5 000 рублей.
Учимся видеть регистры
При проведении документов 1С:Бухгалтерия 8 делает проводки по бухгалтерским счетам (кнопка ДтКт у любого документа):
Именно на основании этих проводок строятся все бухгалтерские отчёты: Анализ счёта, Карточка счёта, Оборотно-сальдовая ведомость.
Но есть огромный пласт данных, которые пишутся программой параллельно с проводками и используются для всего остального: заполнение КУДИР, книги покупок и продаж, регламентированной отчётности. заработной платы к выплате, наконец
Как вы уже, наверное, догадались этот пласт называется регистрами, вот он:
Я сейчас не буду вдаваться в подробности описания самих регистров, чтобы не запутать вас ещё больше.
Скажу лишь, что нам просто жизненно необходимо постепенно учиться "видеть" движения по этим регистрам, чтобы лучше понимать и, когда надо, корректировать поведение программы.
Давайте присмотримся к регистру "Зарплата к выплате" - именно он имеет смысл для решения нашей проблемы с лишними 5 000:
Мы видим две записи по этому регистру, сделанные в приход, то есть в плюс. Если пролистать экран в право, то мы увидим в первой строчке сумму к выплате "-6 500", а во второй "50 000".
Остаток по этому регистру -6 500 + 50 000 равен 43 500, который и должен попасть в документ "Ведомость на выплату из кассы", когда мы нажимаем на кнопку "Заполнить".
Ещё раз повторюсь - ведомость на выплату определяет нашу задолженность по заработной плате перед сотрудником не по 70 счёту, а по регистру "Зарплата к выплате" .
Получается мы знаем, что зарплата к выплате заполняется на основании этого регистра, но даже видя записи регистра не можем понять что не так.
Скорее всего мы не видим всей картины (может быть существуют другие записи по этому регистру) и напрашивается некий инструмент для анализа регистра подобный бухгалтерским отчётам.
Учимся анализировать регистры
И такой инструмент есть, он называется "Универсальный отчёт".
Переходим в раздел "Отчеты" пункт "Универсальный отчёт":
Выбираем тип регистра "Регистр накопления", регистр "Зарплата к выплате" и нажимаем кнопку "Сформировать":
Получилось не очень информативно:
Всё потому, что требуется предварительная настройка отчёта, нажимаем кнопку "Показать настройки" и на закладке "Группировка" добавляем поле "Сотрудник":
На закладке "Отборы" делаем отбор по нашей организации:
Нажимаем кнопку "Сформировать":
Вот это уже более интересно. Видим остаток к выплате нашему сотруднику те самые 48 500 рублей!
Снова заходим в настройки отчёта и добавляем на закладку "Показатели" новое поле "Регистратор":
Снова формируем отчёт:
Вот теперь мы прекрасно видим, что 5 000 появились как результат операции (видимо ввода остатков) 31 декабря 2014 года.
И нам нужно либо изменить эту операцию, либо вручную откорректировать регистр "Зарплата к выплате" и закрыть эти 5 000 рублей, например, 31 декабря 2015 года.
Давайте пойдём вторым путём. Итак, наша задача - сделать так, чтобы на начало 2016 года по регистру "Зарплата к выплате" не было нашей задолженности перед сотрудником.
Это делается ручной операцией.
Учимся корректировать регистры
Заходим в раздел "Операции" пункт "Операции, введенные вручную":
Создаём новую операцию концом 2015 года:
Из меню "Ещё" выбираем пункт "Выбор регистров. ":
Указываем регистр "Зарплата к выплате" и нажимаем ОК:
Переходим на появившуюся закладку регистра и делаем расход на 5 000 рублей:
Этим самым мы как бы отнимаем от регистра 5 000 рублей по сотруднику, чтобы выйти на ноль к началу 2016 года.
Проводим операцию и заново формируем универсальный отчёт:
Всё получилось! Видим, что наша ручная операция от 31.12.2015 вывела остаток в ноль и зарплата к выплате после начисления равна ожидаемым 43 500.
Замечательно. И сейчас мы проверим это в ведомости на выплату.
Но прежде я хочу обратить ваше внимание на ещё один важный момент:
Обратите внимание, что остатки на начало и на конец по группировке "Сотрудник" показывают ерунду. Это никакая не ошибка, это нюанс, который нужно учитывать, связанный с архитектурными особенностями 1с.
Запомните. В том случае, если универсальный отчёт выводится с детализацией до документа (регистратора) - остатки по группировкам будут показывать ерунду.
Если нам требуются остатки по группировке сотрудник - нужно сначала удалить из настроек добавленный нами показатель "Регистратор":
И только потом формировать отчёт:
Сейчас остатки показаны корректно.
Результат
Напоследок убедимся, что мы сделали всё правильно. Снова заходим в ведомость на выплату заработной платы за январь и нажимаем кнопку "Заполнить":
Мы молодцы, на этом пока всё
Кстати, подписывайтесь на новые уроки.
С уважением, Владимир Милькин (преподаватель школы 1С программистов и разработчик обновлятора).
Как помочь сайту: расскажите (кнопки поделиться ниже) о нём своим друзьям и коллегам. Сделайте это один раз и вы внесете существенный вклад в развитие сайта. На сайте нет рекламы, но чем больше людей им пользуются, тем больше сил у меня для его поддержки.
Обязательно делайте бекапы. Тестируйте только на копии. Если на копии все получилось успешно - протестируйте на ней еще раз.
- Самописная или сильно измененная типовая конфигурация
- Отключен контроль остатков
- Режим работы "24х7"
- Большой размер БД
Как-то раз заметили, что объем рабочей базы сильно увеличился. Измеритель показал, что в лидеры вырвались регистры накоплений. Таблица итогов ТОП 10 регистров в несколько раз превышала размер основной таблицы. Начали анализировать - оказалось, что в них появились записи с периодом около начала нашей эры. Соответственно от этой даты и начались создаваться записи в таблицах итогов до текущего момента.
С учетом специфики конфигурации и невозможности определить точную дату документов перепровести их не выдавалось возможным, поскольку это бы заняло много времени, и последствия были плачевными.
Поэтому было принято решение подтянуть старые записи к определенному моменту - даты начала учета. В любом случае они потом закрывались, а лишние и ненужные записи удалилсь бы.
Была создана обработка для этого. Есть два режима работы:
- Просто просмотр данных - показывает, сколько есть записей по каждому РН до даты актуализации.
- Режим актуализации - поиск и перенос периода в данных.
В принципе кнопок там минимум, режим работы показан на скриншотах.
Оптимизация и ускорение.
Но предыдущие действия не сильно помогут, т.к. старые итоги не пересчитываются. Их нужно заново пересчитать. Это можно сделать через "Тестирование и исправление" в конфигураторе. Но поскольку старые записи удаляются методом DELETE , а не TRUNCATE в СУБД - это будет происходить очень долго ну и плюс ко всему в монопольном режиме. Очень хорошо расписано в статье. Для ускорения можно предварительно очистить эти таблицы в СУБД (у меня был MS SQL).
Вот дорабтанный скрипт для MS SQL, который сгенерирует и выполнить запросы для очистки таблиц итогов в контексте определенной базы данных.
В итоге общий размер таблиц РН сократился втрое с 30 ГБ. Уменьшились таблицы итогов, и поиск по ним стал происходить заметно быстрее.
Устройство регистра накопления
Все поля регистра накопления можно разделить на три категории: измерения, ресурсы, реквизиты. К этим категориям относятся и все системные поля регистра. Период является измерением. Регистратор и НомерСтроки, с одной стороны, являются измерениями, так как вместе периодом определяют момент времени в которое произошло движение; с другой стороны, они характеризуют конкретную запись и могут быть отнесены к категории реквизитов. Вид движения является реквизитом так как является только характеристикой конкретной записи.
Таблицы регистра накопления остатков
Регистр накопления остатков состоит из двух таблиц: таблицы движения и таблицы итогов. В таблице движений хранятся записи, которые либо вводятся пользователем вручную, либо генерируются в процессе проведения документа или исполнения обработки. Таблица движений имеет следующую структуру:
1. Период
2. Регистратор
3. Номер строки
4. Вид движения
5. <Измерения>
6. <Ресурсы>
7. <Реквизиты>
В таблице итогов хранятся остатки в разрезе всех измерений с периодичностью месяц, на начало месяца. Временной интервал, за который хранятся остатки, ограничивается установкой периода рассчитанных итогов. Период рассчитанных итогов указывается как последний день месяца, по который рассчитаны итоги. То есть если период рассчитанных итогов равен 31.07.2004, то итоги будут рассчитаны по 01.08.2004 включительно. Кроме того, в таблице итогов отдельно хранятся актуальные итоги. Таблица итогов имеет следующую структуру:
1. Период
2. <Измерения>
3. <Ресурсы>
Если период рассчитанных итогов равен 31.07.2004, а самое раннее движение было сделано 02.05.2004, то итоги будут хранится за следующие периоды: 01.06.2004, 01.07.2004, 01.08.2004 и актуальные итоги.
Виртуальная таблица остатков
Виртуальная таблица остатков для расчета данных всегда использует таблицу итогов и иногда таблицу движений. Использование таблицы движений зависит от момента времени, на который считаются остатки, и периода рассчитанных итогов. При расчете остатков используются довольно простая стратегия.
1. Подбирается ближайший больший или равный момент времени, на который рассчитаны остатки.
2. На этот момент получаются остатки из таблицы итогов.
3. Если момент времени, на который считаются остатки, не совпадает с моментом времени итогов, то остатки досчитываются по движениям за период с момента запроса остатков по момент итогов.
Рассмотрим несколько примеров. Пусть период рассчитанных итогов равен 31.07.2004. Мы хотим получить остатки на 01.07.2004, 15.07.2004, 01.08.2004, 15.08.2004 и актуальные остатки.
Для случаев получения остатков на 01.07.2004, 01.08.2004 и актуальных остатков данные будут получены непосредственно из таблицы итогов. В случае получения остатков на 15.07.2004 сначала будут получены данные из таблицы итогов на момент времени 01.08.2004, так как это ближайший больший момент времени, на который посчитаны остатки, а затем будут обработаны данные из таблицы движений за период с 15.07.2004 по 31.07.2004 включительно. В случае получения остатков на 15.08.2004, ближайшим большим моментом времени, на который посчитаны остатки является момент актуальных остатков. Таким образом, для расчета остатков на 15.08.2004, будут получены актуальные итоги и обработаны данные таблицы движений начиная с 15.08.2004.
Виртуальная таблица оборотов
Виртуальная таблица оборотов всегда работает по данным таблицы движений. То есть для получения оборотов за какой-либо период будут обработаны данные таблицы движений за этот период, независимо от периода рассчитанных итогов.
Виртуальная таблица остатков и оборотов
Виртуальная таблица остатков и оборотов рассчитывает одновременно и остатки, и обороты. В зависимости от того, указана периодичность или нет, изменяется способ работы данной таблицы. Если периодичность не указана, то расчет данных производится единым запросом, который в свою очередь содержит подзапросы. Один из них вычисляет остатки на начальный момент периода, как это описано для виртуальной таблицы остатков, второй -обороты за заданный период, как это описано для виртуальной таблицы оборотов. Результаты подзапросов объединяются и выдаются как единый результат.
В случае если периодичность задана, расчет данных разбивается на следующие шаги:
1. Получение остатков на начало заданного периода.
2. Получение оборотов с заданной периодичностью за заданный период.
3. Объединение данных двух запросов.
Отличие оборотного регистра от регистра остатков
В отличие от регистра остатков, оборотный регистр накапливает обороты. По данному регистру нельзя посчитать остатки, и поэтому для него существуют только одна виртуальная таблица оборотов. Структура таблицы движений оборотного регистра не сильно отличается от таблицы движений регистра остатков. Она имеет следующую структуру:
1. Период
2. Регистратор
3. Номер строки
4. <Измерения>
5. <Ресурсы>
6. <Реквизиты>
Очевидно, что в таблице движений оборотного регистра отсутствует только поле ВидДвижения. Таблица же итогов оборотного регистра по своей структуре идентична структуре таблицы регистра остатков:
1. Период
2. <Измерения>
3. <Ресурсы>
Но сходство этих таблиц на этом и заканчивается. В таблице итогов оборотного регистра хранятся обороты с периодичностью месяц. Итоги хранятся за все периоды, за которые были движения и не ограничиваются периодом рассчитанных итогов. В таблице итогов оборотного регистра не хранятся актуальные данные, так как для оборотов такого понятия не существует.
Виртуальная таблица оборотов
Виртуальная таблица оборотов в своей работе может использовать как таблицу итогов, так и таблицу движений. Зависит это от заданного периода и периодичности. Если периодичность задана, и она меньше месяца, то используется только таблица движений. Если периодичность не задана или задана большей или равной месяцу, то использование таблицы итогов или движений зависит от заданного периода. Если в заданный период попадают целые месяцы, то данные за них считаются по таблице итогов, остальное считается по таблице движений. Например считаются данные с периодичностью месяц за периоды:
1. с 01.03.2004 по 31.03.2004
2. с 02.03.2004 по 03.05.2004
3. с 02.03.2004 по 03.04.2004
В первом случае все данные будут посчитаны по таблице итогов. Во втором случае данные за период с 01.04.2004 по 30.04.2004 включительно будут посчитаны по таблице итогов, а за периоды с 02.03.2004 по 31.03.2004 включительно и с 01.05.2004 по 03.05.2004 включительно будут посчитаны по таблице движений. В третьем случае данные за весь указанный период будут посчитаны по таблице движений.
Читайте также: