Обновление №7 для VOGBIT v.1.1.37841 - В производственном модуле внесен ряд изменений, направленных на упрощение работы с программой на «максимальном» уровне. В том числе: изменён порядок вывода на экран информации о количестве (запланированных/сданных деталей) – стало более наглядно и удобно

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

Заявки покупателей - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Да, это ошибка. На самом деле не при "обновить" даже, а при добавлении строчки в заявку. Разбираемся, почему так получилось. Пока рекомендация, сначала заполнять состав заявки, потом дату ставить. Иначе, судя по всему, её придётся заново ст ...
Расчет себестоимости с учетом входящих компонентов - Новые возможности
Константин Чилингаров: 3520 Alex-220781 написал: Но все таки, получается, что существующий алгоритм расчета себестоимости рассчитан на определенных пользователей (производство строительных металлоконструкций), всем остальным придется составлять техкарты, спецификации по ...
Заявка покупателя - Прочее
Saw-x: Спасибо. Приятно слушать, когда тебя слышат.
Работы попадают в Завершенные, а не Готовые. - Ошибки в работе
Константин Чилингаров: Я Алексею на почту отправил.
Возврат в окно - Интерфейс программы
Fomina: 3520 Alex-220781 написал: Хорошо бы соединить вместе достоинства однооконного и многооконного интерфейса. Согласна. Нужен просто возврат в то окно, где было открыто "Выполнение" или "Остатки"
Чистка базы - Прочее
Константин Чилингаров: Дайте копию базы посмотреть. Поглядим.
Перенос задания на максимальном уровне на терминале - Терминалы
Константин Чилингаров: Мы подумаем на эту тему.
Обновление информации в окне новых заданий. - Интерфейс программы
Константин Чилингаров: 3520 Alex-220781 написал: Я думаю, как минимум щелкнуть мышкой Я знаю людей, у которых новые задания добавляются 2 раза в день и по несколько десятков/несколько сотен штук за раз. Им их все придётся "прощёлкивать"? как-то не очень... Ес ...
Выбор постов на максимальном уровне - Новые возможности
Константин Чилингаров: Ок. Запишу пока в список. Посмотреть нужно. Спасибо
Информация о количестве изделий на терминале - Интерфейс программы
Alex-220781: 13 Константин Чилингаров написал: Когда берёшь (иногда и когда сдаёшь, когда это имеет смысл) есть кнопка "Предыдущий день" (рис.1). По поводу кнопки, она отображается, только если авторизироваться. Без авторизации можно посмотреть тольк ...
Расчёт заработной платы - Общие вопросы
Lesotehnikakirov: Добрый день! В окне статистики не считается заработная плата (расценка 0, сумма 0). Нормы времени на операцию и расценка за нормо-час в технологии заданы. При этом, в окне приёмки задания в столбце "нормо-часы" напротив фамилии работника по ...
Перезапуск программы - Установка
Константин Чилингаров: Здравствуйте, Что вы видите после входа в программу, зависит от того, к какой базе данных вы подключаетесь. Лицензия и база данных (её содержимое) никак между собой не связаны. Лицензия определяет возможность или невозможность запустить, в принципе, ...
В перечень отчётов не добавляется отчёт из шаблонов. - Прочее
Lesotehnikakirov: Да, действительно, так. Благодарю.
Задвоение деталей в графике производства - Производство
Константин Чилингаров: Здравствуйте, Скриншот слишком обрезанный, чтобы по нему что-то точно сказать. Судя по косвенным признакам, это не просто окно "График производства" открыто, а "График производства - Подробно". В этом случае одна строчка соответс ...
Запоминание состояния справочников и категорий - Интерфейс программы
Константин Чилингаров: Если речь о кнопке, которая переназначает исполнителя (участок) сразу для нескольких выделенных заданий в "Новых заданиях", то там, мне кажется, никогда и не предусматривалось в этом месте выводить "категории" и папки. Там, по-мое ...
Исправление количества сданных изделий - Производство
Константин Чилингаров: Резюме: 1. Почему так получилось: нужно было использовать функцию "отмена" в окошке сменного задания. Она корректно "откатывает" состояние задания, включая удаление информации по сданному количеству и другие нюансы. Указанная &qu ...
Нарушение области печати (решение) - Отчёты
Пётр: При подготовке нового шаблона отчёта столкнулся с проблемой, описание которой на Форуме не нашёл. Методом проб и ошибок получил если не правильное, то возможное решение. [B Суть проблемы[/B При редактировании шаблона отчёта в Excel, задаётся вы ...
Задания - Общие вопросы
Lesotehnikakirov: ОК, спасибо. Вопрос решился.
После 18-00 на терминале пустой экран - Терминалы
Константин Чилингаров: 3520 Alex-220781 написал: Может быть не там настраиваю? Не совсем там. На рис. в сообщении #3 - это настройки по умолчанию для создания новой смены. Эти цифры подставляются если создавать новую смену через "создать" или копирование (пе ...
Расчёт обеспеченности на основании заявки покупателя. - Общие вопросы
Константин Чилингаров: Последнее сообщение /forum/forum24/topic2374/ перенесено . Причина - не соответствует заявленной теме топика. См. /forum/forum24/topic928/# здесь , п.2.

Обеспеченность производственного заказа

Всё, что связано с расчётами и учётом материалов, покупных изделий, комплектующих и др. ТМЦ - Материалы, Комплектующие, Складской учёт - Работа с программой
Страницы: 1
Обеспеченность производственного заказа
 
Открываю обеспеченность по производственному заказу. Для него нужна складская позиция, 1 шт. На складе она присутствует - все ОК.

Но одновременно, эта же позиция нужна в другом заказе, а я это никак не вижу в обеспеченности.

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

Как обрабатывать такую ситуацию сейчас?

p.s. Учетными группами мы не пользуемся, на это есть причины.  
 
Открыть общую обеспеченность и выбрать из нее только позиции, относящиеся к конкретному заказу нельзя.

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

Цитата
Lexam написал:
Открыть общую обеспеченность и выбрать из нее только позиции, относящиеся к конкретному заказу
Ну, в эту сторону теоретически можно было бы подумать.
Но мне пока не до конца понятна логика, для чего в таком виде это всё нужно.
 
Цитата
Константин Чилингаров написал:
Это то же самое, что просто нажать "обеспеченность", не выбирая заказ.
Не то же самое, поскольку в общей обеспеченности нельзя выделить нужный заказ.

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

Предположим, у вас есть много заказов, и комплектующие в которых частично пересекаются.
Нужно определить, хватает или нет? Чего не хватает? Можно начинать собирать или нет?
Дальше всё зависит от того, как ставить вопрос.

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

Другая постановка вопроса: "но кроме этого есть ещё вот этот заказ, вот этот и вот этот". Они тоже важны. А все их закомплектовать нам хватит деталей? Или на все сразу уже чего-то не хватит? Чего? Сколько?
Такая постановка вопроса соответствует: выделить несколько интересующих заказов, нажать обеспеченность.

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


Теперь, что касается учётных групп. В чём разница с ними или без них в контексте данной темы?
Рассмотрим пример.
Предположим, у нас есть 10 заказов (1,2,3...10). В каждый из них нужно по 2 детали "А". Всего на складе у нас есть сейчас 12 деталей "А".

Что значит по смыслу вариант без "учётных групп".
Возвращаясь к вопросам выше:
Можем ли мы сейчас прямо собирать какой-то из этих заказов? Да, можем. Любой.
А можем сразу два? Да, и два можем. И три. Но не больше шести. Деталей А хватит только на 6 заказов. На любые 6.
Рассмотрим дальнейшее развитие ситуации.
Допустим, сразу больше двух заказов мы всё равно одновременно собирать не будем. Решили начать с заказов №4 и №7. Дали команду сборке.
Сборщики пришли на склад, им выдали детали "А" в количестве 4 шт., процесс пошёл.
Что мы видим в обеспеченности?
Незакомплектованных заказов у нас осталось 8, потребность в деталях "А" - 16 шт. Деталей на складе осталось 8 шт. Дефицит не изменился (если мы не запускали ещё деталей "А", конечно).
Таким образом мы можем по прежнему закомплектовать сейчас любой из оставшихся заказов (1,2,3,5,6,8,9,10). И даже несколько. Но не больше 4-х уже. На больше деталей "А" оставшихся не хватит.
Таким образом, пока собирают заказы 4 и 7, мы можем подумать, какие следующие два заказа из оставшихся отдать собирать. Можем любые два, какие сочтём нужным.
Например, 1 и 3. Останутся ещё (2,5,6,8,9,10)
И так далее. Если к моменту выдачи команды на третью пару заказов мы так и не получим на склад ещё деталей "А", то оставшиеся 4 заказа подвиснут в их ожидании. Какие - зависит от того, кто останется, кого вы до этого скажете собирать, на тех и уйдут имеющиеся детали из старых запасов.
А по хорошему, в самом начале  этого раздела (где начинается про 10 заказов) мы должны были тогда уже озаботиться намечающимся дефицитом деталей "А", который нам уже тогда программа в окне "обеспеченность" красным цветом показывала, и дать заказ на производство ещё таких деталей. Тогда, глядишь, к этому моменту как раз бы очередная партия деталей А на склад бы поступила и сборка бы не простаивала.

Это был вариант без учётных групп.

Теперь по поводу "учётных групп". Для чего они тут могут применяться:
Смысл использования учётных групп в контексте данной задачи в том, что мы посредством определённых дополнительных действий с программой заранее "распределяем" наши имеющиеся 12 деталей "А" на конкретные заказы из списка. Ещё до выдачи команды на сборку и до того, как кто-то пришёл за этими деталями на склад.
Мы уже заранее "откладываем" 2 детали "А" на заказ №4, две детали на заказ №7, две детали на заказ №1 и так далее. Предположим, мы таким образом "разложили" наши детали "А" на заказы "1,3,4,7,8 и 10".
И теперь уже выдать имеющиеся детали "А" со склада мы можем только на эти заказы.
Заказы, которым "не повезло" (2,5,6,9) в любом случае будут ждать поступления следующей партии деталей "А" на склад. Даже если к тому моменту детали, отложенные на какие-то заказы из списка, которым "повезло", будут продолжать лежать на складе так и не забранные по какой-то причине.

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

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

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

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

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

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

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

p.s.
Поддерживать бездефицитную обеспеченность по всем заказам в реальных условиях невозможно, множество деталей постоянно висит в дефиците, на это есть как организационные, так и другие причины (см. https://vogbit.ru/forum/forum29/topic2361/).
 
Что-то я не понял...
Почему запускать детали недостающие нужно, ориентируясь только на один заказа то?
То есть, как я понял, исходя из Вашей логики:
Чтобы не нарваться на недостаток каких-то деталей нужно пройти по всем заказам. По очереди. По каждому отдельно посмотреть дефицит деталей, из списка, что встречается в этом заказе. Запустить. Потом смотреть так же следующий заказ. И т.д. пока все заказы по очереди по одному не пройдёшь.

Вопрос: а зачем за столько шагов то?
Почему сразу по всем то не посмотреть итого, чего не хватает? Зачем последовательно, по каждому отдельно?

Цитата
Lexam написал:
Деталей повторюсь - десятки
Так это не много, в принципе. Если именно десятки.

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

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

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

Вообще, обеспеченность по заказу у нас проверяется один раз - когда заказ обрабатывается и запускается. После того, как мы достигли положительного баланса по заказу, мы больше не проверяем его обеспеченность.
Цитата
Константин Чилингаров написал:
Но если это и делать, то именно так. Не от одного заказа, а наоборот. Смотреть общую обеспеченность и из неё отфильтровывать только то, что встречается в запросах на конкретный заказ. Не наоборот.
Мне представляется, что нужно делать именно наоборот следующим образом:
Кнопка "Учитывать внешние заявки" в обеспеченности позволяет учитывать заявки покупателей. Но по отношению к обрабатываемому заказу, заявки из других заказов тоже внешние! Ведь так работает кнопка "учитывать незавершенное производство", она же обрабатывает не только данный заказ.

Предлагаю сделать так: если нажата кнопка "учитывать внешние заявки", то к расчету обеспеченности добавляются все имеющиеся заявки на позиции из списка (заявки покупателей, предварительные заявки, лимитные карты, требования). Это логично и позволяет решить проблему.
 
Дело в том, что "учитывать внешние заявки" показывает не только позиции из списка, а позиции из списка плюс позиции из "внешних заявок". В т.ч.и те, которых в исходном списке не было изначально при открытии окна.
И по другому нельзя. Потому что иначе, каким-то неизвестным образом не отыскав и не дав как-то принудительно содержимое всех этих "внешних заявок" на вход расчёту "обеспеченности", есть риск, что никогда и не узнаешь, что там в них вообще есть. Например, выпишет кто-то требование на новую какую-нибудь штуку. Для НИОКР, например. И всё. Никогда по такой логике её в "обеспеченности" не увидишь. Потому что ни на один заказ или заявку покупателя такого не требуется. В списке нет и при такой логике и не появится.

А если учитывать это, то
Цитата
Lexam написал:
к расчету обеспеченности добавляются все имеющиеся заявки
получается = запустить "обеспеченность" на всём. Что я сразу и сказал.  
 
Ну может и так.

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

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

И при запуске на выделенном заказе будет по выбору пользователя учитывать или не учитывать запросы на ту же номенклатуру по всем другим заказам/документам.
И с другой стороны тоже будет. В самой "обеспеченности" будет опция "показать только по одному заказу/документу" (но с учётом всех других).
И ещё и будет запуск обеспеченности просто по выделенной номенклатуре по любой. Прямо из "номенклатуры". С учётом остатков по ней, неснижаемых остатков (если заданы), заявок на закупку оформленных (если есть) и т.д. Не важно, есть сейчас действующие ЛЗК или требования на такую номенклатуру или нет.
Это тоже давно люди хотели.

Это всё одним пакетом в обновление вставим в ближайшее.
И, может быть, ещё пару "плюшек" из той же серии, если успеем.
 
Цитата
Константин Чилингаров написал:
В ближайшее время будет. В лучшем виде.
(первый вариант уже понажимал кнопки)
Ждем.
Назовите, пожалуйста, примерный срок.
 
Скоро. Конец мая - начало июня. Примерно.
Страницы: 1
Сейчас на форуме (гостей: 29)
Всего зарегистрированных пользователей: 2654
Приняло участие в обсуждении: 318
Всего тем: 804
Всего сообщений: 6066

×
Вход на сайт