2 Besa,

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

Из-за гетерогенности нашего бизнеса, старались найти максимально универсальное решение - классификатор показался лучшим выбором.
Этот "выбор" хорошо лег на задачи по другим направлениям: шины и масла имеют не такой богатый набор значений у признаков,
а проблема нашлась только в запасных частях - именно из-за их большого количества.

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

С точки зрения реальной специфики бизнеса запасных частей, самая большая специфика - объем!
Каждый год меняются модели, каждый год обновляются как оригинальные каталоги так и не оригинальные.
Знаменитый TecDoc доходит до пары десятков гигабайт - тащить это все в SAP нет смысла, слишком много лишней и не востребованной информации.
И все потому, что одна буква в модели того или иного авто может сильно изменить перечень подходящих запасных частей.

Вот и пришло решение:
1. Использовать классификатор;
2. Как один из признаков - оригинальный код;
3. Дополнительно в виде признака использовать производителя;
4. Вне классификатора, в ОЗМ использовать артикул производителя, как один из идентификаторов.

По набору производитель+артикул - проставить во все ОЗМ привязку к оригинальному коду.

Вот в этом месте и остановились.

Сейчас проверяем отказ от CAWN через свою таблицу - спасибо за советы niemda и zsap.

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

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

Зачем ОЗМ? Вы же можете использовать партии материала
Запасы запчастей можно хранить, как партии конфигурируемых материалов с классификацией.

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

2 Удав

Увы, "тип" запчастей не говорит ничего.
С точки зрения "шин" можно размышлять о конкретном конечном наборе признаков и их значений - это действительно будет конечный набор.
А с точки зрения запасных частей, если использовать тип - то, в набор признаков и их значений придется положить всю иерархию деталей, производителей, моделей и весь набор их разновидностей.
Элементарная "прокладка" в двигатель имеет огромный перечень моделей к каким она подходит и не меньший перечень моделей к каким она не подходит!
Вот для корректности определения и служат оригинальные каталоги, где отталкиваясь от производителя, модели, типа двигателя, года выпуска - вы получите точное значение КАКАЯ прокладка Вам подойдет. Вот этот идентификатор и будет "оригинальный" код.
Пример не по прокладке, а по щетке с оригинальным кодом 6272279, причем, там же видно, что из общего перечня всех щеток, лишь одна может пойти на другой оригинальный код - FBOE22

По "партиям" - еще сложнее.
1. Используются для других задач;
2. Использование большого количества партий сильно затруднит нормальную жизнь - у нас часть SAP ERP обслуживает розницу, и если вместо одной постоянной партии (99.9% случаев) начнем использовать множество - думаю, что розница станет!

to Chirva, кажется я понял, Ваше примерное положение на пути к реализации БП. Теперь понятно, почему ребята рекомендовали набор значений ориг.кода через проверочную таблицу. В продолжение этого пути, думаю, что Вам нужно заглянуть сюда
http://www.sapboard.ru/forum/viewtopic.php?f=13&t=72275

Спасибо!

Думаю, что это поможет, но и кроме этого потребуется сильно пописать Z.
Добрый человек в начале проекта подсказал, как удобно будет продавать,
если видеть на экране симпатичную табличку с данными о текущем наличии товара и информацией о том,
на каких складах он находится! ..... и так чтоб кнопка refresh была.

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

А с классификацией разве не так?


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

Насколько я понял, тут другой подход - по коду ищутся аналоги. Это - другая таблица вариантов, с кодом производителя.


1.Для каких?
2. Если партии создавать не на каждую закупку, а на уникальную совокупность характеристик, то они просто заменят собой большое количество материалов.

2 Удав

Я раньше писал об объемах внешних каталогов - только TecDoc имеет размер порядка 18 гигабайт.
Если выбросить картинки, то будет 10 гигабайт. Вот эти 10 гигабайт и обеспечивают нормальную идентификацию не оригинальных запасных частей по моделям и производителям автомобилей. Пример о прокладке.
Кроме TecDoc (каталог не оригинальных запасных частей) еще есть оригинальные каталоги - да, они меньше! Но не факт, что с них легко достать информацию.

Вот и вопрос - зачем это все тащить в SAP ERP?

Второй вопрос - что делать через 3 месяца, когда появятся более актуальные каталоги?
Когда появятся новые модели, запасные части? Когда тот же TecDoc подружится с очередным производителем и каталог прибавит 10-15% объема?

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

Партии.
Используются для разделения товаров прошедших таможенную очистку и не прошедших.
Реализации возможны и того и другого. Но в 99.9% случае (расчет по количеству, а не по суммам) - реализация именно из партии товаров с таможенной очисткой.
И как писал выше, сменить концепцию использования партий и перейти на их большое количество - ОЧЕНЬ сильно затруднит работу розницы.
А уж партии по качественным характеристикам - нет смысла:
а) для всех товарных групп, кроме запасных частей - не так уж и много признаков и их значений;
б) для запасных частей - значений признаков огромнейшее количество, хоть рассматривать Вашу идею с большим деревом, хоть наше решение по двум признакам - бренд и оригинальный код.


update. Исправил пример о прокладке.
линк содержал квадратные скобки в своем составе.

2Chirva
1.Вы спросили, справятся ли конфигурируемые материалы: я ответил - справятся и привел пример.
Естественно, на ходу менять решение, которое эксплуатируется несколько лет, тяжело.
Будете ли Вы его менять - ваше дело.
2.Почему Вы считаете, что сотни тысяч партий серьезно затормозят работу R/3, причем "ОЧЕНЬ"?
У нас несколько миллионов партий и ничего, нормально.
Кстати, признак таможенного учета также можно на классификации партии вести.

Апгрейдиться будете — будет интересно.

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

Не SAP ERP, а работу бизнеса.

Цепочка "Клиент-Заказ-Склад" имеет разрывы в пространстве и времени,
достаточно много сильно похожих товаров, есть варианты полного совпадения, но разные методы доставки и из-за это ощутимая разница в стоимости.
Полностью перейти на средневзвешенную стоимость не получается - требование локального законодательства имеет отдельные требования которые могут обеспечить проблемы, если одинаковый товар закупался/продавался с колебанием цены в 25-30% и более процентов.
Что уж говорить, если совершенно взаимозаменяемые детали имеют разное происхождение - одна из Европы, другая из Турции, третья из Китая.

Вот поэтому и ведем ОЗМ на уровне - "точная идентификация изделия до уровня оригинального кода/артикула производителя + бренд".
Если укрупнить ОЗМ, но часть идентификации перевесить на партии, цепочка "Клиент-Заказ-Склад" не дойдет! Если на уровне оформления заказа все это под рукой и в электронном виде, то при выдаче товара кладовщик повесится подбирая именно те партии, которые указаны в выходных документах (прошу учесть, что на складе документы по отпуску не создаются, а с ними на склад уже приходят за товаром).

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

Спасибо.
В принципе, эта проблема стандартная, но преодолимая.

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

При чем здесь средневзвешенная стоимость, если на материале ведется партионный учет?

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

ЗЫ: блин, не хотелось ведь вступать в дискуссию, но затянуло
Если Вы уже приняли решение, что остается ваш вариант, то зачем говорить что он единственно правильный?