Спасибо за новую версию

Первый встречный вопрос - Зачем вы используете окна Коллекции компонентов и Компоненты ? Для чего?

Его и не убирали. Включите себе в настройках Показывать панель инструментов (рис. 1) и будет у вас в каждом окне  свой toolbar (рис. 2).

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

В тех режимах, где это однозначно (более-менее хотя бы) - это так и есть.
Например:
- double click на смене в календаре работы постов открывает сменное задание поста;
- double click на позиции в Графике производства открывает список работ по сменам по изготовлению данной партии изделий;
- double click по строчке в сменном задании открывает окно с подробной информацией по данному заданию;
- double click по детали в окне Технология открывает подробную технологию конкретно этой детали;
- и т.д.

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

Вы говорите "открывать содержимое объекта"...
Если у объекта есть, допустим, 5 вариантов описания его состава, 3 варианта описания техпроцесса его изготовления, а также описывающие этот объект параметры, файлы и связанные объекты. Что есть его "содержимое"?

Ровно так, как работает подключённый viewer для просмотра файлов соответствующего типа. Для растра по умолчанию используется простейший встроенный бесплатный viewer. Он действительно совсем простой. Имеет только два режима отображения: автомасштаб под размер окна (растянуть) и без масштабирования (как есть оригинал картинки). И никаких команд.
Если вам он не нравится - используйте какой-нибудь более продвинутый viewer. Вот примеры:

1. Родной viewer для файлов PDF от Adobe (рис. 3): интеллектуальное масштабирование, оглавление, поиск текста в чертеже, печать и др. функции.
2. Родной viewer для Autodesk Inventor (рис.4): разные способы масштабирование, вращение, прозрачность, перспектива, фиксированные виды и др.
и много других есть.

Резюме: мы не пишем сами viewerы для файлов всех типов и видов. Выберите себе такой, какой нравится (и встраивается), подключите и используйте.

От себя: по-моему, лучще pdf и Adobe Reader не придумаешь.

Есть такой инструмент. Есть специальные средства для коллективной работы с прикреплёнными файлами, включая редактирование, блокировку от одновременного редактирования, check-in, check-out, индикация, у какого пользователя сейчас последняя версия файла. Всё это есть в стандартной функциональности VOGBIT. Не сказать, правда, что очень простой механизм, но есть. Им просто никто не пользуется. Если интересно - можем научить (оплачиваете стандартное сопровождение и Welcome). Можно заодно и обсудить, что и как улучшить, если будете реально использовать.

Вот это я вообще не понял, если честно, про что.
1. Что мешает работать с программой на стадии опытного образца? В чём именно проблемы?
2. Что вы хотите, чтобы программа вам подсказывала?
3. Причём здесь приведённое на скриншоте сообщение о невозможности удалить какую-то коллекцию, у которой есть содержимое? Какое отношение это имеет к опытным образцам, их проработке и т.п.?

Думаем.

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

при double click на «Конструкторской спецификации» сколько вариантов исходов может иметь? Открыть/удалить/переименовать/свойства? В любом окне, в любом режиме работы, для любого сотрудника спецификация нужна, чтобы видеть, из чего состоит изделие (содержание позиции в базе), а не «тип связи», «обозначение статуса» и пр. свойства, обслуживающие заголовок позиции в базе данных.
Какие "5 вариантов описания его состава" технологического процесса или заказной спецификации вы можете предложить?

Лучше ни какой, чем кривой, я считаю. Это досадная небрежность. Кстати, в прошлой версии хотя бы миниатюра работала корректно.
Жпег можно открыть на любом устройстве, даже на мобильнике, на пульте гибочного станка или в почтовом клиенте на ноуте.

А вообще, судя по тому, что все эти вопросы за всё время на форуме не поднимались, значит я - марсианин - не стоит заморачиваться. У нашего диспетчера, например, претензий нет.
Просто вогбит не для технологов задумывался изначально, а для управляющих производством.

UPD:
спасибо, сработало.

