Уточнённый вариант работы с модулем Requisition Management (Требования)

Это улучшенный вариант процедуры «Ещё один вариант работы с модулем Requisition Management (Требования)». Дополнения и изменения в процедуре выделены следующим цветом фона

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

  1. Пользователь вводит требование типа 0 (неопределённый тип):
    Требование типа 0
  2. Его руководитель утверждает требование, используя пункт меню «Authorise Requisition». В поле «Authorisation» вводится буква «F», что означает утвердить все строки. После этого нажимается клавиша «Enter»:
    Утвердить все строки
  3. В результате все строки меняют статус на «Authorisation» (Утверждено):
    Все строки меняют статус на "Утверждено"
  4. Руководитель нажимает клавишу «ОК». Появляется дополнительное окошко, где необходимо снять «галочку» «Start Сonversion»:
    Сохранить утвержденное требование
  5. Руководитель печатает специальную форму утверждения и подписывает её:

    При печати формы утверждения помимо получения бумажной версии документа происходит обновление флага распечатки заявки. Права доступа настроены таким образом, что после распечатки требования его редактирование становится недоступным для пользователя, который его ввёл. Только руководитель или иное лицо, наделённое аналогичным уровнем доступа теперь сможет внести изменения в распечатанное требование.
  6. Кладовщик просматривает специальный отчёт, размещённый на сервере отчётности, установив в качестве критерия тип требования «Undefined» и статус утверждения «Authorised»:
    Рабочий отчёт кладовщика
  7. Обнаружив новые требования он загружает их в подпрограмму «Authorise Requisition» и подставляет для каждой строки код склада, где обычно хранится заказываемая позиция запаса. При этом сразу видно, сколько единиц доступно:
    Кладовщик указывает для каждогй строки требования код склада
  8. Если заказанное количество превышает количество, имеющееся на складе, он разбивает строку требования на 2 (необходимо в поле «Authorisation» ввести букву «t» и нажать «Enter»): в одной указывает доступное количество, во второй — оставшееся:
    Разбиение строки требования
  9. В результате получается вместо одной строки две:
    После разбиения строки требования вместо одной строки появляются две
  10. Для первой строки кладовщик меняет тип требования на 2 (Перемещение со склада на склад). Программа ещё раз предлагает указать правильный склад:
    Программа требует указать склад
  11. Для второй строки (количество, которое отсутствует на складе) кладовщик меняет тип требования на 1 (Заявка на закупку). При этом программа требует указать код поставщика и цену закупки. Кладовщик может выбрать любого поставщика, позднее правильного поставщика укажет закупщик:
    Программа просит ввести код поставщика
  12. Аналогичные действия проделываются для всех остальных строк требования. В результате требование готово к дальнейшему действию:
    Требование готово к преобразованию
  13. После этого кладовщик нажимает на кнопку «ОК» и появляется дополнительное окно:
    Преобразовать требование?
  14. Права доступа настроены таким образом, что кладовщик имеет право преобразовать строки требования, имеющие тип 2 (Перемещение между складами), а для строк типа 1 (Заявка на закупку) преобразование выполнить не может, ему разрешено только сохранить их. В результате преобразовываются строки с типом требования 2. Программа предлагает напечатать внутреннюю накладную:
    Печатать внутреннюю накладную?
  15. Печать производится с помощью выходного канала MSRS:
  16. Накладная выводится на экран, затем печатается на принтер в 2-х экземплярах:
    Внутренняя накладная
  17. Кладовщик расписывается, что выдал запрашиваемые запасы и выдаёт их. Получатель также расписывается, что получил.
  18. После распечатки внутренней накладной программа выводит дополнительное окно, где предупреждает, что некоторые строки не были преобразованы.
    Некоторые строки не были преобразованыРечь идёт о строках, имеющих тип 1 (Заявка на закупку)
    На этом работа кладовщика с требованием заканчивается, он выбирает следующее требование и проделывает аналогичные действия.
  19. Закупщик также просматривает отчёт на сервере отчётов. Только выбирает в качестве параметра другой тип требования (Purchase Requisition — Заявка на закупку). Для требований, которые он увидел в отчёте, закупщик загружает строки в рабочее окно подпрограммы «Authorise Requisition» и подставляет для каждой строки код правильного поставщика и правильные закупочные цены. Затем нажимает кнопку «ОК»:
    Закупщик для каждой строки требования указывает правильного поставщика и правильные закупочные цены
  20. Производится преобразование требования в один или несколько заказов на закупку. Программа выводит окно с предупреждением, где указывает номер созданного заказа на закупку:
    Заказ на закупку создан на основе требования
  21. Далее закупщик работает с заказом на закупку в обычном режиме.
  22. После поступления заказанных запасов от поставщика кладовщик приходует их по заказу на закупку и сразу делает перемещение на склад подразделения, которое их заказало. Перемещение делается через пункт меню «Stock Control -> Transactions -> Enter Transaction -> Stock Transfer
  23. После ввода количества появляется дополнительное окно ввода, где в поле «Reference» указывается код департамента (соответствует складу, куда перемещаются запасы), а в поле «Номер заказа» при нажатии на функциональную клавишу «F4» открывается список номеров требований для данного департамента, преобразованных в заказ на закупку:
    Кладовщик выбирает нужное:
  24. После ввода всех необходимых строк он выполняет обновление и на вопрос «Печатать внутреннюю накладную?» отвечает «Да» и печатает её на выходной канал 99 — MSRS:
  25. Кладовщик расписывается в накладной, выдаёт запасы. Получатель также расписывается в накладной. На этом работа с требованием считается завершённой.