Как работает регистр накопления в 1С

Регистр накопления — один из ключевых объектов метаданных в 1С, предназначенный для хранения количественных показателей: остатков товаров на складах, денежных средств, взаиморасчётов с контрагентами, объёмов продаж. В отличие от справочника, который хранит относительно статичные данные, регистр накопления фиксирует изменения во времени и позволяет получить значение показателя на любую дату.

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

Материал разбирает устройство регистра накопления на уровне платформы: чем отличаются виды «Остатки» и «Обороты», как формируются движения при проведении документа, как работают виртуальные таблицы и итоги, а также какие типичные ошибки допускают при проектировании и как их диагностировать.

Что такое регистр накопления и для чего он нужен

Регистр накопления — это таблица движений, где каждая строка (запись) отражает изменение какого-либо показателя: поступление 10 штук товара на склад, списание 500 рублей со счёта, начисление долга контрагента. Каждая запись обязательно привязана к документу-регистратору и к моменту времени (дате и позиции внутри дня), что обеспечивает хронологию изменений.

Структура регистра задаётся в конфигураторе и состоит из трёх групп полей. Измерения — это разрезы учёта: склад, номенклатура, контрагент, организация. Ресурсы — числовые показатели, которые накапливаются: количество, сумма. Реквизиты — дополнительные атрибуты записи, не участвующие в агрегации, например комментарий или ссылка на связанный объект.

Ключевое правило проектирования: всё, по чему нужно получать остатки или обороты в разрезе, должно быть измерением; всё, что суммируется, — ресурсом. Если поле ошибочно сделать реквизитом, получить по нему итоги в разрезе стандартными средствами не получится — потребуется пересчёт полным сканированием таблицы движений.

Виды регистров накопления: Остатки и Обороты

Платформа предлагает два вида регистров накопления, и выбор между ними определяет поведение итогов. Регистр вида «Остатки» предполагает, что каждая запись имеет вид движения — «Приход» или «Расход». Остаток на любую дату вычисляется как сумма приходов минус сумма расходов с начала ведения учёта. Типичные примеры: «ТоварыНаСкладах», «ДенежныеСредства», «Взаиморасчеты».

Регистр вида «Обороты» не различает приход и расход — записи просто суммируются за период. Получить остаток на дату из такого регистра нельзя, зато он компактнее и быстрее: платформе не нужно поддерживать таблицу итогов остатков. Оборотные регистры применяют для показателей, где важна только сумма за период: «Продажи», «ОбъёмЗакупок», «КоличествоОказанныхУслуг».

Частая ошибка проектирования — делать регистр «Остатки» там, где достаточно «Оборотов», и наоборот. Если по регистру продаж никогда не запрашивается «остаток продаж» (что лишено смысла), вид «Остатки» только замедляет проведение и раздувает итоги. Обратная ошибка опаснее: превратить оборотный регистр в остаточный позже нельзя без потери данных и переписывания всех запросов.

Как документы формируют движения по регистру

Записи в регистр накопления не создаются напрямую — их всегда формирует документ при проведении. В модуле объекта документа разработчик описывает обработку проведения: заполняет коллекцию Движения.ИмяРегистра, добавляет записи, указывает вид движения, измерения и ресурсы, затем платформа записывает набор в базу.

Типовой шаблон проведения выглядит так: сначала в движения добавляются записи по табличной части документа (приход товара), затем, если требуется контроль остатков, выполняется запрос к виртуальной таблице остатков с учётом только что записанных движений. Если остатка не хватает, выдаётся сообщение и устанавливается Отказ = Истина — транзакция проведения откатывается целиком.

Движения.ТоварыНаСкладах.Записывать = Истина;
Для Каждого СтрокаТовара Из Товары Цикл
    Движение = Движения.ТоварыНаСкладах.Добавить();
    Движение.ВидДвижения = ВидДвиженияНакопления.Приход;
    Движение.Период = Дата;
    Движение.Номенклатура = СтрокаТовара.Номенклатура;
    Движение.Склад = Склад;
    Движение.Количество = СтрокаТовара.Количество;
КонецЦикла;

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

Виртуальные таблицы: как читать данные регистра

Физически регистр накопления — это таблица движений, но обращаться к ней напрямую для получения итогов неэффективно. Платформа предоставляет виртуальные таблицы, которые вычисляются на лету или по заранее рассчитанным итогам. Для регистра вида «Остатки» доступны три виртуальные таблицы: Остатки, Обороты и ОстаткиИОбороты; для оборотного регистра — только Обороты.

Таблица Остатки возвращает остатки на указанный момент времени в разрезе измерений. Таблица Обороты — суммы прихода и расхода за период. ОстаткиИОбороты объединяет обе: начальный остаток, приход, расход и конечный остаток за период — это основа большинства складских и расчётных отчётов.

При запросе к виртуальным таблицам важно передавать параметры (период, отборы по измерениям) именно в параметрах виртуальной таблицы, а не в секции ГДЕ. Отбор в секции ГДЕ заставляет платформу сначала выбрать все итоги, а потом фильтровать их в памяти — на больших регистрах это кратно замедляет запрос.

1. 1
   В консоли запросов выберите виртуальную таблицу РегистрНакопления.ТоварыНаСкладах.Остатки
2. 2
   В параметрах таблицы укажите Период — момент, на который нужны остатки
3. 3
   В параметрах же задайте условие по измерениям, например Склад = &Склад
4. 4
   Выберите поля измерений и поле КоличествоОстаток
5. 5
   Выполните запрос и сверьте результат со штатным отчётом по регистру

Итоги, периодичность и производительность

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

Если актуальные остатки не нужны (например, регистр используется только в архивных отчётах), хранение итогов можно отключить — это ускорит проведение документов, но замедлит любые запросы остатков. Также на производительность влияет количество измерений: каждое измерение увеличивает объём итоговых таблиц, поэтому не следует добавлять измерения «про запас».

Признак проблем с производительностью регистра — резкое замедление проведения документов при росте базы. Диагностируется это замером времени записи движений и анализом блокировок: регистры остатков при контроле остатков создают управляемые блокировки по измерениям, и при высокой конкурентной нагрузке (много пользователей проводят документы по одному складу) возможны конфликты.

Контроль остатков и типичные сценарии

Классический сценарий использования регистра остатков — запрет списания в минус. При проведении расходного документа после записи движений выполняется запрос к таблице остатков на момент документа с отбором по измерениям табличной части. Если по какой-то позиции остаток отрицательный, проведение отменяется с сообщением о нехватке.

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

Как проверить корректность данных регистра

Базовая проверка — сверка остатков по виртуальной таблице с штатным отчётом конфигурации. Если отчёт и запрос расходятся, чаще всего причина в параметрах виртуальной таблицы: разный момент времени, разные отборы, неучтённая граница итогов. Вторая проверка — поиск записей без регистратора или с «битой» ссылкой: такие записи появляются после сбоев или некорректных обменов.

Для диагностики «разъехавшихся» остатков полезен отчёт по таблице ОстаткиИОбороты с группировкой по регистратору: он показывает, какие документы сформировали расхождение. Если подозрение на повреждение итогов, выполняется пересчёт итогов регистра (через тестирование и исправление или программно) — на копии базы, поскольку операция ресурсоёмкая.

FAQ