Классификатор документов в 1С:Документообороте: как построить понятную структуру

Классификатор документов в 1С:Документообороте: как построить понятную структуру

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

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

Самый простой пример. Пользователь создал договор, но выбрал вид “Прочий документ”. Карточка есть, файл приложен, номер присвоен. Вроде бы документ создан. Но маршрут согласования договора не стартовал, в отчет по договорам он не попал, юристы его в привычном списке не видят.

Формально пользователь просто ошибся в выборе вида. Фактически документ выпал из процесса.

Бывает и другая картина. База живет несколько лет, и в классификаторе уже есть “Договор”, “Договор новый”, “Договор основной”, “Договор с поставщиком”, “Дог. поставка”, “Договор не использовать”, “Прочий договор”. Часть видов появилась при внедрении, часть добавили по просьбе пользователей, часть осталась после старых доработок. Никто уже не уверен, какой вид правильный, но удалять страшно: вдруг где-то завязан маршрут, отчет или старая обработка.

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

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

 

 

Что я называю классификатором документов

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

В этой статье я говорю о классификаторе как о рабочей структуре, которая помогает ответить на простые вопросы:

• какой документ создает пользователь;
• куда он должен попасть;
• какие реквизиты нужно заполнить;
• какой маршрут должен стартовать;
• кто должен видеть документ;
• какой шаблон нужно использовать;
• как документ потом найти;
• попадет ли он в нужный отчет.

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

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

Для меня главный признак нормального классификатора простой: пользователь может выбрать вид документа без отдельной консультации с аналитиком. Не всегда, конечно. Бывают сложные случаи. Но если почти по каждому документу появляется вопрос в чат “а какой вид выбрать?”, значит структура уже спорная.

 

Почему нельзя просто перенести список из Excel

На обследовании заказчик часто присылает Excel со списком документов. Там могут быть договоры, письма, акты, приказы, заявки, протоколы, служебные записки, дополнительные соглашения и еще несколько десятков строк.

Выглядит удобно: бери список и заводи виды документов. Но переносить такой список один в один без разбора — рискованная история.

Excel обычно показывает, как документы называются в компании. Но он не всегда показывает, как с ними работают в 1С:Документообороте.

Например, в списке могут быть такие строки:

• Договор поставки;
• Договор поставки с предоплатой;
• Договор поставки с отсрочкой платежа;
• Договор поставки с нерезидентом;
• Договор поставки для филиала;
• Договор поставки с особым порядком согласования.

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

В таких местах пользователи почти неизбежно начинают выбирать “на глаз”. Один сотрудник выберет по типу оплаты, другой — по контрагенту, третий — по филиалу. Через некоторое время в базе появятся документы одного смысла, но под разными видами.

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

Например, можно оставить один вид “Договор поставки”, а признаки хранить отдельно:

• условие оплаты;
• резидент или нерезидент;
• организация;
• филиал;
• категория договора;
• признак особого согласования.

Тогда пользователь выбирает понятный вид документа, а маршрут уже учитывает реквизиты. Это не всегда проще в настройке, зато обычно понятнее в эксплуатации.

Есть и обратная ситуация. Документы могут называться похоже, но жить по разным правилам. Например, “Договор” и “Дополнительное соглашение” могут иметь разные шаблоны, разные проверки, разные правила регистрации и связь с исходным договором. В таком случае отдельный вид вполне оправдан.

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

Как проверить, нужен ли новый вид документа

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

Новый вид документа имеет смысл, если он влияет хотя бы на один из элементов:

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

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

Например, если пользователи хотят отдельный вид “Договор с предоплатой”, нужно проверить: отличается ли маршрут? Нужен ли отдельный шаблон? Должны ли его видеть другие сотрудники? Нужен ли отдельный отчет? Если ответ везде “нет”, то отдельный вид может только усложнить жизнь.

На сопровождении это быстро всплывает. Сегодня добавили один вид “для удобства”. Через месяц появился второй похожий. Потом третий. Потом пользователь не понимает, что выбрать, а аналитик добавляет в маршрут условия по нескольким почти одинаковым видам.

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

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

 

 

Когда отдельный вид документа действительно нужен

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

 

Признак	Что это значит на практике	Пример
Отдельный маршрут	Документ идет по своему порядку согласования или исполнения	Договор, служебная записка, заявка на оплату
Свои обязательные реквизиты	Для документа нужны отдельные данные	У договора важны сумма и контрагент, у приказа — основание
Отдельные права доступа	Документ должны видеть не все пользователи	Кадровые документы, претензии, документы руководства
Свой жизненный цикл	У документа есть отдельные этапы	Регистрация, согласование, подписание, исполнение, архив
Свои шаблоны	Нужны отдельные шаблоны файлов или печатные формы	Договор, дополнительное соглашение, акт
Отдельная отчетность	По документу нужны отдельные показатели	Отчет по договорам, контроль входящих, отчет по поручениям
Отдельный владелец процесса	За правила работы отвечает отдельное подразделение	Юристы ведут договоры, канцелярия — входящие, HR — кадровые документы

 

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

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

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

