Какая все-таки методика планирования производства реализована в 1С:ERP 2 согласно классическим определениям? (Закрытая часть)

Продолжение статьи “Какая все-таки методика планирования производства реализована в 1С:ERP 2.1 согласно классическим определениям?”

Первая часть статьи>>>

Следующий этап размещается в следующем интервале, в котором есть свободное время ВРЦ, необходимых для его выполнения. Таким образом программа постепенно “поднимается” вверх по структуре изделия, и определяет расчетную дату выпуска по заказу.

Если при планировании «К окончанию» осуществить не удалось (достигнута дата «Начать не ранее»), то система автоматически меняет размещение выпуска на размещение «К началу» и выполняет расчет возможной даты выпуска

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

• Если раньше – все нормально,
• Если позже, диспетчер либо передоговаривается с клиентом на более позднюю дату, которая получилась при планировании, либо передвигает заказ по очереди вперед и перепланирует его, а заодно перепланирует и все последующие заказы очереди так как этот новый заказ выталкивает из плановой загрузки оборудования последующие заказы, и даты их выпуска, соответственно, смещаются вправо. Получается более ранняя расчетная дата выполнения нового заказа. Заказ двигается вперед по очереди до тех пор пока не получится расчетная дата выпуска, устраивающая клиента.
• Поскольку при перемещении заказа в очереди новый заказ может вытолкнуть расчетную дату выпуска других уже согласованных заказов вправо, то новые даты выпуска по последующим заказам тоже надо пересогласовывать с клиентами. В этом и кроется основная причина “нервозности” производства для APS-подобных систем.

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

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

Какие выводы можно сделать?

Реализован ли в 1С:ERP алгоритм APS?

Очевидно, что алгоритм 1C:ERP похож на APS —планирование слева направо, расчет даты запуска и даты выпуска, захват времени работы ВРЦ в процессе планирования, планирование заказов поочередно с поочередным захватом мощностей. Однако пооперационное планирование на уровне планирования межцеховых перемещений (уровень глобального диспетчера) отсутствует, что делает такой график весьма приближенным. Впрочем, в этом есть свой плюс — система не требует точных пооперационных нормативов для межцехового планирования!

Вторым важным отличием является то, что APS подразумевает синхронное планирование (запасы + производственные мощности), в 1С: ERP это реализовано в соответствии с алгоритмом MRP + CRP (в несколько итераций).

Приближенность такого графика обусловлена следующим допущением: если на этап производства требуется время работы ВРЦ, то это время не привязывается к операциям. Считается, что все потребные ВРЦ, указанные в спецификации на этап, загружаются одновременно и параллельно в течение времени выполнения этапа. В реальности это не так; как правило, этап в подразделении выполняется последовательными операциями, но при планировании 1С:ERP об этом ничего не знает!

К чему это приводит, покажем на простом примере:
На этапе в одном подразделении выполняются две операции — № 1 и № 2. Интервал планирования — день. Операции выполняются последовательно. Согласно количеству, указанному в заказе, Операция № 1 требует 24 часов времени работы ВРЦ 1, а Операция №2 требует 12 часов времени работы ВРЦ 2. Каждый день доступно по 8 часов работы ВРЦ 1 и ВРЦ 2 . Программа расположит этап производства в трех интервалах (днях), так как считает, что всего требуется 24 часа — по большему времени обработки на ВРЦ 1. При этом на первый день программа назначит 8 часов ВРЦ 1 и 4 часа ВРЦ 2, на второй день – 8 часов ВРЦ 1 и 4 часа ВРЦ 2, а на третий день – 8 часов ВРЦ 1 и 4 часа ВРЦ 2. Получается, что работа ВРЦ 2 распланирована параллельно с ВРЦ 1.

Разумеется, организовать параллельную работу ВРЦ 1 и ВРЦ 2 не всегда возможно. В лучшем случае можно выполнить последовательно-параллельную обработку, используя небольшие передаточные партии. Если же обработке в течение 24+12 часов подлежит одна деталь, то на первую операцию потребуется 24 часа, а на вторую 12 часов. Следовательно, за 3 дня этап выполнить не удастся: на это потребуется 5 дней (3+2), но программа запланирует всего 3 дня. Иными словами, график, который сформирует программа, окажется невыполним.

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

