Изменение типа задания в производстве

[Nic]

Цитата:

Изначально опубликовано Vals
Объяснил таки
Посмотрите на картинку - ПЗ сгруппированы.
Отмечу, что цикл обработки я взял 60 минут (с 7-ю днями будет аналогично)

ПЗ 183 - 3т.
ПЗ 184 - 2т.
ПЗ 193 - 5т.
Эта группа делается с 9 до 10

ПЗ 242 - 8т.
ПЗ 247 - 2т.
Эта группа делается с 10 до 11

ПЗ 264 - 5т.
ПЗ 861 - 5т.
Эта группа делается с 11 до 12

Решено это следующими настройками:
1. Загрузка - загрузка РЦ соответствует отношению массы ПЗ к мощности РЦ, как было описано выше.
2. В производственном маршруте задано время обработки операции (в примере 60 минут), реально должно быть 7 дней.
3. В производственном маршруте задано Количество процесса = количеству ПЗ. Здесь и указывается, что сколько бы ни было количество ПЗ, делаться он будет 7 дней.

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

Попробовал, не получилось .

Если возможно, то расскажите по подробнее:
Т.е. как расчитывается потребление в произв. маршруте, по какой формуле "Стандарт" или "Мощность"?
Как указана мощность у РЦ, ограничена ли она?
Время выполнения насколько я понял указано в операции и оно больше не меняется и = 60 минутам. Количество процесса = количеству ПЗ (количество продукции в ПЗ или количество самих ПЗ)?
Загрузка РЦ соответствует отношению массы ПЗ к мощности РЦ - где и как вы указали загрузку РЦ?

С Уважением
Nic

[Vals]

Ой, да я и позабыл уже

Цитата:

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

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

Цитата:

Как указана мощность у РЦ, ограничена ли она?

Мощность ограничена, но нигде не указана (Стандрат, см. выше). Считаем мощность РЦ по календарю.

Цитата:

Время выполнения насколько я понял указано в операции и оно больше не меняется и = 60 минутам.

Да, ведь вы же сказали, что печка работает 7 дней (поэтому это время неизменно для данного РЦ), соответственно вместо 60 минут нужно поставить 7 дней: если поле Часы/время = 1(т.е. час), то соответсвенно время обработки = 7дней*24=168 часов.

Цитата:

Количество процесса = количеству ПЗ (количество продукции в ПЗ или количество самих ПЗ)?

Пардон, действительно двояко можно понять

Количество процесса = полю количество производственного заказа. Т.е. если обжигаете 2 тонны, то количество процесса 2 тонны. Получается что 2 т. обжигаются за Время выполнения 168 часов.

Цитата:

где и как вы указали загрузку РЦ?

Ручками в поле Загрузить производственного маршрута.

Ещё можно разобраться с формулой Мощность и возможно система всё-таки рассчитает описанный алгоритм.

Если получится - напишите обязательно

[Nic]

to Vals

Ок, сработало...
так и есть время одно (начало и конец у нескольких заказов), только приходится указывать на сколько процентов я занимаю время РЦ.
В данном случае все хОКей...


Задача усложняется тем, что мощность РЦ 10 тн, а заказ открыт скажем на 15 тн.
Система в данном случае говорит, что ПЗ будет делаться 1,5 часа
(если указано время выполнения 1 час на кол-во процесса 10), а должна сказать что 2 часа...

может есть способ и решить и эту задачу?

С Уважением,
Nic

[Vals]

Цитата:

только приходится указывать на сколько процентов я занимаю время РЦ.

да, это и не нравится мне в этом варианте, но он работает

Цитата:

может есть способ и решить и эту задачу?

По аналогии со всем остальным:
1. Разделить ПЗ 15 т = 10т. +5 т.
2. Загрузка в первом случае 100%
3. Загрузка во втором случае 50%

P.S. Когда я ставил формулу на Мощность, то система уменьшала время обработки (обжига в печи) в соответствии с мощностью:
т.е. если мощность печи 10 тонн за 7 дней, то 1 тонну она предлагала обжечь за 0.7 дня. Никак не мог её заставить зафиксировать время.
Поройтесь в этом направлении, может удастся. Появится время, я попробую ещё поискать. Напомните через пару дней пожалуйста.

[Nic]

to Vals

По аналогии со всем остальным:
1. Разделить ПЗ 15 т = 10т. +5 т.
2. Загрузка в первом случае 100%
3. Загрузка во втором случае 50%

Все бы хорошо...
есть маленькая проблемка...
у заказчика этих ПЗ очень много >200 и каждый из них многотонный (>10 тн.)
если каждый ПЗ разбивать, то это будет нечто...(представляю себе что скажет заказчик по этому поводу )

