Новая версия VOGBIT 20.5 - Новая платформа: быстрее, надёжнее, удобнее. Новая подсистема управления приоритетами в производстве. Новые возможности для участков ЧПУ. Улучшенные «цеховые терминалы». Новые возможности для совместной работы менеджеров, инженеров и производства при изготовлении уникальной продукции под заказ. И многое другое…

Последние темы на форумах VOGBIT

Карта раскроя - Общие вопросы
mansur: Добрый день, благодарю за развернутый ответ. Только я остановился на начальном этапе - кнопки ""Задания для объединения" отсутст ...
Очередность при расчете комплектации - Производство
Илья: При изучении роликов и тех. документации я понял что автоматическое определение очередности основывается на составе изделия. Т.е если у ...
Колонка материалы для окна статистика производства - Производство
Константин Чилингаров: 13 Константин Чилингаров написал: Я думаю, что Вам можно было бы поразмышлять о некоем "конфигураторе уровня учета", где пользовате ...
Невозможно запустить приложение в связи с недействительными данными активации - Активация, Деактивация, Лицензии
Константин Чилингаров: Да, похоже, есть какая-то проблема с очередным обновлением десятки. Мы уже известили о ней разработчика системы защиты (мы её купили, не с ...
Влияние Статуса - Прочее
Константин Чилингаров: Здравствуйте, С точки зрения общей логики работы программы (различные расчёты, формирование заказов на производство и т.п.) для специфи ...
Активация/деактивация - Активация, Деактивация, Лицензии
Елена Ковалева: Добрый день! Отвечено на почту.
Расчёт потребности - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Здравствуйте, По поводу «материалов» и «комплектующих». [B Первый момент – как лучше вносить:[/B Указывать в техпроцессе, как «комп ...
добавление и удаление деталей в заказ - Состав и технология
Константин Чилингаров: Да, есть такой момент. Много «хвостов» оставляет этот старый модуль «планирования загрузки». В версии 20.5 ещё не все из них удаляются лег ...
Внесение состава изделия, состоящего из большого числа вложенных сборок. - Состав и технология
Константин Чилингаров: 19208 Ирина Хохлова написал: все таки думаю, что фасад это сборочная единица и спецификация нужна Если "фасад" это некая конструкци ...
Пустой бланк - Демо версия
Константин Чилингаров: Правильно. С точки зрения выдачи чего-то со склада на выполнение некоего производственного заказа, обеспеченности, снабжения и т.п. - во ...
"Сворачивание" терминала - Терминалы
Константин Чилингаров: Ctrl+Shift+Esc - диспетчер задач. В нём снять задачу. Нужно только предварительно в диспетчере задач поставить галочку в его настройках "пок ...
Параметры командной строки клиента - Прочее
Константин Чилингаров: Здравствуйте, Да, можно. Вот так: "C:\Program Files\Vogbit\Csdn.Vogbit.Client.exe" -s=SRERVER -d=DATA_BASE -u=USER -is=no -p=PASSWORD -al=yes
Редактирование позиций при оформлении приходной накладной - Интерфейс программы
Константин Чилингаров: Здравствуйте, Про передвижение строчек было уже. Записано в списке пожеланий. Про замену номенклатуры - запишу. P.S. в новой версии сде ...
крнструкторская спецификация - Общие вопросы
Елена Ковалева: Добрый день! Могу предположить, что колонки были случайно удалены. Документация по настройке: https://vogbit.ru/support/628/#T918 https://vogbit.ru/support/628/#T918
Не копируется материал - Состав и технология
Илья: Спасибо, очень полезная кнопочка
Как вернуть производственный заказ в производство - Производство
xoxliandiia: Спасибо большое!!!))) получилось) 
Отображения количества деталей в терминале - Интерфейс программы
1113: Все верно.  И было бы здорово иметь возможность изменять шрифт комментариях к операции.  Например, у меня большая сборочная единица, в ...
Календарный план - Производство
Константин Чилингаров: Здравствуйте, Насколько я понимаю, сейчас карты заказов там идут вообще без какой-либо сортировки. В порядке создания. Как они появляли ...
Порядок строк приходной накладной - Интерфейс программы
Alex-220781: 13 Константин Чилингаров написал: Хорошо, понятно. Запишу отдельным пунктом в список предложений и пожеланий. Спасибо! Добрый день! На ...
Отсутствие РЦ в дашборде - Терминалы
Константин Чилингаров: Здравствуйте, Да, верно. На дашборде показываются данные по «текущей смене». Которая идёт непосредственно сейчас. Если таковой нет для с ...

