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

Сокращения¶

1. ЗСНН - запрос на создание новой номенклатуры.
2. ЗУЦ - запрос на уточнение закупочных цен.
3. Закупщик - менеджер по закупкам
4. Продажник - менеджер по продажам

Вводные данные¶

Создание новой номенклатуры по запросу¶

1. Автор заказа клиента (продажник) на основании заказа формирует запрос на создание новой номенклатуры исполнителю (закупщику).
2. Исполнителю автоматически формируется задача.
3. Исполнитель обрабатывает запрос: создает и указывает в запросе номенклатуру, подбирает аналоги или отказывает, и передает запрос автору для проверки.
4. Автору автоматически формируется задача на проверку.
5. Если причина отказа удовлетворительная и остальная часть запроса выполнена без нареканий, продажник помечает запрос закрытым и данные из запроса переносятся в заказ клиента. Если нет - продажник отправляет запрос на доработку и цикл повторяется.

Уточнение закупочных цен¶

1. Автор заказа клиента (продажник) на основании заказа формирует запрос на уточнение закупочных цен исполнителю (закупщику).
2. При формировании запроса продажник должен указать список товаров для уточнения цен, приоритет по срокам, приоритет по качеству, возможность использования аналога.
3. Закупщику автоматически формируется задача.
4. Закупщик обрабатывает запрос: уточняет у поставщиков цену и срок поставки, и указывает их в запросе.
5. Продажнику автоматически формируется задача на проверку.
6. Продажник проверяет обработанный закупщиком запрос. Если у него имеются замечания, то он отправляет запрос на доработку с указанием замечаний и цикл повторяется. Если замечаний нет, то по уточненным закупочным ценам закупщик обновляет прайс-лист.

Требования¶

1. Реализовать формирование задания (бизнес-процесс) по ЗСНН и ЗУЦ, и задачи закупщику (на выполнение) и продажнику (на проверку) на основе задания.
2. У Продажника должна быть возможность отправить ЗСНН/ЗУЦ на доработку исполнителю с указанием комментария к доработке.
3. У Продажника в табличной части ЗСНН/ЗУЦ должна быть колонка “Комментарий к доработке”. Построчные комментарии к доработке автоматически переносятся в комментарий к доработке в шапке документа с указанием тегов в начале и конце автоматической вставки.
4. Если форма заказа клиента открыта и другой пользователь пытается из ЗСНН/ЗУЦ инициировать изменение заказа (обновление его комментария), то у него должно появляться предупреждение о том, что в заказе клиента работает другой пользователь (и указать какой) и изменения в заказе не должны быть выполнены.
5. Исполнитель ЗСНН или ЗУЦ может быть не указан, тогда задача должна формироваться на роль исполнителей “Исполнитель уточнения цен”. Данная роль будет настроена следующим образом:
   Объект адресации - подразделение
   Исполнители роли - закупщики
6. При отказе заполнения номенклатуры в ЗСНН обязательно заполнение комментария исполнителя.
7. В заказе клиента должна быть команда “Догрузить созданную номенклатуру” , при которой в таблицу товаров автоматически будут добавляться товары, созданные или подобранные по запросу на создание новой номенклатуры. При повторном нажатии на кнопку добавленные ранее товары не дублируются, нажатие на кнопку добавляет в список товары, которых в нем еще нет.
8. ЗСНН должен формироваться как на основании заказа клиента, так и простым созданием нового документа.
9. ЗУЦ должен формироваться только на основании заказа клиента.
10. В форме ЗУЦ при регистрации цен должен создаваться документ “Регистрация цен поставщика” для тех строк, в которых указана цена, включен НДС и поставщик. Ссылка на созданные документы должны отображаться в отдельной колонке “Регистратор цен”.
11. В форме ЗУЦ должна быть возможность открыть “Прайс-лист” для тех строк, которые выделены в табличной части и в которых заполнен регистратор цены.
12. При исполнении запроса на уточнение цен в поле “Менеджер по закупкам” должен подставляться фактический исполнитель запроса. Если было несколько исполнителей, то должен подставляться последний.
13. У продажника должна быть возможность в отдельной форме перед формированием ЗУЦ выбрать определенные товары из заказа клиента для переноса в новый документ ЗУЦ. В этом окне вверху должны быть варианты массовой простановки флагов построчно для товаров: отсутствие цены, отсутствие необходимого количества на складе или по умолчанию (или отсутствие цены, или отсутствие на складе).
14. В ЗУЦ должна быть возможность массово (для выделенных строк) установить/снять флаг «можно аналог», указать приоритеты по срокам, по качеству и комментарий.
15. ЗУЦ должен содержать документ-основание (заказ клиента), автора (менеджер, который создал запрос), исполнителя (фактический менеджер по закупкам, который уточнил цены), склад заказа, подразделение заказа, статус документа, список номенклатуры с редактируемыми либо нередактируемыми колонками (т.е. часть колонок должна быть недоступна для редактирования Продажнику).
16. Продажник не может изменять созданные документы ЗУЦ (даже если создал он), только просматривать. У него нет прав на регистрацию цен поставщиков, у закупщика это право есть.
17. В ЗУЦ в случае, если не указан поставщик или цена, цена не может быть зарегистрирована и должно быть выдано соответствующее сообщение.
18. Цены товаров, поставщик, “Включает НДС” должны браться из последней закупки.
19. В ЗУЦ если поставщик поставил флаг “Включен НДС” или ячейка “Цена” не изменяется закупщиком в сравнении со значением, заполненным по умолчанию, то ячейка в соответствующей колонке должна подсвечиваться желтым. Если изменяется - то зеленым.

