Пропадает номенклатура из расчетов потребности

Как я понял - если номенклатура присутствует непосредственно в карте заказа, то, если она входит в сборки - не считается

Добрый день! Правильно я понимаю: если "Деталь1" в сборке (технологическом процессе сборке) - то режим потребности покажет, что нужна "Деталь1", а не "материал" из которого она сделана. Если деталь непосредственно в технологической карте, то потребность выдаст "материал", из которого деталь сделана.


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

Изображение

Про карту заказа расскажу в другой теме - почему я так делаю.
А вот что делать с этим

Ненадолго выпал, продолжаем разговор...

В общем, работает в этом месте так:
"Расчёт потребности" задуман, в первую очередь, чтобы встать на заказ (или часть его позиций выделить) и получить список, что нужно со склада получать, чтобы изготовить этот заказ (выбранные изделия).
Т.е. программа по каждой выбранной позиции из графика производства (или по всем в заказе) выбирает по технологии, что для неё нужно.
Касательно комплектующих собственного изготовления, которые нужны для сборки, тут следующая логика:
Если в том же самом производственном заказе (карте заказа) есть в качестве изготавливаемых позиций те же самые детали, что и указаны в комплектации к сборке, то эти позиции из «расчёта потребности» исключаются. Т.к. считается, что это те самые детали и есть, которые на сборку нужны. Их сделают и сразу на сборку отдадут, минуя склад. Соответственно, в ЛЗК они не должны попасть, т.к. выдавать  их со склада не нужно будет.
Количество деталей в карте заказа и в комплектации сборочной операции и соответствие одного другому в данном случае не проверяется никак – на откуп пользователя.

Почему именно так было сделано:
Для скорости работы, в первую очередь.
Потому что, если детали передаются сразу, минуя склад, с механики на сборку (случай единичного производства, обычно), то в большинстве случаев при такой системе работы карта заказа заполняется через «расчёт комплектации» и все детали из спецификации в нужном количестве всё равно в неё сами попадут. И ничего проверять дополнительно не нужно. В то время как наворачивание дополнительных проверок соответствия количества резко усложнит сам расчёт и, соответственно, он будет дольше работать. А мы, в своё время, отчаянно боролись за скорость в этом месте, и немало в этом приуспели, кстати (в каких-то старых версиях, помню, минут по 20 этот «расчёт потребности» тупил, сейчас секунды на тех же примерно объёмах). В итоге решили, что не нужно тут дополнительно проверять кол-во в этом случае. Ибо реально нужно это раз из 100, наверное, даже реже. А тормозить то, если проверять, начнёт у всех и всегда…. К тому же, можно просто по-другому немного скомпоновать карты заказов (как изначально и задумывалось делать), и проблемы сама исчезнет, как класс.  

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

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

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

Да, можно.

Вот так: https://youtu.be/HJezvFPm6mc

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

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

Добрый день! Файлы получил. Нет инструкции по настройке.  

Добрый день!
Настроил программу. Потребность считает нормально (ошибок пока не выявил). А вот себестоимость считает по другому.

Не совсем понял, в чем сложности и почему задвоится всё?

На данный момент есть два алгоритма:

1) Если "деталь" есть есть в технологии "изделия" и в карте заказа, то "деталь" считается только в карте заказа. Это, скорее всего, необходимо там, где "деталь" необходимо еще изготовить, для того чтобы применить в "изделии". В данном случае необходимо следить за количеством "деталей" в карте заказа.

2) Если "деталь" есть в технологии "изделия" и в карте заказа, то "деталь" считается в обоих случаях. Это больше подходит, когда "деталь" приобретается.
Под "деталью" имеется ввиду все что угодно: провод, болты, листы металла, краска и прочее.

Вот я сейчас испытываю второй метод. И получается, что "Себестоимость" дает не верные результаты, причем, ошибка может быть значительной.

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

Или я чего-то не понимаю.
 

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

И не понятно, почему Себестоимость можно настроить на учет комплектующих в техпроцессах и в составе заказа, а себестоимость нет.

Правильно. И это описывается в программе Техпроцессом.
"Заказ на производство" - это по смыслу список изделий которые нужно изготовить.
Техпроцесс изделия - это описание как данное конкретное изделие изготавливается (операции) и из чего (какие материалы и комплектующие для его изготовления требуются). Это в общем случае. На практике, к зависимости от того, как именно, используется программа, какая-то половина из этого ("как" или "из чего") может и отсутствовать в базе, если она не нужна в данном конкретном случае. Это допускается. А могут обе присутствовать, если нужны обе.

Опять же правильно.
В программе поэтому, можно так сказать, "заказ в общем" (если искусственно ввести такое понятие) состоит в общем виде из двух сущностей:
- список того, что нужно изготовить - "производственный заказ" он же "заказ на производство"
- список того, что нужно взять со склада - запрос на склад он же "ЛЗК"

И первое и второе, в общем случае (в зависимости от ситуации) может сочетаться как "много ко много".
То есть:
- может быть 1 заказ на производство (что делать), к нему 1 ЛЗК (что для этого нужно).
- может быть много заказов отдельных на производство и на них на всех одна ЛЗК общая.
- может быть 1 заказ на производство и к нему много отдельных ЛЗК (например, на каждый прибор в заказе отдельно).
Можно хоть как сделать в программе. В зависимости от ситуации.

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

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

Это (выше) - базовые сущности (правила), на которых построена логика программы. Уже написанная.
Крайне желательно их придерживаться и не придумывать свои сущности и правила.
Программа достаточно гибкая (местами даже слишком, наверное, получилось). И позволяет эти "правила" при желании и нарушить. И ввести не так, как задумано изначально.
Но я бы очень не рекомендовал этого делать. Потому что существующая логика работы модулей программы заточена под описанные выше базовые "правила игры". И если вместо них придумать какие-то другие, свои, то она их просто не знает.

Добрый день, почему у нас нет выпадающего списка как в видео? Как в нашей версии сделать тогда несколько карт на один заказ?