Коллеги, даже не знаю, что нужно – совет не совет, но очень интересно делал ли кто-то что-то подобное и насколько это потом аукнулось.
Потребовалось изменить длину поля ATZHL в таблице CAWN – набор значений ограничен количеством 9999 (numc 4), чего сильно не хватило для наших задач.

Рассматривали два варианта подхода:
1. Создание своего домена, своего элемента данных и подмена в таблице.
т.е., вместо ATZHL ATZHL NUMC 4 0 предполагалось получить
ATZHL zATZHL NUMC 8 0
к большому сожалению, на последнем этапе получили от SAP ERP сообщение:
Primary key change not permitted for value table CAWN,
Message no. AD300
хоть se11, хоть se14 упирались именно в это сообщение. Выбор нот на sapnet кошмарно беден, вот и не смогли пройти дальше.

2. Смена разрядности в домене ATZHL.
т.е., вместо ATZHL ATZHL NUMC 4 0 получить
ATZHL ATZHL NUMC 8 0
Этот вариант трудностей в реализации не вызвал, естественно, автоматически были внесены изменения во все таблицы, где поля использовали этот домен.

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

В тестовой системе провели набор всевозможных тестов, как по проверке доступности старых значений классификатора так и с добавлением новых.

В целом, вроде все нормально, но что-то не хватает уверенности для повторения этих модификаций в DEV и PROD.

Буду рад любым советам.

Аукнется всем. Не сразу, но да.

А почему вы не используете признаки со ссылкой на таблицы?

Попробуйте сделать так:
1.Удалите все значения из справочника признака, предварительно сохранив их в файле.
2.Поменяйте разрядность признака
3.Восстановите значения признака

Вот где-то такое чувство и есть.


Крайне интересная идея,
если можно, niemda, - подскажите материалы, где это можно узнать получше!

Если ничего не путаю, это в CT04 настраивается

Оно все там,
вот только не понятно, как использовать упомянутые niemda признаки со ссылкой на таблицы.

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

А в чем проблема?
CT04->Знач.->Другая проверкЗнач->ПроверТаблица

Спасибо, попробуем.
Пока не сильно верю, что этот вариант обойдет ограничения, но проверка это решит быстро.

to Chirva, самой проблемой не поделитесь?

Легко!

Естественно, если признак "цвет", то и значений не так уж и много - от степени дифференциации,
но в нашем случае, мы работаем не с цветом, а с запасными частями для автомобилей.
Вот через классификатор пытаемся реализовать легкий способ взаимозаменяемых деталей.
Связь - через "оригинальный код".
Т.е., одном ОЗМ может быть присвоено несколько оригинальных кодов,
а один оригинальный код может быть присвоен многим ОЗМ.

Ну тогда я не знаю как тут может помочь F4 и/или проверка значений признака. Но вот, так сходу, конфигурируемый материал сюда в самый цвет. Не рассматривали этот вариант?

Объемы пугают! Мы работаем с большим набором брендов. Да и запасные части и оригинальные и подешевле.
Десятки тысяч ОЗМ по запасным частям, сотни тысяч оригинальных кодов,
огромнейшая разница в ценах внутри оригинального кода - сильно зависит от производителя, достаточно не слабо зависит от метода доставки.

Вот из всех вариантов и избрали путь через классификатор.

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

Еще думаете, что конфигурируемый материал это накроет?

Легко. Классификация покрывает лишь часть возможностей, предоставляемых конфигурацией

Вы так интересно поставили вопрос Я не понял, Вы этот вариант до лома стандарта рассматривали к Вашему процессу и пришли к выводу, что отпадает? Если да, то я молчу.
Или, Вы особо не знакомы с этим функционалом и спрашиваете возможно ли его прикрутить к Вашей задаче?
Я бизнеса Вашего точно не знаю. Могу сказать, что по объемам данных особых проблем не будет. Конфигурируемый материал, это и есть классификатор, только таблицы другие и применяется это для более детальной классификации, скажем так. Пример - конфигурируемый материал в заявке. Делаете заявку на материал(М) 111 к нему признаки, далее вторая заявку на М 111 к нему свои признаки и тд, то есть ключ будет в классификации не М, а номер заявки + М. Грубо говоря так.
Вот теперь смотрите, накрывает это Вашу задачу или нет.

В схеме 1 ОЗМ может содержать "много" оригинальных кодов, а 1 оригинальный код может быть присвоен "многим" ОЗМ.

Сколько конфигурируемых материалов описывать?
Если сейчас ОЗМ - десятки тысяч, а связанных с ними оригинальных кодов - сотни тысяч.

Причем, и то и другое динамически меняется. Постоянно расширяется.