Строительная компания регулярно отправляет сотрудников на объекты по всей России. Заявку создавали в одном месте, бронирование — в другом, авансовый отчёт — в третьем. Между документами не было связи: каждый существовал сам по себе. Руководитель не мог открыть одну форму и увидеть, где по командировке всё закрыто, а где «висят» незакрытые документы. Мы выстроили в 1С:ERP сквозную цепочку — от заявки до авансового отчёта — со встроенным согласованием и сводным отчётом.
О клиенте
Крупная строительная компания, работающая на государственных объектах. Несколько тысяч сотрудников, около 200 пользователей 1С. Одновременно в работе — порядка 30 проектов. Сотрудники регулярно выезжают на объекты в разных регионах.
Этот кейс — часть большого проекта по внедрению 1С:ERP (подробнее — в обзорной статье). Здесь разберём блок, связанный с документооборотом по командировкам.
Исходная ситуация
Типовой функционал 1С:ERP покрывал командировочные документы по отдельности: заявку, бронирование билетов, авансовый отчёт. Но каждый документ существовал сам по себе — создавался независимо, заполнялся вручную, не ссылался на предыдущий.
На практике это выглядело так. Сотрудник создавал заявку на командировку в ERP. Согласование шло устно или по почте — фиксированного процесса не было. Забронировать отель на основании заявки система не позволяла — только билеты. Когда нужно было оформить авансовый отчёт, сотрудник открывал его и заново вводил те же данные, что уже были в заявке. А чтобы понять, полностью ли закрыта командировка, руководитель открывал несколько документов по отдельности и сверял их вручную.
При десятках командировок в месяц это означало постоянные «хвосты» — незакрытые бронирования, забытые авансовые отчёты, отсутствие общей картины.
Задача
Выстроить процесс так, чтобы каждый командировочный документ создавался на основании предыдущего, данные не вводились дважды, согласование шло внутри ERP, а руководитель видел состояние всех командировок в одном отчёте.
Как решали
Цепочка документов
Первое, что мы определили, — в каком порядке документы должны следовать друг за другом. Заказчик чётко сформулировал: «Приобретение услуг» закрывает бронирование — это последний документ в связке «Бронирование → Приобретение», а не наоборот. Получилась цепочка из пяти звеньев.
Заявка на командировку — входная точка. Сотрудник заполняет даты, маршрут, указывает, нужно ли бронирование отеля и билетов, вносит предполагаемые расходы в табличную часть. Сумму расходов система рассчитывает автоматически — раньше поле приходилось заполнять вручную.
Бронирование — следующее звено. В типовом ERP на основании заявки можно было создать только бронирование билетов. Бронирование отеля — нельзя. Мы доработали механизм: теперь из заявки создаётся бронирование любого типа — отель, трансфер, прочее. Организация, подразделение и сотрудник подтягиваются из заявки автоматически.
Отдельно решили задачу с подстановкой договора. Когда пользователь указывает контрагента в документе бронирования, система ищет подходящий договор по набору условий: действующий, с целью «Закупка», с подходящей валютой и порядком расчётов. Если договор единственный — подставляется сам.
Приобретение услуг — закрывающий документ по бронированию. Создаётся на основании бронирования.
Интересно, что изначально мы спроектировали цепочку в обратном направлении: приобретение → бронирование. Первый же раунд тестирования показал, что логика должна быть другой. Три задачи и несколько итераций ушли на то, чтобы выстроить правильную последовательность и добавить удобные кнопки «Создать на основании» прямо в формах документов.
Авансовый отчёт — финальный документ. Мы добавили кнопку «Выбрать Заявку на командировку» — при выборе реквизиты авансового отчёта заполняются из заявки. Здесь обнаружился нюанс: когда сотрудник привязывал заявку к уже заполненному авансовому отчёту, система затирала введённые расходы. Мы разделили логику: при создании нового АО — заполнять с нуля, при привязке заявки к существующему — сохранять текущие строки.
Все документы цепочки связаны через типовой механизм «Связанные документы». Открывая заявку, руководитель видит в панели всё: бронирование, приобретение услуг, авансовый отчёт, платёжные документы.
Согласование
У компании уже работал собственный механизм согласований, который мы разработали ранее для заявок на закупку и заказов поставщику (подробнее — в кейсе о системе согласований). Вместо того чтобы отправлять людей в отдельную систему, мы подключили заявку на командировку к этому же механизму.
При отправке на согласование система сама подставляет участников — на основании настроек по проекту и функциональной роли. Если в заявке указано, что нужно бронирование, после согласования запускается дополнительный этап — задача направляется ответственному за бронирование. Если бронирование не нужно — процесс завершается после согласования.
Статусы заявки устанавливаются автоматически: «Подготовлена» при записи, «Рассматривается» при старте согласования, «Согласована» или «Отклонена» по итогам. Позже по запросу заказчика добавили статус «Продлена» — для случаев, когда командировка продлевается.
Блокировка и контроль
Когда заявка находится в статусе «Рассматривается» или «Согласована», её основные реквизиты блокируются для редактирования. Изменить может только пользователь с соответствующей ролью. Согласованный документ не будет изменён задним числом.
Печатная форма
Разработали печатную форму «Заявление на командировку». В подвале — блок согласования: все участники, которым отправлялась заявка, с указанием статуса (согласовано, не согласовано, ожидает решения). Первая версия выводила только тех, кто уже согласовал. По обратной связи от заказчика доработали — теперь видны все участники процесса.
Сводный отчёт
Это инструмент для руководителя. Отчёт собирает в одну таблицу данные по каждой командировке: заявка, бронирование (отель и билеты), закрывающие документы, суммы расходов, выданные под отчёт средства, авансовый отчёт, отчёт о результатах. Руководитель открывает его — и сразу видит, где по командировке всё закрыто, а где остались незакрытые документы.
Отдельной сложностью стала колонка «Выдано под отчёт». Первая реализация связи платёжных документов с заявкой оказалась ненадёжной — пришлось переработать логику получения данных, чтобы отчёт корректно находил Списание БДС и Расходный кассовый ордер.
В процессе доработки добавили ещё одно звено: Приходный кассовый ордер с операцией «Возврат от подотчётника» — создаётся на основании заявки на командировку или авансового отчёта.
Что получилось
Сквозная цепочка документов. Каждый командировочный документ создаётся на основании предыдущего. Данные не вводятся дважды. Все документы видны в панели «Связанные документы» из любой точки цепочки.
Согласование внутри ERP. Заявки на командировку проходят согласование через тот же механизм, что и заявки на закупку. Статусы устанавливаются автоматически. Если нужно бронирование — задача направляется ответственному.
Контроль исполнения. Руководитель открывает сводный отчёт и видит по каждой командировке: согласована ли заявка, забронирован ли отель, оплачены ли билеты, сдан ли авансовый отчёт.
Печатная форма. Заявление на командировку формируется одной кнопкой, с полным блоком согласования.
Защита от изменений. Согласованная заявка заблокирована для редактирования. Каждое решение зафиксировано в протоколе.
Стоимость и сроки
Блок командировочного документооборота — часть большого проекта по внедрению 1С:ERP. Работа заняла около трёх месяцев. Стоимость подобного проекта — от 740 000 рублей. Общая стоимость проекта внедрения, сроки и состав работ — в обзорной статье.
Если у вас похожая ситуация — напишите, разберёмся, с чего начать.