VOGBIT Показ дефицита при расчете потребности. - Материалы, Комплектующие, Складской учёт
VOGBIT и Telegram бот - Пример доступа к данным из системы управления производством с телефона через Telegram

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

Учетные документы - Материалы, Комплектующие, Складской учёт
Валерий Бондаренко: Спасибо, слепой поиск очень помог.  Теперь по поводу сдачи на склад. Вогбит внедряли сначала на одном участке, там все так и организовано ...
Создание номенклатуры посредством "перетаскивания" в VOGBIT файлов - Общие вопросы
Константин Чилингаров: Не удалось загрузить файл или сборку "EPPlus, Version=4.1.0.0, Culture=neutral, PublicKeyToken=ea159fdaa78159a1" либо одну из их зависимостей. По этому вопросу:  С ...
Расчет плановых дат - Прочее
Андрей Тюрин: Будем ждать видео. Планирование производства -тема актуальная для нас.
Пример создания плагина - Плагины
Константин Чилингаров: Последние сообщения перенесены /forum/messages/forum24/topic2880/message17712/2880-sozdanie-nomenklatury-posredstvom-_peretaskivaniya_-v-vogbit-faylov#message17712 сюда . Причина: /forum/rules/ Правила ...
Сравнение производительности серверов - Прочее
Константин Чилингаров: Здравствуйте, Времена какие-то запредельные, на мой взгляд. Как по мне, для "расчёта" потребности минута - уже очень долго. Не говор ...
Расчет потребности материала из сменных заданий - Материалы, Комплектующие, Складской учёт
Zms.komissarov: Да, так и есть, не обновил строку и не увидел, что коэффициент пересчета указан для другого материала... Все работает! Спасибо!  
Восстановить учётные записи не срабатывает - Прочее
NPP_ORION: Разобрались, снимается вопрос.
Ошибка раскраски по приоритету - Ошибки в работе
Константин Чилингаров: Здравствуйте, Если кратко: 1. Нужно установить в настройках ручное назначение "приоритетов" (что пользователь сам проставляет &quo ...
Хранение в базе данных ссылок на файлы - Общие вопросы
Константин Чилингаров: Ещё штатный отчёт маршрутный лист с чертежом из PDF на обратной стороне у меня как-то не смог с первого раза сам сформироваться нормально, ...
Ошибка при печати отчёта - Отчёты
Константин Чилингаров: последнее сообщение /forum/messages/forum24/topic2877/message17694/2877-khranenie-v-baze-dannykh-ssylok-na-fayly#message17694 перенесено . Причина - нарушение /forum/rules/ правил форума , п.8.
Новые возможности. Объединённые задания. Как пользоваться? - Производство
Константин Чилингаров: Здравствуйте, Судя по данным вопросам, я понял, что Вы не поняли, как в принципе используется по задумке механизм "объединенных задан ...
Права Доступа Сотрудника - Прочее
Константин Чилингаров: Здравствуйте, Немного из истории вопроса…   В прошлой программе, которую мы делали до VOGBIT, была у нас «развесистая» система управл ...
Формат адреса прокси-сервера - Прочее
Владимир Белов: Добрый день! Нужно указывать в формате URL: http://170.70.0.1:3128 http http://170.70.0.1:3128 ://170.70.0.1:3128 У вас должен быть на прокси-сервере проброшен порт 28 ...
С Новым годом! - Общие вопросы
Сергей: На данный момент проблема решается повторной активацией серийного номера. Нужно нажать на кнопку "Повторить"
Совместимость с MS SQL Server - Общие вопросы
Владимир Белов: Добрый день! MSSQL 2008 не поддерживается. Минимальная поддерживаемая версия - 2012. Рекомендуемая - 2016 или более старшая.
Схема изготовления - Производство
Константин Чилингаров: А нет возможности из этого окна проверять наличие деталей на складе? Ну и выдавать их со склада, чтоб позиции "зеленели". Тут неск ...
И снова про брак... - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: при нажатии на + в Связанных позициях, я ожидал(хотел) увидеть появление трёх позиций... Для этого нужно настроить, какие позиции должны ...
Удаление запланиированных этапов - Состав и технология
Константин Чилингаров: Здравствуйте! Компонент либо не существует, либо на него ссылаются этапы В  базе данных есть задания для производства (создаются ком ...
Групповой перенос номенклатуры с изменением обозначения - Прочее
GlMax: В принципе ожидаемо, но странно, что в системе, которая вроде бы должна работать, в том числе, и с мелкосерийным производством, отсутствую ...
Отсутствие деталей, операций в графике производства - Состав и технология
Константин Чилингаров: Здравствуйте, Нужно смотреть, какие настройки в базе данных сейчас выставлены (тип нормирования, в первую очередь), и данные введённые ...

Показ дефицита при расчете потребности.

Всё, что связано с расчётами и учётом материалов, покупных изделий, комплектующих и др. ТМЦ - Материалы, Комплектующие, Складской учёт - Работа с программой
Страницы: 1
Показ дефицита при расчете потребности.
 
Добрый день!
Недавно столкнулся с такой проблемой - окно Расчет потребности, ставим фильтр Показать дефицит. Не показываются желтые строчки - то что заказано, но не приехало. И это плохо - то что создана заявка - не означает, что деталь когда-нибудь придет на склад - возможен отказ поставщика, замена на аналог и  т.д. - то есть по факту - это дефицит. И тут могут быть неувязки при формировании заявок на покупку и списании по ЛЗК.
Изменено: Alex-220781 - 01.06.2021 10:34:16
 
Здравствуйте,

Цитата
Alex-220781 написал:
окно Расчет потребности
Обеспеченность.

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

Цитата
Alex-220781 написал:
то что создана заявка - не означает, что деталь когда-нибудь придет на склад
Но означает, что не нужно уже создавать заявку на эту позицию. Она уже есть.

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

Так что, если понимать под "дефицит" в "обеспеченности" - нужно или не нужно заказывать (как задумано), то всё правильно показывается.
Если же вам нужно сориентироваться, всё или нет есть в плане уже выдачи со склада, то можно или фильтр не ставить в "обеспеченности", или вообще открыть для данного заказа "расход" и там включить расцветку и сортировку по цветам - см. рис. И сразу видно:
Зеленое - есть
Желтое - сколько-то есть, но меньше, чем нужно
Красное - нет пока в наличии
1.png (66.19 КБ)
 
Цитата
Цитата
Константин Чилингаров
написал:
Кнопка "Показать только дефицит" (предустановленный фильтр по сути) нужна, чтобы оставить на экране только то позиции, которые нужно заказывать. То есть счёт выписать у поставщика или заявку на производство отдать.
Спорное утверждение. В моем понимании дефицит - это то чего нет. Ну да ладно. Пусть будет так.
Цитата
Константин Чилингаров написал:
При этом следует изменить статус "заявки", откорректировать её, удалить или завести новую. Чтобы корректно отразить в программе эти изменения, произошедшие в реальности.
Это можно - а зачем? Только для того, чтобы данные при расчете потребности отражались? Практического применения этой заявки нет. Я создаю заявку в самом начале - чтобы отправить поставщику. Если и происходят какие либо изменения - то к заявке я не возвращаюсь - нет необходимости. Может, это только у меня так. Все вопросы с поставщиком решаются в живом общении, по почте, обмен письмами. А потом просто оформляется приход по заявке с учетом изменений. Но саму заявку менять не было необходимости.

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

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

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

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

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

БД новая - оборотов по складам еще не было.
 
Здравствуйте,

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

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

Если выделить просто номенклатуру (любую) и нажать "обеспеченность", то программа покажет информацию по выделенным позициям, не важно, есть по ним сейчас действующие запросы на получение их со склада, или нет.
Страницы: 1
Сейчас на форуме
Всего зарегистрированных пользователей: 4436
Приняло участие в обсуждении: 435
Всего тем: 804
Всего сообщений: 6067

×
Вход на сайт