Единичное производство. Ввод трудоемкости.

- Практические приемы работы - Старые разделы форума
Страницы: 1
Единичное производство. Ввод трудоемкости.
 
Добрый день! В документации по теме единичное производство описывается процесс создания заказа, когда есть определенный перечень работ, и операции пронормированы в процентном выражении, и режим укрупненного нормирования.
А как быть, если данный метод не подходит? Необходимо на изделие составить маршрут, и указать трудоемкость по операциям в абсолютных величинах (нормочас). Желательно не используя "Перечень работ", а просто переносить в карту операции.
 
Здравствуйте,

Вы хотите, чтобы задания при этом так же делались "по комплектам"?
 
По "по комплектам" подразумевает, что трудоемкость ставится общая на изделие, а трудоемкость отдельных операций в процентном соотношении. Такой способ мне не очень подходит. Не всегда трудоемкость операции зависит от общей трудоемкости изделия. Технологическую карту заполняю как по комплектам, в виде дерева. Это позволяет мне видеть стоимость изделия и формировать документы по изделиям - для передачи в бухгалтерию.
Поясню на примере. У нас сборка электрощитов. В разных заказах щит может называться одинаково "Щит распределительный ЩР", а вот комплектация, трудоемкость может значительно отличатся (даже в одном заказе могут быть разные по комплектации щиты). Поэтому в каждом конкретном заказе на одно и то же изделие необходимо устанавливать разные маршруты и трудоемкости. И не только в заказе, а при предварительном расчете себестоимости. Приходится себестоимость материалов считать в программе, а стоимость работ добавлять отдельно, вручную.
 
Цитата
Alex-220781 пишет:
По "по комплектам" подразумевает, что трудоемкость ставится общая на изделие, а трудоемкость отдельных операций в процентном соотношении.
Нет.
Это вещи, строго говоря, не связанные.

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

А нормирование можно при этом использовать и пооперационное.
Т.е. нормировать всё равно каждую операцию, каждой детали отдельно. Просто трудоёмкость задания рассчитается в таком случае, исходя из того, сколько каких деталей попало в комплект и трудоёмкости по каждой из них.

В общем, тип нормирования (пооперациооное / укрупнённое) и способ организации производства (по отдельным деталям / по комплектам) - это вещи напрямую не связанные. Можно и так и так.
Сочетания:

- Нормирование "пооперационное", производство "по комплектам" - можно
- Нормирование "пооперационное", производство "по деталям" - можно
- Нормирование "укрупнённое", производство "по комплектам" - можно
- Нормирование "укрупнённое", производство "по деталям" - технически можно, но на практике, по-моему, бессмысленно.

Цитата
Alex-220781 пишет:
Технологическую карту заполняю как по комплектам, в виде дерева.
Если говорить именно о тех. карте производственного заказа, то делать её в VOGBIT в виде дерева имеет смысл ТОЛЬКО В ОДНОМ единственном случае. Если у вас реально производственный процесс (выдача заданий, оплата, контроль выполнения) заточены под метод «комплектов». В некоторых производствах эта методика очень хорошо работает, просто «то, что доктор прописал». В некоторых вообще не работает. По определению. Зависит от технологии.
Но это ЕДИНСТВЕННЫЙ случай, когда карта заказа (именно «тех. карта заказа», на основе которой выдаются задания на посты) должна быть в виде дерева. В остальных случаях она должна быть линейным списком.

Цитата
Alex-220781 пишет:
Это позволяет мне видеть стоимость изделия и формировать документы по изделиям - для передачи в бухгалтерию.
Если только для этого, то  можно отдельную «коллекцию» сделать с деревом. Какую нужно. Специально для этого.

Тут вообще, нужно сразу отметить, принципиальный момент:
Все эти разговоры, как должна быть заполнена карта заказа, имеют принципиальное значение, если эта «карта заказа» используется по своему основному прямому назначению. Т.е. на её основании формируются задания для рабочих, и по этим заданиям люди в цехе каждый день работают. Тогда важно, как и что в этой карте. Чтобы задания получались такие, какие нужно.
Если реальных заданий для производства, по которым оно на самом деле работает, из «карты заказа» не делается, то в общем, нет разницы и всех этих нюансов, связанных с «комплектами» / не «комплектами» и т.п.

