Как мы автоматизировали управление закупками в «1С:Документооборот»

Стратегия автоматизации

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

Если с первыми тремя задачами успешно справляется «1С:Документооборот», то с автоматизацией процесса закупок могут возникнуть трудности. Этот процесс включает в себя два направления деятельности: непосредственно управление закупками (от сбора потребностей и организации закупок до подтверждения факта исполнения договоров) и управление механизмом согласования документов, формируемых на каждом этапе управления закупками. С первой задачей проблем обычно не возникает (1С предлагает встроенные механизмы управления закупками в системах «1С:Управление холдингом» и «1С:ERP»), а вот готовых способов решения второй задачи в них нет.

Чтобы удовлетворить все требования клиента, мы должны были выбрать один из трех подходов:

1. Расширить и усилить механизмы управления бизнес-процессами в типовых учетных конфигурациях («1С:Управление холдингом» или «1С:ERP Управление предприятием»).
2. Использовать бесшовную интеграцию учетных систем с «1С:Документооборот».
3. Доработать «1С:Документооборот» для работы с документами закупок.

Мы провели анализ и посчитали, что первый подход может оказаться тупиковым, так как с помощью доработок механизмов «1С:Управление холдингом» или «1С:ERP» трудно достичь той гибкости управления процессами, которую дает система документооборота. Если механизмы согласования документов настолько сложные, что для управления ими не хватает инструментов учетных систем, то заниматься их модификацией не стоит.

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

Как мы решили поставленную задачу

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

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

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

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

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

Для каждого документа, необходимого в организации процесса закупки, создается свой объект метаданных в конфигурации «1С:Документооборот». Предпочтительно, чтобы это был документ, со своими реквизитами и формами. Далее для этого объекта метаданных необходимо установить соответствие с определенным видом внутреннего документа. Хотя зафиксировать эту связь можно разными способами, оптимальным является создание регистра сведений.

При первом запуске обработки документа управления закупками автоматически создается элемент справочника Внутренние документы с реквизитом Вид документа, равным соответствию, определенному ранее (далее — Аватар). При этом информация о связях между ними сохраняется. Ее нужно хранить в отдельном регистре сведений, где основной документ — это измерение, а внутренний документ — ресурс. Предметом же бизнес-процесса должен быть именно Аватар.

Такой подход помогает создать фактически независимый блок управления закупками на базе «1С:Документооборот». Единственным вмешательством в типовое решение является механизм подмены отображаемой формы при открытии внутреннего документа с видом, связанным с одним из документов управления закупками, и запрет на ручное создание внутренних документов с этими типами. Другими словами, типовая конфигурация осталась почти нетронутой, а все изменения были выполнены в объектах метаданных. В будущем такой подход облегчит заказчику обслуживание внедренной ИТ-системы.