← На главную

При организации хранения нормативных документов, таких как приказы, инструкции и политики, в системе 1С, часто возникает вопрос о выборе наиболее подходящего механизма. Рассмотрим различные варианты и их комбинации, а также разберем, как реализовать дополнительные требования, такие как версионирование, подтверждение ознакомления и классификация документов.

Выбор основного объекта для хранения документов: Справочник, Документ или Регистр сведений

Первоначальный выбор объекта метаданных критически важен, так как он определяет базовые возможности системы по работе с нашими нормативными документами. Рассмотрим каждый из вариантов и выясним, когда какой из них предпочтительнее.

1. Хранение в Справочнике (каждый документ – отдельный элемент)

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

   • Уникальность и ссылочность: Каждый документ будет иметь свою уникальную ссылку (GUID), что позволит нам легко ссылаться на него из других объектов системы (например, из кадровых документов, бизнес-процессов). Это удобно для организации связей и иерархий.
   • Простота поиска: В списке элементов справочника найти нужный документ по наименованию, номеру или дате будет достаточно просто. Мы можем использовать стандартные механизмы поиска и фильтрации.
   • Статичность информации: Справочники лучше подходят для хранения относительно статической информации, которая описывает объекты и редко меняется. Если сам факт существования приказа или инструкции постоянен, а меняются лишь его версии, справочник может быть хорошей основой.
   • Расширяемость: К элементу справочника мы можем добавить множество реквизитов, характеризующих документ: номер, дата утверждения, автор, вид документа (приказ, инструкция), категория (внутренний/внешний).

   Когда это подходит: Этот вариант удобен, когда каждый нормативный документ воспринимается как самостоятельный, уникальный объект, на который нужно ссылаться. Например, для списка всех действующих инструкций или приказов.

2. Хранение в Регистре сведений

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

   • Исторические данные: Регистры сведений идеально подходят для хранения исторической информации. Мы можем фиксировать изменения документа во времени, например, дату утверждения новой редакции, дату отмены, период действия.
   • Необъектная природа: В отличие от справочников, записи регистра сведений не являются «объектными сущностями». Мы не можем напрямую сослаться на отдельную запись регистра из другого объекта, но можем сделать запрос к регистру по набору измерений.
   • "Бесконечная табличная часть": Если изначально была мысль хранить все в табличной части одного документа или элемента справочника, регистр сведений по сути предоставляет функционал «бесконечной табличной части», где каждая строка является отдельной записью с набором измерений и ресурсов.
   • Периодичность: Регистр может быть периодическим, что позволяет нам хранить данные, актуальные на определенную дату. Например, какая редакция инструкции действовала на 01.01.2024.

   Когда это подходит: Регистры сведений полезны, когда акцент делается на изменение данных во времени и их историю, а не на сам объект документа как таковой. Например, для хранения актуальных версий документов или истории их изменения. Часто регистры используются в связке с документами.

   Пример структуры регистра сведений:

   Скопировать код

   
   РегистрСведений.НормативныеДокументыСведения (Периодический, Зависимый/Независимый)
       Измерения:
           ДокументСсылка (Тип: СправочникСсылка.НормативныеДокументы)
           ДатаРедакции (Тип: Дата)
       Ресурсы:
           НомерДокумента (Тип: Строка)
           Наименование (Тип: Строка)
           СодержаниеТекст (Тип: Строка, НеограниченнойДлины)
           Ответственный (Тип: СправочникСсылка.Пользователи)
           Статус (Тип: ПеречислениеСсылка.СтатусыДокументов)
   

3. Хранение с помощью Документа (и, возможно, Регистр сведений)

   Использование документов в 1С предполагает фиксацию некоего события. Создание, утверждение, изменение или отмена нормативного документа – это все события, которые могут быть отражены соответствующими документами.

   • Фиксация событий: Документ идеально подходит для отражения факта создания или изменения документа. Например, "ДокументУтверждениеПриказа" или "ДокументИзменениеИнструкции".
   • Регистрация данных: Сам документ может содержать всю необходимую информацию о приказе/инструкции: номер, дату, текст, ответственного, присоединенные файлы.
   • Движения в регистрах: Документ может делать движения в регистрах сведений (например, в периодическом регистре), фиксируя актуальную версию документа на определенную дату. Это позволяет нам иметь и историчность, и событийность.
   • Бизнес-процессы: Документы легко интегрируются в бизнес-процессы, например, для согласования и утверждения.

   Когда это подходит: Этот вариант – один из самых гибких и мощных. Он позволяет нам не только хранить информацию о документах, но и управлять их жизненным циклом через события (документы) и отслеживать историю (регистры).

   Пример:

   1. Создаем справочник НормативныеДокументы для хранения списка всех документов (Приказ №1, Инструкция по ОТ и т.п.). Элементы этого справочника являются уникальными "шапками" документов.
   2. Создаем документ УтверждениеРедакцииНормативногоДокумента. В этом документе мы указываем ссылку на элемент справочника НормативныеДокументы, а также прикрепляем саму редакцию (например, как текст в реквизите или как присоединенный файл).
   3. При проведении документа УтверждениеРедакцииНормативногоДокумента, он делает движения в регистре сведений АктуальныеРедакцииНормативныхДокументов, записывая, какая редакция документа является актуальной на дату утверждения, и сохраняет метаданные о ней (номер, дата, текст, ответственный).