Входящие документы — отдельная история. Для них важны регистрация, отправитель, дата поступления, исполнитель, резолюция, контроль срока. Это уже не просто файл, который кто-то загрузил в систему. Это процесс обработки входящей корреспонденции.

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

 

Когда отдельный вид лучше не создавать

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

Но потом это начинает мешать.

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

Отдельный вид документа лучше не создавать, если:

• разница только в названии;
• маршрут полностью совпадает;
• права доступа такие же;
• обязательные реквизиты одинаковые;
• шаблоны почти не отличаются;
• отдельный отчет не нужен;
• пользователь без подсказки не поймет, какой вид выбрать;
• вид создается “на всякий случай”.

Особенно осторожно я отношусь к видам “Прочее”, “Разное”, “Иное”, “Документ общий”. Иногда они нужны, но очень быстро становятся мусорной корзиной.

Пользователю проще выбрать “Прочее”, чем думать, куда правильно отнести документ. Потом сопровождение разбирает, почему в “Прочем” лежат договоры, письма, акты, служебные записки и документы, которые должны были идти по разным маршрутам.

Если “Прочее” используется регулярно, это сигнал. Либо классификатор непонятный, либо в нем действительно не хватает рабочих видов документов.

 

Слишком детальный классификатор: вроде аккуратно, но пользоваться трудно

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

Но пользователю не всегда нужна такая детализация.

Например, в классификаторе есть:

• Договор поставки с резидентом;
• Договор поставки с нерезидентом;
• Договор поставки с предоплатой;
• Договор поставки без предоплаты;
• Договор поставки с отсрочкой платежа;
• Договор поставки для филиала;
• Договор поставки для управляющей компании;
• Договор поставки с особым маршрутом.

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

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

Часть таких признаков лучше хранить в реквизитах:

• резидент или нерезидент;
• условие оплаты;
• организация;
• филиал;
• категория договора;
• признак особого согласования.

Тогда вид документа остается понятным, а маршруты можно строить по значениям реквизитов.

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

 

Слишком общий классификатор: сначала удобно, потом сложно сопровождать

Есть и обратная крайность — слишком общий классификатор. Например, когда почти все документы создаются как “Внутренний документ”, “Прочий документ” или “Документ организации”.

На старте это кажется удобным. Пользователю не нужно выбирать из большого списка, администратору не нужно заводить много видов, аналитик быстрее запускает первые маршруты.

Но позже возникают проблемы:

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

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

Слишком общий классификатор тоже не упрощает жизнь. Он просто переносит сложность в маршруты, отчеты, инструкции и поддержку.

 

Как выбрать уровень детализации

Уровень детализации лучше не выбирать “на глаз”. В 1С:Документообороте это почти всегда потом возвращается через маршруты, права и отчеты.

 

Вопрос	Если ответ “да”	Если ответ “нет”
У документа отдельный маршрут?	Отдельный вид может быть оправдан	Можно рассмотреть общий вид и реквизиты
У документа отдельные обязательные данные?	Есть аргумент за отдельный вид	Достаточно общего набора реквизитов
Документ видят другие группы пользователей?	Нужно учитывать отдельный доступ	Права не требуют разделения вида
Пользователь легко отличит этот документ от других?	Вид будет понятен в работе	Есть риск ошибок при выборе
По документу нужна отдельная отчетность?	Разделение может быть полезным	Вид ради отчета создавать не обязательно
Есть отдельный владелец процесса?	Вид может отражать отдельную область ответственности	Можно оставить в общей группе

 

Если большинство ответов “да”, отдельный вид документа, скорее всего, нужен. Если отличий мало, лучше не дробить классификатор.

Мне нравится простой рабочий критерий: вид документа должен что-то менять. Если он ничего не меняет в маршруте, правах, данных, шаблонах, отчетах и ответственности — возможно, это не вид документа, а значение реквизита.

 

Группы документов: не нужно превращать дерево в склад

Группы помогают пользователю ориентироваться в классификаторе. Но только если они названы нормальным рабочим языком.

Обычно удобно группировать документы по понятным блокам:

• договорные документы;
• входящая корреспонденция;
• исходящая корреспонденция;
• внутренние документы;
• распорядительные документы;
• кадровые документы;
• финансовые документы;
• проектные документы;
• технические документы;
• архивные документы.