Не буду ввязываться в дискуссию по поводу документации, политики, сущности объектов и их свойств и т.п. - потеря времени.

Сухой остаток:

Длинно-озвученные выше претензии по сути сводятся к:

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

Ответ: Ок. Можно сделать.

2. Для действия "открыть спецификацию/техпроцесс" хорошо бы уменьшить количество кликов с 3 до 2.

Ответ: Ок. Пожелание понятно. Подумаем, что можно сделать.

1. Да, некоторые настройки окон сейчас действительно не запоминаются. Будем новую версию платформы собирать - посмотрим.

2. Проверил. Работает во всех направлениях. Это стандартный компонент (не мы сами его пишем). В нём нет "направления поиска" (вверх или вниз), как например, в Wordе. Он просто позиционирует курсор на первую попавшуюся строчку удовлетворяющую условию "начинается с". Месторасположение курсора и искомой строчки относительно друг друга значения не имеет. Работает корректно, вроде.

3. Принимается. Разумно. Записали в список пожеланий. При случае сделаем.

4. "Ок" по double click на строчке формы - не самое стандартное решение. Стандартный вариант для "Ok" - это Enter. И он работает в этом месте. Предлагается его и использовать. А вот Esc, действительно, почему-то не работает в этой форме, хотя по идее должен бы. Посмотрим, в чём дело.

5. Суть в следующем:

В окне Состав изделия в отличие от окна Технология подробно в одной строчке и деталь и материал, который берётся из технологии. Это с одной стороны удобно и наглядно, с другой вызывает определённые сложности с dragndropом. Т.к. и то и другое (и деталь, и материал) можно мышкой перетаскивать, причём в рамках одного и того же окна, но по разным правилам. В общем, если кратко, то это сильно усложняет всё дело в плане "перетаскивания" из окна в окно. В качестве решения, чтобы копировать часть одной спецификации в другую, специально в этом окне сделали кнопки "копировать" и "вставить". Предлагается повесить на низ hotkeyи (например, Ctrl+c и Ctrl+v стандартные) и использовать.

6. Ну тут неоднозначный вопрос.

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

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

Получается, что пока структура изделия (что является узлом, что деталью, какие детали применяются, сколько и т.п.) не отработана – просто набрасываем её в виде дерева. Ничего не мешает править её как угодно в любой момент. Когда узел уже достаточно проработан (например, его решили применять, как унифицированный в других местах), можно как раз  на него создать свою спецификацию, чтобы легче его было применять.

Возможны комбинированные варианты – получаем заготовку структуры дерева из стандартных узлов и «дорабатываем» её вручную.

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

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

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

спасибо, ждём

Обновились, спасибо, начинаем работать!

Теперь хочется обрисовать одно неудобство, немного портящее жизнь. Правда, я так и не могу придумать, чем его устранить.
Но сначала ещё раз хочу поблагодарить вас за уже внесённые изменения!

При работе с номенклатурой  у меня схема следующая:
1. набиваю все наименования;
2. описываю поочерёдно все техпроцессы, часто копирую их из ранее созданных;
3. формирую спецификации;
4. если изделие с вложенными сборочными единицами, создаю заказную спецификацию.
Неудобно то, что если я копирую техпроцесс или его компоненты из другой номенклатурной позиции – а их уже очень много в множестве папок – приходится возвращаться к обрабатываемому изделию, опять крутить список номенклатуры. То же и после того, как я перешёл в папку материалов, технологий или переходов, собираю спецификацию из узлов других изделий, добавляю покупные комплектующие... Постоянно приходится держать в голове, от какой позиции ушёл и в какой стадии находишься. Хорошо, если ничто другое не отвлекает, но обычно приходится делать несколько дел параллельно.

В голову приходит только – привязать активное окно (техпроцесса или состава изделия) к номенклатурной позиции. То есть, если открыто несколько окон, при активации любого из них активной будет становиться строка в номенклатуре и её папка. Если закрыть активное окно, активным становится предыдущее, соответственно и строка в номенклатуре, ему соответствующая. Так можно будет возвращаться по ступенькам назад.

