1с документооборот согласующее лицо не указан. Автоматизация бизнес-процессов. Мониторинг бизнес-процессов и их оптимизация с помощью «1С:Документооборота»

В связи с выходом/обновлением данных продуктов, а также развитием технологии web сервисов, специалистами компании 1С была реализована бесшовная интеграция, 1С ERP и 1С Документооборот (далее по тексту «ДО»).

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

Для реализации данного взаимодействия между двумя программами нам понадобится:

• 1C «ДО» 2.0 (Версии КОРП)

  Web Server Apache.

Установку и настройку данных программных продуктов описывать нет необходимости, перейдем непосредственно к настройке.

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

Для реализации подобной схемы заведем пользователей в 1С ERP и 1С ДО.

- Безопасность

- Юрист

- Экономист

- Делопроизводитель

Теперь перейдем к настройке

Зайдем в 1С ДО в режиме «Конфигуратор» и опубликуем нашу базу на web сервере.

Имя - адрес ресурса, т.е. http://localhost/DocCorp/

Каталог - Место расположения web сервиса.

Проверяем работу.

Теперь сделаем настройки в 1С ДО.

1) Создадим новый вид документа: «Договор продажи»

Переходим в «НСИ и Администрирование» - «Виды документов»

Создадим группу документов «Договора»

Создаем новый вид

Перейдем во вкладку «Шаблоны документов» - «Реквизиты документа».

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

Переходим в «Шаблоны процессов», создаем новый шаблон.

Откроется форма выбора шаблона «Согласование», создадим папку «Нетиповые процессы», затем создадим процесс «Согласование договора продажи»

Запишем процесс.

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

Вернемся во вкладку «Настройки процесса», добавим согласующих.

Затем изменим направление маршрутизации, и выставим порядок согласования:

Теперь настроим уловную адресацию, нажимаем кнопку «Использовать условия» *(Только в версии КОРП) .

Создадим новое условие маршрутизации: Сумма договора > 100 000р.

Назначим его «Виду документа» - «Договора продажи».

Настройка 1С «ДО» закончена. Переходим к настройке 1С: ERP.

Добавим пользователей, таких же, как в 1С «ДО»

В поле URL вводим web адрес сервиса, устанавливаем необходимые галки и переходим к настройке интеграции.

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

Это будет «договор с контрагентом», объект из 1С «ДО» - «Внутренний документ»

После выбора взаимосвязей будет выполнена базовая настройка связанных объектов.

Необходимо настроить рад полей.

Вид документа в 1 «ДО» - «Договор продажи»

Когда осуществляется ввод вида документа, 1С ERP ищет его в 1С «ДО».

«Папка» - «Договора продажи» (место хранения документов)

«Регистрационный номер»

Система по умолчанию говорит, что это «Код», это неверно, изменим значение.

У нас это номер договора.

Настроим оставшиеся поля

На этом все - Сохраним настройку.

Создадим договор продажи в 1С ERP, будем создавать его под пользователем «Делопроизводитель»

Теперь создадим на основании этого договора процесс 1С «ДО». Нажимаем в форме списка «Еще»

В 1С «ДО» при этом создается внутренний документ «Договор продажи»

«Наименование» которого соответствует данным из 1С ERP. Система сразу нам предлагает выбрать шаблон процесса. Выбираем «Согласование договора продажи», и нажимаем «Создать процесс». Галку «Запуска сразу» пока устанавливать не будем.

Сумма нашего договора > 100 000р, следовательно, сработало наше правило маршрутизации, добавился «Экономист».

Стартуем процесс.

Теперь в 1С ERP зайдем под разными пользователями и посмотрим результат. При первом входе пользователя в 1C ERP, если настроена интеграция с 1С «ДО», пользователю будет предложено ввести логин и пароль для подключения к «ДО».

Потом зайдем «Экономистом»

