Заказ звонка

Закрыть

*
*
*

Константин Чилингаров (все сообщения)

Выбрать дату в календареВыбрать дату в календаре

Страницы: 1 2 3 4 5 6 7 8 9 10 11 ... 442 След.
Новый режим УПАКОВКА, Прошу описать как использовать новый режим упаковка
Здравствуйте,

Если говорить про тот новый режим и функции, касающиеся упаковки, которые появились в обновлении, то они к операциям и постам никакого отношения не имеют.

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

И вот тут начинается та «Упаковка», о которой речь.
В чём тут смысл:

Представьте, что заказ, который вы выполняете, это несколько десятков, или несколько сотен наименований изделий. Разных. Побольше, поменьше, некоторых по несколько штук, некоторых много. А все они вместе – заказ, который вы производите, и который надо отдать в итоге клиенту.
Ну, например, ваш заказ – это «магазин». А поставляете вы по факту заказчику кучу вешалок, крючков, кронштейнов, стоек, рам для крепления этих вешалок и крючков и т.д. и т.п.
Производство делает и сдаёт на склад эти самые вешалки в количестве 200 шт, крючки в количестве 1200 шт, несколько рам, несколько стоек (отдельные изделия). И так они и лежат изначально на складе. Как «вешалки», «крючки», «стойки», «рамы» и т.п. от определённого заказа. В плане постов и операций по этим изделиям на данный момент уже всё. Задания все выданы, выполнены, изделия готовы, сданы и приняты на склад.

Но отгружаются они не совсем так.
А сначала, уже на складе, берутся большие коробки (или паллеты, например). В коробку (на паллет) можно положить, например, 10 вешалок и 200 крючков. Или 2 рамы. Или ещё что-нибудь. И укладываются в разных вариантах эти «вешалки», «крючки» и т.д. по коробкам (паллетам).
Потом каждая коробка заклеивается скотчем, заматывается плёнкой и на неё клеится этикетка. Что это «Упаковка №123, заказ 456». Можно добавить к этому упаковочный лист - чтобы прямо на коробке была наклеена бумага со списком, что в этой коробке лежит.
И заказчику по факту в машину кладутся эти большие заклеенные коробки. Т.е. «упаковки». А не отдельные изделия, которые на склад сдавало производство.

Вот за этим и нужны эти новые режимы и функции про «Упаковку», про которые речь в описании.
Чтобы отразить ту часть, которая уже после изготовления, после технологии, операций постов. Изготовление (технология со своими операциями и постами) уже закончилась на том, что готовые изделия лежат на складе. Это то, в общем, и раньше было.

Что добавилось:
Теперь есть функция «упаковать» на складе ГП. Можно выбрать 3 таких изделия, 2 сяких, 10 эдаких… и сказать, что всё это вместе – это «упаковка». Со своим номером, штрих-кодом, размерами, весом и т.п.
И программа теперь это «понимает». Она может показать не просто список всех изделий на складе, но и какие из них уже упакованы в «упаковки», а какие нет.
Можно посмотреть список готовых «упаковок» заклеенных, подготовленных к отгрузке по заказу. И что в какой лежит.
Можно при отгрузке указать, какие упаковки погрузили, и программа сама сделает накладную на списание всего, что в них лежит, со склада и сопроводительные документы:
- список всех изделий, которые отгрузили, с указанием в какой упаковке что лежит;
- список отгруженных «мест» - т.е. просто всех коробок (паллет и т.п.) и сколько их всего;
- упаковочные листы на каждую коробку (заказ, номер упаковки, штрих-код, что в ней лежит).

Вот про эти новые функции в описании идёт речь про «упаковку».

Но это всё, повторюсь, к постам и операциям не имеет никакого отношения. Это всё уже после них.