Но это не универсальный шаблон. В конкретной компании структура может быть другой. Главное, чтобы пользователь понимал ее без отдельной расшифровки.

Плохой признак — группы, которые понятны только проектной команде: “Блок 1”, “Основные”, “Дополнительные”, “Документы 2 этапа”, “Прочее”, “Разное”. Для аналитика это может что-то значить. Для пользователя — обычно нет.

Если название группы понятно только тем, кто ее создавал, пользователи все равно будут выбирать наугад.

 

Наименования видов документов

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

Лучше избегать:

• внутренних сокращений, которые понимает только один отдел;
• одинаковых названий в разных группах;
• слишком длинных названий;
• названий “Прочее”, если ими начинают пользоваться постоянно;
• названий, которые описывают действие, а не документ.

Например, вид “На согласование юристу” лучше не заводить как вид документа. Согласование юристу — это часть маршрута. Документом может быть договор, дополнительное соглашение, претензия или письмо.

Еще пример: “Документ для руководителя”. Это не вид документа. Это скорее признак доступа, маршрута или получателя. Если так назвать вид, потом будет сложно понять, что именно в нем лежит.

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

 

Связь классификатора с маршрутами

Маршруты — одна из главных причин не делать классификатор случайным.

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

Простой пример:

• договоры до определенной суммы согласуются по короткому маршруту;
• договоры выше суммы идут через финансового директора;
• договоры с нерезидентами дополнительно смотрит валютный контроль;
• договоры по отдельным проектам согласует руководитель проекта;
• договоры с особыми условиями обязательно проверяют юристы.

Это не значит, что под каждый вариант нужен отдельный вид документа. Часто достаточно одного вида “Договор” и реквизитов, которые влияют на маршрут.

Но если документы проходят принципиально разные процессы, их лучше разделить. Например, входящее письмо и служебная записка могут оба быть “внутренними документами” в широком смысле, но в системе они живут по разным правилам.

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

 

Связь классификатора с правами доступа

Классификатор влияет и на права доступа. Это особенно заметно в 1С:Документообороте, где документы часто связаны с рабочими группами, грифами, подразделениями и процессами.

Например:

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

Если классификатор слишком общий, права приходится настраивать сложнее. Если слишком детальный — администрирование прав тоже становится тяжелее.

Поэтому при создании вида документа лучше сразу уточнить:

• кто создает документ;
• кто видит документ;
• кто может менять карточку;
• кто может видеть вложенные файлы;
• кто может менять маршрут;
• кто отвечает за закрытые документы;
• нужен ли особый гриф доступа.

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

 

Связь классификатора с шаблонами и печатными формами

Еще один слой — шаблоны документов и печатные формы.

Если у вида документа свой шаблон, это аргумент в пользу отдельного вида. Но не всегда решающий.

Например, у договоров могут быть разные шаблоны:

• договор поставки;
• договор оказания услуг;
• договор аренды;
• договор подряда;
• дополнительное соглашение;
• протокол разногласий.

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

Здесь не стоит принимать решение только по шаблону. Сначала нужно посмотреть, что меняется вокруг него.

 

Связь классификатора с отчетами и поиском

Отчеты быстро показывают, насколько аккуратно сделан классификатор.

Пользователи часто хотят видеть:

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

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

Я встречала такие ситуации: пользователь уверен, что договоров за месяц было двадцать, отчет показывает пятнадцать. Начинаешь смотреть — пять документов создали как “Прочий договор” или “Документ организации”. Для пользователя это все договоры. Для системы — разные виды документов.

Поэтому при проектировании классификатора полезно заранее спросить, какие отчеты нужны руководителям, канцелярии, юристам, финансам и проектным командам.

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

 

Что проверить перед настройкой классификатора

Перед тем как заводить виды документов, стоит провести небольшое обследование. Не большое исследование на месяц, а короткую проверку основных вещей.

 

Что проверить	Какие вопросы задать
Процессы	Какие документы участвуют в процессах, кто их создает и кто согласует
Роли	Какие подразделения и сотрудники работают с документами
Маршруты	Какие документы идут по разным маршрутам
Данные	Какие реквизиты обязательны и откуда они берутся
Права	Кто должен видеть документы и файлы
Шаблоны	Какие файлы, печатные формы и шаблоны используются
Отчеты	Какие выборки и показатели нужны пользователям и руководителям
Поиск	Как пользователи будут искать документы
Исключения	Какие документы идут не по обычному сценарию
Сопровождение	Кто будет поддерживать классификатор после запуска

 

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

 

Если классификатор уже есть и в нем накопился мусор

Отдельная история — база, которая уже работает. Классификатор в ней мог складываться годами. Его могли править разные администраторы, аналитики, консультанты и пользователи. В такой ситуации не стоит начинать с массового переименования и удаления.

