Друзья,
решил создать такую тему, так как известно, что в некоторых компаниях очень широко развит НЕ-стандарт,
т.е. разработанные самостоятельно бизнес-логика и реализованные на ABAP практически самостоятельные модули в системе SAP.

Поделитесь пожалуйста встречались ли Вам такие вещи, и что именно делали или видели с помощью НЕ-стандарта?
маленькие и средних размеров user-exitы не берем во внимание...

Ни у кого не было опыта по созданию своих функциональностей?

Практически самостоятельных модулей не создавал. Были разработки по интеграции какой то функциональности с другим модулем, многое писалось на Z, писал Z разработки для связки разных модулей, разработки для наворачивания функциональности модулей. Зачем Вам это? Какую цель преследуете? Вообще не думаю, что обилие Z разработок всяких, это круто, думаю чем меньше тем лучше, остальное идет под заточку предприятия.

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

Rednaxela, писал. А в чем, собсно, интерес? Ничем особо не отличается от обычной работы.

У нас на проекте понаворочено связей RE-FX c FI-AA - Осы привязаны к объектам недвижимости.
Реализовано в основном через BADi.
И по этой причине все инвентаризационные формы по ОСам мною переписаны, танцуя от модуля RE-FX
Как это раценить - как стандарт или нестандарт?

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

Для консультанта разработка всегда необычная работа

Судя по моему опыту практика достаточно частая. Но, к сожалению, в подавляющем большинстве случаев вызванная банальной некомпетентностью команды внедрения.
Нормально ли это? Ну как посмотреть. В принципе САП предоставляет неплохую техническую базу и среду разработки для написания своего собственного бизнес ПО
Другое дело что заказчик вряд ли оценит подобное творчество адекватно. Со временем, естественно.

Плюс не совсем понято что вы имеете в виду под собственным модулем. Если рассматривать как аналог стандартного модуля САП - то, ИМХО, в РФ такого никогда не писалось.
Да и нереально это без участия самого вендора.

Действительно непонятно, что подразумевается под модулем.
Если любая объемная Z-разработка, то её достаточно на любом проекте, что обычно обусловлено наличием специфики и отсутствием аналога-решения в стандарте.
Причем "наличие-отсутствие" зависит от версии системы, патчей, компететности проектной команды и заказчика, и т.д. Решение же о такой разработке принимается на каждом конкретном проекте, исходя из ряда условий актуальных именно для этого проекта.
Поэтому IMHO нельзя выделить из общего числа Z-решений частные, которое с ходу подойдут конкректному проекту.

1. Довольно часто 2. Если нет стандартного решения, а делать надо , то нормально.

Решение STC (Solution for Transport Companies) на платформе SAP

Добавлю, что иногда дело не только в наличии/отсутствии функциональности в стандарте, но и в удобстве оной. Например, на прошлой работе консультант нам припер список изменений для функциональности входящей транспортировки (inbound shipment). Поскольку весь процесс переворачивался практически с ног на голову, да еще и 95% функциональности стандарта вообще было не нужно, то было предложeно написать свой "мини-модуль" с экраном, отчетами, табличками и т.п. Было затрачено гораздо меньше времени и усилий, чем если бы мы начали ломать стандарт. Юзеры были довольны как слоны, до сих пор успешно пользуются.

Не скажу насчет "нормальности", но если рациональнее/проще/дешевле сделать свое, чем ковырять чужое, то почему бы и нет? Конечно, надо принимать во внимание и последующую поддержку: у нас внедряли те же, кто и потом будет поддерживать, так что проблем не было.