Цитата
Alex-220781 пишет:
В разных заказах щит может называться одинаково "Щит распределительный ЩР", а вот комплектация, трудоемкость может значительно отличатся (даже в одном заказе могут быть разные по комплектации щиты).
Если это физически разные изделия – а они точно у вас не одинаковые, если отличаются комплектацией, трудоёмкостью и т.п. – то это должны быть в базе РАЗНЫЕ номенклатурные позиции. Наименования хоть у всех пусть одинаковые будут. Но если это две (три, четыре и т.д….) физически разных железки, то в базе это должны быть две (три, четыре, и т.д.) номенклатурные позиции. Пусть все с одинаковыми названиями. Но какие-то индексы можно придумать в обозначении, ещё что-то. Это РАЗНАЯ номенклатура.
Если одной и той же номенклатуре соответствуют совсем разные изделия – это «моветон». Так лучше не делать сразу.

С точки зрения отдела продаж, бухгалтерии и т.п. – они могут никаких различий между ними не видеть, кроме цены, и все называть их «Щит ЩР». Но в базе, которой пользуется производство, Щит ЩР один и Щит ЩР другой – это должны быть разные номенклатурные позиции, если это физически разные изделия. Даже незначительно отличающиеся, но разные. Тем более, если сильно отличающиеся.
Делать новую номенклатуру не сложно. Копировать из похожей всё, что можно и исправлять.
А если изделия типовые, то можно и вовсе «генератор» настроить, он сам будет всё заполнять по новым изделиям. Автоматом.

Цитата
Alex-220781 пишет:
Поэтому в каждом конкретном заказе на одно и то же изделие необходимо устанавливать разные маршруты и трудоемкости. И не только в заказе, а при предварительном расчете себестоимости. Приходится себестоимость материалов считать в программе, а стоимость работ добавлять отдельно, вручную.
Вот вот…
Потому что это с точки зрения продаж, может и "одно и то же изделие". А с точки зрения производства – совершенно разные несколько изделий. Пусть и с одинаковым названием. Но РАЗНЫЕ!

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

P.S.
Все три вопроса, а именно:
1. Как нормировать трудоёмкость (по операциям или укрупнённо);
2. Использовать/не использовать принцип «по комплектам» (и как составлять карту заказа, соответственно);
3. Как правильно заводить изделия одной модели, но по факту разные (по комплектации, с отличиями в технологии и т.п.);

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

 Пример. Вот у меня в заказе есть "Шкаф ШР", техпроцесс "Сборка", "Упаковка". Я создаю техкарту, там указываю маршрут: Сборка - 5 часов, Упаковка - 1 час.
 Одновременно (или через некоторое время, а может и просто для расчета стоимости) в другом заказе также есть "Шкаф ШР", с другой комплектацией и временем изготовления, и там нужен другой маршрут с другими значениями часов. Нет смысла плодить номенклатуру. Не проблема, что в производстве есть изделия с одинаковыми названиями, они делаются по разным заказам, по разным схемам, и разными исполнителями.

 Проблема в быстром и простом составлении маршрута и указании часов по каждому конкретному изделию и операции. Без лишних действий по созданию перечней и пр. Ведь из перечня (документация Единичное производства) можно добавлять операции в заказ, почему нельзя обойтись без него - просто из справочника добавить операции и назначить каждой время, и чтобы эта информация хранилась только в техкарте по определенному заказу (а не техпроцессе на изделие)
Даже, если попробовать применить укрупненное нормирование, то вопрос в процентном нормировании. Укрупненное нормирование задается в настройках, а есть изделия, где такое нормирование не подходит - опять менять настройки?
 
Цитата
Alex-220781 пишет:

Цитата
Alex-220781 пишет:
Это позволяет мне видеть стоимость изделия и формировать документы по изделиям - для передачи в бухгалтерию.
Если только для этого, то можно отдельную «коллекцию» сделать с деревом. Какую нужно. Специально для этого.

Ее как то можно привязать заказу, делать по ней ЛЗК, накладные.
Если можно, поподробнее.
 
ЛЗК и накладные лучше по логике привязывать всё таки к карте производственного заказа.
Имелось с виду, что если нужно число для бухгалтерии сделать данные для "списания по нормативам" "на изделие", то можно чисто для этого сделать "заказную спецификацию" (полное дерево), на нём запустить "себестоимость", и сформировать нужного вида отчёт.

