Константин Чилингаров: Здравствуйте,
В этом окне, насколько я помню, сохраняется только список "постов" выбранных. При закрытии/открытии окна.
Порядок сл ...
Владимир Белов: написал:
Добрый день! Такой вопрос. Могу я установить базу данных на съемный диск и пользоваться на разных компьютерах - переставляя то ...
Константин Чилингаров: Здравствуйте,
Обычно, непосредственно с терминала выгружают управляющие программы какие-нибудь, к заданию, которое берется в работу. Н ...
Константин Чилингаров: К сожалению, проблема хронического отсутствия времени пока не позволила сделать.
Лежит заготовка под второй ролик с лета. Пока отложена ...
Константин Чилингаров: написал:
Честно говоря, "средний" уровень как-то никогда не рассматривали для работы.
Всё меняется...
10 лет назад там действитель ...
Константин Чилингаров: написал:
Можно, пожалуйста, выложить скрины, как это реализовано
Пожалуйста:
Рис.1 - Параметры в справочнике. Которые я использовал, ка ...
Константин Чилингаров: Здравствуйте!
Да, встречали такую ситуацию. Но, к сожалению, пока никак не можем научиться её стабильно повторять. Не можем пока найти к ...
Константин Чилингаров: Здравствуйте,
На совсем понял, если честно вопрос в Вашей терминологии.
Давайте попробуем ещё раз разложить всё по полочкам…
Вы ...
Константин Чилингаров: Здравствуйте,
Вместе с расчетом материала на 7 шт. еще и штучное время поделилось на 7
В этом есть логика.
Обычно эту "единицу нормир ...
Константин Чилингаров: Здравствуйте,
Не совсем понятно. Если речь идёт об окне, где отражается график работы и загрузки постов по дням и сменам (высокий/максим ...
В этой теме я хотел бы рассказать о некоторых технических тонкостях работы с VOGBIT. Осветить несколько вопросов, которые в том или ином виде достаточно часто интересуют многих пользователей.
Тема предназначена, преимущественно, для пользователей VOGBIT, уже имеющих некоторый опыт работы с программой. Тем, кто только знакомиться с программой, я бы порекомендовал начать с этого (или этого) руководства, а также с роликов «Начало работы».
«Производственным заказом» в VOGBIT называется список того, что нужно изготовить.
Не нужно путать с внешними заказами. Т.е. с тем, что хочет получить от вас покупатель (заказчик). В каких-то случаях эти вещи совпадают, а в каких-то нет. Поэтому в VOGBIT есть два отдельных понятия: производственный заказ и заявка покупателя.
Производственный заказ – это список того, что нужно сейчас изготавливать.
Заявка покупателя – это список готовой продукции, которую хочет получить от вас заказчик.
Если производство работает не всегда строго под заказ, а иногда и на склад, на будущее (довольно частая ситуация для мелкосерийного производства), то имеет глубокий смысл вести в программе отдельно заявки покупателей и отдельно производственные заказы. В случае чисто позаказного производства (к примеру, изготовление строительных металлоконструкций) заявка покупателя тождественно равна заказу на производство, поэтому большого смысла заводить в программе отдельно «заявки» отдельно «заказы на производство» нет. Можно обойтись только последними.
Как мы определились, заказ на производство – это список позиций, которые нужно изготовить. Совокупность всех активных производственных заказов представляет собой общий план производства. Что итого нужно сделать.
Что входит в производственный заказ?
Очевидно, продукция. Но это не обязательно только какая-то готовая (товарная) продукция. Может быть, только какие-то отдельные детали для неё. А может быть, и детали, и сами изделия, которые надо из этих деталей собрать. А у кого-то нет как таковых деталей и сборочных единиц, изделия простые и производятся сразу целиком, а не по частям. Бывает по-разному. Зависит от организации производства, от продукции, от технологии.
Важно то, что производственный заказ – это список неких позиций, которые нужно изготовить. Не нужно включать в производственный заказ покупные изделия. Для планирования и учёта потребностей в них в программе существуют другие средства и способы. Производственный заказ – это задание производству. Он должен содержать только то, что, собственно, производство должно изготовить.
Вся необходимая для производства информация: что изготавливать и как изготавливать (по какой технологии) содержится в так называемой карте заказа. Или, что то же самое, технологической карте заказа.
Почему понятия Заказ и Карта заказа в программе разделены? Для удобства.
Дело в том, что бывают случаи, когда предприятие выполняет один и тот же большой заказ в течение нескольких месяцев, а то и лет. В таком случае бывает удобно разделить весь заказ на несколько частей. И тут как раз очень удобна возможность создать в программе один заказ, но к нему несколько разных карт заказа. Например:
Благодаря такой структуре, намного удобнее работать с большими заказами. Составлять план и формировать задания производству, контролировать выполнение, строить отчёты по отгрузке продукции и т.п. Можно, как выделить только одну или несколько интересующих частей заказа и работать только с ними, так и получить данные по всему заказу (например, какой-нибудь общий отчёт, сколько работ выполнено, металла потрачено, продукции отгружено и т.п.).
Именно поэтому в таких режимах, как «Производственные заказы», «График производства» и т.д. вы можете везде увидеть две отдельных колонки «Заказ» и «Технологическая карта» (для возможности группировки).
В более простых случаях, когда разбиение производственного заказа на несколько частей не требуется, по умолчанию действует принцип: один заказ – одна карта заказа. Ненужную колонку (название карты заказа) можно в таком случае просто скрыть.
Теперь рассмотрим техническую сторону вопроса. Что представляет собой «заказ» и «карта заказа» с точки зрения базы данных VOGBIT.
Заказ – это номенклатурная позиция. Карта заказа – это коллекция компонентов, связанная с номенклатурной позицией «Заказ» типом связи «Технологическая карта заказа» (LT_MAN_CHART) – Рис. 1. Таких коллекций у номенклатурной позиции «Заказ» может быть несколько. Что соответствует нескольким картам заказа.
Соответственно, для того, чтобы создать для существующего заказа ещё одну карту заказа, нужно найти в справочнике «Номенклатура» позицию «Заказ» и создать для неё ещё одну коллекцию компонентов «Карта заказа» (в современной версии можно также создавать новую карту для существующего заказа и из окна "производственные заказы" - ролик).
Имеет значение статус карты заказа (рис. 1).
Если статус = «В работе» (ST_InWork), то такая карта будет показываться в окне «Производственные заказы – Текущие».
Если статус = «Завершено» (St_Completed), то такая карта будет показываться в окне «Производственные заказы – Ранее выполненные»
Если карта заказа имеет какой-либо другой статус, то она не будет отображаться в окне «Производственные заказы».
Почему так сделано? Потому что, окно «производственные заказы» - это, в первую очередь, возможность быстро открыть список текущих заказов на производство (карт заказов) для ПДО или подобных отделов, т.е. для специалистов, которые занимаются непосредственно производством. При этом не обязательно, чтобы вновь созданный заказ сразу же становится «текущим». Можно организовать работу и так, что сначала созданная карта заказа не будет видна в окне «производственные заказы». При этом с ней могут работать инженеры по подготовке производства: прорабатывать состав, техпроцессы, нормативы. И только в нужный момент, уже готовая карта заказа становится видна производственникам.
Для такого случая достаточно создать карту заказа, но статус ей поставить «В разработке». С такой картой заказа можно будет полноценно работать, используя стандартные модули «Состав изделия», «Технология» и т.д., но она не будет видна в окне «Производственные заказы». В нужный момент достаточно переключить статус карты на «в работе», и она появится в списке «производственные заказы».
Теперь посмотрим, что происходит, когда вы нажимаете «Создать новый» в окне «производственные заказы» и указываете обозначение и наименование заказа. На самом деле, при этом как раз и создаётся номенклатурная позиция «заказ» и связанная с ней коллекция компонентов «карта заказа» со статусом = «в работе». По умолчанию достаточно заполнить только обозначение и наименование для нового заказа. Созданной карте заказа будет по умолчанию присвоено обозначение такое же, как у заказа, плюс «.ТК1».
Но если вы обращали внимание, в окне, где вы вводите обозначение и наименование создаваемого производственного заказа, есть кнопка «Подробнее» (рис.2). С её помощью можно:
- выбрать в какую папку в справочнике «Номенклатура» положить вновь созданную позицию «Заказ»;
- выбрать в какую папку в справочнике «Коллекции компонентов» положить вновь созданную коллекцию «Карта заказа»;
- задать осмысленное обозначение и наименование карты заказа, а также добавить к ней поясняющий комментарий (на тот случай, если вы планируете создать в дальнейшем не одну карту для данного заказа).
Т.е. кнопка «Подробнее» в данном случае позволяет выполнить создание заказа и карты более осмысленно. Что особенно важно, если вы сразу предполагаете, что это будет, вероятно, не единственная карта для данного заказа.
Таким образом, стандартная функция «Добавить новый» в окне «Производственные заказы» даёт максимальное упрощение работы с программой для пользователя в простейшем (и, возможно, самом распространённом) случае. Когда один производственный заказ = одна карта заказа. И когда нет необходимости организовывать некий «жизненный цикл» карты заказа.
При этом пользователь может вообще не знать о том, что заказ - это номенклатурная позиция. О том, что заказ и карта заказа – это немного разные понятия, и заказ может быть один, а карт много. О том, что «заказ» и «карта» могут быть помещены в какие-то «папки». О статусах и их смысле. И т.п. В простейшем случае это всё не важно. Просто нажимаем «Добавить новый» в окне «Производственные заказы», заполняем номер и название заказа и нажимаем «Ок». Готово! Можно вводить позиции заказа (состав), маршруты, планировать учитывать и т.д.
Более «продвинутые» пользователи, опираясь на изложенную выше информацию, могут использовать и другие возможности программы.
Например, окно «производственные заказы» - это не единственное место, откуда можно добраться до карт производственных заказов. Вы можете создать свою структуру папок (или даже специальную «Категорию») в справочнике «Коллекции компонентов» и раскладывать по этим папкам карты своих производственных заказов. Вы можете полноценно работать с этим картами заказов, использовать режимы «Состав изделия», «Технология», «График производства» и др. Но при этом оперировать не с простым списком текущих заказов, как в окне «Производственные заказы», а создавать свою, произвольную, сколь угодно сложную структуру папок, где карты заказов будут разложены по каким-то вашим принципам.
Ну и, конечно, вы можете создавать к одному производственному заказу несколько разных карт, если хотите разделить его на несколько частей.
Дополнительную информацию о картах производственных заказов можно также найти здесь.
Многие, наверное, видели в роликах и/или сами использовали возможность добавлять в VOGBIT файлы. Изображения, чертежи и т.п.
Рассмотрим некоторые технические аспекты данного вопроса. Где и как хранятся файлы в VOGBIT.
Когда вы «складываете» в систему файлы они помещаются программой в базу данных VOGBIT. Это позволяет вам или другим пользователям получить доступ к нужным файлам с любого компьютера, где есть рабочее место VOGBIT (и доступ к базе). Открыть файлы, сохранить копию к себе на диск, посмотреть и т.п.
В базе данных файлы хранятся в универсальном «контейнере» коллекция компонентов. Да, да. Точно в таком же, который используется для хранения спецификаций, техпроцессов, карт заказов и т.п. Строго говоря, в любую коллекцию компонентов помимо собственно содержания коллекции (спецификации, техпроцесса, карты заказа) при желании можно добавить ещё и файлы. Например, в спецификацию добавить чертежи деталей, в техпроцесс – эскизы и программы для станков с ЧПУ, и т.д. (Рис.3).
Можно создавать отдельные коллекции компонентов, в которых не будет ничего кроме файлов. Специально с целью хранения файлов в VOGBIT.
После того, как вы поместили файл в какую-либо коллекцию компонентов, он уже в базе данных. Чтобы облегчить себе и другим поиск соответствующих файлов, можно привязать их к каким-либо объектам в системе с помощью стандартной функции (формы) «связанные файлы». Например, добавить помещённый в коллекцию «Спецификация» чертёж как связанный файл к детали (рис.4). Тогда в дальнейшем можно уже не вспоминать, где именно лежит чертёж. Из любого места, где вы работаете в программе с деталью, вы сможете открыть чертёж этой детали.
Простейший вариант использования файлов – просмотр. Правда, для того, чтобы просматривать файлы прямо в окне VOGBIT, на вашем компьютере должен быть установлен и соответствующим образом настроен просмотрщик, обладающий необходимыми возможностями (поддержка возможности встраивания в сторонние приложения с использованием технологии ActiveX).
Также в некоторых режимах существуют полезные функции для выгрузки нужных файлов в заданную папку. Например, вот и вот.
Это самые простые и очевидные способы использования файлов при работе с VOGBIT.
Помимо этого, в базовую платформу VOGBIT заложены также и некоторые функции для коллективной работы с файлами. Например, для того, чтобы в случае, когда несколько инженеров ведут один и тот же проект, если кто-то один из команды вносит изменения в файл, остальные могли это видеть, но не могли параллельно изменять тот же файл (иначе при сохранении изменений, внесённых одним автором, могут потеряться изменения, параллельно внесённые другим).
Для этого, когда вы выполняете из VOGBIT команду «открыть файл», соответствующий файл в коллекции блокируется (рис. 5). Указывается дата блокировки и пользователь. Т.е. кто и когда «взял» этот файл в системе для редактирования. Остальные могут посмотреть текущий вариант файла, но не изменить его в базе данных. До тех пор, пока пользователь «взявший» файл не «вернёт» его обратно. При этом он может, как обновить файл в базе данных (сохранить изменения), так и просто снять блокировку (отказаться от сохранения внесённых изменений в базе) – см. рис.6.
Здесь существует один важный технический момент: когда пользователь «берёт на изменение» (отрывает для редактирования) какой-то один файл из коллекции, блокируются все файлы, которые лежат в данной коллекции. На тот случай, если они связаны между собой (такое часто бывает, если говорить, к примеру, о файлах CAD-систем).
Отсюда происходит следующий вывод: если вы складываете файлы в VOGBIT только для того, чтобы их смотреть и выгружать из базы в нужный момент, то технически совершенно всё равно, в какой именно коллекции эти файлы в базе лежат. Через механизм «связанные файлы» вы доберётесь до нужного файла от детали или изделия, где бы физически этот файл не лежал. А вот если вы планируете организовать коллективную работу с этими файлами в плане их редактирования, то уже имеет значение, как файлы разложены по коллекциям.
Теперь, учитывая вышеизложенное, рассмотрим, как технически работают пользовательские функции добавления файлов в различных режимах VOGBIT.
Функция «Эскизы» (ролик, примерно 02:30) – это простейший вариант. Она предназначена для добавления файлов (картинок), которые используются только для просмотра. Эта функция складывает все добавляемые файлы в одну заранее созданную коллекцию (общее хранилище подобных картинок) и добавляет «перетащенный» файл, как «связанный» к соответствующему объекту (подразделению, работнику, номенклатуре).
Функция «Файлы» в режиме «Состав изделия» (ролик, примерно 04:50) складывает добавляемые файлы в редактируемую коллекцию компонентов (спецификацию или карту заказа) и привязывает их в качестве «связанных файлов» к номенклатуре соответствующих деталей или сборочных единиц (чтобы при использовании данной детали в другом изделии связь детали с файлом сохранилась и там).
Функция «Файлы» в режиме «Технология подробно» (ролик, примерно 04:55) складывает добавляемые файлы в коллекцию «техпроцесс» (который редактируется в этот момент) и добавляет в качестве «связанных файлов» к выбранному элементу техпроцесса (к операции или переходу, например).
Таким образом, для простейших задач типа привязать файл к детали / посмотреть / сохранить на диск, можно вообще не задумываться о технической стороне вопроса (что где лежит, блокировках и т.п.). Можно просто прицеплять файлы, как показано в роликах, а потом просматривать или выгружать их в папку на диске, когда нужно (штатными командами из соответствующих режимов работы).
Если использовать заложенные возможности чуть более широко, то кроме этого можно: - прицеплять в программе файлы не только к деталям или строчкам техпроцессов, а вообще хоть к чему; - на простом уровне организовать коллективную работу нескольких человек с проектом (файлами).
Это уже позволяет успешно решать большое количество практических задач.
P.S. При желании можно дальше развивать функции программы в сторону построения полноценного «электронного документооборота». Например, прописать бизнес-логику, ограничивающую доступ к файлам в зависимости от статуса документа и/или роли конкретного пользователя. Добавить функции маршрутизации (пересылки) и т.п. Однако это уже требует разработки дополнительных plugin’ов (модулей) для VOGBIT. Это возможно, и у коллектива разработчиков есть опыт создания подобных систем. Но на сегодняшний день данная задача не является для нас приоритетной, в силу отсутствия реального платёжеспособного спроса на такую функциональность со стороны большинства наших пользователей (или вообще не нужно, или «можно было бы посмотреть», но платить за это не готовы).
Вопрос третий: про «участки» (место выполнения) и «посты»
Те, кто хотя бы немного уже поработал с программой в части описания технологии изготовления, наверняка, обратили внимание что в техпроцессе для операций может указываться такая информация, как:
- «место выполнения» - участок производства где выполняется данная операция; - «пост» - более точное указание рабочего места или зоны, где выполняются работы;
Так же встречается такое понятие как «возможный пост».
Порядок указания соответствующей информации в техпроцессе достаточно подробно описан в документации. Здесь мы рассмотрим более подробно смысл каждого из перечисленных понятий. Как и когда нужно или не нужно указывать «место выполнения», «пост», «возможные посты», и какие при этом есть нюансы. Для чего нужны настройки «участков» и «постов» по умолчанию, и как их правильно использовать.
Место выполнения
Место выполнения операции – это участок производства, где выполняются соответствующие работы. Для какого подразделения будет создано задание на выполнение работ при запуске изделия в производство.
Указывать «место выполнения» (участок) для операции нужно обязательно, если вы используете уровень учёта, начиная от «среднего» и выше. На «минимальном» уровне учёта эта информация может оказаться и не нужна.
Что делать, если операция может выполняться на нескольких участках? В таком случае в техпроцессе конкретной детали уже указывается, на каком участке выполняется соответствующая операция при обработке такой детали.
Что делать, если при обработке одной и той же детали в разные периоды времени одна и та же операция может выполняться на разных участках (например, в зависимости от загруженности этих участков другой работой)? В этом случае в технологии для операции всё равно указывается какой-то один из этих участков. В случае, если потом операция будет реально делаться на другом участке, то при уже при планировании производства существует возможность «передать» соответствующие работы (задания) на другой участок.
Какой из нескольких участков указывать в этом случае в технологии? Логично, тот на котором такая операция выполняется чаще.
Что делать, если операция может выполняться равновероятно на одном или на другом участке? Ну тогда указывайте в техпроцессе любой из них. Разницы нет, всё равно в половине случаев придётся менять.
И ещё, в таком случае есть повод задуматься, не слишком ли вы усложнили описание структуры производства и техпроцесса в программе? Действительно ли вам нужно заводить в VOGBIT столько разных участков или так подробно описывать техпроцесс? Даст ли вам это что-то, кроме того, что вы будете вводить больше данных? Есть ли какая-то реальная польза в том, чтобы делать именно так?
Помните, что определение «участка» в программе вовсе не обязательно должно строго совпадать с существующим административно-территориальным делением производства на цеха и участки.
Пост
Сразу отметим, что говорить о «постах» имеет смысл только, если вы используете «высокий» или «максимальный» уровень учёта. В противном случае, «посты» вам никак не пригодятся и вводить их в программу не имеет смысла. Ни в справочник, ни в техпроцессы.
Пост – это более точное указание, где выполняются работы. Конкретное рабочее место или зона, за которым(ой) закреплены конкретные работники.
В отличие от «участка» (места выполнения) указывать «пост» для операции в техпроцессе, в общем-то, необязательно. На «минимальном» и «среднем» уровне учёта, как мы уже отметили выше, эта информация вообще не нужна и никак не используется. А на «высоком» или «максимальном» уровне вполне допустимо уточнить пост позже, на этапе оперативного планирования производства. Это нормальная ситуация. Именно так и делается, когда существует несколько альтернативных постов, и на каком именно будут выполняться работы заранее неизвестно. В этом случае, часто, «пост» в технологии для операции вообще не указывается. Только «участок». А потом при планировании производства уже выбирается, на какой из доступных постов направить данное задание в текущей ситуации.
В каком случае имеет смысл указать для операции в техпроцессе «пост»? Если это единственно возможный пост, где может выполняться данная операция. В этом случае вы просто избавляете себя (другого пользователя) в дальнейшем (на стадии оперативного планирования) от ненужного выбора, кому выдавать задание, каждый раз при изготовлении таких изделий. Если всегда при этом соответствующая операция в любом случае выполняется на известном, одном и том же посту, вот в этом случае есть смысл указать этот пост для операции в техпроцессе. Чтобы потом созданные для производства задания сразу попадали на соответствующий пост.
Подведём итог: Если однозначно известно на каком именно посту будет выполняться работа, то имеет смысл указать этот пост для операции в техпроцессе.
Если постов, где может выполняться операция, несколько, то можно пойти двумя путями. Можно указать в техпроцессе для операции тот пост, на котором она выполняется наиболее часто. Тогда по умолчанию для производства задания будут создаваться для этого указанного в техпроцессе поста. А в случае необходимости уже на этапе выдачи сменных заданий можно будет передать работы на другой пост. Но это не всегда удобно. Поэтому можно и вообще не указывать в таком случае в техпроцессе для операции никакой пост. Тогда при изготовлении соответствующих изделий уже на этапе подготовки ежедневных заданий для рабочих программа будет каждый раз просить вас выбрать, на каком посту следует выполнять работы в этот раз. И в определённых случаях это преимущество, а не недостаток.
Возможные посты
Есть в программе и ещё одна возможность – указать в техпроцессе для операции несколько «возможных постов». Т.е. сразу задать для одной операции несколько альтернативных постов, где могут выполняться соответствующие работы.
Первое, что следует отметить в данном случае это то, что в настоящий момент лишь один модуль программы использует эту информацию (о «возможных постах»). Это расчёт планируемой загрузки производства.
Поэтому, если вы не знаете, как использовать данный модуль программы, или просто не пользуетесь им для работы, то и «возможные посты» вводить не нужно. Эта информация всё равно останется невостребованной.
А вот если вы используете модуль расчёта плановой загрузки производства, то тогда наоборот, для каждой операции, которая должна учитываться при расчёте, должен быть указан либо конкретный пост, если таковой только один, где она может выполняться, либо «возможные посты», если таковых несколько.
Второй момент, на который нужно обратить внимание, это то, что указывать для операции имеет смысл только что-нибудь одно из двух – либо «пост», либо несколько «возможных постов». Задавать сразу и то, и другое одновременно не имеет смысла. Потому что, если вы указываете для операции «пост», то тем самым говорите программе, что операцию следует выполнять всегда на этом посту. И при создании заданий на выполнение этой операции все они всё равно всегда будут направлены по умолчанию на этот один указанный пост. Соответственно, внесённая информация про «возможные посты» в этом случае лишняя, т.к. она всё равно никак задействована не будет.
Настройка
Ну и наконец, про настройки.
Многие, наверное, видели в ролике и в докумнентации, что можно задать в справочнике для операции «участок» (место выполнения) и «пост» по умолчанию. Для чего и в каких случаях это нужно?
Начнём с того, что данная настройка не обязательна. Можно ввести в справочник «Подразделения» имеющиеся участки и посты, в справочник «Номенклатура», операции, которые нужны для описания техпроцесса и начинать описывать в программе технологию изготовления своих изделий.
Однако, в данном случае участок, где выполняется операция, вам нужно будет указывать каждый раз при разработке техпроцесса для каждой новой детали (или копировать операцию из техпроцесса другой детали, где уже всё указано). Например, каждый раз, добавляя из справочника операцию «Лазерная резка», вам нужно будет не просто «перетащить» её мышкой в техпроцесс, но и открыть окно «подразделение» и указать, что эта операция выполняется, к примеру, на «Заготовительном участке».
И это, согласитесь, с точки зрения простого пользователя не очень логично и удобно. Зачем делать это каждый раз, когда используешь операцию «Лазерная резка», если понятно, что она всегда выполняется на «Заготовительном участке».
Вот в этом случае и полезно указание для операции «участка» (места выполнения) по умолчанию. Чтобы всегда, когда вы задействуете указанную операцию, в техпроцессе любого изделия, программа сама определяла её на участок, заданный по умолчанию. Просто для того, чтобы каждый раз при написании техпроцесса не перетаскивать на эту операцию всегда один и тот же «участок» из справочника.
А при использовании «высокого» или «максимального» уровня учёта можно по аналогии назначить для операции по умолчанию и «пост» или несколько «возможных постов». Например, если пост лазерной резки на предприятии только один, то логично его сразу назначить для соответствующей операции по умолчанию. Других то всё равно нет…
Для назначения «участка», «поста» и «возможных постов» по умолчанию, к операции в справочнике «Номенклатура» добавляются связанные объекты. С типами связей: - «Место выполнения» - для указания участка по умолчанию; - «Производственный ресурс» - для указания поста по умолчанию; - «Возможный производственный ресурс» - для указания возможных постов по умолчанию.
Теперь сопоставим это с тем, что мы обсудили выше по поводу порядка и особенностей использования соответствующей информации.
Как вы, наверное, запомнили, участок для операции в технологии в любом случае задаётся только один. Если вдруг возможно выполнение на другом участке, то уже на этапе планирования осуществляется «передача» работ с одного участка на другой. «Пост» и вовсе указывается в технологии только в том случае, если выполнять операцию можно только на этом одном посту (ну или это почти всегда так).
Соответственно, и при настройке «по умолчанию», в справочнике к операции следует добавлять только одинсвязанный объект «место выполнения» (участок) и только одинсвязанный объект «производственный ресурс» (пост).
А вот связанных объектов «возможный производственный ресурс» (возможный пост) может быть и несколько. Но только в том случае, если у этой операции нет ни одного связанного объекта «производственный ресурс» (пост). Т.к. если задан конкретный пост по умолчанию, то задавать возможные посты по умолчанию уже нет смыла, т.к. до них программа всё равно уже никогда не дойдёт.
Среди начинающих пользователей является достаточно распространённой такая ошибка: Если операция может выполняться на нескольких участках или постах, то они считают нужным добавить к ней в справочнике множество связанных объектов типа «место выполнения» и «производственный ресурс». Это ошибка. Так делать не нужно. Добавлять «участок» и «пост» по умолчанию для операции в справочнике имеет смысл только в одном случае - если этот участок или пост всегда один и тот же, в каком бы техпроцессе эта операция не использовалась. Если это не так, то вообще не нужно ничего добавлять к операции в справочнике. А участок и пост уточнять отдельно в каждом конкретном техпроцессе.
Соответственно, и связанных объектов «место выполнения» и «производственный ресурс» у операции в справочнике должно быть максимум по одному. Или вообще не быть.
Резюме
Итак, каков «сухой остаток» из всего вышесказанного:
1. Участок (место выполнения) для операции нужно указывать в технологии всегда. Если он всегда один и тот же для соответствующей операции, то можно настроить по умолчанию.
2. В техпроцессе для операции указывается всегда только какой-то один участок. На этапе планирования, если нужно, можно «передать» соответствующие работы на другой участок.
3. Пост для операции в техпроцессе можно не указывать.
4. Пост указывается для операции в техпроцессе только в случае, если она всегда выполняется на этом одном посту. Если могут быть задействованы разные посты, то в техпроцессе пост не указывается, только участок. Если операция всегда выполняется на одном посту (независимо от того, что изготавливается), то можно настроить этот пост для неё по умолчанию.
5. Возможных постов можно указать для операции несколько. Но это имеет смысл делать только, если вы пользуетесь модулем расчёта плановой загрузки производства. В противном случае информация о возможных постах, которую вы введёте, всё равно вам в дальнейшем никак не пригодится.
6. Для операции имеет смысл указывать только что-то одно: либо один конкретный пост, либо несколько возможных постов. Указывать одновременно и то, и другое, бессмысленно.
7. Если вы выполняете настройки для операции в справочнике «по умолчанию», то в результате у вас должно получиться у операции не больше, чем по одному связанному объекту «место выполнения» и «производственный ресурс». Связанных объектов «возможный производственный ресурс» может быть и несколько. Но только если при этом нет ни одного связанного объекта «производственный ресурс».