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

Здравствуйте!
Ну, да.. Екзит для польз. полей и признаки.
Используем и то, и то..

спасибо за совет )
неужели SAPytt написал хотя бы несколько экранов для ведения характеристик ? . я сама по ОСам консультант...для ОС SAP хоть немного старается. а тут получается совсем все грустно.

все экраны можно посомтреть в настройке профиля ракурса (спро-ТОРО-Осн данные - Общие данные)

в принципе, есть еще экранчики с транспортных средств, может там что-то нужное найдете.

Мы ведем через классификацию ЕО. + в настройках ракурсов можно, по моему, сделать экран классификации в основных данных ЕО!

И Все красиво и в одном месте!

Тоже ведем ч-з классификацию. Вряд-ли SAP предусмотрит все необходимые пользователям характеристики. Разве что у них есть какие-то отраслевые решения для Вашей отрасли. Мы как-то все больше сами. Еще очень удобно использовать расширение ITOB0001.

Классификация с признаками не есть панацея и скажем так инструмент не удобен для пользователей.

Можете создать свои виды объектов прописать нумерацию, создать совершенно свои элементы данных, как на основе Z таблиц и т.д
ну и отчетики заточить под это.

Мы например мутили с КИП средствами и оптимили, например вкусности массового монтажа перемонтажа и замены статусов.




ITOB0001: Пользовательский подэкран для основных данных технических объектов.

Это расширение позволяет вводить в систему основные данные, не предусмотренные в базовой поставке SAP, для следующих технических объектов: технических мест, единиц оборудования, серийных номеров.
Для этого в транзакции CMOD генерируется один из включенных в расширение по-дэкранов, который затем появляется на вкладке «прочие данные» (экран 1080 в функцио-нальной группе ITO0). Начиная с версии 4.6А, присвоение подэкранов различным вклад-кам основной записи объекта осуществляется в пользовательской настройке, настройкой профилей ракурсов технических объектов.
Обмен данными между вызывающей программой ITO0 и подэкраном реализован по-средствам двух функциональных модулей, включенных в расширение:
• EXIT_SAPLITO0_001 (импорт данных из вызывающей программы в пользо-вательскую структуру);
• EXIT_SAPLITO0_002 (экспорт данных пользовательской структуры в про-грамму ITO1).
На экране SAPLITO0 1080 под пользовательские поля зарезервировано пространство максимум в 10 строк. Включенный в расширение подэкран при добавлении в основную запись объекта должен иметь тип «подэкран».
Пользовательское расширение поставляет для различных целей использования до 5 включаемых подэкранов с номерами от 1000 до 1004.
Для физического создания включаемых подэкранов используется транзакция веде-ния проектов CMOD. Подэкран, необходимый для отображения в транзакции операций над техническим объектом, определяется в функциональном модуле EXIT_SAPLITO0_001 через экспортируемый параметр E_SUBSCREEN_NUMBER. Если модуль не возвращает значения в данном параметре, по умолчанию всегда выводится подэкран 1000.
Процедура изменения данных и передачи их в вызывающую программу осуществля-ется в модуле EXIT_SAPLITO0_002.
Поля, обрабатываемые в обоих функциональных модулях, сохраняются в следующих структурах переноса:
• ISTRU_EQ (для таблицы EQUI);
• ISTRU_EZ (для таблиц EQUZ, ILOA);
• IFLO_USR1 (для таблицы IFLOT).
Приведённым пользовательским структурам сопоставлены следующие индикатор-ные структуры:
• ISTRU_EQ_U
• ISTRU_EZ_U
• IFLO_USR1U
Установкой флагов в сопоставленных структурах индикаторов можно указать, какие из полей приведённых структур будут транспортироваться в функциональные модули, то есть каждое поле приведённых пользовательских структур должно быть сопоставлено с таким же полем в индикаторной структуре. После обработки данных, перед их экспортом в вызывающую программу, необходимо прямо указать системе, какие поля нужно экспор-тировать, посредством установки одноимённого флагового поля сопоставленной индика-торной структуры. Соответственно, пользовательские и сопоставленные им индикаторные структуры должны содержать полностью идентичные одноимённые поля, только поля ин-дикаторной структуры должны быть флагами, то есть иметь тип CHAR и длину 1.
Начиная с версии 4.0А, инклюды для пользовательских расширений были добавлены в таблицы основных данных технических объектов. Соответственно, инклюд для единиц оборудования был включен в таблицу EQUI, инклюд для технических мест – в таблицу IFLOT. Эти же инклюды добавлены в пользовательские структуры переноса ISTRU_EQ и IFLO_USR1, поэтому все пользовательские поля, определённые в инклюде, сразу доступ-ны для обработки и переноса в пользовательских расширениях. Инклюды названы соот-ветственно CI_EQUI и CI_IFLOT, и подлежат созданию, хотя ссылки на них уже опреде-лены в таблицах основных данных объектов.
После создания инклюдов и определения в них пользовательских полей необходимо также создать соответствующие инклюды и определить в них поля для индикаторных структур ISTRU_EQ_U и IFLO_USR1U. Так как поля в этих инклюдах должны быть фла-говые, то уже созданные инклюды CI_... здесь не пригодны.
В результате создания инклюдов и определения пользовательских полей необходимо учесть следующие основные аспекты:
• В структурах переноса пользовательский инклюд должен содержать актуаль-ные поля данных;
• В сопоставленных им индикаторных структурах пользовательский инклюд должен содержать одноимённые флаговые поля типа CHAR длиной 1.