У него задач нет, т.к. его согласование идет после «Юриста», согласуем договор «Юристом», и обновим задачи «Экономиста»

Наш договор перешел в статус «Действует».

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

Но есть возможность развернуть взаимосвязь. «Делопроизводитель» создает в 1С «ДО» внутренний документ «Договор продажи», документ проходит стадии согласования, затем, когда становится согласованным, «Делопроизводитель» вносит уже утвержденные данные в 1С ERP и настраивает взаимосвязь между объектом в 1С ERP и 1С «ДО».

В 1С «ДО» создадим внутренний документ «Договор продажи»

Регистрируем договор и отправляем по созданному нами шаблону согласования.

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

Сумму договора я установил 1500р., следовательно, согласований «Экономисту» делать не нужно.

Перейдем в 1С ERP.

Как видно, даже не создавая документ в 1С ERP при бесшовной интеграции, все процессы пользователя в 1С «ДО», отображаются в 1С ERP.

После того как все процедуры согласования были пройдены, и договор согласован, нужно просто завести его в базу 1С ERP и настроить связь.

Вносим наш договор в 1С ERP и настраиваем связь с согласованным объектом из 1С «ДО»

Переходим в «Документооборот» данного документа и выбираем "внутрений документ" 1С ДО.

Поиск происходит по выбранным критериям на стороне 1С "ДО".

Вот теперь у нас настроена связь между двумя объектами.

При этом мы не создали лишних документов в 1С ERP, весь процесс согласования прошел на стороне ERP (средствами 1С «ДО»). И была получена связь 2х объектов с разных баз.

За сим все. Какие методики выбирать зависит от ваших потребностей, решайте сами.

PS. При интеграции с 1С ERP рекомендовал бы настроить планы обмена структурой предприятия, контрагентами, пользователями и статьями ДДС. Это позволит сократить вмешательство в систему 1С «ДО» и иметь актуальную информацию при договорном учете.

3 Оперативное планирование и факт. движение ДС.

3.1 Резервирование бюджетов

Как было сказано ранее, лимиты ДДС по бюджетам (Бизнес-планы ДДС) зачастую могут уточняться (например, сумма по статье может быть детализирована по контрагентам, по доп. аналитикам, например, мероприятиям и т.д).

Установка лимитов ДС в оперативном контуре будет выполняться документом «Резервирование бюджетов». Такие документы удобно ввести на основании Бизнес-планов ДДС. При этом, установка и контроль лимитов будет проводиться в разрезе предопределенного сценария – «резерв».

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

Для включения запрета проведения документов при превышении лимита, перейдем в раздел «Общие справочники и настройки/Настройка параметров/Казначейство».

Так же установим флаг «Запрещать непосредственное создание платежных поручений на основании заявок, минуя реестр платежей». Этот функционал понадобится, так как в нашей задаче будет в обязательном порядке задействован реестр платежей (реестр в обязательном порядке будет формироваться и утверждаться главным бухгалтером).

Итак, введем документы Резервирование бюджетов на период – Сентябрь 2017 г.

Обратим внимание на следующие моменты:

• 
  Для документа «Резервирование бюджета» маршрут согласования создавать не будем. Установим признак «Вне маршрута» и статус «Утвержден»

• 
  Организацию укажем «МСК УК (Управленческие функции)», при этом ЦФО – оставим то значение, которое было указано в бизнес-плане.

3.2 Маршруты согласование заявки на оплату поставщику

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

Каждый согласант будет «со своей стороны» проверять необходимость утверждения заявки. Например, ответственный за закупки - проверит корректность условий договора, казначей – убедится, что не возникнет кассовый разрыв (и при необходимости выполнить балансировку в платежном календаре), фин. директор выполнит окончательное утверждение заявки и т.д.

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

Перейдем в раздел «Процессы и согласования/Шаблоны процессов».

Создадим новый шаблон – «Процесс согласования заявок на оплату». В качестве назначения процесса укажем – «Маршрут согласования». Тип объекта согласования – «Заявка на операцию».

