Диплом № 2123 Разработка программного модуля Планирование
Содержание
ВВЕДЕНИЕ 7
1 ТЕОРЕТИЧЕСКИЕ АСПЕКТЫ И СУЩНОСТЬ ТЕКУЩЕГО ПЛАНИРОВАНИЯ НА ОАО «АЗ»УРАЛ». 9
1.1 Корпоративная информационная система управления предприятием ERP — класса Infor ERP Ln (BAAN 6.1). 9
1.2. Краткая характеристика модуля планирования BAAN VI. 10
1.3 История развития стандарта управления промышленным предприятием MRP II. 11
1.3.1 Планирование потребности в материалах (Material requirements planning): MRP I. 12
1.3.2 MRP I / CRP (Планирование потребности в мощностях). 14
1.3.3 Замкнутый цикл MRP (Closed loop MRP). 16
1.3.4 Планирование ресурсов производства (Manufacturing resource planning — MRP II). 17
1.4 Исследование ключевых элементов системы текущего планирование на ОАО «АЗ «УРАЛ». 21
1.4.1 Состав нормативно-справочной информации о продуктах. 21
1.4.2 Данные об используемых единицах измерения. 22
1.4.3. Данные о номенклатурных позициях. 22
1.4.4 Общие данные. 23
1.4.5 Модель Информационной Системы Планирования предприятия. 23
1.5 Определение сущности и принципов планирования на «АЗ «Урал». 25
2. ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ КОМПЛЕКСА ЗАДАЧ. 30
2.1 Описание предприятия 30
2.2Бизнес-функция планирования на АЗ «Урал» 32
2.2.1 Бизнес-процесс «Планирование предприятия: Основные данные» 33
2.2.2 Бизнес-процесс «Ведение данных изделия по планированию» 34
2.2.3 Ведение мощностей 34
2.2.4 Бизнес-процесс Позаказное планирование 35
2.2.5 Подпроцесс «Анализ позаканого плана» 38
2.2.6 Подпроцесс «Работа с сигналами» 40
2.2.7 Подпроцесс «Подтверждение и передача запланированных заказов» 42
2.2.8 БП Планирование возвратной кооперации 44
3 ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ КОМПЛЕКСА ЗАДАЧ 44
3.1 Среда разработки 44
3.2 Организация хранения данных в Infor ERP ln (BAAN VI) 47
3.3 Разработка программы «Создание таблицы хранения плановых данных». 47
3.3.1 Сеанс создания таблицы «Справочик документов» (lzrrp001). 48
3.3.2 Формирование таблицы хранения плана. 49
3.4 Разработка программы «Формирование многострочного складского заказа» lzrrp9200m000. 55
3.5 Разработка программы «Отчет по плановым заказам» lzrrp0401m000. 56
4. РАСЧЕТ ТРЕБУЕМОГО ПОКАЗАТЕЛЯ НАДЕЖНОСТИ. 59
5. ЭКОНОМИЧЕСКАЯ ЧАСТЬ. 63
5.1 Расчет проектно-конструкторских затрат 63
5.1.1 Материалы и ПКИ 63
5.1.2 Расходы на оплату труда 63
5.1.3 Отчисления на социальные нужды 66
5.1.4 Командировочные расходы 66
5.1.5 Накладные расходы 66
5.1.6 Затраты по работам, выполняемым сторонними организациями и предприятиями 67
5.1.7 Структура цены 67
5.2 Расчет ожидаемого годового экономического эффекта от внедрения 69
6. БЕЗОПАСНОСТЬ ЖИЗНЕДЕЯТЕЛЬНОСТИ 71
6.1 Нормирование производственного освещения 71
6.2 Нормирование акустических колебаний и вибрации 73
6.3 Нормирование параметров микроклимата 74
6.4 Нормирование параметров электромагнитного излучения 76
6.5 Требования к организации рабочего места оператора ВДТ и ПЭВМ 77
6.6 Электробезопасность 79
6.7 Пожарная безопасность 80
ЗАКЛЮЧЕНИЕ. 82
Внимание!
Диплом № 2123. Это ОЗНАКОМИТЕЛЬНАЯ ВЕРСИЯ дипломной работы, цена оригинала 500 рублей. Оформлен в программе Microsoft Word.
Оплата. Контакты.
ВВЕДЕНИЕ
Планирование является важнейшей частью в системе управления предприятием. Подготовка компетентных специалистов требует серьезного подхода к планированию, который создает основу для устойчивой и эффективной работы предприятия.
Планирование есть процесс обеспечения сбалансированности между объёмом используемых ресурсов и их распределением в рамках предприятия.
Важной проблемой планирования на предприятии является четкое понимание сущности, принципов и подходов к его разработке, а также оценка влияния предложенных рекомендаций на эффективность и финансовую устойчивость компании.
Актуальность данного исследования заключается в остроте указанной проблемы для стабильного и продуктивного развития предприятия в перспективе.
Выбор ОАО «АЗ «Урал» в качестве объекта исследования в дипломном проекте продиктован соображениями наиболее полного раскрытия потенциала применения принципов планирования в широком спектре направлений деятельности предприятия: производство, затраты, продажи, запасы.
Определение объекта исследования и актуальности поставленной в работе проблемы приводит к формулированию предмета изучения. Предметом изучения в работе выступает система текущего планирования объекта исследования.
Дипломный проект ориентирован на решение актуальных практических задач организации по повышению эффективности системы планирования на предприятии на основе стандарта планирования MRP II.
Целью дипломного проекта является разработка мероприятий по совершенствованию планирования на предприятии ОАО «АЗ «Урал».
Достижение данной цели предполагает решение ряда задач:
– изучение теоретических аспектов и сущности текущего планирования на предприятии;
– определение принципов текущего планирования;
– исследование ключевых элементов системы текущего планирования в ОАО «АЗ «Урал»;
– оценка влияния предложенных мероприятий на эффективность деятельности предприятия.
1 ТЕОРЕТИЧЕСКИЕ АСПЕКТЫ И СУЩНОСТЬ ТЕКУЩЕГО ПЛАНИРОВАНИЯ НА ОАО «АЗ»УРАЛ».
1.1 Корпоративная информационная система управления предприятием ERP — класса Infor ERP Ln (BAAN 6.1).
Корпоративная информационная система (КИС) предназначена для автоматизации учёта и управления.
ERP-система (англ. Enterprise Resource Planning System) — система планирования ресурсов предприятия. ERP-системы строятся по модульному принципу и в той или иной степени охватывают все ключевые процессы деятельности компании.
BAAN – голландская компания, разработчик решений для управления предприятиями с высокотехнологичным производством и корпоративной логистикой.
Infor ERP Ln (BAAN 6.1) представляет собой корпоративную информационную систему управления, в которой реализованы подходы и принципы, заложенные в стандартах управления предприятием (ERP, MRPII, MRP). Это позволяет сопровождать практически все направления деятельности предприятия и обеспечивать наличие необходимой информации для принятия решений руководителем. С использованием Infor ERP Ln (BAAN 6.1) на АЗ «Урал» обеспечивается выполнение функций по управлению продажами, закупками, складами, производством, техническим обслуживанием, проектами, обеспечивается планирование и отслеживание исполнения планов, а также построение систем материального, финансового и бухгалтерского учета.
В рамках АЗ «Урал» обеспечивается единая цепочка планирования, учета и контроля материальных и финансовых потоков. Руководитель при этом получает инструмент принятия решений и имеет возможность в режиме реального времени получать информацию о состоянии предприятия по разным ключевым показателям.
Система обеспечивает долгосрочное и краткосрочное планирование производства, закупок и распределения, учета прямых и косвенных затрат, позволяет оценить потребности в мощностях и материалах.
Система Infor ERP LN эксплуатируется в режиме «нон-стоп», т.е. 24 часа в сутки, 7 дней в неделю, 365 дней в году при одновременной работе большого числа пользователей. Объединение средств операционной системы, системы управления базами данных и Infor ERP LN обеспечивает высокий уровень надежности и способность к восстановлению после сбоев.(А)
1.2. Краткая характеристика модуля планирования BAAN VI.
Модуль «Infor ERP LN – Планирование» является неотъемлемой частью всей системы Infor ERP LN для обеспечения исполнения функций по управлению потоками материалов в процессе ведения бизнеса. Материалы закупаются, изготавливаются, используются и распределяются на основе рекомендаций, выдаваемых системой планирования. Эти рекомендации обеспечивают наилучший возможный план на основе имеющихся данных. Таким образом, функция планирования является самым важным звеном в динамике спроса и предложения для каждой товарной позиции. Планирование может осуществляться с учетом ограничений по мощностям и/или материалам.
Модуль «Infor ERP LN – Планирование» является критично важным компонентом для решения задач прогнозирования и управления потоками материальных ресурсов. Она использует ретроспективные данные как для определения действующих на рынке тенденций, так и для планирования хозяйственной деятельности компании.
Целостный взгляд на спрос и производственные мощности предоставляет контроль над всем жизненным циклом заказа.
Решение объединяет многие методы планирования в одном приложении, позволяющем сделать планы более точными и помогающем добиться успеха результатов в реализации бережливого производства.
Основой модуля «Infor ERP LN – Планирование» является методология MRP II, являющаяся де-факто стандартом планирования ресурсов производственного предприятия. Модуль способствует повышению точности прогнозов и позволяет учитывать еще только ожидаемые результаты маркетинговой деятельности. Возможность моделировать планы продаж, а также оценить степень достоверности этих планов и просчитать их возможные финансовые последствия является ключевой. Выбрав определенный план, можно точно определить потребность в материалах и их альтернативах, время их закупки, рассчитать загрузку мощностей. Модуль «Infor ERP LN – Планирование» успешно применяется в организациях со сложной структурой (холдинги, группы, объединения) для планирования и организации материальных потоков между отдельными предприятиями, такой организацией является Дивизион грузовых автомобилей – группа ГАЗ, ведущим предприятием которого является АЗ «Урал».
Благодаря имеющимся в системе мощным средствам моделирования можно проанализировать альтернативные планы, которые могут быть одновременно записаны на самых различных уровнях, таких как готовые изделия и семейства изделий. Реализуемость каждого плана может быть протестирована.
Особо ценной функциональной возможностью планирования в Infor ERP LN является «управление загруженностью», позволяющее выстроить календарный план производства с учётом ограничений по критическим мощностям и материалам. Такой план более выполним, он позволяет заранее определить проблемные позиции и периоды. Кроме этого, подсистема позволяет рассматривать разнообразные сценарии событий вида «Что, если?». Моделирование сценариев позволяет оперировать показателями спроса, а также информацией о мощностях, корректировать цепочки поставок, управлять сгруппированной информацией о планах, формировать сезонно-зависимые планы по запасам и др.(А)
1.3 История развития стандарта управления промышленным предприятием MRP II.
Стандарт управления промышленным предприятием MRP II прошел в своем становлении несколько этапов. По мере развития компьютерной техники шире становились возможности в области управления производством на промышленных предприятиях. Можно сказать, что разработка и применение стандартов MRP шли в ногу с увеличением вычислительных мощностей компьютеров.
1.3.1 Планирование потребности в материалах (Material requirements planning): MRP I.
На первом этапе развития стандарта стояла задача фиксации и «разворачивания» потребности в готовой продукции, в результате чего, с учетом наличного складского запаса, формировалась календарная программа потребности в комплектующих изделиях, сырье и материалах, деталях и сборочных единицах. Эта задача была решена в компьютерном варианте в начале 60-х годов и получила название MRP (Material Requirements Planning) — планирование потребности в материалах.
Рисунок 1. Планирование потребности в материалах
Рассмотрим схему подробнее:
1. Данные о потребности в изделиях независимого спроса: заинтересованность в получении тех или иных номенклатурных позиций проявляет непосредственно потребитель продукции предприятия, которому эта продукция отгружается. Потребность может быть представлена или прогнозом продаж, или уже имеющимися в наличии заказами покупателей, или и тем и другим одновременно. Информация о прогнозах продаж и заказах на продажу является основанием для формирования главного календарного плана производства (MPS — Master Production Schedule), охватывающего все включаемые в план производства номенклатурные позиции. MPS формируется как в объемном, так и в календарном исполнении.
2. Данные о запасах продукции, сборочных единиц и материалов, а также информация об открытых заказах. При решении задачи учитываются не только запасы готовой продукции, отгружаемой на сторону, и сырья, закупаемого у поставщиков, но и запасы номенклатурных позиций всех промежуточных стадий производства продукции (полуфабрикаты собственного изготовления, сборочные единицы, узлы и т. п.).
3. Данные о составе изделий и нормах расхода сырья, материалов и компонентов на единицу измерения готовой продукции. В теории MRP эта информация получила название BOM (Bill of Material) (спецификация).
Результатом вышеперечисленных действий является описание потребности предприятия в производимых и закупаемых номенклатурных позициях, выраженное в виде календарного плана.
MRP формирует два массива сообщений:
Плановые заказы — предлагают размер заказа, дату запуска и дату выполнения заказа как результат работы MRP в том случае, когда MRP встречается с наличием нетто-потребности.
Рекомендации — это результат работы системы, определяющий тип действий, необходимых для устранения текущих или потенциальных проблем. Примерами рекомендаций в системе MRP могут служить «запустить заказ», «перепланировать заказ», «отменить заказ».
Необходимо отметить, что MRP работает исходя из следующих посылок:
1) все операции осуществляются в границах одной производственной площадки, т. е. не поддерживается территориально распределенная структура предприятий;
2) производственные ресурсы не ограничены, поэтому MRP не заботится об их достаточности для выполнения сформированного плана.
Явным недостатком на данном этапе развития технологии MRP была невозможность обновить результатную информацию, получаемую в ходе работы MRP, т. е. подстроиться под изменения, возникающие в случае открытых заказов.
Из-за этого первые MRP-системы называли «запустил и забыл». Однако возможность обновления очень важна, т. к. среда, в которой используется MRP, весьма динамична, а частые изменения размеров заказов и сроков их выполнения не являются редкостью. Отсюда вытекает необходимость отслеживать текущее состояние открытых заказов.
По сути MRP просто фиксировала ситуацию в «развернутом» виде.(Б)
1.3.2 MRP I / CRP (Планирование потребности в мощностях).
С ростом возможностей в области обработки данных присущие MRP ограничения перестали удовлетворять менеджеров и плановиков. Поэтому следующим шагом стала возможность обрабатывать ситуацию с загрузкой производственных мощностей и учитывать ресурсные ограничения производства. Эта технология известна как CRP (Capacity Requirements Planning) — планирование потребности в мощностях. Она представлена на рисунке 2.
Рисунок 2. Планирование потребности в мощностях
Для работы механизма CRP необходимы три массива исходных данных.
1. Данные о календарном плане производства, содержащем сведения о производственных заказах. Они являются исходными и для MRP.
2. Данные о рабочих центрах. Рабочий центр — это определенная производственная мощность, состоящая из одной или нескольких машин (людей и/или оборудования), которая в целях планирования потребности в мощностях (CRP) и подробного календарного планирования может рассматриваться как одна производственная единица.
3. Данные о технологических маршрутах изготовления номенклатурных позиций. Здесь указываются все сведения о порядке осуществления технологических операций и их характеристиках (технологические времена, персонал, другая информация).
CRP информирует обо всех расхождениях между планируемой загрузкой и имеющимися мощностями, позволяя предпринять необходимые регулирующие воздействия. При этом каждому изготавливаемому изделию назначается соответствующий технологический маршрут с описанием ресурсов, требуемых на каждой его операции, на каждом рабочем центре.
Следует отметить, что CRP не занимается оптимизацией загрузки, осуществляя лишь расчетные функции по заранее определенной производственной программе согласно описанной нормативной информации.
В этом смысле и MRP, и CRP — плановые механизмы, позволяющие получать корректный и реальный план-график производства на основе использования опыта и знаний лиц, принимающих решения. Иногда технологию MRP называют еще MRP I. Налаженная технология MRP I / CRP при наличии достаточных вычислительных мощностей позволяет, по сути, осуществлять моделирование ситуации.(Б)
1.3.3 Замкнутый цикл MRP (Closed loop MRP).
Следующим после MRP I/CRP шагом по пути развития стандарта MRP стало создание технологии «Замкнутый цикл MRP» (closed loop MRP).
Основная идея данного усовершенствования технологии MRP заключается в создании замкнутого цикла путем налаживания обратных связей, улучшающих отслеживание текущего состояния производственной системы. Дополнительная реализация мониторинга выполнения плана снабжения и производственных операций позволила снять те ограничения степени достоверности результата планирования, ранее присущие MRP I, которые существовали из-за невозможности отследить состояние открытых заказов.
С добавлением указанных функций к MRP I /CRP был сформирован стандарт «Замкнутый цикл MRP». Отличие MRP I / CRP от Closed-loop MRP хорошо поясняется схемой на рис. 3.
Рисунок 3. Сравнение MRP 1 / CRP и «Замкнутый цикл MRP»
Замкнутый цикл MRP – это система, построенная вокруг планирования потребности в материалах (MRP), которая включает дополнительные плановые функции, а именно планирование производства, разработку главного календарного плана производства и планирование потребности в мощностях. После того как вышеописанные фазы планирования пройдены, и планы были приняты как реалистичные и достижимые, начинается исполнение планов. Это включает в себя такие функции управления производством, как измерение входного/выходного материального потока (мощности), формирование подробных графиков и диспетчирование, а также отчетность по предполагаемому отставанию от графиков завода и от поставщиков, формирование графиков поставщиков и т. д. Термин «замкнутый цикл» означает, что эти элементы не просто включены в общую систему, но и существует обратная связь от функций исполнения, с тем чтобы планирование было всегда корректным.(Б)
1.3.4 Планирование ресурсов производства (Manufacturing resource planning — MRP II).
Стандарт MRP II позволил развить технологию планирования, ориентированную на применение корпоративных информационных систем, очертив полный контур задач управления промышленным предприятием на оперативном уровне.
Важнейшая функция MRP II состоит в обеспечении всей необходимой информацией тех, кто принимает решения в сфере управления финансами.
MRP II, отражая концепцию бережливого производства «Точно, вовремя и в срок», сообщает об объемах и сроках поставки изделий покупателям, что позволяет прогнозировать поступление денежных средств. Для обеспечения достоверности всей результатной информации критически необходимо обеспечение точности и своевременности входной информации нормативного и оперативного характера.
Бизнес-планирование не является составной частью стандарта, а предоставляет исходную информацию для принятия плановых решений более низкого уровня, последовательно уточняющих план путем расширения и детализации объектов планирования, приближения горизонта планирования, уменьшения интервала планирования, а также перехода от стоимостных единиц измерения к натуральным.
Разработанные детальные планы, подлежащие исполнению, находят свое стоимостное отражение посредством калькуляции себестоимости продукции, учета реализации, снабженческих и производственных операций. Полученные фактические затраты сравниваются с плановыми (или нормативными), и отклонения служат основой для принятия управленческих решений, относящихся к следующим плановым периодам.
Структура планового механизма в стандарте MRP II представлена на рисунке 4.
Рисунок 4. Планирование ресурсов производства
Планирование ресурсов производства (MRP II) является методом эффективного планирования всех ресурсов производственного предприятия. Он позволяет осуществлять производственное планирование в натуральных единицах измерения, финансовое планирование — в стоимостных единицах измерения, и предоставляет возможность осуществлять моделирование с целью ответа на вопросы типа «Что будет, если…». Он состоит из множества функций, связанных друг с другом: бизнес-планирование, планирование продаж и операций, планирование производства, формирование главного календарного плана производства, планирование потребности в материалах, планирование потребности в мощностях, система поддержки исполнения планов для производственных мощностей и материалов. Выходные данные от этих систем интегрируются с финансовыми отчетами и документами, такими как бизнес-план, отчет о выполнении закупок, план (бюджет) отгрузки, прогноз запасов в стоимостном выражении и т. д. Планирование ресурсов производства представляет собой прямое продолжение и расширение «замкнутого цикла MRP».
Одной из основных причин того, что MRP была с готовностью воспринята как методология управления производством, является ее обращение к возможностям вычислительной техники в области хранения и обработки больших массивов данных и предоставления доступа к ним в целях эффективного управления предприятием. Она помогает координировать деятельность различных подразделений предприятия по исполнению свойственных им функций. Поэтому привлекательность MRP состоит не только в поддержке принятия решений, но и, что более важно, в ее интеграционной роли для производственных предприятий.
Характеризуя MRP II в целом, можно сказать, что его механизм опирается на три базовых принципа: иерархичность, интегрированность, интерактивность.
Иерархичность означает разделение планирования на уровни, соответствующие зонам ответственности разных ступеней управленческой лестницы предприятия (от топ-менеджмента, планирующего продажи и операции, до мастеров в цехах и на производственных участках, осуществляющих функции диспетчирования производственных заказов и принимающих оперативные решения по загрузке рабочих мест, управлению приоритетами заказов, формированию отчетных данных о выполненных заказах).
На разных уровнях зоны ответственности различны. Планы предприятия разрабатываются сверху вниз с одновременным обеспечением надежного механизма обратной связи.
Интегрированность обеспечивается объединением всех основных функциональных областей деятельности предприятия на оперативном уровне (в пределах горизонта планирования продолжительностью до одного года), связанных с материальными и финансовыми потоками на предприятии.
MRP II охватывает такие функции предприятия, как планирование производства, снабжение производства, сбыт продукции, исполнение плана производства, учет затрат, складской учет, управление спросом и т. д. (Б)
Интерактивность систем на базе стандарта MRP II обеспечивается заложенным в него блоком моделирования. Существует возможность «проигрывания» вероятных ситуаций на предмет исследования их влияния на результаты деятельности предприятия в целом или его структурных подразделений в частности. Эта возможность имеется на различных уровнях иерархии плановых решений. Интерактивность поддерживается современными компьютерными технологиями, предоставляющими удаленный доступ к базам данных с рабочих мест специалистов в разных предметных областях.
Таким образом, можно заключить, что MRP II, являясь применимой преимущественно для производственных предприятий со сложным производством, весьма требовательна к уровню организации процесса внедрения и качеству исходных данных.
1.4 Исследование ключевых элементов системы текущего планирование на ОАО «АЗ «УРАЛ».
1.4.1 Состав нормативно-справочной информации о продуктах.
Прежде чем начинать эксплуатацию MRP-систем, необходимо подготовить для этого некоторые нормативно-справочные данные, которые наряду с данными оперативного характера, образуют информационный базис для плановой системы MRP II.
Данные, касающиеся состава продуктов, способа их изготовления, а также параметры работы с продуктоми компании различных модулей КИСУП называют данными о продукте, а модули, ведающие подготовкой и сопровождением соответствующих информационных массивов, — модулями управления данными о продуктах. Помимо этого, следует описать некоторые параметры предприятия: его территориальную и производственную структуру, а также режим его работы (рабочий календарь).
Список сведений, которые необходимо иметь в наличии, следующий:
1. данные об используемых единицах измерения объемов продукции, материалов, деталей и т.д.
2. данные о номенклатурных позициях;
3. данные о спецификациях;
4. данные о технологических маршрутах;
5. данные о территориальной структуре предприятия (иначе говоря, о местах хранения запасов);
6. данные о производственной структуре предприятия (сведения о цехах, участках и т.д., отражаемых посредством логического понятия «рабочие центры»);
1.4.2 Данные об используемых единицах измерения.
Вопрос о единицах измерения является в некоторой степени техническим, однако важно договориться о том, в каких натуральных единицах измерения будут отражаться данные о запасах и нормах расхода по данной номенклатурной позиции. Может быть так, что одна и та же номенклатурная позиция для целей планирования и снабжения производства может фигурировать в разных единицах измерения с указанием соответствующих коэффициентов перерасчета. Для номенклатурных позиций возможно использование разных единиц измерения, однако основной признается та, котороая признается при планировании потребности в материалах и компонентах.
1.4.3. Данные о номенклатурных позициях.
При рассмотрении данных о номенклатурных позициях анализируется массив данных, включаемых в справочник номенклатурных позиций, в котором отражается информация о параметрах работы с ними, предстваляющий их с различных позиций: для целей разработки планов, для целей управления запасами, для целей расчета себестоимости и т.д.
Сбор и подготовка данной информации производится как первый шаг подготовки данных в рамках управления данными о продукте.
1.4.4 Общие данные.
Данные общего характера – это: код номенклатурной позиции, ее описание, основная единица измерения, описание функционального назначения, форма, вес, номер последнего конструкторского изменения и др.
1.4.5 Модель Информационной Системы Планирования предприятия.
В КИС BAAN IV (предыдущей версии СУ) стандартный планировщик не был задействован, использовались программы планирования собственных разработок, считался «чистый» подетальный план. Для того, чтобы снизить фактические остатки ДСЕ (детале-сборочных едениц) и ПКИ (покупные комплектующие изделия) в подразделениях основного производства с 2009 года была разработана процедура планирования с учетом остатков (НЗП) и резервного задела. В предложенной технологии расчета подетального плана был взят ориентир не на перепроизводство, а на уменьшение НЗП до объема необходимой достаточности. В процессе расчета подетального плана, задействованы остатки ДСЕ, материалов и ПКИ, отраженные в системе на начало месяца.
С февраля 2010 года введена в эксплуатацию КИС Infor ERP ln (Baan v6.1).
Рисунок 5. Модель информационной системы планирования предприятия
Основные информационные потоки
1. Прогнозируемый рыночный спрос а/м и з/ч
2. Заявки на закупку от заказчиков
3. Заказы на продажу запчастей
4. Данные об остатках з/ч на складах ТД
5. План закупок з/ч Торговым Домом (запланированная потребность для долгосрочного и среднесрочного планирования)
6. План закупок а/м Торговым домом (в семействах)
7. План закупок з/ч Торговым домом (запланированная месячная потребность)
8. Заказы Торгового дома на закупку з/ч (утвержденная месячная потребность)
9. Потребность прочих заказчиков (невозвратная кооперация)
10. Заказы на продажу а/м, з/ч, материалов
11. Данные об остатках на складах завода
12. Внутренняя потребность в материалах к выдаче в цеха, службы
13. Запланированные заказы на закупку ТМЦ
14. Запланированные производственные заказы
15. Запланированные заказы на распределение
16. Заказы на закупку ТМЦ
Материальные потоки
1. Автомобили;
2. Запчасти, изготавливаемые на продажу;
3. ТМЦ, закупаемые под основную производственную программу;
4. Продукция, изготавливаемая по заказам кооперации;
5. ДСЕ и прочие ТМЦ на внутреннюю потребность подразделений завода;
6. Автомобили и запчасти Торгового дома
Объекты планирования — Подразделения:
Рабочие Центры,
склады,
офисы закупок (подразделения, осуществляющие закупочную деятельность),
офисы продаж (подразделения, осуществляющие продажную деятельность).
1.5 Определение сущности и принципов планирования на «АЗ «Урал».
Планирование будет действенным только в том случае, если оно будет отвечать следующим требованиям:
Во-первых, планирование должно отвечать на вопросы: что, когда и как может произойти?
Во-вторых, реализацию выбранной альтернативы будущего развития необходимо осуществлять на основе решений, принимаемых сегодня.
В-третьих, планирование есть непрерывный процесс принятия решений, в ходе которого устанавливаются и уточняются по времени цели и задачи развития предприятия в связи с изменениями, происходящими вокруг него, и определяются ресурсы для их выполнения.
В-четвертых, планирование следует осуществлять по принципу, согласно которому функционирование предприятия должно быть рентабельно и обеспечивать денежные поступления и прибыль в объеме, удовлетворяющем заинтересованные в результатах работы предприятия группы лиц (собственников, учредителей, коллективов акционеров, государство и т.п.).
В-пятых, в силу различий в характере проявления факторов производства и задач, вытекающих из отдельных направлений деятельности предприятия, планирование подразделяется на долгосрочное и краткосрочное. Так, вопросы, связанные с приобретением оборудования и характером его использования, кадровой политикой, определением ассортимента продукции и рынка сбыта требуют их рассмотрения на долговременный период. В то же время вопросы, касающиеся текущего обеспечения предприятия сырьем и материалами, платы за энергию, воду, необходимо рассматривать на краткосрочный период.
Реализация этих требований предполагает, что планирование в процессе своего осуществления должно следовать следующим принципам:
1. гибкость, предусматривающая постоянную адаптацию к изменениям среды функционирования предприятия. Его соблюдение требует корректировки плана при различных изменениях внешней и внутренней среды;
2. непрерывность, предполагающая скользящий характер планирования, прежде всего в части систематического пересмотра планов, «сдвигая» период планирования (например, после завершения отчетного месяца, квартала, года);
3. коммуникативность, под которой понимается координация и интеграция усилий. Все должно быть взаимоувязано и взаимозависимо;
4. участие, предполагающее важность вовлечения в него всех возможных участников процесса функционирования предприятия;
5. адекватность, т.е. отражение реальных проблем и самооценки в процессе планирования. Адекватность предполагает, что реально происходящие процессы с рациональной точностью должны моделироваться при составлении плана предприятия;
6. комплексность как взаимосвязь и отражение в плане всех направлений финансово-хозяйственной деятельности предприятия;
7. многовариантность, позволяющая выбрать наилучшую из альтернативных возможностей достижения поставленной цели. Соблюдение этого принципа требует разработки различных сценариев будущего развития предприятия исходя из вероятностных сценариев развития окружающей среды;
8. итеративность, предусматривающая неоднократность увязки уже составленных разделов плана (итерации). Это обусловливает творческий характер самого процесса планирования.
На практике применяется стратегическое, долгосрочное, краткосрочное и текущее планирование. Каждое из них имеет свои формы и методы увязки ресурсов и способов достижения целей и расчета показателей.
Стратегическое планирование — видение предприятия в будущем, его места и роли в экономике и общественно-экономическом устройстве страны, а также основных путей и средств достижения этого нового состояния. Речь идет о формах и методах выполнения принятых стратегических решений на основе их увязки друг с другом, соответствующего ресурсного обеспечения и выбора оптимальных способов их реализации, рассчитанных на длительный период времени.
Таким образом, можно сказать, что стратегическое планирование — это средство реализации стратегии предприятия, оно направлено на поиск необходимых ресурсов и путей по достижению целей, вытекающих из принятой стратегии развития. По существу, это увязка целей и ресурсов по их достижению.
Поскольку стратегия развития определяется каждым предприятием, то принимаемый стратегический план в ходе планирования придает предприятию определенность и в то же время индивидуальность. При этом определенность не может быть неизменной, поскольку она вытекает из стратегической установки. Она может быть скорректирована в связи с изменением хозяйственной среды.
Стратегическое планирование целиком и полностью является прерогативой высшего руководства предприятия. Продолжительность планового периода, который охватывает стратегическое планирование, составляет, как правило, 10-15 лет. Выбор такой длительности обусловливается рядом причин, и прежде всего тем, что за этот период обычно происходят сменяемость основных фондов, кардинальные изменения в науке и технике, изменение вкусов населения в сторону новых видов продуктов и услуг и т.д.
На базе стратегического планирования осуществляется долгосрочное планирование на ближайшие 3-5 лет. В нем установки, сделанные в стратегическом планировании, как бы получают свое экономическое обоснование и уточнение с учетом тенденций развития хозяйственной ситуации на ближайшие 3-5 лет.
На основе этих планов производится краткосрочное планирование. Его конкретным выражением являются планы развития от 1 до 3 лет. Их особенность состоит в том, что показатели ближайшего года корректируются ежеквартально, а второго и третьего годов — каждые полгода или ежегодно. Это делается для того, чтобы плановые показатели полнее отражали происходящие изменения в среде (экономика, политика, техника, конкуренция и т.д.) и в результате повышалась бы действенность составляемых планов.
В силу динамичности процессов, происходящих в деятельности предприятия и страны, необходимо осуществлять текущее планирование. Его результатом являются краткосрочные планы (как правило, на год) с учетом и текущих тенденций спроса и предложения. В них показатели устанавливаются на год с разбивкой по кварталам. Эти планы являются скользящими, т.е. на первые 3 месяца показатели устанавливаются жесткие, неизменные, а в последующие 9 месяцев их корректируют по мере изменения ситуации. По сравнению с краткосрочными планами они являются более детальными, особенно в части движения производства и запасов товарно-материальных ценностей, ценообразования, издержек производства и т.д. По сути, в них увязываются задачи различных служб предприятия. Но более тесная координация различных служб предприятия имеет место в календарном планировании, период действия которого составляет, как правило, 10 дней. Это, по существу, программы движения продукта и всех факторов производства с указанием конкретных дат и служб, отвечающих за тот или иной вид деятельности.(В)
Вывод по главе: изучены теоретические аспекты и сущность текущего планирования предприятия; определены принципы текущего планирования; исследованы ключевые элементы системы текущего планирования в ОАО «АЗ «Урал»; рассмотрены особенности применения стратегического, долгосрочного, краткосрочного и текущего планирования.
На основании вышеизложенного считается необходимым предложить следующие мероприятия: разработать бизнес-процесс планирования автомобилей, з/частей, возвратных коопераций основного производства и прикладного программного обеспечения комплекса задач пользователя.
2. ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ КОМПЛЕКСА ЗАДАЧ.
2.1 Описание предприятия
Автомобильный завод «Урал» образован в 2001 году в результате реструктуризации производственного комплекса «УралАЗ». Предприятие входит в состав «Группы ГАЗ» и является основным активом в структуре дивизиона «Грузовые автомобили».
В настоящее время Автомобильный завод «Урал» выпускает:
полноприводные грузовые автомобили с колесными формулами 4х4, 6х6, 8х8 грузоподъемностью от 4 до 15 тонн;
грузовые автомобили для эксплуатации на дорогах с твердым покрытием (дорожные грузовики) с колесными формулами 4х2, 6х4, 8х4 грузоподъемностью от 9 до 25 тонн;
вахтовые автобусы на базе полноприводных автомобилей «Урал» с колесными формулами 4х4 и 6х6 (на 22-30 пассажиров), грузопассажирские автомобили на их базе, в т.ч. оснащенные гидроманипулятором.
Среди заказчиков преобладают крупные нефтегазодобывающие компании (ОАО «Газпром», РАО «ЕЭС», «ТНК-BP», ОАО «НК «Роснефть», ОАО «Сургутнефтегаз») и государственные заказчики – Министерство обороны РФ, Министерство внутренних дел РФ, Министерство по чрезвычайным ситуациям РФ. Высокая проходимость, большая грузоподъемность, надежность, простота технического обслуживания сделали автомобили «Урал» незаменимой техникой для различных отраслей промышленности, сельского хозяйства, силовых структур. Главной отличительной особенностью автомобилей семейства «Урал» является высокий уровень проходимости. Способность двигаться по бездорожью обеспечивается мощным двигателем, специальной конструкцией ведущих мостов, централизованной системой регулирования воздуха в шинах и рядом других конструктивных особенностей.
Миасские грузовики способны эффективно работать при температурах окружающего воздуха от –50 до +50° С. Автомобили «Урал» имеют высокую ремонтопригодность и рассчитаны на безгаражное хранение.
На базе шасси автомобилей «Урал» монтируются более 400 образцов спецтехники: вахтовые автобусы, подъемные краны, автоцистерны, топливозаправщики, пожарные автомобили, ремонтные мастерские, разнообразные агрегаты для нефтегазового и лесопромышленного комплекса, горной промышленности и коммунального хозяйства. Семейство автомобилей имеет высокую степень унификации по агрегатам и комплектующим, что позволяет снизить затраты на производство, дальнейшее техническое обслуживание и эксплуатацию.
С 2005 года Автомобильный завод «Урал» входит в новую для предприятия нишу дорожных грузовиков. На сегодняшний день освоено серийное производство таких автомобилей, как седельный тягач «Урал-63674» (4х2, полная масса автопоезда 42 тонны), самосвал «Урал-63685» (6х4, грузоподъемность 20 тонн), самосвал «Урал-6563» (8х4, грузоподъемность 25 тонн).
С 2007 года предприятиями – производителями навесного оборудования началось активное освоение производства спецтехники на базе дорожных автомобилей марки «Урал»: автокранов, сортиментовозов, автобетоносмесителей, металловозов, самосвалов с трёхсторонней разгрузкой, автоцистерн и др.
На Автомобильном заводе «Урал» внедряются передовые технологии, а именно:
с 2004 года осуществляется внедрение новой производственной системы, основанной на принципах «бережливого производства» («lean production»). Ее родоначальником является фирма «Toyota»;
внедрена и функционирует современная автоматизированная ERP-система «BAAN-VI» (Нидерланды);
при создании новых продуктов применяется система «Ворот качества», которая позволяет эффективно управлять процессами планирования и разработки новых продуктов — PPDS (Product Planning and Development System);
Реализация автомобилей «Урал» осуществляется через Дирекцию по продажам ООО «Грузовые автомобили – Группа ГАЗ» и дилерскую сеть в регионах.
2.2 Бизнес-функция планирования на АЗ «Урал»
Расчет подетального плана на АЗ «Урал» ведется раз в месяц, а запланированные заказы передаются на уровень исполнения (в производство, закупки, заказы) каждую неделю. На начало месяца формирутся исходный план, а в конце месяца по итогам выполнения заказов формируется фактически план, чтобы выявить отклонения оба эти плана сравниваются.
Процедура расчета подетального плана на АЗ «Урал» определяется такими документами, как Спецификация настройки подсистемы «Планирование производства» КИСУП BAAN, описаниями соответствующих задач Управления информационных технологий и прочими инструктивными документами. Ответственность за методологию и проведение расчетов подетальных планов несет Дирекция по производственной логистике.
Все бизнес-функции предприятия описываются такими документами, как: концептуальное описание бизнес-функции, и спецификацией настройки модулей КИС.
Концептуальное описание бизнес-функции содержит лишь общие сведения о ней, определяет цели, задачи, границы и требования к выполнению проекта в конкретной части.
Документ Спецификация настройки «Планирование автомобилей, запасных частей, кооперации и прочей продукции в INFOR ERP LN» предназначен для определения методики проектирования комплекса бизнес-процессов (БП) и ролей бизнес-функции «Планирование» при внедрении INFOR ERP LN. Бизнес-процесс — поток взаимосвязанных событий и действий. Событие трактуется как сигнал, поступающий извне либо генерируемый в процессе функционирования бизнес — области. Наступление события вызывает реакцию — предопределенную последовательность действий, выполняемую при наступлении данного события. Действия, называемые шагами процесса, представляют собой различные операции, выполняемые с информационными и материальными объектами. Бизнес-процессы данного уровня допускают разбиение на составляющие бизнес-процессы более низкого уровня. Нулевой уровень детализации идентифицирует саму бизнес-область. Данному уровню соответствует корневой процесс. Корневой процесс состоит из первичных процессов. На нижнем уровне детализации находятся элементарные процессы.(Г). Бизнес-функция – это глобальный процесс, определяющий основные работы предприятия. Например, планирование, производства, продажи и т.д. Бизнес-функция «Планирование» является источником информации для закупок, производства и управления запасами. Целью данной функциональной области является поддержка процессов планирования производства и обеспечивающей деятельности на основании потребностей клиентов. Эта функция обеспечивает планирование на операционном уровне и учитывает: какие изделия должны быть произведены и/или закуплены и к какому времени, а также, запасы каких изделий должны быть пополнены через межскладские перемещения.
Объектами – источниками планирования являются автомобили, зап.части, кооперации на сторону, возвратные кооперации, ТМЦ на прочие нужды (материальные заявки цехов).
Бизнес-функция планирования включает в себя такие бизнес-процессы, как: «Планирование предприятия: Основные данные», «Ведение данных изделия по планированию», «Ведение мощностей», «Позаказное планирование», «Планирование ТМЦ на прочие нужды», «Планирование возвратной кооперации». Эти бизнес-процессы могут включать в себя подпроцессы.
Для построения в системе бизнес-процессов и бизнес-функций предприятия и дальнейшей конфигурации системы и ее настройки для конечных пользователе предназначена подсистема Infor ERP LN – Моделирование предприятия.
2.2.1. Бизнес-процесс «Планирование предприятия: Основные данные».
Этот БП предназначен для настроек модуля планирования предприятия. Для функционирования модуля в соответствии с требованиями конкретной компании необходимо задать основные данные планирования. К основным данным планирования относятся: определение сценария и задание Параметров EP. Сценарий – это идентификатор одного или нескольких возможных решений планирования. Планирование выполняется в рамках определённого сценария и зависит от настроек этого сценария. Для задания типов функций, используемых в Планировании, служат Параметры EP. Если некая функция в Параметрах EP запрещена, то использование сеансов, связанных с этой функцией, также запрещено.
2.2.2. Бизнес-процесс «Ведение данных изделия по планированию».
Этот БП предназначен для занесения или корректировки параметров планирования в карточке изделия. Для ускорения ввода данных изделия по планированию могут быть заданы данные по умолчанию, которые основаны на комбинации типа изделия и группы изделия. Таким образом, при создании нового изделия все поля будут заполнены автоматически, в дальнейшем их можно корректировать вручную в соответствии с требованиями.
2.2.3. Бизнес-процесс» Ведение мощностей».
БП предназначен для настроек параметров на предмет использования мощностей, влияющих на результаты планирования.
В Планировании предприятия производственные мощности ссылаются на ресурсы. Каждый Рабочий центр автоматически определяется как Ресурс в модуле Планирования. С каждым ресурсом можно связать отдельный календарь, который используется системой планирования для расчёта и планирования мощности. При отсутствии собственного календаря у ресурса его мощности будут рассчитаны на основе календаря более высокого уровня (например, календаря компании).
В системе возможно создание неограниченного количества календарей, которые могут применяться к различным подразделениям предприятия, если график их работы различается. В обязательном порядке должен быть задан стандартный календарь и календарь, используемый как календарь компании. На этапе запуска системы используем код календаря 1 – базовый календарь.
В Планировании календари используются для того, чтобы иметь информацию о доступных часах в день или в неделю и учитывать доступность ресурсов, т.е. с помощью календарей происходит:
Определение даты начала, даты окончания и даты потребностей для запланированных заказов
Определение доступности мощности в планируемый временной период
Определение фактической длины горизонтов и временных границ, выраженных в рабочих днях
Для Планирования необходимо настроить таблицу периодов, с помощью которой проверяется принадлежность даты к указанному календарному году и определяется время действия временных горизонтов. Периоды – это интервалы времени с учётом часового пояса. Для таблиц периодов должны быть сгенерированы конкретные временные интервалы различной длительности.
2.2.4. Бизнес-процесс «Позаказное планирование».
Этот БП обеспечивает долгосрочное и краткосрочное (месячное) планирование производства и закупок комплектующих и материалов. Краткосрочное планирование отличается от долгосрочного уровнем детализации плана (сценария). БП обеспечивает планирование на основе горизонта заказа (горизонт заказа = 365 рабочих дней) и уровня резервного запаса. В планировании заказов поставка (производство, закупка, перемещение со склада на склад) планируется в виде запланированных заказов (запланированные производственные заказы, запланированные заказы на закупку, запланированные заказы на распределение) на определённое количество изделия. Объём и частота заказов определяется параметрами изделий (установленным объёмом заказа в карточке изделия и интервалом заказа = 5 рабочих дней, по особоучитываемой номенклатуре = 1 рабочий день, для закупаемых = 22 рабочих дня). Для выполнения планирования распределения потребностей используется механизм кластеров. Кластер – это группа складов. Одна из характеристик кластера состоит в том, что можно установить взаимосвязи поставок между кластерным и некластерным изделием. Такие взаимосвязи позволяют построить необходимую цепочку поставок, используемую для выполнения планирования распределения потребностей. Настройки кластерного распределения описаны в методической СН «НСИ».
Полученный план заказов анализируется, если необходимо, проводится корректировка входной информации, и после этого процедура планирования повторяется.
Полученные запланированные заказы передаются на уровень исполнения (в модули Производство, Закупка и Управление запасами). Временной диапазон, за который передаются заказы, зависит от замороженного периода (1 неделя = 5 рабочих дней). Сформированные SFC-заказы на определённый временной диапазон являются законом для производств и могут быть пересмотрены только Дирекцией производственной логистики.
Блок — схема БП Позаказное планирование
Шаг 1: Инициализировать, сместить и обновить сценарии
Шаг выполняется для выполнения смещения сценария планирования (для краткосрочного СФ1 – 1 раз в неделю, для долгосрочного СДi этот шаг выполняется при создании сценария).
Шаг 2: Генерация плановых заказов
Шаг выполняется с целью создания плановых заказов на производство, закупку комплектующих и распределение (перемещение). Генерацию проводим в два этапа: по 1 уровню (автомобили) и после выстраивания автомобилей вручную по дням на планируемую неделю (тем самым создаются предпосылки для создания «жёсткой закладки». Детально «жёсткая закладка» описана в методической СН по «жёсткой закладке»), запускаем генерацию по 2 уровню (вся остальная номенклатура). Запланированные заказы генерируются на основании потребностей складов, цехового управления, с учётом объёмов потребностей, зарегистрированных в системе заказов, данных изделий по заказу и других параметров изделий. При генерации плановых заказов учитывается время потребности в этом заказе. Запланированные заказы генерируются в рамках горизонта заказа.
Шаг 3: Генерация связей цепочки заказов
Шаг выполняется для создания связей цепочки поставок. Цепочки поставок позволяют проследить источник спроса в закупаемом \ изготовляемом изделии.
Шаг 4: Запланированные заказы
Шаг выполняется с целью просмотра данных запланированных заказов.
2.2.5 Подпроцесс «Анализ позаканого плана»
Блок — схема подпроцесса Анализ позаказного плана
Шаг 1: Позаказный план
Шаг выполняется для детального анализа результатов планирования для конкретного изделия.
Шаг 2: Запланированный заказ – складские перемещения
Шаг выполняется для детального анализа планового движения изделий, ПКИ и материалов.
Шаг 3: Просмотр заказа в цепочке заказов
Шаг выполняется для просмотра связей цепочки заказов. Для просмотра отчёта по одноуровневой СИ, необходимо выбрать непрерывный метод «Вверх», для просмотра отчёта по применяемости компонентов СИ, необходимо выбрать непрерывный метод «Вниз». Можно просматривать цепочку по Плановику, по коду изделия, по Рабочему центру, по типу заказа.
2.2.6 Подпроцесс «Работа с сигналами»
Блок — схема подпроцесса Работа с сигналами
Шаг 1: Типы сигналов – По плановику
Шаг выполняется для определения или изменения набора типов сигналов для конкретного плановика, при этом расставляется приоритет сигналов (для показа сигналов в порядке важности от 1 (наивысший приоритет) до 100 (наименьший приоритет) и горизонт сигналов (число рабочих дней с даты расчёта для которых может быть сгенерирован сигнал определённого типа). Для того, чтобы сигнал указанного типа для конкретного плановика не создавался производится блокировка сигнала. Автоматически обрабатываются следующие типы сигналов: отмена заказа, ускорение графика, замедление графика.
Шаг 2: Обновить сигналы
Шаг выполняется для обновления сигналов после корректировок данных, на которых основаны эти сигналы. При этом система запомнит принятые сигналы, чтобы не потерять информацию о том, что рассматриваемые сигналы были приняты.
Шаг 3: Обзор сигналов – По плановику
Шаг выполняется с целью получения обзора общего количества сигналов для конкретного плановика и просмотра перечня изделий, для которых сигналы были созданы.
Шаг 4: Плановик \ Сигналы изделия
Шаг выполняется для просмотра и анализа результатов сигналов по изделию по конкретному плановику.
Шаг 5: Обработка – Сигналы
Шаг выполняется для автоматической обработки сигналов типов «отмена заказа», «замедление графика» и «ускорение графика». При обработке этих сигналов запланированные заказы (в зависимости от сигнала) отменяются или система автоматически составит новый план на дату, которая будет рекомендована в сигнале.
2.2.7 Подпроцесс «Подтверждение и передача запланированных заказов»
Блок — схема подпроцесса Подтверждение и передача запланированных заказов
Шаг 1: Подтверждение запланированных заказов
Шаг выполняется с целью подтверждения запланированных заказов. Временной диапазон, на который подтверждаются заказы, зависит от периода, на который они передаются на уровень выполнения (1 неделя). В результате запланированные заказы со статусом Запланированный получают статус Подтверждённый. Подтверждённые запланированные заказы могут быть переданы на уровень выполнения.
Шаг 2: Передача запланированных заказов
Шаг выполняется с целью передачи запланированных заказов на уровень исполнения (в модули Цеховое управление, Закупки, Управление запасами). Временной диапазон, за который передаются заказы, зависит от замороженного периода (1 неделя = 5 рабочих дней). При передаче запланированного производственного заказа создаётся SFC – заказ с серией: П + первые 3 символа кода склада ГИ. При передаче запланированного заказа на закупку создаётся заказ на закупку с типом заказа S01 и серией: последние два символа типа продукции + 01. При передаче заказа на распределение создаётся складской заказ на перемещение с типом заказа ПР1 и серией ПЛАН_
2.2.8 БП Планирование возвратной кооперации
БП определяет метод планирования работ по возвратной кооперации и потребностей в комплектующих ДСЕ для предприятий, выполняющих работы для производственного процесса АЗ (предприятия «АвтоХимСинтеза», «Надежды», и т.п.). Для изготавливаемых по кооперации деталей и планирования потребности в материалах используется механизм контракты на продажу. В системе регистрируются контракты на продажу в соответствии с определённой серией. Используемые серии контрактов описаны в СН методическая по модулю Продажи. Далее эти контракты участвуют в общем контуре Планирования, таким образом, в системе получаем запланированные производственные заказы на изготовление комплектующих ДСЕ.
3 ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ КОМПЛЕКСА ЗАДАЧ
3.1 Среда разработки
Программная разработка задачи осуществляется во внутренней среде корпоративной информационной системы управления предприятием BAAN VI — SSA ERP Enterprise Studio.
SSA ERP Enterprise Studio предоставляют широкий инструментарии для разработки.
Enterprise Studio содержит интегрированную среду разработки (integrated development environment IDE), которая позволяет вам программировать в:
Бизнес логике
Пользовательском интерфейсе и диалоге
Структурах баз данных
Многоязыковой поддержке меток, описаний, сообщений и.п.
Документировании и написании помощи
Среда разработки включает в себя мониторинг изменений в системе и управление производительностью.
Программисты используют инструментарий Enterprise Studio для разработки программного продукта. Результат разработки – это программные компоненты, из которых строятся приложения.
Основным программным компонентом является сеанс.
Сеанс — это совокупность системных компонент, которые работают вместе выполняя определенную задачу. Эти компоненты могут иметь уникальные идентификаторы, или коды, чтобы можно было отделить их от других компонент. Системные компоненты включают в себя:
Формы(Forms)
Отчеты(Reports)
Диаграммы(Charts)
Объектные коды, скопмпилированные из программных скриптов(Object)
Формы/Forms
Формы — это часть пользовательского интерфейса сеанса. Формы используются для предоставления информации о данных и действиях выполняемых над этими данными.
Сеансы и формы взаимосвязаны. Структура формы в сеанса определяется полями, метками и опциями, которые доступны для показа детального или многострочного сеанса.
Отчеты/Reports
Отчеты используются для печати данных на экран, принтер или иные устройства.
Сеанс может не иметь ни одного отчета, а может и несколько. Если отчетов больше одного, то сеанс обычно предлагает выбор из списка нужных.
Диаграммы/Charts
Диаграммы представляют данные пользователю в графическом виде. Сеанс может содержать один или несколько диаграмм.
Объектные коды/Objects
В объектных кодах содержится масса бизнес-логики. Компилируя 4GL скприпт создается объектный код. Он будет управлять задачами, которые исполняются в сеансе. В объектном коде могут выполняться функциональности, вычисления, модификация данных таблиц.
Объектные коды также могут вызывать динамически привязанные библиотеки(dynamic link libraries DLLs). Библиотеки являются также объектными кодами, которые ни как не ассоциируются с сеансом. Они обычно используются для исполнения каких-либо общих функций. Использование DLL приходится на большие комплексные системы, где используются общие методы решения определенных задач
Программирование осуществляется на языке 4GL
Язык Программирования 4-го Поколения 4GL.
Включает следующие возможности:
Средства стандартных языков программирования 3-го поколения.
Программные переменные.
Изготовление операторов по ходу программы.
Операторы манипуляции базой данных. SQL.
Переброска данных из базы данных в программные переменные, и обратно.
Курсоры.
Печать результатов запросов. Отчеты.
Экранный обмен с пользователем.
Меню. Окна.
Экранные формы, экранные поля, экранные массивы.
Файл описания экранной формы.
Файлы с исходными текстами.
Описание состава программы.
3.2 Организация хранения данных в Infor ERP ln (BAAN VI)
Все данные для работы в БААН хранятся в таблица Оракл на отдельном сервере. Каждя таблица имеет свой уникальный код.
Структуры таблиц определяют структуру данных. Таблица имеет поля. Поля хранят отдельные кусочки данных, такие как имя клиента, количество заказанного изделия, или дату журнальной проводки.
Каждое табличное поле имеет тип, например: символьный для имени клиента, числовой для количества, дата для даты журнальной проводки. Система обеспечивает согласованность в полях используя домены. Домены – это компоненты, которые определяют общую информацию о данных, таких как их тип, возможные значения или специальные характеристики (например, правило выделения заглавными буквами).
Таблица может быть связана с другой таблицей. Связанные таблицы – это если одна таблица имеет ссылку на другую. Таким образом, данные связываются: клиенты могут иметь заказы, запасы изделий хранятся на складах, работники трудятся в подразделениях.
3.3 Разработка программы «Создание таблицы хранения плановых данных».
Данные сеансы предназначены для формирования таблицы хранения плановых данных в BAAN -6, т.к. по стандарту при передаче запланированных заказов на уровни исполнения (в Производство, Закупки, Запасы) их ретроспективы в системе не остаётся, а для существующих отчётов служб необходимо хранить плановые данные, на которых строятся эти отчёты в течение года. Инструкция предназначена для подразделения ДПЛ.
Каждый расчёт месяца идентифицируется отдельным номером документа в таблице «Справочник докумнтов». Регистрация документа должна выполняться до начала расчёта месячного плана. Выполняется регистрация по сеансу lzrrp0101m000.
Существует два типа расчёта месячного плана: расчёт на начало месяца и расчёт на конец месяца. Каждый тип расчёта регистрируется отдельным номером документа в «Справочнике документов». План на начало месяца формируется при выполнении сеанса «Формирование исходного плана». План на конец месяца формируется при передаче заказов на уровень исполнения при помощи сеансов «Формирование фактического плана» (план изготовления и план закупок) и «Формирование многострочного складского заказа» (план подачи) накопительно в течение месяца. Следует иметь в виду, что план подачи присутствует только в плане на конец месяца. Связано это с тем, что запланированные заказы на распределение формируются только после передачи запланированных производственных заказов в модуль «Производство».
3.3.1 Сеанс создания таблицы «Справочик документов» (lzrrp001).
Структура создаваемого справочника представлена в таблице 1.
Таблица 1
Код Тип Размерность Наименование
ndoc string 8 номер документа
bdat date 4 дата начала планового периода
edat date 4 дата окончания планового периода
stat enumerated 1 статус
rdat date 4 дата расчета
prim string 10 примечание
Вид создаваемого справочника представлен в таблице 2.
Таблица 2
Номер документа дата начала планового периода дата окончания планового периода статус дата расчета примечание
ИГГММХХХ формат ДД.ММ.ГГ формат ДД.ММ.ГГ 1 формат ДД.ММ.ГГ
ФГГММХХХ 2
Алгоритм работы: перед тем, как занести плановые данные в архив, в этом справочнике необходимо сформировать номер документа на плановый период, под которым эти данные запишутся в таблицу, где хранится история планирования. И – исходный план, Ф – фактический план, ГГ – последние цифры года, ХХХ – номер расчета. Статус: 1 – действующий, 2 – устаревший.
3.3.2 Формирование таблицы хранения плана.
3.3.2.1 Сеанс формирования исходного плана (lzrrp0201m000)
Для формирования исходного плана необходимо сделать выборку значений из таблиц: cprrp100 – запланированные заказы и cprpd000 – параметры ER. На основе этой выборки будет осуществляться запись данных в таблицу lzrrp002 – таблица хранения плановых данных.
На рисунке представлена схема модели данных, состоящая из таблиц, используемых в процессе реализации алгоритма задачи.
Структура таблиц представлена в соответствующих таблицах.
Таблица 3 «Запланированные заказы»
Код Тип Размерность Наименование
plnc string 3 Сценарий
psdt date 4 Плановая дата начала
type enumerated 1 Тип заказа
item string 50 Код изделия
quan double 8 Объкм заказа
dwar string 6 Склад назначения
suwa string 9 Поставляющий склад
cplb string 6 Плановик (закупщик)
Таблица 4 «Параметры ER»
Код Тип Размерность Наименование
aplc string 3 Фактический план
indt data 4 Дата
Таблица 5 «Таблица хроанения плановых данных»
Код Тип Размерность Наименование
type enumerated 1 Тип заказа
item string 50 Код изделия
quan double 8 Объкм заказа
dwar string 6 Склад назначения
suwa string 9 Поставляющий склад
cplb string 6 Плановик (закупщик)
Алгоритм работы:
1. Записать в таблицу Справочник документов lzrrp001 строку с номером документа ИГГММХХХ, статус равен 1.
2. Выборка данных: взять из таблицы cprrp100 те данные, у которых сценарий соответствует фактическому плану с последней датой; плановая дата начала должна быть в границах даты начала и окончания планового периода.
3. Записать в таблицу lzrrp002 следующие данные: тип заказа, код изделия, объем заказа, склад назначения, поставляющий склад, плановик. Причем, тип заказа – type является ключевым полем. Т.е. если type = 5 (запланированные заказы на закупку), то доступно поле cplb – плановик (закупщик), если type = 30 (запланированные заказа на распределение), то доступно поле suwa – поставляющий склад.
4. Сделать посуммирование количества quan – объема заказа по коду изделия – item.
3.3.2.2 Сеанс формирования фактического плана (lzrrp0202m000)
Для формирования фактического плана необходимо также сделать выборку значений из таблиц: cprrp100 – запланированные заказы и cprpd000 – параметры ER. На основе этой выборки будет осуществляться запись данных в таблицу lzrrp002 – таблица хранения плановых данных. Для формирования серии для производственных заказов и типа для закупок используются таблицы cprpd100 – «Изделия — Планирование» и tcibd001 – «Изделия – Общие данные».
На рисунке представлена схема модели данных, состоящая из таблиц, используемых в процессе реализации алгоритма задачи.
Структура таблиц представлена в соответствующих таблицах.
Таблица 6 «Изделия — Планирование»
Код Тип Размерность Наименование
plni string 50 Плановая единица
cwar string 6 Склад по умолчанию
Таблица 7 «Изделия – Общие данные»
Код Тип Размерность Наименование
item string 47 Изделие
ctyp data 3 Тип продукции
Алгоритм работы:
1. Перед передачей заказов на уровень исполнения сделать запись в таблицу lzrrp001 с номером документа ФГГММХХХ, статус равен 1.
2. Выборка данных: из таблицы cprrp100 взять данные, у которых плановая дата начала входит в границы дат начала и окончания планового периода номера документа и сценарий соответствует фактическому плану с последней датой, статус osta = 30.
Записать в таблицу lzrrp002 следующие данные: тип заказа, код изделия, объем заказа, склад назначения, плановик. Тип заказа – type является ключевым полем. Т.е. если type = 5 (запланированные заказы на закупку), то доступно поле cplb – плановик (закупщик).
3. Сделать посуммирование количества quan – объема заказа по коду изделия – item.
4. Формирование серии для производственных заказов. Из таблицы cprpd100 по плановой еденице plni взять из поля cwar – склад по умолчанию первые три символа, кроме записей: у которых cprpd100.cwar = 021ГИ, cprpd100.plni начинается с 6\ и 8\ — для них серия 9100; у которых cprpd100.cwar = 020ГИ, cprpd100.plni начинается с 6\ и 8\ — для них серия 9000.
5. Формирование типа и серии для закупок. Тип заказа: S01 для всех. Серия заказа на закупку: при условии cprpd100.plni = tcibd001.item в таблице tcibd001 из поля tcibd001.ctyp взять последние два символа.
На форме сеанса должен осуществляться выбор поля: при выборе «Производство» доступен диапазон складов, при выборе «Закупка» доступно поле плановик, а также поле «Дата окончания стр. заказа.»
3.4 Разработка программы «Формирование многострочного складского заказа» lzrrp9200m000.
Сеанс служит для передачи заказов (запланированные заказы на распределение) на уровень исполнения (в Управление запасами) и для записи этих заказов в таблицу по хранению плановых данных. Перед тем, как запустить этот сеанс, необходимо Подтвердить запланированные заказы на период, за который их необходимо передать. Подтверждение выполняется через стандартный сеанс. При этом запланированные заказы меняют свой статус с «Запланированного» на «Подтверждённый».
Еще пока в разработке
3.5 Разработка программы «Отчет по плановым заказам» lzrrp0401m000.
Данный сеанс предназначен для выдачи месячного отчёта по плановым заказам в системе BAAN — 6. Сеанс предназначен для подразделения ДПЛ.
Таблица плана рассчитывается и отражается в сеансе по месяцам. Для просмотра информации по конкретному месяцу надо смотреть расчёт с номером документа, соответствующему номеру месяца.
Необходимо иметь в виду, что фактический план формируется при передаче плановых заказов на уровень исполнения (т.е. в модули Производство, Закупки и Запасы) с накоплением за месяц.
Плановые заказы на распределение в исходном плане (план на начало месяца) не просматриваются, т.к. они могут формироваться только после передачи запланированных производственных заказов в Производство. В связи с тем, что запланированные производственные заказы передаются на неделю, то и заказы на распределение тоже сформированы только на неделю. Поэтому запланированные заказы на распределение можно просмотреть только в фактическом плане (план на конец месяца).
Необходимо помнить, что план рассчитывается с учётом остатков на складах, резервного запаса и наличия уже существующих заказов в системе.
На форме сеанса должен осуществляться выбор номера документа (с выходом на сеанс lzrrp0101m000), если выбран тип – запланированный заказ на распределение, то цеха задаются по диапазону, в остальных случаях возможностьб выбора одного цеха.
Для отображения информации в доступном и понятном виде необходимо сформировать шаблон отчета в прогшраммном приложении «Excel».
Алгоритм работы:
1. По номеру документа, заданному на форме, найти записи в таблице lzrrp002 с аналогичным номером ndoc. Если в поле «Изменения» выбрано значение «Да», то сравниваются записи по двум документам: если номер документа ndoc = ФГГММХХХ, то сравниваются записи с соответствующим му ИГГММХХХ и наоборот.
2. По типу заказа найти в таблице lzrrp002 записи если: запланированный заказ на распределение, то lzrrp002.type = 30; запланированный производственный заказ, то lzrrp002.type = 4; запланированный заказ на закупку, то lzrrp002.type = 5.
3. Найти в таблице lzrrp002 изделия – item, имеющим соответствующие заданным значениям lzrrp002.dwar (для всех типов) и lzrrp002.suwa (только если type = 30 – запланированные заказы на распределение) и занести в отчет.
3.1 Если в поле «Изменения» выбрано значение «Да» и в поле «№ документа» значение ФГГММХХХ, то в отчете в колокнку «Количество» заносятся отклонения либо с «+» либо с «-»: lzrrp002.quan (при lzrrp002.ndoc = ФГГММХХХ) — lzrrp002.quan (при lzrrp002.ndoc = ИГГММХХХ). Если в поле «Изменения» выбрано значение «Да» и в поле «№ документа» значение ИГГММХХХ, то в отчете в колокнку «Количество» заносятся отклонения либо с «+» либо с «-»: lzrrp002.quan (при lzrrp002.ndoc = ИГГММХХХ) — lzrrp002.quan (при lzrrp002.ndoc = ФГГММХХХ).
На рисунке представлена расшифровка отчета.
4. РАСЧЕТ ТРЕБУЕМОГО ПОКАЗАТЕЛЯ НАДЕЖНОСТИ.
Расчет надежности программного обеспечения при дипломном проектировании является прогностическим. Прогнозирование уровня надежности ПО при этом производится только по внезапным отказам при известных вероятностных характеристиках входных данных. Прогностический расчет позволяет предсказать возможные характеристики надежности и разработать стратегию информационного обслуживания ПО в эксплуатации.
Целью расчета надежности ПО является:
1. сравнение вариантов, реализация ПО и выбор варианта оптимальных входных данных, в т.ч. выработка рекомендаций по устойчивости функционирования ПО, т.е. с помощью введения различных форм избыточности, позволяющих иметь дублирующие модули программ, альтернативные программы для одних и тех же задач, осуществлять контроль за процессом исполнения программ.
2. выбор оптимальных режимов работы ПО. Расчет производится на основе информации о вероятности R(n) безотказного выполнения n – прогонов программы.
Понятие отказа системы.
Основными причинами, вызывающими нарушения нормального функционирования ПО, являются:
— ошибки, скрытые в самой программе;
— искажение входной информации;
— неверные действия пользователя;
— неисправность аппаратных средств ИС, на которой реализуется вычислительный процесс.
Ошибки, скрытые в программе. При разработке сложного ПО возможно возникновение ошибок, которые не всегда удается обнаружить и ликвидировать в процессе отладки. В силу этого в программах остается некоторое количество скрытых ошибок. Они являются причиной неверного функционирования этих программ.
Искажение входной информации. Указанная причина вызывает нарушение функционирования ПО, когда входные данные не попадают в допустимую область значения переменных. В этом случае возникает несоответствие между исходной информацией и возможностями программы.
Неверные действия пользователя связаны с неправильной интерпретацией сообщений, с неправильными действиями пользователя при работе в диалоговом режиме. Часто эти ошибки являются следствием некачественной программной документацией.
Неисправность аппаратных средств ИС. Эти неисправности оказывают определенное влияние на характеристики надежности ПО. Появление отказов или сбои в работе аппаратуры приводят к нарушению хода обработки информации и, как следствие, могут искажать как исходные данные, так и саму программу.
Следствием появления ошибок в программе является ее отказ. Последствия отказов ПО можно разделить на:
— полное прекращение выполнения функций программы;
— кратковременное нарушение хода обработки информации в ИС.
Степень серьезности последствий отказов ПО оценивается соотношением между временем восстановления программы после отказа и динамическими характеристиками объектов, использующих результаты работы этой программы.
Исходные данные для расчета:
1) Требуемое значение показателя надежности программы (вероятности безотказной работы программы) RТЗ(n) ≥ 0,997 при n ≥ 100 , где n – число прогонов программы.
2) Разработанная в данном дипломном проекте программа представлена на листах…………..
3) Информация о наборах входных данных программы (см. рисунок …………..).
Оценка надежности программы по числу прогонов (модель Нельсона)
В такой модели за показатель надежности программ принимается показатель R(n) безотказного выполнения n прогонов программы. Вероятность того, что j-ый прогон закончится отказом
,
где Pji – вероятность выбора i-ого набора входных данных при j-ом прогоне из некоторой последовательности прогонов;
yi – «динамическая переменная», принимающая значение 0, если прогон при i-ом наборе входных данных является успешным, и 1, если прогон закончился отказом;
N – число возможных наборов входных данных.
Вероятность появления i-ого набора входных данных Pi в эксплуатацию (экспертная оценка) представлена на рисунке 1.
Pi
0,001
1 2 3 4 N=103 i-номер наборов входных данных
Рисунок — Вероятность появления i-ого набора входных данных
Отработка программы мною была завершена и в процессе последующего тестирования программы мною проверено n = 100 прогонов программы, при этом обнаружено 2 отказа программы.
Первый отказ программы состоял в появлении сбоя при i = 2 наборе и 59 прогоне программы. Второй отказ проявился в остановке программы при i = 998 наборе и 76 прогоне.
Q59 = Р2 ∙ 1 = 0,001;
Q76 = Р998 ∙ 1 = 0,001.
Для n = 100
Таким образом, прогностический расчет надежности по модели Нельсона позволяет оценить надежность моей программы R(n) = 0,998, что соответствует требованиям ТЗ RТЗ(n) ≥ 0,997 при n ≥ 100.
5. ЭКОНОМИЧЕСКАЯ ЧАСТЬ.
Расчет себестоимости объекта, услуги, работы.
В экономической части дипломного проекта приведен поэтапный расчет стоимости (цены) проекно – конструкторской работы.
Оценка проводится методом расчета полных издержек с использованием нормативных и законодательных документов в части ценообразования по состоянию на 15 апреля 2010 года.
5.1 Расчет проектно-конструкторских затрат
5.1.1 Материалы и ПКИ
Затраты по статье «Материалы и ПКИ» рассчитаны исходя из потребностей на сырье и материалы, покупные изделия и полуфабрикаты, вспомогательные материалы, комплектующие изделия, пакеты прикладных программ, дискеты, ватман и др. по цене приобретения без НДС.
Расчет затрат на материалы и ПКИ приведен в таблице .
Таблица 8 — «Расчет затрат на материалы и ПКИ»
Наименование
материалов, ПКИ
и других
материальных ресурсов Ед.
изм. Количество Цена единицы, руб.
(без НДС) Сумма,
руб.
Обоснование
1 2 3 4 5 6
Флэш — карта шт. 1 254,24 254,24 Прайс лист
Всего 254,24
5.1.2 Расходы на оплату труда
Расходы на оплату труда определены исходя из среднемесячного размера расходов на оплату труда одного работника и трудоемкости работ. С учетом премии и территориального коэффициента среднемесячный размер расходов на оплату труда одного работника составит 9177 рублей.
Продолжительность и трудоемкость проводимых работ определяется в соответствии с календарным планом, приведенном в таблице.
Таблица 9 – «Календарный план проведения работ»
№ п.п Наименование этапов дипломного проекта (работы) Срок выполнения Трудоемкость (чел\час)
начало окончание
1 Получение и анализ задания на разработку 01.02.10 08.02.10 48
2 Подбор, изучение научно-технической литературы, подготовка материалов и справочных данных 09.02.10 16.02.10 48
3 Разработка структурной схемы программного комплекса 17.02.10 03.03.10 88
4 Разработка и написание постановки задачи 04.03.10 12.03.10 48
5 Создание программы «Создание таблицы хранения плановых данных» в КИСУП — BAAN VI и его тестирование 15.03.10 29.03.10 88
6 Создание программы «По формированию при передаче из планирования многостр. Склад. заказа» в КИСУП — BAAN VI и его тестирование 30.03.10 13.04.10 88
7 Создание программы «Отчет по плановым заказам» в КИСУП — BAAN VI и его тестирование 14.04.10 28.04.10 88
8 Технико-экономическое обоснование стоимости разработки 29.04.10 04.05.10 24
9 Обоснование раздела «Безопасность жизнедеятельности» 05.05.10 07.05.10 24
10 Обоснование раздела «Надежность» 11.05.10 13.05.10 24
10 Анализ разработки, выводы и оформление проекта 14.05.10 18.05.10 16
Итого 584
При среднем количестве часов в месяц в 2010 году — 165,6 часов в месяц продолжительность работ в месяцах будет составлять 3,5 месяца (584/165,6).
Полные расходы на оплату труда приведены в таблице 15.
Таблица 10 – «Расчет расходов на оплату труда»
Сроки Продолжительность (мес.) Категория работающих ИТР и служащие
Начало Окончание Кол-во участников (чел.) Трудоемкость (чел./мес.) Среднемесячный размер расходов на оплату труда одного человека в месяц Расходы на оплату труда
2 3 4 5 6 7 8
01.02.2010 18.05.2010 3,5 1 3,5 9177,00 32119,50
5.1.3 Отчисления на социальные нужды
В соответствии с Налоговым кодексом РФ (часть вторая) установлен единый социальный налог по ставке 26% от расходов на оплату труда.
Кроме того, предприятие производит отчисления на обязательное социальное страхование от несчастных случаев на производстве и профессиональных заболеваний.
Для ОАО «АЗ «Урал» размер страхового тарифа, указанный в страховом свидетельстве равен 1%.
Таким образом, суммарный тариф отчислений на социальные нужды составит для ГРЦ 26,0% + 1 % = 27 % от суммы расходов на оплату труда.
Размер отчислений на социальные нужды составит:
32119,50 * 0,27 = 8672,27 рублей.
5.1.4 Командировочные расходы
Нормы возмещения командировочных расходов:
оплата найма жилого помещения — по фактическим расходам, подтвержденным соответствующими документами, но не более 550 руб. в сутки, а при отсутствии документов — в размере 12 руб. в сутки;
плата суточных — 200 руб. за каждый день нахождения в командировке;
оплата проезда — по представленным проездным документам.
В нашем случае затраты отсутствуют.
5.1.5 Накладные расходы
Сюда относятся:
расходы на содержание аппарата работников управления;
содержание зданий, сооружений, инвентаря общехозяйственного назначения;
конторские, типографские, почтово-телеграфные и телефонные расходы;
плата (или содержание) за пожарную, военизированную и сторожевую охрану;
плата за аренду в случае аренды отдельных объектов основных производственных фондов;
оплата услуг связи, вычислительных центров, банков;
оплата работ по сертификации продукции;
затраты на обеспечение нормальных условий труда и техники безопасности.
Накладные расходы определяются индивидуально по каждому предприятию и зависят от вида деятельности и составляют 155 % от расходов на оплату труда.
Накладные расходы = 32119,50 * 1,55 = 49785,23 рублей.
5.1.6 Затраты по работам, выполняемым сторонними организациями и предприятиями
Затраты сторонних организаций обосновываются расчетом договорных цен выполняемых ими работ и сопровождаются процессом согласования с учетом их отраслевых особенностей.
В нашем случае затраты отсутствуют.
5.1.7 Структура цены
Себестоимость собственных работ составляет сумму всех вышеперечисленных статей за исключением статьи «Затраты по работам, выполняемым сторонними организациями».
Плановая прибыль определяется в размере 18 % от себестоимости собственных работ.
Плановая структура цены представлена в таблице 16.
Таблица 11 – «Плановая структура цены»
Наименование статей затрат Всего Доля в полной себестоимости (в %)
Материалы и ПКИ 254,24 0,24
Расходы на оплату труда 32119,50 32,12
Отчисления на социальные нужды(26%+1%=27%) от расходов на оплату труда 8672,27 8,67
Прочие прямые расходы (расходы на служебные командировки) 0,00 0,00
Накладные расходы (155% от расходов на оплату труда) 49785,23 49,78
Итого себестоимость собственных работ 90381,24
Затраты по работам, выполняемым сторонними организациями и предприятиями 0,00 0,00
Итого полная себестоимость 90381,24 100,00
Прибыль 5% от себестоимости собственных работ 4519,10
Цена 94900,34
НДС 18% 17082,10
Цена реализации (Цена + НДС) 111982,40
Цена на проектно-конструкторскую работу по теме «Модуль планирования на АЗ «Урал» составила 111982,40 рублей.
5.2 Расчет ожидаемого годового экономического эффекта от внедрения
Разрабатываемая в рамках данного дипломного проекта задача обеспечивает получение достоверных оперативных запланированных данных, необходимых для эффективного управления всего завода. Если данные о запланированной номенклатуре будут не точны или не будут получены в срок, то это может привести искажению финансовых результатов предприятия, к риску принятия необоснованных решений руководством на основе недостоверных отчетов о себестоимости.
Ожидаемый экономический эффект от внедрения задачи:
1 Возможность эффективно управлять экономическими показателями цехов на любом уровне изготовления изделия, возможность пооперационного контроля выполнения производственного заказа.
2 Использование средств поцехового контроля позволяет обеспечить устойчивое снижение уровня незавершенного производства. Планируемое годовое снижение НЗП составляет 20-30% (смотри рисунок 12). Не малая роль в этом процессе принадлежит представленным в данной дипломной работе программным средствам.
3 Снижение времени выполнения программы по сравнению с аналогичными расчётами в BAAN IV в 7,5 раз. Снижение происходит за счёт оптимизации алгоритма задачи.
В BAAN IV производился расчет чистого подетального плана, который не учитывал многих важных параметров производства, таких как производственные мощности, уровень незавершенного производства, производственные календари, уровень детализации плана. Среднее время выполнения программы при этом составляет 30 минут на один цех.
В BAAN VI имеется возможность производить расчет как долгосрочного (1 год), так и краткосрочного планирования (1 неделя), учитывая множество факторов, влияющих на итоговый результат. Время расчёта составляет 1 час 25 минуты, а время работы сеанса отчёта приблизительно равно одной минуте.
Расчет ведется исходя из стоимости работы одного часа в системе BAAN — 1408 рублей. Эта цифра берется из суммы по оплате компании дилеру «GMCS» за организацию технической поддержки и за оплату лицензии за использование.
Стоимость одного расчёта в BAAN IV:
30 минут * 28 = 840 минут (14 часов)
14*1408 = 19712 рублей.
Стоимость одного расчёта в BAAN VI:
1 час 25 минут + 1*28 = 1 час 53 минуты (1,9 часа)
1,9 * 1408 = 2675 рублей
Прямая годовая экономия при условии проведения не менее 24 расчётов в год составит:
(19712-2675)*24 = 408 888 рублей.
6. БЕЗОПАСНОСТЬ ЖИЗНЕДЕЯТЕЛЬНОСТИ
Наука о безопасности жизнедеятельности исследует мир опасностей, действующих в среде обитания человека, разрабатывает системы и методы защиты человека от опасностей. В современном понимании безопасность жизнедеятельности изучает опасности производственной, бытовой и городской среды, как в условиях повседневной жизни, так и при возникновении чрезвычайных ситуаций. Главная задача науки о безопасности жизнедеятельности – превентивный анализ источников и причин возникновения опасностей, прогнозирование и оценка их воздействия в пространстве и во времени.
В данном дипломном проекте будут рассмотрены вопросы, касающиеся безопасности работы оператора видеодисплейного терминала (далее — ВДТ) и персональной электронно-вычислительной машины (далее — ПЭВМ). Требования по обеспечению соответствующих условий труда регламентируются Санитарными правилами и нормами «Гигиенические требования к видеодисплейным терминалам, персональным электронно-вычислительным машинам и организации труда», утвержденным и введенным в действие Постановлением Госкомсанэпиднадзора России от 14 июля 1996 г. № 14 (СанПинН 2.2.2.542-96).
Условия труда работающих с ВДТ и ПЭВМ характеризуются возможностью воздействия на них следующих производственных факторов: шума, тепловыделений, вредных веществ, статического электричества, ионизирующих и неионизирующих излучений, недостаточной освещенности, параметров технического оборудования и рабочего места.
6.1 Нормирование производственного освещения
Естественное и искусственное освещение в помещениях для эксплуатации ВДТ и ПЭВМ регламентируется нормами СНиП 23-05-95 в зависимости от характера зрительной работы, системы и вида освещения, фона, контраста объекта с фоном. Помещение с компьютерами должно иметь естественное и искусственное освещение. Естественное освещение должно осуществляться через светопроёмы и обеспечивать коэффициент естественной освещенности (КЕО) не ниже 1,2 в зонах с устойчивым снежным покровом и не ниже 1,5 на остальной территории. Характеристика зрительной работы определяется наименьшим размером объекта различения. В зависимости от объекта различения все виды работ, связанные со зрительным напряжением делятся на восемь разрядов, которые в свою очередь в зависимости от фона и контраста объекта с фоном делятся на четыре подразряда. Важное место в комплексе мероприятий по созданию условий труда работающих с ВДТ и ПЭВМ, занимает создание оптимальной световой среды, т.е. рациональная организация естественного и искусственного освещения помещения и рабочих мест. Освещенность на поверхности стола в зоне размещения рабочего документа должна быть 300-500 лк. На рабочем месте необходимо обеспечить, возможно, большую равномерность яркости, исключая наличие ярких и блестящих предметов, для снижения монотонности в поле зрения рекомендуются отдельные пёстрые поверхности.
Для освещения рабочих мест рекомендуется применять комбинированное освещение. Для общего освещения используются в основном потолочные или встроенные светильники с люминесцентными лампами. Яркость должна быть не более 200 кд/м.
Местное освещение на рабочих местах обеспечивается светильниками, устанавливаемыми непосредственно на рабочем столе или на вертикальных панелях специального оборудования. Они должны иметь не просвечивающий отражатель и располагаться ниже или на уровне линии зрения операторов, чтобы не вызывать ослепления.
Общее освещение следует выполнять в виде сплошных или прерывистых линий светильников, расположенных сбоку от рабочих мест, параллельно линии зрения оператора при рядном расположении компьютеров. При периметральном расположении компьютеров линии светильников должны располагаться локализовано над рабочим столом ближе к его переднему краю, обращенному к оператору.
Следует ограничивать отраженную блесткость на рабочих поверхностях (экран, стол, клавиатура и д.р.) за счёт правильного выбора типов светильников, и расположения рабочих место по отношению к источникам естественного и искусственного освещения, при этом яркость бликов на экране ВДТ и ПЭВМ не должна превышать 40 кд/кв.м и яркость потолка при применении системы отраженного освещения не должна превышать 200 кд/кв.м.
Для внутренней отделки интерьера помещений с компьютерами должны использоваться диффузно-отражающие материалы с коэффициентом отражения для потолка 0,6-08; для стен — 0,5-0,6; для пола — 0,3-0,5.
6.2 Нормирование акустических колебаний и вибрации
Гигиеническое нормирование вибраций регламентируют параметры производственной вибрации и правила работы с виброопасными механизмами и оборудованием, ГОСТ 12.1.012-90. Нормируемые параметры шума на рабочих местах определены ГОСТ 12.1.003-83 Санитарными нормами СН 2.2.4/2.1.8.562-96.
Для снижения шума и вибрации в помещениях вычислительных центров, оборудование необходимо устанавливать на специальные фундаменты и амортизирующие прокладки, предусмотренные нормативными документами.
В помещении могут находится следующие источники шума: электродвигатели внутреннего вентилятора ЭВМ; работающие принтеры; работающие дисководы. Шум, производимый вентилятором можно классифицировать как постоянный, все остальные источника шума, как импульсные.
При выполнении основной работы на ВДТ и ПЭВМ (диспетчерские, операторские, расчетные кабины и посты управления, залы вычислительной техники и д.р.), во всех учебных и дошкольных помещениях с ВДТ и ПЭВМ уровень шума на рабочем месте не должен превышать 50 дБА.
Нормируемые уровни шума обеспечиваются применением малошумного оборудования, использованием звукопоглощающих материалов и подвесных акустических потолков.
Снизить уровень шума в помещениях с ВДТ и ПЭВМ можно использованием звукопоглощающих материалов с максимальными коэффициентами звукопоглощения в области частот 63-8000 Гц для отделки помещений (разрешенных органами и учреждениями Госсанэпиднадзора России), подтвержденных специальными акустическими расчетами.
Дополнительным звукопоглощением служат однотонные занавески из плотной ткани, гармонирующие с окраской стен и подвешенные в складку на расстоянии 15-20 см. от ограждения. Ширина занавески должна быть в два раза больше ширины окна.
Производственные помещения, в которых для работы используются преимущественно компьютеры (диспетчерские, операторские, расчётные и другие) не должны граничить с помещениями, в которых уровни шума и вибрации превышают нормируемые значения (механические цеха, мастерские и т.п.)
6.3 Нормирование параметров микроклимата
В производственных помещениях, в которых работа на ВДТ и ПЭВМ является основной (диспетчерские, операторские, расчётные кабины, посты управления, залы вычислительной техники и д.р.), должны обеспечиваться оптимальные параметры микроклимата в соответствии с СанПинН: 2.2.2.542-96 «Гигиенические требования к ВДТ и ПЭВМ. Организация работы». В таблице № 17 представлены оптимальные нормы микроклимата для помещений с ВДТ и ПЭВМ.
Таблица 12 – «Оптимальные нормы микроклимата для помещений с ВДТ и ПЭВМ»
Период года Категория работ Температура воздуха, °С Относительная влажность воздуха, % Скорость движения воздуха, м/с
Холодный Лёгкая – 1а
Лёгкая – 16 22-24
21-23 40-60
40-60 0,1
0,1
Теплый Лёгкая – 1а
Лёгкая – 16 23-25
22-24 40-60
40-60 0,1
0,2
Примечания:
1 1а – работы, производимые сидя и не требующие физического напряжения (расход энергии до 120 ккал/ч);
2 16 – работы, производимые сидя, стоя или связанные с ходьбой и сопровождающиеся некоторым физическим напряжением (расход энергии составляет от 120 до 150 ккал/час). В помещениях с избытками тепла необходимо предусматривать регулирование подачи теплоносителя для соблюдения нормативных параметров микроклимата, представленных в таблице .
В соответствии с СНиП II-68-78 площадь кабинетов вычислительной техники с настольными вычислительными машинами должна удовлетворять условию – не менее 6 кв.м. на одно рабочее место. Выполнение данных требований обеспечит поддержание в помещении оптимального значения влажности и состава воздуха.
Человек постоянно находится в процессе теплового воздействия окружающей среды. При благоприятных условиях труда характеристика метеорологических показателей в производственных помещениях на рабочем месте следующая: температура от 20 до 23 градусов при преимущественно умственной или лёгкой мышечной работе, допустимая температура от 19°С до 21°С. Влажность воздуха оказывает большое влияние на терморегуляцию организма. Оптимальная величина относительной влажности составляет 40-60%. Движение воздуха в помещении является важным фактором, влияющем на тепловое самочувствие человека. Скорость движения воздуха не должна превышать 0,1 м/с.
Для повышения влажности воздуха в помещениях с ВДТ и ПЭВМ, следует применять увлажнители воздуха, заправляемые ежедневно дистиллированной или прокипяченной водой.
Помещение с компьютерами должно оборудоваться системами отопления, кондиционирования воздуха или эффективной приточно-вытяжной вентиляцией. Расчет воздухообмена следует проводить по теплоизбыткам от машин, людей, солнечной радиации и искусственного освещения.
6.4 Нормирование параметров электромагнитного излучения
Нормирование параметров электромагнитного излучения регламентируются «Санитарными нормами и правилами выполнения работ в условиях воздействия электрических полей промышленной частоты» и осуществляются по предельно допустимым уровням напряженности электрического и магнитного полей частотой 50 Гц в зависимости от времени пребывания в нем. Средства защиты от статического электричества приведены в ГОСТ 12.4.124-83.
Основные мероприятия, применяемые для защиты от статического электричества производственного происхождения, включают методы, исключающие или уменьшающие интенсивность генерации зарядов, и методы, устраняющие образующие заряды. Интенсивность генерации зарядов можно уменьшить соответствующим подбором пар трения или смешиванием материалов таким образом, что в результате трения один из смешанных материалов наводит заряд одного знака, а другой – другого. В настоящее время создан комбинированный материал из нейлона и дакрона, обеспечивающий защиту от статического электричества по этому принципу.
Для предотвращения образования и защиты от статического электричества необходимо использовать нейтрализаторы и увлажнители, а полы должны иметь антистатическое покрытие. Допустимые уровни напряженности электрических полей не должны превышать 20 кВ/м в течение одного часа.
В целях защиты от электромагнитных излучений следует обязательно использовать защитные экраны (фильтры), представляющие собой оптически прозрачную панель, с нанесённым на неё тонким проводящим слоем. Кроме этого, защитные фильтры помогают устранить блики на экране, увеличить контрастность и понизить яркость экрана.
6.5 Требования к организации рабочего места оператора ВДТ и ПЭВМ
Так как при работе на компьютере основная нагрузка ложится на глаза, поэтому большие требования предъявляются к видеотерминальным устройствам (экранам). Предпочтительным является плоский экран, позволяющий избежать наличия на нём ярких пятен за счёт отражения световых потоков. Особенно важен цвет экрана. Он должен быть нейтральным. Допустимы ненасыщенные светло-зелёные, жёлто-зелёные, жёлто-оранжевые, жёлто-коричневые тона.
Оптимальная высота расположения экрана должна соответствовать направлению взгляда оператора в секторе 5-35° по отношению к горизонтали. Большой наклон экрана может привести к появлению бликов от светильников. При работе на ЭВМ взгляд должен падать на экран под прямым углом и отклоняться от горизонтали на 20%. Размер экрана должен быть не менее 31 см. по диагонали, а высота символов на экране – не менее 3,8 мм, при этом расстояние от глаз оператора до экрана должно быть в пределах 40-80 см.
Клавиатура дисплея не должна быть жёстко связана с монитором. Она должна располагаться на расстоянии 600-700 мм. Наклон клавиатуры должен находиться в пределах 10-15°. Клавиатура располагается на поверхности стола на расстоянии 100-300 мм от края.
Видеомонитор должен быть оборудован поворотной площадкой, позволяющей перемещать ВДТ в горизонтальной и вертикальной плоскостях в пределах 130-220 мм и изменять угол наклона экрана на 10-15°.
При работе с текстовой информацией (в режиме ввода данных, редактирования текста и чтения с экрана ВДТ) наиболее физиологичным является сочетание чёрных знаков на светлом (белом фоне).
Требования к оборудованию рабочих мест:
1 рабочий стол должен регулироваться по высоте в пределах 680-800 мм;
2 оптимальные размеры рабочей поверхности столешницы находятся в пределах 1400*1000 мм. Под столешницей рабочего стола должно быть свободное пространство для ног с размером по высоте не менее 600 мм, по ширине 500 мм, по глубине 650 мм;
3 на поверхности рабочего стола для документов необходимо предусматривать размещение специальной подставки, расстояние которой от глаз должно быть аналогично расстоянию от глаз до клавиатуры;
4 рабочее кресло должно обеспечивать регуляцию высоты сидений и спинки; его конструкция так же должна предусматривать изменение угла наклона спинки. Рабочее кресло должно иметь подлокотники. Высота поверхности сиденья должна регулироваться в пределах 400-500 мм. Ширина и глубина сиденья должна составлять не менее 400 мм. Высота опорной поверхности спинки должна быть не менее 300 мм, ширина не мене 380 мм.
Расположение рабочих мест с ВДТ и ПЭВМ для взрослых пользователей в подвальных помещениях не допускается, для всех учебных заведений не допускается в цокольных и подвальных помещениях. Площадь на одно рабочее место с ВДТ и ПЭВМ должно составлять не менее 6,0 м2, а объем не менее 20,0 м3.
Поверхность пола в помещениях эксплуатации компьютеров должна быть ровной, без выбоин, не скользкой, удобной для очистки и влажной уборки, обладать антистатическими свойствами.
В зависимости от специфики производства, напряженности труда устанавливается количество перерывов на отдых, их длительность и распределение в течение рабочей смены. В соответствии с особенностями трудовой деятельности работникам вычислительных центров должны быть дополнительно введены 2-3 регламентированных перерыва длительностью 10 минут каждый. При восьмичасовой смене дополнительные регламентированные перерывы должны вводиться через 3 часа работы и за 2 часа до её окончания.
Режим труда и отдыха операторов, работающих с ЭВМ, должен быть следующим:
через каждый час интенсивной работы необходимо устраивать пятнадцатиминутный перерыв;
при менее интенсивной работе – через каждые два часа;
выполнение один – два раза в смену пятиминутного комплекса производственной гимнастики.
С целью снижения нервно-психологического, зрительного и мышечного напряжения, предупреждения переутомления необходимо проводить сеансы психофизической разгрузки.
6.6 Электробезопасность
Электробезопасность обеспечивается рядом условий. При этом необходимо учитывать требования нормативной документации. Так, например, согласно ГОСТ 12.1.038-82, при выборе и расчёте технических устройств и других средств защиты, учитываются три основных параметра: сила тока, протекающего через тело человека, напряжение прикосновения и длительность протекания тока. Межотраслевые правила по охране труда при эксплуатации электроустановок (ПОТ Р М-016-201; РД 153-34.0-03.150-00) регулируют такие вопросы, как требование к персоналу, оформление документов, испытания, измерения и д.р.; повышение опасности и т.п.; применять технические средства защиты от электротока:
а) защитное заземление. Корпус прибора заземляется проводником с сопротивлением менее 0,4 Ом. В случае прикосновения человека к поврежденному корпусу, он не получит удар электротоком, так как сопротивление человека намного больше, чем заземляющего проводника;
б) зануление с заземлением нулевого провода генератора. В этом случае корпус прибора соединён с заземлённым нулевым проводом, имеющим сопротивление менее 4 Ом. При замыкании фазы на корпус произойдёт прерывание электросети, т.к. сгорят предохранители;
следить за состоянием проводников и розеток в рабочих и санитарно-бытовых помещениях.
Учитывая большую потенциальную опасность электрического тока в жизни человека, необходима комплексная защита с периодическим обучение (инструктированием) персонала.
6.7 Пожарная безопасность
Общие требования к пожарной безопасности нормируются ГОСТ 12.1.004-91. Возможность возникновения и распространения пожаров в зданиях и сооружениях зависит от того, из каких материалов (конструкций) они выполнены, а также от размеров зданий и их расположения.
По взрывопожарной и пожарной опасности помещения для работы операторов относятся к категориям:
Категория А (взрывоопасные) – горючие газы, ЛВЖ с температурой вспышки ниже 28°С;
Категория Б (взрыво и пожароопасные) – горючие пыли, волокна, ЛВЖ с температурой вспышки ниже 28°С;
Помещение должно быть в обязательном порядке оборудовано ручными средствами пожаротушения. К ним относят:
Оборудование противопожарных щитов
Пожарные краны
Ручные огнетушители
Для тушения пожара в данных помещениях должны применяться порошковые и химические пенные огнетушители.
Персонал, работающий в помещении должен знать последовательность действий в случае пожара, а так же уметь пользоваться ручными средствами пожаротушения.
Выводы: в главе были рассмотрены возможные поражающие, опасные и вредные факторы производственной среды, также были описаны методы и средства обеспечения БЖД работников, основные мероприятия по электробезопасности, охране ОС, предупреждению пожаров и аварий в помещении и ликвидации последствий ЧС. Работники ВЦ — операторы ЭВМ подвергаются воздействию физически опасных и вредных производственных факторов таких, как повышенный уровень шумов, повышенная температура внешней среды, отсутствие или недостаток естественного света, недостаточная освещенность рабочей зоны, электрический ток, статическое электричество и др. Определились пути решения этих проблем, чтобы обеспечить безопасные условия труда для работников BЦ. Особое внимание уделяется пожарной безопасности, так как пожары в ВЦ сопряжены с опасностью для человеческой жизни и большими материальными потерями.
ЗАКЛЮЧЕНИЕ.
В данной дипломной работе описана разработка программного модуля «Планирование». Данная система автоматизировала процедуру расчета плана автомобилей, а точнее обеспечила потребителя необходимым программным модулем, позволяющим с легкостью рассчитывать план, сократив сроки по выдаче заключений. Для подготовки пользователя к полноценной эксплуатации системы не требуется много времени и глубоких знаний, так как система обеспечена удобным WEB-интерфейсом, сопровождается инструкцией пользователю, проста в понимании.
Критерием оценки достижения целей при разработке модуля должна служить такая ситуация в производственных подразделениях, которая позволяла бы в автоматизированном режиме найти и обработать требуемую для расчета информацию в минимальные сроки.
Модуль отвечает следующим характеристикам качества:
— простота, надежность и эффективность использования;
— удобство использования, учет человеческого фактора;
— модифицируемость;
— мобильность;
— экономичность использования ресурсов.
Приложение 1. Листинг программы:
|******************************************************************************
|* lzrrp0101 0 VRC B61C a gaz
|* Работа с таблицей «Справочник документов»
|* Ширяева Ольга
|* 2009-06-18
|******************************************************************************
|* Main table lzrrp001 Справочник документов, Form Type 1
|******************************************************************************
|****************************** declaration section ***************************
declaration:
table tlzrrp001 | Справочник документов
|****************************** program section ********************************
|****************************** group section **********************************
lzrrp0201
declaration:
#pragma used dll olzcmgdlldbf
table tlzrrp002 | История планирования
table tlzrrp001
table tcprpd000
table tcprrp100
extern domain tctbnm ndoc
long yy, mm, dd
group.1:
init.group:
get.screen.defaults()
functions:
function extern main.table()
{ long count
| db.retry.point()
count=0
select lzrrp002.*
from lzrrp002 for update
where lzrrp002._index1 = {:ndoc}
selectdo
db.delete(tlzrrp002, db.retry)
count = count+1
if count>100 then
count=0
commit.transaction()
endif
selectempty
endselect
commit.transaction()
count = 0
select lzrrp001.*
from lzrrp001
where lzrrp001._index1 = {:ndoc}
selectdo
num.to.date(lzrrp001.bdat, yy, mm, dd)
lzrrp001.bdat = date.to.utc(yy, mm, dd, 0, 0, 0)
num.to.date(lzrrp001.edat, yy, mm, dd)
lzrrp001.edat = date.to.utc(yy, mm, dd, 23, 59, 59)
select cprpd000.indt, cprpd000.aplc
from cprpd000
where cprpd000.indt<=:lzrrp001.edat
order by cprpd000._index1 desc
as set with 1 rows
selectdo
select cprrp100.plnc, cprrp100.type, cprrp100.item, cprrp100.suwa,
max(cprrp100.dwar):cprrp100.dwar, max(cprrp100.cplb):cprrp100.cplb, sum(cprrp100.quan):cprrp100.quan
from cprrp100
where cprrp100.plnc = :cprpd000.aplc and cprrp100.psdt between :lzrrp001.bdat and :lzrrp001.edat
and cprrp100.type in (4,5,30)
group by cprrp100.plnc, cprrp100.type, cprrp100.item, cprrp100.suwa
order by cprrp100.plnc, cprrp100.type, cprrp100.item, cprrp100.suwa
selectdo
lzrrp002.ndoc = lzrrp001.ndoc
lzrrp002.type = cprrp100.type
lzrrp002.item = cprrp100.item(4;47)
lzrrp002.quan = cprrp100.quan
lzrrp002.dwar = cprrp100.dwar
lzrrp002.suwa = «»
lzrrp002.cplb = «»
if cprrp100.type = ltoe(30) then
lzrrp002.suwa = cprrp100.suwa
endif
if cprrp100.type = ltoe(5) then
lzrrp002.cplb = cprrp100.cplb
endif
db.insert(tlzrrp002, db.retry)
count=count+1
if count>100 then
count=0
commit.transaction()
endif
selectempty
endselect
selectempty
endselect
selectempty
endselect
commit.transaction()
message(win.to.iso(«УЮвЮТЮ»))
}
lzrrp0202
declaration:
#pragma used dll olzcmgdlldbf
table tlzrrp002 | История планирования
table tlzrrp001
table tcprpd000
table tcprrp100
table tcprpd100
table ttcibd001
extern domain tctbnm ndoc
long yy, mm, dd, p
extern domain tcmcs.str256 msg.out, error.code, filename, file_afs
extern domain lzrrp0202_01 vybor
extern domain tccwar cwar.f, cwar.t
extern domain tcemno planner
extern domain tcdate finish.date.f, finish.date.t
before.program:
seq.saveas.dialog.local («lzrrp0202_» & NUM.TO.DATE$(date.num(), 3)&».txt», «d:», «All Files(*.*)|*.*|Text Files(*.txt) Word documents(*.doc)|*.txt;*.doc», filename)
p = rpos(filename, «\»)
file_afs = filename(p+1; 100-p)
filename = filename(1; p)
group.1:
init.group:
inputfield.visible( «cwar.f» )
inputfield.visible( «cwar.t» )
inputfield.invisible( «planner» )
inputfield.invisible( «finish.date.f» )
inputfield.invisible( «finish.date.t» )
inputfield.invisible( «finish.date.f.time» )
inputfield.invisible( «finish.date.t.time» )
get.screen.defaults()
choice.print.data:
on.choice:
if rprt_open() then
if vybor = lzrrp0202_01.prod then
read.main.table_prod()
else
read.main.table_purch()
endif
rprt_close()
else
choice.again()
endif
field.vybor:
when.field.changes:
if vybor = lzrrp0202_01.prod then
inputfield.visible( «cwar.f» )
inputfield.visible( «cwar.t» )
inputfield.invisible( «planner» )
inputfield.invisible( «finish.date.f» )
inputfield.invisible( «finish.date.t» )
inputfield.invisible( «finish.date.f.time» )
inputfield.invisible( «finish.date.t.time» )
else
inputfield.invisible( «cwar.f» )
inputfield.invisible( «cwar.t» )
inputfield.visible( «planner» )
inputfield.visible( «finish.date.f» )
inputfield.visible( «finish.date.t» )
inputfield.visible( «finish.date.f.time» )
inputfield.visible( «finish.date.t.time» )
endif
field.cwar.f:
when.field.changes:
cwar.t = cwar.f
functions:
function extern main.table()
{
execute(print.data)
}
function read.main.table_prod()
{
long count,psdt.f, psdt.t, pfdt.f, pfdt.t
db.retry.point()
count=0
| select lzrrp002.*
| from lzrrp002 for update
| where lzrrp002._index1 = {:ndoc}
| selectdo
| db.delete(tlzrrp002, db.retry)
| count = count+1
| if count>100 then
| count=0
| commit.transaction()
| endif
| selectempty
| endselect
| commit.transaction()
count = 0
select lzrrp001.*
from lzrrp001
where lzrrp001._index1 = {:ndoc}
selectdo
num.to.date(lzrrp001.bdat, yy, mm, dd)
lzrrp001.bdat = date.to.utc(yy, mm, dd, 0, 0, 0)
num.to.date(lzrrp001.edat, yy, mm, dd)
lzrrp001.edat = date.to.utc(yy, mm, dd, 23, 59, 59)
select cprpd000.indt, cprpd000.aplc
from cprpd000
| where cprpd000.indt<=:lzrrp001.edat
order by cprpd000._index1 desc
as set with 1 rows
selectdo
select cprrp100.plnc, cprrp100.type, cprrp100.item, min(cprrp100.psdt):psdt.f, max(cprrp100.psdt):psdt.t,
min(cprrp100.pfdt):pfdt.f, max(cprrp100.pfdt):pfdt.t,
max(cprrp100.dwar):cprrp100.dwar, max(cprrp100.cplb):cprrp100.cplb, sum(cprrp100.quan):cprrp100.quan
from cprrp100
where cprrp100.plnc = :cprpd000.aplc and cprrp100.psdt between :lzrrp001.bdat and :lzrrp001.edat
and cprrp100.pfdt between :finish.date.f and :finish.date.t
and cprrp100.type in (4,5) and cprrp100.osta = 30
and cprrp100.dwar between {:cwar.f} and {:cwar.t}
group by cprrp100.plnc, cprrp100.type, cprrp100.item|, cprrp100.psdt, cprrp100.pfdt
order by cprrp100.plnc, cprrp100.type, cprrp100.item|, cprrp100.psdt, cprrp100.pfdt
selectdo
stpapi.put.field(«cppat1210m000″,»prod.orders»,str$(1))
select cprpd100.*
from cprpd100
where cprpd100._index1 = {:cprrp100.item}
selectdo
selectempty
endselect
if trim$(cprpd100.cwar) = win.to.iso(«021УШ») and (cprpd100.plni(13;2) = «6\» or cprpd100.plni(13;2) = «8\») then
stpapi.put.field(«cppat1210m000″,»prod.ord.series»,»9100″)
else
if trim$(cprpd100.cwar) = win.to.iso(«020УШ») and (cprpd100.plni(13;2) = «6\» or cprpd100.plni(13;2) = «8\») then
stpapi.put.field(«cppat1210m000″,»prod.ord.series»,»9000″)
else
stpapi.put.field(«cppat1210m000″,»prod.ord.series»,win.to.iso(«Я»)& cprpd100.cwar(1;3))
endif
endif
stpapi.put.field(«cppat1210m000″,»cp.item.f.segment.1″,»»)
stpapi.put.field(«cppat1210m000″,»cp.item.f.segment.2″,»»)
stpapi.put.field(«cppat1210m000″,»cp.item.f.segment.3»,trim$(cprrp100.item))
stpapi.put.field(«cppat1210m000″,»cp.item.t.segment.1″,»»)
stpapi.put.field(«cppat1210m000″,»cp.item.t.segment.2″,»»)
stpapi.put.field(«cppat1210m000″,»cp.item.t.segment.3»,trim$(cprrp100.item))
stpapi.put.field(«cppat1210m000″,»cwar.f»,trim$(cprrp100.dwar))
stpapi.put.field(«cppat1210m000″,»cwar.t»,trim$(cprrp100.dwar))
stpapi.put.field(«cppat1210m000″,»planner.f»,trim$(cprrp100.cplb))
stpapi.put.field(«cppat1210m000″,»planner.t»,trim$(cprrp100.cplb))
stpapi.put.field(«cppat1210m000″,»start.date.f»,str$(psdt.f))
stpapi.put.field(«cppat1210m000″,»start.date.t»,str$(psdt.t))
stpapi.put.field(«cppat1210m000″,»finish.date.f»,str$(pfdt.f))
stpapi.put.field(«cppat1210m000″,»finish.date.t»,str$(pfdt.t))
stpapi.put.field(«cppat1210m000», «spool.fileout», file_afs)
stpapi.set.report(«cppat1210m000″,»rcppat121011000″,»ASCIT»,msg.out)
stpapi.form.command(«cppat1210m000″,5,»exec.cont.process»,msg.out)
if trim$(msg.out)<>»» then
msg.out = «cppat1210m000 » & » » & trim$(cprrp100.item)& » » &msg.out
rprt_send()
else
select lzrrp002.*
from lzrrp002 for update
where lzrrp002._index1 = {:lzrrp001.ndoc, :cprrp100.type, :cprrp100.item(4;47)}
selectdo
lzrrp002.quan = lzrrp002.quan + cprrp100.quan
db.update(tlzrrp002, db.retry)
count=count+1
if count>100 then
count=0
commit.transaction()
endif
selectempty
lzrrp002.ndoc = lzrrp001.ndoc
lzrrp002.type = cprrp100.type
lzrrp002.item = cprrp100.item(4;47)
lzrrp002.quan = cprrp100.quan
lzrrp002.dwar = cprrp100.dwar
lzrrp002.suwa = «»
| lzrrp002.cplb = «»
| if cprrp100.type = ltoe(5) then
lzrrp002.cplb = cprrp100.cplb
| endif
db.insert(tlzrrp002, db.retry)
count=count+1
if count>100 then
count=0
commit.transaction()
endif
endselect
endif
while true
error.code=stpapi.get.mess.code(«cppat1210m000»,msg.out)
If isspace(msg.out) Then
break
EndIF
msg.out = «cppat1210m000 » & » » & trim$(cprrp100.item)& » » &msg.out
rprt_send()
endwhile
stpapi.end.session(«cppat1210m000»)
server2client(file_afs, trim$(filename) & file_afs, false)
selectempty
endselect
selectempty
endselect
selectempty
endselect
commit.transaction()
| server2client(«filiout», «c:\fileout», 0)
message(win.to.iso(«УЮвЮТЮ»))
}
function read.main.table_purch()
{
long count,psdt.f, psdt.t, pfdt.f, pfdt.t
db.retry.point()
count=0
| select lzrrp002.*
| from lzrrp002 for update
| where lzrrp002._index1 = {:ndoc}
| selectdo
| db.delete(tlzrrp002, db.retry)
| count = count+1
| if count>100 then
| count=0
| commit.transaction()
| endif
| selectempty
| endselect
| commit.transaction()
count = 0
select lzrrp001.*
from lzrrp001
where lzrrp001._index1 = {:ndoc}
selectdo
num.to.date(lzrrp001.bdat, yy, mm, dd)
lzrrp001.bdat = date.to.utc(yy, mm, dd, 0, 0, 0)
num.to.date(lzrrp001.edat, yy, mm, dd)
lzrrp001.edat = date.to.utc(yy, mm, dd, 23, 59, 59)
select cprpd000.indt, cprpd000.aplc
from cprpd000
| where cprpd000.indt<=:lzrrp001.edat
order by cprpd000._index1 desc
as set with 1 rows
selectdo
select cprrp100.plnc, cprrp100.type, cprrp100.item, min(cprrp100.psdt):psdt.f, max(cprrp100.psdt):psdt.t,
min(cprrp100.pfdt):pfdt.f, max(cprrp100.pfdt):pfdt.t,
max(cprrp100.dwar):cprrp100.dwar, max(cprrp100.cplb):cprrp100.cplb, sum(cprrp100.quan):cprrp100.quan
from cprrp100
where cprrp100.plnc = :cprpd000.aplc and cprrp100.psdt between :lzrrp001.bdat and :lzrrp001.edat
and cprrp100.pfdt between :finish.date.f and :finish.date.t
and cprrp100.type in (4,5) and cprrp100.osta = 30
and cprrp100.cplb = :planner
group by cprrp100.plnc, cprrp100.type, cprrp100.item|, cprrp100.psdt, cprrp100.pfdt
order by cprrp100.plnc, cprrp100.type, cprrp100.item|, cprrp100.psdt, cprrp100.pfdt
selectdo
stpapi.put.field(«cppat1210m000″,»purch.orders»,str$(1))
stpapi.put.field(«cppat1210m000″,»purch.order.type»,»S01″)
select tcibd001.*
from tcibd001
where tcibd001._index1 = {:cprrp100.item(4;47)}
selectdo
selectempty
endselect
stpapi.put.field(«cppat1210m000″,»purch.ord.series»,tcibd001.ctyp(2;2)&»01″)
stpapi.put.field(«cppat1210m000″,»cp.item.f.segment.1″,»»)
stpapi.put.field(«cppat1210m000″,»cp.item.f.segment.2″,»»)
stpapi.put.field(«cppat1210m000″,»cp.item.f.segment.3»,trim$(cprrp100.item))
stpapi.put.field(«cppat1210m000″,»cp.item.t.segment.1″,»»)
stpapi.put.field(«cppat1210m000″,»cp.item.t.segment.2″,»»)
stpapi.put.field(«cppat1210m000″,»cp.item.t.segment.3»,trim$(cprrp100.item))
stpapi.put.field(«cppat1210m000″,»cwar.f»,trim$(cprrp100.dwar))
stpapi.put.field(«cppat1210m000″,»cwar.t»,trim$(cprrp100.dwar))
stpapi.put.field(«cppat1210m000″,»planner.f»,trim$(cprrp100.cplb))
stpapi.put.field(«cppat1210m000″,»planner.t»,trim$(cprrp100.cplb))
stpapi.put.field(«cppat1210m000″,»start.date.f»,str$(psdt.f))
stpapi.put.field(«cppat1210m000″,»start.date.t»,str$(psdt.t))
stpapi.put.field(«cppat1210m000″,»finish.date.f»,str$(pfdt.f))
stpapi.put.field(«cppat1210m000″,»finish.date.t»,str$(pfdt.t))
stpapi.put.field(«cppat1210m000», «spool.fileout», file_afs)
stpapi.set.report(«cppat1210m000″,»rcppat121011000″,»ASCIT»,msg.out)
stpapi.form.command(«cppat1210m000″,5,»exec.cont.process»,msg.out)
if trim$(msg.out)<>»» then
msg.out = «cppat1210m000 » & » » & trim$(cprrp100.item)& » » &msg.out
rprt_send()
else
select lzrrp002.*
from lzrrp002 for update
where lzrrp002._index1 = {:lzrrp001.ndoc, :cprrp100.type, :cprrp100.item(4;47)}
selectdo
lzrrp002.quan = lzrrp002.quan + cprrp100.quan
db.update(tlzrrp002, db.retry)
count=count+1
if count>100 then
count=0
commit.transaction()
endif
selectempty
lzrrp002.ndoc = lzrrp001.ndoc
lzrrp002.type = cprrp100.type
lzrrp002.item = cprrp100.item(4;47)
lzrrp002.quan = cprrp100.quan
lzrrp002.dwar = cprrp100.dwar
lzrrp002.suwa = «»
| lzrrp002.cplb = «»
| if cprrp100.type = ltoe(5) then
lzrrp002.cplb = cprrp100.cplb
| endif
db.insert(tlzrrp002, db.retry)
count=count+1
if count>100 then
count=0
commit.transaction()
endif
endselect
endif
while true
error.code=stpapi.get.mess.code(«cppat1210m000»,msg.out)
If isspace(msg.out) Then
break
EndIF
msg.out = «cppat1210m000 » & » » & trim$(cprrp100.item)& » » &msg.out
rprt_send()
endwhile
stpapi.end.session(«cppat1210m000»)
server2client(file_afs, trim$(filename) & file_afs, false)
selectempty
endselect
selectempty
endselect
selectempty
endselect
commit.transaction()
| server2client(«filiout», «c:\fileout», 0)
message(win.to.iso(«УЮвЮТЮ»))
}
|******************************************************************************
|* lzrrp9200 0 VRC B61C a gaz
|* передача из Планирования многострочного складского заказа
|* Ширяева Ольга
|* 2009-07-21
|******************************************************************************
|* Main table lzrrp900 , Form Type 1
|******************************************************************************
|****************************** declaration section ***************************
declaration:
#pragma used dll olzcmgdlldbf
table tcprrp100 | ђрсышір е№рэхэшх яырэютћѕ фрээћѕ
table tcprpd000
table tlzrrp001
table tlzrrp002
table twhinh220
table tcprrp010
| table twhinh200
extern domain cprrp.orno orno.f fixed
extern domain cprrp.orno orno.t fixed
extern domain tcorno or2,or1
#pragma used dll olzcmgdlldbf
extern string msg.out(60), err.msg(60), error.code(60),mess.out(60)
long y,m,d,h,mm,s,udate,ldate, psdt, rpnumb, pono
string lzndoc(1) |,ndoc (10)
domain tccwar dwar,suwa
double quan
long count, ret
|****************************** form section **********************************
group.1:
init.group:
get.screen.defaults()
|****************************** choice section ********************************
choice.cont.process:
On.choice:
choice.print.data:
on.choice:
rpnumb= brp.open(«rlzrrp920011000″,»»,1)
read.main.table()
If rpnumb Then
brp.close(rpnumb)
EndIF
execute(end.program)
|****************************** field section *********************************
field.orno.f:
when.field.changes:
orno.t = orno.f
|****************************** function section ******************************
Functions:
Function extern main.table()
{
execute(print.data)
}
Function extern read.main.table()
{
count = 0
lzndoc=win.to.iso («д»)
select lzrrp001.*
from lzrrp001
where lzrrp001.ndoc(1;1)=:lzndoc
and lzrrp001.stat=1
selectdo
dwar=»»
suwa=»»
psdt=0
select cprpd000.indt, cprpd000.aplc |юя№хфхыџхь яюёыхфэўў cprpd000.indt
from cprpd000
order by cprpd000._index1 desc
as set with 1 rows
selectdo
select cprrp100.type, cprrp100.item, sum(cprrp100.quan):quan, cprrp100.dwar, cprrp100.suwa,cprrp100.psdt,cprrp100.orno ,cprrp100.plnc
from cprrp100
where cprrp100.plnc = :cprpd000.aplc and
cprrp100.type =30 and cprrp100.osta = 30
group by cprrp100.type, cprrp100.item, cprrp100.dwar, cprrp100.suwa ,cprrp100.psdt,cprrp100.orno ,cprrp100.plnc
order by cprrp100.dwar,cprrp100.suwa,cprrp100.psdt desc ,cprrp100.item
selectdo
if cprrp100.orno=»2349″ then | я№ютх№ър
cprrp100.orno=cprrp100.orno
endif
if AFS.func()=1 then
SELECT cprrp010.* |
FROM cprrp010 for update |
WHERE cprrp010.orno=:cprrp100.orno |
and cprrp010.koor=:cprrp100.type
and cprrp010.plnc=:cprrp100.plnc | шёя№рттыхэшх юђ 26.01.10
SELECTDO |
db.delete(tcprrp010,db.retry) |
ENDSELECT |
select cprrp100.*
from cprrp100 for update
where cprrp100.plnc = :cprpd000.aplc and
cprrp100.type =30 and cprrp100.osta = 30
selectdo
db.delete(tcprrp100,db.retry)
endselect
endif
commit.transaction()
endselect
ENDSELECT
| ENDIF
ENDSELECT
message(win.to.iso(«Уюђютю»))
}
function long AFS.func()
{
string serija(5), tip(3)
If cprrp100.suwa(1;1)=»6″ and cprrp100.suwa(4;1)=»0″ Then
serija=»20000″
else
serija=win.to.iso(«ЯЫРЭ_»)
EndIF
If cprrp100.dwar=»022022″ Then | вшя ёъырфёъюую чрърчр
tip=win.to.iso(«Яа3»)
else
tip=win.to.iso(«Яа1»)
EndIF
If cprrp100.suwa(1;3)=cprrp100.dwar(1;3) Then
tip=win.to.iso(«Яа5»)
else
tip=win.to.iso(«Яа1»)
EndIF
If dwar=cprrp100.dwar and suwa=cprrp100.suwa |and psdt=cprrp100.psdt | ёђ№юъш чрърчр
Then
stpapi.put.field(«whinh2120m000″,»whinh220.oorg»,str$(72))
stpapi.put.field(«whinh2120m000″,»whinh220.orno»,or1)
stpapi.put.field(«whinh2120m000″,»whinh220.oset»,str$(1))
ret=stpapi.find(«whinh2120m000»,msg.out)
ret=stpapi.synchronize.dialog(«whinh2120m000″,»add»,msg.out)
if ret then
stpapi.put.field(«whinh2120m000″,»whinh220.item.segment.1»,cprrp100.item(4;9))
stpapi.put.field(«whinh2120m000″,»whinh220.item.segment.2»,cprrp100.item(13;38))
stpapi.put.field(«whinh2120m000″,»whinh220.qoro»,str$(quan))
stpapi.insert(«whinh2120m000″,true,msg.out)
if trim$(msg.out)<>»» then
brp.ready(rpnumb)
endif
while true
error.code=stpapi.get.mess.code(«whinh2120m000»,msg.out)
If isspace(msg.out) Then
break
EndIF
brp.ready(rpnumb)
endwhile
endif
stpapi.end.session(«whinh2120m000»)
if whinh220.read(pono,or1) then
upd.lzrrp902()
return(1)
else
return(0)
endif
else | єю№ьш№ютрэшх эютюую чрърчр
utc.to.date (cprrp100.psdt,y,m,d,h,mm,s )
psdt=date.to.utc(y,m,d,23,59,0)
pono=0
stpapi.put.field(«whinh2202m000″,»order.origin»,str$(2))
stpapi.put.field(«whinh2202m000″,»transaction.type»,str$(2))
stpapi.put.field(«whinh2202m000″,»item.segment.1»,cprrp100.item(4;9))
stpapi.put.field(«whinh2202m000″,»item.segment.2»,cprrp100.item(13;38))
stpapi.put.field(«whinh2202m000″,»qty.storage.unit»,str$(quan))
stpapi.put.field(«whinh2202m000″,»shipfrom.code»,cprrp100.suwa)
stpapi.put.field(«whinh2202m000″,»delivery.date»,str$(psdt))
stpapi.put.field(«whinh2202m000″,»shipto.code»,cprrp100.dwar)
stpapi.put.field(«whinh2202m000″,»receipt.date»,str$(psdt))
stpapi.put.field(«whinh2202m000″,»series»,serija)
stpapi.put.field(«whinh2202m000″,»order.type»,tip)
stpapi.set.report(«whinh2202m000″,»rwhinh220211000″,»ASCIT»,msg.out)
stpapi.form.command(«whinh2202m000″,5,»exec.cont.process»,msg.out)
stpapi.get.field(«whinh2202m000″,»order.number»,or1)
while true
error.code=stpapi.get.mess.code(«whinh2202m000″,msg.out)
If isspace(msg.out) Then
break
EndIF
brp.ready(rpnumb)
endwhile
If strip$(or1)<>»» Then
dwar=cprrp100.dwar
suwa=cprrp100.suwa
psdt=cprrp100.psdt
EndIF
stpapi.end.session(«whinh2202m000″)
if whinh220.read(pono,or1) then
upd.lzrrp902()
msg.out=»»
cprrp100.item=»»
brp.ready(rpnumb)
return(1)
else
return(0)
endif
EndIF
return(0)
}
function upd.lzrrp902()
{
lzrrp002.item = cprrp100.item(4;47)
select lzrrp002.*
from lzrrp002 for update
where lzrrp002._index1 = {:lzrrp001.ndoc, :cprrp100.type, :lzrrp002.item ,:cprrp100.suwa} |,:cprrp100.suwa }
selectdo
lzrrp002.quan = lzrrp002.quan + quan
db.update(tlzrrp002, db.retry)
selectempty
lzrrp002.ndoc = lzrrp001.ndoc
lzrrp002.type = cprrp100.type
lzrrp002.item = cprrp100.item(4;47)
lzrrp002.quan = quan
lzrrp002.dwar = cprrp100.dwar
lzrrp002.suwa = cprrp100.suwa
db.insert (tlzrrp002, db.retry)
endselect
}
function long whinh220.read(ref domain tcpono a.pono, domain tcorno a.orno)
{
long pono.l
SELECT whinh220.pono :pono.l
FROM whinh220
WHERE whinh220._index1={72,:a.orno}
ORDER BY whinh220.pono desc
SELECTDO
break
SELECTEMPTY
pono.l=0
ENDSELECT
If a.pono<pono.l Then
a.pono=pono.l
return(1)
else
return(0)
EndIF
}
|******************************************************************************
|* lzrrp0401 0 VRC B61C a gaz
|* Отчёт по плановым заказам
|* Ширяева Ольга
|* 2009-09-04
|******************************************************************************
|* Main table lzrrp002 История планирования, Form Type 4
|******************************************************************************
|****************************** declaration section ***************************
declaration:
table tlzrrp002 | История планирования
table tlzrrp001
table ttcibd001
table ttcmcs003
extern domain tctano ndoc
extern domain tcyesno izmen
extern domain tckoor type
extern domain tccwar dwar.f, dwar.t, suwa.f, suwa.t
extern domain tcdsca dwar.f.dsca, dwar.t.dsca, suwa.f.dsca, suwa.t.dsca
extern domain tcmcs.str256 zagolovok
string rsFile(128)
#include «itfzzzreports»
DECLARE_ROWSET(rsReport)
|****************************** program section ********************************
|****************************** group section **********************************
group.1:
init.group:
set.enum.values.for.field («type», tckoor.cp.sfc, tckoor.cp.pur, tckoor.cp.ipl)
set.ask.enum.values (tckoor.cp.sfc, tckoor.cp.pur, tckoor.cp.ipl)
inputfield.invisible(«dwar.f»)
inputfield.invisible(«dwar.t»)
inputfield.invisible(«dwar.f.dsca»)
inputfield.invisible(«dwar.t.dsca»)
inputfield.invisible(«suwa.f»)
inputfield.invisible(«suwa.t»)
inputfield.invisible(«suwa.f.dsca»)
inputfield.invisible(«suwa.t.dsca»)
get.screen.defaults()
|****************************** choice section ********************************
choice.print.data:
on.choice:
If open.xml.rowset(spool.report, rsFile, USE_ROWSET(rsReport))>0 Then
read.main.table()
close.xml.rowset(USE_ROWSET(rsReport))
send.crystal.parameters()
else
message(win.to.iso(«Я№юсыхьр я№ш ухэх№рішш юђїИђр»),1)
choice.again()
EndIF
|****************************** field section *********************************
field.type:
when.field.changes:
if type = ltoe(30) then
inputfield.visible(«dwar.f»)
inputfield.visible(«dwar.t»)
inputfield.visible(«dwar.f.dsca»)
inputfield.visible(«dwar.t.dsca»)
inputfield.visible(«suwa.f»)
inputfield.visible(«suwa.t»)
inputfield.visible(«suwa.f.dsca»)
inputfield.visible(«suwa.t.dsca»)
else
inputfield.visible(«dwar.f»)
inputfield.invisible(«dwar.t»)
inputfield.visible(«dwar.f.dsca»)
inputfield.invisible(«dwar.t.dsca»)
inputfield.invisible(«suwa.f»)
inputfield.invisible(«suwa.t»)
inputfield.invisible(«suwa.f.dsca»)
inputfield.invisible(«suwa.t.dsca»)
endif
field.dwar.f:
when.field.changes:
select tcmcs003.dsca:dwar.f.dsca
from tcmcs003
where tcmcs003._index1 = {:dwar.f}
selectdo
selectempty
dwar.f.dsca = «»
endselect
dwar.t=dwar.f
dwar.t.dsca=dwar.f.dsca
field.dwar.t:
when.field.changes:
select tcmcs003.dsca:dwar.t.dsca
from tcmcs003
where tcmcs003._index1 = {:dwar.t}
selectdo
selectempty
dwar.t.dsca = «»
endselect
field.suwa.f:
when.field.changes:
select tcmcs003.dsca:suwa.f.dsca
from tcmcs003
where tcmcs003._index1 = {:suwa.f}
selectdo
selectempty
suwa.f.dsca = «»
endselect
suwa.t=suwa.f
suwa.t.dsca=suwa.f.dsca
field.suwa.t:
when.field.changes:
select tcmcs003.dsca:suwa.t.dsca
from tcmcs003
where tcmcs003._index1 = {:suwa.t}
selectdo
selectempty
suwa.t.dsca = «»
endselect
|****************************** function section ******************************
functions:
function read.main.table()
{ domain tctano ndoc.sr
double quan
ndoc.sr = «»
select lzrrp002.*, tcibd001.dsca, tcibd001.cuni
from lzrrp002, tcibd001
where lzrrp002._index1 = {:ndoc, :type}
and lzrrp002.dwar between :dwar.f and :dwar.t
and lzrrp002.suwa between :suwa.f and :suwa.t
and lzrrp002.item refers to tcibd001
selectdo
If izmen = tcyesno.yes Then
ndoc.sr = ndoc
If ndoc(1;1) = win.to.iso(«д») Then
ndoc.sr(1;1) = win.to.iso(«Ш»)
else
ndoc.sr(1;1) = win.to.iso(«д»)
EndIF
select lzrrp002.quan:quan
from lzrrp002
where lzrrp002._index1 = {:ndoc.sr, :lzrrp002.type, :lzrrp002.item, :lzrrp002.suwa}
selectdo
selectempty
quan=0
endselect
lzrrp002.quan = lzrrp002.quan — quan
EndIF
if izmen = tcyesno.yes then
zagolovok = win.to.iso(«Яырэ: эюьх№ фюъѓьхэђр — «) & » » &trim$(ndoc) & win.to.iso(«, эюьх№ фюъѓьхэђр ё№ртэхэшџ — «) & » » & trim$(ndoc.sr)
else
zagolovok = win.to.iso(«Яырэ: эюьх№ фюъѓьхэђр — «) & » » &trim$(ndoc)
endif
zagolovok = trim$(zagolovok) & win.to.iso(«, ђшя чрърчр — «) & » » & enum.descr$ («tckoor», type)
if type = ltoe(30) then
zagolovok = trim$(zagolovok) & win.to.iso(«, ёъырф — ё») & » » & dwar.f & » «& win.to.iso(«яю») & » » & dwar.t
& win.to.iso(«, яюёђртыџўљшщ ёъырф — ё») & » » & suwa.f & » «& win.to.iso(«яю») & » » & suwa.t
else
zagolovok = trim$(zagolovok) & win.to.iso(«, ёъырф — «) & » » & dwar.f
endif
write.xml.row(USE_ROWSET(rsReport))
selectempty
endselect
}
function send.crystal.parameters()
{
long active.record
active.record=crystal.request.open(«rlzrrp040111000» & «.xls», PLAIN_ROWSET, rsFile, rsfile, «Яхїрђќ»)
If active.record Then
crystal.close.request(active.record)
launch.rview(rsfile)
EndIF
}