Библиотека управления

Лекции по ERP

Авторы И.В.Балахонова, С.А.Волчков, В.А.Капитуров, И.А.Обухов, С.В.Румянцев http://interface.mfg.ru

Введение

В последние годы после продолжавшегося целое десятилетие тяжелого кризиса в промышленности России наблюдается заметное оживление. Наметившаяся стабилизация внутреннего рынка способствует повышению эффективности деятельности российских промышленных предприятий и делает для них актуальными проблемы обновления техники и технологии, совершенствования системы управления и снижения издержек. Современные российские предприятия переживают сегодня посткризисную фазу, которая определяется как предшествующей историей, так и современными тенденциями рынка.

Наблюдавшийся с 1991 по 1998 гг. в спад промышленного производства в России был обусловлен целым рядом факторов, которые по отношению к предприятиям можно условно разбить на две группы: внешнюю и внутреннюю. К внешним факторам относятся:

  • затянувшаяся на десятилетие структурная перестройка народного хозяйства;
  • разрыв старых еще социалистических хозяйственных связей;
  • инфляция и инфляционные ожидания, ведущие к огромным процентным ставкам за пользование краткосрочных банковских кредитов, которые промышленные предприятия не в состоянии отработать;
  • хроническая нехватка денежных ресурсов у предприятий, что ведет к цепочке неплатежей и преобладанию бартерных эрзацсхем расчетов предприятий между собой;
  • спад инвестиционной активности и катастрофический износ основных фондов предприятий и т.д. Важнейшими внутренними факторами, влияющими на положение предприятий, являются:
  • уровень технологии, используемой на предприятии (возраст парка технологического оборудования и его структура, уровень обслуживания и ремонта оборудования, уровень транспортно-складского обеспечения, уровень прогрессивности технологических процессов по стадиям производства и т.д.);
  • состояние организации производства (уровень специализации цехов и участков, уровень ритмичности производства, уровень загрузки производственных ресурсов, уровень операционного планирования и диспетчирования производства, нормирование и т.д.);
  • совершенство управления предприятием (уровень стратегического планирования и формирования оптимальной производственной программы, уровень маркетинга и про гнозирования, уровень ассортиментного планирования, наличие контроллинга производственно-финансовой деятельности – то есть учет и анализ, технология принятия управленческих решений, мотивация персонала, контроль исполнения и т.д.).

Как показывает практика, несмотря на то, что все российские предприятия находятся практически в одинаковых внешних условиях, среди них есть такие, которые адаптировались к внешней среде и работают вполне успешно. Следовательно, упадок многих предприятий объясняется не только наличием неблагоприятных внешних условий, но также и внутренними причинами, определяющими чрезвычайно высокий уровень производственных затрат.

В современных российских условиях, когда большинство предприятий не имеет серьезных возможностей для получения объемных инвестиций, первые шаги по повышению эффективности приходится делать на базе существующих технологий, оптимизируя в первую очередь организацию хозяйственной деятельности и управление. Для того, чтобы наиболее эффективно реорганизовать предприятие, адаптировать его к современным условиям хозяйствования, полезно обратиться к мировому опыту, к тем формам и методам управления предприятия, которые стали мировыми стандартами.

В обзорах Gartner Group приводится график соотношения спроса и предложения в США в период с 1945 г. по 1997 г. (см. рис.1).

Как видно, по соотношению спрос / предложение можно выделить два периода:

  • с 1945 по 1980 гг. – это дефицитный рынок, когда спрос существенно превышал предложение и производитель диктовал потребителю цены на готовую продукцию. Цена в данный период привязывалась к себестоимости продукции и той норме прибыли, которую компания-производитель устанавливала, исходя из потребностей своего развития;
  • начиная с 1980 г. в США (да и во всем «западном» мире) происходит перелом соотношения спроса и предложений (данный срок является усредненным, для многих отраслей и предприятий этот перелом происходил в разные периоды и процесс этот еще не закончен); рынок в целом становится конкурентным, то есть цена на продукцию начинает определяться исключительно конъюнктурой рынка и для того чтобы получить необходимую прибыль и не понести убытков, предприятия должны снижать себестоимость своей продукции.

Для нашей страны, таким переломным годом стал 1992 г., когда в результате «экономической реформы» (а точнее, революции) отечественные предприятия в одночасье из дефицитного рынка переместились в рынок конкурентный, причем конкурировать пришлось сразу же с мировыми производителями, у которых соотношение цена/качество на продукцию было много предпочтительнее.

Если рассматривать развитие социально - экономических отношений в западных странах (см. Таблицу 1) в период перехода от дефицитного к конкурентному рынку, то следует отметить, что в 90-е годы:

  • деятельность компаний нацелена на непрерывное улучшение обслуживание клиентов (потребителей) по приемлемым для последних ценам;
  • продолжительность жизни продукции сокращается по сравнению с предшествующим десятилетием в несколько раз;
  • повышается качество продукции и уменьшается ее себестоимости (жесткая конкурентная борьба концентрируется вокруг «бездефектного производства» ( Defects Per Million Opportunities -DPMO (PPM) … - РРМ.) и использования философии «Тотального управления качеством» (Total Quality Management - TQM), внедрение философии управления производством и запасами «точно в срок» (Just in Time - JT), что ведет к обновлению запасов материалов и комплектующих 50 – 100 раз в год и сокращению производственного цикла);
  • планирование выпуска готовой продукции, опирается на заказ, то есть на идеологию – «производить только то, что уже продано» (производство синхронизируется с потребностями покупателей).

Российские предприятия к 90-м годам по развитию экономических отношений находились на уровне, характерном для западных компаний в 60-е годы. И именно в таком положении они были поставлены не просто в условия конкурентного рынка, а в условия конкуренции с лучшими мировыми производителями. Заслуживает удивления и восхищения тот факт, что многие из них не просто выжили, но и научились эффективно работать в новых условиях.

Сегодня производства с неэффективной организацией, где не ведется борьба со всеми видами потерь (в том числе не сокращаются различные запасы, которые в мировой практике рассматриваются как наихудший вид потерь), и производители низкокачественной продукции быстро становятся банкротами, в результате конкурентной борьбы с эффективными производителями высококачественных товаров.

Мировой опыт показывает, что успеха достигают те компании, которые балансируют производственные, коммерческие и финансовые цели, то есть рассматривают предприятие как единую производственно-сбытовую систему (ПСС), связывающую воедино такие сферы как:

маркетинг – создание новых изделий – снабжение – производство – сбыт – доставка продукции потребителю – сервисное обслуживание (см. рис. 2), и используют промышленные стандарты MRP/ERP в качестве базовой бизнес - модели, нацеленной на достижение экономической эффективности.

ERP-модель облегчает интеграцию деятельности всех подразделений предприятия, уменьшает количество ошибок, устраняет излишние операции. Прогнозирование и планирование, являющиеся неотъемлемыми атрибутами модели, дают существенное снижение стоимости продукции и услуг, оптимизируют бизнес - процессы предприятия. Широкое использование модели ERP и основанных на ней комплексов автоматизации управления предприятиями сделало ее промышленным стандартном «де - факто». Производители, надеющиеся на процветание в условиях современной конкуренции, настойчиво применяют ERP методологию для того, чтобы не отстать в эффективности производства и сбыта от своих конкурентов.

Настоящая книга посвящена модели ERP, ее важнейшей части – стандарту MRP II и их реализации в одной из лучших информационных систем поддержки бизнеса MFG/PRO корпорации QAD, одного из мировых лидеров на рынке систем автоматизации предприятий. Она задумана как учебное пособие и авторы надеются, что применение полученных при чтении книги знаний окажется полезным для специалистов отечественных предприятий.

Часть I

Современные концепции управления производством и их реализация в корпоративных информационных системах

Содержание

Лекция 1. Стандарты управления производством MRP/ERP

Лекция 2. Синхронизация внедрения ERP-системы с системой менеджмента качества

Лекция 1. Стандарты управления производством MRP/ERP

1.1. От MRP к ERP

Исторически, методология Enterprise Requirement Planning (ERP), то есть планирование ресурсов предприятия, является результатом последовательного развития, начавшегося с концепции Material Resource Planning (MRP), обеспечивавшей планирование потребностей предприятий в материалах. Преимущества, даваемые MRP, состоят в минимизации издержек, связанных со складскими запасами сырья, комплектующих, полуфабрикатов и прочего, а также с аналогичными запасами, находящимися на различных участках непосредственно в производстве.

В основе этой концепции лежит понятие Bill Of Material (BOM), то есть спецификации изделия, которая показывает зависимость внутреннего для предприятия спроса на сырье, комплектующие, полуфабрикаты и т.д. от плана выпуска (бюджета реализации) готовой продукции. При этом очень важную роль играет фактор времени, поскольку несвоевременная доставка материалов может привести к срыву планов выпуска готовой продукции. Для того чтобы учитывать временную зависимость производственных процессов, информационной системе, поддерживающей реализацию концепции MRP на предприятии, «необходимо знать» технологию выпуска продукции (технологическую цепочку), то есть последовательность технологических операций и их продолжительность. На основании плана выпуска продукции, BOM и технологической цепочки в MRP – системе осуществляется расчет потребностей в материалах в зависимости от конкретных сроков выполнения тех или иных технологических операций.

Однако у методологии MRP есть серьезный недостаток. При расчете потребности в материалах не учитываются загрузка и амортизация производственных мощностей, стоимость рабочей силы, потребляемой энергии и т.д. Поэтому в качестве логического развития MRP была разработана концепция Manufacturing Resource Planning (планирование производственных ресурсов), сокращенно называемая MRP II. В рамках MRP II можно уже планировать все производственные ресурсы предприятия: сырье, материалы, оборудование, людские ресурсы, все виды потребляемой энергии и пр.

Далее концепция MRP II развивалась в соответствии с тенденциями изменения рынка и порождаемыми ими новыми потребностями в управлении предприятиями. К MRP II постепенно добавлялись возможности по учету и управлению другими затратами предприятия. Так появилась концепция ERP, называемая иногда также Enterprise-wide Resource Planning (планированием ресурсов в масштабе предприятия). В основе методологии ERP лежит принцип единого хранилища данных (repository), содержащего всю деловую информацию, накопленную организацией в процессе ведения бизнеса, включая финансовую информацию, данные, связанные с производством, управлением персоналом, или любые другие сведения. Это устраняет необходимость в передаче данных от одной информационной системы к другой и создает дополнительные возможности для анализа, моделирования и планирования. Кроме того, любая часть информации, которой располагает данная организация, становится одновременно доступной для всех работников, обладающих соответствующими полномочиями.

Начиная с середины 90-х годов, концепция ERP стала очень популярной в производственном секторе, поскольку ее использование для планирования ресурсов позволило существенно сократить время выпуска продукции, снизить уровень товарно-материальных запасов, а также улучшить обратную связь с потребителем при одновременном сокращении административного аппарата. Методология ERP позволила объединить информацию обо всех ресурсах предприятия добавляя, таким образом, к MRP II возможности управление заказами, поставками, финансами и т.д.

Итак:

MRP (Material Requirement Planning) – это планирование потребности в материалах;

MRP II (Manufacturing Resource Planning) – это планирование производственных ресурсов;

ERP (Enterprise Resource Planning) – это планирование ресурсов всего предприятия.

Стандарты MRP/ERP поддерживаются Американским обществом по контролю за производственными запасами APICS (American Production and Inventory Control Society). MRP/ERP – это набор проверенных на практике разумных принципов, моделей и процедур управления и контроля, предназначенных для повышения показателей экономической деятельности предприятия. Так, изданный APICS в 1989 г. стандарт «MRP II Standard System», содержит 16 групп функций производственно - сбытовой системы:

  • Планирование продаж и производства (Sales and Operation Planning);
  • Управление спросом (Demand Management);
  • Составление плана производства (Master Production Scheduling);
  • Планирование материальных потребностей (MRP - Material Requirement Planning);
  • Спецификация продуктов (Bill of Materials);
  • Управление запасами (Inventory Transaction Subsystem);
  • Управление плановыми поставками (Scheduled Receipts Subsystem);
  • Управление на уровне производственного цеха (Shop Flow Control);
  • Планирование производственных мощностей (CRP – Capacity Requirement Planning);
  • Контроль входа/выхода рабочих потоков (Input/output control);
  • Материально техническое снабжение (Purchasing);
  • Планирование ресурсов для распределения (DRP – Distribution Resource Planning);
  • Планирование и контроль производственных операций (Tooling Planning and Control);
  • Управление финансами (Financial Planning);
  • Моделирование для производственной программы (Simulation);
  • Оценка результатов деятельности (Performance Measurement).

С накоплением опыта моделирования производственных и непроизводственных бизнес -процессов эти понятия постоянно уточняются, постепенно охватывая функций. Развитие стандарта MRP/ERP проиллюстрировано в Таблице 1.

1.2. Современная структура модели MRP/ERP

Сегодня модель MRP/ERP включает в себя следующие подсистемы, которые часто называют также блоками или сериями:

  • управление запасами;
  • управление снабжением;
  • управление сбытом;
  • управление производством;
  • планирование;
  • управление сервисным обслуживанием;
  • управление цепочками поставок;
  • управление финансами.

Остановимся кратко на базовой функциональности, поддерживаемой каждой из подсистем.

1.2.1. Управление запасами

Эта подсистема обеспечивает реализацию следующих функций:

1) Inventory Control – мониторинг запасов;

2) Physical Inventory – регулирование и инвентаризация складских остатков.

При решении задач управления запасами - производится обработка и корректировка всей информации о приходе, движении и расходе сырья и материалов, промежуточной продукции и готовых изделий; учет запасов по складским ячейкам, выбор индивидуальных стратегий контроля, пополнения и списания запасов по каждой позиции номенклатуры сырья и материалов, и т.д. Учитывается нормативная и текущая фактическая стоимость запасов, а также отслеживается прохождение отдельных партий запасов и серий изготавливаемой продукции.

1.2.2. Управления снабжением

Подсистема реализует следующие функции:

1) Purchase Orders - заказы на закупку;

2) Supplier Schedules - график поставок;

3) MRP - планирование потребности в материалах, понимаемое как управление заявками на закупку.

1.2.3. Управление сбытом

Базовыми функциями этой подсистемы являются:

1) Sales Quotations - квотирование продаж;

2) Sales Orders / Invoices - заказы на продажу (счета фактуры);

3) Customer Schedules - график продаж потребителям;

4) Configured Products - конфигурирование продуктов;

5) Sales Analysis - анализ продаж;

6) Distributed Resource Planning (DRP) - управления ресурсами распределения.

1.2.4. Управления производством

В этой подсистеме реализуются следующие функции, соответствующие различными типам производственных процессов:

1) Product Structures - спецификация изделий, определяющая, какие материалы и комплектующие используются в производимом изделии;

2) Routings / Work Centers - операции/центры переработки, включает в себя описание цехов, участков, рабочих мест;

3) Formula / Process - технологические процессы производства продукции с маршрутизацией по рабочим центрам для объемного (процессного) производства.

4) Work Orders – наряд-задание (сменное задание) на производство работ для позаказного и мелкосерийного производства;

5) Shop Floor Control - управление трудозатратами (диспетчирование);

6) Repetitive - поточное производство (для серийного и массового производства).

7) Quality Management - управление качеством, то есть описание различных проверок изделий во время производственного процесса.

1.2.5. Планирование

В модели MRP/ERP предусматривается сквозное планирование, согласование и оперативная корректировка планов и действий снабженческих, производственных и сбытовых звеньев предприятия.

Подсистема планирования реализует следующие функции:

1. Product Line Planning (PLP) – финансовое планирование товарно - номенклатурных групп (ТНГ);

2. Master Scheduling Planning (MSP) – главный календарный график или объемно календарное планирование;

3. Distribution Resource Planning (DRP) – планирование распределения ресурсов (RCP);

4. Materials Requirements Planning (MRP) – планирование потребности материалов;

5. Capacity Requirements Planning (CRP)– планирование потребления мощностей. Эту функциональность можно условно отнеси к трем уровням планирования, отражающим иерархию планов в ERP-модели (см. рис. 5).

1.2.6. Управление сервисным обслуживанием

Эта подсистема активно используется компаниями, которые не только производят и продают свою продукцию, как, например, производители продовольствия, но и обеспечивают послепродажное техническое обслуживание и техническую поддержку своей продукции. Подсистема обеспечивается полный спектр необходимых функций: от создания графика технического обслуживания, заказа комплектующих, учета контрактов на обслуживание и формирования счетов до учета прибыли, получаемой от послепродажного обслуживания.

1.2.7. Управление цепочками поставок

Эта подсистема предназначена для обеспечения эффективного управления материальными и соответствующими им информационными потоками: от поставщика через производство к потребителю. Реализованная в подсистеме идеология «управления глобальными цепочками поставок» дает промышленным предприятиям возможность представлять свою деятельность в виде так называемых эффективных цепочек логистики: от поставщиков сырья и комплектующих до продажи готовых изделий конечному потребителю. При этом обеспечиваются широкие возможности управления транснациональными компаниями, координации распределенного между многими дочерними компаниями производства.

1.2.8. Управление финансами

В соответствии с идеологией MRP/ERP эта подсистема полностью интегрирована со всеми остальными и позволяет оперативно получать информацию о финансовых потоках, связанных с потоками материальными (см. рис. 6), о текущем финансовом состоянии компании, и помогает находить оптимальные финансово - экономические решения. Сквозное управление материальными потоками находит свое отражение в управлении финансовыми потоками (движении денежных средств).

В подсистеме реализована функциональность:

  1. General Ledger – главная бухгалтерская книга, предназначенная для отражения финансовых транзакций и ведения бухгалтерского учета;
  2. Multiple Currency – мультивалютность, для ведения учета в разных валютах;
  3. Accounts Receivable - дебиторская задолженность;
  4. Accounts Payable - кредиторская задолженность;
  5. Payroll - заработная плата;
  6. Cost Management - управление себестоимостью;
  7. Cash Management - управление платежами;
  8. Fixed Assets - учет основных средств.

Модель MRP/ERP реализована в ряде информационных систем (ERP –систем) корпоративного уровня. Согласно статистическим данным, полученным при анализе использования ERP-систем в США, результатом внедрения таких систем на предприятиях является сокращение объемов запасов в среднем на 17 %, уменьшение затрат за закупку сырья и материалов на 7 %, повышение рентабельность производства в среднем на 30% и качества выпускаемой продукции на 60%.

1.3. Реализация стандартов управления в корпоративных информационных системах (КИС)

1.3.1. Краткий обзор систем управления бизнесом

Приобретая и внедряя корпоративную информационную систему, предприятия получают вместе с ней и соответствующую технологию управления. Построение современной системы корпоративного управления - процесс длительный, сложный и трудоемкий. И если предприятие решается на проект внедрения КИС, то перед ним встает проблема выбора системы, наиболее соответствующей его роду деятельности, исторически сложившейся структуре и методам управления. Ясно, что в процессе внедрения, который во многом представляет собой перманентный консалтинг и последующую реорганизацию действующих бизнес – процессов, и структура и система управления предприятие будут серьезно видоизменены. Однако это изменение не должно быть ломкой рациональных устоев, которые, собственно, и позволяли предприятию существовать весь период, предшествующий внедрению КИС. Новая информационная система должна нести в себе позитивный заряд перемен, многократно усиливающих традиционно сильные стороны предприятия, оптимизирующих его структуру и методы управления, ликвидирующих устаревшие, тормозящие бизнес формы и методы руководства.

Западные аналитики различают два вида корпоративных информационных систем: Business Management Systems (BMS) – системы управления бизнесом и Enterprise Recourse Planning (ERP) – системы планирования ресурсов предприятия.

В свою очередь, BMS – системы разбиваются на три группы. В первую из них входят простые системы, предназначенные для автоматизации малых предприятий. Системы этой группы рассчитаны на выполнение весьма ограниченного числа стандартных бизнес - процессов и представляют собой «коробочный продукт». Как правило, они работают на одном рабочем месте или в небольших сетях из 4 – 8 компьютеров. За рубежом такие системы называют «Low End PC». Отечественным примером системы такого уровня является «1С Бухгалтерия».

Ко второй группе, называемой «Middle PC», относят системы, отличающейся большей глубиной и широтой охвата функций. Они нуждаются в настройке, которую в большинстве случаев осуществляют специалисты фирмы-разработчика. В такой системе могут быть описаны десятки бизнес - процессов. В основном данные системы автоматизируют бухгалтерский и/или складской учет, как например «1C Предприятие».

Следующая группа систем под названием «High End PC» рассчитана на работу большого числа пользователей. Такие системы могут применяться на средних предприятиях, не предъявляющих высоких требований к функциональности и гибкости системы управления. В системах этой группы можно встретить описание уже сотен бизнес - процессов. В большинстве случаев они могут работать в среде Windows NT или UNIX. Среди российских программных продуктов к данному классу относятся “Галактика”, “NS2000”; среди западных – «Concorde XAL».

Высший уровень иерархии занимают системы, которые обеспечивают планирование и управление всеми ресурсами предприятия и строятся на основании MRP/ERP модели, то есть ERP-системы. В них содержится описание тысяч бизнес - процессов. Такие системы могут иметь до 100 тысяч настраиваемых параметров, позволяющих реализовать огромное многообразие требований различных предприятий. ERP-системы удовлетворяют большинству запросов как средних, так и очень крупных предприятий. Они могут работать на различных платформах (Windows NT, UNIX, Solaris, AIX и т.д.) и с различными мощными профессиональными СУБД.

На мировом рынке представлено около трех десятков полноценных ERP-систем. В России систем подобного уровня пока еще не создано. Затраты на создание ERP-системы оцениваются экспертами в несколько тысяч человеко-лет с вытекающими отсюда финансовыми и организационными затратами. Кроме того, очень важным для столь сложных информационных систем является процесс апробации на множестве предприятий. Только после нескольких десятков успешных внедрений ERP-система может претендовать на рыночный успех, поскольку только тогда она аккумулирует в себе достаточный опыт предметных специалистов и необходимые управленческие технологии. Чтобы вернуть инвестиции и получить прибыль, компания-разработчик ERP-системы должна обеспечить ей высокий уровень продаж. Но рынок России и стран СНГ, даже по самым оптимистическим оценкам, не способен пока обеспечить спрос в миллиарды долларов за системы подобного класса. Это значит, что система должна хорошо продаваться на западных рынках, прежде всего в США. Все без исключения лидеры рынка ERP-систем смогли занять свои позиции только после успеха на самом богатом американском рынке. Так как у нас только начинается развитие экономики предприятий на базе MRP/ERP – моделей, то пройдет немало времени, прежде чем в России появятся специалисты, которые научатся не только разбираться в современных методах управления предприятиями, но и создавать программные продукты, реализующие эти методы. Однако ничто не препятствует уже сейчас использовать мировой опыт применения информационных технологий для управления предприятиями, поскольку многие из ERP- систем представлены в России, переведены на русский язык и адаптированы к требованиям российского законодательства.

Сейчас практически все современные западные производственные системы и основные системы управления производством базируются на концепции ERP и отвечают её рекомендациям, которые вырабатываются американской общественной организацией APICS, объединяющей производителей, консультантов в области управления производством, разработчиков программного обеспечения. К сожалению, большинство из российских систем управления производством не удовлетворяет пока даже требованиям MRP, не говоря уже обо всех остальных более развитых концепциях (см. Таблицу 1).

Последний по времени стандарт CSRP (Customer Synchronized Resource Planning) охватывает кроме управления непосредственно предприятием также и взаимодействие с лиентами: оформление технического задания, наряд – заказа, поддержку заказчика на местах и пр. Таким образом, если MRP, MRP-II, ERP ориентировались на внутреннюю организацию предприятия, то CSRP включил в себя полный цикл от проектирования будущего изделия, с учетом требований заказчика, до гарантийного и сервисного обслуживания после продажи. Основная суть концепции CSRP в том, чтобы интегрировать заказчика в систему управления предприятием. То есть не отдел сбыта, а сам покупатель непосредственно размещает заказ на изготовление продукции - соответственно сам несет ответственность за его правильность, сам может отслеживать сроки поставки, производства и пр. При этом предприятие может очень четко отслеживать тенденции спроса и т.д.

На мировом рынке сейчас предлагается свыше 500 систем класса BMS (в том числе и системы класса MRP II-ERP). Рынок бурно растет - на 35% - 40% каждый год. В настоящее время в России присутствуют около десятка западных систем и три-четыре отечественные информационные системы, которые можно отнести к корпоративным. Для того чтобы понять, кто есть кто на рынке информационных систем для предприятий России, ниже предлагается классификация информационных систем (см. Таблицу 2 и рис. 7).

В отечественной прессе в последнее время немало писали про якобы избыточную функциональность и дороговизну системам стандарта ERP, апеллируя, как правило, к самым заметным представителям этого класса - продуктам SAP R/3, Baan и Oracle Application. Действительно, помимо высоких цен, программные продукты этих корпораций сложны для внедрения в российских условиях: во-первых, в России элементарно не хватает специалистов по внедрению достаточной квалификации, а во-вторых, эти системы требуют от заказчика серьезной реорганизации управления.

При формировании Таблицы 2 использованы данные аналитического отчета «Выбор тиражируемой интегрированной системы управления предприятием», раз в полгода выпускаемого независимой исследовательской компанией RC Group и корпорацией "МетаСинтез" (подробнее см. www.RussianEnterpriseSolutions.com). Они не претендуют на абсолютную полноту, а отражают состояние исследований на октябрь 2000 года. Системы отмеченные как (2*) подробно представлены в аналитическом отчете и за их правильную квалификацию эксперты RC Group и «МетаСинтез» несут ответственность. Остальные системы квалифицированы так, как это представляют их разработчики.

Приведенные в таблице системы отличаются от всех прочих присутствующих на российском рынке программных продуктов для автоматизации финансово-хозяйственной деятельности (FTP), во-первых, наиболее развитой функциональностью, а также тем, что в них или уже присутствует модуль планирования производства и оперативного управления им (MRP), или разработчики системы обещают появление таких возможностей в ближайшие два года (т.е. уже идет работа над реализацией этих задач). Достоинством и одновременно недостатком систем ERP уровня из первой тройки (R/3, BAAN, Oracle Application) является их универсальность. Иными словами, у «гигантов» есть референтные модели для любого типа производственного процесса, и количество автоматизированных рабочих мест определяется исключительно финансовыми возможностями заказчика. Но и возможности эти должны быть серьезными. Проект с использованием такой системы не может обойтись дешевле 500 тысяч долларов, а чаще всего стоит несколько миллионов долларов. По сути, эти системы оптимальны для компаний, ведущих бизнес не менее масштабный, чем бизнес самих разработчиков.

Для компаний среднего масштаба или имеющих не слишком диверсифицированный бизнес больше подходят другие системы ERP. О них до недавнего времени потребители либо не слышали, либо не совсем понимали, на кого они рассчитаны. Речь идет о западных продуктах для самого массового сегмента рынка - среднего и малого бизнеса, то есть для компаний с годовым оборотом от 3 до 10 млн. долларов и количеством работающих от 100 до 1000 человек. Типовая стоимость проекта по внедрению такой системы составляет от 50 до 250 тысяч долларов. Для сравнения: у российских ИСУП этот показатель колеблется в пределах от 50 до 500 тысяч долларов для тиражно - заказных систем и до 10 тысяч - для тиражируемых, или «коробочных».

Основное отличие систем ERP среднего уровня от программного обеспечения для крупных предприятий состоит в ограниченности решаемых задач и относительной простоте технологий внедрения и применения. Иными словами, эти системы поддерживают несколько определенных видов промышленной деятельности и имеют лимитированное количество возможных пользователей.

В соответствии с мировой практикой, при необходимости более тонкого анализа нескольких систем одного или близких классов, этапу выбора придается большое значение. Каждый проект в области автоматизации должен рассматриваться предприятием как стратегическая инвестиция средств, которая должна окупиться за счет улучшения управленческих процессов, повышения эффективности производства, сокращения издержек. В выборе правильного решения должно быть, в первую очередь, заинтересовано руководство предприятия. Данный проект должен ставиться на один уровень с приобретением, например, новой производственной линии или строительством цеха.

Прежде всего, предприятие должно определить, а что же собственно ожидается от новой системы: какие функциональные области и какие типы производства она должна охватывать, какую техническую платформу использовать, какие отчеты готовить? Проведение такой работы заканчивается обычно составлением документа «Требования к компьютерной системе». Он предназначен, прежде всего, для самого предприятия, так как в нем формализованы и расписаны в соответствии с приоритетами все характеристики новой системы. Этот документ дает объективные критерии для сравнения систем по заранее определенным параметрам. Любая из систем - лишь механизм для повышения эффективности управления, принятия правильных стратегических и тактических решений на основе своевременной и достоверной информации.

Увеличение эффективности работы предприятия при внедрении ERP-системы могут быть достигнуты за счет:

  • уменьшение сроков закрытия учетного периода;
  • повышения общей культуры управления, снижения бумажного документооборота, использования более оптимальных схем построения бизнес – процессов;
  • проведения поставок точно в срок;
  • более эффективного использования средств предприятия за счет увеличения общей оборачиваемости как всего капитала в целом, так и отдельных его частей;
  • снижения транспортно-заготовительных расходов;
  • улучшения послепродажного обслуживания;
  • снижения задержек с отгрузкой готовой продукции;
  • уменьшения страховых запасов (неснижаемых остатков на складах), внедрения прогрессивных методов их планирования и контроля;
  • снижения производственного брака;
  • уменьшения затрат на административно-управленческий аппарат;
  • более точного учета затрат;
  • снижения потребности предприятия в оборотных средствах за счет повышения ритмичности работы;
  • уменьшения складских площадей.

Как мы уже отмечали, в настоящее время не существует КИС российского происхождения, полностью отвечающих требованиям модели ERP. Поэтому для рассмотрения возможных вариантов автоматизации предприятия были взяты западные КИС, отвечающие требованиям ERP-модели и имеющие наилучшие позиции на российском и мировом рынках ERP-систем (см. Таблицу 3).

На рис. 8 представлены позиции ERP-систем на рынке для средних предприятий.

1.3.2. BAAN, BAAN IV

Компания BAAN основана в 1978 г. в Нидерландах. В ней работает около 1000 человек. Система «BAAN» имеет около 7000 внедрений за рубежом; 20 в России из них 2 проекта успешно завершены (Нижфарм – г. Н. Новгород, АО «Элем» - г. Чебоксары). По оценкам внешних экспертов в России только на АО «Элем» удалось выйти на полное использование стандартов MRPII.

В качестве СУБД используются: Oracle, Sybase, Informix.

Для разработки используются: Own 4GL – TRITON Tools

Архитектуры: Unix-сер., Win-кл.,Web-кл., RDA (двухуровневый клиент-сервер), AS (трехуровневый клиент-сервер).

Система ускоритель внедрения: Enterprise Modeler.

Система локализована в России в 1996 г.

В России систему представляет: BAAN-Евразия (Санкт-Петербург).

Финансовый модуль системы позволяет формировать отчетность Главной Книги в соответствии с российскими стандартами.

Предназначена для крупных предприятий следующих отраслей:

  • Авиакосмическая и оборонная промышленность,
  • Автомобилестроение,
  • Государственный сектор,
  • Металлургия,
  • Нефть и газ,
  • Пищевая промышленность,
  • Приборостроение,
  • Судостроение,
  • Телекоммуникации и связь,
  • Тяжелое машиностроение,
  • Фармацевтическая промышленность,
  • Целлюлозно-бумажная промышленность.

BAAN IV имеет стандартную функциональность ERP-системы.

1.3.3. SAP, R/3

Компания основана в 1972 г. в Германии. В компании работает около 7000 человек.

Система имеет 13000 внедрений за рубежом, 15 в России.

В качестве СУБД используются: Oracle, Adabas, Informix.

Для разработки используются: ABAP/4GL.

Архитектуры: Unix-сер., Win-кл.,Web-кл., RDA (двухуровневый клиент-сервер), AS (трехуровневый клиент-сервер).

Система ускоритель внедрения: Business Engineer.

Система локализована в России в 1996 г.

В России систему представляет: официальное представительство SAP в Москве.

Финансовый модуль системы позволяет формировать отчетность Главной Книги в соответствии с российскими стандартами.

ERP-система R/3 компании SAP AG позиционируется как готовое решение информатизации для крупных предприятий с конфигурациями для следующих направлений деятельности:

    Авиакосмическая промышленность;
  • Автомобилестроение;
  • Банковские услуги;
  • Химическая промышленность;
  • Потребительские товары;
  • Строительство;
  • Медицина;
  • Высшее образование и научные исследования;
  • Высокие технологии;
  • Страхование;
  • Сервисное обслуживание;
  • Телекоммуникации.

1.3.4. Oracle, Oracle Application

Компания основана в 1979 г. в США. В компании работает около 16500 человек из них 500 над ERP-системой. Система имеет 8500 внедрений за рубежом, 10 в России.

В качестве СУБД используются: Oracle.

Для разработки используются: Oracle Designer.

Архитектуры: Unix-сер., Win-кл.,Web-кл., RDA (двухуровневый клиент-сервер), AS (трехуровневый клиент-сервер).

Система ускоритель внедрения: Application Implem Wizard.

Система локализована в России в 1998 г.

В России систему представляет: официальное представительство Oracle в Москве.

Финансовый модуль системы позволяет формировать отчетность Главной Книги в

соответствии с российскими стандартами.

ERP-система для крупных предприятий. Компанией разработаны решения для следующих отраслей:

  • Государственный сектор;
  • Нефть и газ;
  • Металлургическая промышленность;
  • Фармацевтическая промышленность.

1.3.5. QAD, MFG/PRO

Компания основана в 1979 г. в США. В компании работает около 1300 человек.

Система MFG/PRO имеет около 6000 внедрений за рубежом, 10 в России.

В качестве СУБД используются: Progress, Oracle.

Для разработки используются: Progress 4GL.

Архитектуры: Unix-сер., Win-кл.,Web-кл., RDA (двухуровневый клиент-сервер), AS (трехуровневый клиент-сервер), хост -терминал.

Система ускоритель внедрения: Qwizard.

Система локализована в России в 1998 г.

В России систему представляют: российская компания Интерфейс - МФГ (Москва), американская компания BMS (Нью-Джерси).

Финансовый модуль системы не позволяет формировать отчетность Главной Книги в соответствии с российскими стандартами бухучета. Для формирования российской бухгалтерской отчетности разработана специальная программа, связывающая MFG/PRO с российскими бухгалтерскими системами.

MFG/PRO - открытая система, работающая в архитектуре клиент-сервер с СУБД Progress или Oracle Data Server.

MFG/PRO полностью русифицирована.

Система MFG/PRO представляет собой интегрированную, автоматизированную систему управления производственно-хозяйственной деятельностью предприятия, поддерживающую идеологию универсальных гибких цепочек процесса производства.

Предназначена для средних и крупных производственных предприятий.

Отрасли индустрии:

  • Машиностроение;
  • Химическая и фармацевтическая;
  • Пищевая;
  • Производство товаров народного потребления;
  • Производство электроники, электротехники, приборов;
  • Промышленное производство.

Функциональность:

  • Производство;
  • Финансовые операции;
  • Сбыт;
  • Материально-техническое снабжение;
  • Складское хозяйство;
  • Транспорт;
  • Управление проектом;
  • Техническое;
  • Сервисное обслуживание.

1.3.6. Сравнительные характеристики систем