Что касается реального управления производством, то тут нужно, чтобы карта заказа максимально соответствовала тому, что на самом деле делается в производстве. И если склад в VOGBIT используется для того, чтобы реально отслеживать обеспеченность производства всем необходимым, своевременно выявлять дефицит, закупать что нужно и в том количестве, сколько нужно и т.п., то и ЛЗК (и выдача по ним, соответственно) должны быть завязаны, конечно, на производственный заказ, по которому реально производство работает.

Почему я заговорил про "отдельную коллекцию" и отчёт специально для бухгалтерии для списания (по её правилам)?

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

И в таком случае приходится выбирать.
Если нужно реально управлять тем, что происходит (чтобы понимать на самом деле, что есть на складе, чего нет, какие детали надо делать, а какие готовые и так есть, то же по комплектующим, что на самом деле в каком состоянии сейчас в производстве и т.д.), то тогда нужно данные (заказы на производство, складские операции и т.п.) вести в базе в сооответствии с тем, что на самом деле в производстве происходит.
Но это, зачастую, мало похоже бывает на "списание на заказ", как его видит бухгалтерия.
Что, в общем, не так страшно, на самом деле, т.к. можно сделать отдельный отчёт в виде списка материалов и покупных на изделие (можно с ценами сразу) и отдать это в бухгалтерию, пусть списывают, как им нужно. Не трогая при этом реальные заказы на производство и кладские операции в том виде, как они происходят на самом деле.
Если же в такой ситуации пытаться "подогнать" в программе данные не под реальный производственный процесс, а чтобы "списывалось правильно", то да, добится такого эффекта (нужного вида отчета) можно. Но это будет единственный результат. Управлять реально производством и его обеспеченностью не получится точно. Потому что в программе будет одна картинка, каким образом "как будто" делаются детали, выдаются материалы и т.п., а в жизни совсем другаю. Имея такие данные, особо ничем не поуправляешь. А вот поддержание "в рабочем состоянии" этой виртуальной пирамиды потребует скорее всего очень заметных усилий.

Это я не к тому, что у вас так.
Я не знаю, как у вас. На вашем производстве не был.
Просто сама ситуация такая далеко не редкость.
Довольно часто встречается.
Когда вопросы эффективности работы реального производства и снабжения вступают в противоречие с пожеланиями (требованиями) бухгалтерии (насчёт, например, списания всего и вся на изделие/заказ).
И тут надо разделять, что для чего делается и зачем.
Т.к. если смешать, то наступает беда. Сам видел. Работы получается куча людьми делается, толку ноль.


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

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

Если рассматривать вариант чисто позаказного производства, вообще без каких-либо заделов, в принципе, с чётким разделением непосредственно в производстве, какая деталь конкретно под какое конечное изделие делается, то там описанной проблемы, в общем то, и нет.
Например, производство строительных металлоконструкций:
Получили заказ, получили аванс, купили чисто под этот заказ материал, нарезали чисто под изделия этого заказа детали, сварили, покрасили, отправили.
И всё со "списанием" и с реальным производством нормально. Никаких противоречий.
А вот если брать, например, любое почти машиностроение/электронику и т.п. чуть посложнее, там зачастую не совсем так всё просто :)
Там и делали встречаются, которые на самом деле со склада берутся по факту соответственно никакой материал на самом деле не выдаётся на них сейчас со склада, потому как сто лет как уже потрачен он в реальности и т.п.
 
Много букв написал... :)

Краткое резюме:
Если вам нужно реально производственным процессом управлять, то структура и содержание карты заказа (комплекты, не комплекты, технология и т.п. - с чего тема началась) должно определяться ИСКЛЮЧИТЕЛЬНО требованиями соответствия данных в программе и реального производственного процесса.

Если производство сильно завязано на склад и сильно от него зависит, то добавляем к первому тезису, задачу четко увязать процесс изготовления (предыдущий пункт) с сопутствующими ему складскими операциями. Формируем к производственным заказам (которые, как мы определились, у нас соответствуют тому, что производство реально делает) ЛЗК - т.е. список что нужно взять со склада, чтобы это сделать. И фиксируем по факту, что пришло на склад, что выдали, вернули.

Имеем реальную картинку. Рулим процессом.
Отталкиваемся изначально в любом случае от того, что на самом деле и как делается в производстве.
 
Склад, ЛЗК и взаимодействие с бухгалтерией это отдельная тема.

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

Если настроить программу на укрупненный режим нормирования, как будут "работать" изделия, у которых технология описана в техпроцессе?
Можно ли при создании перечней не задавать никаких параметров (например, сложность как в документации).
 
