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

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

Пример создания плагина - Плагины
Сергей: 18542 Николай Спирин написал: где здесь указать тип объекта? Второй параметр:[CODE ExtApp.Application.General.GetObjectByNotation(nmkNotation, (long)SystemObjectTypes.Nomenclature); [/CODE 18542 Николай Спирин написал: Второй вариант подойде ...
Внеплановые задания - Производство
Zms.komissarov: Здравствуйте! При создании внепланового задания не можем оставить комментарий, описывающий суть задания. Ячейка активна, но текст не набирается. В чем может быть дело? 
Форма ввода параметров - Отчёты
Владимир Трусов: Спасибо. Работает.
Поиск при создании накладной по заявке - Интерфейс программы
Константин Чилингаров: Здравствуйте, Записал. Спасибо.
Порядок строк приходной накладной - Интерфейс программы
Константин Чилингаров: Хорошо, понятно. Запишу отдельным пунктом в список предложений и пожеланий. Спасибо!
Пропали кнопки в меню. - Прочее
Константин Чилингаров: Здравствуйте, 18542 Николай Спирин написал: Как добавить прав пользователю? В справочнике "Сотрудники" в свойствах пользователя поставить галочку "Администратор". Если её нет - пункта "Настройки" в меню не будет у этог ...
Приёмка деталей на склад - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: 18424 Lesotehnikakirov написал: У нас так получилось:1. Количество детали в производственном заказе 1051 шт2. На склад сдано 244 шт3. Со склада выдано в работу 244 шт, остаток 04. На склад сдано 1051 деталь5. Теперь на складе в данном производстве ...
Комплект сборочных единиц - Производство
Константин Чилингаров: https://youtu.be/_wNKgTamNIs https://youtu.be/_wNKgTamNIs К качеству есть претензии (у меня у самого), но в целом смысл понятен. Если что-то слишком быстро или непонятно по ролику - пишите, тут рассмотрим подробнее. Сейчас с ролико-производством, н ...
Создание ЛЗК - Материалы, Комплектующие, Складской учёт
Lesotehnikakirov: Благодарю. Вопрос решился.
Редактирование накладных - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Заходим в общий справочник "учётные документы" (Рабочая -> Учётные документы). Там находим нужный "приходный ордер". Например, по дате и поставщику. Встаём на него, нажимаем "Отменить оприходование" (рис.1). Открыв ...
Поступление по заявке. - Ошибки в работе
Константин Чилингаров: Здравствуйте, Спасибо, записал.
Расчет себестоимости - Состав и технология
Константин Чилингаров: 18389 Zms.komissarov написал: отрезать деталь на станке дисковой фрезой по времени будет около 1 мин. - это Т шт. А вот получить задание, получить на складе пилу нужной конфигурации, установить ее на станок , настроить программу и т. п. по времени ...
Настройка колонок во вкладке "Движение по складу" - Общие вопросы
Lesotehnikakirov: ОК, благодарю
Ошибка приложения - Общие вопросы
Lesotehnikakirov: Вопрос решился, благодарю.
Ошибка Приложения. Недопустимый параметр. - Общие вопросы
Владимир Трусов: Переустановили операционную систему, заработало. Спасибо.
Создание учетных групп - Интерфейс программы
Константин Чилингаров: Здравствуйте, Записал в список. Нужно будет посмотреть, как это можно сделать.  Но уже точно не в ближайшем обновлении. В следующем, может, только.
Подключение к базе данных через API - Плагины
Сергей: Если вы про номенклатуру, то можно взять обозначение и наименование из одной базы и создать номенклатуру с такими же обозначением и наименованием в другой базе. Отличаться будет только ID. Поэтому, если есть связанные или зависимые объекты, которые т ...
Автоматическая установка единиц измерения - Интерфейс программы
Alex-220781: Также можно сделать и при заполнении позиции приходной накладной
SQL запрос - Экспорт импорт данных
Сергей: Да. Только немного не такой. Да и он может измениться со временем. Как и структура базы. API может спасти от некоторых проблем и ошибок. В общем, всё зависит от сложности задачи. Главное бэкап базы сделайте.
Ошибка при печати отчёта - Отчёты
Константин Чилингаров: Не очень понял, если честно, что именно вы сделали. Но коли разобрались - хорошо :)

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

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

×
Вход на сайт