Заканчивая обзор информационных систем, заметим, что объективные потребности российских предприятий диктуют использование наиболее современных технологий корпоративного управления (на базе MRP/ERP стандартов). В настоящее время для отечественных предприятий наиболее критичным являются ценовые характеристики ИСУП как по стоимости внедрения, так и по стоимости лицензий. Соотношение цена/качество (в т.ч. и сроки внедрения) ERP-систем делает наиболее предпочтительными продукт MFG/PRO (QAD). Эта система по стоимости может быть отнесена к колонке «Средние интегрированные системы» (см. Таблицу 10).

На рис. 17 представлена матрица оценки наиболее эффективного возврата инвестиций от ERP-систем. Матрица составлена по зарубежным данным.

Оценка ведется по двум параметрам :

    1. сроки внедрения (на примере проекта на 250 пользователей); 2. стоимость проекта.

Лидером среди ERP-систем оказывается продукт MFG/PRO корпорации QAD, внедряя который заказчики начинают получать выгоды от использования системы в среднем через пять месяцев. При этом стоимость проекта для 250 рабочих мест не превышает двух миллионов долларов США. Следует учитывать, что сюда включены и затраты на консалтинг и реорганизацию.

Лекция 2. Синхронизация внедрения ERP-системы с системой менеджмента качества

2.1. Связь между ERP-стандартами и стандартами качества серии ИСО 9000

Существуют разные взгляды на организацию управления промышленным предприятием. На многих отечественных предприятиях доминирующими являются следующие мнения:

  1. «наше предприятие уникально, и опыт других (особенно международный) для нас мало приемлем»;
  2. «если нам нужны изменения, то эти изменения должны быть радикальными и принести быстрый результат» – идеология «Большого скачка».

Многие исследователи определяют данные умонастроения российского менеджмента определяется как препятствия на пути успешного развитии предприятий. Можно с большой уверенностью утверждать, что:

во-первых - у предприятий существует специфики не более чем на 10 %, остальные 90 % деятельности - стандартны. Для улучшения дел на таких предприятиях необходимо опираться на передовой опыт других и «не изобретать велосипед». Квинтэссенцией такого опыта являются международные стандарты управления MRPII, ERP, CSRP, ISO 9000;

во-вторых – наши предприятия должны переломить существующее у них положение, когда сиюминутные проблемы не дают реализоваться важным перспективным решениям. У предприятий должны появиться долгосрочные цели. К этим целям они должны упорно двигаться, учредив постоянство перемен к лучшему, то есть изжить пустые иллюзии «большого скачка», заменив их на идеологию постоянного совершенствования - Business Process Improvement (BPI).

В данной лекции мы постараемся показать, что движение в сторону стандартизации методов управления является главным направлением развития экономики предприятий во всем мире (в том числе и в России); что стандарты управления являются инструментами реализации концепции BPI (постоянного совершенствования); что внедряя передовые методики управления предприятия получают практические результаты в виденепрерывного улучшения, а также критерии оценки достижения уровней совершенства (уровней BPI).

Сегодня многие отечественные предприятия не могут вырваться из кругооборота вредных эффектов и проблем (даже несмотря на наличие портфеля заказов) таких как:

  • слишком большое время, необходимое на освоение новой продукции или модификацию старой под требования заказчика приводит к недостаточной гибкости взаимодействия с клиентом;
  • такая негибкость обуславливает низкий уровень удовлетворенности клиента;
  • при низкой удовлетворенности клиента нет уверенности, что клиент в следующий раз захочет закупит продукцию, что ведет к трудностям прогнозирования сбыта;
  • ухудшение точности прогнозов сбыта приводит к хаотичным продажам, которые невозможно предсказать, поэтому предприятие вынуждено работать не на заказ, а на склад, что ведет к слишком ранним запускам продукции в производство;
  • ранние запуски в производство Готовой Продукции (ГП) по сравнению с реальными потребностями реализации этой ГП приводит к тому, что не удается сократить уровень Запасов;
  • увеличение Складских Запасов (СЗ) по материалам и ГП ведут к повышению издержек на хранение СЗ и к снижению оборачиваемости оборотных средств;
  • снижение оборачиваемости оборотных средств и увеличение накладных; расходов на персонал (для поддержки детальных требований к информации по планированию и управлению материальными ресурсами) обуславливает замораживание капитала;
  • замораживание капиталов предприятия ведет к невозможности за необходимый период освоить новые продукты или модифицировать старые под требования заказчика за счет существующих ресурсов (возможности привлечения сторонних ресурсов как правило отсутствуют).

Таким образом, форма «узкого коммерческого мышления» приводит к созданию негибких производственных систем. Решение любой из выше перечисленных проблем требует комплексного решения всех остальных проблем. Ключевым фактором выхода из «замкнутого круга» является достижение баланса целей предприятия (коммерческих, производственных и финансовых). Одинаково вредным для рентабельности является избыточное давление либо производственных, либо финансовых, либо коммерческих целей предприятия.

Мировой опыт показывает, что успех достигли компании, которые:

  • имеют системный взгляд на свою деятельность и рассматривают себя как единую производственно-сбытовая система (ПСС), интегрируя такие сферы как маркетинг – создание новых изделий – снабжение – производство – сбыт – доставку продукции потребителю – сервисное обслуживание;
  • используют для достижения технологической эффективности в качестве главной бизнес-модели промышленные ERP-стандарты;
  • используют стандарты серии ИСО 9000 в качестве базы для повышения качества Готовой Продукции.

В Таблице 1 соотнесено развитие стандартов ERP с развитием принципов управления качеством. Два этих направления («организация и управление производством» и «управление качеством») неразрывно связаны между собой, и являются инструментами повышения потенциала предприятия (под потенциалом понимается перспектива получения предприятием прибыли в будущем).

Как видно из Таблицы 1 источником развития ERP-стандартов и Стандартов Качества является «Научная организация труда» Ф. Тейлора. С развитием Вычислительной Техники (ВТ) произошло разделение на Систему Управления производством (которая опиралась на автоматизированную поддержку) и на Систему управления качеством (которая, помня заветы Э.Деминга, больше опиралась на бумажные процедуры и производственные философии). CALS-идеология, появившаяся в середине 80 гг. прошлого века, протянула мостик между «Автоматизированными Системами Управления(АСУ) и Проектирования(САПР)» и «Системой качества (СК)», вводя стандарты управления как структурированными документами (характерными для АСУ), так и неструктурированными документами (характерными для СК). С конца 80 гг. развитие АСУ было направлено в сторону Интегрированной Информационной Системы (ИИС), впитывающей в себя как CALS-технологии, так и методологии Системы Качества. Фундаментом такой интеграции стало:

  • С одной стороны - унификация понятия «жизненного цикла продукции» как в ERP-стандартах, так и в Стандартах Качества;
  • С другой стороны – «Принцип непрерывного улучшения деятельности предприятия», что заставило отказываться от жестких и застывших систем документирования производственных процессов (СК) и перейти к динамичным моделям, что невозможно без информационной поддержки таких моделей.

Таким образом, через пятьдесят лет раздельного развития, АСУ и СК в наше время вновь соединяются во «Всеобщем менеджменте предприятия» (другое название - «Гибкая система управления»). Прежний принцип специализации перестал работать. Чтобы управлять всеми процессами (охватывать все функции на современном предприятии) необходим целостный взгляд на объект управления, что невозможно без компьютеризации процессов. Из-за усложнения процессов на предприятии разработка уникальной Интегрированной Информационной Системы, опирающейся только на опыт данного предприятия стала не реальной. На помощь приходит «Компонентный подход» в построении ИИС и промышленные стандарты (ERP-стандарты). Те, кто унифицируют свою деятельность – выигрывают, упорствующие в своей уникальности строят «вавилонские башни» в области АСУ, которые обречены на то, чтобы рухнуть.

2.2. ERP-стандарты и Стандарты Качества как инструменты реализации принципа «Непрерывного улучшения»

2.2.1. Уровни Непрерывного улучшения бизнес-процессов (BPI)

Использование ERP-системы направлено на оптимизацию организации производства и управления предприятием , то есть на улучшение бизнес-процессов предприятия BPI (Business Process Imrovement). Философия в BPI констатирует, что достичь совершенства невозможно, но к нему нужно все время приближаться. BPI определяет уровни совершенства, или иначе уровни непрерывного улучшения бизнес- процессов предприятия (см. рис. 1).

Декларируется пять уровней улучшения бизнес-процессов на предприятии [8]:

  1. Динамик-Хаос - дисбаланс коммерческих, производственных и финансовых целей. Хаос характеризуется отсутствием системного взгляда, предприятие рассматривается как совокупность отдельных элементов;
  2. Контроль – балансировка коммерческих, производственных и финансовых целей предприятия. Данный уровень подразумевает «налаженный» учет и контроль основных мероприятий на предприятии;
  3. Оптимизация – оптимизация (упрощение) основных бизнес-процессов на предприятии, что ведет к снижению издержек;
  4. Адаптация – адаптивность бизнес-процессов к условиям внешней среды;
  5. Мировой класс – возможность предприятия формировать рынок.

Каждый BPI уровень можно охарактеризовать с точки зрения качества Готовой Продукции (ГП) и критериев управляемости процессов (то есть оценки бизнес - процессов на полноту и точность).

Определяются следующие критерии управляемости процессов:

  • Процесс признан как таковой (соответствует уровню BPI «Динамик-Хаос»), характеризуется хаотичностью и отсутствием стабильной внешней среды (ужас неопределенности); процессы на предприятии определены, но представляются как «черный ящик», то есть при заданных входных данных непредсказуем результат, что ведет к большим ошибкам в прогнозах и планировании (процессы на предприятии не имеют ни качественной ни, тем более, количественной оценки);
  • Процессы контролируемы (соответствует уровню BPI “Контроль»), характеризуется тем, что бизнес приобретает более устойчивый характер, основные бизнес-процессы повторяемы и управляемы; становится возможной успешная реализация задуманных проектов, но еще не достигается оптимизация, так как не точны нормативы процессов; основные процессы имеют описание, делаются попытки их качественной оценки;
  • Процессы оптимизированы (соответствует уровням BPI «Контроль» и «Оптимизация»), характеризуется тем, что полностью формализованы процессы как в управлении, так и в производстве; процессы документированы, стандартизованы и объединены в единый информационный поток; существует возможность оперативного получения информации о качестве использования ресурсов и проведения анализа по основным аспектам управленческой деятельности, то есть проведено нормирование процессов, на основании которого достигается оптимизация планирования; постановка долгосрочных целей базируется в основном на показателях предшествующего периода (преобладает аналитический аспект); начинает развиваться управление корпоративными знаниями на базе формирования системы метрик процессов;
  • Процессы адаптируемы (соответствует уровням BPI «Оптимизация» и «Адаптация»), характеризуется тем, что приоритеты смещаются в сторону оценки качества процессов (ведущих к повышению качества продукции и услуг); формируются внутрифирменные стандарты, цель которых количественное измерение качества всех процессов; планы (стратегические и оперативные) получают количественную оценку; принятия плановых решений опирается на явные знания, которыми обладает предприятие; стратегические и оперативные планы взаимоувязаны; обратная связь делает возможным эффективное согласование между оперативным и стратегическим уровнем управления;
  • Процессы экономичны и гибки (соответствует уровням BPI «Адаптация» и «Мировой класс»), характеризуется тем, что предприятие способно управлятькачеством процессов по всей цепочке, включая поставки, производство, сбыт, обслуживание; осуществляется оптимизация (то есть упрощение) бизнес-процессов; текущий контроль основан на управлении изменениями; формализация процессов и рыночные перспективы позволяют просчитывать стратегические планы и оптимизировать пути их достижения.

При определении уровней BPI декларируются следующие критерии оценки «Качества Готовой Продукции» (Рис.2):

«Соответствие стандарту» подразумевает то качество продукции, которое достижимо на существующем технологическом оборудовании предприятия и соотносится с BPI-уровнями «Динамик-Хаос» и «Контроль». На предприятиях, организация бизнес- процессов которых соответствует BPI уровню «Хаос», качество продукции является случайной величиной и напрямую зависит от способностей отдельных сотрудников. Качество продукции для BPI уровня «Контроль» уже является постоянной величиной за счет того, что предприятие из «черного ящика» превращается в «прозрачную систему», где налажен четкий производственный и управленческий учет и контроль.

«Соответствие использованию» определяется не только соответствием стандарту предприятия, но и удовлетворением эксплуатационных требований (потребностей потребителя). С этим уровнем качества продукции соотносятся такие BPI уровни как «Контроль» и «Оптимизация».

«Соответствие фактическим требованиям рынка» подразумевает высокое качество продукции по низкой цене. Продукция данного уровня качества может конкурировать с продукцией мировых производителей. С данным уровнем соотносятся такие BPI уровни как «Оптимизация» и «Адаптация»

«Соответствие скрытым потребностям» качество продукции данного уровня направлено на удовлетворение будущего спроса. Уровень «Соответствие скрытым потребностям» характерен для предприятий BPI уровня «Мировой класс».

2.2.2 Цикл BPI перехода на следующий уровень

Переход с одного уровня BPI на вышестоящий предполагает использование:

  • набора взаимосвязанных процессов, которые при совместном выполнении приводят к достижению набора целей, задаваемых для выхода на заданный уровень BPI (именуемых в дальнейшем Ключевых процессов/КП);
  • общих принципов процессов, определяющих каким должен стать процесс, чтобы обеспечить достижение набора целей, задаваемых для выхода на заданный уровень BPI (именуемых в дальнейшем практиками);
  • технологию реализации цикла BPI: использование определенного набора методик входящих в ERP-стандарты и стандарты Системы Менеджмента Качества; информационных технологий (ERP-система).

Переход предприятия с одного уровня BPI на вышестоящий(на базе ERP-системы) подразумевает использование определенного набора ключевых практик - практик ERP- стандарта, использование которых базируется на ERP-системе (Интегрированной информационной системе управления предприятием).

В основу перехода предприятия с одного уровня BPI на следующей положено предварительное моделирование бизнес-процессов предприятия и внедрение новой бизнес-модели в практику.

Для критерия оценки перехода на следующий уровень BPI выделяются только те процессы, которые необходимы для данного перехода. Все оценки процессов нижних уровней BPI присутствуют на более высших уровнях BPI, но с более детальными к ним требованиями. Таким образом, переход с одного уровня BPI на вышестоящий предполагает использование:

  1. набора взаимосвязанных процессов, которые при совместном выполнении приводят к достижению набора целей, задаваемых для выхода на заданный уровень BPI (Ключевых процессов/КП);
  2. общих принципов процессов, определяющих каким должен стать процесс, чтобы обеспечить достижение набора целей, задаваемых для выхода на заданный уровень BPI (именуемых в дальнейшем ключевыми практиками);
  3. технологию реализации цикла BPI (использование приемов и информационных технологий).

Достижение всех целей в рамках КП для заданного уровня BPI определяет соответствие организации данному уровню. Если хотя бы одна цель хотя бы одной КП для уровня BPI не достигнута, то организация не может соответствовать данному уровню BPI. КП можно разбить на три категории: управляющие, организационные и обеспечивающие (Таблица 2). BPI не определяет все процессы, имеющие отношение к жизненному циклу продукции; выделяются только те, которые необходимы для достижения уровня BPI, они и включаются в Ключевые Процессы.

Переход предприятия с одного уровня BPI на другой именуется циклом BPI. При каждом цикле BPI используются определенный набор методик, входящих в ERP- стандарты и стандарты Системы Качества.

2.2.3 Цикл BPI - балансировка и внутренняя рационализация (переход с I уровня на II)

На данном цикле ставится задача внедрения в реальное пользование методики MRPII и производственного учета. В рамках ERP-системы должны быть определены и отлажены:

  • система учета затрат;
  • система многоуровнего планирования (MRPII);
  • система контроля и диспетчирования.

Использование MRPII на данном цикле BPI позволяет предприятию продвинуться от "Динамик-Хаос" к "Контролю" и осуществить балансировку производственных, коммерческих и финансовых целей предприятия за счет многоуровнего планирования.

Совместно с внедрение MRPII подразумевается и внедрение ERP-системы, где ERP является развитием MRPII с точки зрения охвата операционного менеджмента и финансовых потоков.

2.2.4 Цикл BPI - объединение с поставщиками (переход с II уровня на III)

Только после выхода предприятия на II-й уровень BPI могут быть по-настоящему эффективны поставки «точно – в - срок» (JIT), без избыточных хранилищ и обработки материалов.

Данный цикл развивает связи с поставщиками и подразумевает решение таких задач как:

  • задачи анализа данных о затратах и результатах хозяйственной деятельности в разрезе необходимых для управления объектов;
  • задачи оперативного принятия управленческих решений для расшивки узких мест и оптимизации финансовых результатов;
  • задачи взаимодействия с поставщиками для понимания и поддерживания общих требований к деятельности предприятия.

Философия JIT помогает предприятию оптимизировать достижение сбалансированных целей, вводя критерии оценки эффективности плана. Философия JIT гласит, что - убыточно все, что увеличивает издержки, но не увеличивает ценность продукции. Основные принципы JIT ориентированы на:

  • повышение эффективности производства (снижение длительности цикла),
  • повышение качества (принцип «ноль дефектов»),
  • активизацию человеческого фактора.

JIT призвана обеспечить производство качественной продукции по более низкой цене за более короткое время. Реализация философии JIT для средних и крупных предприятий базируется на использовании ERP-системы.

2.2.5 Цикл BPI - рационализация и развитие клиентов (переход с III уровня на IV)

Этот цикл начинается только после того, как процессы I –го и II-го уровней BPI работают, и на предприятии реализуется идеология JIT «точно-в-срок».

На данном цикле налаживается взаимодействие с клиентами с целью совершенствования продукции и перспективного планирования рыночных тенденций, наряду с философией JIT начинает использоваться методология CSRP.

CSRP делает возможным планирование ресурсов предприятия в зависимости от потребностей клиента, осуществляя адаптацию бизнес-процессов к внешней среде за счет интеграции предприятия с внешними агентами.

MRP и ERP методологии охватывают производственный и логистический циклы изделия. Методика CSRP охватывает весь жизненный цикл товара.

Методология CSRP позволяет при планировании и управлении предприятием учитывать не только основные производственные и материальные ресурсы предприятия, но и все те ресурсы, которые обычно рассматриваются как «вспомогательные» или «накладные».

CSRP перемещает фокус внимания с планирования производства к планированию заказов покупателей. Производственное планирование не просто расширяется, а замещается требованиями клиентов, поступающими из подразделений, ориентированных на работу с покупателями.

CSRP заставляет пересмотреть бизнес-логику, фокусируя её на рыночной активности, а не на производственной деятельности. Бизнес-процессы синхронизируются с деятельностью покупателей. Результаты успешного применения CSRP - это повышение качества товаров, снижение времени поставки, повышение потребительской ценности продукции, и т.д., а в результате этого:

  • снижение производственных издержек,
  • развитие инфраструктуры для создания индивидуализируемых, конфигурируемых решений;
  • улучшение обратной связи с покупателями;
  • обеспечение лучшего сервиса для покупателя.

Это не технологическая эффективность, которая обеспечивает лишь временное конкурентное преимущество, это - способность создавать продукты, удовлетворяющие разнообразным потребностям покупателя и лучший сервис, то есть - получение устойчивого конкурентного преимущества.

2.2.6 Цикл BPI - одержимость качеством (переход с IV уровня на V)

Управление Качеством рассматривается как составная часть общей системы управления предприятием. Система Качества присутствует во всех элементах управления бизнесом как критерий достижения постоянного роста потенциала предприятия и на всех уровнях BPI.

Стандарт системы качества ИСО 9000:2000 базируется на философии Тотального Управления Качеством (TQM), которая может быть определена как оптимизация деятельности всех частей и функций организации.

Цель данного цикла BPI – внедрение на предприятии культуры качества, где каждый предан непрерывному усовершенствованию во всем, что делается в каждодневной работе. TQM включает базовые элементы, которые существенно расширяют понятие системы качества и могут быть реализованы с помощью ERP- системы.

Определены следующие фазы развития качества, фиксирующие проникновение философии TQM на предприятие.

2.3. Результаты , необходимые для выхода на следующий уровень BP

2.3.1. Ключевые процессы и экономический эффект перехода на II-й уровень BPI

Переход с I–го на II-й уровень BPI предполагает использование ключевых процессов , которые при совместном выполнении приводят к достижению целей внедрения новой бизнес - модели предприятия на базе методики MRPII и технологий ERP-системы.

Ключевыми процессами при достижения II уровня BPI являются (см . рис . 3):

  • управление требованиями клиентов;
  • планирование;
  • диспетчирование производства;
  • управление снабжением;
  • обеспечение качества;
  • управление Складскими Запасами.

Практическое использование MRPII при реализации новой бизнес -модели приводит к сокращению :

- логистического цикла , то есть времени перемещения материальных потоков от поставщика к потребителю продукции ;

- производственного цикла , то есть длительности изготовления продукции ;

Сокращение логистического цикла происходит :

За счет сокращения страховых запасов материалов . Страховые запасы формируются из -за того , что никто на предприятии не знает времени доставки материалов поставщиками , нормирование данного времени по элементам номенклатуры и по поставщикам , накопление статистик и выбор поставщика с учетом «надежности поставок », ведет к предсказуемости длительности срока поставок и к сокращению страховых запасов материалов .

За счет сокращения запасов Готовой Продукции . Введение в практику прогнозов отгрузки ГП , накопление статистики по потребности ГП потребителями (то есть точного прогнозирования ), и точного запуска в производство выпуска ГП (то есть работать под заказ , а не на склад ).

Сокращение производственного цикла происходит:

  • за счет сокращения времени настройки оборудования и времени перемещения;
  • за счет оптимального расчета партий запуска деталей;
  • за счет сокращению времени выпуска изделий, исключив возвраты по технологическим операциям и переделу брака.

Это достигается с помощью набора статистики дефектов по рабочим центрам , работникам , деталям , техкартам , и с помощью строгой технологической дисциплины , когда Наряд Задание не запускается в производство , если нет Спецификации и техкарты изготовления .

Сокращение данных циклов ведет к сокращению Складских Запасов (СЗ ) (по данным западных исследователей от 15 до 50 %) и уровня Незавершенного Производства (НЗП ).

Внедрение MRPII на базе ERP-системы имеет также и косвенные выгоды , такие как :

  • снижение доли непроизводительного труда за счет сокращения процессов , не приносящих добавочную стоимость ;
  • сокращение коммерческого цикла за счет более четкой организации оформления и заключения заказов на продажу и закупку ;
  • сокращение цикла оборачиваемости оборотных средств за счет более четкой организации управления счетами дебиторов и кредиторов ;
  • повышение гибкости реагирования на требования потребителей .

Фиксация фазы внедрения новой бизнес -модели осуществляется только после того , как предприятие начинает получать реальную экономическую выгоду от использования MRPII.

2.3.2. Оценка достижения II-го уровня BPI по ключевым процессам

Ниже приводятся цели КП и количественные показатели их достижениях для уровня BPI «Контроль », где делается акцент на поэтапное достижение целей КП за счет пошагового внедрения практик КП , которое позволит предприятию достичь уровень BPI «Контроль »:

0% - практики КП не внедрены . Описание в бизнес -модели желаемых способов выполнения КП (1 этап ). Данный этап позволяет проиграть разные сценарии улучшения , то есть разные комбинации желаемых способов выполнения процессов предприятия ;

20% - внедрено 20% от объема всех практик КП (2 этап ) ;

60% - внедрено 60% от объема всех практик КП (3 этап );

100 - внедрено 100% от объема всех практик КП (4 этап );

Далее будут рассмотрены цели в Ключевых Процессах . Ключевые Процессы соотносятся с элементами стандарта ИСО 9001:2000. Качественная и количественная оценка Ключевых Процессов соответствует следующим уровням BPI:

  • 20 % - 1-й уровень BPI;
  • 40 % - 2-й уровень BPI;
  • 60 % - 3-й уровень BPI;
  • 80 % - 4-й уровень BPI;
  • 100 % - 5-й уровень BPI.

Таким образом , достижение 40% по всем шести Ключевым процессам будет означать , что предприятие вышло на II-й уровень BPI. Если хотя бы у одного Ключевого Процесса не достигнута оценка 40 %, то считается , что предприятие находится на первом уровне BPI. Далее мы будем рассматривать использования практик , предложенных компанией QAD на базе ERP-системы MFG/PRO, для перехода предприятия с уровня I на уровень II.

2.3.3. Планирование (ИСО 9001:2000–«7.1.Планирование процессов реализации »)

КП «Планирование » в общем контексте внутрифирменного планирования является одним из уровней многоуровневого планирования , включающего :

«Стратегическое и годовое тактическое планирование », определяющее задачии финансовые результаты , которые организация хочет достичь в заданный плановый период ;

«Объемно -календарное планирование », определяющее понедельный график выпуска Готовой Продукции .

«Наряд -Задание на выполнение работ », подразумевающее детализацию выполнения работ до индивидуальных заданий исполнителям с определением технологической карты и маршрута изготовления ДСЕ , комплектации материалов , нормативной себестоимости работ , критериев качества .

Первый уровень планирования реализуется с помощью финансового планирования с детализацией данного плана по отдельным бюджетам предприятия .

Второй уровень планирования не является жестким требованием , а , скорее , прогнозом производства и реализации продукции .

Требования к исполнению точно в срок планового задания связано не со II-м , а с III-м уровнем планирования – «Задание на выполнение работ ».

КП «Планирование » ставит следующие цели :

  1. базовые данные , используемые для планирования (нормативы на организационный и элементные аспекты ), должны подлежать формализации , учету в ИС и непрерывному уточнению ;
  2. реализация планов должна отслеживаться ;
  3. действия и обязательства по осуществлению планирования должны стать повседневной практикой . Задействованные группы и личности должны выполнять обязанности , связанные с планом .

Ключевыми приемами (для данного КП ) являются следующие методики :

  • Для I-го уровня планирования : Управление планированием продуктовой линии / ТНГ ; Управление укрупненным планированием ресурсов (RCP);
  • Для II-го уровня планирования : Управление планирования Главного Календарного Графика / MPS; Управление планированием Возможности Использования Ресурсов (RCCP);
  • Для III-го уровня планирования : Управление планированием потребности материалов (MRP); Управление планированием потребности мощностей (CRP); Управление планированием возможностей распределения (DRP).

2.3.4. Управление требованиями потребителя (ИСО 9001:2000 – «7.2 Процессы , связанные с потребителем »)

В КП «Управление требованиями » описывается порядок действий , обеспечивающий появление понятных всем сторонам (и заказчику и исполнителю ) требований к конечному продукту , то есть - «Заказ на продажу » с параметрами , удовлетворяющими , как потребителя , так и поставщика . Таким образом , целью КП является , чтобы :

1. Требования согласованны с потребителем ГП ; условиям поставки ГП , должны быть исполнимыми , выгодными для предприятия , контролируемыми и являться основой для планирования и диспетчирования производства .

Ключевыми приемами (для данного КП ) являются следующие методики :

  • управление ценообразованием ;
  • управление «Заказами на продажу »;
  • управление «Долгосрочными контрактами с потребителями »;
  • управление отправками потребителям ;
  • управление сервисными услугами потребителю ;
  • управление конфигурированием изделий под заказ ;
  • управление счетами дебиторов ;
  • управление анализом продаж .

2.3.5. Управление снабжением (ИСО 9001:2000 – «7.4 Закупки »)

КП «Управление снабжением » определяет процессы , связанные с оценкой , выбором и организацией работ с поставщиками . Данный КП определяет следующие цели :

  1. предприятие должно выбирать только качественных поставщиков (не более трех на каждый вид материала или покупные ) и строить отношения на долгосрочной основе , поддерживать постоянную связь ;
  2. предприятие и поставщик должны согласовать друг с другом свои обязательства , заключив долгосрочные контракты на поставку ;
  3. предприятие должно постоянно отслеживать реальные результаты деятельности поставщика в сравнении с его обязательствами . Результаты анализа должны быть формализованы и учтены в ИС посредством отслеживания нормативов по времени доставки материалов и точке заказа .

Ключевыми приемами (для данного КП ) являются следующие методики :

  • управление «Заявками на Закупку »;
  • управление «Заказами на Закупку »;
  • управление «Долгосрочными контрактами с поставщиками »;
  • управление получением /возвратом материалов ;
  • управление входным контролем качества материалов и прослеживаемостью полученной партии материалов ;
  • управление прайс -листами поставщиков и нормативами по доставке продукции ;
  • управление счетами кредиторов ;
  • управление анализом деятельности поставщиков .

2.3.6. Диспетчирование производства (ИСО 9001:2000 – «7.5.1 Управление деятельностью », «8.2.3 Измерение и мониторинг процессов »)

КП «Диспетчирование » подразумевает учет процесса выполнения работ по закрытию Наряд Заданий . В рамках данной КП производится детальное диспетчирование по видам работ в разрезе каждого конкретного исполнителя и Рабочего Центра , тем самым накапливаются статистические данные для формирования метрик (количественных характеристик действующих процессов предприятия ). Процесс диспетчирования подразумевает автоматическое накопление данных для их дальнейшего анализа и преобразования в нормативы .

При наличии третьего уровня планирования контроль за ходом проекта необходимо производить в рамках спланированных заданий , обеспечивая реальное диспетчирование работ и исполнения плановых заданий , контроль за возникновением узких мест в реальном режиме времени .

Данный КП ставит следующие цели :

  1. Базовые данные , используемые при диспетчировании (нормативы на организационный и элементные аспекты ), должны подлежать формализации , учету в ИС и непрерывному уточнению ;
  2. Результаты и характеристики выполняемых работ должны постоянно сравниваться с нормативами . Корректирующие действия должны выполняться тогда , когда действительные результаты значительно отклонились от плановых .

Ключевыми приемами (для данного КП ) являются следующие методики :

  • управление спецификациями изделия (формулами изготовления );
  • управление техкартами (процессами );
  • управление Рабочими Центрами ;
  • управление нормативной и текущей себестоимостью изделия ;
  • управление производственными рабочими ;
  • управление Наряд -Заданиями ;
  • управление производственным контролем ;
  • управление поточным производством .

2.3.7. Обеспечение качества Готовой Продукции (ИСО 9001:2000 «8.2.4 Измерение и мониторинг продукции »)

Данный КП определяет следующие цели :

  1. деятельность по контролю качества продукции должна планироваться : нормативы по качеству , последовательность действий в рамках управления качеством ;
  2. должен обеспечиваться объективный контроль за строгим соответствием продукции и процессов принятым стандартам , процедурам и требованиям ;
  3. задействованные группы и конкретные работники должны информироваться о действиях по обеспечению качества и об их результатах ;
  4. вопросы несоответствия требованиям , которые невозможно разрешить в оперативном режиме , должны решаться на высшем уровне организации .

Ключевыми приемами (для данного КП ) являются следующие методики :

  • управление нормативами по качеству продукции (тесты );
  • управления Заказами Качества ;
  • управление операциями контроля качества в рамках Наряд -Заданий ;
  • управление учетом брака , исправления брака , простоям по Наряд -Заданиям в разрезе операций , работников и рабочих центров ;
  • управление статистикой по итогам контроля качества ;
  • управление дефектами оборудования и др . производственных элементах .

2.3.8. Управление складскими запасами (ИСО 9001:2000 – «7.5.2 Идентификация и прослеживаемость » , «7.5.4 Консервация продукции »)

Данный КП ставит следующие цели :

  1. складские Запасы должны быть пронормированы (по требованию к складским помещениям , по точке заказа , по стоимости , по фрахту , по срокам хранения );
  2. используемые для производства материалы и ДСЕ должны быть идентифицируемы , управляемы и прослеживаемые .

Ключевыми приемами (для данного КП ) являются следующие методики :

  • управление складской инфраструктурой ;
  • управление элементами запасов и складскими нормативами по позициям ;
  • управление контролем Складских Запасов ;
  • управление инвентаризацией ; - управлением А BC-анализом Складских Запасов .

2.4. Заключение

В лекции используются такие термины как философия (JIT, TQM), методика (MRPII, ERP, CSRP, ISO 9000) и технология (ERP-система , CASE-средства , CALS).

    Внедрить новые технологии можно за 1 год .
    Внедрить новые методики управления можно за 2 года .
    Внедрение новой производственной философии осуществляется минимум 4 года .
    Переход предприятия с одного уровня BPI на следующий есть в большей степени изменение производственной философии на предприятии , а методики и технологии являются инструментами данного культурологического преобразования предприятия .
Внедрение ERP-системы можно рассматривать как начало процесса значительного улучшения организации и управления предприятием , начало перехода предприятия на новые производственные философии . Для успешного внедрения ERP-системы необходимо учитывать , что именно ЛЮДИ , работающие на предприятии , могут использовать или не использовать методик MRP II, JIT, CSRP, заложенные в основу данной Информационной Системы . Для того , чтобы ЛЮДИ прониклись новыми методиками , необходима программа обучения . Закрепление программы обучения и обеспечение регулярного использования методик в рамках ERP-системы осуществляется методами Системы Качества (методы обеспечения качества , методы стимулирования качества , методы контроля результатов по качеству ) и базируется на принципах «Лидерства » и «Вовлечение персонала ».

Таким образом , успешное использование принципа «Непрерывного улучшения » (BPI) основывается на пересечении трех областей знаний (см . рис . 4).

Область А - развитие Информационных Технологий :

  1. использование профессиональных операционных систем (для серверов Баз Данных ) и персональных компьютеров ;
  2. использование профессиональных Систем Управления Базами Данных (СУБД );
  3. использование ERP-систем как ядра Интегрированной Информационной Системы предприятия ;
  4. использование кооперативных технологий , обеспечивающих компьютерную поддержку параллельной согласованной работы группы («команды ») сотрудников над одним проектом , документом и т . п .;
  5. использование телекоммуникации , позволяющую исключить передачу бумажных документов и личных встреч , свести к минимуму необходимость переездов для проведения совещаний ;
  6. использование Систем Управления Знаниями для организации хранилища и поиска неструктурированных документов ;

Область В - развитие бизнес -платформ , включающей :

  1. методики Управления Качеством (то есть целостная идеология управленияпредприятием ) на базе стандартов ИСО серии 9000 в редакции 2000 г .;
  2. методики Организации операционного менеджмента (ERP-стандарты );
  3. методики Управления требованиями и конструкторскими разработками (CALS- стандарты );
  4. методики моделирования бизнес -процессов (SADT, IDEF0, DFD, UML).

Область С определяет “психологию труда ” и направлена на решение следующих задач :

  1. внедрение принципа «Лидерства » (устранение недостатков производственной системы , а не отдельных работников );
  2. внедрения принципа «Вовлечения работников » (повышение значимости и инициативности каждого работника );
  3. снятие барьеров между производственными подразделениями , организация групповой «артериальной работы »; образование так называемых «плоских » рабочих групп , использующих эдхократические (эдхократия – компетентная бюрократия ) способы управления , опирающиеся на Информационные Технологии и организующие динамическое и неформальное распределение прав и обязанностей сотрудников группы (такие группы реактивны , никому не дают монополию на истину , требуют проработку альтернативных решений );
  4. формирование корпоративной культуры и повышения эдхократии в организации ;
  5. внедрения философии Тотального Управления Качеством на всех рабочих местах (TQM);
  6. внедрение философии организации производственных процессов «Точно во время » на всех рабочих местах (JIT).

В недавнем прошлом руководители отечественных предприятий , осознавая значительные культурные различия между нами и Западом , предполагали , что западные методики не будут работать в России . Однако когда ряд западных фирм открыли свои производства в России и добились успеха на нашем рынке , всем стало ясно , что рассмотренные выше методики могут успешно работать и на отечественных предприятиях .