Почитал настройки, укрупненное нормирование мне вряд ли подойдет. Не применимы характеристики: масса, объем и т.д.
 
Цитата
Alex-220781 пишет:
есть ли способ прямого составления маршрута изделия с указанием количества часов в абсолютных единицах?
Да. Можно и так.
Собственно само составление - вообще никак не отличается от других случаев. Берём операции, перетаскиваем мышкой.
Если использовать штатный механизм "техпроцессов", то трудоёмкость вводится тоже элементарно.
Если нужно чтобы операции были, но без техпроцесса, но при этом с пооперационным нормированием, то можно и так извернуться. Но тут уже, видимо, придётся прибегнуть к нестандартным средствам.
Но можно и так, думаю, сделать.
Попозже, будет время когда, поэкспериментирую, напишу подробнее, что получится.

Цитата
Alex-220781 пишет:
Если делать технологический процесс на каждое изделие, то, если это изделие будет в другом заказе - там будут те же данные по количеству часов - а необходимо, чтобы они отличались.
На каждый вид шкафа можно создавать отдельную номенклатурную позицию. Я так и делаю в пределах одного заказа. Но создавать на каждый заказ номенклатуру - не реально - их будут сотни и тысячи, причем номенклатура будет использоваться однократно. А отличатся они будут всего лишь количеством времени, затраченным на сборку.
Попозже на эту тему тоже выскажусь отдельно. Тут в двух словах тоже, боюсь, не получится.

Цитата
Alex-220781 пишет:
Проблема в быстром и простом составлении маршрута и указании часов по каждому конкретному изделию и операции. Без лишних действий по созданию перечней и пр.
по составлению маршрута и нормированию, выше уже написал. "Перечни" не нужны.
Необходимость в "перечне" есть, строго говоря, только при укрупнённом нормировании. Ибо в нём проценты проставляются. А в случае пооперационного нормирования, как вы хотите, можно использовать "перечень", а можно и не использовать.

Цитата
Alex-220781 пишет:
Ведь из перечня (документация Единичное производства) можно добавлять операции в заказ, почему нельзя обойтись без него - просто из справочника добавить операции
Можно. Без всякого перечня добавлять операции просто из справочника. При пооперационном нормировании.


Цитата
Alex-220781 пишет:
и назначить каждой время, и чтобы эта информация хранилась только в техкарте по определенному заказу (а не техпроцессе на изделие)
Это с предыдущим (перечни/не перечни) вообще никак не связано. Выше уже писал. Думаю и так можно извернуться при желании. Попробую. Большой только вопрос - стоит ли. Об этом тоже, как говорил, когда будет время напишу отдельно.

Цитата
Alex-220781 пишет:
Укрупненное нормирование задается в настройках, а есть изделия, где такое нормирование не подходит - опять менять настройки?
Нет. Тут нужно выбрать что-то одно. Либо методику укрупнённого нормирования использовать, когда трудоёскость задаётся целиком на изделие (совершенно не важно в данном случае, как она вычисляется, и откуда берётся), а при создании заданий распределяется в заданном процентном соотношении по видам работ. Либо использовать пооперационное нормирование, когда трудоёмкость задаётся на каждую операцию, каждой детали отдельно, а потом при создании задания складывается, исходя из того, что именно в задание попало.
Но надо либо так, либо так.
Использовать в половине случаев один способ, в половине другой - не вариант. Очень неудобно. Точно запутаешься.
По поводу укрупнённого нормирования вообще: если нет понимания, что это именно то, что нужно, и как этим пользоваться, то, видимо, оно вам просто и не нужно. Оно, действительно, подходит только в некоторых случаях. В большинстве - не нужно или неудобно.

Цитата
Alex-220781 пишет:
Если настроить программу на укрупненный режим нормирования, как будут "работать" изделия, у которых технология описана в техпроцессе?
Дело не в том, где описана технология. В "техроцессе" или прямо в тех. карте (без техпроцесса).
Тип нормирования влияет, по большому счёту, только на одно - как вычисляется плановая трудоёмкость заданий для производства при их создании (или при моделировании их создания, а-ля как это делают расчёты "себестоимости" или "загрузки").
Для одного способа нужны одни исходняе данные, чтобы посчиталось. Для другого - другие.
Если завести данные под один тип нормирования, а в настройках включить другой, то никак это работать не будет. Не посчитается просто плановая трудоёмкость заданий. Потому что исходных данных нет.
По этой же причине не имеет смысл пытаться использовать параллельно оба способа. Либо один, либо другой.