Другой вариант — увеличить интервал до недели, если это допустимо.
Таким образом, отказ в 1С:ERP от точного пооперационного планирования по методу APS, но использование основных подходов APS позволяет получить результаты, похожие на результаты APS-планирования, но имеющие несравненно меньшую точность, чем APS. Тем не менее, график производства, формируемый 1С:ERP, по сути уже является расписанием загрузки мощностей, что кардинально отличает данное решение от MRP-систем.

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

Можно считать, что такой расчет не позволит уплотнить загрузку ВРЦ настолько, насколько это позволяет APS, т. е. потребуется буферизация, искусственное занижение доступного фонда работы и не 100% загрузка оборудования в графике. В этом смысле методика 1С:ERP ближе к MRP-системам.

Зато 1С:ERP не требует высокой точности нормативных данных, как того требует системы APS, а это очень важное преимущество. Без точных нормативных данных построить точный пооперационный график производства не получится, но он будет в любом случае точнее, чем график, формируемый MRP-системой. Аналогично APS-системе, 1С:ERP строит приблизительный график совокупной загрузки мощностей, отдавая все полномочия по его исполнению и планированию операций локальному диспетчеру цеха .

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

Итак, можно утверждать, что алгоритм планирования производства 1С:ERP — нечто «среднее» между MRP и APS, компромиссный вариант.

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

Реализован ли в 1С:ERP алгоритм MRP/CRP/RCCP?

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

В первом случае на выполнение этапа будет выделяться фиксированное время, указываемое в спецификации и не зависящее от количества обрабатываемых изделий по заказу. Для этого в спецификации этапа надо снять флажок «Использовать виды рабочих центров». В этом случае мы получаем планирование по алгоритму MRP. Причем это будет достаточно усеченный MRP, поскольку длительность этапов распланированного заказа никак не зависит от количества готовых изделий в заказе. Например, на выполнение заказа из 1 шт. и 1000 шт. программа отведет 3 дня, согласно суммарной длительности этапов заказа. Также важно понимать, что расчет сроков обеспечения материалами осуществляется до процедуры расчета графика на основе данных обеспечения в цепочках поставок.

Если это устраивает и необходимо хоть как-то запустить планирование производства без данных о нормативной загрузке ВРЦ этапами, то этот вариант — единственный.

Во втором случае в настройках видов рабочих центров устанавливается переключатель в положение «Не учитывать ограничение». В этом случае длительность производства планируется исходя из плановой доступности вида рабочего центра, но это не является ограничением. Фактически используется планирование «на пустой завод». В этом случае можно сказать о том, что мы получаем расчет по классическому алгоритму MPR + СRP. Единственное ограничение в этом режиме в типовом отчете не выводится доступность ВРЦ, что не дает сформировать информацию по дефициту или профициту.

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

Итак, при настройке 1С:ERP в режиме MRP получается совсем грубый график. Он менее точен, чем график, рассчитанный по полному алгоритму MRP, но дает общее представление о том, какие изделия и в какое время сдавать. При этом методики CRP/RCCP не поддерживаются.

О чем это говорит? Дело в том, что изначально такой режим спецификаций, по-видимому, не предназначался для работы по MRP-алгоритму. Данный режим настройки спецификаций предназначался, скорее всего, для реализации метода «ББВ» в межцеховом планировании.

И здесь начинается самое интересное!

 Реализован ли в 1С:ERP алгоритм ББВ?

Сначала определимся на каком уровне мы рассматриваем планирование в 1С:ERP по методике ББВ. Забудем внутрицеховое управление маршрутными листами, в котором используются так называемые “ключевые ВРЦ”. Данная статья посвящена исключительно межцеховому планированию.

Поэтому вопрос формулируется так: реализовано ли в 1C:ERP межцеховое планирование по методике ББВ?

Как выше показано, в 1С:ERP можно использовать варианты:

1. Для этапа производства (в спецификации) можно настроить время работы ВРЦ (причем нескольких ВРЦ), которое захватывается этапом при обработке заданного в спецификации количества изделий (в самом простом случае – на 1 шт.) и становится недоступным для других менее приоритетных заказов.
2. Указать, что этап производства выполняется фиксированное время для любого количества изделий и не захватывает время работы ВРЦ.

Если в производстве есть ярко выраженный узкий ВРЦ, то можно поступить проще: в спецификации, которая задействует этот “узкий” ВРЦ, достаточно указать потребное время работы этого ВРЦ (вариант 1), а в остальных спецификациях на полуфабрикаты в структуре продукта использовать фиксированное время выполнения этапа (вариант 2).

В результате:

• Узкий ВРЦ будет “барабаном”.
• Цепочка спецификаций перед барабаном с фиксированным временем выполнения будет “веревкой”.
• Суммарное фиксированное (!) время выполнения цепочки спецификаций перед барабаном будет «предшествующим» временным буфером.  В каждой спецификации важно указывать утроенное (как это рекомендуется в общем случае ТОС) фиксированное время обработки изделий. Иначе говоря,  время обработки (длительность) должно соответствовать суммарному времени операций на количество, указанное в спецификации на барабан.
  • Пример: если барабан способен обрабатывать 100 шт в час, то во всех предшествующих спецификациях (этапах) проставляется фиксированное время обработки: временной норматив на обработку 100 шт умноженный на 3.
• Суммарное фиксированное (!) время выполнения цепочки спецификаций после барабана (также умноженное на 3) будет “завершающим буфером”.

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

Получаем ББВ в чистом виде!

У этой методики возможные следующие расширения:

1.Если в структуре продукта на разных уровнях есть несколько потенциально узких ВРЦ, то в соответствующих этапах (спецификациях) вводится потребное время работы этих ВРЦ. В результате получаем планирование цепочки узких ВРЦ, загружаемых последовательно при выполнении заказа. Например если заданы два “узких” ВРЦ в разных подразделениях (т.е. разных этапах-спецификациях) и заказ проходит последовательно через эти ВРЦ, то планироваться будут три буфера:

1. предварительный перед ВРЦ1
2. промежуточный между ВРЦ1 и ВРЦ2
3. завершающий после ВРЦ2

2. Иногда при обработке изделия в цехе задействованы параллельно два узких ВРЦ – например, станок и оператор. Оба ВРЦ являются узким местом, но график работы у них разный. То оператор уходит на больничный, то станок встает на ремонт. Возможна ситуация, когда оператор одновременно обслуживает два станка — это значит, что потребное время оператора в спецификации будет равно половине потребного времени работы ВРЦ.

Пример. Нормативное время загрузки ВРЦ на этапе составляет10 часов, а оператора, обслуживающего этот ВРЦ — 5 часов. Это значит, что 2 станка работают параллельно по 10 часов, а один оператор работает 10 часов на двух станках одновременно (так называемый «многостаночник»). В спецификации этапа можно указать два и более ВРЦ с разными потребными временами для выполнения спецификации. Получаем несколько параллельно работающих «барабанов» в цехе (например, станок +оператор), работу которых программа будет загружать, исходя из доступного фонда их рабочего времени.

Оптимизации времени переналадки барабана.
Отметим, что переналадки барабана 1С:ERP планировать не будет, тем более оптимизировать время переналадок. Можно попробовать обойти это ограничение следующим образом: ввести фиктивные заказы на конечную продукцию «Услуга по переналадке» и на эту услугу прописать потребность в соответствующей переналадке «барабана», которая потребляет время его работы так же, как при обработке изделий.

Особенности в реализации ББВ в 1С:ERP в межцеховом планировании
Необходимо упомянуть особенности реализации методики ББВ, которые могут вызвать неудобства в сопровождении системы.

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

Получается, что правки спецификаций приходится выполнять не из-за изменения технологии изготовления отдельного продукта, а из-за изменения ассортимента выпускаемой продукции, что совершенно нелогично и очень неудобно. При изменении «узкого ВРЦ» необходимо зайти во все спецификации и выяснить у технологов (или извлечь из PDM-системы) операционные времена ВРЦ, которые теперь стали узкими. После этого операционные времена (потребности во времени работы) ВРЦ , которые стали «узкими», надо вписать, а потребности во времени работы ВРЦ, которые перестали быть узкими — удалить.

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

Это решение имеет свои издержки — например, сложность в синхронном внесении изменений в одинаковые спецификации, отличающиеся лишь описанием в потребности времени работы узких ВРЦ. Все остальное — материалы, трудозатраты и так далее — одинаковы. Если нарушение принципа «Одна информация вводится один раз» не смущает, так вполне можно работать.

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

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

Подробнее об этой методике>>>

Реализовано ли сквозное планирование по всем цехам в 1С:ERP?

Осталось рассмотреть еще один интересный вопрос — вопрос сквозного планирования межцехового графика по всей структуре продукта (дереву изделия).

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

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

При этом продвинутые APS и MRP декларируют учет запасов НЗП и различают потребности в полуфабрикатах брутто (валовая потребность) и нетто (чистая потребность).

