Новая версия VOGBIT 23.1.8 - Новые более функциональные и информативные цеховые терминалы, учёт остатков материалов в цехе и др.

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

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

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

Всё, что связано с расчётами и учётом материалов, покупных изделий, комплектующих и др. ТМЦ - Материалы, Комплектующие, Складской учёт - Работа с программой
Страницы: 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
Сейчас на форуме
Всего зарегистрированных пользователей: 3979
Приняло участие в обсуждении: 415
Всего тем: 804
Всего сообщений: 6067

×
Вход на сайт