Изменение серийного номера материала в IQ02

[Uukrul]

В общем виде, если не запрещено, то системе позволяет изменить серийный номер пользователю используя транзакцию IQ02. Такое изменение может привести к следующей проблеме, например, через пару месяцев кто-то находит документ прихода или какого-либо движения материала, показывает серийный номер, который есть в документе, но при этом просмотреть данный серийный номер уже не представляется возможным, так как системе сообщает что такой серийный номер не существует в системе. Ясно дело у пользователя истерика, ваша сапа фигня, вот номер есть, в от она говорит, что его нет и вообще верните мне мой номер. Само собой, никто уже не вспомнит, что менялось и на что менялось и зачем. Поэтому стоит задача найти новое значение серийного номера и как следствие найти автора такого изменения.
Стандартно если вы не отключали для объекта EQUI ведение истории изменений, то система при каждом изменении значения в полях объекта создает документ изменений, который содержит все необходимую информацию, кто менял, что менял и когда. Однако с серийным номером не все так просто.

Данные по изменениям объектов ведутся в так называемых документах изменений системы. Документы находятся в двух таблицах:
CDHDR – Заголовок документа
CDPOS – Позиции документа изменения

Что менялось и какие были значения старое и новое находятся в таблице CDPOS и тут сразу же появляется проблема, задать запрос к этой таблице по имеющейся информации, а это код материала и серийный номер не представляется возможным в принципе, так как таблица большая, да и еще является кластерной, так что построить какие-то индексы для ускорения работы выборки, например по запросу вида, где изменялось значение поля EQUI-SERNR со значения ZZZZZZ, не получится, точнее запрос то задать можно, но вот ответ вряд ли кто дождется. А вся проблема в том что объектом в системе является не серийный номер в связке с кодом материала, а единица оборудования (ЕО), причем она ведется даже если вы задали ведение серийных номеров без ЕО и соответственно запрос на получение изменений надо строить отталкиваясь от номера единицы оборудования, а не серийного номера.

И так есть таблица CDPOS, со следующими ключами:

• OBJECTCLAS - Класс объекта, в нашем случае класс объекта ЕО = имя основной таблицы, где хранятся единицы оборудования.
• OBJECTID - Код объекта, в нашем случае это код ЕО, вот если бы серийные номера велись отдельной таблицей, то такой проблемы не существовало бы, так как как минимум мы всегда знали бы второе поле ключа, но в данном случае кода ЕО мы не знаем.
• CHANGENR - Номер документа изменения, тоже не известен.
• TABNAME - Имя таблицы = EQUI.
• TABKEY - Тоже не известен, но обычно это мандант + номер объекта, т.е. в случае с ОЕ, это будет CHAR_3 + CHAR_18, но опять же кода ЕО мы пока не знаем.
• FNAME - Ну тут просто это код поля серийного номера из EQUI, поле SERNR.
• CHNGIND  - Тип операции, в нашем случае мы знаем что была смена серийного номера, т.е. тип операции U - Update ну или еще можно D - Delete, ну если кто умудрился сделать удаление обойдя проверку на наличие серийного номера в документах.

В общем задача найти номер ЕО. Для этого надо вернуться в документ материала в котором есть старый серийный номер и по коду материала и серийному номеру нужно зайти в таблицу OBJK и в ней по значению полей:

• SERNR
• MATNR

Находим любую первую запись (там есть индексы на эти поля, так что все должно отрабатывать быстро) получаем значение из поля EQUNR, это и будет номер единицы оборудования ЕО, а значит уже известно значение для поля OBJECTID для запроса по таблице CDPOS. При указании только значения в полях
OBJECTCLAS  = EQUI
OBJECTID = Номер ЕО
Система быстро выдаст вам все операции изменения с серийными номерами, а ограничив запрос по полю SERNR получит новое значение серийного номера и кто и когда это сделал.
Как результат, пользователи спокойны, а ваши волосы чистые и ухоженные  ;)

PS: Картинок особо нет, но они вроде как и очень нужны в данной ситуации...