Комплектность пакета документов в 1С:Документообороте 3.0: приложения, версии файлов и обязательные вложения
В 1С:Документообороте 3.0 КОРП документ редко существует отдельно от других материалов. Обычно рядом с основным файлом есть приложения, сканы, спецификации, счета, протоколы, дополнительные соглашения, расчеты, служебные вложения и другие файлы.
На этапе согласования это может выглядеть просто: пользователь создал карточку документа, приложил файл и запустил маршрут. Но дальше выясняется, что к договору не приложили спецификацию (которая, как правило, содержит важные условия), к заявке на оплату нет счета, к служебной записке не приложили расчет, а у приказа есть новая версия файла, но часть согласующих смотрела предыдущую.
В таких ситуациях проблема не только в невнимательности пользователя. Чаще не описаны правила комплектности: какие вложения обязательны, кто проверяет пакет, когда это делается, как учитываются версии файлов и что считается актуальным комплектом документа.
На обследовании этот вопрос лучше проверять на конкретном документе: договоре, заявке на оплату, служебной записке или приказе. Так быстрее становится понятно, какие файлы нужны для принятия решения, какие нужны только для справки, а какие появляются уже после согласования.
Эта статья о том, как подойти к контролю комплектности пакета документов именно в 1С:Документооборот 3.0 КОРП. Разберем приложения, версии файлов, обязательные вложения, ответственность участников и типовые ошибки процесса.
Что считать комплектом документов
Комплект документов — это не только основной файл, который отправляется на согласование. Это набор материалов, без которых участник маршрута не может принять корректное решение.
Например, для договора основного текста, как правило, недостаточно. Юристу нужен сам договор и приложения. Финансовому контролеру нужны сумма, график оплаты, спецификация или расчет. Руководителю может быть нужен итоговый вариант договора и краткое пояснение по условиям. Бухгалтерии после согласования может понадобиться счет, акт или скан подписанного экземпляра.
В состав комплекта могут входить:
- основной файл документа;
- приложения к документу;
- спецификации;
- счета и коммерческие предложения;
- расчеты и обоснования;
- сканы подписанных документов;
- электронные оригиналы;
- протоколы разногласий;
- дополнительные соглашения;
- служебные вложения для внутренней проверки.
Главный вопрос для процесса: какие из этих вложений обязательны, а какие являются дополнительными.
Почему недостаточно просто прикрепить файл
Если в процессе нет контроля комплектности, пользователи действуют по-разному. Один инициатор прикладывает все приложения сразу. Другой загружает только основной файл, а приложения прикладывает к ответу на вопрос в ходе согласования. Третий отправляет счет отдельным письмом. Четвертый добавляет новую версию уже после начала согласования и не сообщает об этом участникам.
В 1С:ДО карточка документа помогает хранить файлы, видеть версии и историю работы с документом. Но система не заменяет правила процесса. Заранее стоит договориться, какие вложения должны быть в карточке до запуска маршрута, какие можно добавить позже, кто отвечает за проверку и уже после этого фиксировать итоговые требования и в последующем выполнять необходимые настройки.
Если изначально не был оговорен процесс создания документа и загрузки файлов (и, соответственно, не был настроен), то впоследствии это будет особенно заметно после запуска задач согласования. Файл вроде бы приложен, но согласующий не всегда понимает, является ли он основным документом, приложением, старой редакцией или справочным материалом.
Комплектность — это не количество файлов в карточке. Это наличие нужных материалов для принятия решения.
Этап 1. Определить виды документов и обязательные вложения
Контроль комплектности лучше начинать не с настройки, а с перечня видов документов. Для каждого вида документа стоит зафиксировать, какие вложения обязательны.
Пример (я люблю на совещаниях с заказчиком давать сразу конкретные примеры видов файлов, тогда беседа идет легче):
| Вид документа | Обязательные вложения | Дополнительные вложения |
| Договор | Основной файл договора, приложения, спецификация при наличии | Протокол разногласий, переписка, расчет цены |
| Заявка на оплату | Счет, основание оплаты, договор или ссылка на договор | Пояснение инициатора, расчет, подтверждающие документы |
| Служебная записка | Основной текст, расчет или обоснование при необходимости | Скриншоты, письма, дополнительные материалы |
| Приказ | Текст приказа, согласованные приложения | Проект, лист замечаний, служебные материалы |
| Дополнительное соглашение | Файл соглашения, основание изменения, исходный договор | Сравнение редакций, переписка с контрагентом |
Такую таблицу лучше согласовывать, в первую очередь, с владельцем процесса, а также с пользователями, которые реально готовят документы. Иначе можно описать аккуратное правило, которое не совпадет с ежедневной работой инициаторов, юристов, бухгалтерии или делопроизводителей.
Этап 2. Разделить обязательные и информационные вложения
Не все файлы в карточке одинаково важны. Часть вложений нужна для принятия решения. Часть нужна только для справки.
Например, к договору могут быть приложены основной текст, спецификация, расчет стоимости, письмо от контрагента, старая редакция договора и внутренний комментарий инициатора.
Если не разделить эти файлы по смыслу, согласующий может не понять, какие из них нужно проверять. В результате важное приложение может остаться без внимания, а второстепенные материалы будут восприниматься как часть согласуемого пакета.
Для процесса полезно ввести простую классификацию:
- обязательное вложение — без него маршрут нельзя запускать или нельзя принимать решение;
- согласуемое вложение — файл является частью предмета согласования (например, печатная форма);
- информационное вложение — файл помогает разобраться, но не является частью согласуемого документа;
- техническое вложение — скан, копия, служебный файл, который нужен для хранения или проверки.
Даже если в системе не вводится отдельная сложная классификация, такую логику стоит описать в правилах работы пользователей.
Мини-кейс: договор согласовали без приложения
Договор был отправлен на согласование в 1С:ДО. Участники маршрута посмотрели основной файл, согласовали условия и завершили задачи. После этого бухгалтерия запросила спецификацию, потому что без нее нельзя корректно связать договор с дальнейшими документами.
Инициатор ответил, что спецификация была еще в работе и ее планировали добавить позже. Формально договор прошел согласование. Но согласующие принимали решение без части пакета.
В такой ситуации стоит разбирать не только конкретный документ, но и правило процесса. Если спецификация влияет на предмет, сумму или состав обязательств, она должна быть обязательным вложением до запуска маршрута или должна проходить отдельное подтверждение после добавления.
Этап 3. Определить контрольные точки
Комплектность можно проверять в разные моменты процесса. В описании процесса стоит отдельно зафиксировать, где проверка обязательна.
Обычно есть несколько контрольных точек:
- до запуска маршрута согласования;
- при возврате на доработку;
- перед финальным согласованием;
- перед подписанием;
- после получения подписанного экземпляра;
- перед передачей документа в учетную систему или архив.
Для разных документов контрольные точки могут отличаться. Например, для заявки на оплату важно проверить наличие счета и основания до запуска согласования. Для договора — приложения до согласования и подписанный экземпляр после подписания. Для приказа — актуальную версию файла перед финальным утверждением.
Если контрольная точка не определена, пользователи будут проверять комплектность по-разному: кто-то до согласования, кто-то после, кто-то только при возникновении ошибки.
Этап 4. Назначить ответственного за комплектность
Комплектность не должна быть общей ответственностью всех участников. Нужна конкретная роль, которая отвечает за проверку пакета.
Ответственным может быть инициатор документа, секретарь, делопроизводитель, юрист, финансовый контролер, владелец процесса, исполнитель по документу или архивариус. Выбор зависит от вида документа и этапа процесса.
Например, по договору первичную комплектность проверяет инициатор, юридические приложения — юрист, финансовые вложения — финансовый контролер (или любой другой сотрудник, выполняющий финансовую роль). По заявке на оплату обязательные вложения может проверять тоже финансовый контролер или бухгалтерия.
Важно не только назначить ответственного, но и описать его действие: он проверяет наличие файлов, актуальность версии, правильность типа вложения, соответствие названия файла или состав приложений.
Этап 5. Работать с версиями файлов
Версии файлов — отдельный риск в процессе согласования. Пользователь может загрузить новую версию после начала маршрута, после замечаний или после согласования. При этом не всегда понятно, какую версию смотрели участники и какая версия считается актуальной.
На практике лучше заранее договориться:
- можно ли загружать новую версию после запуска согласования;
- кто имеет право заменить основной файл;
- нужно ли описание изменений при новой версии;
- кто проверяет, что изменилось;
- нужно ли повторное согласование после замены файла;
- как определить актуальную версию для подписания или передачи в учет.
Новая версия файла сама по себе не означает, что нужно запускать весь маршрут заново. Но она должна быть понятна участникам процесса. Если файл изменился, должно быть видно, что именно изменилось и кто подтвердил актуальность новой версии.
На пилоте такие сценарии лучше проверять отдельно, потому что обычный путь “создали карточку — запустили согласование — завершили задачи” не показывает проблем с версиями и обязательными вложениями.
Мини-кейс: согласовали одну версию, подписали другую
Документ прошел согласование. После этого инициатор загрузил новую версию файла, потому что контрагент попросил изменить формулировку. Файл отправили на подписание, но часть согласующих новую версию уже не смотрела.
Позже возник вопрос: какая версия была согласована и почему на подписание ушла другая редакция.
Такая ситуация возникает, когда в процессе не описано правило работы с версиями после согласования. Если меняется только техническая ошибка, может быть достаточно локального подтверждения. Если меняется содержание документа, требуется повторное согласование или подтверждение затронутых ролей.
Для контроля комплектности важно фиксировать не только наличие файла, но и его актуальную версию.
Этап 6. Описать правила для обязательных вложений
Обязательные вложения должны быть описаны просто и понятно. Пользователь должен понимать, что именно нужно приложить до запуска маршрута.
Пример правил:
- договор не отправляется на согласование без основного файла и приложений, если приложения указаны в тексте договора;
- заявка на оплату не отправляется без счета или другого основания оплаты;
- дополнительное соглашение не отправляется без исходного договора или ссылки на него;
- служебная записка с финансовым эффектом должна содержать расчет или обоснование;
- после подписания должен быть приложен подписанный экземпляр или электронный оригинал;
- новая версия файла после согласования должна сопровождаться описанием изменений.
Такие правила лучше включить в инструкцию пользователя, описание процесса или требования к настройке маршрута.
Этап 7. Определить, что делать при неполном пакете
Недостаточно перечислить обязательные вложения. Нужно также описать действия при неполном пакете.
Возможные варианты:
- не запускать маршрут до добавления обязательных файлов;
- вернуть документ инициатору на доработку;
- отправить поручение на добавление вложения;
- разрешить запуск маршрута, но отметить отсутствующее вложение как риск;
- разрешить согласование только части пакета;
- запросить локальное подтверждение ответственной роли.
Для большинства процессов лучше не запускать маршрут, если отсутствуют обязательные вложения. Иначе согласующие будут принимать решение по неполному комплекту.
Но могут быть исключения. Например, подписанный экземпляр появляется только после завершения согласования и подписания. В таком случае он не может быть обязательным до запуска маршрута, но должен быть обязательным на следующем этапе — перед архивированием или завершением процесса.
Матрица контроля комплектности
Для настройки и обучения удобно использовать матрицу. В ней видно, какие вложения нужны на каком этапе и кто за них отвечает.
| Документ | Этап | Обязательное вложение | Ответственный | Что делать, если отсутствует |
| Договор | До согласования | Основной файл, приложения | Инициатор, юрист | Вернуть на доработку |
| Договор | Перед подписанием | Актуальная согласованная версия | Ответственный за документ | Проверить версию и подтверждение |
| Договор | После подписания | Подписанный экземпляр | Инициатор или делопроизводитель | Поставить задачу на добавление |
| Заявка на оплату | До согласования | Счет, основание оплаты | Инициатор | Не запускать маршрут или вернуть на доработку |
| Служебная записка | До согласования | Обоснование или расчет при необходимости | Инициатор | Запросить вложение |
Такую матрицу удобно использовать на обсуждении с пользователями до настройки маршрутов. На ней быстро видно спорные места: где приложение обязательно, где файл нужен только для справки, а где документ можно согласовать без части вложений, потому что они появятся позже.
Роль маршрута согласования
Маршрут согласования должен учитывать не только участников, но и состояние пакета документов.
В описании маршрута стоит отдельно ответить на несколько вопросов:
- проверяется ли комплектность до старта маршрута;
- кто может вернуть документ на доработку из-за отсутствующих вложений;
- можно ли добавлять обязательные вложения в ходе маршрута (это в том числе и вопрос прав);
- нужно ли повторное согласование после изменения вложений.
Если маршрут не учитывает комплектность, он может быть выполнен формально: задачи завершены, но пакет документов неполный или содержит неактуальные версии файлов.
Роль прав доступа
Контроль комплектности связан с правами доступа. Здесь важно определить не только участников маршрута, но и тех, кто может добавлять, заменять и удалять файлы в карточке документа и в каком состоянии.
На тестовой эксплуатации стоит проверить, кто может прикрепить основной файл, добавить приложение, заменить версию, удалить вложение, видеть служебные файлы и подтвердить комплектность.
Если права слишком широкие, пользователи могут менять комплект после согласования без понятного контроля. Если права слишком узкие, любая замена файла будет проходить через администратора или ответственного специалиста.
Как обозначать актуальный файл
В карточке документа может быть несколько файлов и несколько версий. Поэтому пользователям нужно понимать, какой файл является основным и какая версия актуальна.
В правилах работы стоит зафиксировать:
- как называется основной файл;
- как называются приложения;
- нужно ли указывать номер версии в названии;
- где фиксируется описание изменений;
- можно ли хранить старые редакции в той же карточке;
- кто подтверждает актуальную версию перед подписанием.
Отдельно стоит договориться о названиях файлов. Если в карточке лежат файлы “договор новый”, “договор новый финал”, “договор финал 2”, “договор на подпись”, пользователям сложно понять, какой файл нужно проверять.
В идеальном варианте процесс лучше все же организовывать таким образом, чтобы пользователь не добавлял новую версию файла в карточку документа, а менял уже существующий - тогда намного проще работать с историей изменений и у согласующих тратится меньше времени на то, чтобы разобраться, что к чему.
Мини-кейс: в карточке пять файлов с похожими названиями
В карточке договора находятся несколько файлов: “договор”, “договор новый”, “договор финал”, “договор финал исправленный”, “договор на подпись”. Участник маршрута открывает один из них и оставляет замечание. Другой участник открывает другой файл и согласует.
Формально все файлы приложены. Но комплектность не контролируется, потому что непонятно, какой файл основной и какая версия актуальна.
В таком случае нужно не только переименовать файлы. Нужно определить правило: один основной файл, понятное хранение версий, описание изменений и ответственность за актуальность пакета.
Что включить в инструкцию пользователям
Пользовательская инструкция по комплектности должна быть короткой. В ней не нужно описывать всю методологию, но нужно указать обязательные действия.
Например:
- перед запуском маршрута проверьте основной файл и обязательные приложения;
- если в тексте документа есть приложение, оно должно быть вложено в карточку;
- для заявки на оплату приложите счет и основание оплаты;
- при загрузке новой версии укажите, что изменилось;
- не удаляйте старую версию без необходимости;
- перед подписанием проверьте, что используется актуальная согласованная версия;
- после подписания приложите подписанный экземпляр или электронный оригинал.
Такие правила удобнее воспринимаются пользователями, чем длинное описание процесса.
Что проверить на пилоте
При запуске процесса в 1С:Документообороте 3.0 КОРП сценарии комплектности нужно проверять отдельно. Недостаточно проверить только создание карточки и выполнение маршрута.
На реальном внедрении этот блок удобно проверять прямо на тестовой карточке документа: загрузить основной файл, приложение, новую версию, вернуть документ на доработку и посмотреть, что увидит каждый участник маршрута.
На пилоте стоит проверить:
- можно ли запустить маршрут без обязательного файла;
- что происходит, если нет приложения к договору;
- как добавляется новая версия файла;
- видно ли описание изменений;
- как участник понимает, какую версию согласует;
- что происходит при возврате на доработку;
- как прикладывается подписанный экземпляр;
- кто видит обязательные и служебные вложения;
- как фиксируется факт проверки комплектности;
- как документ передается дальше после согласования.
Если эти сценарии не проверить, проблемы обычно появляются уже после запуска, когда пользователи начинают работать с реальными документами.
Что стоит зафиксировать в описании процесса
Перед настройкой или изменением процесса полезно подготовить краткое описание правил комплектности.
В нем стоит указать:
- виды документов, для которых контролируется комплектность;
- обязательные вложения по каждому виду документа;
- информационные и служебные вложения;
- контрольные точки проверки;
- ответственного за комплектность;
- правила работы с версиями файлов;
- правила именования файлов;
- действия при неполном пакете;
- права на добавление, замену и удаление вложений;
- сценарии для пилотной проверки.
Такое описание помогает аналитику, консультанту, администратору и пользователям одинаково понимать, что считается полным пакетом документов.
Вступайте в нашу телеграмм-группу Инфостарт