Часть II

Лекция 3. Общие сведения о системе MFG/PRO

Как уже отмечалось, MFG/PRO является одной из лучших существующих систем автоматизации управления промышленными предприятиями. Она решает задачи автоматизации управления деятельностью средних и крупных предприятий в автомобильной, авиационной, электронной, электротехнической, химической, фармацевтической и пищевой, промышленности.

MFG/PRO – лучшее решение для крупных и средних промышленных предприятий с дискретным типом производства

Использование системы MFG/PRO помогает оптимизировать основные бизнес- процессы предприятия и позволяет получать всю необходимую информацию для управления на всех уровнях компании. Система поддерживает все типы сборочного производства: серийное/поточное, штучное, "на заказ".

В системе MFG/PRO, по сравнению с аналогичными решениями других производителей, наиболее полно реализованы стандарты планирования материальных ресурсов, а небольшие сроки внедрения системы делают ее особенно привлекательной для динамично развивающейся экономики России.

MFG/PRO поддерживает следующие направления хозяйственной деятельности предприятий:

  1. производство
  2. продажи и закупки
  3. финансовые операции
  4. материально-техническое снабжение
  5. складское хозяйство
  6. техническое и сервисное обслуживание
  7. управление проектами

MFG/PRO используют:

  • 4 из 5 крупнейших компаний, производящих электронику
    - Siemens, Hitachi, Matsushita Electric Industrial, Royal Phillips Electronic
  • 3 из 4 крупнейших производителей медицинского оборудования
    - Medtronic, Becton Dickinson, Boston Scientific
  • 4 из 5 крупнейших производителей напитков
    - PepsiCo, Coca-Cola, Diageo, Anheuser-Busch
  • 2 из 4 крупнейших компаний пищевой промышленности
    - Unilever, Sara Lee
  • 13 из 25 крупнейших компаний автомобильной промышленности
    - Ford Motors, Volvo, Volkswagen, Honda, Yamaha, Daewoo, Subaru и др.

MFG/PRO используют также компании Colgate-Palmolive, Heinz, Mars, Ford, Xerox,

General Electric, Johnson&Johnson, Alcoa, Gillette, Caterpillar, Black&Decker, Avon, AT&T,

Quaker, Kraft и многие другие известные компании.

Внедрение системы позволяет существенно повысить эффективность деятельности предприятия за счет:

  • четкого выделения центров затрат и прибыли;
  • полного оперативного контроля за издержками и доходами;
  • прозрачности для руководства финансовых потоков предприятия;
  • оперативного получения необходимой для принятия управленческих решений информации;
  • широких возможностей анализа и планирования всех видов деятельности.

Как показывает мировой опыт, использование MFG\PRO обеспечивает:

  • уменьшение складских запасов как минимум на 25%;
  • снижения по незавершенному производству не менее чем на 40%;
  • уменьшение времени на подготовку к производству в среднем на 50%;
  • улучшение в обслуживании заказчиков по качеству выполнения поставок и сервисного обслуживания на 60%.

3.1. Серия «Производство»

Эта серия используется для управления производственной деятельностью предприятия. Она поддерживает различные типы производственных процессов (серийное производство, производство "на заказ" и т.д.) и состоит из модулей:

  • наряды на производство;
  • поточное производство / расширенное поточное производство
  • структура продукции;
  • центры выполнения работ и технологические карты;
  • формула / технологический процесс;
  • учет побочной продукции;
  • MRP (планирование материальных ресурсов)
  • планирование загрузки мощностей
  • контроль качества;
  • прогнозирование / разработка главного календарного плана.

3.1.1. Наряды на производство

MFG/PRO поддерживает два основных вида производственных процессов: дискретное производство и производство непрерывным потоком. Дискретное производство обычно управляется при помощи нарядов на производство. В MFG/PRO производственные модули позволяют осуществлять календарное планирование и контролировать производство любого типа. Могут быть отражены в любой комбинации производство продукции "на склад" или "на заказ", дискретный или непрерывный метод производства, производство непрерывным потоком или партионное производство.

3.1.2. Поточное производство / Расширенное поточное производство

MFG/PRO обеспечивает два способа управления поточным производством. Модуль "Поточное производство" используется при следующих условиях:

  1. время производства относительно небольшое и партии не перекрываются;
  2. процесс завершается к концу каждого рабочего дня;
  3. объем незавершенного производства либо незначителен, либо постоянен;
  4. технологические карты не содержат субконтрактных операций.

Модуль "Расширенное поточное производство" поддерживает следующие типы производственного процесса:

  1. длительные по времени производственные циклы;
  2. продолжительные производственные процессы: каждая линия выпускает одну номенклатурную единицу на протяжении нескольких дней, недель, месяцев;
  3. объем незавершенного производства либо высок, либо не постоянен;
  4. позволяет использовать субконтрактные операции;
  5. партии могут перекрываться, и необходим контроль над работами в процессе.

3.1.3. Структура продукции

Однажды определив в справочниках материалы и комплектующие, входящие в состав готовой продукции, система будет отслеживать их движение и участие во всех производственных процессах.

3.1.4. Центры выполнения работ и технологические карты

В этом модуле определяются центры выполнения производственной деятельности (цеха, подразделения) и, соответственно, их производственные процессы.

3.1.5. Формула / Технологический процесс

В этом модуле определяются отношения между продуктами и ингредиентами, входящими в них, а также процессами, при помощи которых эти продукты были произведены. Другой способ определения структуры продукта – это формула, согласнокоторой изготавливается соответствующий продукт. При этом MFG/PRO позволяет указывать, из каких ингредиентов состоит продукт, как в количественном выражении, так и в процентном соотношении.

3.1.6. Учет побочной продукции

Результатом какого-либо процесса может являться не только основной продукт, но и сопутствующие или побочные продукты (отходы). Параллельно с основными процессами, система позволяет управлять процессами производства сопутствующей (побочной) продукции. При этом поддерживаются различные типы производственных процессов:

  • смешивание ингредиентов, например при производстве лекарственных препаратов
  • сортировка продукции в зависимости от каких-либо характеристик, например размера, веса или качества
  • декомпоновка, как, например, кожура и сок при производстве апельсинового сока
  • склеивание, например, при производстве пластиковых корпусов из мелких частей

Модуль обеспечивает мощную поддержку этих процессов на таком же качественном уровне, как и основное производство.

3.1.7. MRP (Планирование материальных ресурсов)

Одной из ключевых функцией планирования производства является планирование потребности в материалах. При помощи этого модуля оценивается предложение и спрос, и формируются плановые заказы. Для организаций с несколькими заводами MRP может быть использовано совместно с модулем Планирования внутренних материальных потоков, который балансирует предложение и спрос между заводами. Модуль содержит программы для формирования плана потребности в материалах.

3.1.8. Планирование загрузки мощностей

Модуль Планирования загрузки мощностей (CRP) формирует план потребности в мощностях для оборудования, отдельных цехов и центров выполнения работ. В модуле информация о запланированных поступлениях заказов и подтвержденных заказах используется для определения загрузки центров. Далее эти данные могут быть представлены в отчетах для отдельных единиц оборудования или целых цехов.

3.1.9. Контроль качества

Модуль контроля качества позволяет тестировать входящие материалы, готовую продукцию и запасы; инспектировать процессы, номенклатурные позиции в процессе. Все операции по тестированию обязательно документируются по месту, времени и методу проверки. Вы можете определить спецификацию процедуры тестирования, и зафиксировать результаты испытаний.

3.1.10. Прогнозирование/Разработка Главного календарного плана

Прогнозирование/Разработка Главного календарного плана охватывает возможности создания системы замкнутого цикла, где анализируется история отгрузок по продажам, прогнозируется спрос, осуществляется планирование потребностей в материалах. Модуль предоставляет широкие возможности по настройке методов рогнозирования, в том числе допускает добавление новых методов построения прогнозов.

3.2. Серия «Продажи и закупки»

Серия используется для контроля за состоянием товарно-сырьевых запасов на складах, управления закупками и сбытом продукции. Серия состоит из следующих модулей:

  • закупки
  • квотирование продаж;
  • заказы на продажу / Счета;
  • централизованное управление заказами;
  • заказы на поставку;
  • доставка;
  • компоновка продукции;
  • анализ продаж.

3.2.1 Закупки

Модуль закупок позволяет полностью контролировать процесс поставок материалов и услуг. Сырье для производства, вспомогательные материалы, не участвующие в основном производственном цикле, услуги сторонних организаций по поддержанию производственного оборудования в надлежащем состоянии — все это учитывается в системе. Это обеспечивает слаженное функционирование всего предприятия. Существует возможность взаимодействия с дополнительным модулем EMT (Enterprise Material Transfer), который позволяет автоматически переводить заявки покупателей в заявки на закупку необходимого сырья. В стандартном MRP заявка покупателя на приобретение становится заказом, который в свою очередь трансформируется в заявку на приобретение сырья для поставщика. EMT позволяет сократить время за счет автоматизации большей части этих шагов.

MFG/PRO поддерживает два типа квотирования: для одиночных и для повторяющихся продаж. Для повторяющихся продаж, на основании договоренности с покупателем, система позволяет ввести предположительное количество и периодичность закупок. Дополнительный модуль Release Management позволяет устанавливать специальный график продаж для каждого покупателя отдельно. Соответственно, этот график может учитываться при планировании производства.

3.2.2 Заказы/Счета-фактуры

В этом модуле происходит обработка заказов и формирование необходимых документов на отгрузку продукции. Система позволяет рассчитать транспортные затраты в зависимости от веса заказанной продукции, просмотреть и изменить любую информацию, использующуюся при расчете затрат, а также изменить порядок автоматического расчета затрат. Модуль предоставляет возможность учета тары, возвратов, а также генерации всевозможных отчетов.

3.2.3. Централизованная обработка заказов

Централизованная обработка заказов применяется в том случае, когда все продажи роходят через один центральный офис. Все заказы хранятся в базе данных центрального офиса, а распределенные производственные площадки имеют свои локальные базы данных. Компании, использующие централизованную обработку заказов, получают возможность обрабатывать большие заказы и снизить потери связанные с распределенной структурой отдела продаж.

3.2.4. Доставка

MFG/PRO предоставляет мощный инструмент для организации всевозможных типов доставки: от простейших до глобальных международных перевозок. При этом поддерживаются различные способы хранения: централизованный склад или распределенная сеть складов.

3.2.5. Компоновка продукции

Система позволяет определять собранную продукцию, как, например автомобиль, состоящий из множества комплектующих. MFG/PRO оперирует с такого вида продукцией, как с обычной: позволяет оформлять заказы, сборку, доставку покупателю.

3.2.6. Анализ продаж

Модуль "Анализ продаж" предоставляет мощные инструменты для генерации различных отчетов с группировкой по позициям, линейке продуктов, покупателям, местам доставки, менеджерам по продаже и т.д. Эта информация может далее служить для прогнозирования спроса, а также для предоставления отчетности заинтересованным сторонам.

3.3. Серия «Финансы»

Эта серия полностью интегрирована с сериями «Производство», «Продажи и распределение» и модулями планирования, позволяет оперативно получать информацию о финансовом состоянии компании и принимать правильные решения по финансово- экономическим вопросам. Серия состоит из модулей:

  • главная бухгалтерская книга;
  • учет для нескольких юридических лиц
  • валютные операции;
  • кредиторская задолженность;
  • дебиторская задолженность;
  • обработка платежей;
  • расчет себестоимости;
  • управление денежными средствами.

3.3.1. Главная бухгалтерская книга

Главная бухгалтерская книга – это система счетов, которые отражают значения активов, пассивов, капитала предприятия, доходов и расходов.

3.3.2. Учет для нескольких юридических лиц

В одной базе данных можно вести несколько юридических лиц. В главной бухгалтерской книге можно установить несколько юридических лиц, и тогда система втоматически рассчитает балансирующие записи и запишет их на межфирменный (корпоративный) счет.

Для ограничения доступа пользователей на обновление информации главной бухгалтерской книги по определенным юридическим лицам предусмотрены специальные меры. Пользователи могут распечатывать отчеты или просматривать информацию по запросам по любому юридическому лицу. Однако вводить транзакции, вести бюджеты и участвовать в других операциях обновления пользователи могут только в тех юридических лицах, к которым им открыт доступ.

3.3.3. Валютные операции

Система поддерживает учет в различных валютах, в том числе и в евро, при этом Вы можете задавать курсы пересчета.

3.3.4. Кредиторская задолженность

Модуль кредиторской задолженности используется для записи сумм, причитающихся к уплате поставщикам, а также для обработки и печати платежей на эти суммы.

Модуль может использоваться самостоятельно, а также совместно с другими модулями, включая модуль закупок.

3.3.5. Дебиторская задолженность

Модуль дебиторской задолженности учитывает суммы, ожидающиеся к поступлению от заказчиков. Модуль позволяет создавать проводки по дебету/кредиту, обрабатывать платежи, рассчитывать просрочки и штрафы, отслеживать балансы покупателей, выпускать векселя и письма о неуплате.

3.3.6. Обработка платежей

Модуль используется для записи платежей покупателей и прочих денежных поступлений (например, возвращаемых налогов). MFG/PRO поддерживает три типа платежей:

  • выставленные (погашенные финансовые задолженности). Этот тип используется для записи платежей покупателей по определенным счетам-фактурам, проводкам или штрафным санкциям;
  • невыставленные (авансовые платежи). Этот тип используется для записи денежных средств, получаемых от покупателей, которые не связаны с какими-либо документами. Это может быть, например, предоплата по будущему счету-фактуре или переплата;
  • прочие поступления. Этот тип используется для записи денежных средств, которые не находят никакого отражения в счетах-фактурах, проводках или штрафных санкциях. Например, возвращаемые налоги или скидки.

3.3.7. Расчет себестоимости

В зависимости от текущих потребностей модуль позволяет использовать различные системы расчета себестоимости: фиксированная, усредненная, периодическая или реальная.

3.3.8. Управление денежными средствами

Модуль позволяет управлять входящими и исходящими потоками наличных денег и отслеживать текущее состояние.

3.4. Блок «Техническое обслуживание»

Блок обеспечивает послепродажное техническое обслуживание и поддержку производственных мощностей и проданных продуктов, предоставляя полный спектр функций от создания графика технического обслуживания, заказа комплектующих, учета контрактов на обслуживание и формирования счетов до учета прибыли, получаемой от послепродажного обслуживания. Состоит из модулей:

  • управление обслуживанием;
  • услуги и гарантии;
  • ведение договоров на обслуживание;
  • возврат продукции;
  • справочник клиентов;
  • справочник персонала;
  • учёт локальных особенностей;
  • ценообразование;
  • справочник услуг.

Для производственных компаний послепродажное обслуживание является важным источником доходов наряду с непосредственно продажей готовой продукции. При этом существуют различия в планировании и учете операций по техническому обслуживанию. MFG/PRO предоставляет мощный инструмент для организации сервиса, при этом позволяя отследить весь жизненный цикл продукции. Блок включает также возможности по управлению деятельностью центра приема заявок на техническое обслуживание, обеспечивает ведение базы данных обращений.

3.5. Блок «Общие данные»

Блок обеспечивает хранение и обработку основной нормативно-справочной информации, которая используется остальными блоками MFG/PRO и прикладными программами. Состоит из модулей:

  • Справочники продукции и структуры предприятий;
  • Справочники ингредиентов, полуфабрикатов и готовой продукции;
  • Физическая инвентаризация склада;
  • Система налогообложения;
  • Отчеты;
  • Установки для модуля "Управление запасами";
  • Пользовательский интерфейс;
  • Администрирование системы;

3.6. Справочники продукции и структуры предприятий

В этом модуле хранится информация о структурных подразделениях компании, местоположении складов, спецификации изделий и компонентах, их ценах, единицах измерения, системах пересчета.

3.6.1 Справочники ингредиентов, полуфабрикатов и готовой продукции

Модуль обеспечивает ввод информации об изделиях и их составляющих, наличии их на складе, информации о поставках, планировании поставок и закупок изделий и ингредиентов, информации о ценах на них. Модуль содержит следующие данные:

  • данные об изделиях;
  • данные по позициям на складе;
  • данные о комплектующих;
  • данные о планируемых изделиях;
  • данные о ценах изделий и себестоимости любой позиции.

3.6.2 Физическая инвентаризация склада

Модуль используется для учета наличия на складе материалов, комплектующих деталей и готовых изделий.

3.6.3 Система налогообложения

В этом модуле хранится справочная информация о клиентах, торгующих организациях и лицах, о сотрудниках компании. Здесь же хранится информация о ставках налогов. Причем налоговые ставки, условия их платежей связаны с информацией о клиентах, торгующих организациях и лицах, служащих компании. Практика эксплуатации FG/PRO в 86 странах мира доказала гибкость и мощь MFG/PRO по учёту специфики практически любых систем налогообложения.

3.6.4 Отчеты

Этот модуль позволяет производить необходимые установки для получения отчетов. Использование таких продуктов, как Crystal Reports или Progress Report Builder, позволяет генерировать свои собственные отчеты. Кроме того, в системе MFG/PRO имеется подсистема принятия решений (ППР), которая снабжена собственным генератором отчетов. ППР предназначена:

    на стратегическом уровне - для управляющих компанией;
    на управленческом уровне - для менеджеров среднего звена;
    на оперативном уровне - для ответственных исполнителей.

3.6.5 Установки для модуля Управления запасами

Модуль используется для обработки различных документов: товарных накладных, денежных переводов, платежных требований и поручений. Ведется история документов.

3.6.6 Пользовательский интерфейс

Модуль позволяет формировать для каждого пользователя свое меню для работы в системе. Допускается три структуры меню:

  • меню в графическом режиме с использованием значков (Icons) делает систему более дружественной для конечного пользователя и похожей на другие Windows- приложения;
  • Tear-Off-меню - прямая навигация по имени/внутреннему номеру функции/программы;
  • меню в символьном режиме (ASCII) - поддержка символьных экранов (терминалов).

3.6.7 Администрирование системы

Этот модуль используется для системных установок по умолчанию, выполнения команд операционной системы, установок принтеров, поддержания системы безопасности, модификации пользовательского интерфейса, выполнения операций по администрированию базы данных (восстановление после сбоев, архивирование данных).

3.7. Блок «Клиентские модули»

Блок реализует возможность включения в систему приложений, разработанных заказчиком, и ссылок к внешним программным системам. Дополнительные модули, которые устанавливаются по желанию заказчика:

  • подсистема поддержки принятия решений;
  • библиотека функций подсистемы поддержки принятия решений;
  • операции с торговыми партнерами;
  • подсистема работы с хранилищами данных (Enterprise Data Warehouse);
  • управление модификациями изделий;
  • протоколы проверок;
  • автоматизированная система бухгалтерского учета.

Лекция 4. Нормативная модель управления предприятием в MFG/PRO

4.1 Продуктовые линии и номенклатурные позиции

Введение продуктовой линии и номенклатурной позиции является начальным этапом настройкой ERP-системы и, в частности, MFG/PRO. Поскольку важнейшей задачей, решаемой системой, является отражение всей деятельности предприятия в стоимостном выражении, то первый шаг в настройках – это установление счетов Главной Книги (ГК). Данные установки будут использованы после ввода данных в модуль, поэтому они будут рассмотрены позже. Контрольный файл ГК должен быть установлен до того, как какая-либо информация будет занесена в модули Производства и Дистрибуции. Для ввода продуктовой линии в главном меню введите номер функции.

Продуктовая линия (товарно-номенклатурная группа - ТНГ) – группа номенклатурных позиций, объединенных для использования, в основном, для целей планирования и учета.

Номенклатурная позиция (НП) – это единица учета, которая может быть детале- сборочной единицей (ДСЕ), ГП, закупаемой компонентой, фантомом.

Примечание: например, если ДСЕ проходит три стадии обработки в разных цехах: штамповку, механическую обработку и окраску, то она меняет свою сущность, поэтому в случае необходимости детального отслеживания всех трех стадий, в системе надо отражать три номенклатурные позиции.

4.1.1. Ведение продуктовой линии

В продуктовую линию (или, другими словами, товарно-номенклатурную группу, ТНГ) объединяются номенклатурные позиции по схожим характеристикам производства. Например, такие ТНГ как: готовая продукция, промежуточные продукты, сырье. Все номенклатурные позиции вводятся в систему как принадлежащие какой-то ТНГ, в противном случае они не могут быть введены в MFG/PRO. ТНГ связывает номенклатурные позиции со счетами Главной Книги (ГК).

Для ведения ТНГ в главном меню введем номер функции равным 1.2.1. На экране ваших мониторов появилась форма «Ведение групп продуктов».

Основными полями являются:

ТНГ: код продуктовой линии (группы номенклатурных позиций);

Был предложен следующий принцип кодирования;

1000 – готовая продукция;

2000 – промежуточная продукция;

3000 – материалы.

Описание: описание продуктовой линии;

Налоблг.: признак того, что ТНГ подлежит налогообложению;

КлассНал.: идентификатор класса налога;

Счета Запасов: № счета ГК, на котором будут отражены операции с запасами по продуктовой линии (для НП, относящихся к данной ТНГ);

Счет НЗП: № счета ГК, на котором будут отражены операции по незавершенному производству – например, отражение списание материалов в незавершенное производство (для НП, относящихся к данной ТНГ);

Счет расхожд.СЗ: № счета ГК, на котором будут отражены операции, связанные с расхождениями складского запаса (для НП, относящихся к данной ТНГ);

СчетОткл.ОтМетода: № счета ГК, на котором будут отражены операции, связанные с отклонениями между нормативной и текущей себестоимостью (для НП, относящихся к данной ТНГ);

Счет Отход.: № счета ГК, на котором будут отражены операции, связанные с отходом по НП, относящихся к данной ТНГ;

СчетПродаж: № счета ГК, на котором будут отражены операции по продаже номенклатурных позиций (относящихся к данной ТНГ);

ЗНПИСчетМатерЗатрат: № счета ГК, на котором будут отражены затраты на материалы (для НП, относящихся к данной ТНГ);

Счет СкидокПр-ж: № счета ГК, на котором будут отражены операции по скидкам клиенту (для номенклатурных позиций, относящихся к данной ТНГ);

СчетТрдЗатратЗНПИ: № счета ГК, на котором будут отражаться трудозатраты (для НП, относящихся к данной ТНГ);

СчётБезн.Продаж: № счета ГК по безналичным расчетам с клиентами (для НП, относящихся к данной ТНГ);

чет ПрНР ЗНПИ: № счета ГК, на котором будут отражаться переменные накладные расходы (для НП, относящихся к данной ТНГ);

Счет ПсНР ЗНПИ: № счета ГК, на котором будут отражаться постоянные накладные расходы (для НП, относящихся к данной ТНГ);

СчетСубконтракта ЗНПИ: № счета ГК, на котором будут отражаться затраты по субконтракту (для НП, относящихся к данной ТНГ). Примечание: продажи НП могут отслеживаться по продуктовой линии, площадке, типу клиентов и/или каналу продаж. После ввода ТНГ для учета продаж необходимо произвести настройку счетов Продаж, которая будет рассмотрена позже.

4.1.2. Ведение номенклатурных позиций

Далее осуществим ввод номенклатурных позиций. В главном меню введем номер функции равный 1.4.3. На экране ваших мониторов появится форма «Ведение данных о позиции».

№ Позиции: код номенклатурной позиции (не более 18 символов);

Предлагается следующая кодировка номенклатурных позиций:

первая цифра кода характеризует продуктовую линию, где “1” готовая продукция “2”

промежуточная продукция “3” материалы;

вторая цифра характеризует подгруппу продуктовой линии;

последние четыре цифры характеризуют порядковый номер номенклатурной позиции внутри группы.

Описание: описание номенклатурной позиции;

ЕИ: единица измерения номенклатурной позиции;

ТНГ: код продуктовой линии, к которой принадлежит номенклатурная позиция;

Все номенклатурные позиции вводятся в систему как принадлежащие какой-то продуктовой линии, в противном случае они не могут быть введены в MFG/PRO.

Продуктовая линия связывает номенклатурные позиции со счетами Главной книги.

ТипПозиц.: идентификатор типа номенклатурной позиции (используется в отчетах о запасах и MRP) – аналитический признак группировки номенклатурной позиции;

Чертёж: идентификатор чертежа номенклатурной позиции;

Добав: справочное поле;

Статус: код статуса номенклатурной позиции, накладывающий ограничения на операции;

Прв: номер заказа на конструкторские изменения/разработки;

ГруппаПроекта: идентификатор группы лиц, которая оповещается в случае конструкторских изменений по номенклатурной позиции - для дискретного производства;

Груп.: идентификатор группы номенклатурной позиции, использующийся удобства

создания выборки и формирования отчетов;

Где Чертеж: местоположение чертежа по номенклатурной позиции – для дискретного производства;

Разм: размер чертежа номенклатурной позиции– для дискретного производства;

Группа Рекл: признак группировки номенклатурной позиции;

Катег.Скидки: признак группировки номенклатурной позиции для получения лучшего количественного разбиения –необходимо при наличии гибкой системы продаж для разбивании прайс-листов;

4.2 Настройка справочников

Для проверки вводимых значений поля формы, для настройки справочников используется функция 36.2.13 “Ведение обобщенных кодов”.

Имя Поля: имя поля (вызывается при нажатия клавиши Ctrl-F, при нахождении курсора на данном поле);

Знач.: разрешенное значение поля;

Коммент.: комментарии при вводе поля;

Для осуществления возможности вывода справочника по полю необходимо использовать функция 36.4.21, где помимо кода поля указать имя функции – gplu072.p.

Поле: имя поля;

Процедура Вызова: наименование процедуры вызова (необязательно для заполнения);

Описание: описание поля;

Процедура Выполнения: наименование процедуры выполнения (gplu072.p);

Первая Строка В Окне: 0 (предлагаемое значение поля);

Строк В Окне: 0;

4.3 Преобразование единицы измерения

Многие номенклатурные позиции рассчитываются при хранении в одних единицах измерения, но заказы на продажу и заказы на производство создаются в других. Для этого необходимо установить альтернативные единицы измерения с помощью функции 1.13. MFG/PRO автоматически сделает пересчет из альтернативной единицы измерения в основную, где это необходимо.

ЕдиницаИзмерен.: идентификатор стандартной единицы измерения;

Альтернат.ЕИ: идентификатор стандартной единицы измерения;

№ Позиции: код номенклатурной позиции, для которой определяется единица измерения (если не ставить код, то альтернативная единица измерения будет распространяться на все номенклатурные позиции);

Преобраз. ЕИ: коэффициент пересчета из стандартной единицы измерения в альтернативную.

4.4 Статус складского запаса

С помощью функции 1.1.1 “Ведение кодов статуса запасов” определяются особые условия при планировании, складском учете. Например, определяется, являются ли наличные запасы доступными для размещения по заказам на продажу и рабочим нарядам. Они могут также ограничивать определенные операции на определенных местонахождениях. Например, ограничивать отпуск с участка (местонахождения) приемки.

Код статуса запасов (Inventory Status Code). Этот код идентифицирует статус запасов на определенной площадке или местонахождении с определенным номером партии/серии (если партия/серия контролируется) и ссылкой на партию (lot reference). Доступные (Available) – признак доступности складских запасов (Да/ Нет).

«Да» - доступные запасы, могут размещаться и появляться в ведомости комплектации.

«Нет» - недоступные складские запасы, номенклатурные позиции для последующего использования, могут быть зарезервированы для проверки или ожидания приемки.

Учитываемые при планировании (Nеttable) – признак возможности использования складских запасов при планировании (Да/ Нет).

Подобная номенклатурная позиция MRP/DRP учитывает как часть наличного количества. Не учитываемые при планировании (Non-nettable) номенклатурные позиции обычно дефектные или зарезервированные.

Перевыпуск (Overissue). Если установить на Да (Yes), запасы могут быть выпущены с местонахождения, даже если система не показывает их существование. Такая ситуация может возникнуть, когда ввод данных по приходованию запасов отсрочен, что часто случается при группировке вводимой информации. Перевыпуск должен быть установлен на Нет (No) для контролируемых партий/серий или, в обычных условиях, для уверенности в возможности непосредственного отслеживания запасов.

Поскольку для номенклатурных позиций требуется установить код статуса запасов, будет проще установить код статуса = <пробел> как умолчание для номенклатурных позиций, которые являются доступными или учитываемыми при планировании, без ограничений транзакций.

Статус складских запасов используются при ведении заводов и местоположений.

4.5 Ведение площадок и местоположений

Процесс настройки продолжает ведение данных о площадках и местоположений. Площадка (или завод) представляется как место, где происходит использование, хранение или перемещение номенклатурных позиций. В разрезе площадок в системе осуществляется планирование, расчет себестоимости (как нормативной, так и текущей)

Под площадками понимается - производственная площадка (площадку-цех), площадка дистрибуции.

Местоположение – это места (составляющие площадку), где хранится продукция.

З-д: код площадки (код площадки идентифицирует ее принадлежность к одному из видов площадок: производственная площадка-цех, площадка для дистрибуции - склады);

Описание: описание площадки;

ЮрЛицо: код юридического лица, где юридическое лицо определяется наличием финансовой отчетности;

Исход.Статус Скл.Запасов: код статуса запасов, который по умолчанию будет обозначен для всех местоположений площадки;

Авто Местоположения: Да /Нет (признак того, что местоположение будет проверяться на наличие площадки или нет);

БазаДанн: идентификатор базы данных площадки – используется при транснациональной корпорации;

ПоставщикАСЗ: код внутреннего поставщика – используется при протоколах DRP (когда не весь технологический процесс осуществляется на заводе);

Внешний Поставщик: признак “внешнего поставщика”, где «да» - это признак, что данная площадка является внешним поставщиком. Этот флажок отличает одну базу данных от другой;

Счёт Откл.При Перемещ.: номер счета, на котором учитываются недостача и избыток материала;

З-д: код площадки;

Местопол: код местоположения площадки;

Описание: описание местоположения;

СтатусСкл.Запаса: код статуса запаса;

ДатаСоздания: дата создания записи;

Постоянн.: “Да” -признак постоянного местоположения, “Нет” –признак не постоянного местоположения;

Тип: идентификатор типа местоположения. Характеризует номенклатурные позиции, хранимые на местоположении (используется для проверки соответствия требованиям хранения номенклатурной позиции и проверяется при ее получении и перемещении);

ОднаПозиция: “Да” – на местоположении находится одна номенклатурная позиция,

“Нет” – на местоположении находится много номенклатурных позиций;

Един.Парт./Ссл: признак количества партий/серий, которые могут храниться на местоположении;

Мощность: максимальное количество номенклатурных позиций на местоположении;

ЕИ: единица измерения мощности местоположения (например, его вместимости).

4.6. Структура продукта

Структура продукта – это иерархический список номенклатурных позиций/компонент, составляющих конечный продукт. Каждая структура продукта состоит из одного родительского изделия (родительской номенклатурной позиции) и его компонент. Имя структуры продукта – это BOM код (код перечня материалов). Обычно BOM код совпадает с номером родительской номенклатурной позиции.

Но, если необходимо определить альтернативные структуры продукта, то сначала необходимо создать код структуры продукта - BOM код (функция 1.4.7 или 1.4.17). С помощью функции 13.5 связывается номер родительской номенклатурной позиции и ее компонента.

4.6.1. Ведение структуры продукта

Готов позиц: BOM код (код “родительской/готовой” номенклатурной позиции);

Описание: описание родительской номенклатурной позиции;

Поз. Компонент: код компоненты (номенклатурной позиции), входящий в состав “родительской/готовой” номенклатурной позиции;

Прв: код конструкторской разработки компоненты (берется из функции 1.4.1);

Ссылка: признак того, что компонент используется больше одного раза на одном и том же уровне «готовности» родительской номенклатурной компоненты;

Нач.Действовать: интервал времени производственного процесса начала “создания готовой” номенклатурной компоненты;

КонецДействия: интервал времени производственного процесса окончания “создания готовой” номенклатурной компоненты;

К-во на: количество компонент на родительскую номенклатурную позицию (выражается в единицах готовой номенклатурной позиции);

Отходы: процент отходов от использования компоненты (планирование потерь);

Сдвиг ДЦ: признак необходимости компоненты в начале работы по “созданию” готовой номенклатурной позиции (положительное число – компонента нужна после начала работы, где число указывает количество дней после начала работы; отрицательное число – компонента нужна до начала работы);

Оп: номер операции, используемой в составе процесса производства с использованием данной компоненты;

Номер Последов-ти: номер последовательности для сортировки компонент при создании отчета по операциям;

Тип Структуры: идентификатор типа структуры для проверки на цикличность структуры продукта (то есть компонент является частью своей же структуры где-то выше, незаполненное поле – стандартная структура, “Р” – планируемая; “О” – одна из несколько возможных; Х – фантомная часть в этой структуре, нормальная в других случаях, “D” – чертежи, документы, “А” альтернативная структура, J – производство субпродуктов и сопродуктов посредством отражения базового процесса производства). Кроме типов А и D остальные типы структуры участвуют в планировании и подсчете издержек;

Прогноз: процент прогноза. Обычно устанавливается в 100%. Если установить менее 100%, то система при планировании автоматически допланирует недостающее до 100 значения компоненты;

Нач.Действовать: дата начала действия компоненты в структуре продукта;

ГруппаВыбора: используется для удобства получения отчетности;

КонецДействия: дата окончания действия компоненты в структуре продукта;

Процесс: код базового процесса (при описании сопродуктов – для типа структуры «J»);

Замеч.: справочное поле.

4.6 Совместные продукты

Модуль 13.22 направлен на описание совместных продуктов – основных продуктов и субпродуктов. Данные понятия «основных продуктов» и «субпродуктов» определяют, так называемую, обратную сборку. Примером субпродукта может быть металлическая стружка.

Для того чтобы наладить учет и анализ работ по основным продуктам и субпродуктам необходимо:

  1. определить единицу учета работ по основным продуктам и субпродуктам, то есть необходимо определить базовый процесс. Базовый процесс определяется как НП в функции 1.4.1, причем данная НП должна иметь значение поля «Зкп/Прз» M (производимая НП);
  2. определить «входы базового процесса», используя функцию 13.5:
  3. определить «выходы базового процесса» - основные продукты и субпродукты, используя функцию 13.22.1. В функции 13.22.1 в поле "Осн/Поб Прод" определяется код НП, являющейся основным продуктом или субпродуктом (значение поля "ТипСовм.Прод." - О/основной продукт или С/субпродукт) для базового процесса. Определяется процент распределения затрат в поле «Распред. Затрат». Затраты базового процесса распределяются на основные продукты. Далее при работе с Н-З с/б субпродукта учитывается.

Например, есть структура продукта:

Вводим в систему НП с кодом БП_Д2.

1. С помощью функции 13.5 определяем входы базового процесса – Д1.

2. С помощью функции 13.22.1 описываем выходы базового процесса – 1 основной продукт – Д1(тип «О») и субпродукт Д3(тип С). Определяем процент распределения затрат базового процесса в поле «Распред". Затрат».

ПРИМЕЧАНИЕ: В функции 13.5. структура продукта для Д2 НЕ вводится, так как она создается автоматически после прохождения функции 13.22.1.

Функция 13.22.1 содержит следующие поля:

Код СПЦФ/Формулы: код спецификации, для которой будет описываться сопродукт или субпродукт (данная спецификация должна быть «конечной», то есть конечная НП по данной спецификации не должна входить в другие НП ); при выборе можно воспользоваться помощью, нажав клавишу F2;

