Какой регистр отвечает за продажи в 1С 7.7 Торговля и Склад и как расширить аналитику продаж

Программист 1С v7.7 Управленческий учет Торговля и дистрибуция
← На главную

При доработке типовой конфигурации 1С 7.7 «Торговля и Склад» (ТиС) разработчики часто сталкиваются с вопросом выбора регистра для модификации данных о продажах. В конфигурации присутствуют похожие по смыслу регистры: Продажи и РеализованныйТовар. Выясним причину их разделения, разберем архитектуру движений и рассмотрим варианты добавления дополнительных разрезов учета, таких как менеджер, скидка или автор документа.

Разница между регистрами Продажи и РеализованныйТовар

Разберем назначение каждого из регистров в типовой логике конфигурации:

  1. Регистр «РеализованныйТовар»: предназначен исключительно для комиссионной торговли, когда организация выступает в роли комиссионера. Приход по этому регистру формируется в момент продажи комиссионного товара покупателю, а расход — при формировании отчета комитенту о проданных товарах. Для анализа собственных торговых операций и розницы этот регистр не предназначен.
  2. Регистр «Продажи»: основной оборотный регистр конфигурации, в котором фиксируются все факты реализации собственных и комиссионных товаров (документы Реализация, ОтчетККМ, ЧекККМ, ВозвратОтПокупателя). Именно он является источником данных для управленческого анализа.

Что касается типовых отчетов: отчет «Отчет по продажам ТМЦ» ориентирован на работу с комиссионным товаром и отражение сумм НДС. Для комплексного анализа торговой деятельности стандартным и наиболее удобным инструментом является отчет Анализ продаж, который строит выборку именно по регистру Продажи.

Архитектура регистра Продажи

Рассмотрим особенности внутреннего устройства регистра Продажи в платформе 1С 7.7:

  1. Оборотный характер: регистр не хранит входящих и исходящих остатков на каждую дату, а агрегирует обороты (как правило, с месячной периодичностью). Это обеспечивает высокую скорость формирования отчетов через объект Запрос.
  2. Централизованное проведение: движения документов по регистру формируются не в модулях каждого отдельного документа, а через общую процедуру в Глобальном модуле — глДвижениеПродажи. Это упрощает поддержку и расширение логики.
  3. Порядок измерений: составной индекс регистра формируется строго в порядке следования измерений в дереве метаданных. Первыми должны располагаться реквизиты, по которым чаще всего накладываются условия и фильтры (например, Фирма, Номенклатура).

Способ 1. Модификация типового регистра Продажи

Если требуется хранить информацию о скидках или ответственном менеджере непосредственно в типовом регистре, выполним следующие шаги:

  1. Откроем конфигуратор и добавим в регистр Продажи необходимые реквизиты: новое измерение (например, Менеджер) или ресурс (например, СуммаСкидки).
  2. Перейдем в Глобальный модуль и найдем процедуру глДвижениеПродажи. Добавим передачу и заполнение новых реквизитов при формировании движений.
  3. Сохраним конфигурацию и выполним обязательную операцию пересчета итогов.
  4. Выполним перепроведение документов за прошлые периоды, чтобы исторические данные заполнились по новой структуре.

Способ 2. Создание отдельного оборотного регистра

Если требуется сохранить типовой регистр в исходном виде для упрощения последующих обновлений конфигурации, создадим собственный оборотный регистр:

  1. Создадим новый оборотный регистр (например, ПродажиТоваров) с нужным набором измерений (Номенклатура, Покупатель, Менеджер, Склад) и ресурсов (Количество, Сумма, Себестоимость, Скидка).
  2. В процедурах проведения нужных документов (или через вызов отдельной общей процедуры в Глобальном модуле) добавим запись движений в созданный регистр.
  3. Разработаем или адаптируем отчет на языке запросов 1С 7.7 для вывода данных из нового регистра.

Способ 3. Прямые SQL-запросы без изменения регистров

Для баз данных, работающих на Microsoft SQL Server, доступен альтернативный вариант получения аналитики без добавления измерений в регистры. Необходимые данные о продавце, авторе и скидках можно извлекать прямыми SQL-запросами к таблицам шапок (DH*) и табличных частей (DT*) документов реализации, объединяя их с таблицами движений регистра (RA*). Такой подход позволяет строить произвольные отчеты без замедления типового проведения документов и изменения структуры метаданных.

← На главную