Создадим следующий маршрут согласования:

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

Для проверки того, как сработают условия маршрутизации в зависимости от параметров заявки, предусмотрена функционал «Отобразить» в проверке маршрута.

В качестве отдельного этапа (сетевой диаграммы процесса) может выступить этап «Оповещение».

Т.е при переходе на этот этап, система сможет сформировать для пользователя отдельное оповещение.

Соответственно, этап «Оповещение», можно включить в сетевую диаграмму процесса.

Для настройки содержания оповещения необходимо настроить шаблон оповещения:

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

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

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

Что бы включить формирование оповещений по событиям, следует перейти в раздел «Процессы и согласования/Настройки оповещений» и добавить такую запись:

И,наконец, после того как шаблон процесса согласования полностью настроен, необходимо указать этот шаблон в регламенте подготовки отчетности. В нашем примере, требуется в регламенте «Установка и контроль лимитов ДДС» настроить матрицу полномочий согласования экземпляров отчетов – указать в ней шаблон процесса согласования.

Для документа Заявка на операцию указать шаблон процесса «Процесс согласования заявок на оплату».

3.3 Согласование заявок по маршруте

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

Заполним документ Заявка на операцию с видом «БДДС (Расход) расчеты с контрагентами».

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

При попытке проведения документа получим сообщение о превышении лимита.

Исправим эту ситуацию, сформировав заявку корректно. Укажем источник лимитов (документ резервирования бюджета), укажем доступную сумму.

Заполним контрагента, договор; перейдем на закладку «Контроль лимитов».

Увидим – какой на данный момент остаток лимита (с учетом текущей операции) и какой лимит был запланирован.

Проведем документ и увидим, что документ получим статус «На утверждении»

По кнопке «Ход согласования» откроем маршрут и увидим этап, на котором в данным момент находится заявка.

Текущий этап – выделен голубым цветом.

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

Перейдем в раздел «Процессы и согласования/Мои задачи и оповещения».

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

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

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

В разделе «Планирование и контроль/Разрешение и запреты платежей» внесем (для примера) следующую запись.

При попытке отправить на согласование такую заявку – получаем следующее сообщение

Это означает, что хотя заявка и проходит по контролю лимитов, но не проходит по директиве контроля платежа.

Отключим ранее введенную директиву и отправим заявку на согласование.

По кнопке «Согласовать документ» перейдем к выполнению согласования текущего этапа.

Проставим визу (пояснение) и нажмем «Согласовать».

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

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

• 
  Отклонить заявку на предыдущий шаг согласования;
• 
  Передать заявку на согласования дополнительным согласующим (т.е по необходимости можно добавит согласантов в текущий маршрут и перенаправить заявку им).

3.4 Работа с платежным календарем.

Итак, в данный момент 2 заявки на оплату находятся на этапе «соглования» у казначея.

Основной задачей казначея является контроль возможности оплаты. Т.е, что бы например не возник кассовый разрыв (следует оценить какая сумма планируется на расчетных счетах в момент оплаты). Так же в этих 2-х заявках не определены и расчетные счета (с которых будет произведена оплата).

Итого, казначей должен сбалансировать платежную позицию (определить счет оплаты и проконтролировать дату оплаты на предмет кассового разрыва). И если выяснится, что д/с на планируемый момент не хватает, то тогда казначей должен либо сместить дату планируемой оплаты, либо учесть (дозаплнаровать) д/ c к поступлению, либо отложить заявку в связи с невозможностью ее оплаты (перенести в стоп-лист). Все эти функции, а так же функция разделения одной заявки на несколько (с целью разбить одну сумму на несколько) и функция перемещения д/с между счетами – все это будет рассмотрена при работе с платежным календарем далее.

Так же важно упомянуть еще об одной функциональной возможности работы с платежным календарем, а именно – возможность сохранения разных «вариантов развития событий».

