На слайде выше описан один из возможных и весьма логичных сценариев работы с модулем «Требования» (Requisitions). Я буду вести речь о шагах, которые следуют за преобразованием требования в заказ на закупку (если нужные запасы невозможно сразу выдать со склада из-за их отсутствия там).
Если предполагается, что запасы, закупаемые у поставщика, будут сразу оприходованы на склад, ассоциированный с подразделением, сотрудник которого создал требование, тогда, вроде как и говорить не о чем. Вот только это в теории. На практике обычно за получение запасов от поставщика отвечает сотрудник склада (центрального, а не маленькой кладовки или полки в самом подразделении). В этом случае в системе логично сделать приход на центральный склад, а уже с него выдать в подразделение (это может быть сделано с использованием требования типа 5 — «расход» или типа 2 — «перемещение на склад, ассоциированный с подразделением»). Но исходное требование уже преобразовано в заказ на закупку. Получается, что для выдачи ранее затребованных запасов снова нужно вводить требование и повторять процедуру утверждения? Или кладовщик должен вручную выполнить перемещение/выдачу запасов, указав правильный номер исходного требования и код департамента? Можно, разумеется, и так, вот только, на мой взгляд, есть идеи получше 🙂
Тем клиентам, что имеют лицензию на соответствующий пакет Epicor Service Connect, можно предложить следующий сценарий:
При вводе накладной по заказу на закупку (поступлении заказанных запасов) срабатывает событие, запускающее специальный рабочий поток (Workflow). Рабочий поток проверяет, был ли заказ на закупку введён вручную или преобразован из требования. В последнем случае создаются копия исходного требования, только первая цифра его номера меняется, например, на 9, а тип указывается равным 2. Используется специальный код департамента, ввод требований для которого запрещен всем пользователям, кроме пользователя, от имени которого работает рабочий поток. Параметры одобрения установлены таким образом, что утверждение выполняет непосредственно кладовщик, ничье дополнительное согласие не требуется (ведь исходное требование уже прошло многоступенчатую процедуру одобрения). Требование утверждается кладовщиком и готово к выдаче.
Как говорится в похожих случаях: «Вот, как-то так» 🙂
Я, кстати, это уже частично опробовал на своей виртуальной машине с iScala 3.1 🙂