Описание: описание спецификации (обновляется автоматически при подтверждении ввода кода спецификации);

МетодАвтоИзьятия: код метода автоматического пополнения складских запасов;

ЕИ: единица измерения конечной НП (обновляется автоматически при подтверждении ввода кода спецификации);

Осн/Поб Прод: код НП, являющейся сопродуктом или субпродуктом;

Прв: код конструкторского изменения/разработки (берется из функции 1.4.1);

Нач.Действовать: дата начала действия сопродукта или субпродукта;

ТипСовм.Прод.: код типа совместного продукта. Значение поля «О» характеризует основной продукт, а «С» -субпродукт;

К-во: количество совместного продукта (сопродукта или субпродукта) на одну единицу конечной НП;

Распред. Затрат: процент распределения затрат;

Тип Структуры: код типа структуры (проставляется автоматически - «J»);

Нач.Действовать: дата начала действия сопродукта или субпродукта.;

КонецДействия: дата окончания действия сопродукта или субпродукта;

Замеч.: информационное поле;

Оп: код операции, на которой вырабатывается сопродукт или субпродукт;

Номер Последов-ти: номер поседовательности для сортировки при создании отчета по операциям;

ГруппаВыбора: используется для удобства получения отчетности;

4.7 Номенклатурные позиции-заменители (альтернативные компоненты)

С помощью функции 13.19 можно внести все возможные альтернативные компоненты. Внесение альтернативы позволит ее включить в заказ на производство.

Поз. Сб.Уз./Баз.Проц.: код номенклатурной позиции – для конкретной замены, « » - для глобальной замены;

№ Позиции: код номенклатурной позиции, которая может быть заменена (здесь вводится код предпочтительной номенклатурной позиции);

Позиция Замены: код номенклатурной позиции замены;

К-во Замены: числовой показатель возможной частоты замены;

Замеч-я: справочное поле;

Коммент.: справочное поле.

4.8 Формула

Формула - это один из способов определения структуры продукта, используемая для объемных производств (пищевая промышленность или производство медикаментов).

Если при определении кода “готовой” (родительской) номенклатурной позиции необходимо больше, чем один BOM код (Bill of Materials – спецификация) – например при создании емкостей различного размера, то для определения нового BOM кода для номенклатурной позиции предварительно необходимо использовать функции 15.1, а затем –15.8.

Готов позиц: код “готовой” номенклатурной позиции;

ОбъемГруппы: размер партии «готовой» номенклатурной позиции;

Описание: описание “готовой” номенклатурной позиции;

Поз. Компонент: код компонента;

Прв: код конструкторской разработки компоненты (берется из функции 1.4.1).

Ссылка: признак того, что в «готовой» (родительской) номенклатурной позиции используется компонента больше одного раза для уточнения того момента, когда используется компонент;

Действит.: признак срока годности компоненты;

К-во На: количество компоненты на размер «готовой компоненты»;

Отходы: процент отходов от использования компоненты (планирование потерь);

Тип К-ва:

    “пусто” - признак того, что количество компонент на одну единицу родительского продукта выражено в единицах измерения родительского компонента,
    “В” - признак того, что количество компонент на одну единицу родительского продукта выражено на целую емкость родительского компонента,
    “Р” - признак того, что количество компонент на одну единицу родительского продукта определено как процент от емкости;

Сдвиг ДЦ: признак необходимости компоненты в начале работы по “созданию” готовой номенклатурной позиции (положительное число – компонента нужна после начала работы, где число указывает количество дней после начала работы; отрицательное число – компонента нужна до начала работы);

% Группы: 0.0

Оп: номер операции, используемой в составе процесса производства с использованием данной компоненты;

Тип Структуры: идентификатор типа структуры для проверки на цикличность структуры продукта (то есть компонент является частью своей же структуры где-то выше);

Номер Последов-ти: номер последовательности для сортировки при создании отчета по операциям;

Прогноз: процент прогноза. Обычно устанавливается в 100%. Если установить менее 100%, то система при планировании автоматически допланирует недостающее до 100 значения компоненты;

Нач.Действовать: дата начала действия компоненты в структуре продукта;

ГруппаВыбора: используется для удобства получения отчетности;

КонецДействия: дата окончания действия компоненты в структуре продукта;

Замеч.: информационное поле;

Процесс: код базового процесса.

4.9 Технологические маршруты

Технологический маршрут – перечень операций, или шагов, которые необходимо выполнить для производства номенклатурной позиции. Перед вводом технологического аршрута необходимо установить цеховой календарь (для точного планирования), отделы (по которым отслеживаются финансовые проводки) и рабочие центры (рис. 13).

4.9.1. Цеховой календарь

Для планирования, составления расписаний и подсчета длительности циклов используются два календаря:

- Рабочий календарь(36.2.5) устанавливает регулярное расписание для цеха;

- Календарь праздников(36.2.1) показывает исключение из этого расписания.

Введенные часы используются для вычисления производственных мощностей рабочих центров.

З-д: код площадки;

Раб.Центр: код рабочего центра (если поле будет не заполнено, то цеховой календарь будет применяться ко всем рабочим центрам);

Машина: код оборудования;

Раб.День: признак работы в конкретный день недели (да/нет);

Часы: количество рабочих часов в день недели;

Ссылка: идентификатор ссылки;

Нач.: дата начала действия рабочего календаря;

Кон.: дата окончания действия рабочего календаря;

Часы: количество сверхурочных или нерабочих часов;

З-д: код площадки;

Дата: дата праздничного дня;

Праздн.: описание праздничного дня.

4.9.2. Отделы

Отделы группируют рабочие центры для составления отчетов, планирования и бухгалтерского учета.

По отделам:

- Составляются отчеты;

- Планируется мощность и загрузка;

- Отслеживаются в Главной Книге трудовые издержки, переменные накладные расходы и себестоимость продукции.

Занесите данные с помощью функции 14.1 для возможности отслеживания загрузки и издержек.

Отдел: код отдела;

Описание: описание отдела;

Производит-ть: сумма производственных мощностей рабочих центров отдела (используется при планировании потребностей в мощностях для определения ситуаций недозагрузки - и перегрузки, можно поле не заполнять);

4.9.3. Рабочие центры

Рабочий центр – это группа людей и/или машин. Группа рассматривается в качестве единой единицы для целей планирования загрузки и составления детального расписания.

Раб.Центр: код рабочего центра;

Машина: код машины в рабочем центре;

Описание: описание;

Отдел: код отдела, которому принадлежит рабочий центр;

Рабоч.Местоп.: код местоположения;

Время Очер.: время до обработки;

ВремяОжид.: время после обработки;

Маш./Оп: количество машин, способных работать параллельно над одной операцией;

Бриг.Настр.: общее число машин или людей в данном рабочем центре;

НормаНастр.: ставка за настройку оборудования (руб.);

К-воРаб.: информационное поле;

НормаТрдЗт: накладные расходы по технике - часовая ставка, применяемая ко времени обработки;

Оборуд.: количество оборудования в рабочем центре;

НормаТрдПрНР: накладные расходы по работе - часовая ставка, применяемая ко времени настройки и обработки;

НормаПрНРОбор: норма накладных расходов на оборудование;

% ТрдПрНР: процент по накладным расходам на работу;

Работник: код работника (код вида работ). Вводится вручную;

НСС: номер страхового полюса работника;

Отдел: код отдела, в котором работает работник;

НормаОплаты: фактическая почасовая ставка оплаты труда;

НормЧасы: Обычная продолжительность рабочей смены.

Статус Работника: может принимать следующие значения:

    AC – активный;
    LA – в отпуске;
    PT – неполный рабочий день;
    TR – удален.

4.9.4. Технологический маршрут

С помощью функции 14.13.1 осуществляется ввод технологического маршрута (или техпроцесса). При больших объемах производства необходимо использовать функцию 14.13.2. Функция 14.13.1 используется для дискретного производства. При объемном производстве используют функцию 15.13.

Код ТехКарты: код технологической карты;

Операция: внутренний порядковый номер операции техкарты;

ДатаНачала: дата начала операции;

ДатаОконч.: дата окончания операции;

Стандарт.Операция: код стандартной операции;

Раб.Центр: код рабочего центра;

Машина: код машины рабочего центра;

Описание: описание рабочего места;

МашинНаОперацию: количество машин, задействованных в операции;

Ключевая Операция: номер операции, определяющей завершение производственного процесса (проставляется для поточного/конвейерного производства).

К-воПерекр.Ед.: размер передаточной партии;

ДЦ Субконтракта: длительности цикла по субконтракту (в днях);

Время Очер.: время до операции;

Бриг.Настр.: количество настройщиков;

ВремяОжид.: время после операции;

Бригада: количество рабочих, выполняющих операцию на рабочем центре;

ВремяНастр.: время настройки;

Код Инстр.: код инструмента;

Время Обр.: время операции;

Перемещ-е: время перемещение;

%Выхода: % не бракованных изделий.

Функция 14.13.7 позволяет выборочно обновить технологический маршрут для новых рабочих центров или для новых параметров стандартных операций.

Код ТехКарты: код технологического маршрута;

Оп: номер операции;

Раб.Центр: код рабочего центра;

Машина: код машины;

Стандарт.Операция: код стандартной операции.

Стандартная операция описывает установки по умолчанию для операций технологического маршрута.

Код ТехКарты: код технологической карты (технического маршрута);

Операция: код операции;

К-воГруппы: количество машин, используемых для операции;

Стандарт.Операция: код стандартной операции;

Раб.Центр: код рабочего центра;

Машина: код машины рабочего центра;

Описание: описание;

МашинНаОперацию: количество машин, которые могут одновременно работать над данной операцией;

Ключевая Операция: «Да» - признак поточной операции;

К-воПерекр.Ед.: количество деталей, которое может быть передано на следующую операцию еще до завершения текущей;

ДЦ Субконтракта: длительность цикла по субконтракту;

Время Очер.: время в очереди (часы);

Бриг.Настр.: количество бригады настройщиков (человек);

ВремяОжид.: время (в часах) на перемещение партии на этой операции;

Бригада: количество бригады обработки (человек);

ВремяНастр.: время настройки раб. Центра;

%Выхода: % выхода годных изделий;

ВремяВып/КвоГруппы: время обработки одной партии на этой операции;

Код СПЦ: BOM код (код номенклатурной позиции)

ОбъемГруппы: старый размер партии;

Нов.РазмГруппы: новый размер партии;

Скорр.: признак корректировки партии Да/Нет;

Лекция 5. Нормативная модель управления предприятием в MFG/PRO (продолжение 1)

5.1. Альтернативные Структуры и технологические маршруты

Почему используются альтернативные структуры и технологические маршруты?

Альтернативные структуры и технологические маршруты используются при различных способах изготовления продукта. Любой производственный заказ может быть модифицирован и запущен с использованием этих альтернативных структур.

Любой производственный заказ может быть модифицирован на месте для отражения использования различных компонент и технологических маршрутов. Альтернативные структуры и технологические маршруты позволяют переопределить утвержденный вариант для уменьшения ручного труда, требуемого для внесения изменений. Они также обеспечивают механизм для вычисления стоимости вариантов (заместителей).

MRP вычисляет потребности, основанные на стандартных структурах и технологических маршрутах. Конкретный производственный заказ должен быть модифицирован для отражения заменителей, которые действительно будут использованы. После этой информации планирование использует информацию о заместителях.

5.1.1. Альтернативные структуры

Код структуры и BOM код однозначно определяет каждую структуру (или формулу) продукта. Для стандартной структуры BOM код определяет номер родительской номенклатурной позиции. Если Вы имеете несколько продуктов с идентичными структурами или изделие с альтернативными структурами, Вы можете ввести BOM коды для ссылки на различные структуры.

Чтобы использовать эту возможность сделайте следующие шаги:

- введите BOM код в «Введение кода структуры продукта(13.1) или «Ведение кода формулы(15.1)»;

- используйте функции: «Ведение структуры продукта»(13.5) или «Ведение формулы»(15.5) для определения компонент BOM кода (или Вы можете использовать функции копирования для копирования существующей структуры или формулы);

- код и его альтернативная структура должны быть определены как утвержденный способ производства стандартного изделия. Это делается в «Введении альтернативной структуры»(13.15) связыванием стандартного изделия с BOM кодом.

- «ведение рабочего наряда» (функция 16.1) позволяет модифицировать конкретный производственный заказ для применения альтернативной структуры путем определения альтернативного BOM кода. Таким образом, генерируется правильная ведомость комплектации. Производственные заказы для поточной линии (конвейера) могут также ссылаться на альтернативные структуры для записи об отпуске в производство нужных компонент.

Код СПЦ: BOM код;

Описание: описание структуры;

ЕИ: единица измерения;

Коммент.: комментарии по структуре продукта.

Код СПЦ: BOM код;

Описание: описание BOM код;

ОбъемГруппы: количество формул, входящих в группу;

ЕИ: единица измерения;

Формула: код формулы, являющейся компонентом BOM кода;

Коммент.: комментарии к формуле, входящей в BOM код.

Готов позиц: BOM код (код “родительской/готовой” номенклатурной позиции);

Описание: описание родительской номенклатурной позиции;

Поз. Компонент: код компоненты (номенклатурной позиции), входящий в состав “родительской/готовой” номенклатурной позиции;

Прв: код конструкторской разработки;

Ссылка: признак того, что компонент используется больше одного раза на одном и том же уровне «готовности» родительской номенклатурной компоненты;

Нач.Действовать: дата начала работы по “созданию готовой” номенклатурной компоненты;

КонецДействия: дата окончания работы по “созданию готовой” номенклатурной компоненты;

К-во на: количество компонент на родительскую номенклатурную позицию;

Отходы: процент отходов от использования компоненты (планирование потерь);

Сдвиг ДЦ: признак необходимости компоненты в начале работы по “созданию” готовой номенклатурной позиции (положительное число – компонента нужна после начала работы, где число указывает количество дней после начала работы; отрицательное число – компонента нужна до начала работы);

Оп: номер операции, используемой в составе процесса производства с использованием данной компоненты;

Номер Последов-ти: номер последовательности для сортировки (при создании отчета по операциям);

Тип Структуры: идентификатор типа структуры для проверки на цикличность структуры продукта (то есть компонент является частью своей же структуры где-то выше):

незаполненное поле – стандартная структура;

“Р” – планируемая;

“О” – одна из несколько возможных;

“Х” – фантомная часть в этой структуре, нормальная в других случаях;

“D” – чертежи, документы;

“А” – альтернативная структура;

“J” – структура для базового процесса.

Кроме типов А и D остальные типы структуры участвуют в планировании и подсчете издержек.

Готов позиц: код “готовой” номенклатурной позиции;

ОбъемГруппы: размер «готовой» номенклатурной позиции;

Описание: описание “готовой” номенклатурной позиции;

Поз. Компонент: код компонента;

Прв: код конструкторских изменений/разработки;

Ссылка: признак того, что в «готовой» (родительской) номенклатурной позиции используется компонента больше одного раза для уточнения моментов процесса, где используется компонент;

Действит.: признак срока годности компоненты;

К-во На: количество компоненты на размер «готовой компоненты»;

Отходы: процент отходов от использования компоненты (планирование потерь);

Тип К-ва:

“пусто” - признак того, что количество компонент на одну единицу родительского продукта выражено в единицах измерения родительского компонента,

“емкость” - признак того, что количество компонент на одну единицу родительского продукта выражено на целую емкость родительского компонента,

“процент” - признак того, что количество компонент на одну единицу родительского продукта определено как процент от емкости;

Сдвиг ДЦ: признак необходимости компоненты в начале работы по “созданию” готовой номенклатурной позиции (положительное число – компонента нужна после начала работы, где число указывает количество дней после начала работы; отрицательное число – компонента нужна до начала работы);

% Группы: 0.0

Оп: номер операции, используемой в составе процесса производства с использованием данной компоненты;

Тип Структуры: идентификатор типа структуры для проверки на цикличность структурыпродукта (то есть компонент является частью своей же структуры где-то выше);

Номер Последов-ти: используется для сортировки при создании отчета по операциям.

Позиции: код НП, для которой назначается альтернативная структура;

ЕИ: единица измерения;

Спцф/Формула: BOM код;

Ссылка: код, который позволяет выделить одни альтернативные структуры от других;

Замеч.: информационное поле.

5.1.2. Альтернативные техкарты

№ позиции: код НП;

Описание: описание НП;

ЕИ: единица измерения НП;

З-д: код площадки (завода/цеха);

Чертеж: идентификатор конструкторского чертежа;

ТипПозиц: код типа НП;

Статус: статус НП;

Код техкарты: код техкарты для изготовления НП;

Спецификация: не обязательное для заполнения поле для указания кода спецификации.

5.2. Издержки по номенклатурной позиции

Подсчет нормативной себестоимости позволяет проверить точность введенных нормативов. Нормативную себестоимость после подсчета можно проанализировать с помощью функций 1.4.9, 1.5.6. Но перед подсчетом помимо техкарты и спецификации, рабочих центров надо определить нормативные затраты по закупаемым материалам с помощью функции 1.4.9.

№ Позиции: код номенклатурной позиции;

Описание: описание номенклатурной позиции;

ЕИ: единица измерения номенклатурной позиции по закупки;

Цена: стоимость номенклатурной позиции (используется в сбыте);

Нал.: признак налогообложения;

КлассНал.: идентификатор класса налогообложения;

Элемент:

Материальные затраты (Material Cost). Затраты на потребляемые, закупаемые или поставляемые номенклатурные позиции. Материальные затраты могут быть обновлены вручную по заказу на закупку или счету к оплате.

Трудозатраты (Labor Cost). Затраты труда (время на подготовку и обработку) для технологического маршрута. Рассчитывается для каждого рабочего центра умножением часовой тарифной ставки на количество часов работы, а затем добавлением итогов для каждого рабочего центра. Обновляется при подсчете общих затрат на технологический маршрут или закрытии рабочего наряда.

Переменные накладные расходы (Burden Cost). Переменные накладные расходы изменяются при изменении времени на изготовление изделия. Рассчитываются для каждого рабочего центра прибавлением часовых ставок машинных и трудовых переменных расходов, затем умножаемых на время изготовления. Переменные накладные расходы могут также рассчитываться как фиксированные затраты на 1 час работ. Часовая ставка переменных накладных расходов обновляется при 'Подсчете общих затрат на технологический маршрут' (Routing Cost Roll-Up) (14.13.13) или вручную в 'Обновлении переменных накладных расходов на номенклатурную позицию' (Item Burden Cost Update) (1.4.20).

Постоянные накладные расходы (Overhead Cost). Постоянные накладные расходы вводятся вручную. Они представляют собой постоянные накладные расходы, распределенные по номенклатурным позициям, такие как затраты на размещение, заработная плата менеджеров, свет, отопление, и общие накладные расходы.

Этот Уров.: затраты данного уровня по НП;

НизшУровень: затраты нижних уровней для НП;

Поле А/О (Add On) зарезервировано для использования для дальнейшего расширения учета затрат.

5.3. Ввод исходных и настройка исходных данных для снабжения

Для обработки операций снабжения в системе необходимо ввести исходную информацию о поставщиках, условиях ценообразования, кодах подтверждения Заявок на Закупку (З-каЗ), счета кредиторов и закупок и т.д., а также настроить параметры контрольных файлов модулей относящихся к функциям снабжения.

  • Ввод счетов ГК кредиторов и закупок.
  • Параметры налогообложения.
  • Условия ценообразования.
  • Ареса компании и заводов
  • Данные поставщиков.
  • Настройка контрольных файлов закупок (5.24), Счетов Кредиторов (28.24).
  • (В случае применения модуля СОФ) запуск программы конверсии СОФ, ввод условий СОФ.
  • Ввод счетов ГК и параметров налогообложения, а также настройка контрольных файлов, описаны в соответствующих методиках использования MFG/PRO. Порядок ввода адресов компании и заводов приведен в разделе “Обработка сбыта в MFG/PRO”.

5.3.1. Ввод адресов компаний

Функция 2.12 облегчает процесс ввода контрагентов. Она содержит следующие окна:

Компания: код компании (вводится вручную);

Адрес: данные о адресе;

Внимание: данные связи: телефон, факс;

Нал.Инф: информация о налогах;

При необходимости можно, нажав комбинацию клавиш «Esc-M», можно с помощью верхнего меню ввести и банковские данные.

5.3.2. Ввод условий ценообразования

Во время ввода строк ЗЗ система автоматически назначает цену закупки позиций, данные о которых существуют в системе, такие позиции называются “хранимые на складе”. Для определения стоимости закупки система использует или Прайс-Лист (П-Л), указанный в главном окне ЗЗ или затраты позиции указанные в функциях ведения данных НП (1.4.1, 1.4.9).

В последнем случае в качестве закупочной стоимости по умолчанию будет использоваться значение поля “Материал”-“Этот Уров.” набора затрат используемого для проводок ГК.

В первом необходимо создать П-Л закупок в функции 1.10.2.1 Ведение Прайс- Листов (П-Л) для дальнейшего их указания в ЗЗ.

Значение полей “ТНГ”, “№ Позиции”, “ЕИ”, “Нач.”, “Оконч.”, “Валюта” используются для задания условий, в которых используются П-Л. Несколько П-Л могут иметь одно и тоже название, указанное в “Прайс-Лист”.

П-Л может быть четырех типов:

P – в этом случае в следующем окне задается цена позиции указанной в условиях применения П-Л в зависимости от количества закупки.

D – в следующем окне задается величина скидки в зависимости от количества закупки.

M – в П-Л указываются наценки рассчитываемые по следующей формуле:

Чист.Цена = Итог Затр + (Итог Затр / 100) * Наценка %,

где Итог Затр – суммарные затраты НП набора затрат используемого для создания проводок ГК за исключением затрат на ПсНР,

Наценка % - процент наценки введенный в П-Л в зависимости от количества закупки.

L – означает, что вводимый П-Л является Таблицей Цен (ТЦ) в котором указываются максимальные и минимальные цены закупок.

5.3.3. Данные поставщиков

Для обработки сбытовых операций в системе необходимо ввести имена и адреса поставщиков и организаций, с которыми будет осуществляться расчеты за получаемые по ЗЗ товары.

В данных поставщиков (2.3.1 Ведение Поставщиков) вводится информация, используемая в дальнейшем в модулях Закупки и Счета Кредиторов.

В этих данных указывается код, имя поставщика, адрес.

Поставщик может быть временным (Временный: Да), то есть созданным для единичной закупки или единичного платежа, в этом случае после создания ЗЗ, получения по ЗЗ и обработки Счетов Кредиторов в момент удаления закрытого счета кредитора (28.23) данные об этом поставщике будут удалены автоматически.

Каждый поставщик имеет два счета ГК.

СчетЗакуп. – этот счет используется только в случае закупки позиций не хранимых на складе. В случае закупки позиций хранимых на складе используется счет закупок ТНГ.

Счета СК – при вводе нового поставщика счет принимается по умолчанию из данных 36.1 Контроль.Файл Системы/Бухг.Счета. этот счет используется при обработки ваучеров.

По умолчанию при расчетах с поставщиками может использоваться одна из семи форм чека (Форма Чека). 1 и 2- печатаемые чеки, 1- стандартная форма, 2- альтернативная, отображающая сумму платежа ниже даты. 3 и 4- формы чеков используемые при применении электронного обмена данными. 5, 6 и 7- используются при обработке векселей.

Многие параметры, указанные в данных поставщика используются для присвоения по умолчанию в момент создания ЗЗ: Валюта, Зкпщк, Табл.Цен, ТаблСкид., Фиксир.Цена. Параметр фиксированная цена может использоваться для разрешения (Да) или запрещения (Нет) пакетного обновления цен закупок ЗЗ (5.19 Коррект. Стоим. Заказа на Закуп.) на основе изменений данных позиций или П-Л.

Также как при работе с покупателями расчеты с поставщиком могут оговариваться условиями кредита. В этом случае в поле “УслКредита” указывается код условий кредита предварительно введенный в 2.19.1 Ведение Условий Кредита. Эти условия будут автоматически объединяться со всеми вновь вводимыми ЗЗ.

В случае предоставления поставщиком постоянной скидки Вашей компании введите ее в поле “%Скид”, тогда она будет принимать по умолчанию при вводе строки ЗЗ, но может быть изменена в случае изменения условий.

Баланс предоплаты поставщику ведется системой автоматически и указывается в поле “БалансПредоплаты”.

Данные банковских счетов поставщика обычно используются системой для обработки транзакций ЭОД. В момент генерирования платежа поставщику система проверяет соответствие банка и типа счета в ваучере и в данных поставщика.

5.3.4. Данные получателя поставщика

Все платежи поставщика могут отправляться на адрес получателя отличающийся от адреса отправителя.

Если поставщику назначен получатель все платежи будут оформляться на адрес получателя и отменить это с клавиатуры нельзя.

Данные получателей и их соответствие тому или иному поставщику вводятся в

2.3.13 Ведение Получателей Поставщиков.

Данные адреса получателя заполняются аналогично данным адреса поставщика.

5.3.5. Данные о дистрибуции

Перед обработкой сбытовых операций и операций с дебиторами необходимо ввести следующую информацию:

  • счета Главной Книги,
  • условия и параметры налогообложения,
  • условия ценообразования,
  • коды и параметры Дополнительных Услуг,
  • адреса компании и заводов,
  • адреса покупателей и получателей,
  • настройка Контрольного Файла ЗП.

Ввод счетов ГК и условий, параметров налогообложения представлены в соответствующих методиках по настройке и использованию системы.

5.3.6. Условия ценообразования

Во время ввода строк заказов, квот и ожидающих С-Ф система может автоматически назначать наилучшие цены в зависимости от введенных условий ценообразования. Условия и размеры применяемых скидок и наценок описываются в Прайс-Листах. Количество вводимых П-Л не ограничено и зависит от потребностей компании в области ценообразования, но при этом их ввод необязателен для автоматического применения цен при вводе. Если П-Л не введены система будет использовать значение поля “Цена” функций ведения затрат НП (например, 1.4.9). П-Л для сбыта ведутся в функции 1.10.1.1 Ведение Прайс-Листов. Помимо П-Л вводимых в этой функции могут быть созданы Таблицы Цен в 1.10.2.1 Ведение Прайс- Листов (тип L) и скидки по объему в 1.10.13 Ведение Скидок по Объемам.

П-Л могут создаваться не для определенного покупателя или конкретной позиции, а для групп покупателей и позиций. Для их группировки вводятся коды анализа объединяющие их по определенным признакам. Данные кодов анализа и их взаимосвязей ведутся в модуле 1.8 Коды Анализа.

5.3.7. Коды Анализа

Создание кодов анализа осуществляется в функции 1.8.1 Ведение Кодов Анализа.

Укажите в функции “Тип” создаваемого кода: Поз.- объединяет позиции, Клиент- объединят клиентов; название кода в поле “Код”; при определении цен будут использоваться только активные коды анализа, поэтому, присвойте “Активный”- Да. Если при создании П-Л будет указан неактивный П-Л, появится предупреждающее сообщение.

Далее в функции 1.8.4 Ведение Выбора Кода Анализа, указываются признаки, по которым позиции или клиенты объединяются под названием кода.

В первом окне указывается тип и название кода анализа для которого создаются условия группировки позиций или покупателей. Возможные значения “Поле Условия”:

Здесь указывается имя поля значения, которого будут использоваться в качестве селекционного критерия. Один код анализа может объединять несколько критериев выбора. Для этого после ввода данных одного критерия нажмите GO и введите название и данные следующего. Если критериев несколько, то выбираться будут позиции или клиенты, данные которых отвечают всем критериям.

В поле “Маска” вводится метод выбора диапазона позиций или клиентов: точка (.) или звездочка (*).

Точка (.) указывает на присутствие в соответствующем поле введенных символов. Например, для 3.00 будут соответствовать 3100, 3200, 3300 и т.д. Звездочка (*) обозначает соответствие строки символов в коде анализа и определенном поле позиции/клиента. Например, для 35* будут соответствовать 3510, 350, 35950 и т.д.

В полях “Из” и “В” указывается диапазон заданных значений.

Пример.

Поле Условия: Плат-к

Маска: *

Из: 001

В: 200

Будут выбраны все клиенты с кодом от 1 до 200 (2, 34, 123 и т.д.).

После создания кодов анализа и условий их выбора необходимо запустить функцию 1.8.19 Создание Детального Кода Анализа, генерирующую список позиций или клиентов отвечающих требованиям критериев выбора кодов анализа. Укажите тип “Поз.” или “Клиент” и выведете отчет на принтер или в файл.

5.3.8. Прайс-Листы сбыта

В П-Л указывается необходимая информация для определения требуемых цен позиций для определенных покупателей. Коды покупателей и позиций могут присваиваться в П-Л по следующим комбинациям:

  • Номер одной позиции.
  • Код одного покупателя.
  • Группа покупателей объединенных кодом анализа.
  • Группа позиций объединенных кодом анализа.
  • Все покупатели.
  • Всем позиции.

Тип скидки, указываемый как Тип Суммы, определяет назначение П-Л.

Существует несколько типов скидок, которые могут комбинироваться. В П-Л также указываются минимальные суммы, даты указывающие длительность действия и другую информацию.

Когда вводятся заказы MFG/PRO определяет применяемые П-Л, проверяя какие из них дают наилучшие цены по заказу.

Типы скидок.

Тип скидки П-Л указывается в поле “Тип Суммы” функции ведения данных П-Л, и может принимать значения:

Цена изП-Л (List Price). Основная цена номенклатурной позиции, которая будет заменять основную цену, указанную в основных данных о номенклатурной позиции (1.4.1).

Основные цены также устанавливают допустимые минимальную и максимальную цены, если последние выбраны для определенной номенклатурной позиции заказа.

Чистая цена (Net Price). Фиксированная цена как результат данной скидки. Должна быть базового или исключительного совместимого типа (указанного в поле " КомбинТип").

% Скидка (Discount %). Скидки есть процент, вычисляемый от основной цены номенклатурной позиции.

СуммаСкидки (Discount Amt). Величины скидок есть указанные суммы, которые вычитаются из основной цены номенклатурной позиции.

Накопление (Accrual). Накапливаемые Прайс-Листы отправляют процент от чистой цены на бухгалтерский счет Главной Книги. Этот Прайс-Лист работает как Прайс-Листы скидок, за исключением того, что вместо уменьшения основной цены на определенный процент он инициирует накопление итога, выраженного в процентах от чистой цены, на указанном бухгалтерском счете Главной Книги без влияния на расчет чистой цены.

Проведение накопленных сумм есть дополнение к обычным проведенным суммам транзакций. Номер счета накопления и расходов указывается в рамке "Основная информация" (1.10.1.1).

Усл.Кредита (Credit Terms). Прайс-Листы условий кредита указывают условия кредита для заказа или квоты. По готовящимся заказам система соответственно обновляет условия кредита.

СписокФрахтов (Freight List). Прайс-Листы списков фрахта указывают лист доставки для отдельной номенклатурной позиции заказа или квоты. По готовящимся заказам списки фрахтов по номенклатурным позициям обновляются соответственно.

УсловияФрахта (Freight Terms). Прайс-Листы условий фрахта указывают условия доставки для заказа или квоты. Система соответственно обновляет условия доставки для готовящихся заказов.

Наценка (Mark-Up). Наценки есть проценты, добавляемые к затратам номенклатурной позиции для указанного набора затрат. Прайс-Листы наценки должны быть базового или исключительного совместимого типа (указанного в поле "КомбинТип").

5.3.9. Резюме по нормативной модели логистики предприятия

Лекция 6. Нормативная модель управления предприятием в MFG/PRO (продолжение 2)

6.1. Нормативные данные по Главной книге

6.1.1. Настройка контрольного файла Главной Книги

Перед вводом счетов ГК и настройки отчетности необходимо настроить 25.24

Контрольный Файл Главной Книги. Настройки Контрольного Файла определяют условия обработки транзакций, применения субсчетов и ЦЗ, счета нереализованных прибылей/убытков обмена валют и т.д.

Счет Приб./Убытков(Бал.): код счета ГК для отражения балансовых прибылей/убытков С Начала Года (СНГ). Этот счет используется только для отчетов, на него не могут быть выставлены транзакции. Система подсчитывает суммы прибылей/убытков СНГ по всем суммам выставляемым на все счета доходов (тип I) и расходов (тип Е). Эти суммы печатаются в балансовых отчетах, отражая текущие доходы компании. Прибыли/убытки СНГ пересчитываются каждый раз, когда печатаются балансовые отчеты.

Прибыли/убытки подсчитываются отдельно для каждого ЮрЛица.

Счет Удержанных Выплат: используется в функциях: 25.13.12 Транзакция Закрытия Года, во время закрытия года система подсчитывает и выставляет на этот счет прибыли/убытки СНГ, и 25.13.2 Вед. Ретроактивных Транзакций, транзакции сделанные во время закрытия года могут влиять на прибыли/убытки года для которого делалась ретроактивная проводка (например, выставление проводок продаж закрытого года должно увеличить доходы того года).

СчетНереализ.Приб/Убыт Обмена: этот счет используется только при использовании нескольких валют в системе. Применяется в функции 25.13.9 Переоценка Обмена Валюты для отражения сумм появляющихся в случае изменения обменного курса. Например, у Вас есть валютный счет в банке 100$. В момент его создания 1$=20р, то есть 2000р. В некоторый момент курс изменился и стал 1$=25р., то есть 2500р. Прибыль 500р. не реализована, т.к. существует только на бумаге и останется таковой до момента снятия этих денег со счета.

СчетПоправокПереводов(БО): используется только в момент импорта транзакций другого Юр. Лица с иной базовой валютой. Если поле “ВнестиСкоррект.Транз.В Б/Д”- Баланс (25.3.1), тогда суммы приведения переводов выставляются на этот счет.

СчетПоправокПереводов(ОПУ): используется только в момент импорта транзакций другого Юр. Лица с иной базовой валютой. Если поле “ВнестиСкоррект.Транз.В Б/Д”- Доход (25.3.1), тогда суммы приведения переводов выставляются на этот счет.

Настройка Главной Книги в MFG/PRO.

Исп. Суб-Счета, Исп.ЦентрыЗатрат: определяет применяет компания суб-счета и центры затрат, если применяются суб-счета или ЦЗ – присвойте “Да” в соответствующем поле.

БалансПоЮр.Лицам: применяется только если в одной базе данных существует несколько Юр. Лиц. “Да” - если все транзакции внутри одного Юр. Лица должны быть сбалансированы.

Например, ниже приведенная транзакция выставлена в ГК не будет.

Дб 1200 (Юр. Лицо 1)

Кр 1500 (Юр. Лицо 2)

МожноИзменитьМодульТранзакции: “Да” - означает транзакции из модулей продаж, закупок и т.д. могут быть скорректированы в 25.13.1 Ведение Стандартных Транзакций ГК.

Непр. Номера Страниц Для Аудита: если “Да” система будет печатать аудиторские отчеты начиная со следующей страницы. Последняя страница храниться в функции ведения Юр. Лица (25.3.1) для Юр. Лица и в НомерПосл.Стр.ДляВыст.Аудита для компании. p>Ежедн./Непрерыв. Послед-ть Ссылок: определяет систему нумерации ссылок для некоторых транзакций ГК (JL - стандартные транзакции Главной Книги, RV- ретроактивные транзакции ГК, RA - обратные транзакции ГК, FX - транзакции переоценки иностранной валюты).