Реализация специфических требований

После выбора основного механизма хранения, давайте разберем, как мы можем реализовать дополнительные требования, озвученные в задаче.

1. Хранение истории изменений и версионирование

Потребность в хранении истории изменений нормативных документов – это стандартное требование. В 1С существует встроенный механизм версионирования, который значительно упрощает эту задачу.

1. Встроенный механизм "История данных" (Версионирование)

   Платформа 1С предлагает готовый инструмент для версионирования объектов конфигурации. Этот механизм позволяет нам хранить все изменения объекта, упорядоченные по шкале времени.

   • Настройка: Мы можем настроить версионирование для любых объектов, будь то элементы справочника или документы. Настройка осуществляется через раздел Администрирование -> Общие настройки. Здесь необходимо установить флажок "Хранить историю изменений" и выбрать объекты, для которых будет вестись история.
   • Глубина версионирования: Мы можем настроить, что именно будет версионироваться: объект целиком или только определенные реквизиты, включая табличные части.
   • Момент сохранения: Определим, когда будет сохраняться новая версия: при записи элемента справочника, или при записи/проведении документа.
   • Срок хранения: Также мы можем указать срок хранения версий и настроить автоматическое удаление устаревших версий для экономии места в базе.
   • Просмотр и сравнение: Механизм версионирования предоставляет удобные средства для просмотра всех сохраненных версий объекта, их сравнения и даже возврата к предыдущим версиям.
   • Комментарии: При сохранении версии можно добавлять комментарии, описывающие суть изменений.

   Как это использовать: Если мы используем справочник или документ для хранения наших нормативных документов, просто активируем для них версионирование. Платформа сама будет отслеживать и сохранять изменения. Это самый простой и эффективный способ получить историю версий без дополнительного программирования.

2. Ручное версионирование через регистры сведений

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

   Например, при изменении документа, мы создаем новый документ УтверждениеНовойРедакции, который фиксирует новую редакцию и дату ее вступления в силу, а затем записывает новую запись в периодический регистр сведений.

2. Реализация подтверждения ознакомления

Требование о подтверждении ознакомления с документом, включая хранение даты, сотрудника и возможность запроса, является ключевым для нормативных документов.

