Главная  »»»  Как сделать так, чтобы? Что может упростить Вашу жизнь?  »»»  Многоуровневое утверждение заявок в Epicor iScala: как это работает? Доклад на конференции клиентов Эпикор в Москве 12.09.2017

Многоуровневое утверждение заявок в Epicor iScala: как это работает? Доклад на конференции клиентов Эпикор в Москве 12.09.2017

Многоуровневое утверждение заявок в Epicor iScala: как это работает? Алексей Васильев, консультант-эксперт, партнёр EpicorПлан презентации: Что нужно, чтобы эта функциональность заработала? Какие необходимо сделать настройки? Различные варианты конфигурации. Процесс утверждения на конкретном примере. Краткая демонстрация работы? (если останется время). Вопросы
Что нужно, чтобы эта функциональность заработала?
Лицензионные опции: Для начала необходимо убедиться, что имеется соответствующая лицензия: Multi Level Approvals и Multi Level Requisition Approval Workflow
Дополнительные настройки компании: Далее – редактирование дополнительных настроек компании – активировать свойство 450. В настройках компании активировать поднятие системой бизнес событий (если Вы хотите использовать утверждение требований через монитор задач и автоматическое уведомление пользователей по электронной почте)

Пример из практики: Предполагается, что пользователи в подразделениях вводят требования типа 0 (неопределённый тип) – имеется ли это на складе неизвестно, цены «предварительные», поставщик не указан; После этого производится предварительное одобрение руководителем отдела; После предварительного согласия руководителя подразделения кладовщик проверяет, имеется ли на складе заказываемые позиции. Если нет, он передаёт процесс дальше (закупщику), если да, меняет тип требования на 2 (перемещение между складами) и передаёт дальше; Закупщик, получив «эстафету» смотрит на тип строки, если он 2 (на складе есть необходимое количество), то ничего не меняет, если 0 (на складе нет) – меняет на тип 1 (заказ на закупку), указывает правильного поставщика, правильную цену. Передаёт дальше; Процесс утверждения снова попадает к руководителю отдела, на сей раз все цены уже окончательные. Руководитель отдела снова даёт своё согласие. Если сумма небольшая, процесс утверждения на этом прекращается, иначе, переходит к Финансовому директору и, если необходимо, то после него к Генеральному менеджеру; После финального утверждения Требование преобразуется в перемещение с основного склада на склад, ассоциированный с подразделением, или в заказ на закупку.

Группы одобрения (пример)

Таблица одобрения (пример)

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

Конфигурация с использованием Service Connect: Добавить тип бизнес события и связать его с рабочим потоком; Создать и настроить выходной канал для отправки сообщений Service Connect’ом

Конфигурация с использованием Service Connect: Откорректировать рабочий поток; При желании создать рабочий поток для информирования о получении финального одобрения

Процесс утверждения на конкретном примере

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

2. Руководитель отдела получает уведомление о необходимости утверждения требования: Руководитель отдела получает уведомление и сразу может оценить, нужно ли давать разрешение или, может быть, то, что запросил его подчинённый, совсем не требуется для работы :) Если он согласен, он утверждает требование, однако, это лишь первоначальное согласие, т.к. цены являются предварительными, они могут быть позднее изменены специалистами склада или закупок. Утверждение требования типа 0 лучше всего выполнить через стандартную функциональность

3. Руководитель отдела утверждает требование в iScala: После утверждения руководителем отдела «эстафета» переходит к тому, кто стоит следующим в иерархии группы одобрения, в нашем случае, это кладовщик, который будет проверять, имеются ли затребованные позиции на складе или нет

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

5. Кладовщик при необходимости изменяет тип строки и утверждает требование в iScala: После предварительного согласия руководителя подразделения кладовщик проверяет, имеется ли на складе заказываемые позиции. Если нет (как в нашем примере), он ничего не меняет и просто передаёт процесс дальше (закупщику), если да, меняет тип требования на 2 (перемещение между складами) и передаёт дальше

6. Закупщик получает уведомление о необходимости утверждения требования: Как только выполнена передача «эстафеты» кладовщиком, следующему пользователю в иерархии группы одобрения, в нашем случае, закупщику, отправляется уведомление по электронной почте. Закупщику надлежит проверить тип строки и если он остался равным 0, то изменить его на 1 (чтобы преобразовать требование в заказ на закупку после его окончательного утверждения). Закупщик также работает в iScala, поэтому следующий шаг ему удобнее сделать непосредственно в интерфейсе iScala.

7. Закупщик при необходимости изменяет тип строки и утверждает требование в iScala: После получения «эстафетной палочки» от кладовщика закупщик проверяет, изменил ли кладовщик тип строк. Если нет (как в нашем примере), тогда закупщик должен заполнить поле «склад», изменить тип строки на 1, указать правильного поставщика и уточнить, если необходимо закупочную цену. После этого он передаёт процесс следующему пользователю в иерархии группы одобрения. Если тип строки уже был изменен кладовщиком, закупщик ничего не меняет и просто передаёт процесс дальше

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

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

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

11. Финансовый директор утверждает требование с помощью монитора задач: Финансовый директор выполняет одобрение через веб интерфейс монитора задач. Если сумма требования находится в рамках его полномочий, процесс утверждения на этом завершается. Если сумма больше, чем может единолично утвердить Финансовый директор, процесс переходит следующему пользователю в иерархии группы одобрения, Генеральному менеджеру. Генеральный менеджер вообще не работает в iScala, поэтому он выполняет процесс утверждения аналогично (через веб интерфейс монитора задач).

12. Создатель требования получает уведомление о финальном одобрении: Как только получено финальное одобрение требования, пользователю, создавшему требование, отправляется об этом уведомление по электронной почте. Никаких действий с его стороны не требуется, сообщение носит информационный характер.
Преобразование требования: После завершения процедуры одобрения процесс преобразования требования может быть выполнен автоматически или вручную (зависит от параметров). В рассматриваемом примере параметры установлены таким образом, что преобразование производится «вручную», т.к. обычно это связано с физической выдачей запасов со склада в случае использования типов требований 2 и 5.
Краткая демонстрация работы
Вопросы?

Спасибо за внимание