Последний блок, который мы выделим, — это P2P закупки (Procure-to-Pay), предназначенные для комплексной оптимизации процессов в закупочном отделе. Разрабатываемый блок P2P системы охватывает весь процесс от создания заявок на закупку до их оплаты и доставки товаров, обеспечивая полный контроль и прозрачность на каждом этапе цепочки поставок. Его можно реализовать как самостоятельное продуктовое решение, так и он может быть частью SRM системы. |
Одним из преимуществ P2P закупок является возможность настройки статусных и ролевых моделей для согласования заявок и заказов. Использование BPM-конструктора позволяет быстро внедрять и адаптировать бизнес-логику клиента. Это ускоряет процесс утверждения, минимизируя бюрократические задержки, что способствует сокращению времени цикла закупок. Система поддерживает сложные сценарии согласования с контролем лимитов на одобрение, а также параллельные и последовательные маршруты, обеспечивая гибкость и точность в управлении закупками. Этот инструмент существенно сокращает время внедрения и позволяет вносить изменения без значительных переработок, что защищает финансовые интересы компании и адаптируется под её потребности
Кроме того, благодаря P2P закупкам ваша компания получит возможность гибко управлять приемкой товаров и услуг. Система позволяет вести как полную, так и частичную приемку, что помогает адаптироваться к меняющимся потребностям и оптимизировать процессы поставок. Это означает меньше хаоса и больше структурированности в ваших закупках. Рассмотрим доступный функционал подробнее.
Есть возможность настроить любую ролевую модель, которая необходима под ваши индивидуальные требования. Мы рассмотрим некоторый базовый вариант, который можно будет кастомизировать. |
Глобально всех пользователей можно разделить на Покупателей и Поставщиков в рамках платформы. Рассмотрим, какие основные роли и настройки есть для каждого типа пользователей.
Название роли | Доступные возможности |
---|---|
Инициатор | Может создавать заявки на закупку товаров. |
Руководитель инициатора | Видит заявки и заказы своих подчиненных. |
Бюджетодержатель и финансовый контроллер | Согласуют заявки, основываясь на лимитах бюджета. |
Централизированный инициатор | Инициатор с большим количеством прав. |
Администратор IT | Имеет права на просмотр и изменения данных в административной панели. |
Просмотр | Есть права на просмотр всех данных, но нет права их изменять. |
Служба поддержки закупок (P2P) - управление пользователями | Управляют данными о пользователях, в том числе назначают роли. |
Служба поддержки закупок (P2P) - группа мастер данных поставщиков | Имеют возможность изменять мастер данные по поставщикам. |
Служба поддержки закупок (P2P) - группа по процессу оформления закупок | Согласуют заявки содержащие некаталожные позиции. |
Всем новым покупателям, зарегистрировавшимся на платформе, по умолчанию назначается роль Инициатор.
У пользователя платформы есть возможность делегировать свои полномочия по работе в системе AGORA другому пользователю на определенный период.
Делегируются права на:
Кроме того, пользователь может полностью переназначить Заказы, Поступления и Задачи на согласование другому пользователю.
Делегировать или Переназначить права можно только в случае, если грейд сотрудника выше или равен грейду пользователя, чьи права делегируются. Исключением является роль Финансовый контролер, он может передать права сотруднику с любым грейдом.
Также в настройках пользователя он может формировать отчеты. Можно настроить периодическую выгрузку отчетов. Таким образом в выбранную дату и время сформированный отчет будет направлен автоматически всем выбранным получателям.
Отправку уведомлений с платформы также можно гибко настраивать по отдельным событиям, а также выбирать где именно вы хотите получать уведомление: в системе и/или на адрес электронной почты.
После регистрации, пользователю поставщика становится доступны функции платформы в зависимости от его роли. Как правило, поставщики просматривают и согласовывают текущие заказы, проверяют их статус, участвуют в спотовых событиях.
Название роли | Доступные возможности |
---|---|
Администратор |
|
Менеджер поставщика |
|
Для создания заказа, пользователю необходимо предварительно создать заявку и отправить её на согласование. Позиции в заявке можно как выбрать из каталога, так и писать в свободной форме, если в нем нет необходимой позиции.
Статус | Предшествующее действие пользователя/платформы | Переход в статус |
---|---|---|
Черновик |
| На согласовании |
На согласовании |
| Согласована Черновик |
Согласована |
|
Создайте заявку, заполнив все обязательные поля. После успешного заполнения всех необходимых полей заявка готова к отправке на согласование, цепочка которой построилась по мере заполнения заявки. Для отправки нажмите на кнопку Отправить на согласование:
Помимо создания заявки с нуля можно также копировать заявку с уже созданной ранее. При копировании создается Черновик заявки со всеми данными, что удалось перенести из копируемой.
Цепочка согласующих формируется автоматически на основании грейдов, лимитов согласования и использования каталожной и некаталожной позиции в заявке.
Согласующий | Описание этапа согласования |
---|---|
Инициатор | Данный этап согласуется автоматически после отправки заявки на согласование. Ответственным за данный этап является инициатор - пользователь, создавший заявку. |
Служба поддержки закупок | Данный этап необходим при использовании некаталожной позиции в заявке. Ответственный за данный этап - сотрудник службы поддержки закупок с ролью P2P. |
Технический согласующий | На данном этапе происходит валидация на стороне SAP. |
Бюджетодержатель | На данном этапе ответственный сотрудник контролирует, не выходит ли сумма заказа за рамки бюджета. Бюджетодержатель закрепляется за определенным инициатором. В зависимости от того, выходит сумма за рамки бюджета или нет, к согласованию будет также привлечен руководитель бюджетодержателя, рамки бюджета у которого выше. |
Финансовый контролер | Данный этап необходим только в том случае, если сумма по заявке превышает его лимит. |
После прохождения вышеперечисленных этапов проходит второе техническое согласование и после успешной валидации заявка считается согласованной, на основе которой создаются заказ(ы). Количество заказов зависит от договоров, используемых при формировании заявки.
Для согласования заявки, согласующему необходимо открыть заявку на платформе и нажать Согласовать или Отклонить в зависимости от желаемого результата.
Статус | Предшествующее действие пользователя/платформы | Переход в статус |
---|---|---|
Создан |
|
|
Отправлен | Система отправила заказ поставщику |
|
Ручная отправка | При отправке заказа поставщику была получена ошибка и заказ не был отправлен |
|
На согласовании |
|
|
Частично получен | Пользователь подтвердил создание частичного поступления по заказу |
|
Полностью получен | Пользователь подтвердил создание полного поступления по заказу |
|
Закрыт мягко |
|
|
Закрыт полностью |
| |
Отменен | Пользователь подтвердил отмену заказа |
|
Для создания Заказа (PO), сначала необходимо создать Заявку (PR) с указанием необходимых позиций. Создание заявки было описано выше. После того, как заявка успешно прошла согласование, по ней будут созданы заказы. Количество заказов зависит от договоров, которые использовались в заявке.
Сразу после создания заказа система выполняет следующие действия:
• Отправляет заказ на закупку в SAP.
• Отправляет заказ на закупку поставщику (на электронный адрес и/или в личный кабинет).
После того как по Заказу был получен товар или его часть, на этом основании можно создать Поступление. Создание поступлений мы рассмотрим далее.
Изменение заказа доступно пользователям с ролями Инициатор и Служба поддержки закупок: группа по процессу оформления закупок.
Изменение заказа доступно при соблюдении всех перечисленных условий:
Изменение Количества товара в оформленном заказе, где в строке заказа в платежной информации выбран инвестиционный ордер (название объекта затрат начинается с @) доступно пользователям с ролью Инициатор и P2P Служба поддержки закупок.
Изменить количество на меньшее число, чем уже принято по данной строке заказа, не получится. |
После сохранения изменений заказ перейдет снова на согласование. Исключением являются случаи, когда после изменения заказа сумма уменьшилась относительно согласованной или увеличилась не более чем на 5%. При этих обстоятельствах создается новая версия заказа, и обновленный заказ уходит поставщику в виде измененной печатной формы.
Отменить заказ возможно только в случае, если по нему не создано поступление (GR). Данный функционал доступен пользователям с ролью "Служба поддержки закупок: группа по процессу оформления закупок".
Данный функционал доступен пользователям с ролями:
Мягкое или полное закрытие заказа доступно на статусах:
Мягкое закрытие можно выполнить вручную, после чего, при необходимости, есть возможность переоткрыть заказ. Также, закрытие сработает автоматически через 90 дней после даты поставки.
Повторное открытие заказа доступно на статусе Закрыт мягко. Функционал открытия доступен пользователям с ролью Служба поддержки закупок: группа по процессу оформления закупок.
Закрытие заказа может осуществляться пользователем вручную, либо же автоматически - по истечению 2-х лет с даты последнего изменения. Функционал закрытия доступен пользователям с ролью Служба поддержки закупок: группа по процессу оформления закупок.
Статус | Описание |
---|---|
Создано | Поступление создано. |
Аннулировано | Поступление аннулировано. |
После того как заказ успешно был передан в SAP и находится в статусе Отправлен, по нему можно создать поступление. Для этого необходимо:
В случае возникновения ошибки при создании поступления, ошибка записываться в журнал интеграции SAP и видна в истории изменения Поступления (GR) и Заказа (PO).
Аннулировать поступление может только пользователь с ролью Служба поддержки закупок - группа по процессу оформления закупок.
Договор с поставщиком подразумевают соглашение между Покупателем и Поставщиком, в рамках которого реализуются позиции каталога, а также регулируются такие условия, как Условия оплаты, Условия доставки, Общий лимит по договору (денежный), Возможность превышения установленного денежного лимита.
Сумма по Заявке (PR) учитывается в Сумме всех заказов по договору после согласования заявки. В дальнейшем, при закрытии Позиции в Заказе (PO), производится расчет разницы между суммой позиции и суммой проведенных поступлений по ним, эта разница освобождается в Сумма всех заказов по договору.
Общая формула расчета Свободных средств в договоре:
Свободных средств = Сумма всех заказов по договору - Сумма всех заказов по договору.
В разделе Каталоги отображаются доступные позиции из каталогов поставщиков. Каталожные позиции связаны с определенным Поставщиком и его Договором (см. раздел Договоры с поставщиком).
Доступна возможность:
Создание каталожной позиции доступно пользователям с ролью Служба поддержки закупок (P2P) - группа мастер данные поставщиков.
Для создания необходимо:
После сохранения созданный товар отобразится в списке товаров в разделе Каталог.
Импорт каталога доступен пользователям с ролью Служба поддержки закупок (P2P) - группа мастер данные поставщиков.
Для создания необходимо:
После успешного импорта товары будут отображены в списке товаров в разделе Каталог.
Представления - используется для поиска и фильтрации данных. Построены на elasticsearch, что дает возможность гибкой настройки фильтра.
Используются в разделах:
• Заявки
• Заказы
• Поступления
• Каталоги
• Поставщики
• Договоры
Чтобы создать представление, необходимо:
Для того, чтобы применить представление необходимо:
Если необходимо отфильтровать данные без использования представлений, можно воспользоваться функцией Фильтр. Её можно использовать как при выбранном представлении, чтобы уточнить выборку, так и без него.
Для того, чтобы указать Фильтр, необходимо:
Запрос на согласование заявки на закупку (тип 1) | Заявка доступна для согласования следующему пользователю/группе пользователей в цепочке согласования. Каждый пользователь в цепочке согласования получает уведомление в тот момент, когда предыдущий пользователь в цепочке согласования нажал “Согласовать”. |
Запрос на согласование заявки на закупку (тип 2) | Заявка доступна для согласования бюджет-держателю после согласования предыдущими пользователями из цепочки. Бюджет-держатель получает уведомление в тот момент, когда предыдущий пользователь в цепочке согласования нажал “Согласовать”. |
Заявка утверждена | Заявка утверждена всеми пользователями из цепочки согласования. Каждый пользователь в цепочке согласования и инициатор заявки получает уведомление в тот момент, когда последний пользователь в цепочке согласования нажал “Согласовать”. |
Заявка отклонена | Заявка отклонена любым пользователем из цепочки согласования. Каждый пользователь в цепочке согласования и инициатор заявки получает уведомление в тот момент, когда текущий пользователь в цепочке согласования нажал “Отклонить”. |
Запрос на изменения заказа на закупку | Заказ доступен для согласования следующему пользователю/группе пользователей в цепочке согласования. Каждый пользователь в цепочке согласования получает уведомление в тот момент, когда предыдущий пользователь в цепочке согласования нажал “Согласовать”. |
Запрос на изменение заказа утверждён | Запрос на изменение заказа утвержден всеми пользователями из цепочки согласования. Каждый пользователь в цепочке согласования и инициатор запроса на изменение получает уведомление в тот момент, когда последний пользователь в цепочке согласования нажал “Согласовать”. |
Запрос на изменение заказа отклонён | Запрос на изменение заказа отклонен любым пользователем из цепочки согласования. Каждый пользователь в цепочке согласования и инициатор запроса получает уведомление в тот момент, когда текущий пользователь в цепочке согласования нажал “Отклонить”. |
Напоминание о необходимости создать поступление (GR) | За 4 дня и за 1 день до наступления даты поставки и через 1 день после, если поступление по заказу не было создано. |
Запрос на подтверждение заказа | Произошло создание заказа PO в AGORA. После этого уведомление отправляется на почту поставщика. |
Заказ изменен | Последний в цепочке согласования подтвердил заявку на изменение PO, создана новая версия заказа. |
На платформе реализованы интеграции со сторонними сервисами клиента.
Между платформой и SAP (P0x) настроено интеграционное взаимодействие для обмена следующими данными по следующим потокам:
Название потока | Источник | Получатель | Инициатор | Частота |
---|---|---|---|---|
Cost centers | SAP P0x | Agora | SAP P0x | Раз в сутки |
Internal orders | SAP P0x | Agora | SAP P0x | Раз в сутки |
Suppliers | SAP P0x | Agora | SAP P0x | Раз в час |
Technical contracts | SAP P0x | Agora | SAP P0x | Раз в сутки |
PO simulation create | SAP P0x | Agora | SAP P0x | Каждые 10 секунд |
PO create | SAP P0x | Agora | SAP P0x | Каждые 10 секунд |
PO simulation update | SAP P0x | Agora | SAP P0x | Каждые 10 секунд |
GR create | SAP P0x | Agora | SAP P0x | Каждые 10 секунд |
Раз в 5 минут запускается задача, по которой Middleware получает данные по списку заявок с платформы, которые на этапе согласования Технический согласующий, далее внутри их системы происходит проверка, возможно ли создать заявку с данными, указанными в заявке (правильное ли заполнение, не превышены ли какие-либо лимиты). При отклонении заявки Техническим согласующим, заявка возвращается в статус Черновик и цепочка согласования сбрасывается. В истории изменений заявки пишется причина, почему проверка была не пройдена. При согласовании заявки, заявка движется дальше по цепи согласования и в истории отражается факт согласования со стороны Технического согласующего.
Только что созданные заявки помечаются в системе выключенным параметром "Экспортировано в SAP". Такие заявки выгружаются запросом от SAP раз в 5 минут, после чего помечаются включенным параметром. Выгрузка такого заказа может как создать заказ в SAP, так и обновить уже существующий. В случае возникновения ошибки экспорта в SAP, заказ помечается параметром "Ошибка при миграции заказа в SAP".
Интеграция с 1С используется для синхронизации пользователей
Для пользователей реализована авторизация по технологии SSO через ADFS, для этого настроена интеграция с Active Directory.