Что же касается именно операции «упаковка» в техпроцессе изделия, которая выполняется на отдельном посту – то это имеет смысл в случае, если, например, процесс непосредственно производства этого изделия заканчивается тем, что каждое такое изделие складывают в свою коробку с пенопластовыми прокладками, коробку заклеивают и в таком виде сдают уже, как готовое изделие, на склад. Уже в коробке. Вот в этом случае можно операцию упаковки прописать и в техпроцессе (с отдельным постом, заданием и т.п.). Т.к. на склад изделие попадает уже упакованное определённым образом. Т.е. такую "упаковку" можно рассматривать, как составную часть "изготовления" данного изделия.

Что, в общем, не мешает совершенно потом уже на складе эти коробки с изделиями складывать в паллеты (или большие коробки), заматывать их плёнкой, клеить упаковочные листы и т.д. – т.е. заниматься с ними дальше тем, о чём выше шла речь в контексте «упаковки».

Это было пояснение, о чём вообще речь в данном случае.
Если кому-то интересно более подробно, как конкретно те или иные действия делаются из тех, что кратко описаны выше, то справшивайте, постараюсь кратко показать/ответить.
Ошибка после обновления, UID = VGB_Terminal_Connect
Здравствуйте,

Инструкция, пункт 5.
Нужно выполнить.

С любого рабочего места зайдите в VOGBIT, откройте в меню "Настройка", нажмите "Проверка настроек". И всё.
Достаточно один раз сделать.
И будет всё нормально.
Отслеживание результатов выполнения работ на участках
Мне доказать то не сложно.
Я уже сказал, что определённую пользу вижу в возможности получать статистику в разрезе "готовности продукции по участкам". Если можно так выразиться. Причём в данном случае абсолютно всё равно в чём мерить. В штуках, в тоннах, в метрах...
Причём мне интересно это не только в плане измерения объёма, но и в плане автоматизации получения списка, что движется с участка на участок. В том числе. Тоже нужная задача. И можно её заодно порешать, как видится.

Концептуально да, можно сделать, наверное, и такое.
Просто, если делать, то надо ещё подумать в разрезе некоторых смежных вопросов. Чтобы потом не плодить ещё похожие режимы и не переделывать.

Что же касается концептуально вопроса нужности/ненужности, то я, если позволите, тоже чуть-чуть поучаствую.
Тут мне кажется вот в чем ещё дело. У Дмитрия производство выстроено и работает как "поток". В нем все постоянно движется с тактом в 1 день (может, быстрее). То, что порезали, завтра сваривают. Пока это сваривают, режут под то, что дальше будут варить. Завтра то, что сейчас на сварке попадёт на покраску, а то, что сегодня резали, будут дальше сваривать. И так в потоке постоянно всё движется. То есть раз в день (а может и чаще) весь этот поток +- синхронно перемещается. С заготовки на сборку, со сборки на окраску, с окраски на склад.

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

Если же такого "потока" нет, то возникает как раз вопрос, тесно связанный с мотивацией.

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

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

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

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

Я лично вот так данный вопрос понял.
Может, не прав. Вполне допускаю. Тогда поправьте, пожалуйста, где я не прав.

P.S.
Поймите правильно, к деланию/неделанию режима/отчёта это всё это не имеет прямого отношения.
Делать/не делать, когда и за какие деньги указанный режим/отчёт - это вообще из другой оперы совсем вопрос.
А вышесказанное - личное мнение в рамках концептуального обсуждения проблематики вообще. Для самообразования, можно так сказать.
Отслеживание результатов выполнения работ на участках
хм...
Мнения представителей разных заводов разошлись... Он "обязательно нужно" до "абсолютно бесполезно, даже вредно".
Отслеживание результатов выполнения работ на участках
Ну, когда дело дойдет до этого, можно и обсудить... Когда будет что показать в каком-то виде хотя бы.
Пока на уровне общей идеи всё находится.
Отслеживание результатов выполнения работ на участках
Цитата
Клим Серебренников пишет:
Есть ли возможность включить в выходящее обновление?
Точно нет. Оно уже собрано. Заканчиваем тестирование. В него 100% уже больше ничего не добавится.

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

