О системах планирования ресурсов предприятия Scala, iScala
“ English version of the presentation at the Epicor client conference in Moscow 12.09.2017
  • Главная
    • О проекте
      • Разъяснение о проекте и его участниках
      • Заявление / Memorandum
    • Новости проекта
    • Список опубликованных материалов основного раздела
    • Информация, перенесённая из старых форумов
    • Подписаться на новостную рассылку
  • Статьи
    • Статьи
    • Избранное
    • Мысли вслух
  • Процедуры
  • Доходчиво о сложном
    • Обучение
    • Как сделать?
    • iScala «для чайников»
    • Оч.умелые ручки
  • Структура таблиц
    • Scala 5.1 SR13
    • iScala 2.2 HF 2.3318
    • Tables structure changes history from iScala 2.2 SR2 to iScala 3.0 FSP4
    • Epicor iScala 2.3 — 2.03.3363
    • Epicor iScala 2.3 SR1
    • Epicor iScala 2.3 SR2
    • Epicor iScala 2.3 SR3
    • Epicor iScala 3.00 FSP 2 — 3.00.02254
    • Epicor iScala 3.0 FSP4 — 3.0.4267
    • Изменение структуры таблиц iScala 3.1 по сравнению с iScala 3.0 FSP4 / Table structure changes between iScala 3.0 FSP4 and iScala 3.1
    • Epicor iScala 3.1 — 3.1.0511
    • Epicor iScala 3.2 — 3.2.0317
    • Epicor iScala 3.3 — 3.3.0419
    • Epicor iScala 3.4 — 3.4.0399
    • Epicor iScala 3.5 — 3.5.0.0429
    • Изменение полей в таблицах БД iScala 3.4 по сравнению с iScala 3.2 / Difference between DB structure of iScala 3.4 and iScala 3.2
    • Изменение полей в таблицах БД iScala 3.5 по сравнению с iScala 2.2 / Difference between DB structure of iScala 3.5 and iScala 2.2
  • Материалы по модулям iScala
    • Главная Книга
    • Основные Средства
    • Книга Закупок
    • Книга Продаж
    • Заказы на Закупку
      • Требования
    • Заказы на Продажу
    • Управление Запасами
    • Установка, Администрирование
      • Настройка определений документов MSRS
    • Заработная плата
    • Структура базы данных
    • Отчётность SSRS
    • Отчётность AFR
    • Примеры отчётов
    • Примеры отчётов AFR
    • Интеграция с другими системами
    • Epicor Service Connect
  • English
  • Контакты
  • Поиск
Главная  »»»  Как сделать так, чтобы? Что может упростить Вашу жизнь?  »»»  Multi Level Approvals for Requisitions: How it works?

Multi Level Approvals for Requisitions: How it works?

16.10.2017 Автор Алексей Васильев

