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

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

Расчёт комплектации конструкторской спецификации - Состав и технология
NPP_ORION: Спасибо, вроде разобрались.
Калькуляция на изделие - отчет! - Отчёты
Константин Чилингаров: Здравствуйте, Отчёт сделать можно. Вопрос только в трудоёмкости (соответственно, стоимости). В идеале, хорошо бы взглянуть на данные, и ...
К чему привязан StarForce - Активация, Деактивация, Лицензии
Константин Чилингаров: Здравствуйте, К процессору, материнской плате, сетевой карте, памяти, диску, ОС. Ко всему этому в разных пропорциях. По идее, в инструкц ...
Создание нового производственного задания - Производство
Константин Чилингаров: Здравствуйте, Вероятно, или нет вообще технологии на соответствующую позицию (деталь, сборочную единицу), или в этой технологии нет ни ...
Отчет задание на пилу - Отчёты
Виктор Левушкин: Спасибо....уже применяем.
Ошибка печати отчета - Отчёты
Виктор Левушкин: Спасибо. Вроде уже разобрался. Веду теперь блокнот по каждой операции пишу последовательность, т.к. пока нет опыта, но уже много чего запу ...
Одно задание для нескольких работников и совместное выполнение - Обновление
Константин Чилингаров: Здравствуйте, Совместное выполнение отмечать через терминал "Тип 2" и раньше было можно. Вот пример - краткое пояснение на эту тему ...
Нормы расхода на окраску - Состав и технология
Lyovushkin: Спасибо буду пробовать
VOGBIT Онлайн - Общие вопросы
Константин Чилингаров: Здравствуйте, Клиентское приложение VOGBIT в данном случае ставится не на ваш конечный компьютер, а на сервер. А вы работаете с ним через и ...
Планирование производства - Демо версия
Константин Чилингаров: API есть. Описания базы данных нет (и вряд ли будем делать в ближайшее время). Есть /forum/forum35/ раздел на форуме . Там примеры использования AP ...
Как отслеживать все детали, входящие в заказ? - Прочее
Константин Чилингаров: Чуть добавлю: Ответ кратко: Да, можно будет продолжать работать с тем, что ввели в "демо-версии". Дополнение к предыдущему сообщен ...
Ошибка при открытии спецификации - Прочее
Константин Чилингаров: Здравствуйте! Версия программы старовата. Хорошо бы обновить. Когда-то, давным-давно, кажется, была такая ошибка, но её быстро починил ...
Учет материалов - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Здравствуйте, Вкладка меню "Складской учёт" -> Алгоритм списания -> FIFO.
Обороты по складу - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Здравствуйте, Это какими-то настройками или ещё как-то самостоятельно не решается, к сожалению. Нужно форму экранную саму поменять нем ...
Удаление позиции из номенклатуры - Прочее
mansur: Доброе утро, спасибо, все сделал по второму варианту. 
Ошибка при входе в Vogbit - Прочее
Григорий Клеков: написал: Здравствуйте. ...
Установка Демо версии - Демо версия
Amg: Спасибо большое за ответ. Демо-версию установил на ноутбук, если руководство решит перейти на ваш продукт, то думаю видеоконференция буд ...
Хранение файлов в БД - Общие вопросы
Константин Чилингаров: Если при этом вы хотите потом использовать штатные возможности VOGBIT (например, просматривать эти прикрепленные к операциям файлы в окне ...
Предварительные заявки, ЛЗК, Требования - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Здравствуйте! Периодически возникают похожие вопросы по "Предварительным заявкам", "ЛЗК", "Требованиям". В чём разница, ...
Конструктор фильтра - Прочее
Kochurova.av: Спасибо Вам большое!  Всё как всегда оказалось проще простого)

Технология подробно и заявки

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

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

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

То же касается ситуации, когда на деталь были созданы задания, а потом изменена технология.

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

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

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

Что делать:
Как вариант, можно использовать режим Затраты план-факт. И контролировать. Периодически, самому.
Пример на рис.1. Белая строчка - есть по последним данным по технологии, но отсутствует в запросах на склад.
Строчка выделенная жирным шрифтом - наоборот. Есть в запросе на склад, а по технологии (в состоянии её на текущий момент) такого нет.

А если подходить к проблеме системно, то это надо внедрять на предприятии процедуру проведения изменений.
А это мероприятие на 95% лежит в части чисто организационной.
В советское время ещё всё придумано.
Воспроизводить 1 в 1 все формы документов и процедуры в современном мире, конечно, не обязательно, наверное, но суть то правильная.
Что конструктор решив что-то изменить, если речь идёт о уже выпускаемом изделии, должен не просто делать это ни с кем не согласовав, и никому ничего не сказав, а как минимум, предварительно согласовать свою идею:
- с технологом, на предмет, как это вообще делать будут и не вылезет ли каких-то нюансов в других местах в плане изготовления;
- с ПДО, которые знают ситуацию по заделам деталей, планам и состоянию изделий, которые уже в производстве сейчас;
- со снабжением, чтобы они подтвердили, что они вообще такое привезут, в принципе, и насколько это сложно будет.
И потом только менять.
И после изменения, согласно принятого регламента известить народонаселение, что поменял и где.

Вот тогда будет порядок. Головняк, конечно, определённый в плане того, что нельзя просто так взять и всё поменять самому и всё. А только по определённой процедуре. Но на то оно и порядок.

А сама организация такого рода процесса, повторюсь, это в большей части именно организационный вопрос. Программа (какая бы то ни было, любая) - вторично.
1.png (44.69 КБ)
 
Да, про механизм "Затраты план-факт" я не знал, он наверно позволит решать проблему в какой-то степени.

А насчет организации изменений - да, мы работаем над таким механизмом сейчас.
 
Цитата
Lexam написал:
он наверно позволит решать проблему в какой-то степени
Ну, по крайней мере, выявить такого рода "отклонения" он позволит.
Были у меня некоторые мысли по поводу доработки этой штуки, как раз в контексте похожей ситуации, но пока только в качестве идей.
Страницы: 1
Сейчас на форуме
Всего зарегистрированных пользователей: 4008
Приняло участие в обсуждении: 416
Всего тем: 804
Всего сообщений: 6067

×
Вход на сайт