Все сложности, которые тут выше описаны (с параметрами и т.п.), они все из-за того, что вы не хотите, чтобы физически разные "щиты" были разной номенклатурой. Вы хотите, чтобы номенклатура в базе была одна "щит", а физически это были разные щиты.

Вообще, это идеологически не верно, с моей личной точки зрения. Чтобы не было путаницы, и всё было прозрачно и логично, номенклатурная позиция должна соответствовать конкретному объекту в реальном мире. И если 2 объекта разные, если они чем-то отличаются (комплектацией, порядком изготовления и т.п.), то это должны быть две разные номенклатурные позиции. Недавно кстати в соседней теме похожая тема обсуждалась.

Ну ладно…
Давайте рассмотрим, а что мы, собственно, экономим, не создавая разную номенклатуру «щит».
Карта заказа (коллекция), в любом случае есть. Что так, что так.
Операции (компоненты) что так, что так есть. Одни и те же, в том же количестве. Вся разница только лишь в том, где эти компоненты лежат. В коллекции «карта заказа», или в коллекции «технология щита». Но компоненты то точно такие же все есть всё равно. И в том, и в другом случае. Включая их параметры и связанные объекты. Задания все точно так же создаются на основе этих компонентов. Точно такие же. Со всеми параметрами, связями, содержимым и т.п.
То есть, итого, во всей этой пирамиде объектов (компоненты, параметры, связанные объекты, задания и т.д.) разница только в одну номенклатурную позицию и одну коллекцию. И всё!
А всё остальное то что так, что эдак, создаётся всё одно и то же!
То есть 99% мы все равно хоть так, хоть эдак создаём. А 1% зачем-то упорно экономим, создавая себе сложности дополнительные. А зачем?

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

Сложно создавать много номенклатуры?
Ну, во-первых, вы и так всё равно каждый раз создаёте. Большую часть из всего: операции, комплектацию. Что так, что эдак. Тут то ничего не меняется. Только одну номенклатурную позицию ещё плюс добавить.
Во-вторых, если они действительно эти щиты так похожи друг на друга, как вы говорите, и отличаются только чуть-чуть, то это значит, что можно, судя по всему, применить «генератор». Чтобы он либо вообще автоматически всё заполнял по новым изделиям сам, либо по крайней мере, создавал сам новую номенклатуру и на 90+% заполненную технологию с операциями, основной комплектацией и т.п., которую потом уже вручную подправлять с учётом конкретного случая. Т.е. технически сложности не представляет расплодить щиты, чтобы получался каждый раз «точно такой же, но другой», с минимальными правками. Ещё быстрее и проще, чем вы сейчас делаете, мне кажется, можно сделать при отдельной номенклатуре на каждый новый «щит».

Ещё «генератор» удобен в этом плане тем, что он сам перед тем, как создавать новое изделие, ищет в базе, нет ли уже ранее сгенерированого с точно такими же параметрами. И если есть, то говорит об этом. То есть можно не искать в базе, был ли уже точно такой же «Щит», к примеру, или нет. Просто каждый раз запускать «генератор» и вводить нужные параметры. Если был уже точно такой, то он найдёт и скажет. Если нет – новый сделает.

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

Несколько примеров из жизни про «много номенклатуры»:

Два года назад я запустил VOGBIT на предприятии, которое изготавливает приборы отопления. Нюанс там в том, что всего есть, по-моему, 11 моделей приборов у них. Не считая совсем уж нестандартных (которые тоже бывают). Но прибор каждой модели может иметь 3-5 вариантов высоты и 3-5 вариантов ширины. А длина может быть практически любой от 500 мм до 5000 мм. Какой закажут, такой и сделают.
Плюс у некоторых моделей может быть разный материал корпуса. Плюс может отличаться у некоторых моделей комплектация. Плюс разные цветовые решения могут быть. Разные по цвету и конструкции декоративные решётки могут быть. Кроме того, от размеров прибора (длины, ширины, высоты) зависит, какой теплообменник в него ставить (а теплообменники тоже изготавливаются) – сколько труб, как расположены, как и чем между собой соединены, сколько и каких ламелей в теплообменнике (это, кстати, ещё зависит от того, есть или нет в комплектации прибора вентилятор).
В общем, сочетаний очень много.
Каждый день поступают заказы новые. Иногда не очень много, иногда много. Но точно не один. В заказе может быть одно наименование прибора, а может быть 10 и больше. И все разные.