Ежедн - перезапускаются с номера 000001, и ссылочный номер может быть введен с клавиатуры.

Непрерыв. - номер генерируется системой и не может быть введен с клавиатуры.

6.1.2. Юридические Лица

В одной базе данных может быть несколько Юридических Лиц (ЮЛ). ЮЛ вводятся для ведения отдельных планов счетов и разных параметров календарей ГК, то есть ЮЛ вводятся в системе для возможности генерирования отдельной финансовой отчетности.

Все транзакции в системе ссылаются на определенные комбинации ЮЛ, счета, суб-счета и ЦЗ, что обеспечивает в БД с несколькими ЮЛ включение транзакции в требующуюся финансовую отчетность. Даже если в БД требуется одна финансовая отчетность необходимо ввести код ЮЛ в функции 25.3.1 Ведение Кодов Юр.Лиц.

ЮрЛицо: код Юридического Лица (ЮЛ).

Описание: описание ЮЛ, объединенного с этим кодом.

ОсновноеЮрЛицо: только для одного Юр. Лица базы может быть Да. Это ЮЛ будет использоваться по умолчанию в проводках системы, но может быть изменено на время сессии в функции 25.3.3 Изменение Кода Юр.Лица. Если в БД одно ЮЛ присвойте- Да.

Валюта: код базовой валюты ЮЛ, используется при импорте транзакций другого ЮЛ для определения требуется ли перевод в базовую валюту основного ЮЛ. В случае если в системе одно ЮЛ код в этом поле и значение поля “БазоваяВалюта” в 36.1 должны совпадать.

ВнестиСкоррект.Транз.В Б/Д: система приводит транзакции импортированные из другой базы, оперирующей другой валютой, к базовой валюте. Это приведения могут быть выставлены или в балансовую ведомость или в ведомость доходов. Если Вы не используете многовалютность, содержимое этого поля теряет значение.

Это поле используется только в случае импортирования транзакций другого юр. лица в небазовой валюте.

№ Страницы Для Печати Аудита: с номера введенного в этом поле будет начинаться отчет аудиторского контроля

6.1.3. Настройка агрегированной отчетности

Когда транзакции появляются в отчетах, они суммируются по счету/субсчету/ЦЗ.

Сходные счета группируются вместе. Например, счета денежных потоков в различных валютах могут быть сгруппированы вместе как Денежный Поток. Группы счетов могут быть дополнительно сгруппированы в большие группы, например, Текущие Активы. И в еще большие – Активы.

В MFG/PRO такие группы называются Позициями Формата (ПФ). ПФ озаглавливают группы счетов появляющиеся в балансовых отчетах и отчетах о прибылях/убытках. Они также определяют, в каких отчетах появляются счета (балансовых или о прибылях/убытках, счета не могут появляться и в одних и в других). Ввод ПФ осуществляется 25.3.7 Ведение Позиции Формата.

Позиция Формата: код позиции формата (не более 6 символов).

Описание: описание ПФ объединенной с этим кодом, то есть название группы счетов объединяемых этой ПФ. Например, если в этой ПФ будут объединены счета активов, то название может быть “Активы”.

Сумм. В: код позиции формата в который будет суммироваться итог этой позиции формата .

Тип Отчета: определяет в каком отчете будет появляться эта позиция формата. Каждая позиция формата может входить либо в “Баланс.Отчет” либо “Отчет по Доходам”.

Счета поступлений и расходов (I, E) включаются в отчеты о Прибылях и Убытках. Активы и обязательства (A, L) включаются в балансовые отчеты.

Норм. Баланс: определяет баланс счетов суммируемых в ПФ. Для счетов типов I и L- Кр, для А и E- Дб. В отчетах кредитовые суммы дебетовых ПФ будут показаны с минусом, также как дебетовые суммы кредитовых ПФ.

После заполнения полей этой рамки нажмите F1 и настройте параметры сортировки и формы отчетов.

Сорт-тьСуб-СчетаДоСчетов: устанавливает будут ли суб-счета предшествовать счетам при печати и сортировке позиций формата.

Сортировать ЦЗ Прежде Счетов: устанавливает будут ли центры затрат предшествовать счетам при печати и сортировке позиций формата.

Эти две установки работают вместе с установками в полях “Суммировать Суб-Счета” и “Суммиров.ЦентрыЗатрат” в функциях печати балансовых отчетов и отчетов о прибылях/убытках. В приведенной таблице представлены варианты установок в этих полях и соответствующие этим комбинациям последовательности вывода информации о счетах, суб-счетах и ЦЗ в отчетах.

С – счета, СС – суб-счета, ЦЗ – центры затрат.

РазрывСтр.ПослеИтога: указывает системе печатать ли следующую позицию формата с новой страницы. Обычно это делают после печати самых больших групп.

Подавить Загол., Подавить Итог: в отчете описание позиции формата может быть напечатано или перед вложенными счетами и позициями формата или после них.

ПропСтрокуПослеИтога, ДвойноеПодчерк. Итога: предназначены для организации читаемости формы отчета.

6.1.4. Счета Главной Книги

В MFG/PRO все транзакции ссылаются и выставляются в ГК на комбинацию ЮЛ и счета (обязательно) и суб-счет, ЦЗ и проект (опционально). Счета используются для определения как транзакции влияют на активы, расходы, обязательства и собственный капитал компании.

Счета вводятся в функции 25.3.13 Ведение Кодов Бухгалт.Счетов.

Счёт: код счета. Длина счета не может превышать 8 символов. Если используются суб- счета, то сумма длин счета и суб-счета должна быть не более 8 символов, так как в некоторых функция счет и суб-счет вводятся в одном поле (содержащем 8 символов).

Например, если счет содержит 2 символа, то длина суб-счета не может быть более 6 символов.

Описание: описание счета объединенного с этим кодом.

Тип: определяет отношение счета к балансу и может принимать значения:

Активные

A(Asset)- активы,

E(Expense)- расходы.

Пассивные

L(liability/Capital)- обязательства (капитал),

I(Income)- поступления.

Статистические

M(Memo) – используется в отчетах но не вносится в итоги.

S(Statistical) – используется в отчетах (не вносится в итоги) и в случае применения налогообложения НДС.

Валюта: возможно назначение счетам типов “A” и “L” не базовой валюты.

Позиция Формата: код позиции формата обозначающий в какой отчет и в какую главу будет входить счет. После назначения ПФ система ниже показывает иерархию ПФ до присвоенной счету.

ЗаписьТолькоИзСубМодулей: если “Да” - система не даст возможности записывать проводки в функциях 25.13.1 Вед.Стандарт. Транзакций, 25.13.2 Вед. Ретроактивных Транзакций, 25.13.3 Вед. Обратных Транзакций, 25.13.9 Переоценка Обмена Валюты.

Статистический Счет: используется в случае применения налогов НДС. В этом поле указывается счет с типом S для отражения сумм, с которых были рассчитаны налоги.

Активный: определяет - используется ли этот счет для проводок. Транзакции ГК могут ссылаться только на активные счета.

ИндексПреобр.ВалКурса: используется только когда переводятся суммы не в базовой валюте в базовую во время импорта транзакций из другой БД. Может принимать значения:

  1. текущая обменная ставка,
  2. взвешенная средняя,
  3. простая средняя,
  4. из истории,
  5. определенная пользователем.

1, 2 и 3 используют записи из функции 26.1, 4 берет ставку из экспортируемой базы, 5 устанавливается в 25.19.1.

6.1.5. Суб-счета Главной Книги

Для более детальной отчетности могут использоваться субсчета. Многие отчеты MFG/PRO позволяют суммировать суб-счета или печатать информацию о суб-счетах детально.

Во многих функциях системы счет и суб-счет необходимо вводить в одном поле (как комбинацию). Поэтому, необходимо заранее решить, сколько символов будет составлять длина счета и сколько суб-счета, и указать длину суб-счета в поле: “Длина Суб-Счета Суб-Модуля” функции 36.1 Контроль.Файл Системы/Бухг.Счета.

Например, все счета будут состоять из 2 символов (счет 10 ТМЦ), тогда длина суб- счета не должна превышать 6 символов, то есть (101 - суб-счет 1 счета 10). В поле ввода комбинированного кода счета/суб-счета необходимо будет ввести “10___101” (___- три пробела), тогда в проводке эта комбинация будет представлена как 10-101, то есть транзакция будет корреспондироваться с суб-счетом 101 счета 10.

Ввод суб-счетов производится в функции 25.3.17 Ведение Кодов Суб-Счетов.

Суб-Счет: код суб-счета. В системе для всех счетов, для которых, например, применяются суб-счет 1 этот суб-счет представляет один и тот же суб-счет, то есть если у счетов 10 и 19 существует суб-счет 1, то система просуммирует суммы проводок корреспондирующиеся с комбинациями 10-1 и 19-1 вместе на один суб-счет 1. Поэтому, для каждого счета необходимо вводить суб-счета относящиеся только к ним и имеющие специальную кодировку, указывающую на это, как это показано в примере: суб-счет 101- это суб-счет 1 счета 10.

Описание: описание (название) суб-счета.

Активный: система позволяет использовать в транзакциях только активные суб-счета. В рамке “Разр. Пред. Счётов” поля “Из Счета” и “До Счет” указывается диапазон счетов, с которыми суб-счет может составлять комбинацию в той или иной транзакции. Для описанной выше ситуации введите в обоих полях один и тот же счет (как в примере) После ввода суб-счетов необходимо указать признак “Исп. Суб-Счета”- “Да” в функции 25.24 Контр.Файл Гл.Бухг.Книги.

1.1.5.1 Коды Проектов

Коды проектов вводятся для отражения какой-либо стороны деятельности компании. Например, если есть потребность проследить операции ГК касающиеся создания нового отдела компании, необходимо ввести код проекта (в функции 25.3.11) и далее во всех операциях (закупки, продажи, производства и т.д.) имеющих свое отражение в транзакциях ГК указывать этот код. После выставления транзакций ГК можно напечатать отчеты (25.15.21 Сводные Работы по Проекту, 25.15.22 Детальные Работы по Проекту, 25.15.23 Сравнение Работ по Проекту) отражающие какие суммы на тех или иных счетах относятся к проекту.

Проект: код нового проекта.

Тип Проекта, Код Статуса: ссылочные поля, печатаемые в отчетах.

Активный: при записи транзакции система позволяет ссылаться только на активные проекты.

ДатаНачала, ПервичнаяДатаЗавершения, Пересмотр.ДатаЗаверш., Дата Исправл.,

РеальнаяДатаЗавершения: ссылочные поля для указания дат появляющихся в отчетах.

1.1.5.2 Коды Центров Затрат

Центры затрат используются для отчетности по подразделениям предприятия и могут быть присвоены к определенной комбинации счетов, суб-счетов. Их можно использовать, например, для большей детализации отчетности дополнительно к суб- счетам. Большинство отчетов ГК позволяют выводить данные по ЦЗ в деталях или суммировать.

Данные ЦЗ вводятся в функции 25.3.20 Ведение Кода Центра Затрат.

ЦентрЗатр: код Центра Затрат.

Описание: описание (название) Центра Затрат. Активный: система позволяет использовать в транзакциях только активные ЦЗ. Разр. Пред. Счётов, Разреш. Пред. Суб-Счетов: окна позволяющие задать диапазоны счетов и суб-счетов с которыми ЦЗ может составлять комбинацию.

1.1.5.3 Коды Резервирования

Коды резервирования позволяют делить сумму транзакции между несколькими счетами. То есть в поле указания счета проводки (или в функции указывающей счета для проводок по умолчанию, например, 1.2.1 Ведение ТНГ, 2.1.1 Ведение покупателей (Счет СД) и т.д.) Вы можете указать код резервирования (КР), который в свою очередь ссылается на несколько счетов. Транзакция будет содержать счета КР, а суммы, дебетующие или кредитующие счета, будут представлять собой определенную долю общей суммы транзакции. Например, для КР приведенного в окнах функции 25.3.23 Ведение Кодов Резервирования

проводка будет иметь вид:

Кр 1040 – 200р.

Дб 1200 – 50р.

Дб 2200 – 150р.

Счёт, Суб-Счет, ЦЗ, Проект – укажите комбинацию счета, суб-счета, ЦЗ и проекта получающего процент суммы транзакции. Процент - процент соответствующий комбинации счета/суб-счета/ЦЗ/Проекта. Сумма процентов всех строк должна быть 100%.

1.1.5.4 Календарь Главной Бухгалтерской Книги

Транзакции ГК выставляются по периодам определяемым в 25.3.4 Ведение Календаря Гл.Бухг.Книги. Периодов в году может быть любое количество, начинаться и заканчиваться они могут любой датой (но при этом не могут перекрываться, например, если один период заканчивается 31/01/00, то следующий должен начинаться с 01/02/00), но для всех ЮЛ БД они должны совпадать. В этой же функции можно закрыть период по тому или иному направлению деятельности.

Год, Период: год и порядковый номер периода ГК. Нач. Периода, КонПериода: даты начала и конца периода. Даты смежных периодов перекрываться не могут.

Как уже говорилось в этой функции могут быть закрыты периоды по некоторым направлениям деятельности компании, но при этом открытые и закрытые направления для разных ЮЛ могут не свпадать

Направления деятельности компании:

СК – счета кредиторов; СД – счета дебиторов; OС - основные средства; НЗ КС - наряд- заказы контроль складских запасов; ПВ – модуль зарплаты; ЗП – заказы на продажу; ГК – Главная Книга; Год Закрыт - закрытие всех направлений.

“Нет” в соответствующем поле означает, что модуль открыт. “Да” - закрыт

1.1.5.5 Настройка суб-модулей

При обработке операций в системе имеющих свое отражение в проводках ГК (выставление С-Ф по ЗП, Бухгалтерское закрытие Н-З и т.д.) программа использует счета указанные в записях нормативных данных (например, “Счет СД” в функции 2.1.1 используемый в проводках продаж определенного покупателя). Поэтому необходимо во всех записях нормативных данных используемых для проводок ГК ввести соответствующие им счета, суб-счета и ЦЗ.

Список функций, в которых необходимо указать какие счета, суб-счета и ЦЗ использовать в тех или иных проводках:

1.1.13 Ведение Заводов,

1.2.1 Ведение Групп Продуктов,

1.10.1.1 Ведение Прайс-Листов,

2.1.1 Ведение Покупателей,

2.3.1 Ведение Поставщиков,

2.13.13.1 Ведение Налогов. Ставки,

2.19.13 Ведение Кодов Доп. Услуг,

14.1 Ведение Цехов/Произв.Участков,

26.13 Ведение Банков,

27.6.1 Ведение Банков (покупателей),

28.9.1 Ведение Банков (поставщиков).

Помимо этого во время создания новых записей нормативных данных и в некоторых транзакция используются счета, суб-счета, ЦЗ указанные в контрольных файлах системы, таких как:

36.1 Контроль.Файл Системы/Бухг.Счета,

3.24 Контроль. Файл Складского Запаса,

5.24 Контрольный Файл Закупок,

7.1.24 Контроль. Файл Заказа на Продажу,

25.24 Контроль. Файл Заказа на Продажу,

27.24 Контр.Файл Счетов Дебиторов (СД),

28.24 Контр.Файл Счетов Кредитор. (СК).

6.1.6. Нормативные данные по налогам

6.1.6.1.1. Налогообложение в MFG/PRO

В одной базе данных может использоваться только одна система налогообложения из:

  • Прямые Налоги на Продажу (США),
  • Налоги на Добавл.Стоимость (НДС),
  • Смешанные Налоги (Канада),
  • Полное Управление Налогами.

Признак применения той или иной системы указывается в 36.1 Контроль.Файл Системы/Бухг.Счета, если применяются Налоги на Добавл.Стоимость(НДС), Смешанные Налоги(Канада) или Полное Управление Налогами необходимо поставить “Да” в соответствующем поле: Канад. Налоги, Нал. на Доб. Стоим, Исп.Упр-е Налогами, если применяются Прямые Налоги на Продажу(США) – всем трем полям необходимо присвоить Нет.

Покупатели, поставщики, ТНГ и позиции имеют флаги, определяющие облагаются ли обычно они налогами. Программа использует эти признаки для определения по умолчанию статусов и ставок налогов при создании заказов, проводок и ваучеров.

6.1.6.1.2. Возможности Полного Управления Налогами

Используя этот модуль можно:

  • ввести неограниченное количество налогов и ставок;
  • назначить определенным поставщикам, покупателям или позициям наиболее часто применяемые;
  • указать когда подсчитываются налоги, использующуюся при их подсчете формулу и какая сумма будет объектом налогообложения;
  • установить налоговые ставки, основанные на: географическом расположении покупателя/поставщика, действительной дате операции, в зависимости от вида деятельности компании и т.д.;
  • налоговые освобождения позволяющие генерировать отчеты;
  • настроить налогообложение по строкам заказов или по итогу;
  • создать налоги, основанные на части суммы операции или на базе суммы операции плюс другие налоги;
  • настроить накопительные налоги;
  • ввести налоги на закупку возвращаемые при продажах;
  • отменить подсчитанные системой налоги на ту или иную проводку и ввести с клавиатуры;
  • подсчитать налоги уже включенные в сумму операции;
  • ввести и учитывать при расчетах налоговые льготы;

Одним из преимуществ ПУН является простота перехода на другие способы расчета налогов (например, НДС).

6.1.6.1.3. Элементы модуля Полное Управление Налогами

Каждая страна в мире имеет уникальную систему налогообложения. Но при этом они зачастую имеют общие элементы. Модуль Полного Управления Налогами (ПУН) по возможности полно представляет каждую систему налогообложения, но с использованием специальных синтетических терминов (элементов), позволяющих настроить налогообложение под конкретные условия и правила.

Бизнес операции могут быть объектом многих разновидностей налогов – налоги с продаж, отечественные обязанности по импорту (пошлины) и т.д. В ПУН налог, который является специальным в регионе или в системе налогообложения, имеет особенный метод подсчета и включается в отчет отдельно от других называется типом налога.

Регионы, в которых действуют особые правила расчета налогов, в которых

существуют собственные типы и классы налогов называются налоговыми зонами.

Внутри налоговой зоны тип налога может воздействовать на всех людей и ном. позиции или только на некоторые из них. В ПУН покупатели, поставщики и позиции могут быть сгруппированы в класс налога. Подобным образом налог может быть оценен в различных ставках основывающихся на роде операции покупателя или на применении закупаемой позиции. В ПУН поставщики/покупатели и позиции могут также быть сгруппированы по использованию налогов.

При создании налогооблагаемой транзакции три фактора определяют какие типыналогов должны применяться к операции: 1) налоговая зона “отправка-из”, 2) налоговая зона “отправить-в”, 3) класс налога поставщика или покупателя. В ПУН комбинация установки типов налога для определенной “ship-to”/”ship-from” зоны и класса налога называется налоговой средой, то есть комбинация налоговых зон, между которыми производится операция и класса налога.

Тип налога при различных комбинациях налоговых классов, использований налогов и действительных дат транзакций может иметь различные проценты. Эти проценты называются - налоговыми ставками.

Налоговая база – сумма-объект налоговой ставки. Обычно база налога 100% суммы продажи или покупки позиции. Но Вы можете установить налоговую базу для части суммы транзакции, для суммы транзакции плюс другие налоги.

6.1.6.1.4. Настройка модуля Полное Управление Налогами

Для запуска модуля необходимо ввести информацию о налоговых зонах, средах, классах и т.д., на основе которых будут выбираться ставки налогов на ту или иную операцию. А также скорректировать признаки налогообложения продуктовых линий, покупателей, поставщиков, позиций, площадок (заводов) на которых производятся закупочно-сбытовые операции.

При вводе параметров модуля желательно придерживаться последовательности приведенной на рис. 13.

6.1.6.1.5. Описание шагов настройки модуля

Коды стран

1. Коды стран используются при записи налоговых зон, адресов и транзакций.

Для их ввода необходимо в функции 2.13.1.1 Ведение Кода Страны заполнить следующие поля.

Код Страны: код страны или если несколько стран имеют одинаковые типы налогов код группы стран. Например, если при создании транзакций между Россией - Россией и Россией – Беларусью применяются одинаковые типы налогов, то удобней создать одну налоговую среду для всех сделок. То есть среду, в которой налоговая зона отправителя РФ (Россия), налоговая зона получателя РБ (Россия, Беларусь).

Имя: название страны или группы стран объединенной с этим кодом. Два кода не

могут иметь одинаковое имя.

Имя в дальнейшем будет появляться печатаемых документах.

Альтернат.Код: (опционально) может принимать значение подгруппы объединенной с этим кодом или код используемый при сортировке и отличающийся от значения поля “Код Страны”.

Страна ЕС: этот признак используется системой для определения - относятся ли складские операции к внутриевропейским складским перемещениям, которые должны включаться в отчетность Intrastat.

После ввода кодов стран для облегчения ввода налоговых зон введите наиболее часто используемый код страны в поле “Код Страны” функции 2.13.24 Контр.Файл Полного Управл.Налог. – этот код будет присваиваться автоматически при вводе налоговых зон, но может быть отменен с клавиатуры.

2. Коды областей, районов и городов используются для определения корректной налоговой зоны по адресу компании, поставщика, покупателя. Если эти коды в записи адреса не соответствуют записям налоговых зон – будет назначена ошибочная налоговая зона.

Ввод кодов областей, районов и городов осуществляется в функции 36.2.13 Ведение Обобщенных Кодов.

Для ввода необходимо:

В поле “Имя поля” - ввести соответствующее имя поля Progress. Для ввода кода области- ad_state, района- ad_county, города- ad_city.

В поле “Знач.” ввести код области, района, города. Причем длина кода области не может превышать 4 знаков, района и города 20.

В поле комментариев можно ввести ссылочную информацию о коде, например, полное название города или района.

Налоговые зоны

Установить налоговые зоны 2.13.3.13 Ведение Налоговых Зон.

Налоговые зоны должны быть определены для каждой страны, области, штата, района, города для которых используются определенные налоговые типы и по которым требуется отдельная налоговая отчетность. Всем адресам покупателей, поставщиков и заводов соответствует определенная налоговая зона. При создании операций продаж, закупок и других налогооблагаемых транзакций налоговые зоны используются для определения налоговой среды, в которой указаны налоги, которыми облагается операция.

Нал.Зона: код налоговой зоны (не может превышать 16 символов).

Описание: описание налоговой зоны. Появляется в дальнейшем в отчетах и запросах.

Код Страны: код страны соответствующий коду налоговой зоны. Для вновь вводимых зон присваивается значение, указанное в контрольном файле ПУН.

Регион, Район, Гор.: присвойте значения ранее введенные в 36.2.13.

Почт.: если есть необходимость введите почтовый индекс соответствующий этой налоговой зоне. Если параметры налогов никогда не выбираются по индексу – оставьте это поле пустым.

ПодИтог Эт. Уров.: значение этого поля определяет будут ли суммы налогов этой

налоговой зоны появляться отдельным под-итогом в отчетах.

Зона Отчета: определяет появляется ли налоговая зона в отчетах.

Если налоговых зон много и существует потребность в настройке сложной отчетности – они могут быть сгруппированы в иерархии для суммарных отчетов.

Например, созданы налоговые зоны РФ, Пензенской области, Самарской области, Беларуси, СНГ. Для отчетности необходимо чтобы Пензенская и Самарская области суммировались в РФ, а РФ и Беларусь в СНГ.

Для этого в поле “Сумм. в Нал. Зону” рамки “Суммы-В Нал. Зону” зоны нижнего уровня введите код зоны верхнего уровня. Например, для зоны РФ будет СНГ.

Для удобства ввода иерархии зон - начинать следует с ввода верхнего уровня затем более низкого и т.д. (Для примера: 1) СНГ, 2) РФ, Беларусь, 3) области).

Ввод налоговых зон закончите вводом кода “ошибочной налоговой зоны”. Затем присвойте это значение в поле “НалогЗона” функции 2.13.24. Это значение будет использоваться системой, когда Вы будете вводить данные адресов. В этот момент она проверяет по параметрам адреса какой налоговой зоне соответствует адрес и если таковой не находится система присваивает значение поля “НалогЗона” (2.13.24).

Тип налогов

Тип налогов – определенный вид налогов, подсчитываемый по специфическим правилам и присутствующий в налоговых отчетах отдельной строкой. Например, в России типами налогов можно назвать НДС, Налог с Продаж, Акцизы. Во время обработки налогооблагаемой транзакции система подсчитывает налоги ТНГ и Дополнительных Услуг, основываясь на типах их налоговой среды.

Если существует потребность отчетности и по необлагаемым налогами транзакциям необходимо ввести и тип освобождения от налогов.

Ввод налоговых типов производится в функции 2.13.1.1 Ведение Типов Налогов и включает в себя заполнение двух полей.

ТипНалога: длина кода типа налога не может превышать 16 символов. Описание: описание типа налога.

Коды налоговых классов и использований В случае если налоги определенной налоговой зоны рассчитываются по разным правилам необходимо ввести коды налоговых классов и использований. Примерами применения классов и использований могут послужить следующие ситуации.

То есть классы и использования применяются для определения налоговой ставки типа в зависимости налоговых характеристик позиции (покупателя/поставщика) и от условий транзакции.

Например, для некоторых ситуаций Российской системы налогообложения можно составить следующую таблицу взаимосвязи типов, классов и использований налогов.

В клетках пересечения типа/использования и класса – налоговые ставки.

В таблице классы: 1- обычный налог НДС (20%), 2- налог НДС на ГСМ (16%) и Акциз 6%, 3- некий налог НДС со ставкой 10% и Акцизом 6%.

Использования: Исп1- продажа/закупка производится за наличный расчет, то есть сделка облагается дополнительно Налогом с Продаж, Исп2- продажа/закупка производится за безналичный расчет, то есть сделка не облагается Налогом с Продаж (ставка НП=0%).

Ввод налоговых классов и использований налогов осуществляется в функциях 2.13.1.5 Ведение Классов Налогов и 2.13.1.9 Ведение Использования Налогов.

КлассНалога: длина кода класса не может превышать 3 знаков.

Описание: описание кода класса налога. Появляется в отчетах как дополнительная информация о классе.

Исп.Налога: код использования налога может содержать не более 8 знаков.

Описание: описание кода использования налога. Появляется в отчетах как дополнительная информация об использовании.

Методы округления

Во время ввода транзакции система подсчитывает суммы налогов, которые необходимо округлять для отображения в отчетах и на экранах ввода транзакций. В ПУН можно назначить определенный метод округления каждому типу налоговой среды.

В системе уже есть три метода округления:

  • округление до целого;
  • округление до десятых;
  • округление до сотых.

Если этих методов не достаточно можно ввести дополнительные в функции 2.13.1.17 Вед. Методов Округления.

МетодОкругления: цифровой код (одна цифра). Методы с кодами 0,1 и 2 поставляются вместе с MFG/PRO и эти методы не могут быть изменены пользователями.

Описание: описание метода округления. Появляется в отчетах как дополнительная информация о методе.

ЕдиницаОкругл.: может принимать целое или десятичное значение получившееся как степень 10 умноженная на 1 или 5 (например, 10, 50, 0.01, 0.5 и т.д.) Порог Округления: определяет точку с которой суммы округляются до ближайшего меньшего значения или большего. Если сумма меньше то округляется до меньшего, если больше или равна, то до большего.

В приведенном ниже примере сумма налога 12.2345 будет округлена как 12.235, а сумма 12.2343 как 12.234.

Десятич.Точка: может принимать значения “.” или “,”.

После ввода методов округления введите код наиболее часто используемого метода в поле “МетодОкругления” функции 2.13.24 – этот код будет присваиваться по умолчанию при вводе метода округления типа налога во время задания налоговых сред.

Налоговая среда

Перед подсчетом налогов система определяет, используя записи адресов покупателя и продавца, к какой налоговой среде относится транзакция для определения того какие типы налогов применяются к транзакции. Таким образом, Налоговая Среда – это установка типов налогов применяемых в той или иной комбинации налоговых зон “отправителя” и “получателя” и опционально класса покупателя или поставщика.

Например, в операциях закупки/продажи из России (налоговая зона отправителя- РФ) в Россию (налоговая зона получателя- РФ) будут применяться типы налогов: НДС, НП, Акцизы и другие применяемые к внутри-российским расчетам. В операциях закупки/продажи из США (налоговая зона отправителя- США) в Россию (налоговая зона получателя- РФ) будут применяться типы налогов: американские налоги: федеральный налог США, налог штата и т.д. (или просто один тип “Налоги США”), пошлины и т.п.

Установку записей налоговых сред осуществляют в функции 2.13.5.1 Ведение Налоговой Среды.

Налоговая Среда: код налоговой среды (не более 16 знаков).

Описание: описание налоговой среды система не предотвращает ввод одинаковых описаний для разных сред.

Нажмите F1 и введите комбинации налоговых зон и классов.

Отгр.ИзНалЗоны: в этом поле можно ввести налоговую зону из которой происходит отгрузка товаров, но если все отгрузки происходят из одной налоговой зоны – оставьте это поле пустым.

ЗонаГрузопол.: в этом поле можно ввести налоговую зону получения товаров, но если все получения происходят в одну налоговую зону – оставьте это поле пустым.

КНл: если налоговая среда должна дополнительно выбираться по налоговому классу покупателя/поставщика введите их в этом поле. Если налоговая зона применяется для всех поставщиков/покупателей (не зависимо от их налогового класса) – оставьте это поле пустым. Не вводите в этом поле класс позиции – ПУН использует класс позиции только для определения ставок.

Описание: описание комбинации налоговых зон “отправителя”, “поставщика” и класса.

Если налоговая среда является общей для всех налоговых зон оставьте поля Отгр.ИзНалЗоны и ЗонаГрузопол. Пустыми. Аналогично, если в среде используются все классы налогов оставьте поле класс пустым.

Нажмите F4 и введите типы налогов применяемые в этой среде.

ТипНалога: код типа налогов применяемый к операциям в этой среде. Для возможности отчетности по необлагаемым налогами суммам введите дополнительный тип налогов “Не облаг-й налогами”.

Пс: определяет последовательность подсчета сумм налогов типов в среде. То есть тип с последовательностью 1- будет подсчитан первым, с 2- вторым и т.д. В ситуации, когда один налог подсчитывается на основе другого – подсчитываемый первым должен иметь меньший номер последовательности. Например, в российской системе налогообложения НП подсчитывается на основе НДС, то есть НДС должен подсчитываться раньше НП.

R: метод округления применяемый к конкретному типу налогов, предварительно введенный в 2.13.1.17.

Описание Типа: принимается описание типа введенное в 2.13.1.1.

Типы налогов в среде имеют номер последовательности и методы округления.

Последовательность типов используется при расчете смешанных налогов, раньше рассчитываются налоги с меньшим последовательным номером. Введите тип налога “Nontaxable” (необлагаемый) для возможности формирования отчетов по необлагаемым сделкам, причем этот тип необязательно вводить в 2.13.1.1 – он уже существует в MFG/PRO.

После ввода необходимых налоговых сред, введите “Ошибочную Налоговую Среду” и укажите ее код в поле “Налоговая Среда” функции 2.13.24 – это среда будет назначаться транзакции если система на основе информации о компании и покупателе/поставщике не найдет какую либо подходящую под эти условия среду.

База налогов

Базы налогов используется для вычисления налогов, для которых налогооблагаемой базой является или 1) часть суммы транзакции или 2) сумма транзакции плюс другой налог.

В российской системе налогообложения эта возможность может быть полезной при расчете Налога с Продаж в операция с наличными расчетами. То есть база НП равна сумме транзакции и налога НДС.

Например, сумма продажи 200р., НДС=(200/100)*20=40р.,

НП=((200+40)/100)*5=12р.

Таким образом, в ставке для расчета НП потребуется указать, что база налога равна сумме транзакции и налога НДС. Для этого необходимо в функции 2.13.1.13 Ведение Базовых Налогов ввести данные базы налога.

Нал.База: код базы налога (не более 8 символов).

Описание: описание базы налога.

Баз. Процент: процент от суммы транзакции являющийся базой, на которую будет начисляться налог.

Это поле используется, если база налога равна части суммы операции или больше ее на определенный процент. Например, если налог рассчитывается на 50% стоимости закупаемого товара – базой налога будет 50% (соответственно это значение необходимо присвоить этому полю).

Для обозначения налоговых льгот значение этого поля должно быть отрицательным.

Баз.Знач.: налог может рассчитываться на основе суммы продажи или суммы затрат Главной Книги позиции.

После заполнения полей первой рамки функции нажмите F1 и внесите в базу налога коды типов налогов, которые должны вносится в базу рассчитываемого налога. Для приведенного примера в сумму базы НП должна быть внесена сумма НДС.

Бухгалтерский учет суммы налогов

Суммы налогов в системе рассчитываются отдельно по каждой налоговой ставке в которой указывается комбинация счета, суб-счента и ЦЗ Главной Книги куда будут вносится суммы налогов.

Поэтому на этом этапе необходимо ввести все необходимые счета, суб-счета и ЦЗ для сумм налогов, используя функции: 25.3.20 Ведение Кодов Бухгалт.Счетов, 25.3.17 Ведение Кодов Суб-7Счетов, 25.3.20 Ведение Кода Центра Затрат (методика их ввода описана отдельно).

После ввода счетов, суб-счетов, ЦЗ введите их в соответствующих полях функции 36.1 для автоматического их присвоения в функции 2.13.13.1 Ведение Налогов. Ставки во время ввода новых ставок (значения по умолчания могут быть отменены и изменены на требующиеся).

Налоговые ставки

Для расчета сумм налогов по типам система использует налоговые ставки в которых указаны процент налога, база налога, счета ГК и другая информация в зависимости от использования, класса и действительной даты.

Для облегчения ввода ставок налогов необходимо настроить некоторые поля 2.13.24 Контр.Файл Полного Управл.Налог.: Нал. Метод, НалПоСтрокам, НарастНалоговПриПолучении, Налог Скидки в Счет-Факт., Налог Скидки при Оплате, МожноИзменятьНалоги (значения этих полей приведены в описании функции 2.13.13.1). Такие же поля есть и в функции 2.13.13.1 Ведение Налогов. Ставки и они будут принимать по умолчанию значения, введенные в контрольном файле.

ТипНалога: определяет тип налога, для которого вводится ставка. КлассНалогаПоз: назначает класс типа налога. Если ставка применяется ко всем классам оставить это поле пустым.

ИспНалога: устанавливает использование типа налога. Оставьте поле пустым если ставка применяется независимо от использования.

НалПоСтрокам: определяет либо налоги рассчитываются отдельно по строкам либо по итогу транзакции. В транзакциях продаж налоги на дополнительные услуги всегда рассчитываются на основе итога заказа не зависимо от установки в этом поле. Эта установка не имеет влияния на счета подсчета налогов СД и СК; по Дб/Кр проводкам налоги всегда рассчитываются по итогу, а в ваучерах по линиям позиций.

Нал.База: определяет базовую сумму для расчета налога. Оставьте поле пустым если база составляет 100%.

Мин.Обл.Нал: минимальная базовая сумма для которой применяется налоговая ставка.

Макс.Обл.Нал: максимальная базовая сумма к которой применяется ставка.

Возместимый%: определяет возвращаемый процент налога, если Вы можете возместить часть или всю сумму налога по закупочной операции для этой ставки суммой налога получаемой по этой ставке при продажах.

В российской системе налогообложения это поле можно использовать для отражения сумм налогов по закупкам на определенных счетах, счет необходимо в этом случае указать в поле “Нал.Счет СК”, иначе суммы налогов по закупкам будут относится на счета отклонений по закупкам.