Т.е казначей может смоделировать, например, ситуацию №1 «допланирования» ожидаемого поступления д/c от клиента и проанализировать и сохранить этот «сценарий» развития событий (такой вариант платежного календаря). Затем, смоделировать ситуацию №2, когда ожидаемого поступления д/с не случилось, а необходимо закрыть нехватку д/ c через перемещение д/ c с другого расчетного счета и частично сдвинуть даты оплаты. Итого, можно будет сравнить оба варианта развития событий и выбрать более выигрышный.

Функционал платежного календаря в УХ предоставляет богатые возможности для казначея, рассмотрим все это на примерах.

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

Настроить рад параметров работы платежного календаря:

• 
  Горизонты формирования календаря (кол-во дней);
• 
  Учитывать или нет (1 или 0, или например - 0.5 – тогда «на половину учитываем») документы заявок (в том числе не утвержденные, находящиеся в процессе согласования) при формировании платежного календаря.
  • 
    Т.е. если по неутвержденным заявкам везде установить «1», то все неутвержденные (но находящиеся в процессе утверждения) заявки будут в полной сумме учитываться программой при формировании платежного календаря.

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

Зарегистрировать текущие начальные остатки д/с:

Для расчета платежного календаря в программе необходимо зарегистрировать начальные остатки д/c . Требуется, что бы начальные остатки были зарегистрированы в регистре накопления «Денежные средства». При этом и фактическое движения (поступление/выбытие) д/ c так же должны отражаться по этому регистру.

Регистрация начальных остатков д/c осуществляется через оформление документа «Корректировка начальных остатков». При этом, это документ разумеется можно заполнить автоматически, по данным бух. учета ( m .е по текущему дт 51 счета).

Итак, зарегистрируем начальные остатки по 2 юр. лицам и их банковских счетам.

Фактические поступления/выбытия д/с будут отражены в программе через документы «Отражение фактических данных бюджетирования». Такие документы будут сформированы в программе автоматически, в момент отражения факт. бухгалтерских документов движения д/ c (поступления/списания д/ c по счету). Такое поведение системы определяется вот этими настройками:

Перейдем в раздел «Планирование и контроль/Платежный календарь».

Выполним установку следующих, ключевых параметров:

• Группировки установим: по организации и банковскому счету;
• Период установим: c текущей даты до даты конца текущего месяца;

Отбор по организации: установим по консолидирующей группе МСК Энергетика +

Сформируем платежный календарь (календарь будет сформирован с текущей даты и до даты окончания месяца).

Увидим, что в календарь попали начальные остатки по двум расчетным счетам, попали плановые движения по расходу д/c (оплата двух заявок на оплату, датой на завтра).

Красный цвет означаем то, что у нас образовался кассовый разрыв по счету «Банковский счет не определен». Это возникло потому, что счет оплаты в заявках не определен.

• Изменим счет выбранных заявок. Установим счет – ВТБ 24.

• 
  В результате получим, что «Банковский счет не определен» - исключен из календаря, однако на 05/09 присутствует кассовый разрыв на сумму 4000. Суть в том, что планируемые расход (34 тыс. руб. суммарно по 2 заявкам) превышает остаток д/c на счете.

• C помощью функционала «отложить/отложенные» можно отложить на время заявку (перенести ее в стоп-лист). Затем, вернуть ее из отложенных.

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

• Можно сдвигать дату оплаты заявок на указанную, на крайнюю дату

Еще закрывать кассовые разрывы можно, например, за счет внутригруппового перемещения д/c (со счета одной организации на счет другой организации). Для этих целей предусмотрена заявка на внутреннее перемещение.

Можно оперативно планировать как расход, так и ожидаемые поступления д/c . Это могут быть операции как поступления о клиентов, так и ожидаемый приход по прочим операций.

3.5 Формирование реестра платежей.

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