Но не создаст ли это ещё больших неудобств, не знаю.

Я ещё с нашим диспетчером не обсуждал эти материи, но, мне кажется, в разделе производства и складов подобная история.

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

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

По поводу «заказных спецификаций» и изменений:

Суть в следующем

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

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

Если рассматривать общий случай, то это на самом деле не так плохо, если разобраться. Даже, скорее, хорошо и правильно.

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

Как в этом всём может быть задействован VOGBIT (при условии оставления той схемы, как сделано сейчас)?
Ну, во-первых, просто удалить деталь из спецификации, если она присутствует в каком-то дереве изделия нельзя. Что уже само по себе хорошо в контексте выше описанной ситуации.
Кроме того, используя возможности работы с наследованием, формы типа Компоненты и разные зависимые окна, при такой структуре данных, стоя на детали в исходной спецификации, можно:

- легко найти в каких изделиях применяется данная деталь в составе узла;
- посмотреть эти деревья;
- заменить при необходимости в конкретном дереве эту номенклатуру на другую;
- или разорвать между деталью в конкретном дереве и деталью-первоисточником в спецификации;

Переводя на более инженерный язык это означает:

- можно быстро определить применяемость детали в составе узла в разных изделиях;
- можно быстро  попасть в нужное дерево изделия, отталкиваясь от детали в спецификации узла;
- можно в составе какого-то изделия или его модификации оставить «как есть», т.е. зафиксировать, что конкретно в этом месте менять ничего не нужно, несмотря на изменение в спецификации-первоисточнике (разорвать наследование);
- можно достаточно легко при необходимости последовательно заменить нужную деталь во всех изделиях, где это требуется. Или удалить её из этих деревьев.

Для примера прикладываю скриншот.

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

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

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

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

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

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

Так что истина где-то посередине.

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

Нужно ли определять следует ли производить соответствующую замену отдельно для каждого такого изделия? В общем случае, думаю, это тоже не лишнее.

Если отключить «наследование» при построении деревьев, то обе эти задачи на порядок усложнятся по сравнению с тем, что есть сейчас. Но корректировка спецификации-первоисточника упростится. Хорошо ли это? Не знаю. Не факт.

Теперь по описанной вами последовательности действий.
Что, с моей точки зрения, сейчас в ней  не так:

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

В случае каких-то более мелких изменений, можно и в программе ограничиться «точечными» изменениями.

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

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

Но для этого нужно освоить работу со спецификациями на более «низком» (или "высоком", это как посмотреть) уровне. Т.е. использование режима Компоненты, зависимых окон типа Унаследованные компоненты, настройку под себя доступных зависимых форм, применение функции Отменить наследование и др.

Можно пойти и другим путём: убрать из Конфигуратора на уровне программы сохранение каких бы то ни было связей между позицией спецификации и позицией дерева, построенного на основе спецификации. Править исходную спецификацию при этом будет элементарно. Но вот, правда, с поддержанием актуальности всего остального могут возникнуть некоторые проблемы.
На тему добавления такой опции подумаем.

Не понял. Воспроизвести не получается.
Можно скриншоты с пояснениями?

по третьему вопросу:

Слева: сразу при формировании спецификации задаю тип связи, в селекторе жму "С" и мне предлагаются варианты, начинающиеся с "С".

Справа: тип связи был не задан, бросаю в спецификацию компонент, загорается окно с выбором типа связи. После нажатия "С" курсор перемещается на первую из строк, начинающуюся с "С".

(это не баг, а фича)

В целом, идея понятна. Возьмём на заметку на будущее.

В качестве альтернативного варианта:
Можно использовать "Категории".
Например, создать альтернативную структуру для справочника ("Категорию"), в которой  разложить позиции по соответствующему принципу в разные папки.

Последнее сообщение перенесено в отдельную тему.

Причина: см. рекомендации, п.2.