Изменение цен потребностей после отправки на согласование возможно с использованием обработки «Пересчет цен». Данная обработка позволит пересчитать цены в потребностях, находящихся в процессе согласования. После полного согласования потребностей, редактирование цен невозможно.
Обработка «Пересчет цен» будет доступна пользователям с ролью «Пересчет цен потребностей». Оповещение участвующих в процедуре согласования не предусмотрено, т. к. изменение цены будет доступно только заинтересованным пользователям.
Обработка «Пересчет цен» позволит поддерживать актуальность цен на этапе согласования.
В обработке «Ввод и согласование потребностей» при обращении к реквизиту «Вид потребности» проверять следующее: если текущая дата на сервере попадает в период заявочной компании, ограниченный реквизитами «Дата начала» и «Дата окончания», разрешать выбор значения «Долгосрочная». Тем самым мы сможем ограничить ввод долгосрочных потребностей отведенным для этого периодом. Так же пользователь, вводящий потребности, будет оповещен об этом до ввода данных потребностей.
4.2.4.1. Ввод долгосрочных потребностей.
Пользователи в рамках долгосрочного планирования определяют объем своих потребностей, с разбивкой на периоды - месяцы.
Долгосрочные потребности, в силу своей особенности, формируются с указанием количества или суммы на период (месяц), например Январь 10 шт., февраль 15 шт., и т. д.
По умолчанию валюта потребностей определена параметрами планирования и не может редактироваться при формировании потребностей.
Введенные, долгосрочные потребности также контролировать на соответствие установленным лимитам. Данный контроль выполнять, если в параметрах «Заявочной компании» установлен реквизит «Контролировать лимиты».
4.2.4.2. Ввод оперативных потребностей.
При формировании оперативных (текущих) потребностей на следующий месяц, за основу берутся введенные, согласованные долгосрочные потребности на этот период. В качестве даты потребности устанавливать дату равную началу подпериода. Пример:
· Если подпериод равен месяцу, тогда дата будет равна первому числу месяца;
· Если подпериод равен неделе, тогда дата будет равна числу понедельника.
Выполнять контроль, при сохранении, ограничивающий дату потребности, а именно «Дата потребности» 
текущей даты сервера.
· Текущая потребности - При формировании оперативных (текущих) потребностей на следующий месяц, за основу необходимо взять план долгосрочных потребностей на этот период. Оперативные потребности могут быть отредактированы. После внесения изменения пользователь отправит оперативные потребности на следующий этап – согласование.
· Срочная потребности - Для того чтобы повысить важность и критичность своих потребностей пользователю необходима возможность дать своим потребностям, или установить для вновь вводимых потребностей, приоритет срочные. Потребности со срочным приоритетом должны иметь сокращенную процедуру согласования. Данный приоритет будет сигналом, для всех кто впоследствии будет обрабатывать данные потребности.
· Аварийная потребности - В течение месяца, когда оперативные потребности уже поступили в обработку, у подразделения может появиться аварийная потребность, к немедленному обеспечению.
Оперативные потребности должны вводиться с указанием более точной даты. Например: ГСМ 100 л на 15.03.2013, Фильтр 10 шт. на 20.03.2013.
Ввод оперативных потребностей с указанием плановой даты необходим для последующего расчета:
· Плановой даты доставки;
· Плановой даты исполнения потребности.
Алгоритм расчета «Плановой даты исполнения» оперативных потребностей и «Плановой даты доставки» оперативных потребностей.
· «Плановая дата исполнения» рассчитывается по формуле «Дата утверждения потребности» + «Срок поставки» + «Срок перемещения между складами»;
· «Плановая дата доставки» рассчитывать по формуле «Дата утверждения потребности» + «Срок поставки».
В случае отсутствия договора поставки требуемой номенклатуры, рассчитывать плановые даты с учетом проведения тендерных мероприятий. Таким образом, алгоритм принимает следующий вид:
· «Плановая дата исполнения» рассчитывается по формуле «Дата утверждения потребности» + «Срок договорных процедур (Календарных дней)» + «Срок поставки» + «Срок перемещения между складами»;
· «Плановая дата доставки» рассчитывать по формуле «Дата утверждения потребности» + «Срок договорных процедур (Календарных дней)»+ «Срок поставки».
Реквизиты «Срок поставки» и «Срок перемещения» между складами хранить в системе в разрезе складов, с возможностью изменения. Данные реквизиты будут храниться как нормативные показатели, без автоматического расчета.
Реквизит «Срок договорных процедур (Календарных дней)» хранить в регистре «Настройки организаций МТО» в разрезе организаций, с возможностью изменения.
Реквизиты «Плановая дата исполнения» и «Плановая дата доставки» будут представлены пользователям, с ролями «Менеджер по управлению запасами» и «Менеджер по закупкам», при обеспечении потребностей. Также в отчетной форме «Анализ исполнения потребностей» можно будет анализировать реквизиты «Плановая дата исполнения» и «Плановая дата доставки».
Ввод потребностей номенклатуры будет возможен как в разрезе самой номенклатуры, так и в разрезе ее характеристик.
Возможность ввода характеристик номенклатуры определяется в карточке элемента справочника «Номенклатура», реквизитом «Вести учет по дополнительным характеристикам».
Требуется вести учет статей затрат в разрезе Филиалов.
Так же Система должна контролировать:
· Привязку отдельных статей затрат к определённому ЦФО. В справочник «Статьи затрат» добавить реквизит «ЦФО» с возможностью добавления одной статьи затрат к нескольким ЦФО. На форме выбора элементов справочника «Статьи затрат» применять отборы по реквизитам «Организация» и «ЦФО», указанных в настройках пользователя.
· Связь Номенклатуры и статьи затрат (в случае привязки одной номенклатуры к нескольким статей затрат, на этапе ввода потребности Система должна позволить Пользователю выбрать статью затрат из списка).
Т. к. схемы закупки номенклатуры МТР и Основных средств могут отличаться друг от друга, поэтому в системе требуется хранить перечень основных средств в регистре «Основные средства». Регистр содержит аналитики:
· Организация;
· Номенклатура;
· Ответственный.
Потребности по данной номенклатуре не должны вести расход лимитов на материалы.
Системой должно быть предусмотрено электронное согласование потребностей. Для согласующего должна выводиться полная информация о потребности, включая информацию, о количестве уже заявленном на текущий период и всего.
4.2.5. Корректировка потребности.
Процесс корректировки потребностей введенных и сохраненных в систему, но окончательно не согласованных, может производиться непосредственно инициатором потребности.
Случаи корректировок потребностей:
· В процесс ввода – пользователь может корректировать потребности, без каких либо последствий;
· В процессе согласования – пользователь может корректировать потребности после отзыва с процесса согласования;
· Согласованных – пользователь может корректировать потребности, только документом «Корректировка потребностей».
Процесс корректировки потребностей на этапах, отличных от этапа ввода потребностей, будет производиться с помощью специального документа «Корректировка потребностей». Данный документ предполагается формировать в Системе любым пользователем, с ролью «Инициатор потребности» (должны совпадать Организация и ЦФО). В табличную часть документа «Корректировка потребностей» пользователь должен подбирать только потребности, по которым он является инициатором. При подборе потребностей обязательно ограничивать подбор долгосрочных и оперативных потребностей в рамках одного документа. Также в форме подбора выводить информацию:
· Номенклатура (доступно к изменению);
· Номер потребности;
· Дата потребности (для оперативных потребностей);
· Период потребности (для долгосрочных потребностей) (доступно к изменению);
· Количество потребности (доступно к изменению в меньшую сторону);
· Обеспеченное количество;
· Текущий статус потребности;
· Ответственный за обеспечение
· Статья Затрат (доступно к изменению);
· Подразделение получатель (доступно к изменению);
В процессе обеспечения потребности будут изменять статус, в соответствии с текущим этапом обеспечения. Любой этап процесса обеспечения подразумевает формирование в Системе определенного документа.
Корректировка на любом этапе, кроме этапа ввода потребности, должна быть одобрена сотрудником, выполняющим ее обработку, и ответственными руководителями направления. Например, при корректировке на этапе обеспечения, менеджер по закупкам должен подтвердить возможность внесения изменений в потребность. Для данных целей к документу «Корректировка потребностей» должен быть предусмотрен механизм согласования (настройка общая для типа документа, в разрезе Филиала), что позволит оперативно, в электронном виде производить согласование корректировок, а также хранить исторические данные в системе, постоянно доступные для анализа.
Корректировка потребности должна быть доступна на любом этапе, до проведения документа «Задание на перемещение». В случае распроводки документов, корректировка может быть осуществлена.
1.
2.
3.
4.
5.
5.1.
4.2.6. Согласование потребности.
Пользователям системы предоставить механизм согласования введенных потребностей, для утверждения затрат по объектам и контролю рамок запланированного лимита.
Данный механизм должен обеспечить:
· Автоматическое построение маршрута согласования (на основании разрезов планирования введенных на этапе ввода потребности);
· Хранение истории согласования;
· Анализ процесса согласования на основании исторических данных;
· Оповещение согласующего;
|
Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
