Попытаюсь порассуждать о сильных и слабых сторонах iScala исходя из собственных представлений о том, что есть хорошо и что есть «не очень». Разумеется, это мой личный субъективный взгляд.
Если предполагается, что запасы, закупаемые у поставщика, будут сразу оприходованы на склад, ассоциированный с подразделением, сотрудник которого создал требование, тогда, вроде как и говорить не о чем. Вот только это в теории. На практике обычно за получение запасов от поставщика отвечает сотрудник склада (центрального, а не маленькой кладовки или полки в самом подразделении). В этом случае в системе логично сделать приход на центральный склад, а уже с него выдать в подразделение
Главный бухгалтер прекрасно работал с Главной Книгой, захотелось ему посмотреть подробности по складу и ему добавили роль кладовщика. Раз, и пропал доступ в Главную Книгу. Всё из-за неграмотного назначения ролей кладовщику. Вот такие случаются неприятности, когда невозможно проанализировать права доступа для различных ролей. 🙂
Это улучшенный вариант процедуры «Ещё один вариант работы с модулем Requisition Management (Требования)». Имеются важные дополнения и изменения. Для удобства они выделены цветом фона
В ситуации, когда пользователь, создающий требование, не знает, имеется ли то, что ему нужно, на складе, можно ли это заказать, у какого поставщика имеется подобный товар и по какой цене, уместно использовать следующий сценарий работы: Пользователь вводит требование типа 0 (неопределённый тип): Его руководитель утверждает требование, используя пункт меню «Authorise Requisition». В поле «Authorisation» вводится … [Подробнее…]
|
|
|
