Как реализовать учет заявок в 1С: выбрать справочник, документ или бизнес-процесс?

← На главную

При разработке собственной подсистемы Service Desk, Helpdesk или учета произвольных заявок (на оплату, отпуск, техподдержку) разработчик сталкивается с базовой архитектурной дилеммой: какой объект метаданных платформы 1С должен выступать основой заявки и как фиксировать связанные с ней события. Рассмотрим подробнее критерии выбора архитектурного решения, особенности работы каждого объекта платформы и практические паттерны проектирования.

Критерии выбора: справочник, документ или бизнес-процесс

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

Заявка как документ (ДокументОбъект). Выбирается в ситуациях, когда заявка фиксирует факт хозяйственной деятельности или учетное событие во времени, меняет показатели в регистрах (накопления или бухгалтерии) и требует механизма проведения и отмены проведения. У документа из коробки есть стандартный реквизит Дата, поддержка последовательностей, механизм «Даты запрета изменения данных» и возможность включения в журналы документов.
Заявка как справочник (СправочникОбъект). Подходит, если заявка является сущностью-контейнером или элементом аналитики (тикет, карточка задачи), которая многократно меняет свой статус, редактируется несколькими сотрудниками и не делает жестких проводок. Справочник обеспечивает встроенную иерархию элементов («Заявка — подзадачи») и меньшую нагрузку при частых изменениях, так как не требует механизма транзакционного перепроведения движений.
Заявка как связка «Бизнес-процесс + Задача» (БизнесПроцессОбъект, ЗадачаОбъект). Оптимальный выбор для сложных маршрутов согласования с ветвлением условий, ролевой адресацией исполнителей и динамическим контролем сроков выполнения этапов.

Организация ленты событий и комментариев по заявке

В процессе жизненного цикла заявки требуется фиксировать хронологию: комментарии, смену ответственных, переходы статусов. Разберем три способа реализации этого механизма:

Подчиненный периодический регистр сведений (рекомендуемый вариант). Создается непериодический или периодический регистр сведений (например, ИсторияЗаявок или СобытияПоЗаявкам), где ведущим измерением выступает ссылка на заявку. Это позволяет пользователям добавлять комментарии и статусы без блокировки основного объекта заявки, избегая таймаутов блокировок при конкурентной работе.
Табличная часть объекта. Хранение истории непосредственно в табличной части заявки просто в реализации, однако приводит к постоянному росту объема записи объекта при чтении формы и блокирует всю заявку целиком при отправке каждого нового сообщения. Не подходит для документов, которые уже проведены и закрыты от изменений.
Подчиненные документы взаимодействия. Создание отдельных документов (например, Событие, Взаимодействие) с указанием заявки в качестве документа-основания. Оправдано, если каждое событие само по себе является учетным фактом (звонок, выезд специалиста, акт выполненных работ) и требует раздельных прав доступа.

Практический паттерн: разделение карточки заявки и учетных движений

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

Заявка создается как Справочник (или документ без движений) со статусной моделью (Новая, В работе, Выполнена, Отклонена).
Переписка, логирование и смена состояний пишутся в Регистр сведений.
Когда по заявке требуется отразить реальную хозяйственную операцию (списание материалов, выплата денежных средств), на ее основании создаются целевые Документы конфигурации, выполняющие движения по регистрам.

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


Процедура ЗафиксироватьСобытиеПоЗаявке(СсылкаНаЗаявку, ВидСобытия, ТекстКомментария, ТекущийПользователь) Экспорт

    НаборЗаписей = РегистрыСведений.ИсторияЗаявок.СоздатьНаборЗаписей();
    НаборЗаписей.Отбор.Заявка.Установить(СсылкаНаЗаявку);
    
    НоваяЗапись = НаборЗаписей.Добавить();
    НоваяЗапись.Период = ТекущаяДатаСеанса();
    НоваяЗапись.Заявка = СсылкаНаЗаявку;
    НоваяЗапись.ВидСобытия = ВидСобытия;
    НоваяЗапись.Комментарий = ТекстКомментария;
    НоваяЗапись.Автор = ТекущийПользователь;
    
    // Записываем без очистки предыдущих записей
    НаборЗаписей.Записать(Ложь);

КонецПроцедуры

Паттерн статусной модели проведения документа

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


Процедура ОбработкаПроведения(Отказ, РежимПроведения)
    
    // Движения формируются только на определенных этапах жизненного цикла
    Если Статус = Перечисления.СтатусыЗаявок.Черновик 
        Или Статус = Перечисления.СтатусыЗаявок.НаСогласовании Тогда
        // В предварительных статусах движений по регистрам накопления нет
        Возврат;
    КонецЕсли;
    
    Если Статус = Перечисления.СтатусыЗаявок.Утверждена Тогда
        // Формируем движения планирования или резервирования ресурсов
        Движение = Движения.ПланыЗаявок.ДобавитьПриход();
        Движение.Период = Дата;
        Движение.Заявка = Ссылка;
        Движение.Количество = ТабличнаяЧасть.Итог("Количество");
    КонецЕсли;

КонецПроцедуры

Итоги

Проектирование структуры данных следует вести от конечных учетных показателей: если заявка представляет собой этап бизнес-процесса и ленту коммуникаций, предпочтительнее использовать Справочник в связке с Регистром сведений; если заявка формирует оперативные остатки, резервы и контролируется по датам запрета редактирования — используем Документ с ветвлением логики проведения по статусам.