Нал. Метод: необходимо выбрать из существующих стандартных методов 01, 02, 11, 12 (возможно дополнение собственных, созданием специальных программ).

Формулы расчета.

1. Метод 01.

Сумма налога=Налоговая ставка*Сумма позиции.

Для обратно подсчитываемых налогов, то есть если налог уже входит в сумму транзакции. Сумма налога=Налоговая ставка*[Сумма позиции/(1+ Налоговая ставка)].

Налогооблагаемая база= Сумма позиции*Процент базы налога.

Если Налогооблагаемая база< Мин.Обл.Нал, Сумма налога=Мин налог

Если Налогооблагаемая база> Макс.Обл.Нал, Сумма налога=Макс налог

Возвращаемая сумма=Сумма налога*Возместимый%

2. Метод 02.

Аналогичны формулам метода 01 за исключением того, что он поддерживает роскоши на предметы налоги и перекрывает налоги, которые оцениваются только на определенные налогооблагаемые базы.

Если Налогооблагаемая база< Мин.Обл.Нал, Сумма налога=0

Если Налогооблагаемая база> Макс.Обл.Нал, Сумма налога=0

3. Метод 11.

Такой же как метод 01, но имеет регрессивный подсчет обратно подсчитываемых налогов.

Сумма налога=Налоговая ставка*Сумма позиции.

МожноИзменятьНалоги: определяет, могут ли пользователи использовать опцию просмотр/редактирование деталей налогов во время записи транзакции для изменения принятой системой налогооблагаемой базы и сумм налога. Но при этом система не ведет аудиторский контроль за изменениями.

МожноВключитьНалог: определяет - может ли использоваться обратный-подсчет налогов (то есть подсчет суммы налога когда она уже включена в сумму операции – транзакции в которых поле “С Нал.”- Да) при использовании этой ставки. ЗАМЕЧАНИЕ. В версии MFG/PRO Release 8.6C налоги не вычленяются из сумм дополнительных услуг ЗП (7.1.1, 7.13.1) и КП (6.1).

СписокПродажКИ, ПроцессКИ: опции применяемые в странах Европейского Сообщества.

Счёт Нал.на Прдж: определяет счет обязательств по налогам при продажах.

Кредитуется в момент подсчета налогов по операции продажи (в функциях 7.13.4, 27.1).

По умолчанию счет устанавливается из 36.1, но может быть изменен.

Абсорб.Нал./Прдж-у: определяет обязательства по налогам при продажах (счет кредитуется в 7.13.4, 27.1). Используется - если Ваша компания платит налоги взамен перевода их на покупателя. Если ставка налога для абсорбированных налогов установите опцию - Да. По умолчанию счет устанавливается из 36.1, но может быть изменен.

Нал.Счет СК: определяет счет дебитуемый для получения обратно налогов по закупкам и счетам кредиторов или когда обязательства трактовались как контрсчет платежей налогов с продаж. По умолчанию счет устанавливается из 36.1, но может быть изменен.

Удерж.Нал.СК: определяет счет обязательств кредитуемый когда Ваша компания отправляет налоговые суммы напрямую государству взамен поставщика. Если ставка для удерживаемых налогов установите эту опцию - “Да”. По умолчанию счет устанавливается из 36.1, но может быть изменен.

НарастНалоговПриПолучении: эта устновка определяет, создает ли система записи ГК для сумм налогов по закупкам до получения товаров или С-Ф поставщика. По умолчанию записи создаются во время получения товаров. Однако для возвращаемых налоговых ставок присвойте значение “Нет”, т.к. Вы не можете вычесть возвращаемую часть налогового платежа на закупки с налога собранного по продажам пока Вы не подтвердите ваучер по С-Ф поставщика.

Налог Скидки в Счет-Факт.: эта установка определяет, подсчитывается ли налоги на основе суммы продажи минус скидка по условиям кредита. Если налог базируется на полной сумме продажи установите “Нет”.

Налог Скидки при Оплате: эта установка похожа на предыдущую за исключением того, что чистый итог заказа равен сумме продажи со скидкой плюс сумма налога со скидкой.

Параметры покупателей, поставщиков, Н.П. и ТНГ

Скорректировать параметры покупателей, поставщиков, ном. позиции и ТНГ (2.1.1, 2.3.1, 1.2.1, 1.4.1).

3.4.2.5.Контр.Файл Полного Управл.Налог (2.13.24).

Загруз.Упр-е Налог.: Да- для активизации окна налогообложения при вводе компании (2.12), покупателя (2.1.1) и поставщика (2.3.1).

НалогЗона: код налоговой зоны присваиваемый в случае если система не в состоянии определить НалогЗона компании (продавца или покупателя) при обработке транзакций продажи/закупки (например, при создании ЗП).

Налоговая Среда: код среды присваиваемый в случае если система не в состоянии определить код НалоговуюСреду по умолчанию при обработке налогооблагаемой транзакции (например, при создании ЗП).

Код Страны: значение по умолчанию для большинства налоговых зон, являющееся вершиной иерархии суммирования (используется как значение по умолчанию поля “Код Страны” в функции 2.13.3.13).

МетодОкругления: код метода округления принимаемый по умолчанию в 2.13.5.1 Ведение Налоговой Среды (вводится в 2.13.1.17).

Нал. Метод, НалПоСтрокам, НарастНалоговПриПолучении, Налог Скидки в Счет- Факт., Налог Скидки при Оплате, МожноИзменятьНалоги: значения принимаемые по умолчанию при создании новой налоговой ставки (2.13.13.1)

МожноОбновл.Историю: определяет могут ли пользователи изменять записи деталей истории налогов. Установка этого поля имеет смысл только если “ВестиИст.Налога: Да”. ВестиИст.Налога: определяет будет ли MFG/PRO создавать записи истории налогов.

Записи истории всегда создаются по позиции. Эта установка должна быть Да если “МожноОбновл.Историю: Да”.

ПодтвердитьРегистрациюНДС: введите Да для возможности доступа к полям ввода регистрационных номеров налогов в функциях ведения адресов.

ПечатьРегистрациюНДС: определяет - будет ли система печатать регистрационные номера в документах (например, ЗП,КП, С-Ф, Дб/Кр проводки, ЗЗ и т.д.).

Показать Детали в Отчете: будут ли печататься налоги в документах “В деталях” или “Суммарно” (например, в ЗП, ЗЗ, Квитанциях о получении и т.д.). Суммарные налоги Вы можете печатать только если эта установка и установка “Печат. Дополнит.Услуги” – “Да” в функции печати документов. Детали налогов можно печатать только в документах содержащих дополнительные услуги

ПослКодНалога: система может автоматически назначать номер налоговой ставки (2.13.13.1). В этом поле представлен последний автоматически назначенный код (обновляется системой).

1.1.6.2 Ввод данных налогообложения заводов, покупателей, поставщиков, ТНГ, позиций 1.1.6.2.1 Адреса компании и заводов

В ПУН заводу должен соответствовать адрес компании, так как налоги подсчитываются по адресу, а не по заводу. Поэтому каждый завод компании должениметь запись адреса с таким же кодом адреса как код завода. Записи адресов создаются в функции 2.12 Ведение Адресов Компании. Данные налогообложения завода вводятся в окне “Нал.Инф”.

Налоблг.: признак налогообложения завода. Если операции, производимые с этим заводом облагаются налогами присвойте “Х” (снятие и присвоение “Х” осуществляется пробелом).

С Нал.: показывает - могут ли налоги быть включены в сумму транзакции производимой с этим заводом, компанией. “Да” – налоги могут быть включены в сумму транзакции, “Нет” – налоги всегда начисляются.

Облаг. РНП: применяется в случае использования канадского налогообложения.

КлассНал.: класс налога завода используемый для определения налоговой среды.

Нал.Зона: налоговая зона завода используемая для определения налоговой зоны завода.

ИспНалога: код использования налога используемый по умолчанию во время создания налогооблагаемых транзакций.

ИН Нал.-Федер.: код идентификационного номера налогоплательщика. Печатается в некоторых отчетах и документах.

ИН Нал.- Штат: идентификационный номер НДС. Печатается на документах (таких как ЗП или С-Ф) и в некоторых отчетах.

ИН Нал.-Смеш.1, ИН Нал.-Смеш.2, ИН Нал.-Смеш.3: ссылочные поля значения которых могут присутствовать в некоторых отчетах.

Код Страны: код страны регистрационного номера НДС (номер задается в поле ИН Нал.-Федер.). Появляется в момент сохранения данных окна “Нал.Инф”, если поле “Подтвердить Регистрацию НДС”- Да в функции 2.13.24.

ИН Нал.-Смеш.: номер регистрационного номера НДС (номер задается в поле ИН Нал.- Федер.). Появляется в момент сохранения данных окна “Нал.Инф”, если поле “Подтвердить Регистрацию НДС”- Да в функции 2.13.24.

1.1.6.2.2 Адреса покупателей, поставщиков

В функциях ввода информации адресов покупателей (2.1.1), поставщиков (2.3.1) в отдельном окне указываются данные налогообложения. Эти данные будут приниматься по умолчанию во время создания налогооблагаемых транзакций.

Налоблг.: признак налогообложения контрагента: Да- транзакции с этим контрагентом облагаются налогами, Нет- не облагаются.

Нал.Зона: система принимает код налоговой зоны основываясь на кодах страны, региона, города контрагента.

КлассНал.: используется для определения налоговой среды транзакции.

ИспНалога: код использования налога принимаемый по умолчанию во время создания налогооблагаемой транзакции.

С Нал.: если налоги уже включены суммы операций с этим контрагентом введите Да.

ИН Нал.-Федер.: код идентификационного номера налогоплательщика. Печатается в некоторых отчетах и документах.

ИН Нал.- Штат: идентификационный номер НДС. Печатается на документах (таких как ЗП или С-Ф) и в некоторых отчетах.

ИН Нал.-Смеш.1, ИН Нал.-Смеш.2, ИН Нал.-Смеш.3: ссылочные поля значения которых могут присутствовать в некоторых отчетах.

In City: указывает находится ли адрес в границах города для налоговых потребностей.

1.1.6.2.3 Данные ТНГ, позиций

В функциях ведения ТНГ (1.2.1) и позиций (1.4.1) введите признак налогообложения:

Налоблг.: “Да” - если ТНГ или позиция облагаются налогами, “Нет” - если не облагаются. И класс налога, принимаемый по умолчанию во время создания налогооблагаемых операций в поле “КлассНал.”.

1.1.6.3 Признак применения Полного Управления Налогами

Для запуска использования модуля ПУН присвойте Да в поле “Исп.Упр-е

Налогами” функции 36.1 Контроль.Файл Системы/Бухг.Счета.

1.1.6.4 Применение Полного Управления Налогами

1.1.6.5 Рекомендации по настройке параметров модуля ПУН в соответствии с Российской системой налогообложения

1. Для подсчета налогов НДС и НП при формировании операций с наличным расчетом создайте специальное использование и в ставке для типа налога НП с этим использованием укажите код “Нал.База” включающей сумму операции и налога НДС. Перед созданием налоговой ставки введите код налоговой базы в функции 2.13.1.13 Ведение Базовых Налогов в соответствии с приведенной выше методикой.

2. Если операция облагается НП и НДС и при этом суммы налогов вычленяются из суммы операции, рекомендуем использовать базу налога для расчета НДС - 95.238% суммы операции. Так как система использует в качестве исходной базы для расчета всех налогов сумму операции, то необходимо исключить из расчета НДС сумму НП (Налогооблагаемая база НДС = СуммаОперации – СуммаНП). Для этого определяется процентное соотношение Суммы Операции (СО) и Суммы из которой должен быть вычленен НДС (Сумма Для НДС- СД НДС):

100% СО = 105% СД НДС,

Х = 100% СД НДС,

откуда

Х=(100*100)/105=95.23809%.

Создайте специальную ставку для определенного использования/класса и с налоговой базой 95.238%, которую предварительно необходимо ввести в 2.13.1.13 Ведение Базовых Налогов.

3. Во время создания налогооблагаемой операции система определяет суммы налогов для всех Типов Налогов налоговой среды, и если для комбинации даты/класса/использования, вводимой операции какого либо Типа налоговой среды ставка не существует, то система показывает предупреждение, замедляющее работу по вводу операции.

Для избежания появления предупреждений введите ставки (2.13.13.1) для всех комбинаций дат/классов/использований, даже если они нулевые, для всех типов Налоговой Среды.

4. Для того, чтобы система во время создания ваучера формировала проводку:

Дб Счета Налогов

Кр Счет Кредитора

В функции ведения ставок 2.13.13.1 налоговым ставкам необходимо присвоить полю “Возместимый %”- 100.00%, а в поле “Нал.Счет СК”- указать счет, который должен дебетоваться в вышеприведенной проводке.

1.1.6.6 Пример настройки параметров модуля

  1. Код страны (2.13.3.1) – РФ.
  2. Налоговая зона (2.13.3.13) – РФ.
  3. Типы (2.13.1.1) – НДС- Налог на добавленную стоимость, НП- Налог с Продаж.
  4. Класс (2.13.1.5) – 001- Обычный.
  5. Использования (2.13.1.9) – И1- только НДС, И2- НДС с НП, И3- для вычленения НДС из суммы транзакции в случае использования НДС и НП.
  6. Налоговая среда (2.13.5.1) – РФ/РФ. Параметры: Зоны Отгр.ИзНалЗоны и ЗонаГрузопол.-РФ, Класс- пробел, Типы

8. Ставки (2.13.13.1).

Лекция 7. Реализация концепции трехуровневого планирования деятельности предприятия в MFG/PRO

7.1. Методология MRP

Методология MRP разрабатывалась в 60-х годах прошлого века под влиянием целого комплекса факторов. Послевоенное оживление экономики выдвинуло на повестку дня задачу эффективного управления себестоимостью продукции. В ответ на это активизировались исследования в области математической экономики, которые столкнулись не только с методологическими трудностями, но и с техническими проблемами: нужно было за разумное время уметь учитывать огромное множество параметров. С развитием вычислительной техники эти проблемы были преодолены. В результате появились первые автоматизированные системы планирования - системы планирования материальных ресурсов, MRP-системы.

Почему первые системы были ориентированы именно на работу с материалами?

Управление материальными ресурсами - одна из важных областей планирования.

Успешное функционирование промышленного предприятия напрямую зависит от того, насколько хорошо и ритмично оно снабжается сырьем или комплектующими, насколько рационально используются складские площади, и, наконец, насколько тесно объемы выпуска связаны с заказами клиентов или потребностью рынка. Отклонение от оптимального значения любой из этих составляющих приводит к проблемам: перебои с поставками сырья ведут к простоям оборудования и снижению выпуска продукции; поступление большего, чем необходимо, количества материалов может повлечь необоснованные потери в виде избыточных запасов на складах (обычно такие запасы называют «омертвленными затратами»).

Проблема наличия необходимых материалов и комплектующих в нужное время, в нужном месте и в нужном количестве особенно актуальна для массовых сборочных производств, где простои конвейера недопустимы. Именно под такие производства и разрабатывалась методология MRP и соответствующие программные решения.

Методология MRP служит для реализации следующих целей:

  • Минимизировать запасы на складах сырья и готовой продукции;
  • Оптимизировать поступление материалов и комплектующих в производство и исключить простои оборудования из-за не прибывших во время материалов и комплектующих.

В соответствии с этим, закупки материалов и комплектующих всего отрезка планирования автоматически распределяются по плановым периодам (например, дням), причем объем и время закупок рассчитываются так, чтобы в каждый плановый период на предприятие поступало именно столько материалов и комплектующих, сколько требуется производству в этом плановом периоде.

7.1.1 Логика работы MRP-модуля: информация на входе и выходе Остановимся подробнее на алгоритме работы MRP-модуля. Для простоты речь ниже будет идти о дискретном производстве. Как и всякая компьютерная программа, MRP-система обменивается с окружающей средой входной и выходной информацией (рис. 1).

Для работы MRP-модуля требуются следующие входные данные:

- Основной производственный план-график (объемно-календарный план, Master Production Schedule - MPS) - документ, в котором расписано, сколько единиц конечного изделия будет производиться в каждый плановый период отрезка планирования;

- Данные о состоянии запасов (книга учета запасов, Inventory Status File) - документ, максимально полно раскрывающий информацию о каждой учетной единице сырья, материалов, комплектующих, конечных изделий, включающую:

  • Общее описание - идентифицирующий код, характеристику, размер, вес и пр.;
  • Данные о запасах: единица запаса, расположение, размер запаса, статус (например, находится на руках, на складе, в текущих заказах), оптимальный запас, страховой запас и пр.;
  • Данные по закупкам и продажам для сырья, материалов и комплектующих: единица закупки/продажи, основные поставщики/покупатели, цена, время доставки, реквизиты поставщиков/покупателей, дополнительная информация (например, возможные задержки поставок);
  • Данные по производству для полуфабрикатов и конечных изделий: размер партии, длительность производственного цикла;

- Спецификация состава изделия (Bill of Materials File - BOM) - документ, содержащий:

  • Перечень сырья, материалов и комплектующих, необходимых для производства конечного изделия, с указанием нормативов по их использованию;
  • И ерархическое описание структуры конечного изделия.

Результатами работы MRP-модуля являются следующие документы:

- График заказов на закупку/производство материалов и комплектующих (Planned Order Schedule) - документ, расписывающий, какое количество сырья, материалов, комплектующих должно быть заказано в каждый плановый период в течение срока планирования. Этот документ определяет внутрипроизводственный план сборки комплектующих и план внешних закупок;

- Изменения к графику заказов на закупку/производство материалов и комплектующих (Changes in planned orders) - документ, содержащий корректировки ранее спланированных заказов на закупку/производство материалов и комплектующих. Входные и выходные данные MRP-модуля представляются в виде таблиц базы данных.

7.1.2 Логика работы MRP-модуля: схема цикла

На рис. 2 приведен пример, иллюстрирующий логическую схему MRP-цикла. Собственно MRP-цикл состоит из следующих шагов.

1. Составляется таблица общих потребностей в материалах и комплектующих. Последовательность ее создания такова.

1.1. Древовидная структура состава изделия разворачивается в линейный список материалов и комплектующих (1а):

  • Узловые элементы различных уровней сборки кодируются - корневому элементу присваивается код 0, элементам самого верхнего уровня сборки - код 1 и т.д. по уровням;
  • Если некоторый элемент встречается на различных уровнях, ему присваивается код самого нижнего из этих уровней (и, таким образом, в линейном списке этот элемент встретится только один раз);
  • Разузлование состава изделия происходит последовательно по уровням - сначала обрабатывается уровень 0, затем уровень 1, и т.д.

Примечание 1: в приведенном ниже примере изделию A будет присвоен код 0, узлу C - код 1, узлам D и B - код 2. Узел B встречается на более высоком уровне сборки, но учитывается на нижнем уровне.

1.2. Из книги учета запасов переносятся данные о материалах и комплектующих, необходимых для производства конечного изделия, и, в частности, данные о времени выполнения заказа на их поставку/производство (1б).

1.3. Переносятся плановые показатели выпуска конечного изделия из основного план-графика производства (1в).

1.4. По каждому материалу и узлу для каждого планового периода рассчитывается общая производственная потребность в этом материале/узле; при этом используются данные состава изделия (количество каждого материала/узла, необходимое для производства конечного изделия или промежуточного узла) и информация о времени поставки/производства материалов и комплектующих.

Примечание 2. В приведенном ниже примере общая потребность в элементе В во втором плановом периоде (она равна 400) получается так: потребность производства «А» в элементе «В» в третьем плановом периоде - 200 элементов (100·2), потребность производства «С» в элементе «В» в третьем плановом периоде - тоже 200 элементов. С учетом того, что время поставки/производства элемента В - один плановый период, заказ элемента В записывается во второй плановый период в количестве 400 единиц (200+200). Аналогично рассчитываются остальные ячейки таблицы.

2. По каждому материалу на каждый плановый период считается чистая потребность в этом материале. При этом используются данные о состоянии запасов.

Чистая потребность считается по формуле:

Чистая потребность = общая потребность - (текущие запасы + активные заказы - страховой запас)

Примечание 3. В идеале MRP-система не должна создавать страховых запасов. Однако в реальности случаются непредвиденные и неустранимые срывы поставок материалов. Для поддержания процесса производства в подобных ситуациях создают страховой запас. Его размер определяется заранее компетентными лицами и зависит от конкретных условий производственного процесса.

3. По ненулевым чистым потребностям формируется график заказов на закупку/производство материалов и комплектующих. При его создании учитывается время выполнения каждого заказа.

4. Просматриваются заказы, сгенерированные ранее текущего периода планирования. В случае необходимости система пересчитывает сроки и размер заказа и вносит корректировки в сформированный ранее план-график закупок. Эти изменения автоматически регистрируются в базе данных о состоянии запасов (поскольку создание, отмена или модификация заказа влияет на статус соответствующего ему материала).

Представленная схема работы MRP-цикла очень упрощена. В реальности необходимо учитывать огромный спектр особенностей конкретного производственного процесса (например, широкий ассортимент производимых товаров, конструктивную сложность конечных изделий, территориальную разбросанность складов, регулярные сбои поставок комплектующих). Поэтому MRP-системам приходится просчитывать огромное количество информации, и длительность MRP-цикла может измеряться часами даже на современном уровне развития вычислительной техники.

7.1.3 Уровни планирования

Существует несколько уровней планирования:

1. Стратегическое планирование (Strategic Planning). Из всех уровней этот - наименее интегрированный и наименее точный, поскольку планирование осуществляется для достаточно длительного периода. Исполнительным и финансовым директорам компаний необходимо прогнозировать спрос не только в рамках ближайшего года, но и последующих, для того, чтобы установить прогноз предполагаемого роста компании. Стратегические планы устанавливают границы (guidelines) для планирования производства и продаж на текущий год или даже более длительный период. Стратегический план устанавливает общие цели для организации, касающиеся в основном валовых продаж (gross sales) или общего дохода (overall income). Чтобы проверить реальность выполнения такого плана, Вы должны посмотреть на общие затраты (total outlays) и сравнить их с общим доходом (total income). Если Вы тратите больше, чем зарабатываете, то рентабельными Вы не будете.

2. Планирование производства (Production Planning). Эти планы составляются на уровне завода (factory) или площадки (site) работниками, ответственными за достижение целей, установленных руководителями компании. Им необходимо следить за всеми видами деятельности на площадке и осуществлять координацию. Когда эти планы разработаны, они являются руководством к действию для работников, ответственных за производство конкретных номенклатурных позиций, относящихся к определенным группам продуктов. Этот план создается для завода, площадки, подразделения (division) или отдела, где прогноз продаж, прогноз производства и предполагаемый доход является сферой деятельности различных работников. Для проверки реальности выполнения плана все эти прогнозы должны быть сбалансированы. Вы не сможете продать то, что не произведете.

3. Планирование конечного продукта (End Item Planning). Эти планы обычно составляются создающими главные календарные планы работниками (master schedulers), которые оценивают спрос на продукт и определяют, какое количество продукта необходимо произвести. Эти работники обладают информацией о ближайшем будущем и изменяют производственные планы для того, чтобы регулировать текущую ситуацию на производстве. Горизонт планирования производства конечного продукта обычно приближенно равен общей длительности цикла (cumulative lead time). Этот план рассматривает ряд приоритетных позиций (конечные продукты, номенклатурные позиции 1-го уровня, запасные части (service parts) и т.д.), которые будут произведены, а также календарный план их производства. Проверкой достижимости такого плана является наличие достаточного объема критических ресурсов. Если Вы хотите произвести 50 изделий за следующую неделю, а Ваше производство изготавливает только 25 единиц за неделю, Вы не выполните план.

4. Планирование компонент (Component Planning). Главный календарный план формирует спрос на компоненты; ППМ использует этот спрос для планирования заказов на компоненты. Плановики и работники цехов (Planners and shop floor people) используют результаты ППМ для определения календарного плана производства, который имеет такой же горизонт планирования, как и главный календарный план. Этот план позволяет Вам определить, какие рабочие центры (группы взаимозаменяемого оборудования) и компоненты будут использованы для реализации плана. Проверкой выполнимости плана является определение того, имеют ли рабочие центры необходимые мощности для выполнения календарного плана.

7.1.4 Многоуровневое планирование в рамках MFG/PRO

В концепции MRP/ERP, заложенной в рамках MFG/PRO, предусматривается сквозное планирование, согласование и оперативное корректирование планов и действий снабженческих, производственных и сбытовых звеньев предприятия. Планы снабжения, производства и сбыта могут согласовываться в долгосрочной перспективе (Strategic Planning) и среднесрочной перспективе (Tactical Planning).

На первом этапе осуществляется агрегированное планирование с использованием прогнозов спроса на готовую продукцию и данных о фактически поступивших заказах. Сформированный план в рамках системы MFG/PRO проверяют на возможность выполнения с точки зрения критичных ресурсов.

На втором этапе осуществляется формирование графика производства, дезагрегирование плана производства с указанием конкретных дат. Сформированный план в рамках системы MFG/PRO проверяют на возможность выполнения с точки зрения критичных ресурсов.

На третьем этапе с помощью МРП производится расчет потребности в материальных ресурсах и производственных мощностях под график производства. Информационное обеспечение МРП включает данные плана производства, файл материалов (формируемый на основе плана производства и включающий специфицированные наименования необходимых материалов с указанием их количества в расчете на ед. готовой продукции), файл запасов (данные по необходимым, для выполнения плана производства, материальным ресурсам - как по имеющимся на складе, так и заказанным, но еще не поставленным; по срокам выполнения заказов; страховыми запасами и др.). План МРП проверяется на выполнение с помощью модуля CRP, который анализирует загрузку рабочих центров. Ресурсами, используемыми для обработки заказов в производстве являются мощности рабочих центров. Производственный календарь определяет фактическое число рабочих дней в периоде. CRP моделирует расходование часов РЦ, используя заказы как производственный спрос. Технологические маршруты наряд-заказов обеспечивают информацию о том, какие заказы и когда используют РЦ. Планирования является сердцевиной MFG/PRO (см. рис.3, рис.4). Решение задач расчета потребности в материальных ресурсах решается совместно с задачами прогнозирования, контроля за состоянием запасов и др. (при этом осуществляются разработка прогноза потребности в сырье и продуктах, анализ возможных сроков выполнения заказов и уровней запасов страховых средств производства с учетом затрат на формирование и хранение запасов; качества обслуживания заказчиков; ретроспективный анализ хозяйственных ситуаций с целью оптимизации прогнозирования).

7.2 Планирование группы продуктов

ТНГ – товарно-номенклатурная группа. Каждое предприятие прогнозирует предполагаемые объемы поставок, заказы и производство на последующий год. Для этих целей используется модуль 20 «ПланГруппыПродуктов».

7.2.1 Ввод прогнозов

Прогнозируемые объемы поставок, закупок и производства вводятся на отдельных экранах системы, где отражаются как прогнозируемые значения на основании экспертных значений, так и фактические значения.

Вводимые планы:

1. Ведение плана отгрузки(20.5) отражают доход от продаж и себестоимость производства.

По прогнозам:

2. Ведение плана по заказам(20.9).

3. Ведения плана по производству(20.13).

4. Ведение плана складских запасов(20.17).

5. Ведение плана портфеля заказов (20.21).

6. Ведение плана группы продукта(20.1) показывает взаимосвязь между всеми планами и рассчитывает:

- Задолженность по отгрузке,

- Уровень складских запасов,

- Показывает процент валовой прибыли.

В функции 20.1 отражаются совместно: предполагаемые объемы поставок, заказы и производство на последующий год, где:

Отгрузка – доход от продаж.

Затраты – себестоимость производства.

Отгрузка – затраты = Валовая прибыль.

С помощью функции 20.1 ведется:

1. Работа с планируемым доходом.

Портфель заказов = прогнозируемый заказ – прогнозируемая отгрузка + предыдущее значение по портфелю заказа.

2. Работа с прогнозом затрат.

Складской запас = ПргнЗатр – Пргн + Предыд. Значение запаса.

Функции 20.1 содержит следующие поля:

З-д: код площадки;

Группа Прод.: код группы продуктов;

Год: год;

ПргнОтг: прогноз отгрузки ТНГ(товарно-номенклатурной группы) за месяц в отпускных ценах. Для обеспечения возможности сравнения прогноза отгрузки с фактом отгрузки по ТНГ необходимо в функции 20.5 ввести факт по отгрузки ТНГ за истекший месяц;

ПргЗак: прогноз сбытовых заказов по ТНГ в отпускных ценах. Значение данного поля включает планируемые долгосрочные и краткосрочные договора в отпускных ценах, причем долгосрочные договора отражаются на дату заключения (на месяц его заключения). Для обеспечения возможности сравнения прогноза заказов ТНГ с фактом необходимо в функции 20.9 ввести факт по заказам ТНГ за истекший месяц;

ПортЗак: портфель заказов вычисляется автоматически как разность прогноза заказов и прогноза отгрузки. Для обеспечения возможности сравнения планируемого портфеля заказов с фактом необходимо в функции 20.21 ввести факт по портфелю заказов за истекший месяц;

ПргнЗатр: прогноз отгрузки ТНГ в себестоимости;

Пргн Прзв: прогноз производства ТНГ в себестоимости. Для обеспечения возможности сравнения прогноза производства ТНГ с фактом необходимо в функции 20.13 ввести факт по производству ТНГ за истекший месяц;

ПргнСкл: прогноз складских запасов вычисляется автоматически как разность прогноза производства и прогноза затрат по ТНГ. Для обеспечения возможности сравнения планируемого складского запаса с фактом необходимо в функции 20.17 ввести факт по складскому запасу за истекший месяц;

ВП %: уровень рентабельности.

Уровень рентабельности = (валовая прибыль / прогноз отгрузки) * 100, где валовая прибыль равна разнице прогноза отгрузки и прогноза затрат по ТНГ;

Позволяет нам ввести прогнозируемые объемы поставок, заказов и производства, контролировать и регулировать их в их взаимосвязи.

7.2.2 Балансирование плана по группе продуктов

Балансировка общего плана осуществляется путем регулирования прогнозов отгрузки и затрат для получения наилучшей возможной величины валовой прибыли.

Балансировка прогнозов внутри доходов и затрат осуществляется путем:

- Регулирования заказов и отгрузки для балансировки дохода,

- Балансировка затрат и производства для балансировки запасов.

После установки для каждой группы продуктов плана, сумма планов отражает годовые и месячные финансовые планы предприятия.

7.3 Планирование ресурсов

Эта процедура устанавливает, что у заводов есть достаточно определенных ресурсов, чтобы произвести продукцию в запланированных объемах. Планирование ресурсов начинается с определением и ввода ключевых ресурсов – ресурсов, которые необходимы для производства, но могут ограничить его объем.

7.3.1 Ключевые ресурсы

Ключевые ресурсы - это ресурсы, необходимые для производства готовой продукции, которые могут ограничить объем производства (труд, производственные мощности, доступные денежные средства, определенные материалы).

Ресурс: код ресурса;

З-д: код завода, который содержит данный ресурс;

Описание: описание ресурса;

ЕИ: единица измерения ресурса;

Ссылка: код ссылки, определяющий актуальность действия ресурса на определенный период, который задается в полях «Нач.», «ДатаОконч.»; Первая ссылка должна быть базовая или нормальная. Остальные ссылки характеризуют отклонения объема/мощности ресурса; периода отклонения объема ресурса(уменьшения, увеличения ресурсов):

Нач. ДатаОконч.: временной период актуальности ресурса. Если действие ресурса является актуальным вне зависимости от временного периода, то значения полей «Нач.» и «ДатаОконч.» можно не заполнять;

Мощ/День: Мощность ресурса в день.

7.3.2 Преобразование плана производства в единицы ресурсов

Процедура используется для определения количества каждого ресурса, необходимого для выполнения производственного плана.

В функции 21.5 определяется связка ресурса с ТНГ для конкретного завода и задается коэффициент (значение поля «К-во На»), с помощью которого определяется загрузка ресурса для конкретной ТНГ.

ТНГ: код ТНГ(при вводе можно воспользоваться справкой, нажав клавишу F2);

Ресурс: код ресурса(при вводе можно воспользоваться справкой, нажав клавишу F2). Код ресурса определяется в функции 21.1;

З-д: код завода (при вводе можно воспользоваться справкой, нажав клавишу F2);

ДатаНачала: дата начала действия коэффициента(значение поле «К-во На»);

ДатаОконч.: дата окончания действия коэффициента(значение поле «К-во На»);

К-во На: коэффициент, с помощью которого определяется загрузка ресурса для конкретной ТНГ. Значение поля «К-во На» вводится вручную. Приведем пример расчета данного значения. Для простоты расчета предположим, что ТНГ включает только одну НП. На одну НП затрачивается 40,45 н/ч трудоресурса. Себестоимость НП равна 2000 рублей за штуку. Тогда на 1 тысячу рублей приходится 20,225 н/ч (2000 * x = 40,45 * 1000, x = 40,45*1000/2000);

Дл. Цикла(Мес.): количество месяцев, в течении которых будет использоваться ресурс.

Это число действует как коэффициент распределения, при делении на которое общего объема ресурса получается объем ресурса, необходимый на период; Если определяется данное поле, то загрузки ресурса будет рассчитываться как: ПргнПрвз (20.1) * К-во На (21.5) / Дл. Цикла (21.5) , причем данное значение распрастраняется на весь период длительности цикла. Приведем пример: ПргнПрзв: октябрь =1000, ноябрь=2000, декабрь=3000, Ко-воНа=1, ДлЦикла=2. При запуске отчета 21.9 с датой начала от 1 ноября, получаем:

При запуске отчета 21.9 с датой начала от 1 октября, получаем:

Сдвиг: количество месяцев до начала периода производства, в течении которого потребуется ресурс. Это число будет отрицательным, если ресурс потребуется после окончания процесса производства. На основании положительного значения поля «Сдвиг» загрузка ресурса сдвигается на определенный период (значение поля «Сдвиг») вперед (на более раннее дату) - до начала процесса производства. На основании отрицательного значения поля «Сдвиг» загрузка ресурса сдвигается на определенный период (значение поля «Сдвиг») назад - после процесса производства.

7.3.3 Загрузка ресурсов по группе продуктов

В отчете функции 21.9 (21.10) приводится суммарная загрузка(поле «Загрузка») ресурса по всем закрепленным за ним ТНГ.

Система рассчитывает загрузку, используя прогноз производства по плану по определенной группе продуктов и площадке и значения коэффициентов перевода.

Отчет функции 21.9 содержит следующие поля:

Рабочие Дни: количество рабочих дней в периоде. Определяется на основании рабочего календаря (функция 36.2.5);

Мощности: мощность ресурса за определенный период. Мощность определяется как произведение мощности в день (Мощ/День 21.1) и значения поля «Рабочие Дни»;

Загрузка: суммарная загрузка ресурса по всем закрепленным за ним ТНГ:

Суммарная Загрузка ресурса (21.9)=

= Загрузка для ТНГ1 + Загрузка по ТНГ2 + ... + Загрузка ТНГn,

Где

Загрузка для ТНГ1 = Значение поля «ПргнПрвз» (20.1)* К-воНа(21.5) / ДлЦикла (21.5) Свыше/Меньше: разница мощности и загрузки;

Накопленный: предыдущее значение поля «Накопленный» + тек. Значение поля «Свыше/Меньше»;