В нашем примере главный бухгалтер формируем и проводит реестр в статусе «Утвержден».

Платежные поручения формируются по кнопке «Сформировать платежные поручения».

3.6 Отражение факта, разнесение выписок по аналитикам бюджетирования.

После загрузки из клиент-банка по факту списания с расчетного счета в программу будут загружены документы «Списания с расчетного счета».

Обратим внимание на то, по факту списания с расчетного счета в программе автоматически будут сформированы документы «Отражение фактических данных».

Предназначение документов «Отражение факт данных» - отразить в регистрах бюджетирования и движения д/с факт расхода д/с. Факт расхода д/ c учитывается и в платежной календаре, для определения текущих остатков д/ c .

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

Такой алгоритм можно настроить в обработке «Разнесение банковской выписки по аналитикам планирования». Заполнение будет осуществлятся на основе шаблонов ананалитик. В программе можно быть создано множество шаблонов заполнения.

Приведем пример шаблона, который устанавливает значение аналитики «Проект». Шаблон (правило) срабатывает по любым организациям и контрагентам. При этом проверяется содержание назначения платежа. Т.е если поле «назначение платежа» содержит сочетание слов «Основной договор», то в этом случае устанавливается аналитика «Проект основной» в поле проект.

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

Подсистема подходит для тех, кому

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

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

Существуют следующие статусы:

• “Не утверждено”,
• “В процессе согласования”,
• “Утверждено”,
• “Отменено”,
• “Возвращено на доработку”.

При создании задач рецензентам не указывается конкретный пользователь, а заполняется только РольАдресации + ПодразделениеАдресации. Допустим, что согласовать должен

Тогда задача будет создана для Бухгалтера из Бухгалтерии. А конкретных пользователей необходимо указать в регистре «Регистр адресации»

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

Преимущества

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

Видео

• Настройка нового согласования

• обзор подсистемы согласования

• как встроить подсистему в типовую конфигурацию

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

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

Примеры использования подсистемы

Пример 1

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

• всегда согласовывать с «Руководителем по закупкам»;
• если сумма заявки больше 10000, тогда согласовывать с коммерческим директором;
• если сумма заявки больше 50000, тогда согласовывать с финансовым директором;
• если сумма заявки больше 100000, тогда согласовывать с генеральным директором.

Пример 2

В системе договора могут создавать любые пользователи, необходимо настроить согласование договора по следующему маршруту:

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

Часто задаваемые вопросы (FAQ)

Вопрос: можно ли встроить подсистему в нетиповую конфигурацию?

Ответ: да, можно, для этого необходимо, чтобы в конечной конфигурации было следующее:

• Справочник.Пользователи;
• Параметр сеанса «ТекущийПользователь»;
• У конфигурации должно стоять или свойство «Управляемое приложение» или свойство «Управляемое и обычное приложения», т.к. все формы управляемые.

Вопрос: можно ли вызывать форму «Статусы согласований» прямо из элемента справочника или документа?

Ответ: да, можно. Если у Вас используются управляемые формы тогда необходимо:

• зайти в конфигуратор;
• найти общую команду «бпсСтатусСогласования»;
• нажать правую кнопку мыши выбрать свойство;
• в свойстве “Тип параметра команды” указать составной тип данных и выбрать нужный объект.

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

• взять из поставки обработку «бпсСтатусСогласования.epf»;
• нажать «Сервис - Дополнительные печатные формы и обработки - Печатные формы»
• нажать добавить, далее указать обработку;
• в табличную часть добавить те объекты, для которых должна вызываться данная обработка;
• теперь по кнопке печать будет доступен вызов этой обработки.

Если у Вас используются обычные формы и конфигурация не типовая, тогда необходимо в каждую форму элемента справочника/документа необходимо вручную вставить код, пример кода можно посмотреть в обработке «ПримерКодаДляДобавленияКнопкиВОбычнуюФорму.epf»(из поставки).