Цитата
Alex-220781 пишет:
Можно ли при создании перечней не задавать никаких параметров (например, сложность как в документации)
Можно. Это не связанные вещи.

Цитата
Alex-220781 пишет:
укрупненное нормирование мне вряд ли подойдет. Не применимы характеристики: масса, объем и т.д.
Опять же, дело не в этой "главной характеристике", по большому счёту (масса, объём и т.п.). Это просто коэффициент, по идее.
Суть в другом, в применимости самого принципа.
Можно ли вообще каким-то образом определить общую трудоёмкость изготовления изделия более-менее достоверно? Без всяких "техпроцессов" вообще. Или нет?
Применима ли аппроксимация, что эта общая трудоёмкость плюс-минус примерно одинаково распределяется по видам работ для разных изделий? Или это вообще кардинально не так?
Существует ли в принципе техническая возможность нормировать каждую операцию? Или нет?
Вот это определяет на самом деле выбор способа нормирования. А наличие "главного параметра" и т.п. - это всё вторично.

P.S. Кстати, сам факт жедания проставлять отдельно трудоёмкость на операции косвенно показывает, что на самом деле номенклатура то видимо, не такая уж титанически большая (даже если на каждое изделие отдельную заводить - это без разницы в данном случае, операции то хоть как на каждое по новой писать). Ибо сама идея укрупнённого нормирования в таком виде родилась, что называется, "от безысходности", если можно так выразиться.
В производстве, где реально такое количество новой номенклатуры (она по сути всегда там новая, никогда не повторяется), что пооперационно нормировать просто нереально. Невозможно просто. Быстрее сделать будет, чем по всем операциям трудоёмкость проставлять.
Пришлось придумывать людям другие способы. Иначе просто никак. Т.к. реально, очень много номенклатуры, чтобы на каждую операцию отдельно цифру вводить.
 
Добрый день!
Сделал так. Внес операции в техкарту, время опереций через кнопку "Редактировать параметры". Не самый удобный вариант работы в плане интерфейса, но пока так. Вроде корректно посчиталась себестоимость и создались задания. Посмотрим что дальше будет.

А раньше не получалось вставить операции - наверное, стояла галочка Готово. Я бы и не приставал так сильно :)
 
Да. Такой вариант, пожалуй, оптимальный. Если именно нужно, чтобы: операции были, пооперационное нормирование, но при этом без техпроцесса.
Имеет ли смысл именно в это упираться или не очень - думаю, ещё вернёмся к этому разговору. Взвесим за и против. Попозже только. Немного некогда пока.

Если же всё таки задаться именно такой целью, то да. Так и делать.
ТП не создавать. Добавить операции прямо в карту заказа.
Через "редактирование параметров" поставить операциям "Тшт".
Да. Не супер удобно. Но вполне. И главное, можно же.
Но и случай, всё таки, ИСКЛЮЧИТЕЛЬНО редкий, когда так делается. Поэтому не думаю, что стоит создавать ещё один какой-то специальный интерфейс, чтобы только было поудобнее конкретно в этом случае.

Дальше работает всё нормально. Я проверил. Задания создаются, отмечаются, всё правильно по ним получается.
 
Добрый день! Такая особенность - если задавать Тшт. в минутах - задания не создаются.
И еще. Если несколько позиций, в колонке Компонент (Редактирование параметров) показываются все операции, а название компонента - того, что был выделен при нажатии кнопки "Редактировать параметры"
 
Здравствуйте,
Цитата
Alex-220781 пишет:
если задавать Тшт. в минутах - задания не создаются
Да. Так и должно быть.

Когда-то давно, в самых первых версиях VOGBIT не было ни режима "состав", ни "технология", ни "технология подробно". Ничего этого не было.
И единственный способ описать техпроцесс было вручную через коллекции, компоненты, параметры.
В те времена и придумали, для задания трудоёмкости использовать два разных параметра "Тшт, час" и "Тшт, мин". Вроде как, для удобства. Добавляешь один параметр - задаёшь в часах. Добавляешь другой - задаёшь в минутах. Только два одновременно не предусматривалось добавлять.

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