English version of the presentation at the Epicor client conference in Moscow 12.09.2017
Multi Level Approvals for Requisitions: How it works? Alexey Vasiliyev, principal consultant, Epicor’s partnerPresentation plan: What does it take for this functionality to work? What settings do you need to make? Different configuration options; The approval process for a specific example; Brief demonstration (if there is time left); QuestionsWhat does it take for this functionality to work?License options - First you need to make sure that you have the appropriate license: Multi Level ApprovalsandMulti Level Requisition Approval Workflow
Additional company settings: Next - additional company settings - activate feature number 450; In the company settings, activate System Raise Business Events (if you want to use the approval of requisitions through the Task Monitor and automatically notify users by e-mail)
What settings do you need to make?Case study: It is assumed that users in departments enter requisitions of type 0 (undefined type) - whether this is in the warehouse is unknown, the prices are "preliminary", the supplier is not specified; After that the preliminary approval of the head of the department; After the preliminary approval of the head of the department, the storekeeper checks whether the ordered items are available in the warehouse. If not, it passes the process on (to the purchaser), if so, changes the requisition type to 2 (stock transfer) and passes on; The purchaser, after receiving the "relay", looks at the type of the line, if it is 2 (there is the necessary quantity in the warehouse), it does not change anything, if 0 (not in stock) - changes to type 1 (purchase order), indicates the right supplier, the right price. Passing on; Approval process again goes to the head of department, this time all prices are final. Head of department again agrees. If the amount is small (within the competence of the head of department), the approval process is terminated, otherwise, it moves to the CFO and, if necessary, afterwards to the General Manager; After the final approval, the Requisition is converted to a stock transfer from the main warehouse to the warehouse associated with the department, or to a purchase orderApproval Groups (example)Approval Matrix (example)Specify Approval Group Level in DepartmentDifferent configuration optionsConfiguration using Service Connect: Add Business Event Type and associate it with the workflow; Create and configure an output channel for sending email messages via Service ConnectConfiguration using Service Connect: Edit existing “ProcessRequisitionApproval” Workflow; Create a workflow to inform the requisition owner for a final approvalThe approval process for a specific example1. Department employee enters Requisition: It is assumed that the user in the department enters requisitions of type 0 (undefined type) - whether this is in the warehouse is unknown, the prices are "preliminary", the supplier is not specified; After entering all the lines, the user presses the button “Req. Approval" and the request “goes" to the Head of Department.At the same time, the requisition becomes unavailable for the user to make changes. The user will only be able to see at which stage of approval his demand is2. The department manager receives notification of the request to approve the requisition: Head of department receives a notification and immediately can assess whether it is necessary to give approval or, perhaps, what his subordinate has requested, is not required at all for work; If he/she agrees, he/she approves the demand, however, this is only the initial agreement, because prices are preliminary, they can be later changed by warehouse or procurement specialists3. The head of the department approves the requisition in iScala: After approval by the head of the department, the "relay race" passes to the one who stands next in the hierarchy of the approval group, in our case, it's the storekeeper who will check whether there are requested items in the stock or not4. The storekeeper receives notification of the request for approval of the requisition: Once the head of department is approved, the next user in the hierarchy of the approval group, in our case, the storekeeper, is notified by e-mail; Storekeeper should find out whether there is in the stock what the user of the department has requested or it needs to be purchased. Storekeeper works in iScala, so the next step is more convenient for him to do directly in iScala interface5. The storekeeper, if necessary, changes the line type and approves the requisition in iScala: After the preliminary approval of the head of the department, the storekeeper checks whether the ordered items are available in the warehouse. If not (as in our example), it does not change anything and simply passes the process on (to the purchaser), if so, changes the requisition line type to 2 (stock transfer) and passes on6. Purchaser receives notification of the request for approval of the requisition: As soon as the handover is transferred by the storekeeper, the next user in the hierarchy of the approval group, in our case, the purchaser, receives an e-mail notification; The purchaser should check the line type and if it remains equal to 0, then change it to 1 (to convert the requisition into a purchase order after its final approval), If not, it does not change anything and simply passes the process on. The purchaser also works in iScala, so the next step is more convenient for him to do directly in the iScala interface7. The purchaser, if necessary, changes the line type and approves the requisition in iScala: After receiving the "baton" from the storekeeper, the purchaser checks whether the storekeeper has changed the type of lines. If not (as in our example), then purchaser must fill in the "warehouse" field, change the line type to 1, specify the correct vendor and change the purchase price if necessary; After that, it passes the process to the next user in the hierarchy of the approval group. If the line type has already been changed by the storekeeper, purchaser does not change anything and simply passes the process onHOD receives notification of the request for approval of updated requisition: As soon as approval process is transmitted by the purchaser, the next user in the hierarchy of the approval group, in our case, Head of Department, receives an e-mail notification. It indicates the changed price and the amount of the requisition. Head of Department for the second time approves the requisition, this time with the final (updated) prices9. Head of Department approves updated requisition in iScala: After receiving the notification with the updated prices and the amount of the requisition, the head of department do the approval. If the amount of the requisition is within the authority of the head of department, the approval process is completed. If the amount is greater than the head of department can unanimously approve, the process passes to the next user in the hierarchy of the approval group10. Financial Director receives notification of the request for approval of the requisition: The next user in the hierarchy of the approval group, in our case, the Director of Finance, is notified by e-mail. Financial Director does not work with the “Requisitions" module in iScala, so it is more convenient for him to use the approval procedure with the Task Monitor, for which he clicks on the link in an e-mail message11. Financial Director approves the requisition using Task Monitor in web interface: Financial Director performs the approval through the web interface of the task monitor. If the amount is within its authority, the approval process is completed. If the amount is more than Financial Director can solely approve, the process passes to the next user in the hierarchy of the approval group, the General Manager. GM does not work in iScala at all, so he performs the approval process in a similar way (via the web interface of the task monitor)12. The owner of the requisition receives notification of the final approval: Once the final approval of the requisition is received, the notification is sent to the user who created the request by e-mail. No action on his part is required, the message is informativeConvert Requisition process: After the end of the approval process, the process of converting the requisition can be performed automatically or manually (depending on the parameters). In this example, the parameters are set in such a way that the conversion is done "manually", this is usually due to the distribution of roles between storekeeper and purchaser (depends on requisition type: 1 – purchaser, 2,5 – storekeeper).
Brief demonstration
Questions?
Thank you!

VK Telegram

Copyright © 2023 О системах планирования ресурсов предприятия Scala, iScala.

Gammapolis WordPress Theme by ERP & Business Consulting

Прокрутка вверх