Функциональный модуль EXIT_SAPLITO0_001.
Используется во время работы пользовательского расширения для вывода основных данных технического объекта на пользовательский подэкран.
Поддерживаются следующие технические объекты:
• Технические места (параметр I_OBJECT_TYPE = '01').
• Единицы оборудования (параметр I_OBJECT_TYPE = '02').
• Серийные номера (параметр I_OBJECT_TYPE = '03').
Данные технических объектов переносятся в модуль в следующих структурах:
• I_DATA_IFLO (данные технических мест).
• I_DATA_EQUI, I_DATA_EQKT, I_DATA_EQUZ, I_DATA_ILOA (данные оборудования и серийных номеров)

Функциональный модуль EXIT_SAPLITO0_002.
Используется во время работы пользовательского расширения для ввода основных данных технического объекта с пользовательского подэкрана в базу данных системы.
Подлежащие экспорту данные переносятся в соответствии с видом технического объекта в следующих структурах модуля:
• E_UPDATE_DATA_IFLO (данные технических мест).
• E_UPDATE_DATA_EQ, E_UPDATE_DATA_EZ (данные оборудования и се-рийных номеров).
Данные, копируемые в структурах переноса, подлежат определению путём установ-ки флагов в сопоставленных индикаторных структурах, описанных в модуле:
• E_UPDATE_FLAGS_IFLO (флаги данных технических мест).
• E_UPDATE_FLAGS_EQ, E_UPDATE_FLAGS_EZ (флаги данных оборудова-ния и серийных номеров).

p.s если нет желания мутить с признаками, классами, можете создать свой табличный элемент данных, создать базу краткую, где можно мобильно и просто её описать, например у вас 200 видов объектов и спокойно в отчетах и в других плоскостях её юзать, зачем усложнять.

p.s если нет желания мутить с признаками, классами, можете создать свой табличный элемент данных, создать базу краткую, где можно мобильно и просто её описать, например у вас 200 видов объектов и спокойно в отчетах и в других плоскостях её юзать, зачем усложнять.

спасибо за советы.
Мне тоже кажется что классы и признаки не совсем удобно использовать... .

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

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

Классы, признаки хороши когда есть база и есть ресурсы и люди и желание людей все это мутить и поддерживать.

Можно добавить закладку в единицу оборудования подр текст и создавать через пакет характеристики и видеть все в отчетах,
пример

Вот даные по приводу, записывай хоть любые данные.

SEW - EURODRIVE type R87DV100L №01.3115703004.0001Х02 i52,82 n =1400/27.0 Nm 1080 W 3/S1 Cosf 0,83 V 230/400//Y A 11.00/6.30 50
Hz M M1 Kg 89.420IP54 B H1-H2 230V RT-45 C CLP 220
SYNTH/2,3L

Также можно создаь свою упрощенную градацию, не заморачиваясь признаками.

У нас например технарям хватает Изготовителя, Название Типа, Номера и ... а мутить с признаками что откуда и из чего для этого надо цедый отдел. и потом отдел еще на корректность

Классы, признаки хороши когда есть база и есть ресурсы и люди и желание людей все это мутить и поддерживать.

Можно добавить закладку в единицу оборудования подр текст и создавать через пакет характеристики и видеть все в отчетах,
пример

Вот даные по приводу, записывай хоть любые данные.

SEW - EURODRIVE type R87DV100L №01.3115703004.0001Х02 i52,82 n =1400/27.0 Nm 1080 W 3/S1 Cosf 0,83 V 230/400//Y A 11.00/6.30 50
Hz M M1 Kg 89.420IP54 B H1-H2 230V RT-45 C CLP 220
SYNTH/2,3L

Также можно создаь свою упрощенную градацию, не заморачиваясь признаками.

У нас например технарям хватает Изготовителя, Название Типа, Номера и ... а мутить с признаками что откуда и из чего для этого надо цедый отдел. и потом отдел еще на корректность

я тоже уже подумала, что в краткий текст можно вписывать данные паспорта объекта...они нужны механикам и энергетикам.
А в каком например стандартном отчете можно увидеть красиво все, что в кратком тексте есть?
Еще посоветуйте куда лучше добавлять свои поля (характеристики оборудования)...в табл. EQUI или в z- таблицы?.

А где перевод документации к юзер-екситам достали?