В 99,99% случаев люди стали вводить трудоёмкость через "технология подробно". В связи с этим поддержку ввода трудоёмкости через параметр "Тшт, мин" убрали. Потому что никто фактически этим не пользовался, в то время как при создании заданий всё равно, каждый раз, проверялось наличие параметра "Тшт, мин" на предмет нет ли там случайно значения, которое нужно пересчитать. Лишние действия - лишнее время. Убрали. Оставили, что трудоёмкость "внутри" программы задаётся всегда единообразно, в часах. Ибо через тот интерфейс, которым все в 99,99% пользуются, не важно в чём вводить, само пересчитавается в обе стороны.

Цитата
Alex-220781 пишет:
название компонента - того, что был выделен при нажатии кнопки "Редактировать параметры"
Это посмотрим. Тут, похоже, не совсем так должно быть.
 
Теперь по поводу "сотни и тысячи номенклатурных позиций". Выше я обещал к этому вопросу ещё вернуться, т.к. тогда времени совсем не было. Возвращаюсь:

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

Вообще, это идеологически не верно, с моей личной точки зрения. Чтобы не было путаницы, и всё было прозрачно и логично, номенклатурная позиция должна соответствовать конкретному объекту в реальном мире. И если 2 объекта разные, если они чем-то отличаются (комплектацией, порядком изготовления и т.п.), то это должны быть две разные номенклатурные позиции. Недавно кстати в соседней теме похожая тема обсуждалась.

Ну ладно…
Давайте рассмотрим, а что мы, собственно, экономим, не создавая разную номенклатуру «щит».
Карта заказа (коллекция), в любом случае есть. Что так, что так.
Операции (компоненты) что так, что так есть. Одни и те же, в том же количестве. Вся разница только лишь в том, где эти компоненты лежат. В коллекции «карта заказа», или в коллекции «технология щита». Но компоненты то точно такие же все есть всё равно. И в том, и в другом случае. Включая их параметры и связанные объекты. Задания все точно так же создаются на основе этих компонентов. Точно такие же. Со всеми параметрами, связями, содержимым и т.п.
То есть, итого, во всей этой пирамиде объектов (компоненты, параметры, связанные объекты, задания и т.д.)  разница только в одну номенклатурную позицию и одну коллекцию. И всё!
А всё остальное то что так, что эдак, создаётся всё одно и то же!
То есть 99% мы все равно хоть так, хоть эдак создаём. А 1% зачем-то упорно экономим, создавая себе сложности дополнительные. А зачем?

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

Сложно создавать много номенклатуры?
Ну, во-первых, вы и так всё равно каждый раз создаёте. Большую часть из всего: операции, комплектацию. Что так, что эдак. Тут то ничего не меняется. Только одну номенклатурную позицию ещё плюс добавить.
Во-вторых, если они действительно эти щиты так похожи друг на друга, как вы говорите, и отличаются только чуть-чуть, то это значит, что можно, судя по всему, применить «генератор». Чтобы он либо вообще автоматически всё заполнял по новым изделиям сам, либо по крайней мере, создавал сам новую номенклатуру и на 90+% заполненную технологию с операциями, основной комплектацией и т.п., которую потом уже вручную подправлять с учётом конкретного случая. Т.е. технически сложности не представляет расплодить щиты, чтобы получался каждый раз «точно такой же, но другой», с минимальными правками. Ещё быстрее и проще, чем вы сейчас делаете, мне кажется, можно сделать при отдельной номенклатуре на каждый новый «щит».

Ещё «генератор» удобен в этом плане тем, что он сам перед тем, как создавать новое изделие, ищет в базе, нет ли уже ранее сгенерированого с точно такими же параметрами. И если есть, то говорит об этом. То есть можно не искать в базе, был ли уже точно такой же «Щит», к примеру, или нет. Просто каждый раз запускать «генератор» и вводить нужные параметры. Если был уже точно такой, то он найдёт и скажет. Если нет – новый сделает.

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

Несколько примеров из жизни про «много номенклатуры»:

Два года назад я запустил VOGBIT на предприятии, которое изготавливает приборы отопления. Нюанс там в том, что всего есть, по-моему, 11 моделей приборов у них. Не считая совсем уж нестандартных (которые тоже бывают). Но прибор каждой модели может иметь 3-5 вариантов высоты и 3-5 вариантов ширины. А длина может быть практически любой от 500 мм до 5000 мм. Какой закажут, такой и сделают.
Плюс у некоторых моделей может быть разный материал корпуса. Плюс может отличаться у некоторых моделей комплектация. Плюс разные цветовые решения могут быть. Разные по цвету и конструкции декоративные решётки могут быть. Кроме того, от размеров прибора (длины, ширины, высоты) зависит, какой теплообменник в него ставить (а теплообменники тоже изготавливаются) – сколько труб, как расположены, как и чем между собой соединены, сколько и каких ламелей в теплообменнике (это, кстати, ещё зависит от того, есть или нет в комплектации прибора вентилятор).
В общем, сочетаний очень много.
Каждый день поступают заказы новые. Иногда не очень много, иногда много. Но точно не один. В заказе может быть одно наименование прибора, а может быть 10 и больше. И все разные.

