При разработке конфигураций для автотранспортных предприятий или при создании дипломных проектов часто возникает классическая задача: необходимо сохранять в базе конкретный автомобиль с начальным значением пробега, регулярно изменять (увеличивать) это значение с помощью документов (например, путевых листов) и обнулять при достижении определенного лимита. Возникает закономерный вопрос: какой тип регистра 1С лучше всего подходит для этих целей?
Давайте подробно разберем эту ситуацию, проанализируем возможные варианты реализации и выясним причины частых ошибок, с которыми сталкиваются начинающие разработчики.
Прежде чем создавать объекты в дереве конфигурации, давайте разберем по шагам требования к системе. Из постановки задачи мы видим следующие ключевые условия:
Для решения этой задачи нам предстоит выбрать между Регистром Сведений (РС) и Регистром Накопления (РН). На практике, в профессиональных типовых решениях (например, в 1С:УАТ), используется комбинированный подход. Рассмотрим подробнее каждый вариант.
Если наша главная цель — в любой момент времени знать точные цифры, которые водитель видит на приборной панели (одометре), то идеальным решением будет Периодический регистр сведений.
Структура такого регистра будет выглядеть так:
Автомобиль (СправочникСсылка.Автомобили).ПоказанияСчетчика (Число).При использовании этого подхода разработчики часто сталкиваются с критической ошибкой. При попытке провести второй документ по одному и тому же автомобилю система выдает предупреждение: «Запись с такими ключевыми полями существует». Выясним причину этой ошибки. Она возникает, если в свойствах регистра сведений не включена периодичность. В непериодическом регистре для одного автомобиля можно сохранить значение лишь один раз. Чтобы документы могли регулярно обновлять пробег, регистр обязательно должен быть периодическим. Наилучшей практикой здесь будет установка периодичности ПоПозицииРегистратора. Это жестко привяжет показания к конкретному документу и точному времени его проведения.
Для извлечения текущих показаний пробега из такого регистра мы будем использовать виртуальную таблицу:
РегистрСведений.ПробегАвтомобилей.СрезПоследних
Теперь проанализируем условие: «если пробег больше максимального, нужно его обнулить». Скорее всего, речь идет о контроле пробега до планового технического обслуживания (ТО). Для алгоритмов, подразумевающих накопление ресурса и последующее его списание (обнуление), Регистр Сведений не подходит. Здесь нам понадобится Регистр накопления с видом «Остатки».
Создадим следующую структуру:
Автомобиль.ПробегДоТО.Как будет работать алгоритм проведения в этом случае? Разберем по шагам:
ПробегДоТО увеличивается на 200.РегистрНакопления.ПробегТСТК.Остатки.Пример кода формирования движения прихода для документа маршрута:
Движения.ПробегАвтомобилейДоТО.Записывать = Истина;
Движение = Движения.ПробегАвтомобилейДоТО.Добавить();
Движение.ВидДвижения = ВидДвиженияНакопления.Приход;
Движение.Период = Дата;
Движение.Автомобиль = ТранспортноеСредство;
Движение.ПробегДоТО = ПройденноеРасстояние;
Если бы задача требовала получения суммарных данных за определенный период (например, сколько километров проехал каждый автомобиль за прошедший месяц для расчета зарплаты или списания ГСМ по нормам), нам бы потребовался Регистр накопления с видом «Обороты».
В оборотном регистре нет понятия остатков, он фиксирует только дельту (пройденное расстояние за рейс). Получить из него начальный или текущий абсолютный пробег автомобиля невозможно, поэтому для задачи с обнулением и фиксацией показаний на панели приборов он применяется только как вспомогательный инструмент для отчетов через таблицу Обороты.
Давайте сведем все воедино и посмотрим на пример идеальной архитектуры для подобной задачи, к которой не будет вопросов ни у преподавателей на защите диплома, ни у реальных заказчиков:
Применяя этот структурированный подход, вы получаете гибкую систему: у вас есть и точные исторические показания приборов (через срез последних), и удобный контроль лимитов (через проверку остатков регистра накопления).