Вопрос: можно ли указать статус допустим «Оплачено» для документа?

Ответ: да, можно, для этого необходимо:

• зайти в справочник «Статусы объектов» и добавить элемент с наименованием «Оплачено» записать и закрыть;
• далее открыть обработку «Статусы согласований» нажать на кнопку «Установить статус» и выбрать статус “Оплачено”.

Роли

• (БПС) Пользователь - необходимо указать для всех пользователей;
• (БПС) Редактирование регистра адресации - право необходимо для редактирования регистра “Регистр адресации”;
• (БПС) Редактирование документа регистрация статуса объектов - право необходимо для того, чтобы можно было вручную указывать статус для объекта 1с;
• (БПС) Полные права - доступ ко всем объектам подсистемы согласования, а также необходима для настройки согласования.

Что происходит автоматически

• уведомления рассылаются с помощью регламента (раз в минуту);

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

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

Разработка ведется на Bitbucket (пока закрытый репозитарий), основной функционал подсистемы покрыт тестами с помощью xUnitFor1c ().

Тестирование переноса в типовые конфигурации

Тестирование производилось на платформе: 8.3.8.1652

Конфигурация

Результаты тестирования

Бизнес-процесс – это устойчивая последовательность действий сотрудников организации. Автоматизация таких последовательностей упорядочивает работу и значительно ускоряет выполнение конечной задачи.

В программе "1С:Документооборот 8" реализованы бизнес-процессы следующих видов:

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

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

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

• Все руководители автора бизнес-процесса,
• Все подчиненные автора бизнес-процесса,
• Непосредственный руководитель автора документа,
• Все руководители автора документа.

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

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

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

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

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

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

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

Например, шаблон бизнес-процесса Согласование договора может выглядеть следующим образом:

В карточке вида документа можно указать перечень связанных с ним шаблонов бизнес-процессов. Этот перечень будет автоматически использоваться при создании новых бизнес-процессов на основании документов этого вида. В приведенном примере вид входящего документа Договор связан с приведенным выше шаблоном Согласование договора и двумя другими шаблонами – Утверждение договора (простое) и Регистрация договора :

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

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

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

Предварительная настройка процесса согласования цен

• Налаживание процесса согласования цен в программе 1С: Управление торговлей 8 начинается с включения соответствующей опции.
• Затем необходимо проверить «Профили доступа» всех пользователей, которые занимаются ценообразованием. В нашем примере цены устанавливает маркетолог, после чего их утверждает руководство, поэтому проверяем: в его профиле должна быть отключена роль «Установка цен номенклатуры без согласования».
• В заключение необходимо добавить пользователей, которые утверждают окончательные цены. Для этого необходимо зайти в справочник «Роли и исполнители бизнес-процессов» и ответственному руководителю назначить роль «Согласующий установки цен номенклатуры».

Как работает бизнес-процесс «Согласование цен»?

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

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

• В этом случае ему следует заполнить поле «Результат выполнения задачи», внеся свои предложения, и нажать кнопку «Не согласовано».
• Маркетолог в этом случае получает уведомление о принятом решении, в котором может ознакомиться с пожеланиями руководителя.
• Затем маркетолог нажимает кнопку «Ознакомился» и завершает бизнес-процесс. Теперь маркетолог должен пересмотреть цены в соответствии с предложениями руководителя и создать новый бизнес-процесс.
• Руководитель в очередной раз знакомиться с измененными ценами т согласовывает их. В этом случае созданный маркетологом документ «Установка цен номенклатуры» получает статус «Согласовано» и проводится в программе.

У руководителя все под контролем

На закладке «Согласование» руководитель может отследить весь процесс по согласованию того или иного документа по изменению цен.

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

В заключение хотелось бы отметить, что использование бизнес-процесса «Согласование цен» позволяет наладить процесс ценообразования, повысив качество управления персоналом и контроля над ними.