Новая версия VOGBIT 20.5 - Новая платформа: быстрее, надёжнее, удобнее. Новая подсистема управления приоритетами в производстве. Новые возможности для участков ЧПУ. Улучшенные «цеховые терминалы». Новые возможности для совместной работы менеджеров, инженеров и производства при изготовлении уникальной продукции под заказ. И многое другое…

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

Экспорт/Импорт данных - Экспорт импорт данных
Илья: Кто нибудь сталкивался с проблемой экспорта/импорта баз данных с localDB на сетевой SQL?
Как лучше описать технологию? - Состав и технология
Serge.v.astapov: Добрый день! Просьба подсказать как лучше оформить техпроцесс. Исходная проблема такая - мы производим контроллеры с разной частотой радиоканала. Грубо говоря, номенклатура повторяется для каждой частоты. Тех процессы одинаковые за исключением одн ...
Свяванные объекты - Прочее
Константин Чилингаров: Нужно для этого пользователя /support/474/#763_1232331032 настроить доступные "зависимые окна" (зайти под этим пользователем и настроить). Форму нужно выбрать: Csdn.Vogbit.Mail.LinkedObjectsForm  Связанные объекты (рис.1). Дальше выб ...
Последовательность операций - Производство
Алексей Пономарев: Здравствуйте. Работаем на максимальном уровне. В графике производства делаем сортировку по операциям. В производстве детали несколько операций, штамповка, гибка, гальваника. Деталь находится на стадии планирования. В операциях гальваника деталь появл ...
Пустой бланк - Демо версия
Илья: Перепутал шаблоны. Да все работает. Спасибо
Установка программы для терминалов. - Установка
Константин Чилингаров: RFID нужен для авторизации. Чтобы подошёл рабочий к терминалу, и ему не нужно было ничего вводить (типа Имя, Пароль), ничего выбирать. Просто приложил свой "пропуск" (брелок, браслет), терминал понял, что это "Иванов" пришёл, и в ...
Очень долго открываются обороты - Прочее
Константин Чилингаров: Здравствуйте, Какая версия программы? Базу (копию) можете дать посмотреть?
Прошу помощи в установке - Установка
Владимир Белов: Ок, спасибо, проблема стала понятна.
Аналоги в материалах - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Посмотрим. Там, помню, есть какая-то заморочка с единицами изменения и "заявками на закупку", когда этих единиц много разных используется для одной и той же номенклатуры. Как будет время, понажимаю там кнопки, посмотрю, насколько работае ...
Создание, удаление, и создание вновь заданий - Производство
Константин Чилингаров: 19032 Илья написал: Не удается создать задание на среднем уровне /support/552/#_Toc400385408 Наиболее типичные причины . Сообщение с вашей картинки - первое по списку. 19032 Илья написал: Это может быть связано с отсутствием норм времени? ...
Сортировки в сменном задании - Интерфейс программы
Алексей Батраков: Спасибо, будем очень благодарны. 
Ошибка при создании отчета "Заказ на производство (цвет)" - Ошибки в работе
Алексей Батраков: Работает, спасибо
Сортировка производственных заказов - Производство
Константин Чилингаров: Понятно. Это из-за того, что в смене есть "внеплановое" задание. Это оно не может "передвинуться". "Нормальные" задания, связанные с какой-нибудь деталью (позицией заказа на производство), сдвигаются, раздвигаются, п ...
Проблема со справочником "Номенклатура" - Общие вопросы
Константин Чилингаров: Предупреждение! [B Нарушение /forum/rules/ правил форума , п.6.[/B ответ /forum/messages/forum39/topic2591/message15964/2591-sortirovka-papok-po-alfavitu#message15964 здесь
Сортировка папок по алфавиту - Интерфейс программы
Константин Чилингаров: В этой версии по умолчанию отключено, как редко используемая функция. Поскольку можно самому расставлять папки в любом удобном порядке, чем, в основном, все и пользуются. Кроме того, в 20.5 появилась возможность быстрого поиска папки по Ctrl+F. (ещ ...
Колонки Операция и Состояние - Производство
Константин Чилингаров: 19032 Илья написал: Цель- учесть наличие задела часто используемых комплектующих изготавливаемых своими силами. 19032 Илья написал: Из остатков металла наточили деталей и они лежат ждут следующего заказа. Нужно в таком случае оформить в про ...
Автоматический расчет количества материалов - Материалы, Комплектующие, Складской учёт
Илья: 13 Константин Чилингаров написал: Вы не поняли, мне кажется. Заносится один раз. В базу данных VOGBIT добавляется используемый материал: название (марка + сортамент) + вес погонного или квадратного метра соответственно (можно сразу заодно и ЕИ ...
Смена единиц измерения при выдаче со склада. - Интерфейс программы
Константин Чилингаров: Здравствуйте, Не очень понятно. Сейчас сделано наоборот - так, чтобы автоматом пересчитывалось для кладовщика (при выдаче со склада) в те единицы измерения, которые, собственно, кладовщик, сам и использует. То есть в те, в которых он учитывает то ...
Применяемость материалов - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Значит нужно будет потом как-нибудь сделать, как описано выше (сообщение #2). Запишем в общий список пожеланий.
Оформление прихода по заявке. - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Здравствуйте, Спасибо, возьмём на заметку. Пока пара моментов на тему: Если "поставщик" указан в "заявке", и "Склад" (получатель) выбран в ленте, то они сами подставляются по нажатии на "Создать приход". ...

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

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

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

Если вы добавите при тех же исходных данных в тот же заказ рядом со "сборкой" ещё "деталь 1", то получите в результате "расчёта потребности" другой результат.
Деталь 1 не нужна. Готовая. Т.к. то, что вы добавили её в состав заказа = вы сказали, что собираетесь её сделать. Сделаете и сразу соберёте из неё "сборку".
Но появится в результате в расчёте потребности материал, который нужен, чтобы сделать деталь 1. Условно говоря, "круг".

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


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

Цитата
Константин Чилингаров пишет:
Деталь 1 не нужна. Готовая. Т.к. то, что вы добавили её в состав заказа = вы сказали, что собираетесь её сделать. Сделаете и сразу соберёте из неё "сборку".
Но появится в результате в расчёте потребности материал, который нужен, чтобы сделать деталь 1. Условно говоря, "круг".

Но программа не может сама определить, для чего я вношу "Деталь1" в карту заказа отдельной строкой: для изготовления "сборки" или просто изготовить на склад (или просто как отдельная позиция заказа). И количество отдельных "Деталей1" и количество "Деталей1" для изготовления "сборки" вообще могут быть не связаны.
 
Применительно к моему случаю: у меня покупное изделие Изолятор ИО-10, он применяется в сборке "Сборные шины". И в конкретном случае требуется еще 3шт. для КСО393-14В. Так вот Потребность мне считает только 3шт., а те что в Сборных исключает из расчета. Если удаляю ИО-10 3шт., то считает, то что нужно для Сборных шин. А надо и то и другое.
 
Изображение
 
Думаю, начать нужно с того, что если у вас на рисунке "карта производственного заказа", то она изначально составлена неправильно.

1. В производственном заказе (карте заказа) вообще не должно быть покупных изделий. Производственный заказ - это список позиций, которые нужно изготовить.

2. Карта заказа имеет древрвидную структуру только в одном случае. В случае организации производства (выдача заданий, приёмка, оплата) методом "по комплектам". Что само по себе довольно редкое явление.
В большинстве случаев карта производственного заказа должна представлять из себя просто линейный список того, что нужно изготовить.

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

Цитата
ALEX-220781 пишет:
Но программа не может сама определить, для чего я вношу "Деталь1" в карту заказа отдельной строкой: для изготовления "сборки" или просто изготовить на склад (или просто как отдельная позиция заказа). И количество отдельных "Деталей1" и количество "Деталей1" для изготовления "сборки" вообще могут быть не связаны.
 
Вот сделал карту без покупных. Техпроцесс на "РВФЗ" включает в себя "Тягу", которую надо изготавливать. Вот если я в ТК оставляю только "РВФЗ" - потребность мне выдает, что нужно готовых "Тяг" - 12шт. Как только я добавляю в ТК "Тягу" -1шт. отдельной строкой (вот нужно мне изготовить ее, независимо от количества, требуемого для РВФЗ), потребность мне выдает материал только на изготовление одной "Тяги" - "Полоса 40х8". А то, что нужно еще 12 "Тяг", вообще никак не учитывается. На мой взгляд, это не правильно. Придется перепроверять, нет ли деталей, сборок, вложенных в другие техпроцессы.
 
Ненадолго выпал, продолжаем разговор...

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

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

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

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

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

Вот так: https://youtu.be/HJezvFPm6mc
 
Как будет себестоимость по заказу при этом считаться?
 
В текущем варианте "себестоимость" считает на одну "коллекцию". Т.е. будет считать на каждую карту по отдельности, по одной. В перспективе, можно допилить "себестоимость", наверно, чтобы она и по нескольким коллекциям сразу считала. Если нужно.
Пока никто просто не спрашивал особо в таком разрезе.
 
Цитата
Константин Чилингаров написал:
Также давно у нас где-то записана идея сделать «галочку» какую-нибудь в настройках, чтобы можно было её включить, и тем самым эту функцию "исключения деталей из расчёта потребности" (из ЛЗК, по сути) просто отключить. Чтобы всегда все комплектующие попадали в ЛЗК, даже если они в этом же заказе и делаются. На тот случай, когда в любом случае все детали сдаются сначала на склад. Обязательно.В принципе, идея не лишённая здравого смысла. Но как-то руки пока не дошли. Может, и нужно такую опцию добавить ещё.
Очень нужно добавить. Без неё прям беда...
 
Сделали. В ближайшем обновлении будет.
Если прямо совсем "беда-беда" пишите на почту, могу дать пререлиз (типа "бэты" - в целом проверено, работоспособно, но ещё тестируем пока, может, что вылезет ещё)
 
На почту написал
 
Добрый день! Файлы получил. Нет инструкции по настройке.  
 
Отправил
 
Добрый день!
Настроил программу. Потребность считает нормально (ошибок пока не выявил). А вот себестоимость считает по другому.
 
Так и будет.
На "Себестоимость" эта настройка не влияет (исключать/не исключать позиции при повторении в "комплектации" и в "Составе" при "расчёте потребности").
"Себестоимость" в любом случае будет работать, как при настройке по умолчанию "расчёта потребности" (исключать при повторении).
Потому что иначе там не будет однозначного алгоритма, как считать.
При расчёте "на изделие" - задвоится всё.
При расчёте на "хитрый заказ" когда что-то берётся из того, что делается в рамках данного заказа, что-то не из этого - там получается нет однозначной логики, как правильно. Если как-то кардинально не усложнять процесс подготовки данных, чтобы это всё учитывалось в любых сочетаниях. А усложнять мы его не будем.
 
Не совсем понял, в чем сложности и почему задвоится всё?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это не есть хорошо. Расчет себестоимости будет не корректен.

Либо жду изменений, либо ломаю голову, как составлять карту заказа, чтоб все считалось правильно.
 
Цитата
Константин Чилингаров написал:
Да, можно.

Вот так:  https://youtu.be/HJezvFPm6m
Добрый день, почему у нас нет выпадающего списка как в видео? Как в нашей версии сделать тогда несколько карт на один заказ?
Форум.JPG (104.51 КБ)
Форум 2.JPG (87.52 КБ)
 
Здравствуйте,

Цитата
Михаил Анатольевич написал:
почему у нас нет выпадающего списка как в видео?
Версия программы старая. Нужно обновить.

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

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

Полезные ссылки:
Себестоимость Видео-презентация подготовка производства складской учет Создание новой базы данных VOGBIT управление данными Полная версия VOGBIT Планирование мелкосерийного производства Техническая Подготовка Производства электронный архив управление качеством деактивации VOGBIT активация VOGBIT управление производством Производственный заказ Установка VOGBIT управление ремонтами Трудоёмкость Деактивация VOGBIT планирование производства базы данных VOGBIT Начало работы инструкция Расчёт комплектации Складской учёт загрузка оборудования расчет себестоимости ТПП Демонстрационный режим VOGBIT Обновление VOGBIT График производства технологическая подготовка производственный учет Тип нормирования Заказ на производство производство металлоконструкций Нормирование пост руководство администраторов VOGBIT Планирование производства разработчика отчетов vogbit состав изделия демоверсия технология Состав изделия Обзор обновления Генератор отчетов склад Сменное задание Задания для производства Выбор уровня учёта новая база данных Расчёт общей стоимости материалов Заявки покупателей Управляемый расчёт материалов Парт
×
Вход на сайт