Приступая к разработке в системе 1С:Предприятие, начинающие специалисты часто сталкиваются с дилеммой: какой объект метаданных использовать для хранения тех или иных данных. Ошибка на этапе проектирования может привести к невозможности быстро получить нужные цифры в отчете или к серьезному замедлению работы системы. Рассмотрим подробно, в чем заключается разница между регистром сведений и регистром накопления, и как правильно выбирать их для решения практических задач.
Разберем основной принцип работы РегистраНакопления. Этот объект предназначен для накопления числовой информации в разрезе определенных измерений. Главное слово здесь — накапливать. Если нам нужно знать, сколько товара пришло, сколько ушло и какой остаток получился в итоге, мы всегда обращаемся к регистру накопления.
Проанализируем структуру регистра накопления. Он состоит из:
Номенклатура, Склад, Организация).Количество, Сумма, Вес).Важно помнить, что регистры накопления делятся на два типа:
Выясним причину, почему для отчета о продажах чаще используется именно регистр накопления (вид «Обороты»). Продажи — это процесс, который характеризуется суммой выручки и количеством проданного товара за интервал времени. Нам не нужно знать «остаток продаж» на вечер пятницы, нам нужно знать, сколько мы наторговали за неделю. Именно поэтому РегистрНакопления.Продажи — это классика жанра.
Теперь посмотрим на РегистрСведений. В отличие от регистра накопления, он предназначен для хранения сведений о чем-либо. Если регистр накопления отвечает на вопрос «Сколько?», то регистр сведений отвечает на вопросы «Какой?», «Где?», «Кто?» или «Почем?».
Рассмотрим ключевые особенности регистра сведений:
Проанализируем ситуацию: нам нужен отчет по ценам. Цены — это не то, что мы «складываем». Мы не суммируем вчерашнюю цену с сегодняшней. Нам нужно знать конкретное значение на дату. Следовательно, отчет о ценах строится исключительно по регистру сведений.
Для того чтобы отчеты работали быстро, платформа 1С предоставляет механизм виртуальных таблиц. Это не реальные таблицы в базе данных SQL, а запросы, которые система формирует «на лету», используя заранее рассчитанные итоги.
Посмотрим, какие таблицы мы можем использовать в запросах:
Остатки, Обороты, ОстаткиИОбороты. Платформа сама вычислит итог, вам не нужно перебирать все документы поступления и реализации с начала времен.СрезПоследних и СрезПервых. Это позволяет мгновенно получить самую свежую цену или статус объекта, не заботясь о поиске максимальной даты в базе.Рассмотрим пример обращения к виртуальной таблице остатков в коде запроса:
ВЫБРАТЬ
ТоварыНаСкладахОстатки.Номенклатура КАК Товар,
ТоварыНаСкладахОстатки.Склад КАК Склад,
ТоварыНаСкладахОстатки.ВНаличииОстаток КАК Остаток
ИЗ
РегистрНакопления.ТоварыНаСкладах.Остатки(&Период, ) КАК ТоварыНаСкладахОстатки
Давайте систематизируем наши знания и выработаем алгоритм выбора регистра. Представим, что перед нами стоит задача спроектировать учетную систему.
Шаг 1: Определяем тип данных. Если данные не числовые (например, статус «Отгружено» или ссылка на контактное лицо), выбор однозначен — это РегистрСведений. Регистр накопления умеет работать только с числами.
Шаг 2: Анализируем необходимость суммирования. Нужно ли нам складывать эти данные? Если мы фиксируем факт продажи (Количество 5 шт., Сумма 1000 руб.), и в конце дня хотим увидеть СУММУ(Количество) — используем РегистрНакопления. Если же мы фиксируем состояние (например, текущий лимит кредита для клиента), где новое значение заменяет старое — используем РегистрСведений.
Шаг 3: Проверяем связь с документами. Регистры накопления всегда жестко привязаны к регистратору (документу). Вы не можете сделать запись в них «просто так». Регистры сведений могут быть независимыми. Это позволяет редактировать их напрямую, как справочники. Это удобно для различных настроек, учетной политики или справочной информации, которая не требует документального подтверждения.
Разберем несколько конкретных кейсов, чтобы закрепить материал:
Нужно построить отчет о том, сколько часов отработал сотрудник за месяц. Мы будем суммировать часы.
Решение: Регистр накопления (вид «Обороты»). Измерения: Сотрудник, Проект. Ресурс: Часы (Число).
Сотрудница вышла замуж и сменила фамилию. Нам нужно знать и старую, и новую фамилию на разные даты. Мы не суммируем фамилии.
Решение: Регистр сведений (периодический). Измерение: ФизЛицо. Ресурс: Фамилия (Строка).
Нужно знать, сколько денег в кассе сейчас и сколько было на прошлый четверг.
Решение: Регистр накопления (вид «Остатки»). Измерения: Касса, Валюта. Ресурс: Сумма.
В сложных конфигурациях, таких как ERP, вы можете встретить данные о продажах и в регистрах накопления, и (косвенно) в регистрах сведений. Выясним, почему так происходит. В регистре накопления хранятся факты (сколько продали), а в регистре сведений могут храниться условия (какая скидка была назначена этому клиенту в момент продажи). При построении сложного отчета разработчик соединяет эти таблицы, чтобы получить полную картину.
Также стоит упомянуть исторический аспект. В версии 1С 7.7 существовали «периодические реквизиты справочников». В 1С 8 от них отказались в пользу регистров сведений, так как это значительно упростило написание запросов и повысило производительность системы. Теперь, используя виртуальную таблицу СрезПоследних, мы получаем данные одной строкой кода, тогда как раньше это требовало сложных вычислений.
Выбор регистра — это не просто формальность, а фундамент архитектуры вашего решения. Помните золотое правило: если вы собираетесь считать итоги (плюсовать и минусовать) — берите регистр накопления. Если вы фиксируете информацию, свойства или историю изменений — ваш выбор регистр сведений. Правильное использование виртуальных таблиц в обоих случаях обеспечит вашим отчетам высокую скорость работы даже на очень больших объемах данных.