В отчете функции 21.11 (21.12) можно просмотреть загрузку ресурса по конкретным ТНГ(значение поля «Вед 100 2000», где 100 – ТНГ, 2000 – 2000 год.

7.4 Планирование номенклатурных позиций

Данные о планировании НП содержат информацию о том:

- Когда заказывать,

- Сколько закупать или изготовлять.

1.4.1. Ведение данных о планировании номенклатурных позиций

№ Позиции: код планируемой номенклатурной позиции(НП);

Описание: описание НП;

ЕИ: единица измерения НП;

Главн.График: признак построения плана-графика для НП(НП, для которых строятся план-график подлежат контролю людьми, обычно план-график составляется для НП независимого спроса - конечных продуктов и запчастей для ремонта);

Зкпщ/Плановик: код лица, осуществляющего закупку/планирование НП;

Полит.Выпус.: признак использования политики выпуска; если данное поле определено в «Нет»: то в ведомости комплектации/ВК(функция 16.6) данная НП будет печататься под заголовком "Производ. запасы" и величина данной НП в ВК не будет оказывать влияние на зарезервированное количество СЗ(исходя из отчетов 3.6.5, 3.17, 3.18). По данной НП можно осуществить отпуск материалов в производство и это изменит величину текущего складского запаса; если данное поле определено в «Да»:

процесс формирования ведомости комплектации отразится на величине зарезервированного СЗ.

План.Заказы: признак автоматического планирования заказов(обычно заказы планируют для НП зависимого спроса – компонент конечного продукта, сырья); если «ПолитикаЗак» установлена в нет, то независимо от значения поля «ПланЗак» планирование по данной позиции осуществляться не будет, если «ПланЗак» - «Нет», а «ПолитикаЗак» - не пробел, то заказы не будут спланированы, но будут созданы рекомендации, отражающие необходимость данной НП;

Поставщ.:код поставщика НП(единственного или привилегированного). Данное поле используется для формирования отчетов в модулях «Закупки», «ПланПотрМат»(23.14, 23.17, 23.20), «ПланРаспределения»;

Фантом: признак «нематериальной» НП, не участвующей в планировании (не будут планироваться заказы, но планируются рекомендации по необходимому количеству данной НП);

Вр.Запрета: количество дней(от системной даты), на которое не будут планироваться заказы для конкретной НП;

З-д ЗЗ: код площадки, где будет осуществляться закупка НП(значение поля обязательно при использовании DRP для НП);

Мин.Зак.: минимально возможное количество в спланированном заказе по НП (если MRP рассчитает меньшее количество, спланированный заказ будет на значение поля «МинЗак»);

Требует ППМ: признак использования MRP (поле обновляется автоматически);

Зкп/Прз:

  • «Р» - закупаемые компоненты (необходимо определить длительность циклов закупки и приемки для определения сроков запуска плановых заказов);
  • «М» - производимые НП (необходимо длительность производственного цикла для определения дат запуска плановых заказов);
  • «R» - НП, используемые в технологическом маршруте(признак планирования заказов должен быть «Нет»);
  • «C» – конфигурируемые на заказ (при вводе квоты или заказа на продажу система напоминает о выборе конфигурации);
  • «F» - не изготовляемые и не хранимые НП;
  • «D» - поставляемые с других площадок (необходимо определить сеть поставок – код площадки с которой поставляется НП);

МаксЗак: максимальное количество, возможное в спланированном заказе по НП (если MRP рассчитает большее количество, спланированный заказ будет на значение поля «МаксЗак»);

ПолитикаЗак.: « » - НП не планируются;

«POQ» - на основании определенного спроса создается один заказ на определенный период - (необходимо определить также длительность периода: поле «Период Заказа»). Например, есть независимый спрос для данной НП (НП, для которой определяется политика заказа): в 1-ю неделю 50 и во 2-ю неделю – 50. Для обеспечения 1- го независимого спроса необходимо 50 данной НП, для обеспечения 2-го независимого спроса – 50 данной НП; В случае, если мы укажем период, равный 14 (дней) будет спланирован только один заказ на 100 данной НП. В случае, если период заказа определен в значение «7» политика «POQ» будет идентична политике «LFL»;

«FOQ» - всегда создается фиксированный объем заказа (также необходимо установить/определить фиксированный объем заказа – поле «КвоЗаказа»). Например, есть независимый спрос для данной НП (НП, для которой определяется политика заказа): в 1-ю неделю 50, во 2-ю неделю – 50 и в 3-ю недел. - 50. Для обеспечения 1-го независимого спроса необходимо 50 данной НП, для обеспечения 2-го независимого спроса – 50 НП и для обеспечения 3-го независимого спроса – 50 НП. Определен фиксированный размер заказа, равный 100. MRP спланирует для данной НП два заказа по 100 (один заказ на 100 покроет 1-й и 2-й независимый спрос, второй заказ на 100 покроет(с избытком) 3-й независимый спрос);

«LFL» - создается один заказ для каждого источника верхнего уровня(на каждую партию) Например, есть независимый спрос для данной НП (НП, для которой определяется политика заказа): в 1-ю неделю 50, во 2-ю неделю – 50 и в 3-ю неделю - 50. Для обеспечения 1-го, 2-го, 3-го независимого спроса MRP спланирует три заказа по 50 данной НП;

«ОТО» - создается единственный заказ определенного объема(поле «КвоЗаказа») независимо от графика спроса или объема заказа. Например, есть независимый спрос для данной НП (НП, для которой определяется политика заказа): в 1-ю неделю 50, во 2-ю неделю – 50. Поле «КвоЗаказа» определено как 50. MRP спланирует единственный заказ на 50 данной НП;

Конфигурация: код конфигурации (для конфигурируемых НП на заказ). Данное поле указывается при использовании модуля «КонфигурирИзделия»;

КратнЗак: кратность, которую используют при генерировании заказа;

КвоЗаказа: количество заказа для НП(используется при фиксированном объеме заказа – политика);

Прз ДЦ: длительность производственного цикла – число рабочих дней, требуемых в среднем для изготовления обычного размера заказа(подготовка документов + отпуск компонент + производство + прием кон. Продуктов + отправка на склад). Длительность производственного цикла может быть введен вручную(тогда поле «Суммир.Дл-тьЦикла» установит в Нет), может быть рассчитан автоматически(14.13.13). Длительность производственного цикла НП равен сумме длительности производственных циклов всех операций техкарты НП. Длительность производственного цикла операции = (Время очереди + Время настройки + Время перемещения(14.13.1))/К-во часов РЦ(36.2.5) + Время Обработки(14.13.1) * КвоЗаказа(1.4.7)/Часы(36.2.5)*М/ОП(14.13.1) + Время ожидания(14.13.1)/24 + ДЦСубконтракта(14.13.1);

%Выхода: процент выхода годных изделий/НП (ожидаемый годным к использованию).

Пример: Дана структура изделия «А» – рис.10.

Для изделия «А» имеется структура, схематично изображенная на рис. 10, где в скобочках указаны количества компонент на 1 единицу изделия «А». % Выхода равен 98%.

Определим чистую потребность для изготовления изделия «А». Независимы спрос на изделие «А» равен 100 единицам.

(100/98)*100 = 103. MRP спланирует 103 единицы изделия «А». Соответственно для изделия «В» спланируется 206 единиц, а для изделия «С» – 103 единицы.

К-воГруппы: количество НП, используемое при подсчете затрат на материалы для родительской НП. Значение поля изменяется автоматически при выполнении функции 15.9 или при вводе поля «ОбъемГруппы» функции 15.1;

ДЦ Зак.: число рабочих дней с момента отправки заказа на закупку поставщику до получения НП (определяется для закупаемых НП и используется при подсчете срока выполнения заказа по данной НП);

Время Обр.: время выполнения обработки по техкарте НП (рассчитывается автоматически при запуске функции 14.13.13);

Период Заказа: временной период через который будут планироваться заказы (используется для политики заказа POQ);

Проверка: признак наличии проверки закупаемых изделий;

ВремяНастр.: время на подготовку рабочего центра и машин для выполнения операций по техкарте НП (рассчитывается автоматически при запуске функции 14.13.13);

Страх.Зап.: количество запасов, которое должно быть в любое время и защищающий от колебания спроса и предложения(MRP генерирует заказы на НП, если текущий уровень запасов ниже страхового запаса);

ДЦ Прв: число рабочих дней, необходимых для приемки НП после ее получения (НП не может быть запущена в производство пока не закончена приемка). Значение данного поля используется для расчета срока выполнения заказа по НП;

Тип АСЗ, Автом Обработ.АСЗ: информационные поля;

А

С (1) В (2)

Страх.Время: число рабочих дней, добавляемых к обычной длительности цикла для защиты от запаздывания заказов;

СуммДЦ: наибольшее общее время с учетом праздничных дней и количества дней, необходимых для обеспечения компонентами. Значение данного поля рассчитывается и проставляется автоматически при запуске функции 13.12.14;

Точка Заказа: Значение данного поля вводится для не планируемой НП с целью контроля (с помощью функции 3.6.2) за уровнем СЗ и как следствие за вводом заказа для поддержания данного уровня не ниже точки заказа;

Код Сети: код сети распределения (определяется с помощью функции 12.1), характеризующий взаимосвязь площадки-получателя и площадки-поставщика. Значение данного поля обязательно при наличии DRP, оно вводится вручную или выбирается с помощью клавиши F2.

Прв: код ревизии(технической, прикладной) по данной НП. Перечень возможных значений данного кода вводится в обобщенных кодах.

Код ТехКарты: код технологического маршрута, с помощью которого определяется срок выполнения планируемого заказа по НП;

Спцф/Формула: код структуры продукта(НП) или код формулы НП(альтернативной), в соответствии с которой определяются количества в заказах на компоненты(составляющие данную НП).

7.5 Прогнозирование и разработка календарного плана

Главный календарный план(ГКП) позволяет:

  • Ввести прогнозируемое количество НП и показать потребление прогноза, т.е. уменьшение спроектированного прогноза (22.1) на величину подтвержденных заказов (7.1.1.);
  • MRP спланировать наряд-заказы (1.4.7, 22.15) на основании определенной в рамках ГКП потребности в НП независимого спроса;
  • Ввести вручную наряд-заказы(22.13);
  • Ввести сезонное наращивание(22.9).

Разработка главного календарного плана (ГКП/MPS) используется для преобразования утвержденного плана по группе продуктов в план для исполнения.

ГКП, разработанные для площадок, номенклатурных позиций (НП) – входные данные для планирования потребностей в материалах (ППМ).

ГКП/MPS взаимодействуют с планированием ресурсов. Заказы, введенные на уровне ГКП, могут быть проверены на предмет соответствия определенным пользователем ресурсам (как и для группы продуктов).

7.5.1 Ведение прогноза

Прогноз и заказы на продажу формируют источник независимого спроса. С помощью прогноза производится сглаживание производства.

Прогноз – общепринятая стартовая точка для разработки плана для исполнения.

Прогноз является оценкой будущего спроса на НП.

Прогноз отгрузки по НП вводится в систему с помощью двух функций

22.1 «Ведение прогноза» - 52 недельных периодов времени(«временных корзин»),

22.2 «Ведение рабочего листа прогноза» - 13 «временных корзин».

№ Позиции: код НП;

З-д: код завода;

Год: год;

Прогноз: прогноз производства НП(в штуках);

Пр-жа: количество НП в одобренных ЗП, в которых поле «Пргн.Потребл» определено в Да;

Внеплан.: количество НП в одобренных ЗП, в которых поле «Пргн.Потребл» определено в Нет;

ПргнПр-ва: прогноз производства, вытекающий из прогноза родительской позиции – для НП, являющихся как источниками зависимого так и источниками независимого спроса.

ЧистПргн: разница между значениями «Прогноз» и «Пр-жа». Если продажа больше величины прогноза, то величина чистого прогноза равна нулю;

На вычисление чистого прогноза влияют периоды потребления, устанавливаемые в функции 7.1.14 (поля «ИзСледПериод.», «ИзПредПериода»). Сначала потребление (уменьшение прогноза на величину поля «Пр-жа») осуществляется назад на один период, потом вперед на один период от исходного периода прогнозирования.

7.5.2 Потребление прогноза

Потребление прогноза – это регулярный процесс уменьшения спроектированного прогноза на величину подтвержденных заказов.

Техника потребления прогноза может быть задействована для обеспечения более точного состояния спроса, т.к. прогноз и заказы на продажу являются составляющими общей величины спроса.

№ Позиции: код НП;

З-д: код площадки, с которой происходит отгрузка НП;

Год: год;

Нед.: дата, соответствующая началу недели.

Прогноз: количество НП, которое ожидается к отгрузке;

Значение данного поля могут вводится, а могут быть рассчитаны при использовании модуля «Моделирования прогноза» -22.7.1 и 22.7.5;

Пр-жа: количество НП по подтвержденным заказам на продажу (не вводится; это информационное поле, которое отражает уже спланированные и подтвержденные заказы;

Внеплан.: кол-во НП по заказам на продажу, которые не используются для прогноза;

ПргнПр-ва: количество НП, которое надо произвести с учетом вхождения в другие НП;

ЧистПргн: разница между прогнозом и продажей;

Потребление прогноза устанавливается в контрольном файле заказов на продажу – функция 7.24., где устанавливают количество недель вперед/назад, за которые происходит потребление.

Количество неделей для сглаживания:

ИзСледПериод.: количество неделей(сглаживание – с помощью предыдущего периода);

ИзПредПериода: количество неделей(сглаживание – с помощью последующего периода).

Фактическое решение о потребление прогноза принимается в системе на уровне заказа на продажу – функция 7.1.1 поле «Потреблять прогноз».

Если значение поля «Потреблять прогноз» - Да, то система использует для ППМ(MRP) результат (значение поля «ЧистПргн» функции 22.2), полученный путем вычитания из прогнозируемого количества НП, которое ожидается к отгрузке объема подтвержденного заказа на продажу.

Если значение поля «Потреблять прогноз» - Нет(внеплановый спрос), то потребление прогноза не происходит и входными данными для ППМ(MRP) будет объем подтвержденных заказов на продажу(значение поля «Отгруж. "К-во" функции 7.1.1). ППМ(MRP)всегда планирует достаточное количество для покрытия подтвержденных заказов на продажу плюс чистый оставшийся прогноз на протяжении недельного периода:

Внеплан.(22.2) + ЧистПргн (по пред.недели – фун.22.2).

Внеплановый спрос - когда не желаем потреблять прогноз, вследствие каких-то ситуаций. Для внепланового спроса необходимо с помощью функции 7.1.1 поле «Потреблять прогноз» -Нет.

7.5.3 Сезонные колебания

Для многих производств существуют сезонные колебания спроса на продукцию, которые порождают потребность нарастить запасы до определенного уровня.

Сезонность определяется как необходимость нарастить запасы НП накануне ожидаемого спроса на них а значит, это требует их ввод в ГКП.

Сезонные запасы вводятся с помощью функции 22.9 «Ведение сезонных колебаний».

З-д: код площадки;

№ Позиции: код НП;

Дата: дата, к которой необходимо нарастить запасы;

На данную дату потребность в сезонных изменениях уже не присутствует, что разрешает отгрузку.

Ссылка:

Сезонные Запасы: темп наращивания (количество запасов, наращиваемых на каждый последующий месяц);

ЕИ: единица измерения наращиваемого количества (сезонных запасов);

7.5.4 Главный календарный план

ГКП – это ключевой план, который управляет производством на предприятии.

ГКП требует определения:

- какие НП будут в него включены,

- когда необходимы заказы,

- сколько производить.

При разработке ГПК необходимо определить - какие НП включать в ГКП, а какие НП планировать при помощи ППМ(MRP).

Разработка ГКП необходима для предвиденья продаж, вводимых в систему или для контроля производства, если заказы на продажу не используются.

7.5.4.1 Номенклатурные позиции и ведение главного календарного плана

Номенклатурная позиция ГПК – это НП, работа с которой требует контроля человека для оценки календарного плана и его возможного значения для мощностей, материалов и т.п., т.е. те НП, с помощью которых можно контролировать другие НП.

НП ГКП обычно являются конечными продуктами, важными сборочными единицами или ключевыми ресурсами.

Когда НП объявлена как включаемая в ГКП, она попадает под контроль начальника планового отдела.

Для определения НП как включаемой в ГКП необходимо: в 1.4.7 «Ведении планировании НП»(или 1.4.17 – для предприятия со многими площадками) полю «Главный календарный план» присвоить значение «Да».

НП может являться позицией ГКП на одной площадки, и не являться таковой на другой.

Вр.Запрета: граница во времени, которая характеризует время, в которое не будут создаваться заказы (от системной даты).

Горизонт планирования ППМ – временной показатель осуществления планирования.

Горизонт планирования устанавливается с помощью функции 23.24. Горизонт планирования должен быть > длительности цикла + 1 день.

Формирование главного календарного плана

Для формирования ГКП предварительно необходимо определить:

- Прогнозы,

Заказы на продажу,

- Независимый спрос;

- Сезонность.

После этого начальник планового отдела может создать главный план требуемых заказов на поставку для покрытия спроса, который формирует ГКП для НП.

7.5.4.2 Операции ГКП

В системе есть три подхода к разработке ГКП:

1. Автоматически: вводится спрос (прогнозы, заказы и т.д) и запускается ППМ(MRP). Для НП, на которые есть спрос, будут созданы плановые заказы.

2. С помощью компьютера: ППМ планирует заказы для покрытия будущих потребностей и сформирует рекомендации на ближайшее время.

3. Полностью вручную: вводятся все заказы ГКП:

-22.13 «Ведение заказов ГКП» или 16.1 «Ведение наряд-заказов»;

-18.22.2.1 «Ведение графиков поточного производства» или 5.1.4 «Ведение заявок на закупку»;

Данные заказы образуют утвержденный заказ на поставку, который действительно создает ГКП и становится основными входными данными.

Определение использования того или иного подхода возможно с помощью функции 1.4.7 с помощью значений поля «Планировать заказы»: «Да» - с помощью компьютера, «Нет» - полностью вручную.

7.5.4.3 Сводный запрос по ГКП

Сводный отчет по ГКП(функция 22.18) содержит следующие поля:

ПрогнозПроизв.: расчетное значение прогноза на основании планового списка материалов(BOM). Значение данного поля используется при многоуровневой разработки ГКП;

ПрогнозПр-ва = ПрогнозРодИзд(22.1)* К-воНа(13.5)* Прогноз%(13.5)

Прогноз – чистый прогноз из функции 22.2;

ЗП: количество НП из подтвержденных заказов на продажу; независимый спрос(из заказов на продажу);

Суммар.Заявки = К-воНЗРодИзд(16.1) * К-воНа(13.5) * Прогноз% (13.5) + Заказы с других площадок(для DRP);

Суммар.Заявки: валовая потребность, т.е. производственная потребность, возникающая из наряда-заказа на родительское изделие, которое может быть включено в ГКП, так и являться компонентом многоуровневого списка. Суммарные заявки являются общей потребностью с учетом %Выхода.

Главный График: общие запланированные поступления из заказов MRP(являются плановыми, утвержденными и т.п.);

Главный График = ПрогнозПроиз + Прогноз - Запланир. Сз за предыдущей период;

Запланир. СЗ: расчетное значение:

Заплан.СЗ = ЗаплСЗнач. + ГлавГраф – Общ.Потребности,

где Общ.потреб = Произв.прогноз + Прогноз + ЗП + Сум.Заявки

Можно Обещать: расчетное значение:

Можно Обещать = Запланир. СЗ за предыдущей период(составляющая используется только для начала расчета – первой величины на экране итогов) + Главный График – ЗП – Суммар.Заявки – Увеличение Сезон. Колеб. ИЛИ + Снижение Сезон. Колеб.,

Где:

Увеличение Сезон. Колеб. = Сезон. Колеб. – Сезон.Колеб. Предыд. (если полученное значение > 0);

Снижение Сезон. Колеб. = Сезон. Колеб. – Сезон. Колеб. Предыд (если полученное значение < 0);

«Увеличение Сезон. Колеб.» отнимается, а «Снижение Сезон.Колеб» прибавляется в формуле для значения «Можно Обещать».

Сезон. Колеб.: значение из ведение сезонных колебаний, с нарастающим итогом, введенное в функции 22.9.;

7.5.4.4 Детальный запрос по ГКР(22.21)

7.5.5 Разработка многоуровневого Главного календарного плана

Многоуровневый ГКП – это связанные ГКП для нескольких НП.

Лекция 8. Реализация концепции трехуровневого планирования деятельности предприятия в MFG/PRO (продолжение)

8.1 Укрупненное планирование(RCCP)

RCCP составлен на основе данных о ресурсах номенклатурной позиции(НП). RCCP проверяет выполнение ГКП с точки зрения достаточности ресурсов.

8.1.1 Единицы ресурсов и длительность цикла

Планирование НП в ГКП выражено в единицах измерения отличных от единицы измерения ресурса. Поэтому необходимо привести единицу измерения из ГКП в единицу измерения ресурса.

Функция 21.17 устанавливает коэффициент пересчета (К-во ресурсов на) единицы измерения, с помощью которого, например штуки НП в ГКП преобразуются в трудочасы.

№ Позиции: код НП (можно воспользоваться справочником, нажав клавишу F2);

З-д: код завода (можно воспользоваться справочником, нажав клавишу F2);

Ресурс: код ресурса (можно воспользоваться справочником, нажав клавишу F2;)

ДатаНачала: дата начала действия коэффициента(значение поле «К-во Ресурсов На»);

ДатаОконч.: дата окончания действия коэффициента(значение поле «К-во Ресурсов На»);

К-во Ресурсов На: значение поля «К-во Ресурсов На» определяет сколько ресурса приходится на одну НП;

ДлитЦикла(Дни): количество дней, в течении которых будет использоваться ресурс. Это число действует как коэффициент распределения, при делении на которое общего объема ресурса получается объем ресурса, необходимый на период; Если определяется данное поле, то загрузки ресурса будет рассчитываться как: К-во НП (16.1) * К-во Ресурса На (21.17) / ДлитЦикла (21.17). Определите данное поле в значении не меньше 1.

Сдвиг (Дни): количество дней до запуска наряд-заказа(Н-З), в течении которого потребуется ресурс. Это число будет отрицательным, если ресурс потребуется после окончания процесса производства. На основании положительного значения поля «Сдвиг (Дни)» загрузка ресурса сдвигается на определенный период (значение поля «Сдвиг (Дни)») вперед (на более раннее дату) - до запуска Н-З. На основании отрицательного значения поля «Сдвиг» загрузка ресурса сдвигается на определенный период (значение поля «Сдвиг») назад - после запуска Н-З. При значении поля «Сдвиг (Дни)» равным нулю, загрузка ресурса будет отнесена на дату прогноза.

8.1.2 Производственная загрузка по конечной продукции

Производственную загрузку по конечной продукции можно проанализировать с помощью отчетов по ресурсам 21.21 – 21.24, где ресурсы рассматриваются укрупнено (например: трудозатраты, денежные средства и т.п).

Подробная детализация ресурсов будет рассмотрена в ССМ.

В отчете функции 21.21(21.22) приводится суммарная загрузка(поле «Загрузка») ресурса по всем закрепленным за ним НП.

Отчет функции 21.21 содержит следующие поля:

Рабочие Дни: количество рабочих дней в периоде. Определяется на основании рабочего календаря(функция 36.2.5);

Мощности: мощность ресурса за определенный период. Мощность определяется как произведение мощности в день (Мощ/День 21.1) и значения поля «Рабочие Дни»;

Загрузка: суммарная загрузка ресурса по всем закрепленным за ним НП:

Суммарная Загрузка ресурса (21.21)=

= Загрузка по Н-З1 для НП1 + Загрузка Н-З2 поНП2 + ... +Загрузка по Н-З1 для НП2 +

Загрузка Н-З2 по НП2 + … + Загрузка Н-Зn для НПn,

где

Загрузка Н-З1 для НП1 = К-во НП(16.1)* Ко-воРесурсаНа(21.17) / ДлитЦикла(21.17)

Свыше/Меньше: разница мощности и загрузки;

Накопленный: предыдущее значение поля «Накопленный» + тек. Значение поля «Свыше/Меньше»;

В отчете функции 21.24 можно просмотреть загрузку ресурса по конкретному Н-З для НП(«Номер Позиц», значение поля «НЗ:»).

8.2 Планирование потребности в материалах(MRP)

MRP – это компьютеризированный процесс планирования.

Запуск расчета MRP осуществляется с помощью функций 23.1 или 23.2 или 23.3. В результате запуска MRP, как показано на рис.3, появляются спланированные наряд-заказы и заявки на закупку (отчет 23.12 «Отчет о Запланированных Заказах»).

С помощью запуска MRP осуществляется:

  1. Определение общей потребности материалов для изготовления родительского изделия(просмотр - отчеты функций 23.14, 23.13);
  2. Определение чистой потребности(ЧП) материалов для изготовления родительского изделия(просмотр - отчеты функций 23.13, 23.14);
  3. Определение величины планового заказа (наряд-заказа или заявку на закупку) в зависимости от политики заказов( просмотр - отчеты функций 23.13, 23.14), устанавливаемой в функции 1.4.7.
  4. Определение срока выполнения заказа(просмотр - отчет функции 23.13, 23.14),
  5. Автоматическое создание заказов на закупку/ наряд-заказов (1.4.1 “Зак/Прзв”, “Планировать заказы”). Просмотр созданных заказов – функция 23.16,
  6. Создание рекомендаций(просмотр - отчет функции 23.6).

Календарный график плановых заказов на поставку позволяет:

? Иметь нужные запасы в нужное время;

? Минимизировать объем запасов, обеспечивая потребителям нужный уровень сервиса клиента;

MRP

? Максимизировать эффективность производства.

8.2.1 Режимы планирования

Планирование потребности материалов осуществляется по площадке, где создается план по материалам полностью независимо от других существующих площадок.

Меню MRP раскрывает следующие режимы, которые описаны ниже.

8.2.1.1 По изменениям (основной режим работы)

Это перепланирование номенклатурных позиций (НП), по которым были внесены какие-либо изменения с тех пор, как последний раз запускалась MRP.

Перепланирование происходит на основе операций с запасами, изменениях в структуре продукта и других данных, не используя спрос или прогноз для НП.

Изменения касаются:

- Данных о планировании НП,

- Размера партии НП;

- Модификаторов заказов;

- Даты и т.д.

8.2.1.2 Полный пересчет

Перепланирование всех номенклатурных позиций (НП), имеющихся в базе данных на определенной площадке. Перепланирование происходит на основе спроса или прогноза.

8.2.1.3 Выборочный

Перепланирование отдельных НП и/или площадки. Это могут быть НП ГКП, НП MRP, НП DRP и т.д.

Выборочный план планирует только выбранные НП, передавая общую потребность вниз невыбранному уровню и не перепланируя заказы.

a) Спрос на конечный продукт

Если поля функции 23.3 имеют такие значения, как:

Поз. Главн. Граф.: “Да”

Позиции Не Из Гл.Графика: “Нет”,

то системой обсчитываются потребности только в конечных продуктах с передачей общих потребностей только компонентам следующего уровня.

b) Спрос на компоненты

Если поля функции 23.3 имеют такие значения, как:

Поз. Главн. Граф.: “Нет”

Позиции Не Из Гл.Графика: “Да”,

то системой обсчитываются потребности в компонентах.

c) Спрос на конечный продукт до компонент

Если поля функции 23.3 имеют такие значения, как:

Поз. Главн. Граф.: “Да”

Позиции Не Из Гл.Графика: “Да”,

то системой обсчитываются потребности в конечном продукте с разверткой до компонент.

d) Создание плановых запросов с другой площадки для НП DRP (не учитывает запросы с других площадок, но запросы нашей площадки к другим учитывает – связь с DRP(ППР))

Если поля функции 23.3 имеют такие значения, как:

Позиц.ППМ(MRP): “Да”

Позиц.ППР(DRP): “Нет”,

то системой создаст плановые заказы для НП определенной площадки и общие потребности для любых НП DRP.

e) Создание плановых заказов НП площадки с запросами с другой площадки для НП DRP

Если поля функции 23.3 имеют такие значения, как:

Позиц.ППМ(MRP): “Да”

Позиц.ППР(DRP): “Да”,

то системой создаст плановые заказы для НП определенной площадки и запросов с другой площадки для НП DRP.

8.2.2 Как работает MRP

Входные данные. MRP использует построенный ГКП для расчета зависимого спроса на компоненты (рис.7). Зависимый спрос – это спрос, который напрямую извлекается из спроса на другие НП. Независимый спрос не может быть рассчитан или извлечен из спроса на другие продукты. Он формируется прогнозом и заказами на продажу или является результатом ручного ввода. ГКП передает MRP зависимый и независимый спрос. Независимый спрос передается MRP(ППМ) через ГКП. НП может быть объектом и зависимого и независимого спроса(когда сервисные НП также используются и в производственном процессе).

Данные о НП:

- Политика заказа,

- Размер заказа.

Данные о структуре продукта:

- Компоненты продукта,

- Нормы расхода,

- Процент брака.

Горизонт MRP – период времени в календарных днях, на который планирует MRP.

Горизонт времени устанавливается в контрольном файле при вызове функции 23.24.

Горизонт MRP должен быть не короче, чем величина длительности цикла + 1 день.

Результат работы MRP

  • Плановые заказы, предлагающие необходимый календарный план(график) поставок.
  • Рекомендации плановику, предлагающие ускорение, задержку или отмену существующих заказов или создание новых заказов.
  • Балансировка предложения и спроса (сбалансирование поставок и спроса в зависимости от количества),
  • MRP определяет - сбалансированы ли предложение и спрос, используя для каждого периода следующее уравнение:

ЧисТребК-во = ОбщаяПотр – СкладОстат-к – К-воОткЗак Цель MRP:

- Выявить дисбаланс в плане по материалам, то есть выявить дефицит материалов.

- Сформировать рекомендации по восстановлению баланса.

Таким образом, заказы ГКП и зависимый спрос нижних уровней должны быть сбалансированы с существующими заказами на поставку для каждого периода времени.

1. Расчет сроков выполнения заказов (на основе ГКП), т.е. надо убедиться, что для удовлетворения спроса поставка доступна. Для этого используется техника обратного планирования, где:

Входными данными являются:

- Дата выполнения или требуемая дата,

- Длительности циклов.

Результат: дата запуска или начала.

Этот расчет выполняется для всех плановых заказов, позволяя MRP назначить даты запуска, необходимые для выполнения заказов согласно плановым датам - в случае не использования длительности цикла.

Длительность цикла изменяет требуемую дату получения компонента относительно даты родительского изделия.

Поддержка

Поддержка определяет порядок планирования, т.е. с какого уровня структуры продукта будет «начало планирования». Если НП определена на разных уровнях, то она планируется на «меньшем уровне».

Поддержка – термин, используемый для определения источника, формирующего потребность.

Поддержка позволяет просмотреть каждый источник спроса в общей потребности.

Поддержка возможна при наличии кодов нижних уровней.

MRP может изменить коды нижних уровней, поэтому перед запуском MRP их необходимо обновить(23.22 «Обновить коды нижних уровней» поле «Переопред-ть кодыНижУровней» = «Да»).

8.2.3 Данные о планировании номенклатурных позиций(1.4.17)

Устанавливают как MRP планирует НП. Одни и те же НП могут планироваться на разных площадках – функция 1.4.7, где определяется:

НП независимого спроса определяются при помощи следующих значений полей:

ГКП - Да,

Планировать заказы - Да,

Граница во времени - Политика руководства,

Политика заказов - Любая.

НП зависимого спроса определяются при помощи следующих значений полей:

ГКП - Нет,

Планировать заказы - Да,

Граница во времени - По выбору,

Политика заказов - Любая.

Планирование НП по точке заказа

ГКП - Нет,

Планировать заказы - Нет,

Граница во времени - 0,

Политика заказов – Любая(не нулевая).

8.2.4 Установка размера партии

Выполняется на 2-х уровнях.

Сначала путем выбора политики заказа,

Далее путем min, max, кратности заказа().

8.2.5 Запрос итогов MRP

Показывает плановую информацию по НП/площадке и календарный план по дням, неделям.

8.2.6 Одобрение плановых заказов Одобрение плановых заказов осуществляется с помощью функции 23.11 «Подтверждение заказа на закупку».

8.3 Планирование потребностей по распределению (ППР/DRP)

ППР - это автоматическая система планирования заказа на компонент, или зависимого спроса, который использует вычисление чистой потребности и создает плановые заказы.

ППР аналогичен MRP, но стой лишь разницей, что ППР осуществляет планирование для номенклатурных позиций (далее просто НП) типа D – НП на пересечении площадок (рис.8).

Контрольный файл ППР определяет возможность совместного использование DRP и MRP(функция 12.13.24)

8.3.1 Сети поставок

Сети поставок определяют взаимодействие между площадками. Для определение сети поставок необходимо:

1. определить код сети поставок (функция 12.1.1);

2. определить площадки, входящие в сеть поставок(функция 12.1.13);

3. определить режим транспортировки (функция 12.5.1).

Режим транспортировки и транспортные сети управляют длительностью цикла между площадками и календарями отгрузки и получения.

8.3.2 Подробности жизненного цикла ППР

Жизненный цикл (ЖЦ) ППР – это прохождение заказа от требующей площадки к поставляющий и наоборот. Ниже приведена последовательность функций по работе в рамках модуля ППР.

Сначала запускается расчет плана ППР.

С помощью функции 12.15.17. осуществляется просмотр товаров, находящихся в пути, т.е. товаров по не незакрыты заказам распределения.

С помощью функции 12.15.20. осуществляется диспетчирование выполнения заказов распределения.

8.4 Планирование потребности в мощностях(CRP)

CRP рассчитывает загрузку для определенного отдела или на указанном рабочем месте или машине. Этот расчет производится путем разворачивания технологических маршрутов и процессов:

? Для плановых наряд-заказов MRP ,

? Для подтвержденных наряд-заказов.

CRP определяет даты начала и завершения для каждой операции, используя календари рабочих центров и рабочие календари и технику (обратное планирование).

Операции планируются назад от даты выполнения заказа или графика поточного производства, начиная с последней операции.

Для каждой операции рассчитывается даты ее начала и завершения. Дата начала последней операции является датой выполнения предыдущей операции.

1) Производственный календарь определяет фактическое число рабочих дней.

2) CRP моделирует расходование часов рабочего центра, используя заказы как производственный спрос.

3) Расчет мощности за период сводится к умножению рабочих дней на мощность машины рабочего центра.

Мощности отдела определяются общим числом доступных рабочих часов для всех рабочих центров в этом отделе.

8.4.1 Пересчет плана по мощностям

План по мощностям обычно пересчитывается после запуска MRP(планирование потребности материалов). При запуске плана по мощностям(24.1) система ищет все заказы, удовлетворяющие выбранным критериям. Можно промоделировать загрузку рабочего центра используя функцию 24.1.

Отчет 24.1 содержит следующие поля:

Н-З: код Н-З;

ИН: идентификационный номер Н-З;

№ Позиции: код НП;

Выпуска: дата выпуска по Н-З;

Ожд: ожидаемая дата по Н-З;

Ст: статус Н-З;

Заказ. К-во: заказное количество по Н-З;

Завершен.К-во: завершенное количество по Н-З;

Нач Перв.Опер: дата начала первой операции Н-З;

ОждДата Посл.Оп.: дата окончания последней операции Н-З;