Что мы сделали:
Настроили в «генераторе» шаблоны под все модели и варианты.

Как работает:
Девушка менеджер получает заказ. Там список приборов с параметрами и количеством.
Открывает VOGBIT, выбирает модель, запускает «Генератор», вводит параметры. Если точно такой прибор уже был, то программа ей об этом говорит. Если нет, то сразу его создаёт новый в базе, и всё, что нужно автоматом заполняет. Остаётся только название правильно вписать.
Создаёт карту заказа, вставляет туда нужные приборы, на всё про всё – 5 минут. Ну, может, 10…
Дальше всё готово, начальник производства уже может, в принципе, выдавать задания на посты по этому заказу. Что и делает. С учётом текущей загрузки, конечно.

Посмотрел статистику по копии базы одной из недавних.
В ней конечных изделий на сегодня – 9 289 наименований. Разных.
И ничего. Всё отлично работает, все довольны.

И это ещё «пол беды», что называется.
Можно посмотреть на изготовителей строительных металлоконструкций. Там вообще каждый заказ – новая номенклатура. Всегда. По определению.
Они никогда не будут искать какую-то аналогичную по размерам пластину из другого заказа, чтобы её использовать. Они вообще всегда рассматривают новый заказ, как полностью новое изделие (что, в общем то, так по сути и есть у них).
Один заказ в данной области – это от сотни до нескольких тысяч может быть разных изделий (отправочных марок, как они их называют).
Каждое изделие (отправочная марка) состоит из деталей. От одной-двух до где-нибудь 80-ти наименований (деталей) может быть. В одном изделии (марке).
В рамках одного заказа определённая повторяемость деталей есть (встречаются почти одинаковые марки, в которых детали повторяются одни и те же). Между заказами детали никогда не пересекаются.
В месяц может несколько заказов проходить разных.
И каждый раз это новые марки (изделия), новые детали под них.

И ничего… Живут люди. Работают. Номенклатура действительно размножается.
Но это, как показывает опыт, не смертельно. Некоторые уже лет 7 работают в VOGBIT и вполне довольны.
Иногда подчищают базу. Раз в несколько лет. Может, раз в год.

Резюме:
Само по себе наличие сотен или тысяч номенклатурных позиций не смертельно. Номенклатуру можно рассортировать и разложить удобным образом. Можно часть спрятать. Вот если счёт на миллионы пойдёт, вот это, наверно, уже создаст определённые технические проблемы. Но пока за 10 лет мы не встречали такого на практике ни разу.
В то время, как соблюдение принципа «разные физически изделия – разная номенклатура» дает много очевидных плюсов. Тогда как несоблюдение его создаёт очевидные сложности.
Единичное производство. Ввод трудоемкости.
Здравствуйте,
Цитата
Alex-220781 пишет:
если задавать Тшт. в минутах - задания не создаются
Да. Так и должно быть.

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

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

В 99,99% случаев люди стали вводить трудоёмкость через "технология подробно". В связи с этим поддержку ввода трудоёмкости через параметр "Тшт, мин" убрали. Потому что никто фактически этим не пользовался, в то время как при создании заданий всё равно, каждый раз, проверялось наличие параметра "Тшт, мин" на предмет нет ли там случайно значения, которое нужно пересчитать. Лишние действия - лишнее время. Убрали. Оставили, что трудоёмкость "внутри" программы задаётся всегда единообразно, в часах. Ибо через тот интерфейс, которым все в 99,99% пользуются, не важно в чём вводить, само пересчитавается в обе стороны.

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

