Добрый день!
Если не в напряг поделитесь мыслями о реализации следующего сценария.
Есть 15 отделов сбыта, особо нечем не отличающиеся.
Требования.
1. каждый отдел видит только свои закаы.
2. Список товаров для продажи общий (10 000)
3. Базовый прайс лист единый (условие pr00)
4. внутри отделов клиентам дают дополнительные скидки и специальные цены, остальные не должны этого видеть.
5. Отдел в принципе может продать клиенту другого отдела, но нужно чтобы это было видно.

Принятый вариант : одна сбытовая организация. В ней ведутся ОД. К заказам приделать дополнительное разграничение доступов по отделу сбыта (sale_office). Несколько каналов сбыта, но справочники ведутся в общем. Условия тоже.
Проблемы :
как разделить доступ по условиям (специфичным для отдела)
нужен абап для доступов к заказам
неудобно попеременно вводить дебиторов и заказы (общий канал сбыта все время мешается)

Вот я и думаю , может все таки 15 сбытовых оранизаций сделать и справочники множить на 15 ?????

извините что так длинно , заранее спасибо за ответы.

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

Я наверное плохо выразился. НЕ размножать справочники, а размножать сбытовые ракурсы для материалов. Нужно будет расширять материал на 15 СО.
Кроме того условия по ценам. В стандарте PR00 (да и остальные) включают СО-КС. Нужно будет либо цены также вести 15 раз либо сделать условие с последовательностью доступа скажем по БЕ.

А чем не подходит отдел сбыта?

И все-таки я бы не размножал. Если у вас более-менее приличное число клиентов/материалов/условий, то "x 15" даст "офигенную дробь" . Проблема будет даже не в создании, а скорее в поддержании изменений. Что касается объектов полномочий, то да, в стандарте есть некоторое ограничение. Но, могу ошибаться, в данном случае может быть проще сделать на обработке заказов дополнительную проверку полномочий на отдел сбыта как описано тут -> SAP Library

материалов примерно 10 000
условий (общий прайс ) 3000
контрагентов не нужно множить на все со . ими как раз занимается один отдел, тут все хорошо .

Чем не подходит отдел сбыта.
1. не является объектом полномочий для заказов и условий (лечится абапом)
2. не отображается во всех сбытовых транзациях и отчетах в отличие от СО.
3. для разделения контрагентов между отделами нужно будет приделывать какую то доработку которая по отделу будет оповещать "чужой контрагент".

Иметь (и поддерживать) 150 000 записей в таблице, вместо 10 000 все-таки фигово.
Но для САПа это не смертельно. Проблема, повторюсь, будет не в объеме таблицы, а в поддержании целостности всех 15 дублей одной ОЗМ в разных СО.

Решение приемлемо. Там проверка на пару десятков строк. Причем, если п.3 тоже относится к созданию заказов, то это 2-в-1.

Вот тут да. Крыть нечем. Но, может, это не настолько критично? В инфо-системе, например, отдел сбыта есть.

Надо проверять на наличие в записи дебитора того-же отдела сбыта, к которому приписан пользователь, или пустого. В рамках п.1 прокатит?

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

А насчет синхронизации 150 000 записей, так это тоже небольшая разработка сделать табличку которая бы прописывала откуда куда копировать данные (аналог саповских общих кс и сектора) ну и понеслось . меняем в одной сбытовой организации меняется в другой.

Дело ваше. Но это дальше от стандарта, чем дополнительная проверка полномочий на создании заказа.

Это в каких отчетах не отображается?

я конечно вклиниваюсь в вашу горячую дискуссию, но по мне так лучше и впрямь создать свой объект полномочий Отдел сбыта и с ним работать. И всё в рамках одной СбОрг. А отчёты сроду стандартными в большинстве случаев не бывают, опять таки стандартно можно как выше правильно говорили и с помощью ИСЛ, так и с помощью SAP QUERY. Один мАААаааленький абапик с объектом полномочий и столько лишнего отметётся в дальнейшем, всё разумно.

с контрагентами по не своему отделу - написать в экзите проверку значения группы сбыта в заказе и в ОЗД по умолчанию и если не совпадает, то инфо сообщение об этом. Тоже просто, даже не надо быть для этого абапером

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

А в чем кто видит проблему с 15 сбытовыми организациями ?

програмка по размножению данных материалов из одной СО на несколько не сложнее той , которая проверяет свой это или чужой контрагент.
А 150 000 записей в сбытовом ракурсе вроде тоже не так уж и страшно.

Чем это еще плохо ?

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

Решение было правильное.

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

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

Не так уж и страшно. Но именно потому, что их должно быть 10 тыс., а не 150 тыс. это становится неверным.

"Я все сказал".

P.S. Вы еще можете голосование устроить.

Большое спасибо всем ответившим.
Голосования не надо. И ходить по кругу наверное тоже больше не стоит.
Я бы сказал оба решения приемлемы. Наверное пока пойду тем путем каким шел (одна СО и отделы)
Если вдруг еще возникнут какие нибудь конкретные замечания то буду рад услышать.