Собственно проблема: хочется чтоб при создании ЕО, сразу после сохранения ей присваивался определенный клас (например в зависимости от вида) и документ DMS (тоже в зависимости от вида).

На сколько я понял, user-exit IEQM0003 получает EQUNR только при изменении ЕО, а при создании у него только "времменый" номер. Как можно это побороть? Т.е. В общем случае как сделать некую операцию при создании ЕО, для которой нужен нормальный EQUNR ее.

Не знаю какая у тебя версия, но вот например в 5.0 есть такой БАДИ EQUI_UPDATE, в котором есть метод IN_UPDATE, в котором есть вх.параметр I_DATA_EQUI, где уже имеется информация о номере создваемой ЕО.

Используй внешнюю нумерацию, тогда EQUNR будет известен сразу.

Кстати еще один вариант узнать номер ЕО: в экзите IEQM0003 определить текущий номер с помощью ФМ NUMBER_GET_INFO (объект диапазона номеров EQUIP_NR, номер интервала в зависимости от типа ЕО - таб.T370T), и далее определить след.номер, который (вероятнее всего ) и будет присвоен вашей ЕО.

1) EQUI_UPDATE есть, вот только что мне с ним делать, если я создаю ЕО? Я так понял, это к тому как к ЕО присвоить Документ?
2) Внешняя нумерация - это слишком серьезное изменение существующего проекта, да и не нужна она. Как-то это слишком мощьно...
3)Тоже была такая мысль. Вот только действительно, настораживает - "вероятнее всего". Где бы прочитать более детально про нумерацию, чтоюу потом "круто не попасть на ТВ"?

Выше я уже описал как этим можно воспользоваться: в методе IN_UPDATE есть вх.параметр I_DATA_EQUI (в нем можно найти номер создваемой ЕО)

есть вероятность пока ты будешь в экзите присваивать документы ЕО, кто-то в этот же момент создаст ЕО с этим номером. Хотя, может и этого можно избежать.

Кстати вот ссылка на тему нумерации:
http://help.sap.com/saphelp_470/helpdat ... ameset.htm

Это на мой взгляд преодолеть просто. При сохранении сделать проверку, если ЕО с таким номером есть, прибавить 1 и снова сделать проверку, и так далее

Да, спасибо! Так, думаю, все сработает. Только один вопрос: как понять какой объект нумерации (EQUIP_NR) мне нужен? Т.е. как его самостоятельно "достать"?

так EQUIP_NR и есть объект нумерации (номер диапазона зависит от типа ЕО)

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

Что-то про "магическое слово" я не понял Имеешь в виду какой объект нумерации в том или ином случае? Запусти тр. SNRO, или таб.TNRO. Для сообщений, например - QMEL_NR.

все, SNRO - и есть "магия" )) Спасибо.

Это тоже не гарантия. На запись может уйти 1-3 сек. Запрос покажет, что документа с таким номером нет, но он уже там.

Кстати да, мы на такое уже нарывались. Это ксалось сообщений ТОРО. При этом одно из полей сообщения записывали в свою таблицу с идентификатором Номер сообщения. Номер сообщения получить таки удалось (с помощью ФМ NUMBER_GET_INFO ), но когда одновременно создавались несколько сообщений, идентифкаторы перепутывались. В итоге получалась забаваня ситуация: два пользователя создающие сообщения и заполняющие наше новое поле, после сохранения сообщения, снова заходят в него и обнаруживают, что значения поля у них собственно говоря не те, которые они вводили , т.е например, у одного поле вообще пустое, а у второго - значение, которое вводил сосед. В итоге пришлось расширить стандартную таблицу AUFK и писать значения туда. Проблема решилась.

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