Если же всё таки задаться именно такой целью, то да. Так и делать.
ТП не создавать. Добавить операции прямо в карту заказа.
Через "редактирование параметров" поставить операциям "Тшт".
Да. Не супер удобно. Но вполне. И главное, можно же.
Но и случай, всё таки, ИСКЛЮЧИТЕЛЬНО редкий, когда так делается. Поэтому не думаю, что стоит создавать ещё один какой-то специальный интерфейс, чтобы только было поудобнее конкретно в этом случае.

Дальше работает всё нормально. Я проверил. Задания создаются, отмечаются, всё правильно по ним получается.
Одна номенклатура детали на разные материалы, Можно ли сделать чтобы не плодить номенклатуру создать 1 изделие (деталь) и прописать название например "Решетка вентиляционнная" , и указать что она может быть выполнена из разных материалов?
Цитата
Наиль Богапов пишет:
Но если каждое по отдельности забивать
Забивать все возможные сочетания смысла нет. Только те, которые реально сейчас используются (делаете, есть на складе и т.п.).

Цитата
Наиль Богапов пишет:
появляется большой список
Ну и что?

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

Рассмотрим плюсы и минусы.
Плюс один и довольно сомнительный: меньше номенклатуры. Но в чём тут великий плюс?
Теперь минусы:
Когда вы запускаете «решётки» такие в производство, как вы объясните производству, какие именно им делать? Железные? Пластиковые? Белые? Серые?
То есть каждый раз придётся писать комментарии. А не просто добавлять в заказ номенклатуру.
И отчёты все настраивать с упором именно на этот комментарий.

Ок. Комментарий написали, задание выдали. Надо материл со склада брать. Автоматически программа вам никак не определит, какой материал в этом случае вы хотите взять. С её точки зрения это просто некая «общая решётка». Из любого материала. Номенклатура то всегда она.
То есть каждый раз через замены нужно будет заменять «условный» материал, на тот, который реально выдать. Вручную. Не перепутать.

Дальше после того, как сделали «решётки» для верности нужно бы при сдаче на склад приписать им ещё раз комментарий. Для складской карточки. Что это именно за решётки то вы положили на склад. Железные? Пластиковые? Какого цвета?
Т.к. когда они уже лежат на складе, далеко не всегда видно что-то по истории их изготовления. Видно просто, что «решётка» и кол-во. Поэтому чтобы хотя бы визуально понять, что это за «решетка», нужен какой-то комментарий. Т.е. при сдаче из производства на склад придётся опять же, каждый раз (не забыть, не перепутать) приписывать комментарий, что именно сдаём. Ибо из названия номенклатуры непонятно – «решётка» и «решётка».

Идём далее…
Смотрим остатки на складе готовых. Там написано: «решётка» 100 шт. А каких? Железных? Пластмассовых? Чёрных? Белых? Пока кнопку «подробно» не нажмёшь – не поймёшь.

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

То есть сделать то одну номенклатуру, обозначающую разные «решётки» можно. Но этим самым вы создаёте сами себе кучу работы и головной боли потом с идентификацией во всех местах и случаях, что же это на самом деле то за «решётки»? Они ж все одинаково называются. Только можно идентифицировать (отличить) по каким-то дополнительным признакам: комментарии, параметры. А значит их надо вводить, смотреть, вручную выбирать из какой именно партии взять, и т.д.
Возможностей что-то перепутать или забыть – море.

Если же сделать белую железную, серую железную, белую пластиковую и серую пластиковую решётки разными номенклатурами, то все проблемы идентификации исчезают автоматом во всех местах.
Даёте задание производству – всё понятно, какие делать.
Материалы – программа вам сама посчитает и ЛЗК сделает именно на те, которые нужны. Ничего не надо вручную отслеживать, выбирать.
На складе – чётко понятно, какие там решётки лежат и сколько.
При отгрузке тоже все просто. И не обязательно SELECT всегда использовать. FIFO тоже отлично будет работать. То есть проще всё намного.

