пользователям программных продуктов Scala 5.1, iScala 2.1, iScala 2.2, iScala 2.3, iScala 3.0, iScala 3.1 (и так далее)

Работа с модулем «Требования» в Epicor iScala: Возможные усовершенствования процедуры

Пример из практики: Предполагается, что пользователи в подразделениях вводят требования типа 0 (неопределённый тип) – имеется ли это на складе неизвестно, цены «предварительные», поставщик не указан; После этого производится предварительное одобрение руководителем отдела; После предварительного согласия руководителя подразделения кладовщик проверяет, имеется ли на складе заказываемые позиции. Если нет, он передаёт процесс дальше (закупщику), если да, меняет тип требования на 2 (перемещение между складами) и передаёт дальше; Закупщик, получив «эстафету» смотрит на тип строки, если он 2 (на складе есть необходимое количество), то ничего не меняет, если 0 (на складе нет) – меняет на тип 1 (заказ на закупку), указывает правильного поставщика, правильную цену. Передаёт дальше; Процесс утверждения снова попадает к руководителю отдела, на сей раз все цены уже окончательные. Руководитель отдела снова даёт своё согласие. Если сумма небольшая, процесс утверждения на этом прекращается, иначе, переходит к Финансовому директору и, если необходимо, то после него к Генеральному менеджеру; После финального утверждения Требование преобразуется в перемещение с основного склада на склад, ассоциированный с подразделением, или в заказ на закупку.
На слайде выше описан один из возможных и весьма логичных сценариев работы с модулем «Требования» (Requisitions). Я буду вести речь о шагах, которые следуют за преобразованием требования в заказ на закупку (если нужные запасы невозможно сразу выдать со склада из-за их отсутствия там).

Если предполагается, что запасы, закупаемые у поставщика, будут сразу оприходованы на склад, ассоциированный с подразделением, сотрудник которого создал требование, тогда, вроде как и говорить не о чем. Вот только это в теории. На практике обычно за получение запасов от поставщика отвечает сотрудник склада (центрального, а не маленькой кладовки или полки в самом подразделении). В этом случае в системе логично сделать приход на центральный склад, а уже с него выдать в подразделение (это может быть сделано с использованием требования типа 5 — «расход» или типа 2 — «перемещение на склад, ассоциированный с подразделением»). Но исходное требование уже преобразовано в заказ на закупку. Получается, что для выдачи ранее затребованных запасов снова нужно вводить требование и повторять процедуру утверждения? Или кладовщик должен вручную выполнить перемещение/выдачу запасов, указав правильный номер исходного требования и код департамента? Можно, разумеется, и так, вот только, на мой взгляд, есть идеи получше 🙂

Тем клиентам, что имеют лицензию на соответствующий пакет Epicor Service Connect, можно предложить следующий сценарий:

При вводе накладной по заказу на закупку (поступлении заказанных запасов) срабатывает событие, запускающее специальный рабочий поток (Workflow). Рабочий поток проверяет, был ли заказ на закупку введён вручную или преобразован из требования. В последнем случае создаются копия исходного требования, только первая цифра его номера меняется, например, на 9, а тип указывается равным 2. Используется специальный код департамента, ввод требований для которого запрещен всем пользователям, кроме пользователя, от имени которого работает рабочий поток. Параметры одобрения установлены таким образом, что утверждение выполняет непосредственно кладовщик, ничье дополнительное согласие не требуется (ведь исходное требование уже прошло многоступенчатую процедуру одобрения). Требование утверждается кладовщиком и готово к выдаче.

Как говорится в похожих случаях: «Вот, как-то так» 🙂

Я, кстати, это уже частично опробовал на своей виртуальной машине с iScala 3.1 🙂