1. Использование бизнес-процессов

   Наиболее мощный и гибкий способ реализации ознакомления – это использование бизнес-процессов 1С. В типовых конфигурациях, таких как 1С:Документооборот, уже реализован готовый механизм "Ознакомление".

   • Настройка процесса: Мы можем создать новый бизнес-процесс или использовать типовой, который включает задачу ознакомления для определенного круга сотрудников или подразделений.
   • Фиксация "подписи": В рамках задачи ознакомления система фиксирует факт ознакомления сотрудником (например, нажатием кнопки "Ознакомлен"), дату и время. Это может быть приравнено к электронной подписи (если настроено) или просто являться системной отметкой о прочтении.
   • Данные об ознакомлении: Информация о том, кто, когда и с каким документом ознакомился, может храниться в специализированном регистре сведений (например, РегистрСведений.ОзнакомлениеСДокументами) или быть частью механизма бизнес-процессов.
   • Отказ от ознакомления: Если сотрудник отказывается ознакомиться или подтвердить ознакомление, мы можем предусмотреть отдельный шаг в бизнес-процессе или механизм для фиксации этого факта (например, через создание акта об отказе от ознакомления, который также может быть зафиксирован в 1С).
   • Отчетность: Мы можем построить отчеты о ходе ознакомления, о сотрудниках, которые еще не ознакомились, и о датах ознакомления. В 1С:Документооборот такие отчеты доступны, например, в карточке документа на закладке "Обработка - Результаты обработки".

   Пример архитектуры:

   Скопировать код

   
   // Предположим, что у нас есть Справочник.НормативныеДокументы
   // и Документ.УтверждениеРедакцииНормативногоДокумента.
   
   // Регистр сведений для хранения информации об ознакомлении
   РегистрСведений.ОзнакомлениеСНормативнымиДокументами (Независимый, Непериодический)
       Измерения:
           ДокументОснование (Тип: ДокументСсылка.УтверждениеРедакцииНормативногоДокумента)
           Сотрудник (Тип: СправочникСсылка.Сотрудники)
       Ресурсы:
           ДатаОзнакомления (Тип: Дата)
           Подтверждено (Тип: Булево)
           Комментарий (Тип: Строка)
       Реквизиты:
           ДатаЗапросаНаОзнакомление (Тип: Дата)
   
   // Кнопка на форме документа/справочника "Запросить ознакомление"
   // Действия при нажатии кнопки:
   // 1. Создание задачи бизнес-процесса "Ознакомление" для выбранных сотрудников.
   // 2. В задаче сотрудник нажимает "Ознакомлен".
   // 3. Обработчик выполнения задачи записывает данные в РегистрСведений.ОзнакомлениеСНормативнымиДокументами.
   
   // Пример кода для записи в регистр при подтверждении ознакомления:
   Процедура ЗаписатьФактОзнакомления(ДокументОснование, Сотрудник, Комментарий)
       НаборЗаписей = РегистрыСведений.ОзнакомлениеСНормативнымиДокументами.СоздатьНаборЗаписей();
       НаборЗаписей.Отбор.ДокументОснование.Установить(ДокументОснование);
       НаборЗаписей.Отбор.Сотрудник.Установить(Сотрудник);
       НаборЗаписей.Прочитать();
   
       Если НаборЗаписей.Количество() = 0 Тогда
           Запись = НаборЗаписей.Добавить();
       Иначе
           Запись = НаборЗаписей[0];
       КонецЕсли;
   
       Запись.ДокументОснование = ДокументОснование;
       Запись.Сотрудник = Сотрудник;
       Запись.ДатаОзнакомления = ТекущаяДата();
       Запись.Подтверждено = Истина;
       Запись.Комментарий = Комментарий;
   
       НаборЗаписей.Записать();
   КонецПроцедуры
   

3. Классификация внутренних и внешних документов

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

1. Использование реквизитов или видов документов

   Самый простой способ – добавить реквизит ВидДокумента (тип Перечисление или Справочник) в наш справочник НормативныеДокументы или документ УтверждениеРедакцииНормативногоДокумента.

   Скопировать код

   
   // В Справочник.НормативныеДокументы добавляем реквизит:
   Реквизит: ВидДокумента (Тип: ПеречислениеСсылка.ВидыНормативныхДокументов)
   
   // Перечисление.ВидыНормативныхДокументов может содержать значения:
   // - ВнутреннийПриказ
   // - ВнутренняяИнструкция
   // - ВнешнееПисьмо
   // - НормативныйАкт
   

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

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

Общие архитектурные рекомендации и хранение файлов

При проектировании системы хранения важно помнить об общих принципах архитектуры 1С.

1. Выбор типа объекта метаданных

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

2. Хранение самих файлов

   Важно различать хранение метаданных о документе (номер, дата, ответственный, статус) и хранение самого электронного файла документа (например, .doc, .pdf). По своему опыту, рекомендуется хранить сами файлы не в базе данных 1С, а в директории на сервере или в специализированном файловом хранилище.

   • Почему не в базе: Хранение больших бинарных файлов непосредственно в базе данных 1С приводит к быстрому распуханию базы, что значительно замедляет ее работу, увеличивает время резервного копирования и восстановления, а также усложняет обслуживание.
   • Как реализовать: В 1С есть подсистема "Присоединенные файлы" (часть Библиотеки Стандартных Подсистем - БСП). Она позволяет прикладывать файлы к любым объектам 1С, при этом сами файлы могут храниться как в базе (для небольших) или во внешнем томе (на сервере, в сетевой папке). Рекомендуется использовать внешний том.
   • Метаданные о файлах: Даже если файлы хранятся вовне, метаданные о них (имя файла, путь, дата загрузки, пользователь, размер) будут храниться в базе данных, что позволяет нам легко управлять ими и находить нужный файл.

3. Поиск и отчетность

   Для эффективного поиска документов, отслеживания их статуса и изменений, мы можем использовать стандартные инструменты 1С: "Общий журнал документов" (если используем документы), "История изменений документа/справочника" (для версионирования) и, конечно же, строить собственные отчеты на базе регистров сведений, где аккумулируются все необходимые данные.

Таким образом, для хранения нормативных документов в 1С наиболее универсальным и мощным решением часто является комбинация Справочника (для самих документов как объектов), Документов (для фиксации событий жизненного цикла, например, утверждения редакций) и Регистров сведений (для хранения истории изменений, актуальных версий и фактов ознакомления). Дополнительно используем встроенное версионирование и механизмы БСП для работы с присоединенными файлами и бизнес-процессами.