Единственный момент – если покупатель заказал «не важно какие решётки». Но в этом случае как раз и можно завести плюс ещё одну номенклатуру «не важно какая решётка» и у неё в «аналогах» прописать все 4 наших варианта (или сколько их там есть).
И всё решается легко и красиво, вроде бы.
Если заказал человек конкретные решётки, то ставите в заявку, какие ему нужны, по ним видите дефицит, их отгружаете. Без всяких танцев с бубном.

Если заказал «все равно какие», то ставите в заявку свою условную позицию «не важно какая решётка» и кол-во.
Она по определению всегда будет в дефиците (рис.1). Потому что «не важно каких решёток» никогда не бывает на складе. А есть конкретные. И это даже хорошо. Это индикатор, что надо вместо «просто решётки» выбрать из того, что есть, что будем в итоге отдавать. Сколько каких.
Дальше, через «замены» выбираете каких сколько отгрузите решёток, исходя из свободных остатков (рис.2), и отгружаете. Опять же, без каких-либо танцев с бубном.
По-моему, это намного проще и надёжнее получится (такая схема при заказе «не важно каких решёток») чем иметь одну номенклатурную позицию и потом при отгрузке уже при оформлении «расхода» через партии и складские карточки сидеть отмечать, что же на самом деле отдали то.


Какие минусы?
Да больше номенклатуры. Ну и что, с другой стороны. Зато сколько головной боли с идентификацией и отслеживанием автоматически устраняется сразу.
А что номенклатура?
Ну больше и больше, ну и что?
Разложите по папкам. По категориям разным, наконец.
Если вариантов не очень много, то сделайте нужные копированием одного из другого.
Если вариантов очень много (например, эти решётки могут быть от 50х50, до 500х500 мм с шагом 1мм по любой стороне независимо (например, 367х182 и т.п.) + из 3-х материалов + 3 разных цвета) - тоже не страшно. Прописать один раз шаблон в «генераторе», и если в базе подходящей нет решётки (никогда в таком сочетании параметров её не делали ещё), «генератор» вам её за 5 секунд сам создаст новую, и всё заполнит. В следующий раз будет.


В общем, схема с одной номенклатурой возможна. Но я вижу в ней много потенциальных проблем и не вижу плюсов. Плюс «не плодить номенклатуру», мягко говоря, не очевидный в данном конкретном случае.
Мне кажется, что логичнее придерживаться правила, что есть физически изделия разные, то нужно, чтобы и номенклатура соответствовала им в базе разная.

P.S.
Приведу другой пример, когда реально имеет смысл «не плодить номенклатуру».
Был у нас клиент один. Делал электронные устройства. В них есть компоненты. Например, сопротивление 1 кОм. Так вот эти сопротивления делают куча разных контор. Наши, китайцы, всевозможные производители… С виду – цилиндрик и цилиндрик. С двумя ножками. Маркировка немного разная, цвет где краснее, где-то коричневее. Но так резистор 1 кОм, он и есть резистор 1кОм.
Вот тут, чтобы не плодить в базе 100 таких «резисторов 1 кОм» от разных производителей, которые все получается друга на друга взаимозаменяемые, люди завели в базе одну номенклатуру «резистор 1 кОм». А уже на склад приходовали когда, приписывали к партии, что за производитель.
Хранились они у них реально отдельно на складе. Каждая партия резисторов в своей коробочке. Подписанная. Потому что нужно было отслеживать потом, что именно в какой прибор поставили. Что за компоненты, в т.ч. с учётом партии поставки и производителя. Потому сама процедура оформления расхода со склада методом SELECT (с ручным выбором, сколько из какой партии выдали) была для них абсолютно понятна и естественна.
И всё работало.
Но, по-моему, это не то же самое совсем, что ваш случай с «решётками»
1.png (110.43 КБ) [ Скачать ]
2.png (41.98 КБ) [ Скачать ]
Страницы: 1 2 3 4 5 6 7 8 9 10 11 ... 442 След.