С "мощностью" такая же пробл как и со "стандарт", только в поле загрузка ставиться время загрузки оборудования в % (используется для резервирования мощностей РЦ), а в поле Множитель необходимо ставить расчетную величину для каждого ПЗ (мощность/количество) и тогда времена начала и завершения у нескольких заказов будут совпадать...
Это как еще один вариант...

С Уважением,
Nic

[Vals]

Я подумаю...
А пока - есть замечательная функция - Разбиение (ПЗ/Обработка/Разбиение)
Фильтр позволяет выбрать все заказы >10 тонн и разбить их.
Как вариант

Хотя бы не надо ручками ходить и "чикать" их, что на это заказчик скажет?

[Nic]

Согласен, вариант рабочий и является альтернативой решения проблемы.

Проблема может возникнуть в том случае, когда ПЗ создается из формы ЗАКАЗ, т.е. по сути дела ПЗ под каждого заказчика индивидуален и номер ПЗ и позиция совпадает с номером самого заказа на продажу. Когда же в системе будет несколько ПЗ с одним и тем же номером ПЗ (номер заказа на продажу и его позиция), то это может придать некоторое смятение в ряды Заказчика.
Допустим у нас заказ на 100 тонн № его 123456-789 № позиции 1, после разбивки по 10 тн. получается:
123456-789 1 10
123456-789 1 10
123456-789 1 10
123456-789 1 10
123456-789 1 10
123456-789 1 10
123456-789 1 10
123456-789 1 10
123456-789 1 10
123456-789 1 10
и самое интересное все это в одной форме ПЗ.
При данном методе мы только выиграем по загрузке РЦ, а проиграем по ряду причин:
1. Пользователь не скажет с каким именно ПЗ он работет.
2. Каким образом выдавать задание на РЦ (оно выдается позаказно, и пользователь обрабатывает ПЗ занося выработку).
3. Да и потом номер ПЗ и позиция являются уникальными полями и по сути дела это ключевое поле для всей работы предприятия.

Вот и закралась у меня идея со своей доработкой по мощности.
Ведь по сути дела когда мы указываем мощность у РЦ или ГРЦ и поле "Единица мощности" остается пустым, то система подразумевает что эта указана мощность в час.
Может возможно вывести какое-нибудь поле в котором мы будем указывать единицу мощности явным видом, т.е. получится примерно так:

Мощность 10
Единица тн
Период 7
Интервал Сутки (Минута, Час)

Может я в чем то не прав?

С Уважением,
Nic.

[Vals]

Цитата:

когда ПЗ создается из формы ЗАКАЗ

это каким функционалом?
...уже нашёл: Заказ/строки/Запросы/Производство. Функция конечно есть, но по моему мнению позволяет манагерам злоупотреблять ею, обходя параметры покрытия. Т.е. высока вероятность того, что заказ который может "подождать" будет выполнен гораздо ранее. По моему мнению лучше спланировать через сводное.

Цитата:

по сути дела ПЗ под каждого заказчика индивидуален

не обязательно, думаю не стоит принимать это как постулат.

Цитата:

номер ПЗ и позиция совпадает с номером самого заказа на продажу

позиция это номенклатура? Если так, то да, пусть она совпадает. А вот насчёт номера ПЗ не сгласен. У ПЗ и Заказа разные номерные серии, вы сами сделали чтобы они совпадали? А смысл?

Цитата:

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

Номера ПЗ должны быть разными. Что в этом плохого?
Пусть заказчик знает номер своего Заказа № 153 и пусть номенклатура для этого заказа зарезервирована в производствах №1001, № 1156, №60089 и т.д.
Я понимаю о чём вы говорите: менеджер ответственный за работу с заказчиком должен сообщить ему готовность заказа и его текущее состояние. Всё верно, если ПЗ создан из сводного, то система автоматически зарезервирует, если нет, то пусть менеджер зарезервирует соответствующие заказы. Резервирование и будет той связкой, по которой будет определено отношение нескольких ПЗ к конкретному заказу ПЗ.

Цитата:

1. Пользователь не скажет с каким именно ПЗ он работет.

ПЗ должны нумероваться разными кодами и разбиваться по разным номерам. Почему? Вы сами ответили на этот вопрос

Цитата:

Каким образом выдавать задание на РЦ

Задания нумеруются самостоятельной номерной серией. Даже если номера ПЗ будут одинаковы (но лучше не надо) - коды заданий будут разными.

Цитата:

