Сортировочка, 9х12

Дружочки-пирожочки!

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

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

Так вот, желаемый результат пришел после долгих мучений:)

Поехали:

1. calculatedField11 - уже обсуждали это поле, см. пост о спецификации;

2. Семейство - ничего особенного, это полное описание (семейство). В алфавитном порядке выстраивает все имеющиеся и сортирует под него элементы;

3. PipeRunComponent_ACP_vol2 - аналог стандартного ACP_ClassOrder. Пытливый ум спросит: "А какого это такого это поле тут делает, когда есть стандартное?". Со стандартным полем все очень хорошо, не переживайте, но, к сожалению, его нельзя изменить в 3д модели. Именно по этому полю система понимает в какой последовательности должны выходить элементы внутри одного одинакового семейства. Поле создал через PLANTDEFINECALCPROPERTIES, задал начальные значения каждому, из необходимых мне, типу элементов и наслаждаюсь порядком:

Опять таки, такая ситуация бывает только в том случае, когда разные типы элементов собраны под одно семейство. В примере указан стандарт ASTM D5685, но, по желанию, можно сделать какой-нибудь наш аналог и объединить тот же ТУ3600-010-88626180-2012 (а вдруг кому-то захочется, всякое бывает:));

4. Elbow_PathAngle - попало в список т.к. есть необходимость различать как-то отводы. просто по записи, как это сделано у других, некрасиво, да и принцип другой, поэтому сортировка идет по геометрии деталей, а если конкретнее - по углу поворота. Внимание на поле calculatedField15 не обращаем, там тоже Elbow_PathAngle  - мой косяк:);

5. Flange_Pressure - должно быть все понятно, захотелось видеть все фланцы по давлению;

6. calculatedField14 - пример того, как исправляются ошибки в описании. Поле содержит выражение Substring([Olet_ItemCodeOlet],0,9). Что означает? Кто-то закосячил и необходимо было сортировать по какой-то части описания именно в элементах Olet;

7. calculatedField16 - сортировка для опор. Каждая имеет свой номер (К-1,К-2,К-3...), поле содержит ToDecimal(Substring([Support_IdenS],2)), которое опускает 2 знака и преобразует значение в десятичное число. Почему именно в десятичное? Если сортировать текстовое поле - после 10 может пойти, случайно, 100, а то и 150;

8. Инженерные элементы_Стандарт - все понятно, обычное поле, сортировка по нему;

9. Diametre2 - вот оно, то, что я анонсировал в самом начале! Это копия поля номинального диаметра. Почему оно появилось? А все очень просто. Для тех, кто работал с крепежом, не станет открытием тот факт, что на некоторые группы диаметров используется один и тот же размер крепежа. Но что же будет если произойдет сортировка по диаметру? Правильно, выйдет 2 одинаковых крепежа, но в разных строках (на разницу в весе крепежа тоже закрываем глаза, обращаем внимание на М14х70:)):

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

Остальные позиции сортировки говорят сами за себя. calculatedFiled12 сортирует крепеж по размеру болта\оси, SpecificationNamePosition просто сортирует по общей записи, MaterialCode содержит информацию о материале.

Такие вот дела. Не скучайте, еще есть о чем поговорить, как будет настроение - обсудим. До новых встреч;)