Учите матчасть, и разработки вам понадобятся только для формуляров и интерфейсов. Пример: мы с даркдаком (ну и еще группой товарищей, которые не заходят на форум) сделали проект, где для FI были разработки только программ печати на экзотических бланках и все. Так что учите матчасть, и не будете изобретать Z-велосипед.

Спасибо - порадовали Значит всетаки возможно внедрить в России FI без бесконечных Z

мне больше всего понравилось когда мне прислали от туда письмо и предложили вакансию fi консультанта с зп раза в 2 меньше:)

Такое бывает, если вместо 1С на макаронной фабрике ставить R3.

Такое как раз бывает когда клиенту нужен R/3 - и ставят его профессионалы, знающие что R/3 - это не еще один язык программирования для написания 1С подобной системы, а готовое ERP решение. И прежде чем чего-то начинать городить, не мешает проверить - а нет ли этого уже в системе?

К сожалению, примеров таких проектов пока немного...

Слушайте а вроде же Новасофт начанал проект в Евросети. Разве не так? Где они сейчас та

И к чему тут отнести фукциональные модули? Вы их не юзали совсем? А если юзали то как это без Z? Голый R/3 это куча народу его обслуживающего, нам такое не надо.
Так что Z жить и жить, а всем нам как программерам так и функционалам повышать свою квалификацию.
Да и в конце концов кто сказал что разработка это плохо?

PS я не абапер

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

Только поймите правильно - разработка разработке рознь, одно дело программировать действительно недостающий функционал, отчеты и расширения системы стадндартными саповскими путями, другое - переписывать то, что уже написано до нас - причем написано куда как качественнее. На таких проектах действуют два взаимоподдерживающих принципа - "мы знаем, что в сапе функциональность AAA не реализована/реализована криво, поэтому вместо нее мы делаем АБАП-разработку ZZZ, которая конечно же гораздо лучше любой саповской шняги ". "Не реализованный" или "криво реализованный" функционал выделяется по принципу "что не настраивается за полчаса".

Вот даже по поводу отчетов не всегда соглашусь с необходимостью программирования. Часто задача решается созданием вариантом стандартного отчета, в котором нужным образом расставлены нужные поля и применены нужные фильтры. Обычно потребность в таких отчетах выявляется после продуктивного старта. Хотелка должна удовлетворяться быстро. Но вместо варианта отчета с трудозатратими в полчаса сначала создается спецификация (неделя), потом абапит абапер (два дня), потом сырая версия тестируется (сколь угодно долго), потом дорабатывается, и все это время юзеру доказывается недоделанность сапы.
Еще популярно написание прог закрытия периода - это в сад.
Совсем дикий вариант - нет спеца по сбыту или ММ, вся материальная аналитика делается абапом в длинных текстах к бухгалтерским документам. Или размазывается абапом тонким слоем по полям блока контировки. Затраты на разработку размазывалки и отчетов для такой аналитики совершенно не оправданы. Точно так же делается стандарт функционала ТОРО абапом на контроллинге, TR на FI и тому подобное.

а потом абапер уходит на более рыбное место...

Новасофт - генподрядчик. Он никуда не делся, просто кроме Новасофт на Евросети еще пара-тройка компаний работают.