Сторонние организации

Здравствуйте,
Я бы, наверное, сделал так:

Завёл 2 номенклатуры: заготовка (как она приходит изначально) и готовая деталь (что получается после обработки на другом предприятии).
При покупке заготовок приходуем их на склад.
Дальше можно пойти двумя путями.

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

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

И в том и в другом случае основные задачи решаются. Сколько на складе есть заготовок и готовых деталей – известно. Сколько и когда отдали на обработку на сторону – известно.
Какой вариант выбрать? Любой. Какой больше понравится.

Я бы обошёлся вообще без «перемещений».
Посудите сами:
У вас склад. На нём изначально ничего не было. Потом пришли заготовки (приход). Потом часть заготовок забрали и увезли (расход). Потом пришли детали (приход).
Никакого перемещения, один приход и расход сплошной

Не обязательно. Можно вручную «требование» составить. Без всяких техпроцессов.
Нет. Не происходят. Это, по моему, совершенно лишнее.

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

Так вот вопрос – сколько у вас на предприятии таких отдельных друг от друга складов? Что на них хранится? Происходят ли между этим складами какие-либо прямые перемещения чего-либо? В каких случаях и зачем это делается?

По поводу полуфабрикатов, автоматических перемещений и т.п.

Моё личное мнение, что такой подход не самый лучший (представить производство, как последовательное перемещение неких "полуфабрикатов" с места на место). И многие решения, на этом принципе построенные, происходят, ИМХО, от недостаточного понимания сути производственного процесса (хотя не спорю, есть некоторые случаи, где так и надо, но это далеко не все случаи).

Перемещение – это хорошо в торговле.
Есть магазин. Купили коробку, коробка на складе. Взяли коробку со склада, поставили в торговом зале – перемещение. Продали коробку – расход.

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

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

А так вопрос, конечно, сродни религиозному. Тут уж кто как жизнь видит

В продолжение…

Что касается работы со сторонними организациями, то какого-то специального отдельного инструмента в VOGBIT сейчас нет, но можно обойтись, наверное, и существующими.
Как я выше писал, можно попробовать представить в двух вариантах:

1. Как заказ на производство.
Заказ на получение определённого количества изделий имеется. Потребность в заготовках для этого заказа тоже имеется. На выходе получаются желаемые готовые детали, которые попадают на склад. В принципе, получается по смыслу то же самое что и простой производственный заказ, только что работы делаются по нему не своими силами. Соответственно, как-то планировать и учитывать эти работы особого смысла нет, достаточно на уровне "сделано / не сделано" + выдача материала, поступление готовых деталей. А для этого как раз есть "минимальный" уровень учёта. Прямо специально практически под такие задачи "заточенный", можно сказать.

2. Как заказ на покупку. Тоже, в принципе, вариант. Заявка на получение от контрагента определённого количества деталей есть? - Есть. Далее по этой заявке искомые детали приходят на склад? Да, приходят. Можно и так, в принципе, представить.

Нужна ли плюс к этому какая-то дополнительная специальная функциональность для отражения в программе именно взаимоотношений со сторонними организациями? Не знаю пока...
Добавление дополнительных функций неизбежно отягощает программу.
А будет ли это чем-то лучше, чем выше озвученные варианты? Надо посмотреть, чем они плохи, для начала...

Нет. Не существует. Перемещение со счёта на счёт в бухгалтерии - это не есть реальное движение.

"Перемещение" было бы в том случае, если бы вы взяли 3 листа стали на складе металла, перевезли их на склад готовой продукции и там в угол сложили. В виде тех же самых трёх листов стали. Только теперь эти 3 листа лежат на складе ГП. Вот это было бы перемещение. А в вашем примере никакого перемещения нет.

Склад металла выдал листы. В результате работы участка листы были переработаны. Они исчезли. Канули в небытие, как вы говорите. И это так и есть. Зато появились детали.
Листов больше нет! Физически. Не существует больше этих листов металла в виде целого листа размером 2.5 х 6 или сколько там. Нет смысла их никуда виртуально перемещать. Потому что в виде именно листа этот металл больше не существует! Нет больше плоского прямоугольника 2 на 6 метров. Просто нет. Его порезали на много частей, погнули, просверлили, покрасили и т.п.  

В результате получились детали. Деталь - это уже совсем не лист. Это совершенно другой объект реального мира. И в программе это уже другая номенклатура. Детали сдали на склад готовой продукции. Они там лежат пока не понадобились.

Вот и всё!
Лист потратили. Детали пришли на склад. Нет никакого перемещения!

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


