При разработке конфигураций для сервисных центров, ремонтных мастерских или отделов технического обслуживания (ТОИР) разработчики часто сталкиваются с фундаментальной дилеммой: в каком объекте метаданных хранить информацию о ремонтируемых приборах? На первый взгляд может показаться заманчивым создать единый документ "Прибор", который будет содержать всю информацию о поступлении, процессе ремонта и выдаче. Однако на практике такой подход быстро приводит к архитектурному тупику.
В этой статье мы подробно разберем, почему противопоставление справочника и документа является ложным, как правильно распределить функции между объектами метаданных 1С и построить надежную структуру учета, способную выдерживать масштабирование и повторные обращения клиентов.
Рассмотрим ситуацию, когда разработчик решает хранить ремонтируемый прибор в виде документа (например, Документ.Прибор). При этом проведение документа означает выдачу прибора клиенту, а дата документа — дату его приема. На первый взгляд, это кажется логичным: у прибора есть жизненный цикл, и после выдачи он нам больше "не интересен".
Проанализируем последствия такого решения:
В профессиональной разработке и тиражных решениях 1С (например, в решениях класса ТОИР или ERP) эта задача решается четким разделением сущностей на три уровня: Справочники, Документы и Регистры.
Выясним назначение каждого элемента в этой цепочке:
1. Справочники (Физические сущности)
Для хранения информации о самих приборах используются справочники. При этом структуру рекомендуется делать двух- или трехступенчатой:
Номенклатура — хранит общие сведения о моделях техники (например, "Смартфон Samsung Galaxy S23", "Материнская плата Asus Rog"). Это общая карточка без привязки к конкретному экземпляру.СерииНоменклатуры (или подчиненный справочник СерийныеНомера) — хранит информацию о конкретном физическом приборе с его уникальным заводским серийным номером (S/N).ОбслуживаемыеОбъекты (или "Принимаемая техника") — это связующий элемент. Он указывает, какой конкретно прибор (серия номенклатуры) принадлежит какому контрагенту (клиенту). Именно к этому элементу будет привязываться вся история ремонтов.2. Документы (Хозяйственные операции)
Документы не должны заменять собой приборы. Документы фиксируют события, происходящие с приборами во времени. Разберем стандартную цепочку документов:
ПриемкаВРемонт (или "Заказ-наряд") — фиксирует факт поступления устройства от клиента, его комплектность, заявленные неисправности и предварительную стоимость.ВыполнениеРемонта — отражает работу мастера, диагностику, а также списывает со склада использованные запчасти и расходные материалы.ВыдачаИзРемонта — фиксирует передачу исправного прибора клиенту, подписание акта выполненных работ и оплату.3. Регистры (Состояние и аналитика)
Для оперативного получения информации о том, где сейчас находится прибор и что с ним происходит, используются регистры. Вся история изменений записывается именно туда при проведении документов.
Вместо того чтобы хранить статус ремонта прямо в реквизитах прибора или документа приемки, мы создадим периодический регистр сведений СостоянияПриборов.
Структура регистра сведений:
Прибор (тип: СправочникСсылка.ОбслуживаемыеОбъекты)Состояние (тип: ПеречислениеСсылка.СостоянияПриборов — значения: "Принят", "На диагностике", "В работе", "Ожидает запчастей", "Готов к выдаче", "Выдан")ДокументДвижения (тип: ДокументСсылка)Рассмотрим пример кода для записи нового состояния прибора при проведении документа:
Процедура УстановитьСостояниеПрибора(ДокументСсылка, Прибор, НовоеСостояние) Экспорт
МенеджерЗаписи = РегистрыСведений.СостоянияПриборов.СоздатьМенеджерЗаписи();
МенеджерЗаписи.Период = ДокументСсылка.Дата;
МенеджерЗаписи.Прибор = Прибор;
МенеджерЗаписи.Состояние = НовоеСостояние;
МенеджерЗаписи.ДокументДвижения = ДокументСсылка;
МенеджерЗаписи.Записать(Истина);
КонецПроцедуры
Использование регистра позволяет нам в любой момент времени легко получить текущее состояние любого прибора с помощью метода среза последних:
Функция ПолучитьТекущееСостояниеПрибора(Прибор) Экспорт
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ ПЕРВЫЕ 1
| СостоянияПриборовСрезПоследних.Состояние КАК Состояние,
| СостоянияПриборовСрезПоследних.ДокументДвижения КАК ДокументДвижения
|ИЗ
| РегистрСведений.СостоянияПриборов.СрезПоследних(, Прибор = &Прибор) КАК СостоянияПриборовСрезПоследних";
Запрос.УстановитьПараметр("Прибор", Прибор);
Выборка = Запрос.Выполнить().Выбрать();
Если Выборка.Следующий() Тогда
Возврат Новый Структура("Состояние, Документ", Выборка.Состояние, Выборка.ДокументДвижения);
КонецЕсли;
Возврат Неопределено;
КонецФункции
При приемке прибора в сервисный центр ему часто присваивается внутренний уникальный номер (например, номер обращения + порядковый номер прибора в ремонте), который распечатывается на наклейке со штрихкодом. Где правильно его хранить?
Важно разделять две сущности:
СерииНоменклатуры один раз на всю жизнь прибора.Правильным решением будет создание регистра сведений ШтрихкодыПриборовВРемонте. Измерениями регистра будут выступать ДокументПриемки (Заказ-наряд) и Прибор, а ресурсом — строковый Штрихкод (уникальный идентификатор текущего обращения). При сканировании штрихкода в процессе ремонта система мгновенно определит, в рамках какого именно заказ-наряда этот прибор сейчас находится у мастера.
На практике часто возникает необходимость сгруппировать разные приборы из разных заявок для выполнения однотипных задач (например, мастер берет в работу сразу пять ноутбуков разных клиентов на замену термопасты).
Поскольку наши приборы — это элементы справочника, мы можем легко организовать их группировку с помощью специального документа — ГрупповойРемонт (или "Маршрутный лист"). В табличную часть этого документа подбираются ссылки на конкретные приборы из справочника. При проведении этот документ делает движения по регистру состояний, переводя выбранные приборы в статус "В групповой работе", а по завершении — распределяет общую трудоемкость и затраченные мастером материалы на себестоимость ремонта каждого отдельного прибора.
Таким образом, использование классической структуры "Справочник (для сущности) + Документ (для операции) + Регистр (для состояния)" гарантирует стабильность базы данных, быстродействие системы и неограниченные аналитические возможности для построения отчетов любой сложности.