Да и потом номер ПЗ

Вот и должны коды ПЗ быть разными

Цитата:

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

Доработать можно конечно, но гораздо интереснее решить всё стандартным функционалом. Взвесте оба варианта.
Если есть ресурсы для доработки, можно доработать, главное качественно сделать.
И об этом вам придётся принимать решение самому.

[Nic]

Цитата:

не обязательно, думаю не стоит принимать это как постулат.

Для заказчика это действительно является постулатом.

Цитата:

позиция это номенклатура? Если так, то да, пусть она совпадает.

Позиция это не номенклатура.
Мы имеем заказ на 1 год, в течении этого года мы должны отгрузить разную продукцию (номенклатура). Номенклатура одного периода изготовления (месяц) может совпадать с номен. другого периода.
Т.е. у нас есть заказ № 123 и заказчик хочет что бы ему изготовили и поставили следующее:
поз №1 - Валенки в январе
поз №2 - Сапоги в феврале
поз №3 - Валенки в марте
Вот для того что бы и не попутать номенклатуру и срок ее изготовления вводится пораметр "Номер позиции" - по сути дела это просто порядковый номер строк у заказа в форме "Заказ"

Цитата:

А вот насчёт номера ПЗ не сгласен. У ПЗ и Заказа разные номерные серии, вы сами сделали чтобы они совпадали? А смысл?

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

Цитата:

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

Все делается только для этого...

Цитата:

Номера ПЗ должны быть разными. Что в этом плохого?

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

Цитата:

Задания нумеруются самостоятельной номерной серией. Даже если номера ПЗ будут одинаковы (но лучше не надо) - коды заданий будут разными.

ДА так оно и есть

Цитата:

Доработать можно конечно, но гораздо интереснее решить всё стандартным функционалом.

Именно по этой причине я и пришел на форум, может кто чем поможет...
я на все согласен, главное что бы Заказчик был счастлив...

[Vals]

Цитата:

Для заказчика это действительно является постулатом.

Их "старая система" так делала?
Хорошо, если используется тип заказа Контракт, то какой номер будет у ПЗ?

Цитата:

Вот для того что бы и не попутать номенклатуру и срок ее изготовления вводится пораметр "Номер позиции" - по сути дела это просто порядковый номер строк у заказа в форме "Заказ"