Просто попробуйте принять другую логику. Логику реального мира, а не виртуального. Отличную от бухгалтерии и программ для неё написанных.
Логику, что производство есть процесс потребления одних объектов (ресурсов) и получения из них других объектов (изделий).
Это как в компьютерной игре: собрали золото, руду, газ или что там ещё - потратили их, получили танк (строение и т.п.). Золота больше нет. Но зато есть танк...

Точно так же и тут. Потратили металл - получили детали. Потратили детали и покупные компоненты - получили изделие.
Механизм чудесного превращения - производственный заказ. Потратили одно, получили другое.
Вот и всё.

А перемещение - это когда взяли из одного места коробку и в другое место эту коробку перенесли. Ту же самую. Ничего с ней не стало. Просто стояла в комнате №1, а стала стоять в комнате №2. Та же самая коробка. Вот это - перемещение. Такое тоже бывает иногда (особенно на крупных предприятиях). Но в ваших примерах ничего такого нет.

Ну вот… Приехали…

Всё можно. Вопрос желания и усилий, которые вы готовы потратить. Вопрос – а нужно ли? Зачем вам в таком случае VOGBIT для этого?

Представьте, что вы купили автомобиль.
И говорите: «А можно без двигателя? Вытащить его. Остальное пусть, как есть, но двигатель убрать.»

Можно… В принципе
Но придётся толкать вручную. И делать это будет тяжело, нудно и неудобно. И ехать будет медленно.
Фары, приборы, радио – работать толком не будут. Электричества то нет.
Рулить будет тяжело и неудобно. Так же, как и тормозить. Гидравлика то тоже не работает.
А так то можно…

Дальше видим, что получилось то совсем не то, что мы ожидали. В рекламе и в автосалоне было то совсем всё по-другому. Красиво, быстро, удобно. А у нас получилось медленно, неудобно, почти ничего не работает. Начинаем исправлять ситуацию путём «доработки под свою специфику»:

Чтобы работала гидравлика, ставим в багажник генератор и насос. Проводим туда трубы от гидравлической системы, через вентиль соединяем. Заводим генератор, открываем вентиль – ура! Рулится и тормозит теперь более-менее хорошо. Правда появились дополнительные трубки. И перед тем как ехать, надо выйти, открыть багажник, завести генератор и открыть вентиль. После остановки выйти открыть багажник, закрыть вентиль, заглушить генератор. Плюс не забываем оплатить труд механиков, которые вся эту систему на заказ сгородили.

Далее решаем проблемы с электричеством. Заполняем все свободные места аккумуляторами и соединяем их с бортовой сетью. Теперь фары горят и радио работает. Только аккумуляторы от этого быстро садятся. И надо регулярно вытаскивать их (тяжёлые…) и тащить на зарядку (долго…). И потом обратно. И проводов лишних появилось. Но зато фары снова горят и радио работает.

Толкать при этом всё также нужно вручную...

А теперь, внимание, вопрос – а зачем двигатель то было вытаскивать?

Вот так и тут.

Для VOGBIT та часть, что касается производства – что двигатель для автомобиля. Можно и без него обойтись, но тогда и большинство других возможностей так или иначе отвалится или будет сильно ограничено.

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

Результат – см. выше. «Решение» обрастает совершенно чуждыми ему изначально фрагментами и довесками, но лучше оригинала оно от этого не работает. Точнее, почти совсем не работает. Функции какие-то, вроде, выполняются, а общий эффект непонятно в чём. Лучше ничего не становится. Только сложнее, запутаннее и т.д. Но всё равно «стоит». Не едет…

Теперь возвращаемся к сути вопроса. Можно ли в VOGBIT, описывая производство, производственный модуль вообще «выкинуть» из бизнес-процесса, а вместо этого перемещать материалы со склада на склад?

Можно. Но будет неудобно. И кроме собственно «остатков» по этим складам ничего от этого вы не добьётесь. Про остальные функции можно будет позабыть с таким подходом.

Поэтому я и спросил выше  - а зачем вам вообще в таком раскладе VOGBIT?

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

Вот пример, как добираться. По шагам. С инструкцией.

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

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

Здравствуйте,
Да. Естественно.

Вопрос правильного составления техпроцессов и производственных заказов.
В принципе, неоднократно обсуждалось на форуме, но, наверное, местах в 5 разных, если не больше.

Начать можно с того, что посмотреть вот эти ролики. Рекомендую внимательно посмотреть их все:

Ролик 1
Ролик 2
Ролик 3