Сначала нужно посмотреть, что реально используется.

Я бы проверила:

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

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

Поэтому порядок лучше наводить аккуратно.

 

Группа видов	Что делать
Актуальные и понятные	Оставить без изменений
Актуальные, но плохо названные	Переименовать после согласования и обновить инструкции
Дублирующие друг друга	Выбрать основной вариант, остальные постепенно выводить из использования
Редкие, но важные	Оставить, но описать правила использования
Неиспользуемые	Скрыть, пометить как неактуальные или запретить выбор по правилам проекта
Спорные	Передать владельцам процессов на решение

 

Если изменения большие, лучше делать их поэтапно. Сначала договорные документы, потом входящие и исходящие, потом внутренние документы. И после каждого этапа проверять маршруты, отчеты, права и инструкции.

 

 

Как не сломать работу пользователей при изменении классификатора

Классификатор лучше не править резкими движениями. Даже простое переименование вида документа может вызвать вопросы, если пользователи привыкли к старому названию.

Перед изменениями стоит подготовить небольшой план:

• какие виды меняются;
• почему они меняются;
• какие документы уже созданы по этим видам;
• затрагиваются ли маршруты;
• затрагиваются ли права доступа;
• затрагиваются ли отчеты;
• нужно ли обновить инструкции;
• кого нужно предупредить;
• как проверить результат после изменений.

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

Здесь важно помнить: классификатор видят пользователи. Если его поменять молча, поддержка получит заявки в стиле “раньше было, теперь пропало”. Поэтому даже небольшие изменения лучше сопровождать коротким объяснением.

 

Кто должен отвечать за классификатор

Классификатор документов не должен жить только в зоне ответственности администратора 1С. Администратор может настроить систему, но он не всегда должен решать, какие виды документов нужны бизнесу.

На мой взгляд, нормальная модель ответственности такая:

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

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

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

• как называется документ;
• зачем нужен отдельный вид;
• кто будет его использовать;
• какой процесс он поддерживает;
• какие реквизиты обязательны;
• какой маршрут нужен;
• какие права доступа нужны;
• нужны ли шаблоны или печатные формы;
• нужен ли отчет по этому виду;
• есть ли похожий вид документа уже в системе.

Если на эти вопросы нет ответов, я бы не создавала новый вид сразу. Сначала нужно уточнить процесс.

 

Практический чек-лист для классификатора

Ниже чек-лист, которым можно пользоваться при проектировании или ревизии классификатора.

• Каждый вид документа имеет рабочий смысл.
• Нет видов, созданных только “на всякий случай”.
• Пользователь понимает название вида без отдельной инструкции.
• Похожие виды не дублируют друг друга.
• Группы документов названы нормальным рабочим языком.
• Для важных видов известен владелец процесса.
• Понятно, какие маршруты завязаны на виды документов.
• Понятно, какие права доступа зависят от вида документа.
• Понятно, какие шаблоны и печатные формы используются.
• Понятно, какие отчеты зависят от классификатора.
• Есть правила добавления новых видов документов.
• Есть порядок вывода неактуальных видов из использования.
• Инструкции для пользователей соответствуют актуальному классификатору.

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

 

Мини-шаблон описания вида документа

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

 

Поле	Что указать
Название вида документа	Понятное рабочее название
Группа	Раздел классификатора, где находится документ
Назначение	Для чего используется документ
Владелец процесса	Кто отвечает за правила работы с этим документом
Кто создает	Роль или подразделение, которое создает документ
Кто согласует	Основные участники маршрута
Обязательные реквизиты	Какие данные должны быть заполнены
Права доступа	Кто видит, изменяет и согласует документ
Шаблоны	Какие шаблоны файлов или печатные формы используются
Отчеты	Где используется этот вид документа
Исключения	Нестандартные случаи и особенности

 

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

 

Итог

Классификатор документов в 1С:Документообороте — это не просто дерево видов документов. От него зависит, как документ пойдет по маршруту, кто его увидит, какой шаблон применится, попадет ли он в отчет и насколько легко его потом будет сопровождать.

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

Если он влияет на маршрут, права, реквизиты, шаблон, отчетность или владельца процесса — отдельный вид может быть оправдан. Если не влияет ни на что, скорее всего, это не отдельный вид, а реквизит, категория или признак.

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

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

Хороший классификатор не заставляет пользователя думать о внутренней логике 1С:Документооборота. Он помогает выбрать правильный вид документа и спокойно запустить нужный процесс.

Если держать этот принцип, классификатор становится не источником путаницы, а нормальной опорой для маршрутов, прав, отчетов и сопровождения.