Последнее поле: рекомендации CRP: «Конфликт операций» - характеризуют заказы, которые создают перекрытие по календарному плану между отделами и рабочими центрами. Таким образом, для таких Н-З даты начала и окончания Н-З не соотносятся с датой начала первой операции и с датой окончания последней операции. CRP может планировать начальную дату первой операции заказа, которая будет раньше даты выпуска (в производство) спланированного или подтвержденного наряд-заказа. Потому что дата запуска рассчитывается, используя производственную длительность цикла, основываясь на среднем количестве заказа(1.4.7 поле «Заказ»). Если количество заказа использованное при расчете CRP намного отлично от среднего количества(1.4.7 поле «Заказ»), то получается сильное противоречие(расхождение). Расхождение также встречается, когда рабочий центр и цеховой календарь имеют отклонения от нормальной рабочей недели (например, запланируемое дополнительное (сверхурочное)время). Если начальная дата первой операции меньше(раньше) чем дата выпуска заказа, то выводится сообщение «Конфликт операций». Можно скорректировать одну из двух дат – дату запуска или дату выполнения и повторить запуск CRP для сглаживания конфликта; «Нет техкарты» - характеризуют заказы, которые не могут быть развернуты(не могут развернуть техкарту) . 8.4.1.1 Мощности отдела и рабочего центра Ресурсы по мощностям для CRP определяются в ведении рабочего центра(14.1) и отдела (14.5). Мощности отделов и рабочих центров – это время, имеющееся в распоряжении для производства в этих местонахождениях. Мощность рабочего центра – количество оборудования или персонала, умноженное на рабочие часы (из производственного календаря). В производстве мощности – это трудовые ресурсы в отделе и часы работы рабочего центра.

8.4.2 Сравнение загрузки с мощностью

С помощью функций загрузки можно сгенерировать загрузку для определенного диапазона площадок, рабочих центров, машин или отделов.

Загрузка рабочего центра 23.13- 24.17.

Если ранее разрабатывались планы по мощностям более высокого уровня (план по ресурсам) несоответствие между мощностью и загрузкой должно быть минимальным и корректироваться путем внесения небольших поправок в начальную и конечную даты технологического маршрута наряд-заказа.

Отчетов по отделам и рабочим центрам (функции 24.14, 24.16, 24.20, 24.23) отражают их мощность и загрузку.

Мощность по рабочим центрам и отделам может быть изменена за счет корректировки:

- рабочего календаря(36.2.5);

- календаря праздников(36.2.1).

- часы могут быть добавлены или вычтены из рабочих дней по рабочему календарю.

Время или количество загрузки наряд-заказов в разрезе рабочих центров и отделов могут быть изменены за счет корректировки:

- дат выполнения наряд-заказов;

- длительности циклов по операциям техкарты (1.4.7);

- поточного производства.

Планирование загрузки наряд-заказов может быть сдвинуто изменением дат выполнения наряд-заказа. Загрузка для подтвержденных и спланированных наряд-заказов могут быть изменены корректировкой времени очереди, настройки, обработки, ожидания или перемещения.

8.4.3 Анализ входных/выходных данных

Анализ данных необходим для того, чтобы обеспечить управляющие и проверяемые производственные данные о планируемых и фактических результатах.

Сравнение плановый входной и выходной потоки для рабочего центра с часами фактической загрузки и фактическим выходом в часах можно осуществит с помощью 24.5.

Отчет функции 24.5 содержит следующие поля:

План ввода: загрузка по планируемым операциям(по планируемым наряд-заказам),

которые начинаются в данном периоде; Планируемый вход = Стандартная настройка + (Стандартная обработка * Количество заказа(1.4.7))

Рассчитывается от определения начальной дата для планирования операций за период. Реал. Ввод: загрузка по реальным операциям (по подтвержденным наряд-заказам), которые начинаются в данном периоде;

Действительный вход = Стандартная обработка(часы обработки) * Количество заказа перемещенное(по Н-З)

Рассчитывается из транзакций перемещения операций за период. Транзакция перемещения может быть создана посредством выпуска наряд-заказа (в производство) и программы цехового контроля(17 модуль).

СуммОтклВвода: разница между планируемым и реальным значением «входа»;

План Выхода: загрузка по планируемым операциям(по планируемым наряд-заказам), которые заканчиваются в данном периоде;

Планируемый выход = Стандартная настройка +(Стандартная обработка * Количество заказа(1.4.7)

Рассчитывается через планирование операций в периоде, основанном на их дате окончания(выполнения).

Реальн.Выход: загрузка по реальным операциям(по подтвержденным наряд-заказам), которые заканчиваются в данном периоде;

Действительный выход = Действительная настройка +(Стандартная обработка * Завершенное количество(по Н-З))

Рассчитывается через учет трудозатрат за период. Учет трудозатрат осуществляется через обратную связь в модулях контроля работы цехов и производства и через функцию 16.21(закрытие наряд-заказа).

НакоплОтклВых.: разница между планируемым и реальным значением «выхода»;

План Очер.: разница между планируемыми значениями;

План. Очередь = Разница между планируемым вводом и планируемым выходом.

РеалОчередь: разница между реальным значениями.

8.5 Резюме по планированию

8.5.1 Планирование ТНГ

Функция 20 необходима для:

? согласования планов по сбыту и производству,

? балансировка валовой прибыли с помощью планов производства и сбыта

Коэф.оборачив. = ? Затрат(4) / среднее ? запасов(6)

8.5.2 Планирование ресурсов

В функции 21.1 определяется ресурс.

В функции 21.5 определяется связка ресурса с ТНГ для конкретного завода и задается коэффициент(значение поля «К-во На»), с помощью которого определяется загрузка ресурса для конкретной ТНГ.

В отчете функции 21.9(21.10) приводится суммарная загрузка(поле «Загрузка») ресурса по всем закрепленным за ним ТНГ.

Суммарная Загрузка ресурса (21.9)=

= Загрузка для ТНГ1 + Загрузка по ТНГ2 + ... + Загрузка ТНГn,

где

Загрузка для ТНГ1 = Значение поля «ПргнПрвз» (20.1)* Ко-во На(21.5)

В отчете функции 21.11(21.12) можно просмотреть загрузку ресурса по конкретным ТНГ (значение поля «Вед 100 2000»), где 100 – ТНГ, 2000 – 2000 год.

8.5.3 Главный календарный план

Сводный отчет по ГКП (функция 22.18) отражает поля описанные, на ниже приведенной схеме.

8.5.4 Укрупненное планирование/RCCP

ГКП проверяется с помощью функции 21.21. Перед проверкой необходимо определить ресурс и привязать его к конкретной НП.

Для возможности оценки выполнения ГКП необходимо предварительно запустить

MRP, после чего сформировать отчет 21.21 по суммарной загрузки ресурса:

Суммарная Загрузка ресурса (21.21)=

= Загрузка по Н-З1 для НП1 + Загрузка Н-З2 поНП2 + ... +Загрузка по Н-З1 для НП2 +

Загрузка Н-З2 по НП2 + … + Загрузка Н-Зn для НПn,

где

Загрузка Н0З1 для НП1 = К-во НП(16.1)* Ко-воРесурсаНа(21.17) / ДлитЦикла(21.17) В отчете функции 21.24 можно просмотреть загрузку ресурса по конкретному Н-З для НП(«Номер Позиц», значение поля «НЗ:»).

8.5.5 Планирование потребности материалов/MRP

На приведенной ниже схеме представлены поля отчета 23.14 по итогам MRP.

8.5.6 Планирование потребности в мощностях/CRP

CRP определяет возможность осуществления спланированных MRP и подтвержденных наряд - заказов на основании следующих расчетных данных:

? мощность рабочего центра,

? загрузка рабочего центра.

8.5.7 Возможные ошибки планирования

Спланирован заказ на слишком большое количество (при использовании политики POQ) или чрезмерно много заказов (политика LFL, FOQ). Проверена структура, источники независимого спроса – причины «дополнительного» количества НП не найдены. Возможное решение: просмотрите отчет по резервированию СЗ для данной НП(3.18, 3.17) – зарезервированное количество превышает доступный СЗ. MRP «допланировала» с учетом зарезервированного количества.

Лекция 9. Концепция управления производством в MFG/PRO.

9.1 Работа с наряд - заказами

Наряд-заказом называется указание изготовить определенное количество номенклатурной позиции (НП) к определенной дате.

Наряд–заказами могут быть как производственный заказ, так и график поточного производства. Наряд–заказы могут существовать для НП с кодом «Закупка/Производство» = М (т.е. производимые). На рис. 1 перечислены нормативные данные, которые должны быть определены в системе до того, как будет производится работа с производственным модулем .

9.1.1. Создание наряд - заказов

Наряд - заказы могут быть созданы:

- вручную,

- сформированы MRP,

- сочетание ручного и автоматического формирования.

Разница между этими наряд - заказами состоит в назначаемом каждому из них коде статуса:

? наряд - заказу, созданному вручную присваивается код статуса F – подтвержденный заказ,

? наряд - заказу, сформированному MRP, присваивается код статуса P – плановый заказ.

Наряд - заказ автоматически планируется системой, которая назначает даты начала и окончания операции.

Перед тем как одобрить заказ работник плановой службы должен проверить заказ на обеспеченность ресурсами. Плановый наряд - заказ может быть официально подтвержден с помощью функции 23.10, после которой его статус заменяется на F.

Изменения в характеристиках заказа (22.13) можно произвести только после его одобрения (когда его статус будет F). Для заказов со статусами E, A или R могут быть изменены списки материалов и технологические маршруты.

9.1.1.1 Определение наряд – заказа

Для ввода и работы с наряд - заказами используют функцию 16.1 «Ведение наряд - заказа». Спланированные и одобренные наряд - заказы также можно просмотреть с помощью функции 16.1.

Н-З: код наряд - заказа;

ИН: порядковый номер наряд - заказа (присваивается системой);

№ Позиции: код НП;

Тип: идентификатор вида наряд - заказа:

« » - обычные производственные заказы,

«R» - заказы на переработку/восстановление;

«Е» - заказы на расходные изделия/инженерные прототипы;

З-д: код площадки, на которой сформирован наряд - заказ;

Заказ. К-во: количество НП, изготавливаемое по наряд - заказу;

Дата Заказа: дата, когда был введен заказ(по умолчанию –системная дата);

Завершен.К-во: завершенное количество по наряд - заказу;

Дата Выпуска: дата, на которую запланирован запуск заказа;

К-во Брака: количество брака по наряд - заказу;

ОжидДата: дата, на которую запланировано завершение заказа;

Статус:

«P» - плановый,

“F” – подтвержденный,

“B” – пакетный,

“E” – детализированный,

“A” – зарезервированный,

“R” – отклоненный,

“C” – закрытый.

З-д: код площадки, на которой производится обработка по наряд - заказу;

Пр-жа/Раб: опциальный код, связывающий данный заказ с продажей/работой;

Код ТехКарты: код технол-го маршрута, используемый для наряд - заказа;

Поставщ.: код поставщика – информационное поле;

Спцф/Формула: код структуры продукта для наряд - заказа;

Выход: процент изделия по наряд - заказу, ожидаемых к получению в пригодном состоянии;

Замеч-я: информационное поле;

Коммент.: информационное поле;

ВнестиОтклоненияВ ПрК: признак расчета отклонений или их отправки во времени получения по наряд - заказу.

9.1.1.2 Жизненный цикл (ЖЦ) наряд - заказа

Код статуса наряд - заказа характеризует его прохождение по ЖЦ (рис.1).

«P» - плановый. Плановые заказы формирует система, они могут быть перепланированы.

“F” – подтвержденный. Запланированные заказы одобрены плановиком. Данные заказы системой не перепланируются, но по ним системой могут быть сформированы рекомендации.

“B” – пакетный. Используется для ручного ввода в систему большого количества наряд - заказов. Пока статус не изменится на детализированный, зарезервированный или запущенный(16.8 “Пакетное изменение статуса наряд - заказа”) системой не формируется спрос и не создается список и технологический маршрут.

“E” – детализированный. Система пересчитывает список по наряд заказу и фиксирует его вместе с технологическим маршрутом.

“A” – зарезервированный. Система резервирует материалы для наряд - заказа, основываясь на доступности НП на площадке.

“R” – отклоненный (запущенный). Система фиксирует список материалов и технологический маршрут наряд - заказа. Запуск наряд - заказа производит подробное резервирование НП.

“C” – закрытый. Система закрывает наряд - заказы по получению НП (это конец ЖЦ).

9.1.1.3 Список материалов наряд - заказа(16.13.1)

Копия стандартного список материалов наряд - заказа автоматически создается при создании наряд - заказа. По мере прохождения наряд - заказа через производство в этой копии делаются и хранятся необходимые изменения.

Список материалов наряд - заказа определяет компоненты, скорректированные под размер заказа.

Список материалов фиксируется, когда наряд - заказ принимает статус E,A или R.

После этого все изменения должны производится с использованием 16.13.1 «Ведение списка по наряд - заказу». С помощью данной функции также возможно переназначения местонахождений, с которых отбираются материалы для заказов.

9.1.1.4 Технологический маршрут наряд – заказа (16.13.1)

Технологический маршрут фиксируется, когда наряд - заказу присваивается статус E, A или R.

Ведение технологического маршрута сходно с ведением списка материалов по наряд - заказу. Оно позволяет изменять технологические маршруты наряд - заказов. Можно добавить или изменить операции тогда, когда статус заказа E, A или R.

9.1.2. Процесс запуска наряд - заказа

Процесс запуска - это изменение статуса наряд – заказа. Ккогда наряд - заказ готов к производству выполняется процесс его запуска и наряд - заказу присваивается статус R.

Запуск наряд - заказа в производство осуществляется с помощью функции Наряд - заказ

Выпуск/Печать (16.6).

Процесс запуска наряд - заказа:

- Проверка доступности компонент,

- Изменение статуса,

- Печать цеховой документации,

- Поместить в очередь на первую операцию.

При запуске наряда-заказа система выполняет подробное резервирование всех материалов.

Цеховая документация -это физически существующие документы (ведомость комплектации и технологическая карта по наряд - заказу), печатаемые и обычно сопровождающие наряд - заказ при его прохождении по ЖЦ.

В ведомости комплектации указаны: НП; местоположение, на котором хранится НП; требуемое количество для выполнения наряд – заказа (в соответствии со структурой продукта); единица измерения НП. В ведомости комплектации необходимо проставить реальное отпущенное количество по каждой НП для выполнения наряд - заказа.

В технологической карте (техкарте) указаны: операция; рабочий центр; время выполнения операции (в соответствии с техкартой). В техкарте необходимо проставить реальное время выполнения каждой операции. На основании указанных в техкарте реальных показателей выполнения операции по наряд - заказу осуществляется диспетчирование производства (функция 17.1).

9.1.3. Отпуск компонент(16.10)

Когда наряд - заказ запущен, необходимо отпустить со склада требуемые НП. Это выполняется с помощью 16.10.

Функция 16.10 имеет следующие поля:

Н-З: код наряд - заказа(при вводе можно воспользоваться помощью – клавишей F2);

ИН: идентификационный номер наряд - заказа(проставляется автоматически);

№ Позиции: код номенклатурной позиции (проставляется автоматически);

Статус: статус наряд - заказа(проставляется автоматически);

Оп: номер операции. Если в спецификации есть привязка компонент к операциям, то указав номер операции в 16.10 можно отпустить компоненты для конкретной операции(будут доступны только компоненты спецификации для зафиксированной операции);

Резерв Вып.: «Да»: зарезервированное количество(поле «РезервК-во») включается к отпуску(поле 16.10 «ВыбК-во»). ;

Выбран.Вып: «Да»: выбранное количество(поле «Выб К-во») автоматически включается в количество к выпуску(поле «К-воВып»).

ОткрК-во: количество необходимое к выпуску по этому Н-З.

РезервКво: количество зарезервированное для этого Н-З. Компоненты автоматически резервируются когда Н-З присваивают статус "А". Процесс резервирования компонент Н- З переводит количество требуемое в зарезервированное.

Выбр. К-во: количество печатаемое в ВЕДОМОСТИ НЗ. Значение этого поля присваивается во время печати ведомости, и не будет печататься в новой ведомости для этого Н-З. "Выбр. К-во" может быть показано как значение по умолчанию во время работы с функцией 16.10.

Отпуск Компонент по Наряд - заказу (для облегчения процесса выпуска компонент).

Если количество компонент увеличивают или вводят новое то ведомость будет перепечатана только на это количество.

К-во Вып.: количество компонент, которое будет выпущено в результате этой операции.

К-во О/З: количество остающиеся открытым после проведения этой операции.

Следующая рамка необходима для уточнения выпускаемого количества компонент.

№ Позиции: код номенклатурной позиции;

Оп: номер операции, на которой происходит отпуск компонент(проставляется автоматически);

З-д: код площадки;

Мсп: код местоположения;

Описание: описание НП (присваивается автоматически);

Парт/Серия: номер партии, из которой будет производится отпуск компоненты;

К-во: количество к отпуску;

ЕИ: единица измерения (проставляется автоматически);

Слк: ссылка использования компоненты;

Замена: Да/нет - признак возможной замены(предварительно замена должна быть определена). При определении замены появляется окно, в котором приведены позиции- замены для выбора.

Отм.Остат: Да/Нет - признак отмены остатка количества, остающегося к открытым после проведения операции отпуска компоненты;

Множ. Ввод: признак множественного ввода, при определении которого («Да») можно произвести отпуск с нескольких площадках, местоположений, партий.

9.1.3.1. Нехватка по наряд – заказу

При неполном отпуске компонент для отслеживании количества не отпущенных НП используются функции 16.15, 16.16, 16.17.

9.1.4. Расщепление наряд - заказов

Расщепление наряд – заказов производится при необходимости перемещения части наряд-заказа на другую операцию или разделения наряд–заказа на части из соображений ускорения обработки, слишком больших физических размеров или доступности компонент.

Расщепление наряд-заказов осуществляется с помощью функции 16.9. При расщеплении наряд-заказы будут иметь одинаковый код наряд - заказа, но разные идентификационные номера - ИН.

Н-З: код наряд - заказа, который подлежит расщеплению;

ИН: идентификационный номер наряд-заказа, который подлежит расщеплению (проставляется автоматически);

№ Позиции: код НП по наряд-заказу (проставляется автоматически); Статус: статус наряд-заказа, который подлежит расщеплению (проставляется автоматически);

Пакет: код пакета (вводится при наряд - заказе, созданном в пакетном режиме);

Тип: тип наряд - заказа (проставляется автоматически);

Заказ. К-во: количество по наряд - заказу, подлежащего расщеплению(проставляется автоматически);

Завершен.К-во: завершенное количество по наряд-заказу, подлежащего расщеплению(проставляется автоматически);

Разд.Опл.НЗ: Да/Нет – признак разделения бухгалтерских проводок по наряд - заказам; Кво для Разд.: количество НП для разделения;

Операция: код операции (вводится, если расщепление обусловлено необходимостью ускорения процесса обработки);

Нов ИН: идентификационный номер нового(полученного в процессе расщепления) наряд - заказа, проставляемый вручную. Если номер не проставляется, то он присваивается автоматически;

Заказ. К-во: заказное количество по операции(проставляется автоматически, если введен код операции);

К-во НЗП: количество незавершенного производства по операции проставляется автоматически, если введен код операции);

ЗавершенК-во: завершенное количество по операции (проставляется автоматически, если введен код операции);

9.1.5. Получение по наряд – заказу (16.11)

Когда производство выполнило наряд - заказ, он должен отправится на склад (16.11).

Получение наряд - заказа на складе приводит к двум последствиям:

- увеличение запасов на полученное количество,

- уменьшение оставшегося количества по заказу на полученное количество.

Н-З: код наряд - заказа;

ИН: идентификационный номер наряд - заказа;

Замеч-я: замечания по отпуску продукции;

№ Позиции: код получаемой НП(проставляется автоматически);

Описание: описание НП (проставляется автоматически);

Статус: статус наряд - заказа(проставляется автоматически);

ОткрК-во: открытое (не полученное) количество по НЗ (проставляется автоматически);

К-во: вводимое количество к получению по НЗ;

З-д: код площадки, с которой происходит получение НП;

ЕИ: единица измерения получаемой НП;

Местопол: код местоположения, на которое будет произведено получение;

Конвертац.: единица конвертации (для перевода в другую единицу измерения);

Парт/Серия: код партии для получения НП;

К-во Отходов: количество отходов по НП;

ЕИ: единица измерения отходов по получаемой НП;

Конвертац.: единица конвертации по отходам по получаемой НП (для перевода в другую единицу измерения);

Множ. Ввод: Да/Нет – признак возможности множественного ввода (используется для получения НП для нескольких площадках, местоположений, партий)

Уст. Атриб.: Да/Нет – признак определения атрибутов получения (проба, сорт, срок годности, статус складских запасов);

Замеч-я: замечания по получению НП;

Действит.: дата, на которую производится получение.

Закр.: Да/Нет – признак закрытия наряд – заказа (если «Да», то статус наряд - заказа после операции получения будет установлен в «С»)

9.1.5.1 Получение со списанием компонент

Когда под наряд - заказ отпущены компоненты (16.10), система автоматически вычитает отпущенные количества из текущих складских остатков. Возможно заменить выполнение функций 16.10 и 16.11 на 16.12.

Наряд - заказы на переработку Для отслеживания состояния работ по переработке/ремонту в функции 16.1 необходимо установить:

Статус – запущенный,

Тип – R.

Наряд - заказы на расходные изделия

Используются для отслеживания задач и издержек для наряд - заказов, не относящихся к регулярному производству.

В функции 16.1 необходимо установить:

Статус = Запущенный

Тип = Е

Технологический маршрут и список материалов могут быть введены вручную

Счет НЗП - Счет Расходы по проекту

9.1.6. Бухгалтерское закрытие наряд – заказа

В результате бухгалтерского закрытия наряд – заказа:

- закрываются операции,

- фиксируются трудозатраты на обработку,

- фиксируются трудозатраты на подготовку,

- фиксируются внесенные вручную изменения технологическогого маршрута,

- преобразуются производственные запасы в НЗП,

- фиксируются отклонения в использовании материалов,

- фиксируются другие отклонения.

Бухгалтерское закрытие наряд - заказа осуществляется с помощью функции 16.21.

При закрытии печатается “ваучер”.

9.1.7. Отчеты по себестоимости наряд - заказа

Отчеты по себестоимости формируется из системы с помощью следующих функций:

1. 16.3.4,

2. 16.3.5,

3. 16.3.6.

9.2 Оперативное управление производством

9.2.1 Разработка графика наряд - заказа

График определяется датой запуска в производства и датой получения готовой продукции, которые рассчитываются процедурой MRP методом обратного планирования с использованием нормативной длительности производственного цикла (рис. 12).

Рис. 12. Длительность выполнения заказа

9.2.1.1 Разработка графика операций

График операция составляется методом обратного календарного планирования от даты выполнения заказа.

С помощью обратного процедуры планирования с использованием длительности производственного цикла от даты выполнения заказа системой формируется дата запуска наряд - заказа.

Процедура обратного планирования использует следующие данные:

- подготовительное время,

- время обработки,

- время перемещения,

- время ожидания в очереди,

- время ожидания после операции.

Время реализации наряд - заказа изменяется с помощью функции 16.13.13.

Алгоритм календарного планирование учитывает перекрытие, которое определяет количество изделий, которые должны быть обработаны перед началом выполнения следующей операции.

Перекрывающееся количество можно определить в «Ведении технологического маршрута»(14.13.1).

9.2.1.2 Статус операции

Коды статуса операций используются для подробного указания состояния отдельных операций.

Коды статуса операций могут быть:

? введены вручную с помощью функции 16.13.13 или

? установлены автоматически при проведении операций отчета о трудозатратах оперативного управления производством.

Система использует следующие коды статуса :

? очередь (q),

? подготовка (s),

? обработка (r),

? завершение (c),

? задержка (h).

Статус «Очередь» может быть присвоен при запуске наряд - заказа автоматически, если поле в контрольном файле оперативного управления(17.24) «Переместить на следующую операцию» установлено в ДА.

Последующие операции автоматически получат статус «Очередь», когда предыдущая операция отмечена как «Завершенная».

9.2.1.3 Диспетчерские листы

Диспетчерские листы указывают наряд - заказы, которые будут получены на рабочем центре, а также уже находящиеся там наряд - заказы.

Это необходимо для определения ожидаемой загрузки рабочего центра. Такие листы печатаются ежедневно и помогают формировать график работ.

Диспетчерский отчет о наряд - заказе (16.18) показывает операции, запланированные на рабочем центре и отсортированные по датам начала.

Этот отчет обеспечивает для персонала цеха контроль за работой за указанное количество дней.

9.2.2 Запись информации о работе по оперативному управлению производством Начальные данные, которые устанавливаются по умолчанию в рамках функций оперативного управления производством (функций по диспетчированию) определяется с помощью контрольного файла (17.24).

На След. Операцию: Да – автоматическое присвоение статуса «Очередь» наряд - заказу при его запуске (последующие операции автоматически получат статус «Очередь», когда предыдущая операция отмечена как «Завершенная»);

ИндикаторВрем.: D- десятичные часы, M-минуты;

Стандарт.Часы: рабочее время в часах;

Стандарт.Период:

? D – в оперативном управлении производством при учете периода используются дни;

? N- в оперативном управлении производством при учете периода используются недели;

9.2.2.1 Отчет о трудозатратах по операции

Этот отчет используется для начисления зарплаты, связывает операцию наряд - заказа с конкретным работником (таким образом, назначается ответственный за выполнение операции), набирает статистику по простоям и браку. Простой работника – это ситуация, когда работа выполнена быть не может, посредством транзакции о непроизводительном труде.

Если простой не связан с определенным наряд - заказом используют «Отчет о непроизводительных трудозатратах». Должны быть указаны коды причин.

Функция 17.1 содержит следующие поля:

Н-З: код наряд - заказа (далее - НЗ);

ИН: идентификационный номер (вводится автоматически после ввода кода НЗ);

Операция: номер операции НЗ;

Статус ОП: статус операции НЗ;

Работник: код работника/вида работ(вводится в 14.13.21);

Цех: код цеха (вводится автоматически после ввода работника);

Смена: идентификатор смены работника (вводится автоматически после ввода работника);

Раб. Центр Машина: код рабочего центра(вводится автоматически после ввода операции НЗ)

КодОплаты: код оплаты (Например, HR – почасовая оплата; вводится автоматически после ввода работника);

УказВремя: Например, Десятичные часы, Минуты (вводится автоматически после ввода работника);

Проект: код проекта, в рамках которого выполняется НЗ (можно воспользоваться клавишей F2 – для выбора);

Завершен.К-во: завершенное количество по операции НЗ;

Действит.Дата: дата, на которую завершено количество по операции НЗ;

Брак: Да/Нет – признак брака. Если «Да», то появится окно для ввода причины брака и количества брака.

Операция Завершена: признак завершения операции;

Исправ:Да/Нет – признак исправления брака. Если есть исправления,то появится окно ввода количества исправлений;

Перемест.След Опер.: Да/Нет – признак перемещения на следующую операцию НЗ;

Предыд. Опер. Заверш.: Да/Нет – признак завершения предыдущей операции НЗ;

Нач. Настр.: используется для ввода начала времени по настройке для выполнения данной операции НЗ;

Уст-каИстеч/Ост-ки: используется для ввода конечного времени по настройке для выполнения данной операции НЗ или для фиксации количество часов/минут проведения настройки;

Истек.Установ: количество часов/минут проведения настройки (подсчитывается автоматически);

Нач.Вып-я: используется для ввода начального времени по выполнения операции НЗ;

Вып.Истеч/Ост-ки: используется для ввода конечного времени выполнения операции НЗ

или для фиксации количество часов/минут проведения операции;

Истек.Вып-е: количество часов/минут проведения операции(подсчитывается автоматически);

Коммент.: информационное поле;

ВремяПрст: время простоя по операции НЗ;

ПричинаПростоя: причина простоя по операции НЗ.

9.2.2.2 Отчеты о простоях

Простой работника – это ситуация, когда работа выполнена быть не может, посредством транзакции о непроизводительном труде. Если простой не связан с определенным наряд - заказом используют «Отчет о непроизводительных трудозатратах».

Должны быть указаны коды причин.

Коды причин определяются с помощью 36.2.17.

9.2.2.3 Движения по операциям (17.6)

С помощью движения по операциям отслеживается завершенное количество изделий по мере прохождения наряд - заказа. Это используется для фиксации данного прохождения.

9.2.2.4 Отчеты о завершении операций

Завершенные операции не отражаются в диспетчерском листе и не вносят вклад в прогнозируемую загрузку рабочего центра.

Статус «Завершенная»:

? присваивается автоматически во время проведения операции отчета о трудозатратах (17.1),

? 17.5 «Транзакции завершения операции».

9.2.2.5 Проводки Главной книги

Бухгалтерские проводки генерируются автоматически с префиксом WO в результате фиксации действий по изменению складского остатка. В случае установки системы учета затрат «Стандарт - Кост» отражения в разрезе бухгалтерских регистров отклонения между фактическими и нормативными затратами осуществляется с помощью функции 16.21. «Бухгалтерское закрытие», при условии что наряд - заказ закрыт – имеет статус «С».

9.3 Поточное производство

Поточное производство в MFG/PRO выделено в отдельный модуль.

9.3.1 Разработка графика поточного производства и варианты производственной линии

При разработке графика поточного производства используют график, похожий на заказы Главного Календарного плана.

Порядок работы в рамках модуля поточного производства:

1) верстка графика линии (автоматически – 18.1.10),

2) установка производственной линии(18.1.1), устанавливаем НП, участвующую в поточном производстве,

3) ввод времени переналадки линии (18.1.6), определяем время необходимое для переналадки на производство другой НП,

4) отчет о производственной линии (18.1.4) – для наглядности работы,

5) разворачивание графика(18.1.4) – для сравнения плана с фактом,

6) отчет о трудозатратах(18.13-18.18) – закрепление операций поточного производства за рабочими.

9.3.1.1 Ведение производственные линии

Производственная линия может быть определена с целью указания НП, которые будут производиться в рамках данного процесса. Графики поточного производства могут быть созданы только для производственных линий.

Функция 18.1.1. обеспечивает указание для линии количества изготавливаемых изделий в час.

Устанавливаем НП, участвующую в поточном производстве (18.1.1).

Разворачивание графика поточной линии – функция 18.6.

Отчет о трудозатратах в поточном производстве закрепляет операции поточного производства за работниками.

Существует 6 видов отчетов о трудозатратах:

- 18.13 “Подготовительные операции на линии”,

- 18.14 “Основные операции на линии”,

- 18.15 “Простои на линии”,

- 18.16 “Исправление брака на линии”,

- 18.17 “Не принято на линии”,

- 18.18. “Брак на линии”.

Ведомость комплектации (резервирование запасов) позволяет перемещать запасы на местоположение рабочего центра в соответствии с требованием графика.

Для использовании ведомости комплектации должны быть установлены местонахождения запасов с теми же именами, что и рабочие центры.

Запуск расчета ведомости комплектации(18.8.1) резервирует запасы.

Печать ведомости комплектации(18.8.5) изменяет статус запасов с зарезервированных на отобранные.

9.4 Резюме по производству

9.4.1 Последовательность действий при системе учета затрат «Стандарт - Кост»

9.4.2 Последовательность действий при системе учета затрат «Директ - Костинг»

1. Ввод и ведение наряд - заказа:

- Ручной ввод наряд - заказа(16.1),

- Одобрение спланированного наряд - заказа (23.10). Статус НЗ «F»;

При статусе НЗ E(детализированный наряд - заказ), A(зарезервированный наряд - заказ) или R(запущенный наряд - заказ) происходит автоматическое создание копии стандартного списка материалов наряд - заказа(16.13.1) и автоматическое создание копии технологического маршрута наряд - заказа(16.13.13), где по мере прохождения наряд - заказа через производство делаются и хранятся любые изменения.

2. Расщепление наряд - заказа(16.9) используется при недостаче компонент или для ускорения обработки наряд - заказа. После расщепления наряд - заказы отличаются только по ИНН.

3. Проверка доступности компонент по наряд - заказу(16.5):

- Дефицит (нехватка) компонент по наряд - заказу,

4. Запуск наряд - заказов в производство, печать цеховой документации (16.6):

- Присвоение наряд - заказу статуса R.

- Подробное резервирование (статус материала P -«Отобран»), фиксирующееся в списке материалов наряд - заказа(16.13.1):

- Печать цеховой документации(16.6). Это позволяет показать ведомость комплектации, технологический маршрут (т.е. подробности операций, комментарий к наряд - заказу).

5. Отпуск компонент для НЗ(16.10) приводит к:

- Уменьшению запасов на количество НП по наряд - заказу(текущие складские запасы – отпущенные кол-ва),

- Удалению любого резервирования по наряд - заказу для отпускаемых компонент,

- Включению компонент по наряд - заказу в незавершенное производство по нормативной стоимости (с точки зрения учета затрат)-16.3.5.

6. Трудозатраты по операциям конкретного работника(17.2) используется для:

- Определения завершенного количества НП по операции конкретного работника;

- Определения фактического времени выполнения операции;

- Набора статистики по простоям(коллизиям),

- Контроля за выполнением операций работника,

- Определения фактических издержек на оплату труда по факту получения готовой продукции,

- Ведения результатов контроля качества в рамках операции контроля качества.

Если результаты по операции контроля качества не вводятся, то они отражаются с помощью функции 19.13. Предварительно операция контроля качества не должна быть закрыта – для следующей за операции контроля качества операции значение поля «Предыд. Опер. Заверш.»(17.1) должно быть установлено в «Нет»,

- Автоматического формирования кода статуса операций С «Завершенная», когда «Завершен.К-во» = числу, «Операция завершена» = Да, «Перемест.След.Опер» = Да;

- Автоматического формирования кода статуса операций S «Подготовка», когда определено «Нач.Настр»;

- Автоматического формирования кода статуса операций R «Обработка», когда определено «Нач.Вып-я»;

- Автоматического формирования кода статуса операций S «Задержка», когда определено «Уст-каИстеч/Ост-ки», «ВыпИстеч/Ост-ки»;

7. Получение по наряд - заказу – 16.11 (отправление на склад, причем физическое перемещение на склад не обязательно, однако запись о получении означает завершение наряд - заказа):

- Увеличение запасов на полученное количество;

- Уменьшение оставшегося количества по заказу на полученное количество;

- Статус наряд - заказа может быть установлен в закрытый (С) – «Закрытый в «Да»(16.11)».

Получение со списанием компонент(16.12) используется при физическом перемещении материалов без проведения операции отпуска. Использование этих материалов может быть зафиксировано во время получения(16.12). При получении со списанием компонент происходит:

- Уменьшение запасов на количество НП по наряд - заказу(текущие складские запасы – отпущенные кол-ва).

- Удаление любого резервирования по наряд - заказу для отпускаемых компонент,

- Включение компонент по наряд - заказу в незавершенное производство по нормативной стоимости (с точки зрения учета затрат)-16.3.5.

Разница 16.10 и 16.12 в дате обновления запасов.

8. Бухгалтерское закрытие наряд - заказа (16.21) проводится на регулярной основе и направлено на:

- Преобразование производственных запасов в НЗП,

- Закрытие операций,

- Фиксирование в Главной книге трудозатрат на обработку и подготовку,

- Фиксирование разницы между нормативной стоимостью готовых изделий и общей стандартной стоимостью материалов, трудозатрат, переменных накладных расходов и субподряда на счетах отклонений по наряд - заказу.