Навигация
Управление запасами и производством по точке перезаказа
111629
знаков
3
таблицы
21
изображение
1.4.2. Управление запасами и производством по точке перезаказа
Одной из задач управления предприятием, которую выполняет служба ОМТС, является задача управления запасами. Для учета и управления запасами, который в н.в. выполняется вручную, применяются карточки складского учета, в которых указывается поступление материалов на склад, их отпуск со склада, а также их остаток. Аналогично информация с карточек дублируется в книгах учета в ОМТС. Кроме того, в ОМТС ведется карточка на материал, в которой вручную заносится потребность под запуск, лимит для выдачи материалов в цеха. При использовании карточного метода задача пополнения запасов реализуется простым (с точки зрения трудозатрат персонала) и очень неэффективным (с точки зрения достижения основных целей предприятия) способом: когда какой-нибудь материал был полностью израсходован, формируется заказ поставщику. В этом случае (поскольку поставка не всегда могла происходить моментально) в течение некоторого времени необходимый материал просто отсутствовал на складе.
Логичным решением, исключающим такую ситуацию, установление некоторого минимального уровня запасов на складах, по достижении которого формируется заказ на пополнение. Т.е, как только реальное количество материала на складе опускалось ниже определенного уровня, называемого точкой перезеказа, значение которой зависело от времени реализации потребности, величина заказываемой партии и некоторых других параметров, происходило оформление нового заказа на поставку этого материала.
1.4.3. Предлагаемая система
ОМТС из компьютерной системы получает информацию о необходимом к закупке количестве материалов (брутто-потребность). Все необходимые расчеты выполняет БМТН предприятия на каждый запуск производства. Плановое бюро ОМТС группирует все рассчитанные потребности ПО ЗАКАЗУ и ПО ЗАВОДУ, в случае необходимости потребность корректируется на допустимые замены согласно таблице замен или оформляется карта отклонений.
Входной информацией является:
1. Рассчитанные MRP-потребности
2. Заявки на заказ поставщику (ответственные ОМТС)
Выполняемые действия:
1. Просмотр необходимых к закупке материалов
2. Формирование заказов на закупку и уведомление финансового отдела о необходимости оплаты в установленном на предприятии порядке
3. Отслеживание заказов поставщикам и уведомление финансового отдела об оплате в соответствии с договором (заявкой на поставку).
выходная информация:
1. Заказы поставщикам (ожидаемые приходы-даты, количество)
2. Уведомления о необходимости оплаты – заявка на оплату и счет со стороны поставщика для оплаты
При расчете MRP потребности необходимо учесть разрешенные замены согласно СТП и карты отклонений, т.е. если отдел закупок, просмотрев потребность, должен установить связку товар-поставщик, т.е. связать с материалом поставщиков. Если такого материала нет, тогда ищут альтернативу и вводят карту отклонений.
Последовательность выполняемых действий:
1. Выбор режима расчета MRP потребности:
- на каталог
- по на все каталоги
2. Расчет MRP потребности.
3. Расчет MRP потребности с учетом замен.
4. Привязка поставщиков. Если есть таблица поставщиков (т.е. связь материалов и поставщиков)
5. Связка поставщик – материал, по поставщику договор и сроки поставки. Не исключено, что по одному материалу имеется несколько поставщиков.
6. Далее дать возможность посмотреть уже сформированные заказы. Т.к каталоги на один и тот же заказ или разные пополняются, то нужно все время проверять общую потребность к закупке с уже сформированными заказами и формировать новые.
Конструкторская часть
2.1. Назначение и состав программного комплекса
Программный комплекс предназначен для уменьшения трудоемкости работы сотрудников отдела материально-технического снабжения ОАО «Тайфун» при планировании закупок необходимых материалов.
Комплекс разрабатывается для автоматизации планирования процесса закупок.
Программный комплекс состоит из клиентской части, выполненной в среде программирования Delphi, и серверной части, выполненной в виде базы данных Oracle, хранимой на сервере и состоящий из таблиц, хранимых процедур и других компонентов базы данных.
1.2. Безопасность доступа к данным 1.2.1. ИдентификацияИдентификация и проверка подлинности пользователей или аутентификация - основное средство защиты информационных систем от постороннего вмешательства.
Под идентификацией обычно понимается процедура, посредством которой пользователь или процесс сообщает сведения о себе. Проверка подлинности, или аутентификация - это процедура проверки достоверности предъявленных данных. Как правило, большинству пользователей требуется доступ ко многим сервисам, предоставляемым системами. В то же время ни им, ни системным администраторам не хочется размножать регистрационную информацию и особым образом входить в каждый сервер.
Выход из этой ситуации заключается в создании специального сервера проверки подлинности, услугами которого будут пользоваться другие серверы и клиенты информационной системы. Выделение особого сервера аутентификации позволяет реализовать собственные прикладные комплексы со своей системой понятий, но со стандартной процедурой проверки подлинности, что существенно облегчает управление правами доступа пользователей.
Для данных целей подсистема использует модуль UnitM4Server, который содержит все необходимые функции. Проверку подлинности осуществляет функция User_Connect. Входные параметры: login – имя пользователя, password – пароль. Данная функция принимает имя пользователя и пароль и при правильном вводе, подключает пользователя к базе. Окно ввода имени пользователя и пароля представлено на рис 2.
Рис.2. Окно проверки доступа
Код процедуры TMainF.SocketConnection1AfterConnect:
Procedure TMainF.SocketConnection1AfterConnect(Sender: TObject);
var
us_n,us_p,us_fio:Widestring;
begin
us_n:='';
us_p:='';
try
M4Server:=IM4ServerDisp(IDispatch(SocketConnection1.appServer));
if M4Server.Error_Code<>0 then
raise exception.Create(M4Server.Error_Message);
us_n:=UpperCase(IniParameters.UserName);
if UsNamePass='' then
PassDlg(us_n, us_p)
else
begin
us_n:=LeftStr(UsNamePass,pos('@',UsNamePass)-1);
us_p:=midStr(UsNamePass,length(us_n)+2,Length(UsNamePass)-2);
end;
if us_n<>'' then
IniParameters.UserName:=us_n;
if M4Server.User_Connect(us_n,us_p,us_fio) > -1 then
begin
StatusBar1.Panels[0].Text := us_fio;
us_n:='';
us_p:='';
menu:=MainMenuConnected;
ShowModulKatalogs(nil)
end
else
begin
if UsNamePass='' then
begin
ShowMessage('Неправильное имя пользователя или пароль!');
SocketConnection1.Close;
M4Server:=nil;
end
else
close;
end
except
//raise exception.Create('Соединение невозможно!');
SocketConnection1.Close;
M4Server:=nil;
raise
end;
end;
1.2.2. АвторизацияКомпоненты и процессы авторизации позволяют предоставлять пользователям разрешения на доступ к ресурсам и управлять этими разрешениями.
Сотрудники завода, имеющие доступ к информационным ресурсам, получают идентификатор. Чтобы обеспечить управление доступом к управляемым ресурсам, например, базам данных и приложениям, для идентификаторов назначаются роли.
Роль - это ключевой компонент функции управления доступом на основе ролей. Роли создаются в соответствии с тем, что требуется сотрудникам для эффективного предоставления доступа к нужному инструментарию [7].
Политика предоставления доступа задает связь между сотрудниками, принадлежащими к различным ролям в организации, и службами, которые соответствуют различным ресурсам, а также определяет, какие права будут предоставлены этим сотрудникам при доступе к службам.
Реализуемая политика предоставления доступа отражает политику управления идентификацией, соответствующую плану обеспечения защиты на заводе.
Политика предоставления доступа представляет собой ключевой компонент каркаса автоматизации управления жизненным циклом идентификаторов.
Предоставляемое право определяет, какие службы связаны с правилом политики и какие условия применимы к предоставляемому праву. Например, предоставляемое право может указывать, есть ли у связанной с ним роли доступ ко всем экземплярам службы, или только к какому-то одному экземпляру этой службы. С предоставляемыми правами также связаны рабочие потоки, которые позволяют реализовать процедуры утверждения при предоставлении доступа к службам.
Похожие работы
... этот путь сейчас является базовым в оптимизации административно-управленческой деятельности и автоматизации прогрессивных производств. 1.2 Уровень развития ИТ в российском легпроме: оценка ситуации По оценкам исследователей, средний уровень развития информационных технологий на предприятиях легкой промышленности классификации CobiT соответствует второй модели зрелости («регулярной»). Это ...
... для реализации системы бюджетирования Консультационной группы "Воронов и Максимов". Статья о проблемах выбора системы бюджетирования - в проекте "УПРАВЛЕНИЕ 3000". Бюджетный автомат Если вы решитесь на автоматизацию системы бюджетирования компании, перед вами сразу встанут вопросы: что выбрать, сколько платить, как внедрять. Примеряйте! О ЧЕМ РЕЧЬ В “Капитале” на стр. 44, 45 мы рассказали ...
... информацию за предыдущие периоды, иначе отчет нарастающим итогом за год придется тоже делать на бумаге. Вот в чем состоит болезненность срыва сроков автоматизации. Расценки и порядок определения стоимости услуг по автоматизации бухгалтерского и управленческого учета. Порядок определения стоимости услуг по автоматизации строится на двух принципах: 1. Объем работ по автоматизации того или иного ...
... с фактами деятельности предприятия. Здесь необходимо подчеркнуть, что базис составляют именно данные из документов, а не сами первичные документы. Начиная разработку системы автоматизации управления на предприятии, необходимо определить, что составляет информационное содержание базы данных- основного системообразующего звена в системе. Естественно предположить, что основное содержание базы данных ...
0 комментариев