Что мы сделали:
Настроили в «генераторе» шаблоны под все модели и варианты.

Как работает:
Девушка менеджер получает заказ. Там список приборов с параметрами и количеством.
Открывает VOGBIT, выбирает модель, запускает «Генератор», вводит параметры. Если точно такой прибор уже был, то программа ей об этом говорит. Если нет, то сразу его создаёт новый в базе, и всё, что нужно автоматом заполняет. Остаётся только название правильно вписать.
Создаёт карту заказа, вставляет туда нужные приборы, на всё про всё – 5 минут. Ну, может, 10…
Дальше всё готово, начальник производства уже может, в принципе, выдавать задания на посты по этому заказу. Что и делает. С учётом текущей загрузки, конечно.

Посмотрел статистику по копии базы одной из недавних.
В ней конечных изделий на сегодня – 9 289 наименований. Разных.
И ничего. Всё отлично работает, все довольны.

И это ещё «пол беды», что называется.
Можно посмотреть на изготовителей строительных металлоконструкций. Там вообще каждый заказ – новая номенклатура. Всегда. По определению.
Они никогда не будут искать какую-то аналогичную по размерам пластину из другого заказа, чтобы её использовать. Они вообще всегда рассматривают новый заказ, как полностью новое изделие (что, в общем то, так по сути и есть у них).
Один заказ в данной области – это от сотни до нескольких тысяч может быть разных изделий (отправочных марок, как они их называют).
Каждое изделие (отправочная марка) состоит из деталей. От одной-двух до где-нибудь 80-ти наименований (деталей) может быть. В одном изделии (марке).
В рамках одного заказа определённая повторяемость деталей есть (встречаются почти одинаковые марки, в которых детали повторяются одни и те же). Между заказами детали никогда не пересекаются.
В месяц может несколько заказов проходить разных.
И каждый раз это новые марки (изделия), новые детали под них.

И ничего… Живут люди. Работают. Номенклатура действительно размножается.
Но это, как показывает опыт, не смертельно. Некоторые уже лет 7 работают в VOGBIT и вполне довольны.
Иногда подчищают базу. Раз в несколько лет. Может, раз в год.

Резюме:
Само по себе наличие сотен или тысяч номенклатурных позиций не смертельно. Номенклатуру можно рассортировать и разложить удобным образом. Можно часть спрятать. Вот если счёт на миллионы пойдёт, вот это, наверно, уже создаст определённые технические проблемы. Но пока за 10 лет мы не встречали такого на практике ни разу.
В то время, как соблюдение принципа «разные физически изделия – разная номенклатура» дает много очевидных плюсов. Тогда как несоблюдение его создаёт очевидные сложности.
Страницы: 1
Сейчас на форуме (гостей: 12)
Всего зарегистрированных пользователей: 3204
Приняло участие в обсуждении: 369
Всего тем: 804
Всего сообщений: 6067

Полезные ссылки:
Себестоимость Видео-презентация подготовка производства складской учет Полная версия VOGBIT Создание новой базы данных VOGBIT управление данными Планирование мелкосерийного производства Техническая Подготовка Производства электронный архив управление качеством деактивации VOGBIT активация VOGBIT управление производством Производственный заказ Установка VOGBIT управление ремонтами Трудоёмкость Деактивация VOGBIT планирование производства базы данных VOGBIT инструкция Начало работы Расчёт комплектации Складской учёт загрузка оборудования расчет себестоимости ТПП Демонстрационный режим VOGBIT Обновление VOGBIT График производства технологическая подготовка производственный учет Тип нормирования Заказ на производство производство металлоконструкций Нормирование пост руководство администраторов VOGBIT Планирование производства разработчика отчетов vogbit состав изделия демоверсия технология Состав изделия Обзор обновления Генератор отчетов склад Сменное задание Задания для производства Выбор уровня учёта новая база данных Расчёт общей стоимости материалов Заявки покупателей Управляемый расчёт материалов Парт
×
Вход на сайт