Примечание: ячейка должна опять подсвечиваться желтым, если содержание изменено на первоначальное.

Результат¶

1. Разработано расширение
   
2. Разработана рабочая инструкция для пользователей
3. Разработана программа и методика испытаний
4. Диаграмма состояний для запроса на создание новой номенклатуры и запроса на уточнение цен, показывающая изменение статусов в зависимости от действий пользователя:
   
   Создание новой номенклатуры
5. На основании заказа клиента создается документ на уточнение закупочных цен. Направляется запрос менеджеру по закупкам путем нажатия на кнопку “Отправить в работу”
   
6. Формируется новое задание и задача появляется в списке задач менеджера по закупкам
   
   
7. ЗСНН для выполнения. У Закупщика нет прав на просмотр заказа клиента.
   
8. Задача на проверку исполнения появляется в списке задач менеджера по продажам
   
9. Задание ЗСНН от продажника закупщику
   
10. Задание на проверку ЗСНН от закупщика продажнику
    
11. Если при проверке у продажника возникают замечания, он пишет комментарий для доработки (в шапке или построчно) и нажимает “К доработке”. Если нет, то нажимает “Принято”
    
    Уточнение закупочных цен
12. На основании заказа клиента продажником создаётся ЗУЦ. Продажник может выбрать товары без цены, в наличии или выбрать все товары.
    
13. Закупщик получает новую задачу и при уточнении закупочных цен у него есть возможность группового заполнения колонок.
    
    
14. После настраивания столбцов закупщик регистрирует цены. Если поменять поставщика у номенклатуры, то цвет изменится на зеленый и зарегистрировать цену необходимо будет заново, так как документ должен создаться повторно.
    
    
15. Как только закупщик зарегистрировал цены и настроил параметры, появляется возможность сформировать и открыть прайс-лист.
    
16. Продажник получает задачу на проверку и может как принять документ, так и отправить его на доработку.
    
17. Комментарий, появляющийся в заказе после выполнения ЗУЦ
    
18. До и после нажатия на “Догрузить созданную номенклатуру”
    
    
19. Всплывающее сообщение о проблеме, когда заказ клиента открыт и редактируется, а из ЗСНН или ЗУЦ продажник или закупщик пытается изменить заказ
    

Характеристики проекта¶

1. Управление по SCRUM
2. Средняя численность команды за время проекта - 6 человек:
   1. 5 - стажёры
   2. 1 - старший инженер-программист/Скрам-мастер/Владелец продукта в одном лице.
3. Исходные коды:
   1. 104 тыс.символов в 2.6 тыс. строк кода
   2. 222 коммита
4. Инструкция:
   1. 8 тыс. знаков
   2. 30 изображений
5. Программа и методика испытаний: 9.3 тыс. знаков.
6. Отзыв: https://www.3soft.ru/otzyvy/27-otzyv-td-rinkam-o-rabote-trisoft