умножить параметр в репит регионе

[vini 0]

Первоначально репит регион фильтруется на стандартные изделия и их общее значение надо умножить на параметр (na_zakaz)

вводимый в сборку те его нет в деталях и подсборках.

Пробовал &asm.mbr.na_zakaz вставлять в репит регион - не помогает.

Нужно умножить значение в репит регионе на параметр, который вводится в сборке. КАК??

Пример:

на заказ:2___________/* <-- параметр не в репит регионе , но в таблице (вводится: &na_zakaz)

№|Наименование| кол._|итого_|__________/*кол = &rpt.qty

1_|Болт_________|__2__|__4__|__________/* 2*2=4 (должно быть) репит регион

2_|Винт_________|__3__|__6__|__________/* 3*2=6

3_|Гайка________|__5__|__10_|__________ /* 5*2=10

[Sergey___1978 35]

Наверно надо прописать уравнение в уравнениях репит региона, в итоге там появится новый параметр.

Уравнение типа:

Itogo=qty*n

А в репит регион вставить параметр Itogo.

Вроде должно работать, но не проверял.

[EIV 59]

Наверно надо прописать уравнение в уравнениях репит региона, в итоге там появится новый параметр.

Уравнение типа:

Itogo=qty*n

А в репит регион вставить параметр Itogo.

Вроде должно работать, но не проверял.

А в репит регион вставить параметр rpt.rel.Itogo

[Ruslan 688]

Пробовал &asm.mbr.na_zakaz вставлять в репит регион - не помогает.

Кроме параметра asm.name, больше никакой параметр сборки в строках позиций не учитывается.

Поэтому параметр na_zakaz это внутренний параметр региона или его нужно пробивать в каждом используемом компоненте сборки (но есть свои нюансы).

По остальному ответили.

[vini 0]

В репит регион добавлял &rpt.rel.itogo

В уравнениях itogo=asm_mbr_na_zakaz*rpt_qty

В сборке введен параметр na_zakaz целого типа с значением

Репит регион не считает! там остаются пустые строки!!

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

Но мне нужно только стандартые посчитать, без сборок, как передать этот параметр (из общей сборки) чтоб посчитало?

[EIV 59]

В репит регион добавлял &rpt.rel.itogo

В уравнениях itogo=asm_mbr_na_zakaz*rpt_qty

В сборке введен параметр na_zakaz целого типа с значением

Репит регион не считает! там остаются пустые строки!!

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

Но мне нужно только стандартые посчитать, без сборок, как передать этот параметр (из общей сборки) чтоб посчитало?

Уравнение нужно в регионе Стандартные изделия и итого тоже там, а у вас это в регионе Подсборки или как там у вас называется

[Ruslan 688]

vini

Ответы не читаем или что еще не понятно?

[vini 0]

Уравнение нужно в регионе Стандартные изделия и итого тоже там, а у вас это в регионе Подсборки или как там у вас называется

у меня один единственный регион, только фильтром выбираю что оставлять стандартые или что-то другое или все вместе

файл таблицы в zip:kompl.zip

[EIV 59]

Кроме параметра asm.name, больше никакой параметр сборки в строках позиций не учитывается.

Поэтому параметр na_zakaz это внутренний параметр региона или его нужно пробивать в каждом используемом компоненте сборки (но есть свои нюансы).

По остальному ответили.

И в стандартных, они компоненты сборки

[Ruslan 688]

vini

Еще раз.

1. Предусмотрено использование только параметра asm.name и все... Стучите в PTC, что бы добавили asm.User Defined, возможно ли это через API я не знаю.

2. asm_mbr_Имя_параметра - это параметр выводимой детали или подсборки. К самой сборке он не имеет ни какого отношения.

3. Нужно создавать внутренний параметр региона, отвечающий за на_заказ.

Теперь что касается вашей ситуации с общей таблицей:

Есть такой не документированный баг, появляющийся в регионах со сборками, при определенных настройках и при определенных данных.

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

EIV

Я имел ввиду использование asm.mbr.cparam.имя_параметра, но это имеют свои нюансы и новичкам этим лучше не пользоваться.

п.к. А самое правильное в данном случае, использовать PDM это его задача генерировать такие отчеты. К конструкторской модели, количество на заказ, не имеет ни какого отношения. Конструктор может вообще не знать данного параметра.

[EIV 59]

Можно тупо вставить столбец шириной 0,2мм с нужным параметром, прописаным текстом высотой 0,05мм и тупо перемножать.

Конечно это не есть хорошо

[Ruslan 688]

EIV

Не получится, если конечно он не внутренний региона а принадлежит сборке.

[wexus 43]

vini если нет PDM то лучше сделайте параметр в репит регионе na_zakaz и уравнения станут проще. Каждую сборку так пересохранять, если вдуг не на два умножить надо а на три. Не слишком накладно?

Создайте область отчёта:

№_____|Обозначение|Наименование|Кол.__|Итого____|

prt.index|&Обозначение|&Наименование|&prt.qty|&prt.rel.itogo

Уравнения в области

itogo=qty*na_zakaz

где na_zakaz внутренний параметр области.

[vini 0]

vini

Еще раз.

1. Предусмотрено использование только параметра asm.name и все... Стучите в PTC, что бы добавили asm.User Defined, возможно ли это через API я не знаю.

2. asm_mbr_Имя_параметра - это параметр выводимой детали или подсборки. К самой сборке он не имеет ни какого отношения.

3. Нужно создавать внутренний параметр региона, отвечающий за на_заказ.

Теперь что касается вашей ситуации с общей таблицей:

Есть такой не документированный баг, появляющийся в регионах со сборками, при определенных настройках и при определенных данных.

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

EIV

Я имел ввиду использование asm.mbr.cparam.имя_параметра, но это имеют свои нюансы и новичкам этим лучше не пользоваться.

п.к. А самое правильное в данном случае, использовать PDM это его задача генерировать такие отчеты. К конструкторской модели, количество на заказ, не имеет ни какого отношения. Конструктор может вообще не знать данного параметра.

asm_mbr_Имя_параметра - выодит значение также и со сборки (если сам параметр есть на сборке и фильтр пропускает)

В репит регионе если написать &asm.mbr.имя_параметра -также берет значения как со сборок так и с деталей.

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

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

PDM нет, так что приходится так сражаться.

vini если нет PDM то лучше сделайте параметр в репит регионе na_zakaz и уравнения станут проще. Каждую сборку так пересохранять, если вдуг не на два умножить надо а на три. Не слишком накладно?

Создайте область отчёта:

№_____|Обозначение|Наименование|Кол.__|Итого____|

prt.index|&Обозначение|&Наименование|&prt.qty|&prt.rel.itogo

Уравнения в области

itogo=qty*na_zakaz

где na_zakaz внутренний параметр области.

С внутренним параметром области считает, но тогда нужно будет для каждой новой таблицы вводить это значение

Лучше если параметр вводится каким-то образом без редактирования уравнений или внутренних параметров региона те извне репит региона

[wexus 43]

asm_mbr_Имя_параметра - выодит значение также и со сборки (если сам параметр есть на сборке и фильтр пропускает)

В репит регионе если написать &asm.mbr.имя_параметра -также берет значения как со сборок так и с деталей.

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

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

PDM нет, так что приходится так сражаться.

С внутренним параметром области считает, но тогда нужно будет для каждой новой таблицы вводить это значение

Лучше если параметр вводится каким-то образом без редактирования уравнений или внутренних параметров региона те извне репит региона

Так вот как раз это и позволяет иметь одну сборку и кучу таблиц отчётов на разные заказы

Хотя можно пойти дальше. У вас очень большая сборка? Вообще цель всей этой затеи?

Если сборка не сильно громадная и количество заказов не 100 и более можно сделать так:

Создайте сборку ZAKAZ.ASM разместите по умолчанию сборку вашего изделия IZDELIE.ASM создайте массив из этих сборок со смещением по направлению одной из плоскостей.

Создайте чертеж со сборки ZAKAZ.ASM можно не вставлять ни один из видов.

Создайте таблицу

№_____|Обозначение|Наименование|Кол.__|

prt.index|&Обозначение|&Наименование|&prt.qty

В атрибутах поставьте

нет дублиров, рекурсивный

Фильтр региона &asm.mbr.ТИП == СТАНДАРТНОЕ (или какой у вас там фильтр)

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

Но всё же вариант с параметром na_zakaz в регионе предпочтительнее.

[Ruslan 688]

Если же сделать фильтрацию по сборкам, то он считает, но только там, где введен параметр &asm.mbr.имя_параметра те только позицию с основной сборкой.

Вам только кажется что он считает, а на самом деле выводит ерунду да и проблемы с обновлением. Если сама сборка выводится в регион, то запись asm_mbr_Имя_параметра_сборки, работает только для этой записи.

Если вы уж так хотите сделать все равно по вашему, то сделайте в сборке Упрощенное представление по правилу.

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

. Видимо вы это имеете ввиду

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

Лучше если параметр вводится каким-то образом без редактирования уравнений или внутренних параметров региона те извне репит региона

Извне получить параметры, кроме тех что заложены, нельзя

Если не устраивает внутренний параметр и ПДМ тоже не хочется, есть еще два варианта:

1. Вносить во все нужные компоненты сборки параметр количества изделий (это можно сделать скопом, выбрав их через бинокль), и уже asm.mbr.cparam.имя_параметра использовать в уравнениях региона. Но работа регионов с параметрами компонентов имеет свои нюансы.

2. Не делать в ПроЕ этого умножения вообще. Экспортировать основную таблицу в Exsel и там уже добавлять столбец с уравнением и задавать ячейку со значением количества изделий.

[wexus 43]

2. Не делать в ПроЕ этого умножения вообще. Экспортировать основную таблицу в Exsel и там уже добавлять столбец с уравнением и задавать ячейку со значением количества изделий.

Тоже хотел предложить данное решение.

Требуется таблицу сохранить в csv и открыть с помощью EXCEL'а, добавить столбец с уравнением