Посмотрите внимательно, что именно вы делаете.
Когда вы составляете заказ на производство, вы включаете в него что? - Детали.

Т.е. вы создаёте список, что нужно изготовить (производственный заказ).
В этом списке у вас детали.

Нажимая "расчёт потребности" вы спрашиваете программу: "А что мне нужно, чтобы изготовить мои позиции по этому списку?".

Что нужно, чтобы изготовить детали? - Металл.

Логично? - Безусловно. И именно это вы и видите. Как говориться, какой вопрос, такой и ответ.

Если вы хотите увидеть какие детали нужны, чтобы изготовить изделие, то нужно в заказ на производство вставлять само изделие, а не детали для него.
А потом уже смотреть, есть детали или нет, сколько каких ещё реально нужно и т.п. (ролик).

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

И всё будет.

Посмотрите внимательно вот этот ролик (где-то с 04:40 примерно и дальше). Обратите внимание, что я вставляю в заказ на производство на данном этапе только само изделие, но никак не детали для него.

А вот как правильно должна быть написана технология.

Предвосхищая возможные вопросы про комплектацию - сразу и почему должно быть именно так.

Попробую завести учетные карточки, может по этой причине программа идет к корневому материалу...

Вот такая структура у меня сейчас получилась

Алексей,

В сообщении №16 я всё объяснил. И даже выделил курсивом ключевые места и слова.

Повторяю ещё раз.

Посмотрите внимательно, что именно вы делаете.
Вы создаёте в программе заказ НА ИЗГОТОВЛЕНИЕ ДЕТАЛЕЙ.
Откройте "график производства". ЧТО у вас там?
Ответ - у вас там ДЕТАЛИ!

Вы сами говорите программе "НУЖНО СДЕЛАТЬ ДЕТАЛИ". Что вы от неё ожидаете в ответ на вопрос "что нужно для того, чтобы выполнить этот заказ?".

Логично, что программа отвечает вам, что для того. чтобы СДЕЛАТЬ ДЕТАЛИ, нужен металл.
Есть возражения? Что-то в этом не так?

ЗАЧЕМ вы вставляете ДЕТАЛИ в заказ на ПРОИЗВОДСТВО?
Заказ на производство - это список того, что нужно ИЗГОТОВИТЬ.
Если вы НЕ ХОТИТЕ делать детали, а хотите взять готовые со склада, то ЗАЧЕМ вы дайте задание ИЗГОТАВЛИВАТЬ ДЕТАЛИ? (вставляете детали в производственный заказ)

В этом вся причина.

Все дальнейшие изыскания - какое-то непонятное дерево с вставлением в него материалов и т.п. - это всё ерунда. Карточки складские тоже ни на что ни влияют в данном случае.

Попробуйте создать производственный заказ из одной строчки. Само изделие в нужном количестве. И ВСЁ! Не нужно никаких спец. деревьев. Не нужно ничего.

Просто НЕ ВСТАВЛЯТЕ в этот заказ детали этого изделия.

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

Зачем так сложно то всё?

Почему бы просто не:
- создать заказ (в поле "заполнить" выбрать "вручную");
- перетащить в него изделие из справочника, указать кол-во.

И всё!

Расчёт комплектации окно на рисунке.

Зачем вам в данном случае оно вообще нужно?

Читаем документацию:
Оно вам нужно?

только в тот момент, когда вы нажимаете кнопку "построить список компонентов". Т.е. только тогда, когда вы сами же и говорите ей "разложить изделие на составляющие".

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

Другое дело, что предполагается некоторая осмысленность выполняемых действий.
Построить список - не самоцель. Желательно понимать, для чего это делаешь и смысл дальнейших действий с этим списком.

Вы делаете (предлагаете деталь) следующее:
- взять модуль, который раскладывает изделие на составляющие;
- получить с его помощью список всех составляющих изделия, включая его самого и всё, что в него входит;
- удалить из полученного списка всё, кроме самого изделия.

Вопрос - а зачем все эти действия?? в чём смысл?

Почему не сделать так:
1. Создать заказ.
2. Добавить в него вручную изделие из справочника. Указать количество.

И всё. Готово.

Что может быть проще? Мышкой из справочника изделие в заказ перетащить, ко-во проставить.
Без всяких "расчётов комплектации" и т.п.
Просто сказать "хочу сделать N изделий АБВГД". Т.е. создать заказ на производство, вставить в него вручную одну строчку. И всё!

Константин, а почему у меня режим "Обороты" выдает ошибку
- Не найден вид связи: UID = LT_Return