• Потребность брутто – сколько всего надо потребить полуфабриката или материала для выпуска другого полуфабриката или продукции
• Потребность нетто – сколько надо выпустить полуфабриката, с учетом накопленного остатка в НЗП, чтобы покрыть потребность брутто.

Так, при сезонном спросе предприятие накапливает промежуточные полуфабрикаты в НЗП, чтобы обеспечить равномерную загрузку производства в течение года, а в сезон высокого спроса использует накопленные полуфабрикаты. Если предприятие работает именно так, то учет остатков в НЗП при расчете графика —абсолютно необходимая функция.

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

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

Дело в том, что сначала потребность брутто погашается за счет остатка НЗП, а если остатка НЗП не хватило, то возникает потребность нетто, которая и планируется к выпуску.

Решение этой задачи достаточно сложно и приводит к множеству коллизий.
Например, изменение даты выпуска заказа и, как следствие, перепланирование графика по заказу (если потребности этого заказа удовлетворялись за счет остатков НЗП) может привести к внезапной неисполнимости заказа и большому росту потребности во времени работы ВРЦ по заказу. Особенно это вероятно в том случае, если на новую дату выпуска по заказу планово-расчетные остатки НЗП в нужном количестве не обнаружены.
Проблема учета остатков НЗП при планировании решена в 1С:ERP весьма оригинально. Использован «торговый» типовой функционал обеспечения потребностей, который содержится в торговом контуре.

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

В результате образуется «открытая» потребность в полуфабрикате, выпуск которого не планируется в данной процедуре планирования. Чтобы запланировать выпуск такого полуфабриката, требуется снова ввести заказ на производство этого полуфабриката — либо вручную, либо с помощью специального мастера-помощника «Формирование заказов по потребностям», который сформирует новые заказы на полуфабрикаты, исходя из текущих фактических остатков в НЗП, уже имеющихся заказов на производство этих полуфабрикатов и потребности в них согласно графику производства.

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

Пример. В производстве три последовательных участка- передела №1, №2, №3. После участков 1 и 2 появляются остатки НЗП полуфабрикатов, которые надо учесть при планировании. В результате флажок «Производится в процессе» во всех спецификациях нужно снять.Сначала логист рассчитывает график работы участка №3. Получается потребность в полуфабрикатах №2, выпускаемых участком 2.

В мастере-помощнике логист создает новые заказы на производство полуфабрикатов участка 2 с учетом текущих остатков этих полуфабрикатов и потребности в них участка 3, после чего снова запускает процедуру расчета графика на производство по заказам на участок 2. Получается потребность в полуфабрикатах, выпускаемых участком №1. Логист создает новые заказы на производство с учетом текущих остатков полуфабрикатов № 1 и потребности в них участка 2, и опять запускает процедуру расчета графика на производство по заказам на участок 1. В итоге получается потребность в исходных материалах.

Выходит, логисту нужно выполнить три итерации планирования производства на участки 1, 2 и 3. Эти итерации предполагают определенные действия пользователя — запуск процедуры расчета, формирование новых заказов на производство и их контроль.

Итак, если нужно учесть остатки НЗП, то автоматизированный сквозной расчет графика по всем участкам сразу «одной кнопкой» по всем подразделениям от продукции до материалов в 1С:ERP не получается!

Чем это чревато?

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

Итак, сквозное планирование производства от продукта до материалов в 1С:ERP возможно, но только без учета остатков НЗП. В противном случае процедура планирования разрывается на отдельные итерации в точках технологического процесса, в которых надо учитывать остатки НЗП, с вводом новых заказов на производства от которых производятся новые итерации планирования.

Заключение
В этой статье мы постарались изложить основные моменты методик, опуская все подробности. Разумеется, в APS, MRP и ББВ существует множество нюансов, о которых можно прочитать в специальной литературе. Мы не ставили свое й целью детально описать функционал планирования 1C:ERP, а лишь хотели показать, насколько близка реализация планирования производства 1С:ERP к классическим методикам.

На основании вышеизложенного можно сделать вывод, что в части межцехового планирования 1С:ERP реализованы следующие методики:

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

Самое важное, что все три методики могут применяться одновременно – в одной процедуре планирования для разных цехов/участков. Это означает высокую гибкость настроек системы, но эта гибкость имеет и обратный эффект — высокую степень неопределенности при выработке модели планирования, а также необходимость поиска оптимальных режимов работы системы при планировании производства.
Найти универсальные рецепты «на все случаи жизни»— сложная задача, которая под силу только опытным профессионалам.

О функциональном моделировании>>>

[evc_social_likes]