Честно, не вижу никакой необходимости в аналитике поз №... (вы её будете тащить через всю систему?
"всё уже украдено до вас!" (с) Перефразируя известную фразу отмечу, что система способна отличить заказ на поставку Валенок в январе и марте. Как? А лоты зачем же? И даты поставки?
Итак, в вашем примере есть 3 позиции, у 2-х из которых одинаковая номенклатура. Как их отличить?
Во-первых, система запланирует разные сроки поставки и соответственно разные сроки производства.
Во-вторых, для каждой строки будет создан самостоятельный лот, который никогда не спутается.
Таким образом, хоть эти строки и содержат одинаковую номенклатуру, но в системе они будут разделены. Поэтому менеджер ВСЕГДА будет знать и уметь определить текущее состояние номенклатуры.

Цитата:

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

Обратите внимание (могут быть недочёты в кодировке, но суть должна быть понятна), что код Задания на производство формируется как:

Цитата:

заказ № его 123456-789 № позиции 1

т.е. №заказа=№ПЗ +номер позиции.

что плохого, если задание будет содержать не № позиции с сылкой на заказ , а сразу же код номенклатуры? А ссылка на заказ клиента, по которому создан ПЗ будет лежать в недрах системы: в резервировании и лотах.
Посмотрев на мониторинг тот же манагер увидит всё движение .

Цитата:

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

Сложно что-либо сказать. Понятно что раньше они загружали всё в ступки и варили. Но сейчас же у них ЕРП система подходы должны поменять.

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

[Nic]

Цитата:

Их "старая система" так делала?

Старая система это - Лист бумаги, Ручка и Excel - для обработки данных

Цитата:

Хорошо, если используется тип заказа Контракт, то какой номер будет у ПЗ?

Такой же
132456-789 п1...ххх

Цитата:

Честно, не вижу никакой необходимости в аналитике поз №... (вы её будете тащить через всю систему?
"всё уже украдено до вас!" (с) Перефразируя известную фразу отмечу, что система способна отличить заказ на поставку Валенок в январе и марте. Как? А лоты зачем же? И даты поставки?
Итак, в вашем примере есть 3 позиции, у 2-х из которых одинаковая номенклатура. Как их отличить?
Во-первых, система запланирует разные сроки поставки и соответственно разные сроки производства.
Во-вторых, для каждой строки будет создан самостоятельный лот, который никогда не спутается.
Таким образом, хоть эти строки и содержат одинаковую номенклатуру, но в системе они будут разделены. Поэтому менеджер ВСЕГДА будет знать и уметь определить текущее состояние номенклатуры.

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

Цитата:

Обратите внимание (могут быть недочёты в кодировке, но суть должна быть понятна), что код Задания на производство формируется как:

т.е. №заказа=№ПЗ +номер позиции.

что плохого, если задание будет содержать не № позиции с сылкой на заказ , а сразу же код номенклатуры? А ссылка на заказ клиента, по которому создан ПЗ будет лежать в недрах системы: в резервировании и лотах.
Посмотрев на мониторинг тот же манагер увидит всё движение .

Проблема в занесении выработки по РЦ на ПЗ, а точнее сказать в пользователях

Цитата:

Сложно что-либо сказать. Понятно что раньше они загружали всё в ступки и варили. Но сейчас же у них ЕРП система подходы должны поменять.

Подходы то как раз и поменяли...
"Хотим, чтоб система сама все делала"!!!
разьве не здорово?

Цитата:

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

Больше ни каких способов нет?
может какие идеи есть, я все проработаю...

С Уважением,
Nic

[Vals]

Цитата:

Старая система это - Лист бумаги, Ручка и Excel - для обработки данных

Вот отсюда и ноги растут у этой кодировки Заказ=ПЗ
На бумаге это было удобно, но системе это абсолютно не нужно. Наоборот, различная нумерация Заказов и ПЗ даёт дополнительную свободу без потери информативности.

Цитата:

Такой же

Контракт разбивается на заказы, как тогда постулат о том, что №заказа ==№ПЗ?

Цитата:

Проблема в занесении выработки по РЦ на ПЗ

выработка вносится по заданию, в коде задания есть код ПЗ, номенклатуры, самого задания. В чём проблема?

Цитата:

"Хотим, чтоб система сама все делала"!!!

Да, тут народ недавно про большую красную кнопку беседы вёл.
Если так хотят, то пусть возмут Самое короткое ТЗ

Цитата:

Больше ни каких способов нет?

пока в стандартном функционале нет, если что-нибудь выплывет - напишу.

[Nic]

Цитата:

Контракт разбивается на заказы, как тогда постулат о том, что №заказа ==№ПЗ?

Вот эти заказы и ==№ПЗ,
или я не так понял?

Цитата:

выработка вносится по заданию, в коде задания есть код ПЗ, номенклатуры, самого задания. В чём проблема?

В системе проблем нет, проблема в заказчике, т.к. он привык работать с номерами заказов, вот и все.

Цитата:

пока в стандартном функционале нет, если что-нибудь выплывет - напишу.

ОК договорились!

С Уважением,
Nic

[Vals]

Цитата:

он привык работать с номерами заказов, вот и все.

Вопрос из экономики в этом случае.
Т.к. они вводят выработку целиком на ПЗ, то соответственно себестоимость ПЗ - "котловая". Все затраты сваливаются в кучу и отследить их и проанализировать представляется трудным. Ещё раз отмечу, что на бумаге им это было удобно, но ведь система позволяет улцчшить оценку производства.
Итак, у них есть котёл, где Иванов, Петров, Сидоров вводят выработку.
Как управленец могу спросить: кто переработал, кто перевыполнил план, сколько реально стоит операция N и какой РЦ эффективнее её выполняет?

Вот в таком роде реально объяснить преимущества.

[Nic]

Цитата:

Изначально опубликовано Vals

Вопрос из экономики в этом случае.
Т.к. они вводят выработку целиком на ПЗ, то соответственно себестоимость ПЗ - "котловая". Все затраты сваливаются в кучу и отследить их и проанализировать представляется трудным. Ещё раз отмечу, что на бумаге им это было удобно, но ведь система позволяет улцчшить оценку производства.
Итак, у них есть котёл, где Иванов, Петров, Сидоров вводят выработку.
Как управленец могу спросить: кто переработал, кто перевыполнил план, сколько реально стоит операция N и какой РЦ эффективнее её выполняет?

Вот в таком роде реально объяснить преимущества.

А что тут трудного?
Выработка заносится по РЦ ежедневно по ПЗ, и как раз Иванов ставит свою выработку на своем РЦ, Сидоров свою и т.д. стоимость операции определена, т.к. оборудование стоит и никуда не девается, расход ресурсов то же определен.

Этот Вопрос встал тогда, когда говорилось о разбиении ПЗ.

С Уважением,
Nic